以太坊 2.0 Phase 0 V0.8.0 技术规范 - 区块链前沿 - BitMere

概览信标链（Beacon chain）是居于以太坊 2.0 系统核心的一条链。叫这个名字是因为这条链会充当随机性的信标，但也可以就叫做 “系统链” 或者 “脊柱链”，等等。这条链也是验证者 “所在” 的链，也就是说，验证者的责任会在这条链上得到分配、验证者会在这个共识环境中运行协议层的随机数生成器、验证者也在这条链上为链顶端的区块投票并形成确定性检查点；这里也是验证者引用分片链状态（crosslink）、用作诸分片链的根并协助跨分片通信的地方。信标链既是系统运作背后的大脑，也是后续分片系统据以搭建的框架。

信标链的状态（ BeaconState ）乃是技术规范所围绕的核心对象。 BeaconState 涵盖了所有有关的信息：验证者有那些人、他们分别处在什么状态中、这个状态属于区块树上的哪条链，以及对 Eth1 链的哈希值引用。

从创世状态开始，每当有一个区块能够满足状态转换函数所设的所有条件，该块处理完成后的状态就被认为是有效状态。这样依赖，一个区块的前提条件就可以被递归地定义为在前一个区块（及其状态）上运行状态转换函数所得的有效后置条件，这样一路回溯到创世状态。

分叉选择规则分叉选择规则的含义是：给定一棵区块树，总是能够根据这样的规则以及近期来自验证者形而消息，选出单一一条链（即 canonical chain，主链）以及终局状态。分叉选择规则接受该区块树以及相应的来自验证者集合的最新 attestation，然后返回一个区块作为当前的链顶端区块。LMD GHOST（最新消息驱动型 GHOST 算法），Eth2.0 所用的分叉选择规则，仅考虑每一个验证者最新的 attestation（“见证” 或者说 “证明”）所指向的区块，并以此来计算递归地附加在树上每一区块的总见证数量。也就是说，区块树上的一个节点（即一个 “区块”）的 “重量”，乃是将最新见证指向该区块或该区块的子孙区块的所有验证者的数量总和。GHOST 算法会从区块树的底部开始，每到一个节点便选择子链中最重的，直至到达叶子节点（即区块树末端的区块）。该叶子便是链的顶端，并递归地定义出了整条主链。

具体而言，在一个时段（epoch）中的每一个被指定的时隙（slot）中，验证者都有机会产生一个 attestation。提交 attestation.data.beacon_block_root 就是一次分叉选择意义上的投票了。在计算分叉选择结果时，算法会将来自近期活跃验证者所有投票都考虑在内

Finality分叉选择规则让我们可以在一棵区块树中选出一条主梁，而 “Finality”（“确定性”）则给了我们一种保证：特定的一些区块会一直保持在主链上。信标链使用改进版的 Casper FFG 来实现确定性。Casper 提供了 “可审计的安全性”，特定的一些区块会一直保持在主链上，除非一定比例的验证者烧掉他们锁定的资本。这就是我们认为有别于传统共识算法中的传统 “安全性” 定义的、“密码经济学” 意义上的 “安全性”。

具体而言，在一个时段（epoch）中的每一个被指定的时隙（slot）中，验证者都有机会产生一个 attestation。提交 attestation.data.source 会作为 FFG 的 source pair，而提交 attestation.data.target 则会作为 FFG 的 target pair，前者在 “Combining GHOST and Casper” 处有更深入的讨论。

CrosslinkCrosslink（“交联”）即是在信标链上保存的、对分片链近期状态/区块的引用。这些引用既是分片链在做分叉选择时候的树根，也是分片链之间异步通信的工具。在正常情况下，每一个分片每一个时段都可以交联到信标链一次（如果验证者数量少，有时候也会是每 N 个时段一次）。

虽然在 Phase 1 之前我们不会加入分片链，但 Phase 0 中系统还是会给交联委员会分配一个分片并尝试每个时段生成一个交联。在 Pahse 0 中，交联中的数据根会简单地存根为 0x00。

验证者职责关于 Phase 0 中的验证者职责，更详细的讨论可以看此处。

验证者的两种主要职责是：（1）每个时段给信标链做见证；（2）偶尔在被选中时产生信标链区块。每一个时段，验证者都会被分成不同的 “交联委员会”。每一个委员会都会被分配到一个时隙和一个分片。在给定时隙中，验证者为信标链顶端区块做 attestation（到 Phase 1 之后还要为分片链的最新数据做见证）。每一个时隙都会从被安排到该时隙的委员会中（通过 get_beacon_proposer_index）选出一个信标链区块提议者。

只要定期给信标链主链和分片链做见证，验证者就可以得到奖励；反之，如果不能完成职责，他们也会被惩罚。如果一个验证者违反了 Casper FFG 规则，或者他们在同一时段中创造了两个信标链区块，他们就会被罚没（比惩罚要更加严厉）。更多关于罚没条件的细节请看此处。

数据结构注意信标链内的数据街哦股以及数据结构的哈希值都被编码为 Simple SerialiZe (SSZ) 对象。使用 SSZ 哈希方法的一个好处是：在给底层数据生成默克尔树时，树的深度可以是不均匀的。这一点以及 SSZ 其余聪明设计的结果就是：一个 SSZ 对象，无论该对象的子对象是完整表现的还是仅由部分默克尔根值来表现的，该 SSZ 对象的哈希树根值都是一样的。

信标链操作信标链操作就是一个区块提议者可以加入 BeaconBlock （信标链区块）的数据结构，也是与系统层验证/构建相关的多种消息的合并方式。这些操作本质上都是验证者层级的信标链状态机事务。每一种操作在一个区块中都有数量上限，由 max operations per block 定义为常量。

ProposerSlashing

如果一个信标链区块提议者在同一时段中提议了两个不同的信标链区块，TA 可以被罚没。这一数据结构包含了对可罚没事件已然发生的证明。hash_tree_root(block) == hash_tree_root(block_header) ，因此，签名对所有数据结构来说都是有效的。 BeaconBlockHeader 因此可以用作证明来降低消息的大小。字段proposer_index —— 即提议要惩罚的验证者的 ValidatorIndexheader_1 —— 两个需罚没信标链区块中第一个的区块头header_2 —— 两个可罚没信标链区块中第二个的区块头AttesterSlashing

如果一个信标链见证者签署了两个相互冲突的见证（冲突情形由 is_slashable_attestation_data 来定义，后者会应用 Casper FFG 的 “双重投票” 和 “surroud” 投票条件来检查）字段attestation_1 —— 两个需罚没 attestation 中的第一个，注意这个字段的形式也是索引形式的attestation_2 —— 两个需罚没 attestation 中的第二个，注意这个字段的形式也是索引形式的Attestation

验证者为共识过程创建的最基本的消息形式。虽然每个时隙只有一个验证者可以创建信标链区块，但每个时段中所有验证者都有一次创建一个 attestation 的机会。正常情况下，所有在线的验证者每逢一个时段都能创建一个 attestation，并且都有一个 attestation 被纳入区块中。AttestationData 就是验证者签署的主要部分。外部的数据结构包含了聚合后的签名以及为了验证签名所必须的参与者字段。字段aggregation_bits 为委员会的成员存储一个 bit，委员会会为每个参与该聚合签名的验证者赋值为 1。注意，这是按委员会的顺序来排列的。data 就是该验证者或者验证者委员会签名的 AttestationData 。beacon_block_root —— 在被指定的时隙处，被视为链顶端的信标链区块的区块根source —— 在被指定的时隙处，最近在 BeaconState （信标链状态）中被确定的检查点（checkpoint）target —— 试图敲定的检查点（当前时段以及 epoch boundary block）crosslink —— 试图为指定分片构建的交联custody_bitfield 表示每一个委员会成员的 “保管证明（proof of custody）” bit（如果没有参加，那就是 0）。在 Phase 0 阶段，该值必然为 0。（因为托管证明要到 Phase 1 才实现）。signature 就是相关数据的 BLS 聚合签名。AttestationDataAndCustodyBit 是验证者签署的实际消息。给定 Attestation ，验证者可能签署的消息有两种—— 带有 0 或 1 的 custody bit 的 AttestationDataAndCustodyBit 。根据 custody_bitfield，我们可以从每个参与的验证者处，恢复出需要的被签过名的消息（custody_bit 0/1）。在 Phase 0 中，所有的 custody bit 都是 0。Deposit

表示从 Eth1 链的保证金合约中即将到来的验证者保证金。字段proof ——对 BeaconState 中的当前 eth1_data.root 的默克尔证据。注意向量长度的 +1 是因为 SSZ 长度混合到了根中。data —— DepositData 提交给保证金合约，以便被验证，验证时使用 deposit root 的证明。pubkey ——验证者用以对消息签名的 BLS12-381 公钥withdrawal_credentials —— 用于取出质押资金的离线公钥的哈希值。该密钥不会主动用于验证，可以保存在冷钱包中。amount —— 存储的 Gwei 数量signature —— 使用 pubkey 对应的 privkey 对 DepositData 的签名数据。这一数据也被用作一次性的 “proof of custody”，以保证安全地使用 BLS 秘钥。VoluntaryExit

消息类型，验证者可借发送此类消息而主动解除验证者职责字段epoch —— 本次退出行动上链处理所需的最小时段数。这一字段可以防止在链重组/分叉时对本功能validator_index —— 验证者退出活动的索引signature —— 相关验证者用公钥对 VoluntaryExit 的签名（验证者身份由validator_index 定义）。Transfer

让验证者可以转移余额。基本上就是为了让 Eth2 在 Phase 0 和 Phase 1 阶段（分片链承载状态之前）也能具有货币流动性。余额转移必须包括在准确指定的 slot 中，以避免重放攻击。正在承担职责的验证者不能转移余额，除非 TA 的余额高于 MAX_EFFECTIVE_BALANCEMAX_TRANSFERS 在 Phase 0 启动阶段预计会被设置为 0，只有在 Phase 0 看起来已经稳定可用之后才会提高字段sender —— 发送资金的验证者的索引recipient —— 接收资金的验证者的索引amount —— 发送的 Gwei 数量fee —— 用 Gwei 为单位计算的、交给区块提议者的手续费slot —— 这笔签名的 Transfer 可以上链的特定时隙。防止重放攻击pubkey —— sender 取出的 pubkey 。该公钥的 hash 必须匹配 sender 的 withdrawal_credentials。signature —— 对该 Transfer 的签名，来自 transfer.pubkey(未完)

原文链接: https://notes.ethereum.org/jDcuUp3-T8CeFTv0YpAsHw?view#Beacon-state