不用分片也能扩展 10 倍性能？简单了解以太坊 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）

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

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

还有几个 「未解之谜」：

创建一个符合 Apache 2.0 协议、用 C++ 实现的模块化以太坊实现的想法，始于 2019 年初，因为那时我们看到 「Aleth」 项目基本上已经被放弃了。

但那并不是一个好时机。

到了 2020 年 5 月～6 月，时机终于到来。出现了 4 大转机：

启动 Silkworm 项目也打开了我们的思路，比如我们可以把实现逐个逐个地迁移到其它编程语言（比如 Rust） 上。

我相信，以太坊 1.0 即使不引入分片，也能扩展至少 10 倍的吞吐量。我们主要面临三个方面的挑战：

本文链接：https://www.8btc.com/article/649566转载请注明文章出处

—-

编译者/作者：以太坊爱好者

玩币族申明：玩币族作为开放的资讯翻译/分享平台，所提供的所有资讯仅代表作者个人观点，与玩币族平台立场无关，且不构成任何投资理财建议。文章版权归原作者所有。