# [译]以太坊 2.0 信标链详解 By [DavidCai.eth](https://paragraph.com/@davidcai) · 2022-03-03 --- 1 分配：蓝图 ----- 为了深入理解信标链，我们需要先介绍分片。目标的以太坊网络中，每一个节点都要验证所有交易，这大大限制了以太坊的扩容性。 在计算机科学里，扩容主要有两种途径： * 纵向扩容：使每一个节点的算力更加强大 * 横向扩容：增加更多的节点 为了符合去中心化的目标，区块链需要横向扩容。以太坊 2.0 的目标就是让节点可以运行在消费级电脑中。分片的目的就是横向切割当前的数据库。 总体来说，一条分片链上有自己的子节点。虚拟矿工，验证者被分配到分片上，并且只执行和验证当前分片（链）上的交易。 每个以太坊的分片拥有的节点，都是动态的，并且会按照顺序执行区块。 分配的一个主要挑战是安全性。由于验证者被分散开来了，恶意的节点们可能就会有控制分片的可能。 解决这个问题的关键在于：随机分配验证者，确保每个分片上都会存在一个通过伪随机算法选取的一个验证者委员会（committee）。在数学概率上，保证攻击者要控制超过分片上的 ⅓ 节点是困难的。 欺诈证明（fraud proofs），数据托管证明（ustody proofs）以及数据可用性检查（data availability checks）也都是确保安全的机制。 目前的以太坊 2.0 计划存在 64 个分片。尽管分片与信标链是分离的，但是我们还是会阐述分片机制中的一些关键元素。 通过上文对分片的描述，已经暗示了不少以太坊信标链该做的以及需要做的事。我们将在下文阐述信标链在传统区块链结构下，又会新增哪些新组件。 以太坊 2.0 阶段图 简单来说，以太坊 2.0 会有三个阶段： 阶段 0 - 信标链 阶段 1 - 分片 阶段 2 - 执行智能合约 如果使用人体来做一个类比的话： 阶段 0 - 心脏 阶段 1 - 四肢 阶段 2 - 大脑 如果使用乐团来做一个类比的话： 阶段 0 - 指挥 阶段 1 - 乐器 阶段 2 - 乐手 每一个阶段对于系统来说都是必要的。阶段 0 是以太坊 2020 年计划的一部分。阶段一的升级会让新系统开始稳定。阶段二的升级则会让新系统能够开始执行逻辑。 插槽（Slots）和轮回（Epochs） -------------------- 以太坊 2.0 的核心是信标链，它提供了“心跳”。信标链决定了系统中共识的节奏。每一隔 12 秒出一个插槽，每个轮回包含 32 个插槽，即每隔 6.4 分钟产生一个轮回。 2 在每个插槽中，信标链和分片中都有机会可以添加区块。你可以想象，信标链和分片链是步调一致的。系统在理想状态运行时，每间隔 12 秒，就有一个信标链区块和 64 个分片链区块产生。验证者需要大致[同步](https://ethresear.ch/t/network-adjusted-timestamps/4187)它们的本地时间。 所以从另一个角度，由于间隔固定，插槽也可以被视作区块时间，虽然插槽可以是空。信标链和分片链的创始区块都会在第 0 个插槽的位置。分片链将会在信标链的第 0 个轮回之后的下一个轮回开始启动。不过分片链自己的第 0 个轮回会包含它们自己的创世块。 验证者（Validators），证明（Attestations）和信标链介绍 -------------------------------------- 对标工作量证明公式中的矿工，在以太坊 2.0 的权益证明共识下，也会有“虚拟矿工”。由于存在下文将会讨论的权益奖惩，验证者会积极地参与到共识中来。 当要构建区块时，验证者中将会被伪随机地选出一个区块提议者（block proposer）。 大多数时候，验证者会对信标链和分片链上的区块进行投票，充当一份份证明。这些投票会决定信标链和分片链上的最新区块，并且投票本身也会被记录在信标链中。 3 在每个轮回中，验证者都会被伪随机地洗牌进入不同的分片中。验证者通过投票来决定分片的最新区块，以这种方式加入到共识中。验证者随后会将分片链中的区块头，以一个插槽的形式，链接（link）到信标链的最新区块中。 一个验证者的一次投票，即是一份证明，由验证者所质押的以太币比例来决定权重。证明会在出块时一同被广播。 当有验证者给出不正确的投票或者构建超过一个区块时，其他验证者都可以互相举报。 所以信标链上主要存储的内容有：验证者的地址，验证者的状态，证明以及分片链接（links to shards）。信标链有能力激活验证者，并且改变它们的状态，下文将会详细阐述。 有质押的验证者（Staking validators） --------------------------- 验证者是虚拟的，通过质押者激活而来。在工作量证明的场景里，用户通过购买矿机来成为矿工。在以太坊 2.0 中，用户通过质押以太币来激活和管理验证者。 让我们进一步理解有质押的质押者和有余额的验证者之间的关系。每一个验证者最多可以有 32 个以太币的余额，但是质押者可以质押他们身上所有的以太币（可以超过 32 个）。每有 32 个以太币被质押，就会激活一个验证者。 验证者通过验证者客户端来运行，同时需要与信标链保持配合。每一个信标节点都拥有追踪和读取信标链的功能。每一个验证者客户端也可以作为信标节点使用，并且与其他信标节点通信。一个验证者客户端可以同时包含多个验证者的职能。 交联（Crosslinks） -------------- 交联（Crosslinks）是信标链中对分片区块的一个引用。交联用于让信标链能够追踪上分片链的最新块。由于存在 64 个分片链，所以一个信标链区块最多可以包含 64 个交联。如果在一个插槽里，有 63 个分片都没有提交块，那么那个信标链块可能就只包含一个交联。交联计划在阶段 1 实现，用于将分片链扎根于信标链上。为分片链提供分叉选择，确认最终确定性和跨分片通信。所有的分片链都时刻会于信标链保持相连。 委员会（Committees）：简介 ------------------ 一个委员会由若干验证者组成。为了安全起见，在信标链和分片链中，每一个插槽都必须有一个至少拥有 128 个验证者的委员会。攻击者控制委员会中 ⅔ 节点的概率，低于[万亿分之一](https://medium.com/@chihchengliang/minimum-committee-size-explained-67047111fa20)。 以太坊信标链的名称，由来于随机信标（randomness beacon）这一概念（向公众提供随机数）。信标链通过一个成为 RANDAO 的伪随机流程来确认共识。 4 RANDAO 会以验证者的余额为权重，选择区块的提议者。在同一个插槽内，一个验证者可以同时是提议者和委员会成员，但这不常见，发生的概率大概是 1/32 ，所以我们大约在每一个轮回中可以看到一次。上图的场景中验证者数量少于 8192 个，否则一个插槽里至少会有两个委员会。 这里重点讲一下信标链中的委员会：为信标链服务的验证者们。一个信标链委员会被伪随机得分配到一个分片上，用于将该分片交联至信标链。信标链委员会并不是固定的，会随着每一个区块而改变。 仅仅只构造分片区块的分片链委员会将会在后面再讨论。分片链验证者只构建区块而不与信标链通信是可以的。但是，如果要与其他分片链通信，那么必须依赖于信标链委员会来进行交联。 5 上图描述了三个插槽中发生的状况。在第一个插槽里，一个被提议的区块由委员会 A 中的两个验证者投票，其中的一个掉线。然后第一个插槽中的证明和区块会被广播，其他的验证者将会接收。在第二个插槽里，一个区块被提议出来，但是委员会 B 中的一个验证者并没有看到，因此它对第一个插槽中的区块投出了一票证明。注意，这里的行为与刚才委员会 A 的掉线验证者是不同的。向投标链的区块头投出证明的过程被称为 LMD GHOST 投票。在第三个插槽里，委员会 C 中的所有的验证者都遵循 LMD GHOST 分叉选择规则，独立地为同一个提议区块投出了证明。 在一次轮回中，一个验证者只能在一个委员会中。如果全网有超过 8192 个验证者，那么意味着每个插槽将会拥有超过一个委员会。所有的委员会大小都相同，并且至少有 128 个验证者。当全网验证者数量少于 4096 时，由于每一个委员会中分配到的验证者数量会少于 128 ，网络的完全性可能会下降。 委员会：关键 ------ **在每个轮回中，验证者会被均分到各个插槽中，然后组成合适数量的委员会。 该插槽中的所有验证者都要向信标链头投出证明。插槽中的每一个委员会，都会尝试将改分片交联。洗牌算法（shuffling algorithm）会根据验证者调整每个委员会能分配到的验证者，且最少有 128 个。** 举例来说，假设全网有 16384 个验证者。那么每个插槽都会被伪随机得分配到 512 个验证者。第一个插槽中的 512 个验证者会被分成 4 个委员会，然后伪随机地派往各个分片，假设这 4 个委员会被派到了 33,55,22,11 这四个分片上。这 512 个验证者都会向第一个插槽执行一次 LMD GHOST 投票。某个委员会中的 128 个验证者尝试交联分片 33 。另一个委员会尝试交联 55，另一个尝试交联 22，最后一个尝试交联 11。 对于第二个插槽，也重复同样的流程。512 个验证者分成 4 组被伪随机得派到 4 个分片上。假设是分配 41，20，17，15。这 512 个验证者都会向第二个插槽执行一次 LMD GHOST 投票，投出它们认为的信标头。各自尝试交联 41，20，17，15。 这个轮回中，剩下的插槽也是不断重复这个过程。在轮回结束时，每一个验证者都已经有过一次投票和交联的机会。目前为止，所有的验证者投票都是基于插槽的，而不是基于轮回。这更像是本地政府的投票，而不是国家级的选举。接下来，所有的验证者还需要为轮回的检查点（checkpoint）投票。 信标链检查点 ------ 每个轮回中的第一个插槽的区块即是检查点。如果这个插槽中没有区块，那么最向前比邻的区块就会成为检查点。所以每一个轮回总会有一个检查点。且一个区块可能会成为多个轮回的检查点。 6 由于第 65 个插槽到第 128 个插槽之间是空的。第二个轮回的检查点本应是第 128 个插槽上的区块。由于该插槽是空的，所以检查点成了第 64 个插槽上的区块。第三个轮回的情况也类似，由于第 192 个插槽为空，第 180 个插槽上的区块成为了第三个轮回的检查点。 在一些文献中，会将检查点成为轮回边界区块（Epoch boundary blocks），它们是同义词。 当一个验证者进行 LMD GHOST 投票时，它也同时会对当前的轮回的检查点进行投票，该检查点也成为目标（target）。这个投票被成为是一个 Caper FFG 投票，而且投票中还会包含再包含之前的一个检查点，成为源头（source）。在上图中，第一个轮回中的验证者会将创世块作为源头，将第 64 个插槽做的区块作为目标。第二个轮回中，同样的验证者会作出同样的投票。只有在被分配到某个插槽上的验证者，会对该插槽投出一个 LMD GHOST 投票，但是，所有的验证者都会对同一个轮回投出 FFG 投票。 绝大多数（Supermajority） ------------------- 当一个投票背后的所支持的验证者的余额超过总余额的 ⅔ 时，这意味着已经产生绝大多数（supermajority）。简单来说，有三个活跃的验证者，两个验证者有 8 个以太币的余额，另一个验证者有 32 个以太币的余额。那么当那个有 32 个以太币余额的验证者投出票后，已经产生了绝大多数，剩下两个验证者的意见已经不再需要。 最终确定性 ----- 当一个轮回结束时，它的检查点投票产生了 ⅔ 绝大多数，那么该检查点就已经是证明（justified）了的。 如果一个检查点 B 被证明，然后它的下一个检查点也被证明，那么检查点 B 就已经被最终确定（finalized）。所以，一个检查点在两个轮回后被最终确认，即 12.8 分钟。 平均来讲，一个用户的交易会在一个轮回中的某个靠近中间的区块。这意味着还有半个轮回才会达到下一个检查点，所以这个交易的最终确定时间为 2.5 个轮回：16 分钟。理想情况下，超过 ⅔ 的交易会在下下轮回的 22 个插槽被投票证明。所以，交易的最终确认时间平均在 14 分钟（16 + 32 + 22 插槽）。客户端需自行确认自己是否需要最终最终确认性。 7 为了简单起见，我们假设所有的验证者都有相同的余额。 在信标链头发生了什么 ---------- 在第 96 个插槽，最后一个边界区块被提议，该区块中还包含了对轮回 2 的检查点证明。当轮回 2 的检查点证明投票达到绝大多数一致时，该轮回的检查点得到证明，同时意味着轮回 1 检查点得到了最终性确认，并且第 32 个插槽之前的所有区块也同时有了最终确认性。当在每个边界区块里提议最终确认性，能被确认最终确认性的区块数量，理论上无限的，可以从创世块一直到当前头。 在信标区块第 1 个插槽到第 32 个插槽间的所有交联，也使得分片链得到了最终一致性。换句话说，当在信标区块中交联的插槽得到最终确认时，分片上的对应区块也得到了最终确认。交联本身不足以使一个分片被最终确定，但是对分片的分叉选择有帮助。 从创世区块到信标链头发生了什么 --------------- 同样以上图为例，我们看看从创世区块开始会发生什么。所有的提议者一共为第 1 个插槽到第 63 个插槽提议了区块，然后它们出现在了链上。对于在轮回 1 中的所有区块，它们的检查点（第 32 个插槽中的区块）累积了来自 55% 的验证者的证明投票。然后，第 64 个插槽上的区块被提议，并且它包含了轮回 1 的检查点的证明。现在，有 70% 的验证者投票证明了轮回 1 的检查点：因此轮回 1 已经被证明（justified）。然后轮回 2 检查点 （第 64 个插槽）上的区块为轮回 2 没有累积到 ⅔ 绝大多数。所以在第 96 个插槽的区块会包含第 2 个轮回的检查点的投票证明。这会导致第 2 个轮回的检查点达到 ⅔ 绝大多数，并且该轮回被证明。第 2 个轮回被证明意味着包含第 1 个轮回以及之前的区块都有了最终确认性。 现在是另一种可能的场景，只考虑到轮回 1 之前的情况。在第 2 个轮回的检查点被提议之前，第 1 个轮回检查点已经包含了 ⅔ 绝大多数。例如，在第 54 个插槽的区块被提议时，第 32 个插槽上的检查点已经达到了 ⅔ 绝大多数。这这种情况下，轮回 1 的检查点是可以在轮回 2 之前被证明的。检查点可以在当前轮回被证明，但是必须至少在之后的下一个轮回才能被最终确定。 当网络拥堵，网络分裂或者存在网络攻击时，一个证明可以会最终确定多个之前轮回的区块。这些场景在 Gasper 论文有讨论。 对于分片和用户来说，能够获取以太坊区块链上的交易的最终确认性是必要的。最终确认性减少了跨分片通信的复杂度。如果没有最终确认性，分片内和跨分片通信时的频繁区块重组，体验将是非常不好的。 证明：深入了解 ------- 一次证明包含了一个 LMD GHOST 投票和一个 FFG 投票。理想情况下，每次轮回所有的验证者都会投出一次证明。每次轮回中验证者有 32 个插槽的时机可以投票上链。在单个轮回中，可能会存在单个验证者的两个投票（译者注：此处应该是包含了对前一个轮回的投票）。当验证在这被分配给它的插槽上投票时，它会被奖励最多。另外，对于[秘密领导选举](https://ethresear.ch/t/low-overhead-secret-single-leader-election/5994)的研究，也旨在降低攻击和贿赂提议者的风险。 在技术实现优化上，一个单独的聚合签名（aggregate signature）可以包含委员会内所有投票的签名。当委员会中一部分投票者的 LMD GHOST 和 FFG 投票相同时，这些投票签名可以被聚合起来。 质押奖惩 ---- 我们将简单讨论验证者激励相关的六个话题： 1. 证明者奖励 2. 证明者惩罚 3. 质押者独有的风险 4. 罚没（slashings）和吹哨者奖励 5. 提议区块奖励 6. 不作为（inactivity）惩罚 7. 如果验证者投出了绝大多数其他验证者都同意的证明（LGM GHOST 和 FFG 投票），那么它就会得到奖励。在阶段 1 时，验证者也可以通过交联区块获得奖励。奖励会在最终性被确认时随之确定。 8. 另一方面，如果验证者没有投票，或者投票的区块不是最终性确认的那个，就会有惩罚。 9. 在阐述其他一些不常见的奖惩场景之前，你也许也想了解成为质押者的风险。作为一个质押者，同时会有接受奖励和收到惩罚的风险，它们是对应的。例如，例如一名验证者可以通过投票得到 10% 的收益，另一个（诚实）验证者在最差的表现下，也可能受到 7.5% 的惩罚。一个经常掉线，并且经常为没有最终确认的区块投票的验证者，可能会损失 ¾ 的质押金。对于一年 365 天来说，有几天或几周离线并不会有特别大的惩罚：离线 36 天目前大约会损失 0.75% 。 10. 罚没是至少 0.5 个以太币，至多可以没收验证者所有质押金的惩罚。一个诚实的，安全的验证者不会因其他恶意验证者的行为而受到罚没。当验证者受到一次罚没时，至少会损失余额的 1/32 ，并且会被停止参与工作。当一个验证者在 8192 个轮回中保持离线时，就会受到罚没惩罚。基于当时被罚没的验证者数量，还会受到额外的惩罚，公式是：`验证者余额 * 3 * 同时被罚没的验证者数量`。也就是说，如果 1/3 的验证者同时受到罚没，那么验证者们会失去所有质押。对罚没行为举报成功的验证者，将会受到吹哨者奖励。 11. 当提议者提出的区块被最终确认时，提议者会收到客观的奖励。一个总是在线且稳定完成工作的验证者，可以得到大约 1/8 的额外奖励（基于总奖励）。当一个罚没出现时，提议者可以通过将罚没证据打包进区块来得到小奖励。在以太坊 2.0 的阶段 0 ，所有的吹哨者奖励都会给予证据区块的提议者。 12. 以太坊 2.0 是一个有着许多机制的系统，并且机制之间有其联系。奖励和惩罚机制联系起来，就肯能会导致不活跃泄露（inactivity leak）惩罚。和上文第三条的惩罚相比，这种惩罚是罕见的。理论上，如果有超过 4 个轮回没有产生最终确定性，那么验证者的不活跃惩罚将会指数级增长，指导下一个检查点被最终确认为止。不活跃惩罚保证了以下收益：如果 50% 的验证者掉线了，区块会在 18 天重新开始最终确认。这种泄露机制确保了有问题的验证者加速退出。在不活跃泄露期间，投票奖励为零，但是提议和吹哨奖励照旧。 罚没 -- 有三种验证者可能会被罚没的条件。重复提议（double proposal），FFG 环绕投票（FFG surround vote），FFG 重复投票（FFG double vote）。 重复提议是指一个提议者在它被分配到插槽中提议了超过一个区块。 FFG 环绕投票是指当 FFG 投票包含或被包含在验证者自己之前已经投出的票中。以下两个例子中，验证者都先在轮回 5 中，以第 32 个插槽为源头，已第 128 个插槽为目标，作出了投票： * 该验证者若在轮回 6 中提出的 FFG 投票是以第 64 个插槽为源头，第 96 个插槽为目标，那么就是被包含 * 该验证者若在轮回 6 中提出的 FFG 投票是以第 0 个插槽为源头，第 160 个插槽为目标，那么就是包含 FFG 重复投票是指，同一个验证者的两次 FFG 投票都包含了同一个插槽为目标/源头。这在链分叉时存在可能。 8 上图中的蓝色箭头表示两次 FFG 投票，左侧以第 128 个插槽为目标，右侧也一样。这样一来，该验证者就进行了一次 FFG 重复投票，这是一次罚没行为。 以下例子为源头相同： 9 在上方箭头中，轮回 1 的检查点是”第 64 个区块“。下方箭头在轮回 1 的检查点是“第 63 个区块”（因为在下面的箭头那边，第 64 个插槽是空的）。所以对于在轮回 0 角度来看，它们的源头是一样的。 这类罚没的初心是希望验证者尽量不要进行链分叉。 一个吹哨验证者，需要提供另一个问题验证者冲突投票的证明。在大量的投票中寻找到冲突投票，对于算法和数据结构来说，都是一种挑战。 完全受掌控的验证者是可以避免被罚没的：它仅需记住它投出过的票。一个诚实的验证者不会因其他验证者的行为而受罚没。只要一个验证者没有签署冲突的证明和提议，它就不会被罚没。 一个验证者可以同时连接多个信标链，用于降低掉线率，增强信任以及抵御 DOS 攻击。如果设置了多个信标链，验证者客户端需要注意不要重复签发消息。 信标链验证者的激活和生命周期 -------------- 每一个验证者需要 32 个以太币来进行激活。当一个用户向以太坊主网质押合约质押了 32 个以太币后，将会激活一个验证者。 当验证者的余额少于 16 个以太币时，信标链会让这个验证者停止工作。在以太坊 2.0 阶段 0 之后，停止工作后剩余的质押可以被提现。 验证者在服务了 2048 个轮回（大约 9 天）后，也可以“自愿退出”。 当验证者退出时（不论自愿还是被强制停止），都会有 4 个轮回的延迟，质押金之后才可以提现。在这 4 个轮候中，这些验证者如果作恶也会被惩罚。一个诚实节点的盈利余额可以在 27 小时左右后提现，而被罚没过的节点需要等待 8192 个轮回（大约 36 天）。 Further technical details are described in A note on Ethereum 2.0 phase 0 validator lifecycle including this flowchart: 在[以太坊 2.0 阶段 0 验证者生命周期备忘](https://notes.ethereum.org/7CFxjwMgQSWOHIxLgJP2Bw#A-note-on-Ethereum-20-phase-0-validator-lifecycle)中，包含了更多细节： 10 上述这些机制限制了一个轮回中能够激活和退出的验证者的数量上限，以防止大量的验证者在短时间内更替。这样可以防止短时间内加入大量恶意验证者。 另外，信标链上还有一个_有效_余额的概念，它的变化会比验证者余额慢，并且支持技术上的优化。 总结 -- 在每个轮回，验证者被均分到每个插槽中，并且别分为数量合适的委员会。一个验证者只会被分配到一个插槽和一个委员会中，然后： * 在每个轮回，所有的验证者都会尝试给同一个检查点做最终确认：FFG 投票 * 所有被分配到插槽里的验证者都会尝试对同一个信标链头投票：LMD GHOST 投票 * 所有被分配到委员会的验证者，都会尝试交联某个特定的分片 采取最优的行为的验证者会收到最多的奖励。 激活信标链至少需要 16384 个创世验证者。验证者的数量可能会因为罚没或者自愿退出而减少，但是同时也可能会进入更多的新质押者。在以太坊 2.0 的阶段 1 之后，预期会有越来越多的验证者进入到网络中。信标链需要至少 262144 个验证者（大约质押 800 万以太币）来使 64 分片不断交联。 目前世界上还没有一个去中心化的系统如此扩容过。如果你对以太坊 2.0 有深入了解的兴趣，可以参阅[这个文档](https://github.com/ethereum/eth2.0-specs)。文档中包含了对信标链的详述，关键参考资源的链接，以及可能会遇到的一些边际情况和问题。目前，最亟待完善的部分是 [P2P 网络](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/p2p-interface.md)。有志之士欢迎到 [ethresear.ch](http://ethresear.ch) 或 Ethereum Magician 论坛参与建设和[挑战](https://notes.ethereum.org/@protolambda/ryNEqN0mL)。 原文链接 ---- [https://ethos.dev/beacon-chain/](https://ethos.dev/beacon-chain/) --- *Originally published on [DavidCai.eth](https://paragraph.com/@davidcai/2-0)*