区块的 Gas 上限更高会更容易招致 DOS 进攻。Turbe-geth 的安详极限大概是其它实现的 10 倍高；而 Silkworm 大概会更高。更高的 Gas 上限会发生（数据量）更大的区块。这就会反过来发生两个问题：区块传输问题。这可以通过预先共鸣来处理惩罚（本质上就是牺牲生意业务时延来调换生意业务吞吐量）区块下载和存储问题。可以通过利用专门化的存储网络好比 BitTorrent 来办理（这些事情已经在举办中）。
在 Devcon5 上，我提议在一年内不再接管 EIP，好把所有的实现都转成雷同的数据模式。但因为各人有所猜疑，并且 「焦点开拓者」 集体也没有这个努力性，我的提议没有被采用。
在 2020 年 8 月，我们又发明白将状态暗示数据从 50 GB 缩减到 10 GB 的要领。
猜疑意见主要环绕着高效计较和更新状态根哈希的要领。在 2020 年 3 月 的 EthCC 2020 大会上，我们提出了办理方案：特另外数据布局，叫做 「中间哈希值（Intermediate Hashes）」。接下来几个月里我们就完全实现了这个方案。
我相信，以太坊 1.0 纵然不引入分片，也能扩展至少 10 倍的吞吐量。我们主要面对三个方面的挑战：
Turbo-Geth 作为一个纯粹出于好奇心的项目，始于 2017 年（没错，就是在 CryptoKitties 导致的猖獗拥堵时期）。一开始是为了探究基于 trie 的数据库模式的替代方案。在 2018 年 3 月，Turbo-Geth 项目从基金会处得到了一笔小额的奖金（2.5 万美元）。在 2019 年第一第二季度，Turbo-Geth 被用作状态租金（State Rent）研究的状态阐明平台。到了 2019 年第三第四季度，Turbo-Geth 也被用于执行无状态以太坊的回溯检讨（back testing）。在 Devcon5 举行以前，我认为它在观念上已经很靠得住了。
当前我们正在开拓符合的日志索引（indexing of logs）
阶段式同步在架构层面上是一个很是重大的改变（但没有大改数据模式），我们在 2020 年 3 月至 7 月实现了这一成果。正是有了它，我们才气大幅（10 倍）压缩同步时间。
其实，这都不料味着什么，因为当前的实现还没有达到效率的极限。
尚有几个 「未解之谜」：
对长远汗青中的状态的默克尔证明还无法高效生成（对近期汗青的默克尔证明的生成效率是没问题的。可以通过引入中间哈希值的快照来缓解（这些数据相对来说也不大）一些共鸣计较无法与阶段性同步协调事情，抱负环境下，应该配合设计两者Silkworm
阶段式同步（staged sync）的想法来自于对按表写入改观量（per-table write churn）的丈量值的调查。对数据改观（churn）的办理的方案是在一个预先排序号的序列中插入数据。我们在 2019 年尾仔细调查了这些现象，但我们的第一个尝试性的实此刻 2020 年 2 月才表示出有重大的机能优势。
到了 2020 年 5 月～6 月，机缘终于到来。呈现了 4 大转机：
启动 Silkworm 项目也打开了我们的思路，好比我们可以把实现逐个逐个地迁移到其它编程语言（好比 Rust） 上。
在 2020 年 9 月，「中间哈希值」 成果的粒度做得更细，将计较状态根哈希的速度晋升了 4 倍（从 200 ms 缩减到 50 ms），同时将其数据局限从 7 GB 减小到了 2.5 GB.
我们从 BoltDB 切换成了 LMDB （用 C 语言实现的数据库），这就能担保 Turbo-Geth 和 Silkworm 之间的数据库兼容性。阶段式同步模式_自然而然地_将实现解析成了相对独立的组件，这些组件根基上都通过数据库中的记录来交互（可能说通过内存中的 page 来交互，假如交互都产生在一个数据库的事务内的话）。这就意味着，我们可以逐个逐个组件建设 C++ 实现。更早的 EVM 尝试（利用 EVMC 接口）袒暴露了利用跨语言接口的庞大开销，而 EVMC 的双重接口又加剧了这一点。我们以为已经有了足够的履历，，能在一个可预期的时间内（1 年内，而不是 5 到 10 年）、靠着一些专家的辅佐，就能完成这一切了。将来
那么，这一切到底意味着什么呢？
建设一个切合 Apache 2.0 协议、用 C++ 实现的模块化以太坊实现的想法，始于 2019 年头，因为当时我们看到 「Aleth」 项目根基上已经被放弃了。
但那并不是一个好机缘。
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
