乐趣区

关于以太坊:浅析以太坊20

jiezi

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
退出移动版