不用分片也能扩展 10 倍性能?简单了解以太坊 Turbo(2)
时间:2020-09-22 13:46来源:未知 作者:admin 点击:
次
一些共识计算无法与阶段性同步协调工作,理想情况下,应该共同设计两者 Silkworm 创建一个符合 Apache 2.0 协议、用 C++ 实现的模块化以太坊实现的想法,始
一些共识计算无法与阶段性同步协调工作,理想情况下,应该共同设计两者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 来解决(这些工作已经在进行中)。
(责任编辑:admin) |
织梦二维码生成器
------分隔线----------------------------