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