不必分片也能扩展 10 倍功能?简略了解以太坊 Turbo-Geth 客户端

不必分片也能扩展 10 倍功能?简略了解以太坊 Turbo-Geth 客户端

把以太坊逐一迁移到其它编程言语上,即便不引进分片,也能扩展至少 10 倍的吞吐量。…以太坊,分片,Silkworm,Turbo-Geth 以太坊 分片 Silkworm Turbo-Geth以太坊爱好者 图标 Logo以太坊爱好者区块链作者,团队,专栏,大众号,头条·

把以太坊逐一迁移到其它编程言语上,即便不引进分片,也有或许扩展至少 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)

那么,这一切究竟意味着什么呢?

其实,这都不意味着什么,由于当时的完结还没有抵达功率的极限。

还有几个 「未解之谜」:

    对长远前史中的状况的默克尔证明还无法高效生成(对近期前史的默克尔证明的生成功率是没问题的。能够经过引进中心哈希值的快照来缓解(这些数据相对来说也不大)一些一致核算无法与阶段性同步和谐作业,抱负情况下,应该一起规划两者

Silkworm

创立一个契合 Apache 2.0 协议、用 C++ 完结的模块化以太坊完结的主意,始于 2019 年头,由于那时咱们看到 「Aleth」 项目基本上现已被抛弃了。

但那并不是一个好机遇。

到了 2020 年 5 月~6 月,机遇总算到来。呈现了 4 大起色:

    咱们从 BoltDB 切换成了 LMDB (用 C 言语完结的数据库),这就能确保 Turbo-Geth 和 Silkworm 之间的数据库兼容性。阶段式同步形式_自然而然地_将完结分化成了相对独立的组件,这些组件基本上都经过数据库中的记载来交互(或者说经过内存中的 page 来交互,假如交互都发生在一个数据库的业务内的话)。这就意味着,咱们能够逐一逐一组件创立 C++ 完结。更早的 EVM 试验(运用 EVMC 接口)露出出了运用跨言语接口的巨大开支,而 EVMC 的两层接口又加重了这一点。咱们觉得现已有了满足的经历,能在一个可预期的时刻内(1 年内,而不是 5 到 10 年)、靠着一些专家的协助,就能完结这一切了。

未来

发动 Silkworm 项目也打开了咱们的思路,比方咱们能够把完结逐一逐一地迁移到其它编程言语(比方 Rust) 上。

我信任,以太坊 1.0 即便不引进分片,也能扩展至少 10 倍的吞吐量。咱们首要面对三个方面的应战:

    区块的 Gas 上限更高会更简单引起 DOS 进犯。Turbe-geth 的安全极限或许是其它完结的 10 倍高;而 Silkworm 或许会更高。更高的 Gas 上限会发生(数据量)更大的区块。这就会反过来发生两个问题:区块传输问题。这能够经过预先一致来处理(本质上便是献身买卖时延来交换买卖吞吐量)区块下载和存储问题。能够经过运用专门化的存储网络比方 BitTorrent 来处理(这些作业现已在进行中)。

来历链接:github.com

免责声明:作为区块链信息渠道,本站所发布文章仅代表作者个人观点,与链闻 ChainNews 态度无关。文章内的信息、定见等均仅供参考,并非作为或被视为实践出资主张。

[标签:作者]