http://www.7klian.com

Turbo-Geth 客户端:已往与将来

2. 一些共鸣计较无法与阶段性同步协调事情,抱负环境下,应该配合设计两者
3. 更早的 EVM 尝试(利用 EVMC 接口)袒暴露了利用跨语言接口的庞大开销,而 EVMC 的双重接口又加剧了这一点。
阶段式同步(staged sync)的想法来自于对按表写入改观量(per-table write churn)的丈量值的调查。对数据改观(churn)的办理的方案是在一个预先排序号的序列中插入数据。我们在 2019 年尾仔细调查了这些现象,但我们的第一个尝试性的实此刻 2020 年 2 月才表示出有重大的机能优势。

在 Devcon5 上,我提议在一年内不再接管 EIP,好把所有的实现都转成雷同的数据模式。但因为各人有所猜疑,并且 “焦点开拓者” 集体也没有这个努力性,我的提议没有被采用。
Silkworm
当前我们正在开拓符合的日志索引(indexing of logs)
4. 我们以为已经有了足够的履历,能在一个可预期的时间内(1 年内,而不是 5 到 10 年)、靠着一些专家的辅佐,就能完成这一切了。
1. 我们从 BoltDB 切换成了 LMDB(用 C 语言实现的数据库),这就能担保 Turbo-Geth 和 Silkworm 之间的数据库兼容性。

在 2020 年 8 月,我们又发明白将状态暗示数据从 50 GB 缩减到 10 GB 的要领。

但那并不是一个好机缘。

阶段式同步在架构层面上是一个很是重大的改变(但没有大改数据模式),我们在 2020 年 3 月至 7 月实现了这一成果。正是有了它,我们才气大幅(10 倍)压缩同步时间。

到了 2020 年 5 月~6 月,机缘终于到来。呈现了 4 大转机:
1. 区块的 Gas 上限更高会更容易招致 DOS 进攻。Turbe-geth 的安详极限大概是其它实现的 10 倍高;而 Silkworm 大概会更高。
Turbo-Geth 作为一个纯粹出于好奇心的项目,始于 2017 年(没错,就是在 CryptoKitties 导致的猖獗拥堵时期)。一开始是为了探究基于 trie 的数据库模式的替代方案。在 2018 年 3 月,Turbo-Geth 项目从基金会处得到了一笔小额的奖金(2.5 万美元)。在 2019 年第一第二季度,Turbo-Geth 被用作状态租金(State Rent)研究的状态阐明平台。到了 2019 年第三第四季度,Turbo-Geth 也被用于执行无状态以太坊的回溯检讨(back testing)。在 Devcon5 举行以前,我认为它在观念上已经很靠得住了。
尚有几个 “未解之谜”:

Turbo-Geth
启动 Silkworm 项目也打开了我们的思路,好比我们可以把实现逐个逐个地迁移到其它编程语言(好比 Rust) 上。
那么,这一切到底意味着什么呢?
2. 阶段式同步模式 自然而然地 将实现解析成了相对独立的组件,这些组件根基上都通过数据库中的记录来交互(可能说通过内存中的 page 来交互,假如交互都产生在一个数据库的事务内的话)。这就意味着,我们可以逐个逐个组件建设 C++ 实现。
2. 更高的 Gas 上限会发生(数据量)更大的区块。这就会反过来发生两个问题:
b)区块下载和存储问题。可以通过利用专门化的存储网络好比 BitTorrent 来办理(这些事情已经在举办中)。

猜疑意见主要环绕着高效计较和更新状态根哈希的要领。在 2020 年 3 月 的 EthCC 2020 大会上,我们提出了办理方案:特另外数据布局,叫做 “中间哈希值(Intermediate Hashes)”。接下来几个月里我们就完全实现了这个方案。
1. 对长远汗青中的状态的默克尔证明还无法高效生成(对近期汗青的默克尔证明的生成效率是没问题的。可以通过引入中间哈希值的快照来缓解(这些数据相对来说也不大)
建设一个切合 Apache 2.0 协议、用 C++ 实现的模块化以太坊实现的想法,始于 2019 年头,因为当时我们看到 “Aleth” 项目根基上已经被放弃了。
a)区块传输问题。这可以通过预先共鸣来处理惩罚(本质上就是牺牲生意业务时延来调换生意业务吞吐量)
在 2020 年 9 月,“中间哈希值” 成果的粒度做得更细,将计较状态根哈希的速度晋升了 4 倍(从 200 ms 缩减到 50 ms),同时将其数据局限从 7 GB 减小到了 2.5 GB.
其实,这都不料味着什么,因为当前的实现还没有达到效率的极限。
将来
我相信,以太坊 1.0 纵然不引入分片,也能扩展至少 10 倍的吞吐量。我们主要面对三个方面的挑战:

郑重声明:本文版权归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。