你能在不切片的情况下扩展到10倍的性能吗？以太坊turbo geth客户端的简单理解

如果以太坊一个接一个地迁移到其他编程语言，即使不引入碎片，也可以将吞吐量至少扩展10倍。

标题：turbo gETH客户端简介：过去和未来

turbogETH作为一个纯粹出于好奇的项目，于2017年开始（是的，在加密小猫引起的疯狂拥挤期间）。本文旨在探索一种替代基于trie的数据库模式的方法。2018年3月，TurthGeTH项目从ETHunm基金会获得了一小笔奖金（25000美元）。2019年一、二季度，turbo gETH作为国家地租研究的分析平台。到2019年第三季度和第四季度，turbo gETH还用于执行无状态以太坊的反向测试。在devcon5之前，我认为它在概念上是合理的。

在devcon5上，我建议一年内不接受EIP，以便所有实现都可以转换为类似的数据模式。不过，由于“核心开发者”集团的一些疑虑和热情，我的提案没有通过。

质疑意见主要中心化在状态根哈希的有效计算和更新上。在2020年3月的ETHc2020会议上，我们提出了一个解决方案：一个称为“中间哈希”的额外数据结构。在接下来的几个月里，我们已经全面实施了这个计划。

分段同步的思想来自于观察每个表的写周期的测量值。数据更改（Chun）的解决方案是将数据插入预先排序的数字序列中。我们在2019年末仔细观察了这些现象，但我们的第一次实验性实施仅在2020年2月才显示出显著的性能优势。

分阶段同步在架构（architecture）级别是一个非常重要的变化（但数据模没有大的变化），我们从2020年3月到7月实施了这一点。有了它，我们可以大大（10倍）压缩同步时间。

在2020年8月，我们找到了另一种方法将状态表示数据从50gb减少到10gb。

2020年9月，对“中间哈希值”函数的粒度进行了细化，将计算状态根哈希的速度提高了4倍（从200毫秒提高到50毫秒），同时将其数据大小从7GB减小到2.5GB

目前，我们正在开发适当的日志索引

那么这一切意味着什么？

事实上，这并不意味着什么，因为目前的实现还没有达到效率极限。

还有几个未解之谜：

1. 默克尔长期以来的国家证明不能有效地生成（默克尔最近历史证明的效率是没有问题的）。通过引入中间散列值的快照（这些数据相对较小），可以缓解这一点
2. 一些一致性计算不能与相位同步工作。理想情况下，它们应该一起设计

蚕

创建一个基于Apache2.0协议并用C++实现的模块化以太坊的想法始于2019年初，当时我们看到“alETH”项目已经基本放弃。

但那不是个好时机。

到2020年5月至6月，时间终于到了。有四大变化：

1. 我们从boltdb转换为LMDB（数据库采用C语言实现），保证了turbogETH与蚕之间的数据库兼容性。
2. 阶段同步模式uu自然地uo实现被分解为相对独立的组件，这些组件基本上通过数据库中的记录（或者通过内存中的页面，如果交互发生在数据库事务中）。这意味着我们可以按组件创建C++实现组件。
3. 早期的EVM实验（使用evmc接口）暴露了使用跨语言接口的巨大开销，这一点由于evmc的双接口而加剧。
4. 我们认为，在一些专家的帮助下，我们有足够的经验在可预测的时间段（一年而不是五至十年）内完成这一目标。

未来

启动silkworm项目也为我们一个接一个地将实现迁移到其他编程语言（如rust）开辟了道路。

我相信以太坊1.0可以在不引入碎片的情况下将吞吐量至少扩大10倍。我们面临三大挑战

1. 一个区块的气体上限越高，越容易引起DoS攻击。turboget的安全限制可能比其他实现高10倍；蚕可能更高。
2. 较高的气盖会导致较大的区块。这反过来又导致两个问题：块转移。这可以通过预先协商解决块下载和存储问题（本质上，为事务吞吐量牺牲事务延迟）。这可以通过使用专门的存储网络（如BitTorrent）来完成，这些网络已经在进行中。