在我们前面的文章中，我们提到，从建设银行转账到工商银行10w元，过程其实是这样的:

1. 建设银行发送报文到人行CNAPS系统
2. 人行CNAPS发送转账报文到工商银行
3. 工商银行发送响应报文给人行CNAPS
4. 人行发送响应报文给建设银行
5. 转账成功，建设银行、人行、工商银行各自更新账本

整个过程中，有几个很有趣的事实：

1. 所谓的转账交易，不过是账本上数字的加加减减
2. 我们的账户，除了各自在工行、建行开设的户头之外，在人行还有一个总账；人行是所有银行的妈，你在任何银行开设的账户，人行都有一个总账；所以打印征信的时候我们要到人行打印
3. 建设银行和工商银行间的转账需要人行做清算，人行提供了信用；建行和工行相信人行不会造假
4. 我们需要信任三个机构：人行、工行、建行，我们相信他们不会造假
5. 人行是所有账目的中心节点，人行的账本对不上了，中国的金融系统就乱套了

然后作为对比，我们来看看比特币是怎样设计的。

中本聪创造比特币之初，在Genesis Block里面付了一句有名的话:”The Times 03/Jan/2009 Chancellor on brink of second bailout for banks”。在白皮书中他很自豪的宣称:”We have proposed a system for electronic transactions without relying on trust. “ 去中心化一直是比特币的指导纲领，那么问题来了，如果让我们来设计一个去中心化的账本，将会面临哪些技术问题，又该如何解决呢？

很自然的，我们设想的是一个类似于分布式数据库的系统，整个系统维护着唯一的账本，每个节点（node）都是一个副本（Replica Set），每个副本保有完全的账本数据，并且节点间相互同步数据，如果部分节点挂掉，不影响整个系统的运行。

用户转账的行为，其实就是这个分布式账本的增删查改。当然，为了简化设计，我们这个账本可以只支持账目写入，不支持删改。

我们开始思考这个分布式账本要解决的两个核心问题：

什么样的交易是一笔合法的交易

• 一笔交易中，如何保证交易账户的完全所有权；如果保证用户A的资金不会被用户B盗用
• 用户A本来有1000元，如何保证他不会转出2000元？

哪个节点有记账的权力，如何保证整个账本是唯一且不可篡改的

• 如果有部分节点是不诚实的，它就会有动机去伪造不存在的交易来获取利益，如何识别并排除不诚实的节点？(拜占庭将军问题)
• 如果A的账户有1000元，发送了1000元给B，由于是分布式系统，部分节点收到了这笔交易，这时候A又发送了1000元给C，另一部分收到了这笔交易，这时候该如何处理？如何保证一笔钱不会被花两次？ (双重支付问题)

为了解决这两个问题，比特币引入了三个核心技术：UTXO交易模型、POW工作量证明、blockchain数据结构组织。且让我们一一道来。

初版交易设计

如果读了之前我们的<比特币hd钱包>系列文章；天然的，我们意识到非对称加密方法是在分布式账本中建立账户的天选之术；

存款

用户A想要建立一个账户，只要在帐目中增加一笔 公钥+金额 的记录就可以了。我们用一个表格表示整个账本，用户A以及用户B各存入50个币的动作可以记作:

这个原始存入的资金我们先不去纠结怎么来的，总之此时账本中有两笔交易，代表着A以及B各自有50个币

验证

在账目1中，如何验证A确实是这笔资金的拥有者呢？非常简单，就是账户资金增加的时候，A对这笔交易数据的摘要用私钥做一个签名，然后再把公钥附在后面就可以了，这样账目就变成了这样:

任何一个要验证账户A的节点或第三方，对其所有权证明用公钥解密，然后对照摘要(digest)即可。

转账

如果A要向B转账20个币呢，我们最简单的设计，就是构造Trans1 - 20，然后同样的方法构造签名即可，这样账本如下:

看起来一切还好，但是这个时候我们发现了一些缺点

1. 收到汇款的时候因为要添加所有权证明，账户拥有者得一直在线监控自己的账户地址
2. 收款人还得验证汇款人的合法性，感觉都点怪；我收钱就好了，还得去管这个钱合不合法？
3. 如果多重转账，或者一对多，或多对一，这个记录格式就复杂了
4. 用户B要验证一笔交易合法性的时候，可能要回溯到账本非常深的位置，因为上一笔交易可能发生在很久之前，这种交易记录的存储设计很难高效查询
5. 最后，这个账目设计中，所有账户的公钥是暴漏在外的；虽然椭圆曲线算法目前看来牢不可破，但是整个安全体系只依赖一个非对称加密算法，比较脆弱

解决方法其实也简单，换个思路，就是A转账给B，B是不需要验证的，只要A提供账户所有权的证明就好了，想想我们平时转账，不也是这样的吗？

那么最简洁的设计，就是借鉴现实世界。每一笔交易都看作是硬币的流转，硬币其实没有特征，它只是从A的保险箱转移到了B的保险箱而已，那么，采用什么办法来表示：这是A的保险箱中的一笔资金币这个譬喻呢？

进阶交易设计

UTXO 模型

比特币的账本世界，构筑在UTXO (Unspent Transaction Output)之上；其实每个UTXO代表着未花费的一笔硬币(数额可大可小，没有限制)；一个账户的资金，其实就是一堆UTXO的集合；转账交易，就是一个或多个UTXO的输入再输出为另外的UTXO而已。你可以想象成现实世界中金银铸币的流通。

那么一个UTXO中包含什么呢？如何作为输入呢？如何构造输出呢？这就是比特币交易的核心技术。

• 我们用下面一张图来表示A保险箱里面的50个硬币 这件事：

把它想象成一个邮筒构造的保险箱，在不打开的前提下，投币是只进不出的。可以注意到，我们并没有直接将Public Key明晃晃暴露在外面，而是先HASH一下，然后贴到保险箱子上面，想要存币的人，只要知道这个HASH值，作为保险箱的ID，就可以直接投币进去啦。

但是保险箱的锁在哪里呢？

• 这张图中，我们引入了一个脚本，称之为 Pubkey Script；具体内容是:

1

OP_DUP OP_HASH160 <PubkeyHash> OP_EQUALVERIFY OP_CHECKSIG

呵呵，像天书吧，不要怕；这是我们特有的保险锁构造。细节会在后面讲到。这里你可以这样简单理解：

为了锁住这个保险箱里的资金，比特币系统设置了一个谜题作为锁。解开这个谜题，才能转移里面的资金。

这个谜题是这样构造的:

1. 记录了A的公开的Public key hash值，开锁的人，需要提供A的full public key，同时验证 hash160(public key) == Public key hash
2. 需要提供A的私钥基于这笔交易的签名Signature, 这样系统可以用full public key来验证公私钥是否匹配

这个过程是通过上面的脚本指令通过入栈出栈执行的，这也为比特币系统验证更复杂的交易逻辑提供了基础，甚至能作为一个简单的虚拟机执行更复杂的组合指令。

整个过程组织如下图：

当我提供一个signature以及full public key的时候，就可以开锁了，开锁下一步自然就是转移资金啦。我们给B汇款50个币，而B的保险箱又是怎么表示的呢？和A保险箱是一样的。

• 带有public key hash ID的保险箱是一个UTXO，这个保险箱用public key hash上锁，而提供signature和full public key开锁，转移资金的过程，就是花费UTXO的过程，其实就是把A的UTXO转移到B的UTXO的过程，这就是比特币最简单的一笔交易

• 我们可以继续拓展下去，可以1对多支付，多对1支付，多对多支付，更复杂的多签名支付，延迟支付等等，今后我们会详细介绍

这个系统有如下优点:

1. 所有的交易都抽象为了UTXO的转移，你可以想象一下，一堆硬币在几个保险箱之间转移的样子
2. 用户其实可以不检查交易的合法性，只要运行分布式账本的所有节点检查通过合法后，确保写入账本就保证资金的安全转移了
3. 每个账户的拥有者在真正花费UTXO之前，是不用暴露公钥的
4. 验证UTXO交易合法行的函数，抽象为几个指令的集合，这个验证行为指令通用化，为智能合约编写创造了条件
5. 这样的交易记录非常容易组织，我们以后可以看到；把这些交易批量打包，组织成名为blockchain的精巧数据结构，有许多优点
6. 一个用户A可以用一个私钥加密多个保险箱，或者多个私钥加密多个保险箱，非常灵活

小结

好啦，看到这里，我们对比特币的最简单的交易构造已经有感性认识了。但是俗话说得好: 光说不练假把式，下篇文章我们就会手工构造一笔完整的交易，让你搞明白其中细节。

另外，我们前面提出了好几个问题:

• 原始资金从何处来？
• 节点如何解决拜占庭将军问题？
• 节点如何解决双重支付问题？

后面我们会一一解答，那么，下次再见。