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

译者：洒脱

注：原作者为以太坊2.0协调人Danny Ryan（djrtwo）。 在这篇文章中，他详细介绍了以太坊 1.0 将如何与以太坊 2.0 融​​合。 据他介绍，在eth1+eth2组合客户端中，eth2客户端可以处理PoS和分片共识的复杂性，附加的eth1客户端可以成为eth1引擎，可以处理状态、交易、虚拟等复杂事物。机器等

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

自 Vitalik 在 2019 年 12 月提出早期的 eth1 和 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.0 引擎

云南新鲜海味干货，你吃过吗？

X

共识

从核心共识来看，eth2客户端负责并推动信标链、数据分片链和eth1分片链的建设。 eth2 客户端通过 RPC 直接向 eth1 引擎提供有关 eth1 分片链和核心共识（信标链/状态）的任何知识。

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

由于eth1引擎完全依赖eth2客户端来推动共识，我们建议eth2客户端与eth1引擎之间的通信是eth2客户端调用eth1引擎上的所有方法（如addBlock、getBlockProposal等）。 这将强制执行领导者/追随者关系，以降低系统推理的复杂性并限制 eth1 引擎所需的业务逻辑。

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

状态

Eth2 有一个与核心共识相关的状态，即所谓的“信标状态”。 信标状态数据很小（大约只有 10-40MB，取决于验证者集的大小），它包含了理解核心共识和如何处理分片链所需的所有信息。 事实上，要处理分片链的共识相关部分，客户端必须能够访问信标状态（例如，运行分片链分叉选举的最新交联、当前验证集或随机分配的洗牌）。

Eth2 的状态不会一直和用户层的状态交互，最重要的交互是分片链数据的可用性。 实际用户层数据根位于分片链数据中，对于eth1分片链来说，就是当前以太坊用户状态根。

下面讨论了与 eth2 客户端相关的 eth1 状态的不同情况：

1.没有eth1引擎的eth2客户端

核心 eth2 协议可以在没有额外的 eth1 引擎的情况下运行。 单个 eth2 客户端可以遵循信标链和分片链（包括 eth1 分片）。 没有 eth1 引擎，客户端无法执行无状态的 eth1 分片块，因此无法完全验证它们或从中获取任何有用的用户信息。 然而以太坊2.0什么时候开始，基于对 eth2 核心共识和验证者的假设，仍然可以安全地找到 eth1 分片链的头部。

2. 带有无状态eth1引擎的eth2客户端

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

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

3. eth2 客户端与有状态的 eth1 引擎

要运行为 eth1 分片生成块的验证器，eth2 协议必须与额外的 eth1 引擎和完整的 eth1 状态一起运行（开发人员正在探索无状态块生产，但为简单起见我们不会讨论它）。 然后可以使用本地状态和交易内存池（TX mempool）按需形成新的有效块（更多内容见下文）。

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

互联网

为简单起见，eth2 和 eth1 最初将维护自己独立的网络堆栈和协议。 为了应对职责的转移（例如 eth1 分片块八卦），开发人员弃用了一些现有的 eth1 协议（例如 eth1 分片块八卦）并用 eth2 协议取而代之。 在初始原型制作阶段之后，或在更进一步的阶段以太坊2.0什么时候开始，可能需要将 eth1 协议迁移到 libp2p 以统一网络堆栈，但这不是必需的。

eth2 客户端和 eth1 引擎可以访问相同的 discv5 DHT，但独立地找到具有适当能力的对等点并独立地维护连接。

ENR

组合的 eth1+eth2 客户端将使用一个 ENR，因为该节点位于具有多种功能的逻辑网络身份之后。

eth1 的功能（状态、交易等）由 ENR 中现有的 eth（或新的 eth1）密钥表示。

eth2 功能（核心共识）由 ENR 中的 eth2 密钥表示。

每个协议的存在意味着节点能够并且愿意识别底层网络协议的类型。

有线协议

1.eth2协议

1. eth2 request/response（1. Status，2. Beacon区块同步，3. Shard区块同步）； 2.核心共识八卦（1.信标块，2.证明，3.分片块，包括eth1分片，4，其他验证者操作）；

2.eth1协议

1.eth1 wire协议的一个子集（1.交易八卦，2.同步方法，比如getnodedata或者新的方法，3.get receipt收据）

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

3、eth2客户端为什么要处理eth1区块八卦？

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

当验证者将 eth1 分片块分叉到信标链时，eth2 客户端将再次调用 eth1 引擎来执行和验证该块。

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

交易八卦和存储池 mempool

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

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

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 区块数据打包成一个完整的分片区块（添加 slot、positer_index、positer_signature 等），并将该区块广播到网络中。

eth1 引擎能够生成有效/可行的 eth1 区块数据，因为它以与当今以太坊主网相同的方式管理 eth1 交易存储池，并通过来自 eth2 客户端信息的更新来维护最新的 eth1 头部状态。

下一步是什么？

如果就此总体设计达成一致，则接下来的步骤包括：

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