引介 | Turbo-Geth 客户端：过去与未来

Turbo-Geth

Turbo-Geth 作为一个纯粹出于好奇心的项目，始于 2017 年（没错，就是在 CryptoKitties 导致的疯狂拥堵时期）。一开始是为了探究基于 trie 的数据库模式的替代方案。在 2018 年 3 月，Turbo-Geth 项目从以太坊基金会处获得了一笔小额的奖金（2.5 万美元）。在 2019 年第一第二季度，Turbo-Geth 被用作状态租金（State Rent）研究的状态分析平台。到了 2019 年第三第四季度，Turbo-Geth 也被用于执行无状态以太坊的回溯检验（back testing）。在 Devcon5 举办以前，我认为它在概念上已经很可靠了。

在 Devcon5 上，我提议在一年内不再接受 EIP，好把所有的实现都转成类似的数据模式。但因为大家有所怀疑，而且 “核心开发者” 团体也没有这个积极性，我的提议没有被采纳。

怀疑意见主要围绕着高效计算和更新状态根哈希的方法。在 2020 年 3 月 的 EthCC 2020 大会上，我们提出了解决方案：额外的数据结构，叫做 “中间哈希值（Intermediate Hashes）”。接下来几个月里我们就完全实现了这个方案。

阶段式同步（staged sync）的想法来自于对按表写入变更量（per-table write churn）的测量值的观察。对数据变更（churn）的解决的方案是在一个预先排序号的序列中插入数据。我们在 2019 年末仔细观察了这些现象，但我们的第一个实验性的实现在 2020 年 2 月才表现出有重大的性能优势。

阶段式同步在架构层面上是一个非常重大的改变（但没有大改数据模式），我们在 2020 年 3 月至 7 月实现了这一功能。正是有了它，我们才能大幅（10 倍）压缩同步时间。

在 2020 年 8 月，我们又发现了将状态表示数据从 50 GB 缩减到 10 GB 的方法。

在 2020 年 9 月，“中间哈希值” 功能的粒度做得更细，将计算状态根哈希的速度提升了 4 倍（从 200 ms 缩减到 50 ms），同时将其数据规模从 7 GB 减小到了 2.5 GB.

当前我们正在开发合适的日志索引（indexing of logs）

那么，这一切到底意味着什么呢？

其实，这都不意味着什么，因为当前的实现还没有到达效率的极限。

还有几个 “未解之谜”：

1. 对久远历史中的状态的默克尔证明还无法高效生成（对近期历史的默克尔证明的生成效率是没问题的。可以通过引入中间哈希值的快照来缓解（这些数据相对来说也不大）
2. 一些共识计算无法与阶段性同步协调工作，理想情况下，应该共同设计两者

Silkworm

1. 我们从 BoltDB 切换成了 LMDB（用 C 语言实现的数据库），这就能保证 Turbo-Geth 和 Silkworm 之间的数据库兼容性。
2. 阶段式同步模式 自然而然地 将实现分解成了相对独立的组件，这些组件基本上都通过数据库中的记录来交互（或者说通过内存中的 page 来交互，如果交互都发生在一个数据库的事务内的话）。这就意味着，我们可以逐个逐个组件创建 C++ 实现。
3. 更早的 EVM 实验（使用 EVMC 接口）暴露出了使用跨语言接口的巨大开销，而 EVMC 的双重接口又加剧了这一点。
4. 我们觉得已经有了足够的经验，能在一个可预期的时间内（1 年内，而不是 5 到 10 年）、靠着一些专家的帮助，就能完成这一切了。

未来

1. 区块的 Gas 上限更高会更容易招致 DOS 攻击。Turbe-geth 的安全极限可能是其它实现的 10 倍高；而 Silkworm 可能会更高。
2. 更高的 Gas 上限会产生（数据量）更大的区块。这就会反过来产生两个问题：
   a）区块传输问题。这可以通过预先共识来处理（本质上就是牺牲交易时延来换取交易吞吐量）
   b）区块下载和存储问题。可以通过使用专门化的存储网络比如 BitTorrent 来解决（这些工作已经在进行中）。

（完）

（文内有许多超链接，可点击左下 ”阅读原文“ 从 EthFans 网站上获取）

原文链接:

https://github.com/AlexeyAkhunov/papers/blob/master/Turbo-Geth-Silkworm.pdf

作者: Alexey Akhunov

作者：以太坊爱好者；来自链得得内容开放平台“得得号”，本文仅代表作者观点，不代表链得得官方立场凡“得得号”文章，原创性和内容的真实性由投稿人保证，如果稿件因抄袭、作假等行为导致的法律后果，由投稿人本人负责得得号平台发布文章，如有侵权、违规及其他不当言论内容，请广大读者监督，一经证实，平台会立即下线。如遇文章内容问题，请发送至邮箱：linggeqi@chaindd.com