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

By [sixdays](https://paragraph.com/@sixdays) · 2022-03-17

---

为了以太坊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 共识，采用信标链
    

![image.png](https://storage.googleapis.com/papyrus_images/bb37d157b78cc583cda5d2e8027ab387489becfea2147564f0f56bdabdc4470f.png)

image.png

从图中可以看出：

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

四、执行层
=====

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

4.1 区块格式的修改
-----------

![image2.png](https://storage.googleapis.com/papyrus_images/a3c21b9593961280b7dbb282636a4a5092c8016670f52108e6fc0770061c29be.png)

image2.png

另外，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数据。

![image4.png](https://storage.googleapis.com/papyrus_images/33324b6776c771250c8c7898c504b962d89f0a491346d5f0dee096d61a057056.png)

image4.png

五、信标链
=====

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

![image5.png](https://storage.googleapis.com/papyrus_images/b8594ce2d1f7186542d34fbd306a3525efa160261a522e62a465809211f7ae72.png)

image5.png

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

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

![image6.png](https://storage.googleapis.com/papyrus_images/06956bfd9192ab3048db3d8114609eaa6dc8814467c790c22201c7cdf8204fa3.png)

image6.png

六、参考
====

《AllCoreDevs Update 007》[https://tim.mirror.xyz/sR23jU02we6zXRgsF\_oTUkttL83S3vyn05vJWnnp-Lc](https://tim.mirror.xyz/sR23jU02we6zXRgsF_oTUkttL83S3vyn05vJWnnp-Lc)

《eip-3675》[https://eips.ethereum.org/EIPS/eip-3675](https://eips.ethereum.org/EIPS/eip-3675)

---

*Originally published on [sixdays](https://paragraph.com/@sixdays/eth1-eth2)*