又一次大拥堵之后，以太坊何去何从？Deep Talk 美图以太坊DPoS算法实现团队

最近，以太坊又经历了一次大拥堵。 美图基于以太坊框架实现了DPoS算法，并开源了代码（见文末链接）。 希望有了这个解决方案，以太坊的发展会有更多的选择。

图：过去一周，以太坊交易出现大规模拥堵

有些人对以太坊并不是特别熟悉，所以在开始之前先简单介绍一下以太坊的一些基础知识。

整个以太坊由几个模块组成：

协议管理，一种是用于外部访问和交互的JSON-RPC协议（HTTP），另一种用于节点发现和区块/交易数据（TCP/UDP）同步；

交易池，存放当前未打包的交易；

共识算法，目前正式版包括PoW和PoA（Clique），共识算法的主要功能是确定新区块的产生、合法性验证和冲突解决；

EVM，用于执行智能合约代码的虚拟机

StateDB由MPT（merkle patric trie）和KV存储组成。 以太坊中的所有数据最终都会落入 KV 存储。

钱包通过JSON-RPC将签名后的交易发送到交易池，然后由共识算法判断是否可以出块以及时机（非挖矿节点不会主动出块，只会被动接收块），然后写入块到 DB 。

由于以太坊是根据Gas Price来决定先打包哪些交易，所以我们可以看到以太坊交易池中会有一个最大堆来存放当前价格较高的交易ID。

另外，为了避免交易重放的问题，以太坊还在账户中引入了一个nonce，用来表示这是当前用户发出的交易编号（从0开始，严格递增+1）。 比如A转给B和C的两笔交易是tx1（nonce=1）和tx2（nonce=2）。 这两笔交易实际上是相互依赖的，节点并没有收到nonce = 1。在交易的情况下，nonce = 2是无法打包的（假设当前节点中A账户的nonce = 0）。

于是就有了下图中的Queued Pool和Peding Pool。 如果有事务来，它会先进入Queued Pool。 如果nonce值满足要求，就会被迁移到Pending Pool中。 Pending Pool 中的所有交易都被认为是打包的。 Pending Pool 也可能因为区块回滚导致交易返回到 Queued Pool。

然后由共识算法部分决定当前节点是否可以出块以及出块的时机。 不同的共识算法不尽相同，在此不再详述。 最终打包的块将被写入数据库。 至于DB里面怎么存储这些账户和对应的资产，不同账户模型的存储实现是不一样的。

比特币的账户模型是UTXOs（unspent transaction outputs），下图来自Ethereum Design Rationale。

关于优缺点在下面引用的以太坊设计文档中也有详细的描述，这里就不一一列举了。 主要说明一下两者的区别：

Account账户模型和我们传统的业务类似，很容易理解，就是把余额直接存到DB中，但是也引入了其他的问题，比如无法判断交易是否重放等需要account nonce等手段协助解决。

UTXOs模型 从上图可以看出，存储的不再是余额，而是未花费的交易输出。 这种机制可以简单理解为一次性校验。 托收类似于不给你签一次性支票（only is used once），转账也类似，看你有哪些面额的支票，找出支票签名的全额，一起给对方。

相关索引：以太坊设计原理

.

那么延伸出一个问题，账户的余额怎么存储呢？

以太坊的账户余额数据存储在由Patricia Trie和Merkle Trie组成的（MPT）树上，主要利用Patricia Trie的特性实现账户余额的快速查找和Merkle Trie证明交易是否被篡改。 Patricia Trie和Merkle Trie之前已经在很多非区块链场景中使用过（比如内核新的ip路由查找算法就使用了patricia trie）。

存储余额的树是所有区块共享的，如下图所示：

可以直观的看出，区块中每产生一笔交易，实际上只是复制修改过的账户和对应的父节点相关数据，并生成一个新的trie根，这样在不同区块中找到的数据余额就是相应区块的最终余额。 比如我们的最新余额就是沿着最新的区块搜索到的余额。

除了余额树，每个区块头还有交易和收款树。 这两棵树对于每个块都是唯一的，块之间没有关系。 如果你想了解以太坊，你必须先了解 merkle patricia trie。

如果你想了解以太坊，你必须先了解 Merkle Patricia trie。 另一种存储是将树的节点内容存储在KV（以太坊目前使用的leveldb）中。 这个替换KV存储也很简单，只要实现GET/PUT/DELETE几个接口即可。

以上是对以太坊整体模块的简单介绍，接下来会细化DPoS算法的一些内容，作为对上一篇文章的补充。

上一篇文章提到了以太坊的三大机制对开发有很大的影响。 如果要基于以太坊进行改造，需要特别注意：

full sync同步所有区块，重放所有交易数据，构建全局状态树；

fast sync (默认) 同步全量区块数据和第N个区块的全局状态树，只回放第N个区块之后的交易数据。 这种机制与Redis的RDB+AOF机制非常相似，避免了回放带来的性能问题（回放事务的主要性能瓶颈在于随机IO读写）；

light sync只同步区块头信息，不同步具体交易内容，主要用于钱包实现SPV功能。

之前我们在开发过程中踩过一个坑，是Fast Sync导致的。 这个在之前的文章中有介绍，这里不再赘述。 Fast Sync在Geth的作者开发这个功能的时候也有更详细的描述，详见PR：。

这里还有一个重要的点没有说，Fast Sync点之前的block其实是不回放的，直接同步最后的balance，所以没办法根据这个点之前的block获取balance。 每个人都需要注意这一点。

DPoS 本身其实很简单。 与其他几种算法相比，它多存储了几种全局状态树：

这些树的作用主要是避免需要从创世块重放数据来获取相关数据，所以这些树的作用和我们账户的平衡树是一样的，都是全局状态树（shared by所有块）并将树的根存储在块头中。 我们这里踩的坑其实和Fast Sync有关。 由于原代码中只有账户的全局状态树，所以在所有的同步过程中，只同步这个账户状态树。 其他的不送，会给我们的选举带来问题。

其他的开发过程主要是一些细节和逻辑的开发，也比较简单，这里就不展开了。 欢迎大家看看Github上的代码。

问答

Q1：DPoS 是否背离了去中心化？

个人认为是偏差。 出块的 21 个节点是一个小中心。 DPoS算法本身就是以牺牲去中心化换取性能（现在很多人也认为PoW矿池算力集中是另一种中心化）。 另外，BM解释的DPoS的另一个优化是假设出块节点是一些知名节点（如交易所、大型矿池等），它们之间可以进行物理通信，所以出块后出块后，不是随机广播，而是先直接发送给下一个节点，这样理论上，出块后的传播时间只是物理链路的RTT。 例如，从美国西部到中国可能只需要几百毫秒。 早期，BM向BitcoinTalk提出比特币性能太差，需要修改共识算法以太坊何去何从，因此被中本聪批评（不信不明白，我不没时间试着说服你，sorry），神V之前也用过DPoS。 在性能提升方面，个人更倾向于分片或者offchain，减少主链上的交易数量。 如果没有强大的技术或信誉背书，DPoS 还是比较困难的。 另外，如何产生动力，带动社区用户继续围棋投票，不断更新迭代验证器。

相关指标：

BM 解释 BFT DPoS 视频

治理，第 2 部分：财阀统治仍然很糟糕

找不到关于中本聪BM的BitcoinTalk帖子，网上还有一些截图

DPOS 与 Dan Larimer 的 POW

Q2：既然DPoS被认为是背离去中心化的，为什么你们还有美图DPoS？

正如上一篇文章的介绍，我们更多的是探索。 此外，DPoS虽然在一定程度上背离了去中心化，但也有其自身的优势。

Q3：你开发这个项目多久了？ 例如，这需要多少人月？

从真正开始接触以太坊的源码到改造完成，我们大概用了2个月的时间，主要是看代码的周期比较长。 总人力大概是3-4人在看做。

Q4：以后会有源码分析直播吗？

不行以太坊何去何从，太详细的代码分析和分享意义不大。 更欢迎大家直接上去看代码，有问题随时讨论。

Q5：目前你有做过真实的网络环境测试吗？ 运行数据呢？ 瓶颈在哪里？ DPoS原则上可以更快吗？

现在是内网验证，并没有多地域部署验证。 现在将默认出块时间调整得更长一些（5s），所以性能是以太坊的2-3倍。 5s是我们调试的默认时间。 如果假设出块节点都是直连的，出块时间可以像Steemit一样调整为1s。 另外，EOS出块时间的另一个优化是，新出块优先给下一个出块节点，这样时间可以调整到几百毫秒。

Q6：投票和成为候选人是否可以随时投票，任何节点都可以成为候选人？

投票和成为候选人可以像普通交易一样随时进行，但投票和候选人结果只能在下一个选举周期生效。 另外，任何节点都可以成为候选者，所以在线上实操还是需要控制成为候选者的门槛（或者优化算法），否则候选者太多，节点可能需要很长时间才能上线在选举期间排序和计算。 节点不可用。

Q7：投票或成为候选人在美图修改后的以太坊版本中是如何体现的？

我们将投票和候选人相关操作视为普通交易，并在交易中添加类型字段以区分普通交易、投票和候选人相关操作。 这在上一篇文章中也有所体现。

写在后面

未来，美图技术团队会结合自身业务做更多的业务拓展，我们也期待与更多的技术人员交流。

代码开源地址：，以后有什么问题可以随时讨论。