以太坊基金会推出客户端激励计划

多样化的客户端集合是 Ethereum 网络健康和去中心化的关键。多样性确保了创新在协议的底层持续进行，网络在面对潜在的攻击或错误时具有弹性，并且广泛的参与者参与到对核心协议潜在变更的辩论中。

虽然客户端为网络提供了必不可少的服务（没有它们，就没有网络！），但历史上它们很难捕获价值。最近，这些团队已经有更多途径来构建可持续的业务，但大多数途径都侧重于与主网相邻的机会，而不是主要的 Ethereum 网络。此外，这些机会通常不会与创造的价值成比例地扩展。

为了确保客户端团队有强大的动力来长期维护核心 Ethereum 网络，Ethereum 基金会启动了客户端激励计划（Client Incentive Program）。该计划为客户端团队提供以 ETH 计价的奖励，这些奖励会随着时间的推移而解锁，只要他们继续构建满足主网性能和安全要求的软件。

具体来说，该计划中的团队将总共收到 144 个验证器（4608 ETH），每个验证器在主网上运行。这些补助金的规模既认可了过去几年所做的出色工作，也认可了预计未来会面临的许多开发挑战。有一个团队，其客户端比同行更晚兼容主网，因此以 50% 的股份被纳入该计划。有资格参加该计划的团队按字母顺序排列如下：

• Erigon
• Go-ethereum (geth)
• Hyperledger Besu
• Lighthouse
• Lodestar (50% 股份)
• Nethermind
• Nimbus
• Prysm
• Teku

验证器存款是预先支付的，由团队立即运行，而提款凭证（资金的所有权）将在几年内归属，第一批将在交付 Beacon Chain 提款时解锁。为了获得此批以及后续批次的验证器提款凭证，团队必须继续维护其客户端，满足主网上的性能基准，并通常为实现 Ethereum 社区的路线图做出贡献，因为该路线图会随着时间的推移而发展。在 The Merge 之后，客户端团队还将收到其验证器收取的 transactionm 费用。这与 staking 奖励一起，将开始为团队提供稳定的收入来源。

随着补助金的归属，团队可以自由地使用他们控制的验证器做任何他们想做的事情 - 例如，继续进行 stake 并赚取奖励，提款并清算，或两者的某种组合。另请注意，客户端激励计划是对 EF 提供给这些团队的任何补助金的补充。

该计划详细信息的完整副本已作为附录包含在下面。

Geth 参与此计划是独一无二的，因为他们是 Ethereum 基金会内的一个团队。但是，Geth 团队 - 就像上面列出的其他客户端一样 - 将完全有权决定如何使用这些验证器、赚取的费用以及他们的 ETH 存款（随着补助金的归属）。

该计划的结构使团队与网络的长期健康保持一致，并确保他们有动力构建安全和高性能的软件。它旨在回顾过去，并奖励已经交付生产质量软件的团队。我们希望它能为 Ethereum 核心贡献者的健康激励提供基础。Ecosystem Support Program 始终可用，并且渴望为早期的创新 Ethereum 实现工作（包括新的客户端团队）提供资金。

我们很高兴最终公开分享这项计划，并且我们期待看到更多社区聚集在一起并支持公共产品的方式！

客户端激励计划详情

鉴于计划分配给客户端团队的 ETH 总量（考虑到验证器奖励约为 42,000 ETH，或者截至 2022 年 4 月 4 日，价值超过 1.45 亿美元），我们认识到社区有兴趣了解更多关于分配如何进行，以及如何实现里程碑。

与客户端团队分享的激励计划的完整详情如下。

计划目标和资格

该计划旨在为团队提供长期支持和激励，以维护可靠的客户端和整体健康的网络。

为了使客户端团队有资格参加，他们应该已经在为 Ethereum 的整体开发做出贡献，并打算支持即将到来的权益证明过渡。在整个计划中，团队需要保持一定的性能水平才能获得奖励。更多信息如下。

配置

结构

以下是由“EF”和“客户端”在此计划的生命周期中执行的高级步骤。

1. 进行存款
2. 转移活动签名密钥的控制权
3. 客户端运行节点/验证器
4. 分批释放提款凭证

1. 进行存款

在客户端同意加入该计划后，EF 创建 NUM_VALIDATORS 32-ETH 存款。

客户端激励计划中质押的总 ETH 等于 NUM_VALIDATORS * 32。

与客户端团队协商后，将确定此计划的正式开始日期，团队将在大约 2021 年 10 月 1 日至 The Merge 发生的任何时间之间获得对验证器的控制权。

2. 转移活动签名密钥的控制权

在步骤 1 之后，将有 NUM_VALIDATORS privkeys 映射到由单个助记词控制的验证器存款中的 pubkeys。这些密钥必须安全地转移到客户端团队。

此助记词通过以下方式之一转移到客户端：

1. 通过接收客户端的已知/验证的公钥使用非对称加密（例如 PGP）
2. 在各种平台的 4 个加密呼叫中，每次口头读取 25%
3. 通过其他协商的安全手段

然后，客户端使用助记词生成 NUM_VALIDATORS keystores，并验证每个 privkey 是否按顺序映射到以其名义进行的批量验证器 pubkey 存款。

EF 将助记词保存在冷存储中，以防必须使用活动密钥退出该计划的验证器。

3. 客户端运行节点/验证器

存款已进行；密钥已转移。现在，客户端负责管理相关的验证器，直到提款凭证私钥发布。具体来说，客户端 必须 使用他们自己的软件作为执行引擎或共识层，并且有责任在整个激励期间选择和维护对等客户端的支持。

客户端验证器的性能可以通过查看链上指标来简单地评估，但可能会要求提供额外的节点性能指标。

4. 在满足里程碑后发布成套的提款凭证

当通过转移验证器提款凭证的底层私钥来满足预定义的里程碑时，将会向客户端发布一批验证器。

当发布一批验证器时，这结束了客户端对 EF 的这些验证器的义务。客户端可以自由选择继续验证、退出、提款等。

这些密钥将被 pgp 加密并分批传输。

里程碑

由于不断发展的 Ethereum 路线图的动态特性，在选择里程碑时倾向于简单性。

当启用从 Beacon Chain 提款时，将发布一批凭证，从客户端激励计划 (CIP) 启动到完全发布第一批凭证之间至少间隔一年。

如果客户端激励计划的第一个年度内或之前启用了从 Beacon Chain 提款，则第一批凭证将按月发布，以相等的份额，从启用提款后的第一个月到该计划的一年标记。例如，如果在计划开始后的 6 个月内启用了提款，那么第一批凭证的 1/6 将在第 6、7、8、9、10、11 和 12 个月发布。否则，当启用提款时，将发布第一批凭证。如果客户端继续满足预期，则随后的批次会随着时间的推移而发布。具体来说，里程碑如下：

1. 在启用从 Beacon Chain 提款时 (WITHDRAWALS_ENABLED_TIME) 发布 INITIAL_RELEASE 验证器。
2. 对于 i, num_validators in enumerate(TIMED_RELEASES)，如果客户端操作继续表现出成功的指标，则在 WITHDRAWALS_ENABLED_TIME + (i + 1) * 6_months 时发布 num_validators 验证器。

成功指标

客户端/验证器的性能必须始终满足一系列成功指标才能继续参与此计划。

存入的验证器中的前 NUM_PERFORMANCE 个验证器由 EF 跟踪以评估指标。存入的验证器中的最后 NUM_CANARIES 个验证器可以由客户端自由用于测试、实验版本等。金丝雀验证器 不 需要始终满足成功指标，但仍受 slashing 规则的约束。

指标

以下是客户端必须满足的成功指标：

• 客户端验证器的平均余额不低于 MIN_ACCEPTABLE_BALANCE 余额
• 在任何 METRICS_WINDOW epoch 期间，客户端验证器在链上包含的预期 attestation 至少占 MIN_ATTESTATION_PERCENTAGE 百分比
• 在任何 METRICS_WINDOW epoch 期间，客户端验证器在链上包含的预期区块至少占 MIN_BLOCK_PERCENTAGE 百分比

此外，希望客户端团队积极参与关键网络升级的研发。EF 全权负责确定是否已满足此指标。

最重要的是，EF 希望客户端团队积极致力于确保网络的稳健和健康。EF 认识到在某些情况下，这些指标并非完全由客户端控制（例如，由于另一个客户端的问题，网络的大部分在一段时间内处于脱机状态）。在大多数此类情况下，已选择 METRICS_WINDOW 足够长的时间来解决问题和恢复，但在这种特殊情况下，EF 还会考虑客户端无法控制的外部因素。

注意：在此计划的上下文中，validator top-up 违反规则，通常应避免。如果在某种情况下，top-up 将有利于网络的健康，EF 和客户端可以讨论并相应地重新制定指标/里程碑。

缓刑

如果客户端低于成功指标，则客户端的激励状态将进入缓刑期。在缓刑期间，客户端有 MAX_PROBATION_WINDOW 个 epoch 将指标恢复到成功的标准，并且在缓刑期间，客户端不能发布任何验证器凭证。在缓刑期内花费的时间至少会将任何验证器凭证的发布推迟相同的时间。

如果客户端指标在缓刑状态保持超过 MAX_PROBATION_WINDOW 个 epoch，则 EF 可以自行决定部分或完全将客户端从激励计划中移除，并部分或完全退出客户端的验证器。

Slashing

如果客户端的一个或多个验证器被 slashing，则此类验证器将从激励计划中移除。

如果该事件相对孤立且得到迅速补救，则 EF 可以自行决定将每个被 slashing 验证器最多 16 个被 slashing 的 ETH 放回该计划中，以便在最终里程碑发布。

如果 slashing 事件非常大、疏忽或重复发生，则 EF 可以自行决定部分或完全将客户端从激励计划中移除，并部分或完全退出客户端的验证器。

注意：性能验证器和金丝雀验证器 都 受 slashing 规则的约束。

跨层依赖关系

虽然客户端全权负责确保其操作以高性能且非 slashing 的方式运行，但我们认识到执行层或共识层团队可以做的事情来减轻另一层问题的能力是有限的。具体来说，这意味着我们希望客户端采用有关运行其节点的最佳实践，但在另一层引起广泛问题的情况下不会对其进行惩罚。运行验证器的最佳实践包括：

• 确保客户端可以与大多数/所有主要客户端互操作，至少在金丝雀验证器上；
• 确保客户端的故障与网络的其余部分不相关，这可以通过依赖不同的客户端和托管设置来实现；
• 理想情况下，确保客户端的对等节点分布在 >1 个客户端上，以防出现特定于客户端的问题；
• 确保客户端能够在出现特定于客户端的问题时从一个对等客户端切换到另一个客户端。

条款

该计划是客户端的一个可选的额外激励计划。参与该计划和该计划中可用的锁定资金数量不会影响未来的客户端补助金决定。客户端 可以 在补助金请求中包含一小笔节点基础设施津贴，无论是否参与。

参与此计划的先决条件是成功参与多客户端测试网，并在任何时候通常证明生产就绪。

通常，尤其是在发生与客户端、客户端团队、Ethereum 路线图和/或 Ethereum 主网相关的特殊和不可预见的情况下，EF 全权负责决定如何授予提款凭证和/或随时重组此激励计划的条款。

此类特殊情况包括但不限于以下情况：

• 独立的客户端团队合并为一个
• 客户端团队拆分为两个
• 客户端团队停止维护组件（例如，验证器客户端）或其整个软件
• Ethereum 路线图发生根本性变化，导致里程碑不再反映可实现的目标
• Ethereum 主网在稳定性、最终性或其他正确功能方面存在长期问题
• Ethereum 主网经历有争议的硬分叉

之前的帖子 接下来的帖子

• 原文链接： blog.ethereum.org/2021/1...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～