干货丨详解以太坊2.0如何与1.0合并

注：原文作者是以太坊2.0协调员Danny Ryan（djrtwo），在这篇文章中，他详细介绍了以太坊1.0将如何与以太坊2.0合并，根据他的介绍，在ETH1+ETH2组合客户端中，ETH2客户端可以处理PoS和分片共识的复杂性，而附属ETH1客户端可以成为一个ETH1引擎，它可以处理状态、交易、虚拟机等事物的复杂性。

(图片来自：tuchong.com)

以太坊1.0和以太坊2.0客户端的关系

自从Vitalik在2019年12月提出一个早期ETH1 lt;-gt; ETH2 之后，研究人员一直在进行积极讨论，以从软件的角度来考虑这种合并的可能形式，而对于原设计的期望，也是愈发变得更强。我们的愿景是创建一个混合体，其中核心共识工作是由以太坊2.0客户端（以下简称ETH2客户端）管理，而状态/区块则由一个以太坊1.0引擎（以下简称ETH1引擎）管理，而它们一起构成了ETH1+ETH2组合客户端。

本文旨在更明确地区分ETH2客户端和附属ETH1引擎之间的职责，以便为会话、规范编写及原提供更好的基础。注意，文章并不会定义协议的具体细节（例如ETH1 客户端调用ETH2引擎的精确方法），并且文中包含的任何示例，都只是用于帮助描述及后续讨论。

而要理解本文的内容，前提条件是需要你基本熟悉以太坊2.0以及无状态以太坊的概念。

分工明确

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接口，连接到对等方并处理与每个特定域相关的网络协议。

以太坊2.0客户端

1. 信标链和信标状态 （构建系统其余部分的核心共识对象）；
2. 分片链（1、ETH1分片链，2、很多仅限数据的分片链）；
3. Mempool操作[未显示]（证明（Attestation）、存款（deposit）、退出出口（ exit）等）
4. P2P接口（1、共识层信息，2、包括ETH1分片区块gossip）；
5. RPC到ETH1引擎 （所有调用都由ETH2客户端驱动）；

以太坊1.0引擎

1. EVM虚拟机（ETH1分片区块的执行与验证）；
2. ETH1状态（今天以太坊中的用户层ETH1状态）；
3. 交易存储池Mempool（用户交易mempool，为区块生产做准备）；
4. P2P接口（1、今天以太坊上的交易gossip，2、状态同步，3、没有ETH1分片区块gossip）；
5. 来自ETH2客户端的RPC （所有调用都由ETH2客户端驱动）；

共识

从核心共识的角度来看，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分片链，则为当前以太坊用户状态根。

下面讨论了和ETH2客户端相关的ETH1状态的不同情况：

1、没有ETH1引擎的ETH2客户端

核心ETH2协议可以在没有附加ETH1引擎的情况下运行。单独的ETH2客户端可以遵循信标链和分片链（包括ETH1分片）。而没有ETH1引擎，客户端将无法执行无状态ETH1分片区块，因此无法完全验证它们或从中获取任何有用的用户信息。不过，根据对ETH2核心共识和验证者的假设，ETH1分片链的头部（head）仍然可以安全地找到。

2、带无状态ETH1引擎的ETH2客户端

要运行一个验证者节点，必须使用附加的ETH1引擎运行ETH2客户端。这可以通过无状态的方式完成（即不在本地存储整个ETH1状态），因此ETH1分片区块具有可用于执行的验证数据（witness）。信标委员会可以通过对ETH1引擎进行无状态调用，来检查分片区块数据的可用性及关于ETH1的数据有效性。

除了验证者外，很多用户/应用程序节点也可能使用无状态或半状态的ETH1引擎运行。使用瘦ETH2客户端，来跟随ETH1分片链的头部，并以无状态或半无状态的方式与其交互。

3、带有状态ETH1引擎的ETH2客户端

要运行可产生ETH1 分片区块的验证者，必须使用附加的ETH1引擎和完整的ETH1状态运行ETH2协议（研发者们正在探索无状态的区块产生方法，但为简单起见，我们不对其进行讨论）。然后，可以使用本地状态和交易存储池（TX mempool）按需形成新的有效区块（在下文中有更多讨论）。

除验证者外，很多用户/应用程序节点也可能使用完全有状态的ETH1引擎运行，例如区块浏览器、存档节点、状态提供者等。

网络

为简单起见，ETH2和ETH1最初会维护它们各自独立的网络堆栈和协议。为了响应责任转移（例如ETH1分片区块gossip），开发者已不赞成使用某些现有的ETH1协议（例如ETH1分片区块gossip），取而代之的是ETH2协议。在初始原设计阶段之后，或者在更进一步的阶段，可能需要将ETH1协议迁移到libp2p以统一网络堆栈，但这不是必须的。

ETH2客户端和ETH1引擎可以访问相同的disc5 DHT，但是可独立地找到具有适当功能的对等节点并独立地维护连接。

ENR

ETH1+ETH2组合客户端会使用一个ENR，因为节点位于具有多个功能的逻辑网络标识之后。

ETH1功能（状态、交易等）由ENR中的现有ETH（或新ETH1）key表示。

ETH2功能（核心共识）在ENR中用ETH2 key表示。

每种协议的存在，都意味着节点能够且愿意识别底层网络协议的类别。

Wire协议

1、ETH2协议

1、ETH2请求/响应（1、状态，2、信标区块同步，3、分片区块同步）； 2、核心共识gossip（1、Beacon区块，2、证明，3、分片区块，包括ETH1分片， 4、其它验证者操作）；

2、ETH1协议

1、ETH1 wire协议的子集 （1、交易gossip，2、同步方法，例如getnodedata或新方法， 3、获取收据receipt）

2、NOT（与区块哈希、区块头或体相关的消息）；

3、为什么ETH2客户端会处理ETH1区块gossip ?

ETH2专门用于处理分片区块的生产、gossip以及验证。我们的目标是让ETH1分片成为标准分片，并尽可能与其余分片保持一致。关于核心共识，与其他分片相比，ETH1区块的主要区别在于针对ETH1引擎执行/验证区块内容的能力，

当验证者正在将ETH1分片区块叉联到信标链时，ETH2客户端将再次调用ETH1引擎来执行和验证该区块。

当有状态的ETH1 + ETH2组合节点收到新的ETH1分片区块时，ETH2客户端将再次调用ETH1引擎，以验证该区块并更新本地状态存储。

交易gossip和存储池mempool

ETH1引擎几乎会以当前以太坊相同的方式，维护用户交易gossip以及ETH1交易储存池。同样的网络协议和本地机制，可以用于gossip及存储池的维护，为区块的生产做好准备。

主要的区别在于如何确定已用交易的知识，以及如何将存储池用于区块生产，但这些可以说是位于存储池外部的一个层中。

ETH1分片区块是从附属ETH2客户端提供给ETH1引擎的。包含在这些区块中的交易，应该以类似于当前以太坊主网PoW区块的方式从存储池中清除。

ETH1分片区块是根据附属ETH2客户端，通过存储池mempool的内容生成的。此RPC方法和基础功能类似于getWork，但将返回完整的区块内容，而不仅仅是一个哈希值。

区块生产

在ETH2协议中，所有区块（信标区块、分片区块、ETH1分片区块）必须由PoS验证者根据核心共识进行生产及签名。为此，ETH2客户端最终要负责所有区块的生产。

对于信标区块和非ETH1分片区块，ETH2客户端具有生成有效区块所需的一切。

对于ETH1分片区块，ETH2客户端立即/随时访问ETH1状态、交易和其它底层ETH1结构，以生成有效区块。相反，当指定验证者生成ETH1区块时，ETH2客户端从ETH1引擎请求一个可行的ETH1区块数据（TX、状态根等）。然后，ETH2客户端将此ETH1区块数据打包到完整的分片区块中（添加sLoot、positer_index、positer_signature等），并将该区块广播至网络。

ETH1引擎之所以能够生成有效/可行的ETH1区块数据，是因为它采用了今天以太坊主网所使用的相同方式来管理ETH1交易存储池，并且它通过ETH2客户端的更新来维护ETH1头状态的新信息。

下一步该怎么走？

如果这一总体设计被大家认同，那接下来的步骤包括：

1. 确保有关ETH2客户端驱动ETH1引擎的假设与现有ETH1软件一致，并且不会给现有ETH1软件带来意外的负担；
2. 更明确地定义用于驱动ETH1引擎的通信协议，例如new_head(block)、alidate_block_transition(block)、get_proposal(parent_root)等；
3. 定义网络组件，例如需要ETH1协议的哪一个子集，如何具体使用ENR；
4. 扩展以太坊2.0 阶段1 规范
5. 原！

本文经作者Danny Ryan授权翻译。