21

引介 | Turbo-Geth 客户端和 Silkworm:过去与未来

 3 years ago
source link: https://ethfans.org/posts/Turbo-Geth-Silkworm-past-and-future
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

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 倍)压缩同步时间。

MZBvmmn.jpg!mobile

a2m6fa6.jpg!mobile

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

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

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

那么,这一切到底意味着什么呢?

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

还有几个 “未解之谜”:

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

Silkworm

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

但那并不是一个好时机。

到了 2020 年 5 月~6 月,时机终于到来。出现了 4 大转机:

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

未来

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

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

  1. 区块的 Gas 上限更高会更容易招致 DOS 攻击。Turbe-geth 的安全极限可能是其它实现的 10 倍高;而 Silkworm 可能会更高。

  2. 更高的 Gas 上限会产生(数据量)更大的区块。这就会反过来产生两个问题:

a)区块传输问题。这可以通过预先共识来处理(本质上就是牺牲交易时延来换取交易吞吐量)

b)区块下载和存储问题。可以通过使用专门化的存储网络比如 BitTorrent 来解决(这些工作已经在进行中)。

(完)

原文链接: https://github.com/AlexeyAkhunov/papers/blob/master/Turbo-Geth-Silkworm.pdf

作者:Alexey Akhunov

翻译:阿剑


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK