学院 相关新闻 文章

合并以太坊 2.0 客户端与 1.0 引擎

2020.05.09

eth1+eth2 的合并目的,是在升级的以太坊 2.0 共识环境中利用现有以太坊 1.0 的状态、生态系统以及软件。

概括地说,我们今天所认为的 eth2 客户端会处理核心 PoS 以及分片共识。本质上,eth2 协议及 eth2 客户端被设计成非常擅于在一堆「东西」上产生及达成共识,而这些东西,就是很多充满数据和(最终)状态的分片链。与当今 eth1 的 PoW 共识层相比,eth2 的「共识层」要先进的多,同时也复杂的多。

今天,eth1 客户端具有相对简单且较薄的共识层,它只有一条链,并且 PoW 可处理协议外硬件中的大部分复杂性。eth1 客户端的大多数复杂性及优化,都位于用户层(包括状态存储 / 管理、状态同步、虚拟机执行、交易处理、交易池等)。

当 eth1 作为一个分片被纳入 eth2 时,这种关注点分离就可实现很好的配对,eth2 客户端可以处理 PoS 和分片共识的复杂性,而附属 eth1 客户端可以成为 eth1 引擎,它可以处理状态、交易、虚拟机以及更接近用户层事物的复杂性。

如何将 eth1 和 eth2 客户端软件组合在一起,有很多可能的途径(比如完全合并、将 eth1 作为库导入、通过两者之间的通信协议等),但在本文当中,我们会重点介绍一个最具微创性和和模块化的方法 —— 一种 eth2 客户端与简化 eth1 引擎之间的本地通信协议。

考虑到 eth1 和 eth2 客户端实现的多样性,这种方法可以防止客户端软件在任一侧锁定,允许客户端团队保持独立,并专注于他们自己的研发工作,使软件项目在很大程度上保持稳定,以便进行快速原型制作。

那它会是什么样子的呢?

大致上,一个 eth1+eth2 组合客户端会是下面这个样子的:

其中 eth2 引擎和 eth1 引擎一起运行,通过 eth2 客户端驱动的 RPC 进行本地通信。

两者都会维护自己的 p2p 接口,连接到对等方并处理与每个特定域相关的网络协议。

从核心共识的角度来看,eth2 客户端负责并推动信标链、数据分片链以及 eth1 分片链的构建。eth2 客户端通过 RPC 直接提供有关 eth1 引擎关于 eth1 分片链和核心共识(信标链 / 状态)的任何知识。

具体来说,附加的 eth1 引擎必须能够访问 eth2 客户端,因为它不能维护自己的共识。在今天以太坊的 PoW 中,eth1 客户端检查工作量证明,形成一个树状结构,并运行分叉选择规则来查找链的顶端。在 eth2 中,这些机制要大不相同,这需要对 eth2 的核心共识有深入的了解。eth2 客户端提供有关 eth1 分片链头部(head)的最新信息,以便 eth1 引擎可以维护 eth1 状态的准确视图。

由于 eth1 引擎完全依赖 eth2 客户端推动共识,因此我们提议 eth2 客户端与 eth1 引擎之间的通信,都是 eth2 客户端调用的 eth1 引擎上的所有方法(例如 addBlock, getBlockProposal 等)。这将强制执行一个 leader/follower 关系,以降低系统推理的复杂性,并限制 eth1 引擎所需的业务逻辑。

从 eth2 客户端和核心共识的角度来看,eth1 分片链的处理,几乎与所有其他分片链(分叉选择、交联、区块结构、签名等)完全相同。主要区别在于,可以针对 eth1 引擎执行分片区块内容,因此 eth1 分片区块数据的格式必须与 eth1 相关,并且必须针对此成功执行进行额外的验证。

eth2 有一种与核心共识相关的状态,这就是所谓的「信标状态」(beacon-state)。信标状态数据很小(大约只有 10-40MB,取决于验证者集的大小),它包含了理解核心共识及如何处理分片链所需的所有信息。事实上,要处理分片链中与共识相关的部分,客户端必须能够访问信标状态(例如,运行分片链分叉选择的最新交联 crosslink、验证分片链签名的当前验证集或 shuffling 随机分配)。

eth2 的状态不会一直和用户层状态交互,其交互最多的是分片链数据的可用性。实际的用户层数据根位于该分片链数据中,对于 eth1 分片链,则为当前以太坊用户状态根。

作者 : 巴比特资讯

相关推荐