来源 | stonecoldpat.substack.com
作者 | Patrick McCorry
翻译 | John, ECN
审阅 | Franci, ECN
使用权益证明的以太坊的独特性在于参与者数量的最大化设计。它允许成百上千和成千上万的验证者活跃地参与决策过程。在笔者撰文时已经有大约 50 万的验证者实体（从协议的角度而言）在活跃地参与这个过程。
事实上，在约 384 秒（6 分 24 秒）内，所有活跃中的验证者将有机会投下一票或提议一个区块。在约 384 秒内至少有 50 万条信息广播，而且所有信息必须在严格的时间范围内传递。据我所知，没有其他共识协议被设计来处理如此活跃和庞大的共识参与者集。
至于通信模型方面，共识协议是为以下三种情况之一设计的（通常）：
同步通信 一个普遍同意和已知的信息传递超时时间。
异步通信 信息传递所需时间没有上限， 但它最终会被发送。
部分同步通信 在大多数情况下，都有一个已知的超时时间，但零星的事件可能会破坏信息传递，时间长短不一。
大多数现代共识协议都是为部分同步通信而设计的，因为它假设大部分时间条件良好，但由于事件可能会在短时间内中断通信，所以存在不可预测的时期。另一方面，值得注意的是，权益证明的以太坊是为同步通信设计的。
题外话--Casper FFG 是为部分同步通信而设计的，但 LMD-GHOST 的严格计时条件迫使整个系统必须同步。我们将在今后的文章中解释什么是 Casper 和 LMD-GHOST。
它假定在绝大多数的验证者中几乎没有中断，而且所有的信息必须在固定的最后期限前被记录在信标区块链上，这些信息才能被计入/使用。如果出现中断，导致信息延迟传递，那么发送者将根据其延迟程度而招致惩罚。在最坏的情况下，如果错过了最后期限，那么消息将被忽略，信息发送者将受到不活跃的最大惩罚。惩罚政策将在未来的文章中介绍。
为了更好地理解同步通信模型，我们涵盖了 Epochs & Slots 的主题。它定义了验证者被允许参与的时间，以及围绕消息传递的严格时间窗口。如果违反了时间窗口，不管是什么原因，那么就不能保证其他验证者会就迟到的消息到达时采取行动。最后，我们将介绍验证者如何被分配到一个时间槽（time slot），以及消息如何被记录在信标区块链中。
如果你想深入了解各种通信设置，那么我建议阅读这篇文章。这里也有关于 ETH2 是部分同步通信还是同步通信的精彩讨论。
Epoch 和 Slot
每个 epoch 有 32 个 slot，每个验证者在每个 epoch 正好被分配到一个槽位。一个 slot 是一个 12 秒的时间窗口，期间验证者可以参与权益证明协议，对新的信标区块进行提议或投票。
slot 按 epoch 分组，epoch 和 slot 为验证者参与权益证明协议扮演一个时间表的角色：
Epoch 一个包括 32 个 slot 的周期。
Slot 一个验证者委员会在为期 12 秒的时间里完成任务的窗口期。
一个 epoch 代表了权益证明协议的一个完整的回合， slot 为验证者提供了一个参与该回合的机会。在一个 epoch 结束时，所有活跃的验证者都有机会参与。
Slot 委员会 一个验证者在一个 epoch 中正好被分配到一个 slot，所有验证者被平均分配到各个 slot，组成委员会。
一个 slot 里有两种角色：
区块提议者（Block proposer） 一个验证者有机会向委员会成员提议一个区块。
见证者（Attester） 所有剩余的委员会成员会为一个区块投票，他们相信那个区块应该会成为新的区块链头。
每个 epoch 有 32 个区块提议者（每个 slot 一个），所有验证者都有机会参与权益证明协议，向他们认为应该是规范信标链（canonical beacon chain）的链头投出一票。
一个 slot 代表了一个严格的时间窗口，供一个验证者提议一个区块，委员会成员对一个区块进行投票，最后将所有该 slot 的活动广播给下一个 slot 的区块提议者。
Slot 和时间条件 所有 slot 都是按照时间顺序一个接一个地产生的。每一个 slot 都准确地按照 12 秒一个被分配出来，并被分成三个阶段：
提议区块 指定一个验证者提议一个区块，并在前 4 秒内将其广播给所有委员会成员。
投票周期 所有其他委员会的成员都为一个区块投票（见证），他们相信，接下来的四秒内他们的投票就要被这个区块接受。
广播投票 在最后的四秒里所有委员会成员的投票应该被聚合起来并发送给下个 slot 的区块提议者。
所有的区块和投票都是在一个 slot 的委员会内进行广播。在委员会中有一个额外的角色，叫做聚合者，他们会在将证明传递给下一个 slot 的区块提议者之前将其聚合。他们是自选的，这是一个自愿的角色，以减少通信的成本。我们将暂时跳过具体细节--因为这将在未来的文章中涉及。
如果一个提议的区块或见证是在截止日期之后发布的，那么就不能保证该活动会被其他验证者认可。例如，一个迟到的区块可能会被跳过，因为这个 slot 的见证者可能已经为其父块投了票。一个迟到的见证将被其他见证者在一个 epoch 中处理，最多迟到 32 个 slot，并有不同程度的惩罚。如果它在 32 个 slot 之后被发布，那么它将不会被任何验证者处理。
最后提醒一下，这个严格的时间窗口保证了运行验证者所需的带宽和计算能力的下限，因为他们必须要有准时接收、处理、发送见证/区块的能力。
验证者委员会的分配
我们在一个 epoch 里考虑分配验证者到 slot 里的过程。所有的 slot 委员会的规模大致相同。他们根据一个随机信标的输出完成分配，并且提前两个 epoch 进行。这要求使用一个混洗协议和一个同带信号传输随机性的源。
混洗协议 所有验证者都根据一个叫 swap-or-not 的混洗协议被分配到一个 slot 里去。我们不会去探讨这个混洗协议的细节，而是会把注意力集中到随机信标的计算方法上，这个方法奠定了混洗协议执行方式的基础。
随机信标 所有验证者通过一个随机信标被分配，这个随机信标使用了一个叫 RANDAO 的协议。其目的是在新的区块被添加到规范链上时通过聚合随机性来形成随机信标。
对于每一个新的区块而言，有两个阶段：
提议产生的随机性（每个区块） 一个新的信标区块包括了一个叫
randao_reveal的特殊值。它是一个区块提议者的 BLS 签名，用以充当区块的随机信标。它是确定的以防止被验证者篡改，但是不可预测。混合随机性（每个区块） 所有验证者从新的区块里取出随机信标并把它和之前所有聚合起来的区块的随机性混合。它形成了一个新值
mix，有可能作为混洗协议的候选。
正如我们所能看到的，每一个信标区块都包括了一个随机信标，添加并汇聚了所有之前的区块的随机性。
验证者们通过第 N 个 Epoch 最后的随机信标被分配到第 N+2 个 Epoch 的 slot 里
/** 区块提议者在当前 epoch 号码上进行一次 BLS 签名* 以充当这个区块的随机信标* 一个非常好的地方在于签名是确定的（验证者无法篡改它），但是直到签名被计算出来之前都是无法预测的*/DOMAIN_RANDAO = 0x02000000; // 一个签名里包含的神奇数字epoch_hash = hash(current_epoch_number, DOMAIN_RANDAO); // 要签署的哈希码randao_reveal = BLS.sign(epoch_hash, sk); // BLS 签名是 RANDAO/** 使用区块的随机性，进行哈希计算，然后把哈希码混合到现在聚集起来的随机性里*/previous_mix = get_previous_mix(parent_block); // 来自父块的混合（Mix）randao_reveal = new_block.randao_reveal; // 取得新区块的randaomix = previous_mix XOR hash(randao_reveal); // 计算新的混合store_new_mix(new_block); // 把新的“混合”（mix）和新的区块联系在一起
分配会提前 2 个 epoch 发生 所有验证者都会使用最后那个被接受的区块汇聚起来的 mix 值作为随机信标，并在混洗算法中使用它。它会计算得出未来两个 epoch 的验证者委员会。
所以，如果我们考虑目前的 epoch 为第 N 个，那么这个 epoch 里的最后那个信标区块会作为随机信标决定第 N+2 个 epoch 的委员会分配。
验证者们有充足的时间查找它们被分配到的 slot，因为它们提前两个 epoch 就知道了。换句话说，未来 64 个 slot 的验证者的分配是早就公之于众了的 (约 2 个 epoch）。
随机信标的可偏倚性（bias-ability) 只有一个 mix 能被混洗协议使用，那就是一个 epoch 中最后一个被接受的区块的 mix 值。
最后一个被接受的区块不会总是那个在第 32 个 slot 被提议的区块。而是最后一个 slot 的区块，也就是被所有验证者认可为区块链链头的那个区块。举个例子，如果第 32 个 slot 没有区块被提议产生（或者它迟到了），那么第 32 个 slot 的验证者委员会就会为之前在第 31 个 slot 被提议产生的前一个区块投票。
攻击者可以利用这点来使随机信标出现偏差。让我们假设攻击者是第 32 个 slot 的区块提议者。他可以决定这么干：
准时释放区块 攻击者的随机性被混合在信标里
暂缓区块 强迫所有验证者为上一个区块投票，则攻击者的随机性不会被混合在信标里。
这种决定权使得攻击者可以使随机信标出现 1 个字节的偏倚，并最终决定到底两个验证者分配组合里中的哪一个会在未来的一个 epoch 里被使用。实际上如果攻击者控制了一个 epoch 里最后 N 个区块的区块提议者们，那么它们可以利用这个机会释放或暂缓释放一个 N 个区块的组合。目前还缺乏一项严格的研究，来了解针对最后 N 个 slot 的偏倚能力的全部范围及其影响。
检查一个信标区块
一个信标区块的数据结构
一个单独的信标区块包含了它在信标区块链里所处位置的元数据、执行链的数据、以及权益证明协议的一份副本。我们会在下文探讨更多细节。
一个 slot 的区块提议者会尝试扩展规范链，并且只能选择一个父块。
信标父块 一个区块的提议者的目标是提议并添加一个新的信标区块到一个规范链的头。若要这么做的话，它们只能选择一个父块来进行扩展。父块应该是当前的链头，它在元数据中的代表是 parent_root。
Epoch 和 slot 组织验证者产生唯一一条规范信标区块链。
Slot ≠ 信标区块 一个信标区块记录了它的 slot 号码的元数据（一个 epoch 号码的倍数）。它允许其他验证者检查区块提议者是否确实被指定为这个 slot 提议一个区块，这个区块是否就是被提议的那个区块。如果 slot 的号码错误，那么区块会被拒绝。
重点在于，一个区块在区块链里的位置不会与它在其中被提议的 slot 号码相对应。举个例子，如果我们检查第 5184157 个 slot，那么我们会看到第 16015362 个区块，这种不匹配是无法避免的，因为无法保证一个被分配的 slot 里被提议的区块会被所有其他验证者投票通过，而且以太坊从开始到现在运行了超过 7 年了。
执行链数据 区块提议者会提议两个区块，它们提议一个执行区块，给用户的交易排序，并把它附加到新产生的信标区块上。这并不奇怪，因为共识层的最终目的就在于为执行层决定规范链。
区块提议者同样负责从执行层转移信息到信标层上，并使其准备好为权益证明协议所用。这包括：
ETH1 数据 一个来自执行层的附加区块的区块哈希码。
存款 存款合约地址和一连串未记录的存款。
这要求所有的验证者运行一个信标客户端和一个执行客户端。这是必要的，因为验证者们必须检查对应的 ETH1 区块并根据执行层规则验证其有效性。同样地，正如我们在关于注册过程的文章里讨论的一样，存款必须在一个特定的区块间隔期内从执行层上被转移到一个信标区块上，否则信标区块会被拒绝。
元数据 slot 号码、epoch 号码、随机信标和区块提议者
罚没事件 包括其他验证者的恶意行为证据，这些证据可用于惩罚它们
投票历史记录 一连串在这个区块链分叉上针对之前提议的信标区块的未被记录的的投票
区块链分叉 它挑选了一个父块，并反过来定义了这个区块所延伸的规范链。
验证者退出 一连串已注册验证者的退出请求。
通过记录下副本，每一个人都可以独立地回顾整个协议，并且绝对相信目前信标链的状态是正确的。比如说，恶意的验证者会被及时罚没，slot 和 epoch 的时间表受到全体验证者的认可，绝大多数验证者都会以这种方式投票并产生单独一条规范链。
题外话，由于弱主观性的缘故，虽然权益证明的记录可以使我们信服所有历史活动都是按照规则进行的，但是尚不足以向一个外部群体说明这确实是那条真实的信标区块链。简单来说就是它提供了一个检查历史活动完整性的方法。
点击“阅读原文”获取文章内部链接！
原文链接：https://stonecoldpat.substack.com/p/epochs-slots-and-beacon-blocks
ECN 的翻译、编辑工作旨在为以太坊中文社区传递优质资讯和学习资源，文章版权归原作者所有，转载须注明原文出处以及 ETH 中文。若需长期转载，请联系 eth@ecn.co 进行授权。
