区块链的技术世界观：账本的技术演进(3)

UTXO 与 MerkleTree

UTXO 本身是一种复式记账法。比特币的定位是数字货币，UTXO 属于它的账本业务逻辑。这种记账法的好处是任何一笔交易都可以回溯到创币交易，保证货币只能由创币交易产生，无法凭空产生。如果只是货币场景，UTXO 确实比 Account 模型要安全，但如果考虑到其他应用场景，应用的状态就很难设计出一种 UTXO 模型来追踪变更，这也是为什么后来的面向应用的链放弃 UTXO 的原因。

比特币通过 MerkleTree 提供交易证明，方便没有全量账本的轻客户端校验交易。但比特币的 MerkleTree 是每个账本一个，没有全局 MerkleTree，也就是说没办法提供全局证明，轻客户端的实现就会比较复杂。这方面比特币社区也讨论很久，详情可以参看我以前的一篇文章：《谈谈区块链的 UTXO 证明》。后面会谈到 Ethereum 的改进。

Bitcoin Script

比特币的 Script 可以理解成一种支付校验逻辑的扩展能力。前面说了，去中心化账本的业务逻辑和共识机制融合在一起了，支付校验本身也属于业务逻辑。这种逻辑的变更会影响共识，进而可能导致硬分叉，而提供一种可自定义逻辑的脚本，则是一种兼顾的策略。

同时，比特币的这种能力也给后来的染色币(Colored Coin)提供了机会。本来比特币的账本只能记录比特币的交易，但有了 Script 后，可以在 Script 嵌入自定义数据结构，可以理解成对比特币账本的数据扩展。染色币就利用这种机制来制造新的加密币。

这种机制的好处是染色币不需要重新构建一个去中心化的账本网络，降低了时间以及经济成本。但缺点也很明显，一方面，这种目的毕竟不属于比特币的初始设想，得不到更多支持，另外一方面，比特币 Script 只能嵌入数据，无法嵌入对这种数据的校验逻辑，校验逻辑还需要通过部署独立的节点程序来实现。

于是这种需求背景下，以太坊产生了。

Ethereum: A Decentralized Platform that runs Smart Contracts

以太坊的设想是既然运行一个去中心化账本成本这么高，那能不能先运行一个通用的账本，然后提供机制允许用户在上面自定义业务逻辑?所以它的目的不是数字货币，而是运行『智能合约』的平台。如果说以太坊当前的 PoW 共识机制等只是在比特币 PoW 基础上的优化改良，它的最关键的创新就是智能合约和 Global State Trie。

智能合约

这里顺便扯一下对『智能合约』的看法。很多批评『智能合约』的人说这只是一种脚本程序，并不智能。那这样说智能手机(Smart Phone)哪里智能了?智能家居，智能手表，智能xx不都一样?中文领域里把 Smart 和 Intelligence(Artificial Intelligence，AI 人工智能) 都翻译成智能，确实造成混淆。但这是历史遗留问题了，纠结这个名字没有意义。

于是以太坊提供了一种图灵完备的脚本语言来定义业务逻辑，交易数据中明确允许嵌入自定义数据结构(以太坊 transaction 的 data 字段)，链不关心合约本身的逻辑，只是通过在不同的节点重复运行合约，来保证合约的输出是确定的。它和比特币的 Script 的差异不仅在是否图灵完备，更大的差异在于自定义数据和自定义逻辑的结合。染色币这样的场景，它同时托管了染色币的账本数据和交易逻辑，于是引来了一场发币的热潮。它这种机制带来的挑战是不同的场景的业务逻辑的输入输出不一样，如何存储和维护?如何提供证明?

于是它创造性的引入了 Global State Trie。

Global State Trie

以太坊的黄皮书中通过一个公式来定义以太坊。

σt+1≡Υ(σt,T)这个公式中的 σ 代表以太坊的状态，Υ 代表处理函数(包括合约以及内置的 Ether 交易逻辑)，T 代表交易(包含调用合约的交易)， t+1 的状态等于处理函数在 t 状态基础上处理 T 的执行结果。

而这里的状态的程序表达形式就是一个 Merkle Patrica Trie。

这是一个两层的 Trie，第一层的叶节点上保存的是每个 Account 的余额(Balance)，以及针对合约 Account 的 CodeHash 和 Storage root。Storage root 是另外一个 Trie 结构，叶节点是合约内部的状态。任何一个 Account 的余额或者合约状态变更，都会导致 Global State Root 变更，而每个区块都会在区块头上带上当前区块中的 Transaction 执行完后的 State Root 。

这样，一方面提供一种全局校验机制，只要比较 State Root 就可以快速知道不同节点的状态是否一致，这个和 Git 中引入 Merkle hash 证明机制的原理是一样的。Linus 一次分享 Git 的时候也说了，Git 的这种机制可以让他方便的信任来自第三方保存的代码。有了这套机制后，新节点同步的时候可以信任一定区块以前的全局状态，而不是完全通过区块回放来重新构建。这也回答了我们前面提出的那个问题，如何快速校验不同机房的数据状态一致性。

另外一方面，它也提供了一种单个账号状态和全局状态关系的证明能力，可以通过 Merkle Path 证明一个账号的当前状态和全局状态之间的关系，轻钱包实现就会更容易。

如果纯粹从模型看，以太坊已经是一个非常理想的模型了。大家常说程序就是数据结构加算法，它既提供了数据结构的自定义以及存储能力，也提供了算法的计算环境，理论上任何程序都可以放上去运行了。但套用一句俗话，理想是丰满的，现实是骨感的，这样的全球分布式账本的存储和计算成本太高了，稍微复杂的应用都很难运行起来。

EOS:The most powerful Infrastructure for Decentralized Applications

EOS 自项目启动开始，主打的旗帜就是吞吐和性能。如果说比特币和以太坊两个项目带有一种理想主义特质，EOS 则带有非常明显的实用主义特质。

前面说到，Peer to Peer 网络的问题是无准入，节点数不固定，匿名情况下防作弊成本高。EOS 的 DPoS 思路就是通过投票选举，让参与共识的节点在一定时间内保持稳定，同时通过竞选机制，让竞选节点不再匿名，降低防作弊的成本，然后把注意力集中到吞吐以及应用模型的改进上。

互联网应用开发者看了 EOS 的应用模型后，会感觉更容易理解。看它的 ABI 描述文件，第一眼的感觉就像是在定义应用表结构。它交易结构中直接嵌入的是 Message，相当于 EventSource 架构中的 Event。以太坊的链上还保留了 Ether 本身的交易逻辑，而 EOS 上 EOS Token 本身也是通过合约实现的，只是合约分为系统合约和用户应用合约，整个链成为了一个更纯粹的合约执行平台。

EOS 中没有 Global State Trie，这个问题 Vitalik 和 BM 争论过很多次，这代表了两种不同的思维方式，感兴趣的人可以找来看看，我个人是同意 Vitalik 的看法的。

（编辑：ASP站长网）