首页 > 区块链技术

以太坊 2.0 Phase 0 的奖惩力度模拟

区块链技术 2 4 月 22, 2024 0 区块链315

目前处于以太坊 2.0 上线的第一阶段，即 Phase 0 。一旦 2.0 的所有阶段都部署完成，交易量将得到巨幅提升。为实现这一目标，以太坊即将采取两大主要的升级举措：分片和权益证明。升级之后，以太坊网络的经济机制、共识机制和运行机制都将发生变化。

## **简介** ConsenSys Codefi 正在构建构建针对贸易和金融的区块链操作系统，促进全球市场步入“金融 2.0” 时代。为实现这一目标，最关键的部分在于如何创建并利用原生数字资产，并以此作为激励手段将网络的去中心化程度最大化，成为新型金融产品和市场的可靠支柱。实现 “以太坊 2.0” 以及向权益证明的过渡是我们的首要任务。我们很乐于分享相关的经验、知识，并探讨包括代币经济在内的相关话题。 对以太坊 1.0 区块链的巨大需求有时会导致用户体验不佳，比如，交易要等一段时间上链，交易手续费（Gas）波动较大。长期以来，高度可扩展性 —— 将交易的处理能力从当前的每秒 15 笔左右提高到上千笔 —— 都是以太坊的目标之一。 我们目前处于以太坊 2.0 上线的第一阶段，即 Phase 0 。一旦 2.0 的所有阶段都部署完成，交易量将得到巨幅提升。为实现这一目标，以太坊即将采取两大主要的升级举措：分片和权益证明。升级之后，以太坊网络的经济机制、共识机制和运行机制都将发生变化。我们将在下文给出详细介绍。 ## **激励** 以太坊 1.0 是采用工作量证明机制的区块链：矿工要计算出计算难题的解才能挖出一个区块，解决难题的概率与其所提供的计算机运算力成正比，与整条链上的难题难度值成反比。如果这名矿工成功挖出了一个区块，就可以获得 [2 ETH](https://media.consensys.net/the-constantinople-hard-fork-what-you-need-to-know-d438a91dec3f) 的奖励以及交易费。工作量证明的核心就是如此。你可以根据上一个区块的难度值来[估算出整个网络的算力大小](https://ethereum.stackexchange.com/a/21397/1281)，再进一步推算出你自己挖出下一个区块的概率，以此预测自己的成本。 在共识机制方面，以太坊 2.0 的技术性较强。 如果你看到这里，想要有个粗略的参考的话，请跳到下文的 “实用的网络增发率估测法” 一节。 本文的目的是让读者大致了解以太坊 2.0 的权益证明实现，及其奖惩制度。我们会分解一下经济激励，快速评估权益可能会带来的投资回报率（ROI）。最后，我们会介绍 Codefi 的质押即服务（Staking-as-a-Service）团队正在构建的模拟，以便读者能更加细致地理解这个主题。 ## **诚实验证者** 只要你向以太坊 1.0 区块链上部署的保证金[合约（deposit contract）](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/deposit-contract.md)存入资金，不论是一笔还是多笔，等到总金额等于或大于 32 ETH 之后，你就有资格成为以太坊 2.0 信标链上的验证者。 你可以无限制地往保证金合约中转入押金。但是，**有效余额（effective balance）**，即，信标链在运行时对你的权益分量的认定，是有上限的。换言之，你的余额可以高达 1000 ETH ，但是你所能获得的奖惩只取决于有效余额，而有效余额的上限是 32 ETH。 另一方面，如果身为验证者的你遭到了惩罚，致使余额降至 16 ETH 以下，就会触发[强制/非自愿退出](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/beacon-chain.md#registry-updates)。 所谓 [*诚实验证者*](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/validator.md) 就是运行客户端的个体，客户端是根据信标链规范来编写的，会避免采取违反协议的行动。 需要强调的是，**惩罚（penalty）与罚没（slashing）是完全不同的**。前者指的是，验证者因（在某些参数内）投错票或离线而被扣除部分余额。如果有验证者被发现在生成见证消息之时触犯了罚没条件，它就会被强制退出验证者队伍，在排队退出的这段时间内，每一个 epoch（时段）都会扣除部分余额作为罚金。 ## **论以太坊 2.0 的出块和共识** 信标链运行的基本时间单位叫 **slot（时隙）**。就像心跳一样，每 12 秒就是一个 slot ，选出一名验证者来提议区块。一旦区块生成并广播出去，由一些验证者组成的见证者委员会（attester committee）就会对该区块投票，以决定是否将其纳入区块链。 “委员会” 的设计是为了分配验证者到不同的验证工作上，让每位验证者都能在每个 epoch（即，32 个 slot ）期间投一次票。委员会里的验证者之间相互通信，能够将他们的投票消息（“见证消息”）聚合到一起。如果在一个 slot 内被选中的区块提议者没有提出区块，这个 slot 即被认定为**被跳过的 slot （skipped slot）**。在这种情况下，就会基于前一个 slot 中的最后一个区块进一步创建提议和见证消息。 提议者的工作是生成一个 TA 认为可以添加到链顶部的区块。至于哪条链才算主链，则靠 [LMD GHOST ](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md)分叉选择算法决定：在所有获得投票的分叉中，以递归的方式找到权重最大的那个，然后选择这个分叉。当验证者在见证某个区块之时，他们实际上是在对这个区块所在的分叉投赞成票。 为了实现区块链的最终确定性（确保状态不会回滚），诚实的验证者会在他们的见证消息中提供另外两个投票，来推动 [以太坊 2.0 版本](https://github.com/ethereum/research/blob/master/papers/ffg%2Bghost/paper.pdf)的 [Casper the Finality Gadget（FFG](https://arxiv.org/abs/1710.09437)）算法运行：一个投的是最新的合理化（justified） epoch（作为**来源检查点**），另一个投的是最新的 epoch 边界（作为**目标检查点**）。 ![](https://img.learnblockchain.cn/2020/03/24_/374500769.jpg) - 来源：ConsenSys Codefi Analysis - 在[每个 epoch 开始之时](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/beacon-chain.md#epoch-processing)，都会计算见证消息中的投票情况。如果有一个最新的合理化 epoch 获得了绝对多数（达到 2/3 及以上）票， 检查点（checkpoint）就会推进到该 epoch。依据某些规则，该 epoch 的父 epoch 乃至祖先 epoch 都将得到最终确定。 如果系统在连续几个 epoch （目前的规范定为 4 个）内都未能实现最终确定性，则信标链上的所有验证者都会遭受[不作为惩罚（inactivity penalty）](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/beacon-chain.md#rewards-and-penalties-1)。这里还有很多可以展开的地方！如果你想要进一步了解细节的话，可以参见 Vitalik 等人写的[《 将 GHOST 与 Casper 结合》](https://github.com/ethereum/research/blob/master/papers/ffg%2Bghost/paper.pdf) 、以太坊基金会发布的 [Phase 0 信标链技术规范](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/beacon-chain.md)、Danny Ryan 写的关于[ Phase 0 的文章](https://notes.ethereum.org/@djrtwo/Bkn3zpwxBvhttps://github.com/ethereum/research/blob/master/papers/ffg%2Bghost/paper.pdf)，以及 Joseph Chow 写的[一篇信标链入门详解](https://ethos.dev/beacon-chain/)（编者注：见文末超链接《Eth2 信标链：你首先该知道的事》，在描述信标链运行上比本文更为详尽）。 ## **奖惩措施** ### **罚没** 被[罚没](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/beacon-chain.md#slash_validator)意味着验证者会在将来的某个时间点被强制要求退出信标链，在退出之前会不断地遭到惩罚。 如果出现以下三种情况，验证者就会遭到罚没： 1. 作为[区块提议者](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/beacon-chain.md#proposer-slashings)，在同一个 slot 内提议两个不同的信标链区块。 2. 作为见证[者](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/beacon-chain.md#attester-slashings)，在 FFG 投票中，新见证消息所指向的两个 epoch 恰好 “包围” 自己在之前的见证消息所指向的两个 epoch（称 “环绕投票”）。 3. 作为见证者，所发出的多条见证消息明明指向同一个目标检查点，来源检查点却不同（称 “双重投票”）。 验证者只有在被发现之后才会触发罚没流程。作为举报者的验证者需要创建并传播包含违规行为证据的特殊消息，让区块提议者将其打包到区块中。打包的区块提议者和举报者都会获得奖励。 这一点在规范中并不明显，但是在 Phase 0 阶段，[只有提议者能获得举报奖励](https://github.com/ethereum/eth2.0-specs/issues/1631) —— 即，**提议者会获得完整的罚没奖励**（8/8）。 | 举报奖励 | | | 举报者 | 被罚没的验证者的有效余额 / 512 * 7/8 | | 打包举报消息的区块提议者 | 被罚没的验证者的有效余额 / 512 * 1/8 | - 来源：ConsenSys Codefi Analysis - > 假设 > > * *[常数](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/beacon-chain.md#rewards-and-penalties) 最低罚没金额系数 = 32* > * *[常数](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/beacon-chain.md#rewards-and-penalties) 举报者奖励系数 = 512* > * *[常数 ](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/beacon-chain.md#rewards-and-penalties)提议者奖励系统 = 8* 违规的验证者会遭到罚没，可在之后长达 **36 天**的 epoch 集合（8192 个 epoch）内取回自己的余额。 此外，被罚没的验证者将遭受以下惩罚： 1. 提议者在将举报信息打包进区块之时，该验证者会被扣除[基础罚金](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/beacon-chain.md#slash_validator)。 2. [在每个 epoch 开始之时](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/beacon-chain.md#rewards-and-penalties-1)，该验证者会因无法参与 head/FFG 投票而遭到惩罚，直到他度过退出的排队等待期为止。 3. 在从举报信息被打包进区块，到可取回余额的这段时间内，该验证者会被扣除[特殊罚金](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/beacon-chain.md#slashings)。 特殊罚金与同期遭到罚没的其他验证者人数成正比。特殊罚金最高可与违规验证者的有效余额持平。 | 罚没力度 | | | 罚没事件被处理时 | 被罚没的验证者的有效余额 / 32 | | 完全退出前的每个 epoch | 3 * 基础奖励（base reward） | | 特殊惩罚 | 有效余额 * min(3* 近期被罚没的余额总和， 总余额)/总余额 | - 来源：ConsenSys Codefi Analysis - > 假设 > > ![](https://img.learnblockchain.cn/2020/03/24_/591747936.png) > > * *[常数 ](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/beacon-chain.md#rewards-and-penalties)罚没金额系数 = 32* > * *[常数](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/beacon-chain.md#rewards-and-penalties) 基础奖励系数 = 64* > * *[常数](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/beacon-chain.md#constants) 每个 epoch 的基础奖励 = 4* > * *[常数](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/beacon-chain.md#gwei-values) 有效余额增量 = 1* ### **epoch 处理** 每个 epoch （除了创世 epoch （GENESIS）之外，每个 epoch 包含 32 个 slot）在开始之时都需要完成以下事项： 1. 确认此前区块链的合理性和最终确定性 2. 结算见证者的奖惩额度 3. 更新验证者注册表 4. 结算被罚没的验证者的特殊罚金（参见上文） 5. 完成一些最终更新（计算有效余额、重置等） 验证者在上一个 epoch 的状态必须是**活跃的（active）**，才能获得奖励 和/或 惩罚。在退出系统之前，遭到罚没的验证者也会进入这个流程，但是只会在进行 FFG 相应结算时受到惩罚。 如果验证者在上一个 epoch 是活跃的，**但是没有投票**，就会因为无法配对 FFG 投票而遭到**惩罚**。**验证者不会因为离线而遭到罚没。** ![](https://img.learnblockchain.cn/2020/03/24_/840773697.jpg) | 在 epoch 开始时的奖惩结算 | | | | | 奖励 | 惩罚 | | 匹配（Matching）来源检查点投票 | 基础奖励 * 在见证余额 / 激活余额总量 | 基础奖励 | | 匹配来源检查点和目标检查点投票 | 基础奖励 * 在见证余额 / 激活余额总量 | 基础奖励 | | 匹配来源检查点和顶端（head）投票 | 基础奖励 * 在见证余额 / 激活余额总量 | 基础奖励 | | 来源检查点的提议者 | 基础奖励 / 8 * 区块见证者数量 | 无 | | 最早向来源检查点投票的见证者 | 7 /8 * 基础奖励 * 1 / 打包延迟（inclusion delay） | 无 | | 不作为惩罚 —— 系统超过 4 个 epoch 没有敲定检查点 | 无 | 4 * 基础奖励 | | 不作为惩罚 —— 在触发时，验证者既没有提交见证消息，也不能匹配目标检查点投票 | 无 | 有效余额 * 确定性延迟 / 2^23 | - 来源：ConsenSys Codefi Analysis - > 假设 > > ![](https://img.learnblockchain.cn/2020/03/24_/18317984.png) > > * *最终确定性延迟 = 上一个 epoch - 得到最终确定的 epoch* > > * *在见证余额 = 未被罚没的见证者余额的总和*（译者注：参考上下文表述，此处的余额应均指 “有效余额”。） > > * *[常数](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/beacon-chain.md#rewards-and-penalties) 基础奖励系数 = 64* > > * *[常数](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/beacon-chain.md#constants) 每个 epoch 的基础奖励 = 4* > > * *[常数](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/beacon-chain.md#rewards-and-penalties) 提议者奖励系数 = 8* > > * *[常数](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/beacon-chain.md#time-parameters) 不作为惩罚的最小 epoch 跨度值 = 4* > > * *[常数](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/beacon-chain.md#constants) 不作为惩罚系数 = 2^25* > ![](https://img.learnblockchain.cn/2020/03/24_/751749966.jpg) - 来源：ConsenSys Codefi Analysis - ## **实用的网络增发量估测法** 我们利用新学到的知识来对**任意一个 epoch** 的奖惩金额进行粗略估算吧。我们想讲得简单一点，先从两个参数开始。 | 全网 ETH 质押量 | 500,000 | | 在线概率 | 95% | - 来源：ConsenSys Codefi Analysis - 第一个参数很好理解，第二个参数指的是一个随机选择的验证者在满足联网或其他条件的情况下能够参与信标链（主机已经开启）的概率。 如果我们假设信标链上的**所有**验证者的余额和有效余额都等于 **32 ETH** ，并使用上文的在线概率（online probability），我们就可以得到以下数据： | 上一个 epoch 中的在线验证者数量 | 14,843 | | 上一个 epoch 中的离线验证者数量 | 781 | | 基础奖励数量（Gwei） | 22, 897 | - 来源：ConsenSys Codefi Analysis - 现在我们可以计算出**每个验证者**的奖惩情况了，如下表所示： | FFG 奖励 | 3 * 基础奖励 * 在见证余额 / 活跃验证者余额总量 | 65,253 | | FFG 惩罚 | 3 * 基础奖励 | 68,891 | | 区块提议者激励 | 基础奖励 / 8 * 区块见证者数量 | 1,325,163 | | 见证者激励 | 7/8 * 基础奖励 * 1 / 打包延迟 | 19,525 | - 来源：ConsenSys Codefi Analysis - 在计算最后两个激励措施上，我们还需要做一些工作：根据设想，区块见证者是位于 slot 的在线验证者，在每个 epoch 内都呈均匀分布状态；为了计算出验证者激励，我们先要定义预期值概率树，[然后将得到的几何级数进行收敛](https://github.com/hermanjunge/eth2-reward-simulation/blob/master/assumptions.md#attester-incentives)，因为该奖励与见证消息的发出时间和上链时间的差值成反比。 我们看到，提议者激励远远超过其他三个数值。回顾一下知识点：每一个 slot 都会从信标链上的所有验证者中选出一个提议者，随着总质押量越来越多，成为提议者的概率就会降低。换言之，在一个 epoch 内，**只有 32/n 的验证者能成为提议者**。 *还要注意的是，我们不会对遭到罚没的验证者及其举报者或是不作为延迟进行任何假设或计算。* 如果我们将各个值分别乘以在线/离线验证者的人数，再将得到的值相加，就可以得出一个基于初始条件的估计值。 因此，一个 epoch 内所有奖励减去所有惩罚得到的净增量为 1,247,117,399 Gwei。 也就是说，在总质押量为 50 万个 ETH ，且在线概率为 95% 的情况下，**每个 epoch （6.4 分钟）会生成大约 1.25 ETH 的奖励**。 依据 95% 的在线概率，我们还可以进一步算出，总质押量不同的情况下，每个 epoch 产生的奖励变化情况，并绘制成图表。 ![](https://img.learnblockchain.cn/2020/03/24_/833331019.jpg) - 来源：ConsenSys Codefi Analysis - ## **总结** 我们应该利用**每个 epoch** 产生的奖励计算出年奖励估计值吗？ 在给出肯定的回答之前，我们先来考虑以下因素： ### **余额** 在每个 epoch 内，余额都会以各种不同的方式对 ETH 的创建产生影响。例如，如果验证者的**有效余额**达到了上限（32 ETH）并以此获得奖励，则余额中超出的部分不会影响下一个 epoch 的计算。此外，由于有效余额的变更存在[迟滞现象](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/beacon-chain.md#final-updates)，实际上每位验证者都会 “损失” 一部分 ETH 。 还要考虑以下几个情况：可能会有验证者因有效余额低于下限（16 ETH）而遭**驱逐**，可能会有人向以太坊 1.0 保证金合约发送质押金而成为验证者，可能会有质押者触发[自愿退出](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/beacon-chain.md#voluntary-exits)机制。 ### **罚没** 建立罚没操作的模型需要花费大量时间。首先，需要考虑以太坊 2.0 客户端的开发者和质押服务商对罚没条件的理解和所采取的回避模式。另一方面，我们只能猜测系统中诚实参与者的比例；以及违规行为被发现、广播并打包进区块的概率。 ### 可能性 我们已经提到了诚实参与者的比例和违规者被举报的概率。我们来想一下，可以利用哪些不同的方法来衡量并推测一个节点是否在线、连接良好并正常工作，它的见证消息是否会被按时聚集起来并打包进区块，它是否能看到大多数节点所看到的 slot 。 信标链是一个[复杂的自适应系统](https://en.wikipedia.org/wiki/Complex_adaptive_system)。即使我们很好地理解了这个系统的各个部分，这也不能保证我们能很好地理解整个系统。 深入理解一件事物的第一步是选择研究的方法和工具。通过对验证者及其在一些初始条件、设想和限制条件下与信标链的交互进行[建模和模拟](https://github.com/hermanjunge/eth2-reward-simulation)，我们就能更深入地了解权益证明实现的复杂性。 **致谢** *本文由 ConsenSys Codefi 质押即服务平台的架构师兼技术总监 Herman Junge 撰写。* *特此感谢 Joseph Chow、Ben Edgington、Sylvain Laurent、Diederik Protolambda Loerakker、Tim Lowe、Danny Ryan、Alex Stokes 和 Kuhan Tharmananthar 对原稿的评论。* （完） **原文链接:** [https://codefi.consensys.net/blog/rewards-and-penalties-on-ethereum-20-phase-0](https://codefi.consensys.net/blog/rewards-and-penalties-on-ethereum-20-phase-0) **作者:** ConsenSys **翻译&校对:** 闵敏 & 阿剑

简介

ConsenSys Codefi 正在构建构建针对贸易和金融的区块链操作系统，促进全球市场步入“金融 2.0” 时代。为实现这一目标，最关键的部分在于如何创建并利用原生数字资产，并以此作为激励手段将网络的去中心化程度最大化，成为新型金融产品和市场的可靠支柱。实现 “以太坊 2.0” 以及向权益证明的过渡是我们的首要任务。我们很乐于分享相关的经验、知识，并探讨包括代币经济在内的相关话题。

对以太坊 1.0 区块链的巨大需求有时会导致用户体验不佳，比如，交易要等一段时间上链，交易手续费（Gas）波动较大。长期以来，高度可扩展性 —— 将交易的处理能力从当前的每秒 15 笔左右提高到上千笔 —— 都是以太坊的目标之一。

我们目前处于以太坊 2.0 上线的第一阶段，即 Phase 0 。一旦 2.0 的所有阶段都部署完成，交易量将得到巨幅提升。为实现这一目标，以太坊即将采取两大主要的升级举措：分片和权益证明。升级之后，以太坊网络的经济机制、共识机制和运行机制都将发生变化。我们将在下文给出详细介绍。

激励

以太坊 1.0 是采用工作量证明机制的区块链：矿工要计算出计算难题的解才能挖出一个区块，解决难题的概率与其所提供的计算机运算力成正比，与整条链上的难题难度值成反比。如果这名矿工成功挖出了一个区块，就可以获得 2 ETH 的奖励以及交易费。工作量证明的核心就是如此。你可以根据上一个区块的难度值来估算出整个网络的算力大小，再进一步推算出你自己挖出下一个区块的概率，以此预测自己的成本。

在共识机制方面，以太坊 2.0 的技术性较强。

如果你看到这里，想要有个粗略的参考的话，请跳到下文的 “实用的网络增发率估测法” 一节。

本文的目的是让读者大致了解以太坊 2.0 的权益证明实现，及其奖惩制度。我们会分解一下经济激励，快速评估权益可能会带来的投资回报率（ROI）。最后，我们会介绍 Codefi 的质押即服务（Staking-as-a-Service）团队正在构建的模拟，以便读者能更加细致地理解这个主题。

诚实验证者

只要你向以太坊 1.0 区块链上部署的保证金合约（deposit contract）存入资金，不论是一笔还是多笔，等到总金额等于或大于 32 ETH 之后，你就有资格成为以太坊 2.0 信标链上的验证者。

你可以无限制地往保证金合约中转入押金。但是，有效余额（effective balance），即，信标链在运行时对你的权益分量的认定，是有上限的。换言之，你的余额可以高达 1000 ETH ，但是你所能获得的奖惩只取决于有效余额，而有效余额的上限是 32 ETH。

另一方面，如果身为验证者的你遭到了惩罚，致使余额降至 16 ETH 以下，就会触发强制/非自愿退出。

所谓 诚实验证者 就是运行客户端的个体，客户端是根据信标链规范来编写的，会避免采取违反协议的行动。

需要强调的是，惩罚（penalty）与罚没（slashing）是完全不同的。前者指的是，验证者因（在某些参数内）投错票或离线而被扣除部分余额。如果有验证者被发现在生成见证消息之时触犯了罚没条件，它就会被强制退出验证者队伍，在排队退出的这段时间内，每一个 epoch（时段）都会扣除部分余额作为罚金。

论以太坊 2.0 的出块和共识

信标链运行的基本时间单位叫 slot（时隙）。就像心跳一样，每 12 秒就是一个 slot ，选出一名验证者来提议区块。一旦区块生成并广播出去，由一些验证者组成的见证者委员会（attester committee）就会对该区块投票，以决定是否将其纳入区块链。

“委员会” 的设计是为了分配验证者到不同的验证工作上，让每位验证者都能在每个 epoch（即，32 个 slot ）期间投一次票。委员会里的验证者之间相互通信，能够将他们的投票消息（“见证消息”）聚合到一起。如果在一个 slot 内被选中的区块提议者没有提出区块，这个 slot 即被认定为被跳过的 slot （skipped slot）。在这种情况下，就会基于前一个 slot 中的最后一个区块进一步创建提议和见证消息。

提议者的工作是生成一个 TA 认为可以添加到链顶部的区块。至于哪条链才算主链，则靠 LMD GHOST 分叉选择算法决定：在所有获得投票的分叉中，以递归的方式找到权重最大的那个，然后选择这个分叉。当验证者在见证某个区块之时，他们实际上是在对这个区块所在的分叉投赞成票。

为了实现区块链的最终确定性（确保状态不会回滚），诚实的验证者会在他们的见证消息中提供另外两个投票，来推动 以太坊 2.0 版本的 Casper the Finality Gadget（FFG）算法运行：一个投的是最新的合理化（justified） epoch（作为来源检查点），另一个投的是最新的 epoch 边界（作为目标检查点）。

  • 来源：ConsenSys Codefi Analysis -

在每个 epoch 开始之时，都会计算见证消息中的投票情况。如果有一个最新的合理化 epoch 获得了绝对多数（达到 2/3 及以上）票， 检查点（checkpoint）就会推进到该 epoch。依据某些规则，该 epoch 的父 epoch 乃至祖先 epoch 都将得到最终确定。

如果系统在连续几个 epoch （目前的规范定为 4 个）内都未能实现最终确定性，则信标链上的所有验证者都会遭受不作为惩罚（inactivity penalty）。这里还有很多可以展开的地方！如果你想要进一步了解细节的话，可以参见 Vitalik 等人写的《 将 GHOST 与 Casper 结合》 、以太坊基金会发布的 Phase 0 信标链技术规范、Danny Ryan 写的关于 Phase 0 的文章，以及 Joseph Chow 写的一篇信标链入门详解（编者注：见文末超链接《Eth2 信标链：你首先该知道的事》，在描述信标链运行上比本文更为详尽）。

奖惩措施

罚没

被罚没意味着验证者会在将来的某个时间点被强制要求退出信标链，在退出之前会不断地遭到惩罚。

如果出现以下三种情况，验证者就会遭到罚没：

  1. 作为区块提议者，在同一个 slot 内提议两个不同的信标链区块。
  2. 作为见证者，在 FFG 投票中，新见证消息所指向的两个 epoch 恰好 “包围” 自己在之前的见证消息所指向的两个 epoch（称 “环绕投票”）。
  3. 作为见证者，所发出的多条见证消息明明指向同一个目标检查点，来源检查点却不同（称 “双重投票”）。

验证者只有在被发现之后才会触发罚没流程。作为举报者的验证者需要创建并传播包含违规行为证据的特殊消息，让区块提议者将其打包到区块中。打包的区块提议者和举报者都会获得奖励。

这一点在规范中并不明显，但是在 Phase 0 阶段，只有提议者能获得举报奖励 —— 即，提议者会获得完整的罚没奖励（8/8）。

| 举报奖励 | | | 举报者 | 被罚没的验证者的有效余额 / 512 7/8 | | 打包举报消息的区块提议者 | 被罚没的验证者的有效余额 / 512 1/8 |

  • 来源：ConsenSys Codefi Analysis -

假设

  • 常数 最低罚没金额系数 = 32
  • 常数 举报者奖励系数 = 512
  • 常数 提议者奖励系统 = 8

违规的验证者会遭到罚没，可在之后长达 36 天的 epoch 集合（8192 个 epoch）内取回自己的余额。

此外，被罚没的验证者将遭受以下惩罚：

  1. 提议者在将举报信息打包进区块之时，该验证者会被扣除基础罚金。
  2. 在每个 epoch 开始之时，该验证者会因无法参与 head/FFG 投票而遭到惩罚，直到他度过退出的排队等待期为止。
  3. 在从举报信息被打包进区块，到可取回余额的这段时间内，该验证者会被扣除特殊罚金。

特殊罚金与同期遭到罚没的其他验证者人数成正比。特殊罚金最高可与违规验证者的有效余额持平。

| 罚没力度 | | | 罚没事件被处理时 | 被罚没的验证者的有效余额 / 32 | | 完全退出前的每个 epoch | 3 基础奖励（base reward） | | 特殊惩罚 | 有效余额 min(3* 近期被罚没的余额总和， 总余额)/总余额 |

  • 来源：ConsenSys Codefi Analysis -

假设

  • 常数 罚没金额系数 = 32
  • 常数 基础奖励系数 = 64
  • 常数 每个 epoch 的基础奖励 = 4
  • 常数 有效余额增量 = 1

epoch 处理

每个 epoch （除了创世 epoch （GENESIS）之外，每个 epoch 包含 32 个 slot）在开始之时都需要完成以下事项：

  1. 确认此前区块链的合理性和最终确定性
  2. 结算见证者的奖惩额度
  3. 更新验证者注册表
  4. 结算被罚没的验证者的特殊罚金（参见上文）
  5. 完成一些最终更新（计算有效余额、重置等）

验证者在上一个 epoch 的状态必须是活跃的（active），才能获得奖励 和/或 惩罚。在退出系统之前，遭到罚没的验证者也会进入这个流程，但是只会在进行 FFG 相应结算时受到惩罚。

如果验证者在上一个 epoch 是活跃的，但是没有投票，就会因为无法配对 FFG 投票而遭到惩罚。验证者不会因为离线而遭到罚没。

| 在 epoch 开始时的奖惩结算 | | | | | 奖励 | 惩罚 | | 匹配（Matching）来源检查点投票 | 基础奖励 在见证余额 / 激活余额总量 | 基础奖励 | | 匹配来源检查点和目标检查点投票 | 基础奖励 在见证余额 / 激活余额总量 | 基础奖励 | | 匹配来源检查点和顶端（head）投票 | 基础奖励 在见证余额 / 激活余额总量 | 基础奖励 | | 来源检查点的提议者 | 基础奖励 / 8 区块见证者数量 | 无 | | 最早向来源检查点投票的见证者 | 7 /8 基础奖励 1 / 打包延迟（inclusion delay） | 无 | | 不作为惩罚 —— 系统超过 4 个 epoch 没有敲定检查点 | 无 | 4 基础奖励 | | 不作为惩罚 —— 在触发时，验证者既没有提交见证消息，也不能匹配目标检查点投票 | 无 | 有效余额 确定性延迟 / 2^23 |

  • 来源：ConsenSys Codefi Analysis -

假设

  • 最终确定性延迟 = 上一个 epoch - 得到最终确定的 epoch

  • 在见证余额 = 未被罚没的见证者余额的总和（译者注：参考上下文表述，此处的余额应均指 “有效余额”。）

  • 常数 基础奖励系数 = 64

  • 常数 每个 epoch 的基础奖励 = 4

  • 常数 提议者奖励系数 = 8

  • 常数 不作为惩罚的最小 epoch 跨度值 = 4

  • 常数 不作为惩罚系数 = 2^25

  • 来源：ConsenSys Codefi Analysis -

实用的网络增发量估测法

我们利用新学到的知识来对任意一个 epoch 的奖惩金额进行粗略估算吧。我们想讲得简单一点，先从两个参数开始。

| 全网 ETH 质押量 | 500,000 | | 在线概率 | 95% |

  • 来源：ConsenSys Codefi Analysis -

第一个参数很好理解，第二个参数指的是一个随机选择的验证者在满足联网或其他条件的情况下能够参与信标链（主机已经开启）的概率。

如果我们假设信标链上的所有验证者的余额和有效余额都等于 32 ETH ，并使用上文的在线概率（online probability），我们就可以得到以下数据：

| 上一个 epoch 中的在线验证者数量 | 14,843 | | 上一个 epoch 中的离线验证者数量 | 781 | | 基础奖励数量（Gwei） | 22, 897 |

  • 来源：ConsenSys Codefi Analysis -

现在我们可以计算出每个验证者的奖惩情况了，如下表所示：

| FFG 奖励 | 3 基础奖励 在见证余额 / 活跃验证者余额总量 | 65,253 | | FFG 惩罚 | 3 基础奖励 | 68,891 | | 区块提议者激励 | 基础奖励 / 8 区块见证者数量 | 1,325,163 | | 见证者激励 | 7/8 基础奖励 1 / 打包延迟 | 19,525 |

  • 来源：ConsenSys Codefi Analysis -

在计算最后两个激励措施上，我们还需要做一些工作：根据设想，区块见证者是位于 slot 的在线验证者，在每个 epoch 内都呈均匀分布状态；为了计算出验证者激励，我们先要定义预期值概率树，然后将得到的几何级数进行收敛，因为该奖励与见证消息的发出时间和上链时间的差值成反比。

我们看到，提议者激励远远超过其他三个数值。回顾一下知识点：每一个 slot 都会从信标链上的所有验证者中选出一个提议者，随着总质押量越来越多，成为提议者的概率就会降低。换言之，在一个 epoch 内，只有 32/n 的验证者能成为提议者。

还要注意的是，我们不会对遭到罚没的验证者及其举报者或是不作为延迟进行任何假设或计算。

如果我们将各个值分别乘以在线/离线验证者的人数，再将得到的值相加，就可以得出一个基于初始条件的估计值。

因此，一个 epoch 内所有奖励减去所有惩罚得到的净增量为 1,247,117,399 Gwei。

也就是说，在总质押量为 50 万个 ETH ，且在线概率为 95% 的情况下，每个 epoch （6.4 分钟）会生成大约 1.25 ETH 的奖励。

依据 95% 的在线概率，我们还可以进一步算出，总质押量不同的情况下，每个 epoch 产生的奖励变化情况，并绘制成图表。

  • 来源：ConsenSys Codefi Analysis -

总结

我们应该利用每个 epoch 产生的奖励计算出年奖励估计值吗？

在给出肯定的回答之前，我们先来考虑以下因素：

余额

在每个 epoch 内，余额都会以各种不同的方式对 ETH 的创建产生影响。例如，如果验证者的有效余额达到了上限（32 ETH）并以此获得奖励，则余额中超出的部分不会影响下一个 epoch 的计算。此外，由于有效余额的变更存在迟滞现象，实际上每位验证者都会 “损失” 一部分 ETH 。

还要考虑以下几个情况：可能会有验证者因有效余额低于下限（16 ETH）而遭驱逐，可能会有人向以太坊 1.0 保证金合约发送质押金而成为验证者，可能会有质押者触发自愿退出机制。

罚没

建立罚没操作的模型需要花费大量时间。首先，需要考虑以太坊 2.0 客户端的开发者和质押服务商对罚没条件的理解和所采取的回避模式。另一方面，我们只能猜测系统中诚实参与者的比例；以及违规行为被发现、广播并打包进区块的概率。

可能性

我们已经提到了诚实参与者的比例和违规者被举报的概率。我们来想一下，可以利用哪些不同的方法来衡量并推测一个节点是否在线、连接良好并正常工作，它的见证消息是否会被按时聚集起来并打包进区块，它是否能看到大多数节点所看到的 slot 。

信标链是一个复杂的自适应系统。即使我们很好地理解了这个系统的各个部分，这也不能保证我们能很好地理解整个系统。

深入理解一件事物的第一步是选择研究的方法和工具。通过对验证者及其在一些初始条件、设想和限制条件下与信标链的交互进行建模和模拟，我们就能更深入地了解权益证明实现的复杂性。

致谢

本文由 ConsenSys Codefi 质押即服务平台的架构师兼技术总监 Herman Junge 撰写。

特此感谢 Joseph Chow、Ben Edgington、Sylvain Laurent、Diederik Protolambda Loerakker、Tim Lowe、Danny Ryan、Alex Stokes 和 Kuhan Tharmananthar 对原稿的评论。

（完）

原文链接: https://codefi.consensys.net/blog/rewards-and-penalties-on-ethereum-20-phase-0
作者: ConsenSys
翻译&校对: 闵敏 & 阿剑

区块链技术网。

  • 发表于 2020-03-22 23:44
  • 阅读 ( 994 )
  • 学分 ( 24 )
  • 分类：以太访2.0
打赏微海报分享

近期文章

热门

标签

相似推荐

评论