以太坊执行层 (Eth1) 和信标链 (Eth2)合并后会发生什么

为了以太坊 2.0 升级做准备，今年 1 月底时，以太坊基金会宣布”以太坊 1.0”（ETH1）和“以太坊 2.0”（ETH2）一词将被淘汰，取而代之的是“执行层”和“共识层”，执行层+共识层=新的以太坊。

而目前合并的开发工作已基本完成，正处于公开测试阶段，预计到 22 年第二季度完成合并。本次合并，将是以太坊有史以来最大的一次升级，如何保障以太坊这个去中心化的网络在不停服的前提下，六千多个节点顺利升级，并且升级后不影响已有合约、资产的使用。

为了本次升级，以太坊核心开发者和整个社区准备已久，所有的以太坊用户也都拭目以待。那么，本次合并什么时候发生，发生后执行层和共识层会发送什么改变？

一、如何触发

信标链通过监测当前以太坊的出块难度total difficulty， 一旦出块难度大于等于某一个临界值（TERMINAL_TOTAL_DIFFICULTY），该区块将会是最后一个 POW 块，之后的区块将由信标链构建。

二、何时触发

目前各项工作已准备就绪，预计在第二季度进行合并，更准确的是在 6 月份之前。当然，也不排除由于一些意外情况导致的推迟，如公测期间发现一个漏洞，修复完成的时间就不确定了。

之所以是 6 月份，是因为在 21 年 12 月的 Arrow Glacier（箭形冰川升级）中，通过了 EIP-4345，将难度炸弹推迟到了 22 年 6 月，也就是说，如果在 6 月份，合并还没完成，那么难度炸弹会将再次推迟，希望这种情况不会发生。

三、合并后的以太坊

合并后执行层+共识层等于新的以太坊，其中：

• Eth1 → 执行层：负责处理事务和数据
  
• Eth2 → 共识层：负责处理 PoS 共识，采用信标链
  

合并后的架构如下图所示。

从图中可以看出：

• 执行层节点和信标链节点为独立节点
  
• 二者有各自的 p2p 网络和暴露的 API
  
• 二者通过引擎 API 进行通信
  

四、执行层

合并后的执行层会将 POW 共识相关的部分删除，状态管理、区块构建和验证会有修改，其他的如 EVM 等功能保持不变。

4.1 区块格式的修改

在区块中，与 POW 相关的字段会被设置为 0，如下表所示。

另外，extraData 字段长度会被限制为 32 字节。

相应的，对区块的有效性校验，会有如下更改：

• 去掉关于 difficulty 的验证
  
• 去掉 nonce 和 mixHash 的验证
  
• 去掉叔块 ommers 列表及列表成员的验证
  

4.2 以太币增发

由于共识从 POW 切换为 POS，将取消叔块的奖励，而执行层会继续处理交易的手续费，手续费将会支付给 ExecutionPayload（执行数据）中的 feeReceipient（费用接收者）。

4.3 区块广播

合并后，执行层将不会在进行区块广播，具体到客户端上，就是取消 和  的处理逻辑。同时，执行层仍然会同步网络状态，广播交易和维护交易池。

NewBlockHashes (0x01)

NewBlock (0x07)

4.4 Engine API

Engine API 是执行层不同于 JSON RPC API 的，一个独立端口的 API 模块。

Engine API 引入了三个接口：

1、engine_newPalyload

engine_newPalyload，引擎执行数据，该接口的主要作用是要求执行层验证 ExecutionPayload（执行数据）是否符合要求，执行层响应的状态包括：

• VALID，有效
  
• INVALID，无效
  
• SYNCING，同步中
  
• ACCEPTED，已接受，防止重复提交
  
• INVALID_BLOCK_HASH，区块 hash 无效
  
• INVALID_TERMINAL_BLOCK，区块终端无效
  

2、engine_forkchoiceUpdated

engine_forkchoiceUpdated，引擎分叉选择更新，其功能主要是共识层让执行层生成一个新的区块 ExecutionPayload。

3、engine_getPayload

engine_getPayload，引擎获取数据，共识层通过请求 engine_getPayload 接口，获取执行层中的 ExecutionPayload 数据。

ExecutionPayload 数据结构如下图所示。

五、信标链

信标链在 2020 年 12 月 1 日就已经上线，由于还没有合并，因此目前的信标链是对空快达成共识的。信标链浏览器：https://beaconscan.com/[2]

合并后，信标链负责对区块达成共识，合并后的区块如下图所示。

当共识层需要打包一个新的区块时：

• 首先会调用执行层引擎 API 的 engine_forkchoiceUpdated 接口，携带 payloadAttributes 参数，执行层返回 payloadId
  
• 其次，共识层调用 engine_getPayload 接口，传入 payloadId，执行层返回 ExecutionPayload 数据。
  
• 再次，共识层调用 engine_newPalyload 接口，传入 ExecutionPayload 数据，执行层验证交易并返回数据是否有效。
  
• 最后，共识层调用 engine_forkchoiceUpdated，传入 ForkchoiceState 参数，执行层同步新的区块。
  

合并后，信标链开始打包区块，如下图所示。