今天我们直接带您了解比特币！ （上）

阅读时间：20分钟

带你一起变现比特币（一）

在比特币市场放缓的情况下，作为工程师，我们有必要了解一下庞然大物比特币的变现原理。然而，目前关于比特币的文章大多是基于科普的，都试图让你了解比特币的概念。笔者认为，这种思维对于普通人来说是可以的，但对于IT从业者来说，仅仅停留在一个肤浅的概念上是不够的。我们有必要探索一下比特币是如何实现的。

今天，原味区块团队带你实现一个简单的比特币。由于这篇文章涉及到很多技术细节，所以我不会在本文中详细介绍比特币和区块链的原理。小伙伴们可以移动到30分钟自己写一个区块链（一)简单了解区块链的原理和背景，同时本视频从宏观层面阐述了区块链的实现（国内的朋友需要翻墙）

比特币的工作原理

看完以上资料，你会对区块链有一个大概的了解。从这里开始，我们将带你从Signature、UTXO、Transaction、Block、Blockchain五个部分从小到大实现区块链。

本文代码基于Java，文末会给出通用代码地址。

文章开头我们先创建一个文件夹，后面的所有代码都会在这个文件夹中创建文件

一.什么是数字签名

与签名一样，数字签名是个人身份的标识。上图已经体现了数字签名的四个要素，分别是：

私钥：用于签名，不公开

公钥：用于验证签名，公开

数据：待验证的数据

签名：用私钥签名的数据

整个过程是发送方使用私钥和数据共同生成哈希签名，然后将数据和签名一起发送给接收方。接收方收到数据后，可以通过签名、数据和公钥共同验证数据是否由该公钥发起。

这在比特币中意味着什么？试想如果没有签名授权机制，如何防止别人花掉你的比特币。这样的签名过程保证了只有拥有比特币的人才能签署比特币，从而花费该比特币。

了解了这一点，我们来实现一个简单的 Verifier 类，其唯一目的是接受信息、签名和公钥，并验证三者是否匹配。

代码示例

下面是完整代码，先

验证成功返回true，否则返回false。

二. UTXO，未使用的比特币

什么是UTXO

UTXO的全称是未使用的交易输出比特币能转给朋友吗，顾名思义就是未使用的比特币。简单来说，每个人的比特币是由多个未使用的比特币组成，每个比特币来源只能是

挖矿得到

有人转发给你

每个人都应该知道，在比特币中，个人账户的余额是通过从头到尾运行整个账本（区块链）上的所有交易来计算的。因此，如果每笔交易的输出没有被其他人用作输入然后转移给其他人，则它是未使用的交易输出。这样的输出，也就是UTXO，代表了某个人的资产（公钥）。由于UTXO与交易密切相关，我们将UTXO定义为某个特定的输出。

代码实现

这里简单介绍一下 .的构造函数。

将 UTXO 定义为交易的输出。交易由交易的哈希值唯一标识。

下面附上完整的UTXO代码

UTXOPool，在内存中维护所有的UTXO

我们已经知道，每个人所拥有的比特币实际上是从所有转账记录的开始到结束计算出来的（每个区块都会有一定的挖矿奖励，这也是这个系统来源中唯一的比特币），那么每个当你想知道你的个人资产（所有UTXO）时，你不是必须从头到尾计算吗？同时，对于上面的每一笔交易，我们也需要无法得到具体的交易输出。我们如何才能相互联系？

此时，小伙伴们应该想到了，我们可以直接在内存中维护一个包含所有UTXO的Pool。当一个人发起一个新的 Transaction（将他的 UTXO 转移给其他人）时，我们可以快速验证这个交易是否在我们的 Pool 中，并更新我们的 Pool 以应用一个新的 Transaction。链接UTXO和Transaction输出，我们只需要维护一个HashMap，使用HashMap来维护UTXO Pool，链接UTXO和Transaction Output。

总代码如下

事务，事务的核心是事务

对于比特币，系统的核心是交易。每个块包含许多事务，每个事务包含多个输入和多个输出。生成Transaction只有两种方式

第一个计算区块的人将获得 coinbase 交易奖励

由用户发起并在网络中泛滥的普通交易

对于用户而言，发起交易的方式是向系统发送交易。下图是一个事务的结构

如您所见，Transaction 包括两部分：消费原始 UTXO 和生成新的 UTXO，即使用输入声明的先前 UTXO，以及使用输出创建新的 UTXO。

前面我们已经提到，Transaction 的每个输入都是一个 UTXO。而且，要成功申领 UTXO，需要对输入进行签名。所以每个 Transaction 的 Input 包含

使用哪个UTXO（交易哈希+输出索引）

UTXO 的签名

我们先创建一个类，并在里面创建一个内部类，代码如下

之后，我们考虑交易的输出。 Transactiond 的每个输出都代表一个新的 UTXO。这个UTXO的关键属性应该有两个：

新 UTXO 的所有权（给谁）

UTXO的价值（转多少）

关于第一个问题，熟悉比特币基本概念的朋友应该知道，在比特币系统中，身份是由公钥唯一标识的，谁转让就相当于填写谁的公钥

p>

所以在 Transaction 类中，我们添加了第二个内部类

交易代码实现

包装完我们的两个内部类之后，让我们考虑一下 Transaction 需要哪些核心 API。

First Transaction 需要能够支持 Coinbase Transaction

在 Transaction 中添加一个字段来表明它是否是 coinbase 交易

事务需要能够有自己的哈希

将字段添加到事务中并不难理解。既然我们的UTXO是根据交易hash和index来决定一个输出的，自然会涉及到交易hash

交易需要能够签名，所以需要获取需要签名的数据

不难理解，第一个输入需要签名数据。必须建立第一个输入（成功索赔之前的UTXO必须正确签名）

事务需要能够转换成数据流并且可以被散列

将整个Transaction转化为字节流

了解了以上功能，那么事务代码实现起来就不难了，下面是完整的代码（包括和）

事务处理程序

到目前为止，我们已经实现了一个简单的 Transaction 类，但是这个 Transaction 正确吗？在区块链上记录后，如何相应地更改我们的 UTXO 池？这两个问题就是我们接下来需要解决的两个问题。我们来看看这个类的主要API组成

一.验证交易是否有效

对于一个交易比特币能转给朋友吗，交易有效需要以下条件

交易输入使用的所有UTXO都存在

每个输入的签名都由原始所有者签名

没有一个 UTXO 被使用两次

在所有输出中，新创建的 UTXO 都是非负的

总输入UTXO的值大于总输出UTXO的值

二.加入区块链后更改对应的UTXO池

在我们的 UTXO 池中记录所有可能的交易

所以，代码不难实现，完整代码如下