Public Single Leader Election (PSLE) + Secret Probabilistic Backup Election (SPBE)（具体还有其他好的翻译，请各路大神留言）

为什么在eth2中只有单一领导者？

在eth2的每个插槽中（相对于多个插槽），对提案区块进行单一领导者选举有助于减少“额外工作”和p2p消息开销，以及减少与“多个”潜在区块头相关的不必要的分叉。

每个插槽都有多个潜在负责人，这将导致委员会内的不同认证票数，从而降低可聚合性，增加p2p消息开销并增加请求方区块大小。

在阶段1+中增加了分片后，分片提案中的多个领导者将使这一不同的证明问题（每个插槽的BEACON_PROPOSERS_PER_SLOT * SHARD_PROPOSERS_PER_SLOT选项）更加复杂，这不仅会增加开销，而且会降低给定插槽中交叉链接成功的可能性 。如果插槽中的分片提议者的数量为SHARD_PROPOSERS_PER_SLOT，并且每个选择者具有相同的选择概率，则证明将在不同的分片提议中粗略地分割，并且任何SHARD_PROPOSERS_PER_SLOT> 1在大多数情况下都无法获得2/3交叉链接投票 。

单一领导人选举的弊端

无论是公开的还是秘密的单一领导人选举（分别是PSLE和SSLE）都有一个明显的缺点：对于特定时段的活跃性存在单一故障点。

这种活跃性失败可能有两种形式（通过共识协议无法区分）：

• 验证节点不在线，连接不良，或者不生成区块

• 验证节点已被恶意攻击者专门删除

（1）最基本的-如果验证节点只是离线的，那就没办法。反对（1）是一个大问题，该论点是在整体提案期间脱机会产生巨大的机会成本（约占总奖励的1/8），但由于这个原因，我们仍然希望有一定数量的空插槽。

考虑到验证节点信息泄漏（即频繁的共识消息的广播）因此对于典型节点的去匿名化在许多情况下是微不足道的，PSLE使得区块提议者在其指定的插槽时间附近易受目标DoS攻击。

尽管有许多额外的协议工具可供区块提议者使用l (TOR, cloudflare/etc, 使用哨兵节点体系结构等)但这些解决方案中的许多并不令人满意（例如更高的延迟、集中的依赖性、更高的基础设施成本等），而这对于爱好者/节点守卫者来说尤为重要（我们持有的一类验证节点对权力下放eth2至关重要）。

（2）一般来说，可以通过使该领导人选举秘密（SSLE）来解决，因此如果不攻击所有节点，则无法对特定节点执行有针对性的攻击，但是SSLE很难实现，而且还没有准备好投入生产。

建议解决方案

鉴于秘密的单一领导人选举在当前很难进行，尚未准备就绪，且（1）始终是一个边缘问题，我们提出公共单一选举（PSLE）+秘密概率备份选举（SPBE）作为一种混合解决方案，以提高网络对攻击/离线区块提议者的恢复能力。即使SSLE准备好了，SSLE+SPBE仍然可以作为抵抗（1）的额外弹性。

PSLE组件的运行方式与今天的区块提议者领导人选举完全相同，而SPBE则提供了一个备份，以防所选区块建议者没有出现在他们的工作中。

SPBE通过一个可以在区块提议中被证明的局部秘密（例如插槽的签名和纪元的随机种子）来概率地选择一组备用提议者。此选择可以通过与聚合选择非常相似的方式完成（请参阅is_aggregator），其中有一个用于目标备份数的可调参数– TARGET_BACKUPS_PER_SLOT。

如果尚未在本地看到来自公共领导人的区块提议，则选定的备份提议者通过指定的插槽创建并广播部分区块（例如eth2阶段0配置中的1/6）。节点不考虑/广播早期备份。

在LMD GHOST中打破平局时，公共领导建议优先考虑，然后是备用区块提议，然后按字典顺序打破。在正常情况下，公共领导人按时提交提案，该席位的委员会将把该提案视为提案的负责人，而不考虑任何备份，在公共领导人区块准时/可用的情况下，自然会集中选择分叉点。[请记住，在插槽 S+1之前，我们不会考虑插槽 S的证明，因此提案是权重为0的叶节点，给leader-block建议以平局优势]

具体规格变更

将backup_proposer_proof：BLSSignature添加到BeaconBlock

修改process_block_header 1中的提议者断言，以允许备份提议：

def?is_valid_leader_proposal(state:?BeaconState,?block:?BeaconBlock)?->?bool:????return?(????????block.proposer_index?==?get_beacon_proposer_index(state)????????and?block.backup_proposer_proof?==?BLSSignature()??#?empty?bytes????)def?is_valid_backup_proposal(state:?BeaconState,?block:?BeaconBlock)?->?bool:????#?Similar?to?leader?selection,?backups?are?only?known?within?current?epoch????seed?=?get_seed(state,?epoch,?DOMAIN_BEACON_PROPOSER)?+?int_to_bytes(state.slot,?length=8)????signing_root?=?compute_signing_root(seed,?get_domain(state,?DOMAIN_BACKUP_PROPOSER))????proposer?=?state.validators[block.proposer_index]????return?(????????#?public?leader?cannot?make?backup?proposal????????block.proposer_index?!=?get_beacon_proposer_index(state)????????and?bls.Verify(proposer.pubkey,?signing_root,?block.backup_proposer_proof)????)def?process_block_header(state:?BeaconState,?block:?BeaconBlock)?->?None:????...????#?Verify?that?proposer?index?is?the?correct?index????#?--?REMOVE?--?assert?block.proposer_index?==?get_beacon_proposer_index(state)????assert?(????????is_valid_leader_proposal(state,?block)????????or?is_valid_backup_proposal(state,?block)????)????...

记住在fork选择存储中哪些区块是“ leader”区块。例如添加is_leader：Dict [Root，bool]存储在on_block中添加时以领导者（True）或备份（False）提议跟踪每个区块。

修改分叉选项的get_head，以首先由is_leader和第二个按字典顺序平分。

def?get_head(store:?Store)?->?Root:????...????while?True:????????...????????#?Sort?by?latest?attesting?balance?with?ties?broken?leader?blocks?then?lexicographically????????head?=?max(????????????children,????????????key=lambda?root:?(????????????????get_latest_attesting_balance(store,?root),????????????????is_leader[root],??#?tie?break?by?leader????????????????root,??#?tie?break?by?lexicographical?sort????????????)????????)

将备用职责添加到“验证程序”指南中。如果尚未看到领导者的有效提议，则备份区块将在SECONDS_PER_SLOT // 6广播到插槽中。

修改process_randao，process_attestation和slash_validator以使用block.proposer_index（而不是get_beacon_proposer_index）进行提议者查找，因为get_beacon_proposer_index仅适用于领导者。这将需要更改每个函数的功能签名以确保传递信息。

讨论区

及时的备用提议者

我们可能会担心，对于一个备份提议者来说，在任何选定的时段开始时及时地创建和广播备份建议，而不是等待是否真的需要备份。这主要是在带宽方面损害了网络-每个插槽?1 + TARGET_BACKUPS_PER_SLOT个区块。是由于fork选项的修改，当leader处于活动状态时，不会导致更高程度的分叉。

可以添加有关gossipsub beacon_block主题中的其他约束，以确保不传播早期备份块（在1/6时隙之前），并且如果看到前导块，则将其完全删除。在大多数网络遵循这种传播规则的情况下，通常情况下，当领导者处于活动状态并且等待时间很短时，即使备用提议者尝试分发数据块，它们也将在一两跳之内被丢弃。

攻击者备用提议者

我们可能担心备用提议者攻击领导者以增加备用提议者被纳入规范链的机会变得合理。

在验证器内部创建此额外的攻击媒介/诱因是合理的考虑。如果没有SPBE，则想要破坏提议者活动的集合通常仅限于外部攻击者，而SPBE则创建了新的验证者内部动机来进行分析。

有几件事需要注意

1. 这种对SPBE的攻击会退化为一个活链，这很好。

2. 进行这种攻击的动机可以说很低，因为实际获得备份建议的机会只是TARGET_BACKUPS_PER_SLOT的一小部分，因此，在实验中，这仅值已经相对较小的部分奖励（与attes职责相比）。

3. 为了进一步降低备份方案的额外攻击诱因，我们可以使备份方案只接受方案奖励//backup_DISCOUNT_FACTOR，其中backup_DISCOUNT_FACTOR>=2。随着这个数字的增加，备份建议将变得更像是一种利他主义行为，以帮助网络的活跃性（我认为大多数诚实的验证者都愿意执行），而不是一种单独盈利的行为，可能会导致破坏正常运行。

也就是说，在PSLE+SPBE中，备份提议者可以进行的攻击是主要关注的问题，应该进一步讨论和分析。

共识复杂性和第0阶段交付

尽管我想在那里讨论这种潜在的算法，但我还是主张不要在阶段0中引入SPBE，以免干扰阶段0的交付。如果有针对性的DoS成为主网上的真正问题，我们可以将其作为选择。此外将PSLE + SPBE声明为公共选项可能从一开始就可以阻止这种攻击。

根据进一步的讨论，观察到的主网攻击以及SSLE的进展，我们可以考虑将其集成到后续阶段/分支中。