{"content":{"title":"Ethereum POS实现概述","body":"ETH POS算法已经在Ethereum2.0 共识协议Gasper分析 讨论过。 此处要结合ethereum consensus-specs,  分析Ethereum 共识层beacon chain是怎么实现的，以及beacon chain和执行层的关系，以及beacon chain最后如何跟eth1合并。 本文不讨论Ethereum POS对validator的奖惩策略，只关注工程结构。\r\n\r\n参考文献为https:\/\/github.com\/ethereum\/consensus-specs 和 https:\/\/github.com\/ethereum\/annotated-spec。 后者是对前者部分spec的注解。 我们只关注已经实现的3个阶段的spec, 分别是phase 0、Altair、the merge。 每个阶段我们关注<Honest validator guide [changes]>和<The beacon chain [changes]>。\r\n\r\n备注：\r\n1. eh1:   采用POW的以太坊链\r\n2. Beacon chain:  POS 信标链\r\n3. Gasper:  beacon chain 采用的共识算法的缩写，参见Combining Ghost And Casper  \r\n\r\n\r\n## 阶段\r\nPOW 到 POS 的迁移分为了三个阶段：\r\n1. Phase 0:   在eh1之外创建beacon chain。 eth1 对beacon chain无感知，beacon chain 读取eth1上的质押数据， beacon chain 上不运行合约和交易，仅维持POS相关的数据。 \r\n2. Altair:  有两个优化，一方面优化了Phase0中的validator奖惩机制，另一方面引入了一个给轻客户端用的sync protocol。 此时eth1和beacon chain的关系同Phase0。\r\n3. The Merge:  eth1 停止自主出块， eth1 node 将作为执行层，在共识层beacon chain的要求下创建和验证区块。beacon chain block中将引用eth1 block。 \r\n\r\n\r\n## Phase 0:   Beacon chain的诞生\r\n\r\n我们可以把blockchain看作一个不可篡改的历史数据库。 Beacon chain也是这样的， 它也有自己的状态和全部的历史数据。 不过在Phase0,  Beacon chain中的状态和数据，仅与维持POS有关， beacon chain 中没有交易数据。具体地说，beacon chain block 中存储了时间片信息epoch\/slot、validators列表、vote\/attestation信息、奖惩信息、随机数信息。 在eth1中， 我们说state往往指accounts states;  在beacon chain中,  可以把state理解为validators states以及POS状态，记为BeaconState。 \r\nhttps:\/\/github.com\/ethereum\/annotated-spec\/blob\/master\/phase0\/beacon-chain.md\r\nhttps:\/\/github.com\/ethereum\/consensus-specs\/blob\/dev\/specs\/phase0\/validator.md\r\nhttps:\/\/kb.beaconcha.in\/ethereum-2-keys\r\nhttps:\/\/github.com\/ethereum\/consensus-specs\/blob\/dev\/specs\/phase0\/deposit-contract.md\r\n### 时间片\r\nGasper 把时间分为slot和epoch,  在beacon chain,  1*slot=12s,   1*epoch=32*slot。根据当前时间与创世时间，确定当前所处的slot和epoch。 \r\n\r\n```python\r\nclass BeaconState(Container):\r\n    # Versioning\r\n    genesis_time: uint64\r\n    genesis_validators_root: Root\r\n    slot: Slot\r\n    ...\r\n```\r\n\r\n### Validator 生命周期\r\n众所周知，validator要在eth1质押32eth,  才能进入共识层工作。 那么beacon chain是如何同步eth1中的质押数据，激活和组织validators工作的呢？ \r\n#### Deposits\r\nEth1 上的deposits contract见：\r\nhttps:\/\/etherscan.io\/address\/0x00000000219ab540356cBB839Cbe05303d7705Fa#code\r\n目前只可质押deposit，不能赎回withdraw。 调用合约的deposit方法时，传入了一些数据用于validator的验证工作，以及日后的赎回。\r\n\r\n```python\r\n    function deposit(\r\n        bytes calldata pubkey,\r\n        bytes calldata withdrawal_credentials,\r\n        bytes calldata signature,\r\n        bytes32 deposit_data_root\r\n    ) override external payable\r\n```\r\n\r\n1. pubkey:  validator 在参数POS时，要对自己验证的数据进行签名，以证明验证来自validator本身。因此需要准备一个对密钥(privateKey,  publicKey)。publicKey 存入Deposit合约，最终同步到beacon chain, 用于POS的参与者验证签名的有效性。 由于privateKey需要validator频繁在线使用，所以常称为hot key。 \r\n2.  withdrawl_credentials:  validator 撤销凭证。Spec中定义了两种凭证格式。第一种： credentials 本身是一个public key。 Validator 保管相应的private key, 在撤回资金时，进行签名。 credentials中的public key验证撤销请求的正确性。此private key称cold key。第二种：credentials 本身是一个account address。 撤销时直接把资金打到此account address。 \r\n\r\n\r\n以第一种撤销凭证为例，下图展示了质押与回撤过程中涉及的密钥关系：\r\n<img src=\"https:\/\/img.learnblockchain.cn\/attachments\/2022\/10\/QgOQTYYo63493b653d09b.png\" alt=\"drawing\" width=\"50%\" \/>\r\nwithdraw功能将在shanghai升级中实现，相关spec见[execution-specs\/shanghai.md at master · ethereum\/execution-specs](https:\/\/github.com\/ethereum\/execution-specs\/blob\/master\/network-upgrades\/mainnet-upgrades\/shanghai.md)。 从公布的进度看，还没达到准备上线的阶段。\r\n#### Activation & Randao\r\n\r\n**Activation: From Eth1 to Beacon chain**\r\n\r\neth1 中deposits数据由proposer validator引入beacon chain block。为了确保引入的eth1 block是不可篡改的， 通过延迟引入和投票的机制加载eth1的数据。每EPOCHS_PER_ETH1_VOTING_PERIOD (=32)个epoch为一个投票周期。 投票对象为位于投票周期开始slot之前 ETH1_FOLLOW_DISTANCE（=2048）个block之前的最后一个Eth1 block（在POW中， 一个block距离head block距离越远，则其确定性越强。 此处的距离基于eth1出块时间14s预估，而不是基于block number）。 每个proposer validator将对Eth1 block投票，投票信息记录在proposed beacon block中， 一个投票周期过后，获得超过半数票的eth1 block胜出，被更新在BeaconState中，从此刻，加载eth1 block中deposits信息到beacon chain,  validator状态为pending。  平均来说，beacon chain每个epoch激活4个pending validators,  状态变为Active。 Active Validator并不立刻投入POS工作，而是提前4个epoch被告知自己被分配在哪个epoch, 提前一个epoch被确定validator所属的Committe, 以及角色(不包括proposer)。 所以一个eth1的staker从开始质押到产生收益，至少要经历12小时。\r\n\r\n![image.png](https:\/\/img.learnblockchain.cn\/attachments\/2022\/10\/MSmgQOGI63493c3d11217.png)\r\n\r\n相关spec:\r\nhttps:\/\/github.com\/ethereum\/consensus-specs\/blob\/dev\/specs\/phase0\/validator.md#eth1-data\r\nhttps:\/\/github.com\/ethereum\/annotated-spec\/blob\/master\/phase0\/beacon-chain.md#registry-updates\r\nhttps:\/\/github.com\/ethereum\/annotated-spec\/blob\/master\/phase0\/beacon-chain.md#eth1-data\r\nhttps:\/\/github.com\/ethereum\/annotated-spec\/blob\/master\/phase0\/beacon-chain.md#deposits\r\n\r\n**Randdo**\r\n\r\n我们已经知道validator信息如何从eh1加载到beacon chain。 那么validator又是如何被分配到committee呢？ 这个分配过程，需要有几个特点：\r\n1. 随机。 每个validator不会有固定的角色,  避免中心化。\r\n2. 可预测性。validator的在某个slot的角色是可提前确定的。\r\n3. 一致性。 角色随机分配的结果将在 validator之间达到一致。 \r\n\r\n![image.png](https:\/\/img.learnblockchain.cn\/attachments\/2022\/10\/jVL5K1XB63493c662917f.png)\r\n\r\n如上图， 每个proposer会产生一个随机数randao mix,  其生产随机数的入参来源于parent slot randao mix以及当前slot block。 从而产生一个伪随机数列。 服务于未来某个epoch的validator set，将在4个epoch之前，根据当时的validator集合和rando mix确定。Epoch内的committee划分将被其前一个epoch的randao mix确定。\r\n\r\n假设当前为epoch为N，在epoch N的第一个slot处，validator需要计算自己在epoch N+1中所属的角色（不包括proposer）。提前一个epoch确定角色的作用是，让validator完成子网的切换。为了减少attestation数据的广播， 同一个committe中的validator需要进入相同的子网，由agrregator把attestation数据聚合后广播。\r\nhttps:\/\/github.com\/ethereum\/annotated-spec\/blob\/master\/phase0\/beacon-chain.md#randao\r\nhttps:\/\/github.com\/ethereum\/consensus-specs\/blob\/dev\/specs\/phase0\/validator.md#validator-assignments\r\n\r\n### Validator职责\r\n\r\n接下来就是Gasper描述的validator行为了。 在slot开端， proposer打包和发送beacon chain block;  之后validator 验证和投票。\r\nBlock Proposal\r\n在eth1中， block包含两部分数据：transactions 和 state。 Beacon block类似， 包含：\r\n1. 行为数据： attestations、 slashings 、 eth1 data 、deposits 、voluntary exits 、 randao \r\n2. State:  最顶层为BeaconState, 另外还有所有validator的状\r\n\r\n\r\n<img src=\"https:\/\/img.learnblockchain.cn\/attachments\/2022\/10\/TvJCzO6Y63493cc1465b0.png\" alt=\"drawing\" width=\"50%\" align=\"center\"\/>\r\n\r\n#### Attesting & Aggregation\r\n投票和验证过程分为2个阶段。 把slot分成INTERVALS_PER_SLOT段， 在1\/3 slot处（或者在这之前收到slot block）， validator 进行attesting (即vote for GHOST & vote  for Casper),  签名后，构造 Attestation广播到subnet。  在2\/3 slot处， aggregator 将收集到的attestation聚合，广播出去。 \r\n### State Transition\r\nProposer 在构建新的区块时和validator验证新的区块时，都需要基于收集到的validator行为进行state trasition。 有两个重要的state transiton的时间节点， epoch边界和新区块产生。 Epoch边界与Casper共识有关，此时调整validator集合， 对validator进行奖惩罚。 新区块 与Ghost fork choice有关并且对slot之间产生的validator行为进行奖惩处理。 状态更新包括： validator 的奖惩、validaor状态调整、 block finalization、 eth1 block投票与加载等。\r\n\r\n<img src=\"https:\/\/img.learnblockchain.cn\/attachments\/2022\/10\/d9SKpPDI63493d03b179f.png\" alt=\"drawing\" width=\"50%\"\/>\r\n\r\n## Altair\r\n此文只关注轻客户端同步协议sync protocal：https:\/\/github.com\/ethereum\/annotated-spec\/blob\/master\/altair\/sync-protocol.md\r\n\r\n![image.png](https:\/\/img.learnblockchain.cn\/attachments\/2022\/10\/UTLXUr4e63493d18e5336.png)\r\n\r\n此协议的目的是： 轻客户端只需要下载部分block header,  即可证明block的有效性。\r\n这里我们引入了Sync Committee,  相关参数：\r\n\r\n<img src=\"https:\/\/img.learnblockchain.cn\/attachments\/2022\/10\/E8J23CKW63493d35add5f.png\" alt=\"drawing\" width=\"70%\"\/>\r\n\r\n每个Sync Committee里有512个validator,  他们的责任是对他们认为正确的beacon chain head block签名， 对block N的签名，会合并记录在block N+1的sync_aggregate字段中。 每个Sync Committee负责256个epoch(称为 sync period), 即差不多一天的时间， 每256个epoch后Sync Comittee换届。 对于轻客户端Light Client, 它只要每256个epoch, 能有一个head block, 就能完成确定性证明（在一定安全级别下）。\r\n\r\n我们来分析Light Client的证明过程。  BeaconState现在增加了两个字段，分别是current_sync_commitee 和 next_sync_committee,  分别为当前sync period的sync committee和下一个sync period的sync committee。 Sync commit中包含每个validator的公钥（以及所有公钥的和，用于优化验证速度）。  BeaconBlock 中新增sync_aggregate字段， 记录对parent block的聚合签名。 因此Light Client 可以使用至多512个validator的签名验证Block N的合法性 ,  他需要两个信息：\r\n1. Block N 所在sync period的sync_committee\r\n2. 对Block N的聚合签名，这个信息可以从Block N+1上获得，也可以从P2P网络直接获得来自sync committee aggregator的签名广播。\r\n\r\n\r\n由于一个BeaconState中包含了下一个sync period的sync_committee, 所以Light Client连续下载的两个Block header的距离最大可为256*2个epoch（第一个sync period的第一个block, 第二个sync period的最后一个block）。Light Client 通过一个block上签名的数量确定一个block的安全级别，如果一个block获得了2\/3 sync committee成员的签名，则立刻作为light client本地block head； 如果在一个sync period只，始终没收到2\/3 signed block, 则把这段时间（从确定上一个block head到现在）内具有最高签名数的节点作为本地block head。（还有对finalization的考虑，完整协议见：https:\/\/github.com\/ethereum\/annotated-spec\/blob\/master\/altair\/sync-protocol.md）\r\n\r\n现在我们看sync protocal是如何嵌入到POS中的。其实与Attestation Committee是相似的。 在state transition的过程中新增 sync_committee_updates,  在每个sync_period的第一个slot, 基于randao更新BeaconState中的current_sync_commitee和next_sync_committee。为了减少数据广播，有sync committee subnet和sync agregators。 具体讲，512个validator中有16个aggregator,为了降低中心化，在每个slot, aggregator都会随机变化，详见is_sync_committee_aggregator。一共有4个sync committee subnet,  每个validator归属其中一个。beacon chain block的产生和签名过程为：\r\n1. Slot N:   proposer 创建并广播block N\r\n2. Slot N + 1\/3 slot:   sync validator 收到block N,  验证block合法，制作签名发往一个sync committee subnet。   \r\n3. Slot N +  2\/3 slot:  sync aggregator聚合从subnet中收到的签名，并过滤非法签名，打包成一个聚合签名广播。\r\n4. Slot N+1 :   proposer 聚合从sync aggregator广播的签名，打包进block N+1\r\n\r\nPhase 0  中attesting 的过程不受 sync committee的影响。\r\nProposer对签名数量不做要求（即使没有sync committeed signature），但是通过奖惩机制激励validator完成正确的签名。\r\n## The Merge\r\nhttps:\/\/github.com\/ethereum\/annotated-spec\/blob\/master\/merge\/beacon-chain.md\r\nhttps:\/\/github.com\/ethereum\/consensus-specs\/blob\/dev\/specs\/bellatrix\/validator.md\r\n\r\n![image.png](https:\/\/img.learnblockchain.cn\/attachments\/2022\/10\/AI5TdCCy63493d80980cb.png)\r\n\r\n所谓merge，即eth1停止自主出块，而是eth1在beacon chain的调用下出块。这个图存在一定问题，并不是从merge后， eth1 就不存储block chain了。eth1中仍然有完整的block chain,  只不过new block是被动产生的。\r\n\r\nBeaconBlockBody中添加新字段excecution_payload。 execution_payload 中包含与当前的eth1 block头部等价的header信息以及 transactions列表。 BeaconState中添加新字段latest_execution_payload_header， 可以认为是execution_payload的指针。\r\n\r\nMerge之后Beacon Chain中只有eth1的block header信息，以及每个eth1 block包含的transactions（用于新区块的广播）， 合约和Account信息仍然存储在 eth1。\r\n\r\n\r\n现在生产区块的流程是：\r\n1.  beacon chain proposer 调用eth1生产下一个eth1 block, 之后把block header信息和transactions列表打包进BeaconBlockBody.execution_payload。 广播BeaconBlock。\r\n2. Validator 收到新的BeaconBlock后，调用eth1 ,  验证execution_payload的合法性(同时把transactions带入eth1)，如果合法，则在eth1会产生一个block， validator 对BeaconBlock 进行attesting or sync。\r\n\r\nBeacon validator 会把finalization信息传递到eth1,  eth1可以据此确定canonical chain。\r\n\r\n## About Sharding\r\nSharding将是The Merge之后的下一个以太坊重大更新。 由于POS的实现，以太坊可以进一步对集群参与者进行划分和约束， 这成为实现sharding的基础。 \r\n不过，目前还处在方案讨论阶段，2023年上线的计划不太可能实现。主要有两种方案：\r\n1. Sharding chain:   以太坊被分割成多条sharding chain, 每个sharding chain就像一条完整的eth chain, 有自己的数据层、执行层。sharding chain之间基于beacon chain跨链沟通。https:\/\/github.com\/ethereum\/annotated-spec\/blob\/master\/phase1\/beacon-chain.md\r\n2. Danksharding： 仅仅把数据层分割。https:\/\/members.delphidigital.io\/reports\/the-hitchhikers-guide-to-ethereum\r\n\r\n## 总结\r\nGasper 和 Randao 是Ethereum POS的基础。集群的参与者被划分为不同的角色以实现分布式一致。本文概述的就是角色是如何划分的，以及每个角色通常的行为是怎样的。 为了约束集群参与者的行为，Ethereum制定了它的法律，即 reward 和 penalty， 这是相当复杂和微妙的，本文并不涉及。 ETH POS并不是一个简单可证明理论的工程实现， 之后它会不会变得更复杂，它的“法律”能否无漏洞得维持系统运行，让我们拭目以待吧。 Beacon chain explorer： https:\/\/beaconcha.in\/。\r\n\r\n更多文章：[Bo1010 blockchain researches ](https:\/\/al3ul0osmp.feishu.cn\/wiki\/wikcnPaz9ZaBWWD0zm6f6Zf7iqd)"},"author":{"user":"https:\/\/learnblockchain.cn\/people\/11291","address":null},"history":"QmVgGGYCN3T1zFieAcjj3xbtiJTJopCDeLbmuaRTLULh9s","timestamp":1665745149,"version":1}