当前位置:首页 > 区块链新闻 > 正文

不用分片也能扩展 10 倍性能?简单了解以太坊 Turbo-Geth 客户端

来源: 互联网时间:2020-09-22 10:30:03

以太坊逐个迁移到其它编程语言上,即使不引入分片,也有可能扩展至少 10 倍的吞吐量。

原文标题:《引介 | Turbo-Geth 客户端:过去与未来》
撰文:Alexey Akhunov
翻译:阿剑

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

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

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

在 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 上限会产生(数据量)更大的区块。这就会反过来产生两个问题:
    • 区块传输问题。这可以通过预先共识来处理(本质上就是牺牲交易时延来换取交易吞吐量)
    • 区块下载和存储问题。可以通过使用专门化的存储网络比如 BitTorrent 来解决(这些工作已经在进行中)。

来源链接:github.com

免责声明:

1.本文内容综合整理自互联网,观点仅代表作者本人,不代表本站立场。

2.资讯内容不构成投资建议,投资者应独立决策并自行承担风险。