引介

Turbo-Geth 客户端:Beta 版的目标

曾汨   |     |   2026 次阅读

(原题为:从 Alpha 版转向 Beta 版的条件)

我们没有定死从 Alpha 阶段转向 Beata 阶段的时间点。我们是反过来,确定了一些转向 Beta 版的先决条件;实现了这些条件,就意味着 turbo-geth 已经准备好了。下面就是我们要实现的清单:

挖矿功能

让 turbo-geth 支持高效挖矿的难点在于:在任意时间点,都只有一个状态是 “公认最新” 的状态。而挖矿,需要节点产生 “投机” 区块以及 “投机” 状态,以计算出新区块的区块头中需要的状态根哈希值。目前的想法是,“投机” 状态是一块放在内存里的缓存,而且是可以 “复制” 的。“复制” 的意思是,创建该缓存的 lazy-shallow 副本,因此对该副本的改动不会影响节点所保存的公认最新状态。

不过,事实也证明了,当前由哈希化状态(HashedState)和中间哈希值(IntermediateHashes)组成的数据模式不适合于维护这样的缓存。所以我们正在开展纠正数据模式的工作,希望实现可以复制的状态缓存,然后实现挖矿功能。

简化区块头和区块体下载

当前的阶段式同步中,区块头和区块体下载分别安排在阶段 1 和阶段 3。这两个阶段不管看起来还是用起来,都跟其它阶段非常不同,因为它们是在继承自 go-ethereum 客户端的 区块头/区块体/收据/状态 下载实现的基础上开发出来的。这些代码的功能比 turbo-geth 的阶段式同步所需的要更多,可以(也应该)替换成简化后的版本。这个简化的版本已经有一个可用的概念验证了,现在可以测试和撰写文档了。

共识引擎组件

有一个概念叫做 “共识机制即插即用(pluggable consensus)” ,意思是客户端应该很容易能从工作量证明迁移到权威证明(PoS),也包括能从工作量证明的一个变种切换到另一个变种,从 PoA 的一个变种切换到另一个。实际上,曾经有人用接口来实现共识机制即插即用,但因为还是运行在同一个进程中,通常还是与其它代码紧密交织在一起。我们已经在设计一个让共识引擎能运行在独立进程中的接口。

有了这样的接口,虽然还是能够在同一个进程中运行,但这个接口能够更直接让共识引擎与交易执行适当分离。我们已经为 EtHash PoW 和 Clique POA 实现了一个概念验证,现在正准备集成、测试和撰写文档。

从 LMDB 迁移到 MDBX

turbo-geth 客户端是从 BoltDB 数据库后端起步的,现在正在添加对 BadgerDB 的支持,最后,我们会完全迁移到 LMDB。某些时候我们对 LMDB 的使用方式会产生一些稳定性问题,这是连 LMDB 的创造者都没有想到的。因此,我们一直在考察 LMDB 的一个支撑性更优的变种,叫做 MDBX,希望能利用上其稳定性提升,使所有功能在未来结合得更加紧密。对 MDBX 的集成已经能够完成了,现在需要测试和撰写文档。

(完)


原文链接: https://github.com/ledgerwatch/turbo-geth/wiki/Criteria-for-transitioning-from-Alpha-to-Beta
作者: ledgerwatch
翻译: 阿剑


你可能还会喜欢:

Turbo-Geth 客户端和 Silkworm:过去与未来

Turbo-Geth 客户端:数据库改进

Turbo-Geth 客户端:如何实现性能改进

 
0 人喜欢