浅析以太坊2.0

What is ETH2.0

The Merge！

BlockBeats X 欧易 OKX 以太坊合并洞察联合播报，以太坊已于 2022 年 9 月 15 日 14 时 43 分完成主网和信标链的合并，标志着以太坊工作量证明（PoW）的淘汰以及向权益证明（PoS）的完全过渡

Before Merge

在Merge之前，以太坊采用PoW(Proof of Work)共识机制，矿工通过寻找哈希碰撞解进行挖矿，其他节点通过验算找到的解是否满足条件即可确认区块是否有效。

After Merge

在Merge之后，以太坊改用PoS(Proof of Stake)共识机制，新区块的构建不再需要寻找哈希碰撞解，而是改由质押了一定数量ETH的节点按照一定的规则轮流获取打包出块权。如果节点作恶，那么按照共识协议，其质押的ETH会被罚没(slashing) ，通过这种方式来促使节点遵守协议规则。

What's "Merge"

即原来eth1.0的链(PoW Main Chai)和新的信标链(Beacon Chain)合并，由信标链上存储的质押信息来决定出块节点的顺序。而原eth1.0则抽象成一个execution layer，负责合约的执行和合约状态的维护。

Why Merge

• 能源消耗问题 PoW共识机制的哈希碰撞运算消耗了大量的能源，不够环保。
• 网络稳定性问题 质押促使节点需要一直维护来保证节点的正常运行直至退出质押，而PoW机制下矿工随时可以关机

• 实现以太坊扩容(Scaling)⭐ 即提高TPS，在PoW机制下，解决了puzzle的矿工就可以出块，出块的节点和时间间隔是不确定的，不利于分片等扩容技术的实现。在PoS机制下，可以通过信标链来统一协调出块节点的顺序、分片信息等。

  How to ETH2.0

  信标链(beacon chain)

  信标链是一条独立于原有以太坊链而运行的新链，其与原eth1.0抽象出的execution layer相互配合，实现PoS共识机制。

  信标链结构

  
  每一个epoch包含有32个slot，slot间隔周期为12s， 每个slot对应原eth1.0中的一个区块。(后续若启用多个分片链，则1个slot会对应多个分片链中的新区块)。

  type BeaconBlock struct {
    version       int
    slot          types.Slot // slot号
    proposerIndex types.ValidatorIndex 
    parentRoot    [field_params.RootLength]byte
    stateRoot     [field_params.RootLength]byte
    body          *BeaconBlockBody
  }

  其中，BeaconBlockBody的结构如下：

  type BeaconBlockBody struct {
    version                int
    isBlinded              bool
    randaoReveal           [field_params.BLSSignatureLength]byte
    eth1Data               *eth.Eth1Data
    graffiti               [field_params.RootLength]byte
    proposerSlashings      []*eth.ProposerSlashing
    attesterSlashings      []*eth.AttesterSlashing
    attestations           []*eth.Attestation
    deposits               []*eth.Deposit
    voluntaryExits         []*eth.SignedVoluntaryExit
    syncAggregate          *eth.SyncAggregate
    executionPayload       *engine.ExecutionPayload // 非盲区块，对应execution layer中的一个区块信息
    executionPayloadHeader *engine.ExecutionPayloadHeader //盲区块，对应execution layer中的一个区块信息
  }

  其中，engine.ExecutionPayload和engine.ExecutionPayloadHeader结构大体一致，区别在于是否为盲区块（后面讨论）， 以engine.ExecutionPayload为例，其结构体如下：

  type ExecutionPayload struct {
    state         protoimpl.MessageState
    sizeCache     protoimpl.SizeCache
    unknownFields protoimpl.UnknownFields
  
    ParentHash    []byte   
    FeeRecipient  []byte   
    StateRoot     []byte   
    ReceiptsRoot  []byte   
    LogsBloom     []byte   
    PrevRandao    []byte   
    BlockNumber   uint64   
    GasLimit      uint64   
    GasUsed       uint64   
    Timestamp     uint64  
    ExtraData     []byte   
    BaseFeePerGas []byte   
    BlockHash     []byte   
    Transactions  [][]byte
  }

  可以发现，这实际上就是原以太坊中的区块头。 也就是说，通过将区块头打包进beacon chain实现了execution layer和beacon chain的merge。

信标链共识

前面介绍了信标链上的结构，以及存了什么信息以实现和原链的"merge“，下面介绍beacon chain如何实现共识，即不同的信标链节点间达成一致以持续出块。

Stacker->Validator

首先，如果一个节点想要参与beacon chain的共识，首先需要质押32个ETH，随后，经过一段时间的等待（出于安全考虑），质押者Stacker就会被激活成为Validator，即可参与beacon chain的共识，直至由于作恶被slash或主动退出。

委员会(committees)选举

在每个epoch开始的时候，会将当前网络中注册的所有validator随机分配到某个slot中（随机确保恶意节点被分到同一个slot的概率足够小），如果启用了分片链，还会再进一步将validator分到指定的分片上，组成指定epoch、指定slot、指定分片上的委员会。委员会内又会再确定一个validator为Proposer，其他的为则为证明者Attester。

委员会投票

轮到指定slot出块时，Proposer会向网络中广播一个新的区块，然后其他的Attester进行校验投票（该类型的投票称为LMD GHOST投票），如果收集到的赞成票数超过2/3（根据质押数量加权），则新的块被加到beacon chain中。

分叉选择(fork choice)

如果出现分叉，则选择根据质押量加权后权重最高的节点

信标链检查点(checkpoints)

每个epoch中的第一个slot被称为checkpoints，也成为时段边界区块EBB (epoch boundary block)，每个validator在每个epoch中发起一次 LMD GHOST投票（对当前slot的块进行表决）同时还要对最近一个epoch的检查点发起一次投票，称为Casper FFG投票（对最近的检查点进行表决）。在提交Casper FFG投票时，需要包括两个检查点：当前epoch的checkpoint(称为target)和前一个checkpoint(称为source)
如果一个epoch的checkpoint表决通过（根据质押量加权后的2/3票数），则该epoch称为被"证明(justified)"了
更进一步，如果某个epoch的下一个epoch也被justified了，那么该epoch则称为被"确定(finalized)"了

罚没机制(slashing)

如下的行为会被视作恶意行为：

• 双重提议(double proposer) 即proposer在一个slot中提议了两个不同的块
• 双重投票(double vote) 即validator针对同一个target发了相对于不同source的两次FFG投票

• 环绕投票(surround vote) 指一个FFG投票的区间包括了另一个FFG投票的区间
  

  激励机制

  validator的激励来源包括两部分：Attestation Reward 和 Proposer Reward
  首先定义base_reward
  $$base\_reward =\frac{ 64 * Average\_effective\_balance}{4*sqrt(Total\_active\_balance\_staked)}$$
  其中, 64和4为可调节的协议参数，Average effective balance为平均质押量(没有被slash的validator时为32ETH，存在被slash的validator时将会小于32)，Total active balance staked为质押的ETH总数

  Attestation Reward

  
  其中，source和targe对应Casper FFG投票中的参数，head则为LMD GHOST投票对应的区块头

  Proposer Reward

  $$Reward\_per\_proposer = \frac{base\_reward*number\_of\_attestors}{8}$$
  其中，\( number\_of\_attestors \)为收集到的Attester的票数

  merge后的通胀率

  实际上，以上的激励机制里面起调节作用的主要是base reward，而base_reward在1. 节点越稳定时收入越高 2.质押总量越少收益越高，从而鼓励质押 以上两个指向都有利于以太坊的稳定性。在merge之前，挖矿的收益=固定收益(2ETH)+矿工费，merge之后，validator的收益=质押收益（当前每个块约0.1~0.2ETH不等）+矿工费(如果当选proposer)。
  据估算，在新的激励模型下，merge后的通胀率将远低于merge前的通胀率

  论文

  beacon chain的基本内容就是这些，有一篇完整的论文专门讲beacon chain的共识，包括了安全性证明等内容。
  

  beacon chain和execution layer的交互实现

  总体架构

  

• eth1即原有的实现，现在作为执行层复用（如geth）
• eth2为根据beacon chain的规范实现的beacon client，独立于原有实现（如prysm）

• 两者分别实现组成各自的p2p网络，并通过RPC调用通讯

  eth2 client

  由社区根据规范实现，如prysm(https://github.com/prysmaticl...)
  

• eth2 client 负责实现beacon chain的共识协议
• eth2 client中维护了beacon chain的相关状态

• 通过RPC调用将收到的区块传递给eth1-engine

  eth1 engine

  

• 接收并响应来自eth2-client的RPC请求
• 维护原eth链中的状态，如合约状态、账户余额等

• 交易广播、打包以及EVM虚拟机仍复用eth1 engine的原有实现

  Post-Merge? Ready For Surge！

  以太坊Merge的目的是为了实现扩容(scaling，即提高tps)。
  目前社区提出了新的扩容方案EIP4844，该提案是前一个提案的改进版本。
  
  这两个提案的核心思想都是数据分片(Danksharding )。这是一个有别于原有的“网络分片-交易分片-状态分片”外的一种分片方案
  这与之前区块链里面研究的状态分片不同，状态分片更多讨论如何将交易划分到不同的分片去执行，此外还要考虑跨片交易的实现。
  
  为了保证安全性，如果采取状态分片的方案，那么必须要在每个epoch对每个validator所属的分片进行重新随机分配，但这样会引入新的问题：数据同步问题，即validator在切换分片后需要使用相应分片的数据库

• 如果validator在切换分片后重新同步新分片的数据，难以保证这项工作能够在切换分片的短时间内完成
• 如果validator保留完整的数据，在切换分片时使用相应分片的数据，那节点的数据库将会一直膨胀，与分片的初衷相违背。

• 此外，跨片交易的设计也很复杂，特别是针对以太坊EVM这种具备图灵完备特性的虚拟机，既难以预测合约执行过程中会访问哪些分片的数据，也难以保证合约执行过程访问的数据在同一分片上。
  
  为此，目前主流的观点是放弃状态分片，改用数据分片。在介绍数据分片之前，需要先介绍目前主流的扩容方案，rollup

  rollup

  目前主流的扩容方案是，以太坊链上不再执行EVM合约，而只存储有效性证明（即特定数据），将执行EVM合约的任务转至链下中心化节点上执行，并将所有交易输入(经过压缩后的transacitons)和 执行结果的有效性证明(如state root)上链供校验，这样所有用户都可以校验中心化节点的执行结果是否正确，以这种方式保证了链下中心化节点正确的执行了用户交易。 即链下(off-chain)计算，链上(on-chain)校验， 这种扩容方案被称为rollup。
  

  optimistic-rollup

  optimistic--乐观的，这种rollup的基本思想就是乐观的假设链下的中心化节点不会作恶，但是每个区块都有一定时间的挑战期，任何一个人都可以在挑战期内根据链上保存的交易输入和有效性去校验中心化节点的计算结果是否正确，如果不正确则可以发起提交欺诈证明以获取中心化节点的质押保证金。
  
  缺点： 挑战期内资金必须锁定在链上，流动能力不足

  zk-rollup

  运用密码学中零知识证明(zero knowledge)相关的技术,将交易以及交易状态转移的相关证明提交到智能合约上，只有验证通过才能完成上链。
  缺点： 目前基于zk-rollup的扩容方法仍尚未实现 对 图灵完备的EVM执行后的状态转移 生成零知识证明，只适用于一些特定的交易，如转账，代币兑换等。
  
  通过rollup，以太坊链的任务从执行合约，存储合约、账户状态变为了存储特定常量数据（如前面提到的有效性证明），为此，问题也就从“如何将不同交易划分到不同分片节点上执行”变成了“如何将数据划分到不同节点上存储”，即数据分片
  

  数据分片方案(Danksharding)

  数据分片方案是为了配合rollups而提出的一种分片方案，目的是降低验证节点(validator)验证区块有效性所需要的配置门槛，从而让更多验证节点能够参与进共识中，进而提高网络的去中心化和安全性。
  其主要包括如下三个部分：

• 数据可用性抽样（DAS） 通过数学设计对区块数据进行分片，让验证节点只需要检查部分数据碎片就可以验证区块的完整性。主要通过Reed-Solomon（RS）编码 + KZG多项式承诺 来实现。 RS编码用于实现数据分片，KZG多项式承诺确保编码人按照预先的编码规则进行了编码。
• 出块者-打包者分离 (PBS Proposer-builder Separation) 为了进一步降低validator的门槛，validator作为proposer可以将打包区块的工作分离出去，交由专门的builder来进行，而validator只需要根据利益最大化的原则，采纳多个builder提交的区块中出价最高的那一个进行签名广播即可。此外，为了防止validator或其他builder窃取一个builder构建的区块，需要采用盲区块(blind block)机制，即builder在给validator发送的区块中并不包含具体的交易，只包括了区块头，只有等到validator将采纳的区块签名广播后，builder才会公布包括区块交易的完整区块。（待确认点：proposer看不到交易的内容，如何确保builder构造的区块是合法完整的）
• 抗审查清单(crList) 为了防止打包者(builder)有意的忽略指定交易而造成中心化，validator可以通过提供crList指定builder打包的区块内必须包含指定交易，从而实现了validator和builder的分权制衡

包含PBS和crList的完整架构如下所示：

数据可用性采样(DAS)

Reed-Solomon（RS）编码

基本原理：
对于两个数m、n，设方程f(x)=ax+b,
令m=f(0)=b,n=f(1)=a+b，可得a=n-b,b=m
则有p=f(2)=2n-m,q=f(3)=3n-2m
则对于原数据m、n和冗余数据p、q，只有接收到这4个数中的任意两个，都可以还原出m、n
依此类推，将数据分成x个碎片，再生成x个冗余碎片，将这2x个数据进行分发，只要其中任意x个都可以还原完整数据。
以此为基础，validator可以不下载完整的数据，而是请求采样k个碎片，如果都能校验通过，则认为无法找到x个还原完整数据的碎片的概率为 \( 0.5^k \)

KZG多项式承诺

https://dankradfeist.de/ether...
该技术用于在validator请求数据分片校验时，数据节点生成相应的证明以证明数据完整性（类比默克尔证明）

总结

目前以太坊社区主流的观点都是放弃执行分片，改用数据分片，结合

• 中心化出块 (rollup)
• 去中心化验证(DAS+PBS)
• 抗审查(crList)

来实现以太坊扩容
我认为围绕这一个思想，确实有很大的想象空间，一方面，中心化出块可以让交易执行、确认的时间大幅缩短，另一方面，去中心化验证保证了这种方案仍然不违背区块链的基本原则。倘若能够将传统互联网应用中的分布式处理技术运用到中心化出块中，并保证去中心化验证的可行性和高效性，有可能能够将区块链的tps提高一个数量级。

参考资料

1. 详解以太坊2.0信标链
2. Combining GHOST and Casper
3. Danksharding解读
4. Danksharding workshop