以太坊 2.0：公开单领导人选举（PSLE）+秘密机率后备选举（SPBE）

公开单领导人选举（PSLE）+秘密概率后备选举（SPBE）（具体来说，还有其他不错的翻译，请给所有神灵留言）

为什么在ETH 2中只有一个***？

在ETH 2的每个插槽（而不是多个插槽）中，对提议的块进行一次***选举有助于减少“额外工作”和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攻击。

尽管有许多其他协议工具可用于阻止提议者（TOR，cloudflare / etc，使用哨兵节点体系结构等），但是其中许多解决方案都不令人满意（例如，更高的延迟，中心化的依赖性，更高的基础架构成本等），这对于爱好者/节点守护者来说尤其重要（我们拥有的验证节点的类对于去中心化ETH 2是必不可少的）。

（2）通常，可以通过使***选择一个秘密（SSLE）来解决，因此，如果您不攻击所有节点，则无法对特定节点执行有针对性的攻击，但是SSLE难以实施并且尚未准备好良好的生产。

建议的解决方案

鉴于目前秘密单身领导人选举目前难以执行且尚未准备就绪，并且（1）始终是一个边际问题，因此我们建议将公开单身选举（PSLE）+秘密概率后备选举（SPBE）设置为混合解决方案，以提高网络从攻击/脱机提议者中恢复的能力。即使SSLE准备就绪，SSLE + SPBE仍可以用作针对（1）的附加弹性。

PSLE组件的运行方式与今天的大提议者主持人选举完全相同，并且SPBE提供了备份，以防所选的大提议者不在其工作中出现。

SPBE会通过可在整体提案中证明的本地机密（例如广告位签名和时代的随机种子）来概率地选择一组备用提案人。可以采用与聚合选择（请参见is_aggregator）非常相似的方式进行选择，该聚合选择具有用于目标备份数量的可调参数-TARGET_BACKUPS_PER_SLOT。

如果在本地未看到来自公共负责人的阻止提议，则选定的备用提议者通过指定的时隙创建并广播部分阻止（例如ETH 2 stage 0配置中的1/6）。节点不考虑/广播早期备份。

当在LMD GHOST中打破平局时，公共***建议给与优先考虑，然后交替提议提案，然后按词典序排列。在正常情况下，公共***会按时提交提案。座位委员会将提案视为提案负责人，而不考虑任何备份。当公共领导块按时/可用时，自然会选择分叉点。 [请记住，在插槽S + 1之前，我们将不考虑插槽S的证明，因此，该建议是权重为0的叶节点，建议使用***块具有并列优势]

具体规格变更

将backup_proposer_proof：BLSSignature添加到BeaconBlock

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

DeFis_alid_leader_proposal（状态：信标状态，块：信标块）-gt;布尔：返回（块.proposer_index == get_beacon_proposer_index（状态）和块.backup_proposer_proof == BLSSignature（）＃emptybytes）DeFis_alid_backup（ededed（当前状态）纪元，DOMAIN_BEACON_PROPOSER）+ int_to_bytes（state.sLoot，length = 8）signing_root = compute_signing_root（seed，get_domain（state，DOMAIN_BACKUP_PROPOSERstate）proposer＃indexer（）publicleadERCanmakebackupproposalblock.proposer_index（）。propproper_index（）。 ，block.backup_proposer_proof））DeFiprocess_block_header（state：BeaconState，block：BeaconBlock）-gt;无：＃correct–index＃correct .proposer_index == get_beacon_proposer_index（state）assert（is_alid_leader_proposal（state，block）oris_alid_backup_property …

记住要选择存储中哪些块是fork中的“ leader”块。例如，添加is_leader：Dict [Root，bool]存储在on_block中，并建议使用leader（True）或backup（False）跟踪每个块。

修改分叉选项的get_head，以使is_leader和第二个以字典顺序平均分配。

DeFiget_head（store：Store）-gt; Root：… whileTrue：…＃Sortbylatestattestingbalancewithtierokenleaderblocksthenlexicographicalhead = max（children，key = lambdaroot：（get_latest_attesting_balance（store，root），is_leader [root]，＃tiebreakbyleaderroot，＃tiebreakbylexicographic）

将其他职责添加到“验证过程”指南中。如果您未看到***的有效建议，则备份块将广播到SECONDS_PER_SLOT // 6的插槽中。

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

论坛

及时的替代提议者

我们可能会担心，对于备份提议者，请在任何选定时间段的开始时及时创建和广播备份建议，而不是等待是否确实需要备份。这主要是在每个插槽的带宽-〜1 + TARGET_BACKUPS_PER_SLOT块方面损害网络。由于前叉选项的修改，当***处于活动状态时，不会导致更高的前叉度。

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

攻击者替代提议者

我们可能担心替代提议者攻击***以增加将替代提议者包括在规范链中的机会变得合理。

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

有几件事要注意

1.对SPBE的这种攻击将退化为一条生命链，这是件好事。

2.进行这种攻击的动机可以说是非常低的，因为获得备份建议的实际机会只是TARGET_BACKUPS_PER_SLOT的一小部分，因此在实验中，这只是相对而言是部分的奖励小（相比于关税）。

3.为了进一步减少备份方案的额外攻击动机，我们可以使备份方案仅接受方案奖励// backup_DISCOUNT_FACTOR，其中backup_DISCOUNT_FACTORgt; = 2。随着数量的增加，备份建议将更多地成为一种利他行为，以帮助提高网络的生命力（我认为大多数诚实的验证者都愿意这样做），而不是仅靠获利行为，可能会损害正常运行。

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

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

尽管我想在那里讨论这种潜在算法，但我仍然主张不要在阶段0中引入SPBE，以免干扰阶段0的交付。如果目标DoS成为主网上的一个实际问题，我们可以将其用作选项。此外，将PSLE + SPBE声明为公共选项可能从一开始就防止了此类攻击。

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