Turbo-Geth 客户端：Beta 版的目标

我们没有定死从 Alpha 阶段转向 Beata 阶段的时间点。我们是反过来，确定了一些转向 Beta 版的先决条件；实现了这些条件，就意味着 turbo-geth 已经准备好了。下面就是我们要实现的清单：

让 turbo-geth 支持高效挖矿的难点在于：在任意时间点，都只有一个状态是 “公认最新” 的状态。而挖矿，需要节点产生 “投机” 区块以及 “投机” 状态，以计算出新区块的区块头中需要的状态根哈希值。目前的想法是，“投机” 状态是一块放在内存里的缓存，而且是可以 “复制” 的。“复制” 的意思是，创建该缓存的 lazy-shallow 副本，因此对该副本的改动不会影响节点所保存的公认最新状态。

不过，事实也证明了，当前由哈希化状态（HashedState）和中间哈希值（IntermediateHashes）组成的数据模式不适合于维护这样的缓存。所以我们正在开展纠正数据模式的工作，希望实现可以复制的状态缓存，然后实现挖矿功能。

当前的阶段式同步中，区块头和区块体下载分别安排在阶段 1 和阶段 3。这两个阶段不管看起来还是用起来，都跟其它阶段非常不同，因为它们是在继承自 go-ethereum 客户端的 区块头/区块体/收据/状态 下载实现的基础上开发出来的。这些代码的功能比 turbo-geth 的阶段式同步所需的要更多，可以（也应该）替换成简化后的版本。这个简化的版本已经有一个可用的概念验证了，现在可以测试和撰写文档了。

有一个概念叫做 “共识机制即插即用（pluggable consensus）” ，意思是客户端应该很容易能从工作量证明迁移到权威证明（PoS），也包括能从工作量证明的一个变种切换到另一个变种，从 PoA 的一个变种切换到另一个。实际上，曾经有人用接口来实现共识机制即插即用，但因为还是运行在同一个进程中，通常还是与其它代码紧密交织在一起。我们已经在设计一个让共识引擎能运行在独立进程中的接口。

有了这样的接口，虽然还是能够在同一个进程中运行，但这个接口能够更直接让共识引擎与交易执行适当分离。我们已经为 EtHash PoW 和 Clique POA 实现了一个概念验证，现在正准备集成、测试和撰写文档。

turbo-geth 客户端是从 BoltDB 数据库后端起步的，现在正在添加对 BadgerDB 的支持，最后，我们会完全迁移到 LMDB。某些时候我们对 LMDB 的使用方式会产生一些稳定性问题，这是连 LMDB 的创造者都没有想到的。因此，我们一直在考察 LMDB 的一个支撑性更优的变种，叫做 MDBX，希望能利用上其稳定性提升，使所有功能在未来结合得更加紧密。对 MDBX 的集成已经能够完成了，现在需要测试和撰写文档。