信标链提议的替代设计方案：基于小型委员会进行链确认

这是信标链的替代设计方案。信标链可以在遥远的将来切换到这种模式（取代目前计划的CBC）。它试图提供以下主要功能：

在正常情况下，它为单个插槽提供了有意义的经济确定性（即类似tendermint的功能）

即使大多数验证者参与了重组单个插槽的阴谋，执行成本也比现在高得多，从而降低了一致性可提取值（CEV）

消除了对LMD鬼分岔选择的高度依赖性，避免了已知的缺陷，并引入复杂的混合分岔选择规则来修复这些缺陷。

可以降低最小存款规模，增加验证器数量

保留经济确定性最终接近非常大的价值（百万以太）这一特征

预备知识

使consensus成为一种异步的、安全的一致性算法（例如，tendermint、Casper-FFG等）。我们假设一致性算法的设计涉及时隙和视图，即当它试图在每个固定的时间段内达成一致性时。我们还假设它以一组加权的验证器（很容易将此功能添加到现有的拜占庭容错一致性算法中）作为输入。

在下面的设计中，我们修改consensus，使最终的验证器集在每个视图中都不同。也就是说，函数get采用conconconsus，而不是验证器集uValidator uu集（view_number:int）——gt;；映射[Validator，int]；（其中int表示验证器余额），此函数可以生成验证器集的新视图。get_uValidator_uuu集应该具有这样一个功能，即验证器集从一个视图到下一个视图最多可以更改1/R，其中R（R=65536）是恢复周期的长度。更正式地说，我们希望：

其中| x |返回x的绝对值之和，diff返回减去每个键值后的值（例如，diff（{A:0.1，B:0.2}，{B:0.1，C:0.3}）={A:0.1，B:0.1，C:-0.3}）。

实际上，两组相邻的验证器之间的差异将包括现有验证器的扣除余额，并且新添加的验证器的比率等于扣除余额的比率。

请注意，仅当前一个验证器未进行最终敲打时，1/R的最大验证器集差异函数才可用。如果前一个验证器集合已经定稿，则conconsus的实例将发生变化，因此get_uvalidator_uu集合函数的内部随机性将完全改变；在这种情况下，两个相邻的验证器组件变得完全不同。

请注意，这意味着如果两个最终定稿视图上的值之间的差异足够大，consenus函数现在可以一起定稿，而不会被没收；这是特意以这种方式设计的，协议的处理方式与Casper FFG今天处理减速惩罚的方式相同。

机制

我们使用两阶段分叉选择：

S选择；最新确定的区块；（新完成的区块）

来自；最新确定的区块；最初，使用其他分叉选择（如LMD ghost）选择块标题

您可以在每个插槽中查看一次consus算法，该算法将基于get_uupost_uu状态（最新的_ufinalized_u块）；生成数据的验证器集生成函数用作输入。有效的提案必须包含最新的uu最终确定的uuu有效的块的子块。只有当该部分在分歧选择中获胜并成为区块链的一部分时，验证者才会准备并投票支持区块提案。

如果一致性在视图中获胜，则视图中建议的块将成为新的最新“最终”块，在接下来的几轮中更改验证程序集。如果失败，它需要在下一个插槽或视图中进行下一次尝试。

注意：插槽应始终等于当前视图编号加上每个先前成功完成的验证器集的视图编号之和。

我们受到以下处罚：

共识算法确定的常规没收罚金

减速处罚：如果区块链无法最终确定，则所有未参与最终确定的验证者都将受到处罚。这个惩罚是在R/2插槽后将余额减半。

FFG 替代方案：单个- sLoot-epoch 的 Casper FFG

上述设计的另一种选择是使用Casper FFG，但使epoch的长度等于插槽。Casper FFG的工作机制是不同的，因为它不试图阻止同一委员会完成一个区块及其子区块。为了适应这种差异，我们需要实现（I）1/4而不是1/3的安全阈值，以及（II）这样的规则：如果一个插槽最终确定，验证器集最多可以替换1/4而不是完全替换。

请注意，在这种设计中，实现一个插槽（但不超过一个插槽）的重组在理论上没有成本。此外，在图表末尾，“达到最大最终确定性的时段”的数量需要增加4倍。

特性

如果某个区块最终确定，且其竞争区块将最终确定，则需要出现以下情况之一：

委员会有问题，而且≥ 1/3的核查人员因双重确定另一个区块而被没收

最近的委员会离线。在R/3档位之后，委员会最终可以完成另一个档位，而不会在完全洗牌后被没收。然而，这带来了严重的惩罚(≥ 攻击者余额的1/3）

在任何情况下，即使要回滚最终块，至少需要烧掉dispose_size*commit_size/3（存款金额*委员会成员数/3）ETH。如果我们设置commit_size=131072（ETH2委员会每个插槽的最大验证器数量理论上为400万），那么该值为1398101 ETH。

该计划的其他一些重要特点包括：

无论有多少验证者存款，在处理数据时，验证者的负载都是稳定的；提交每个插槽的大小（委员会大小）事务

验证者的负担变得更低，因为他们可以在没有被要求加入委员会时睡觉

休眠验证器可以在不牺牲安全性的情况下快速退出和取款。

扩展：用小委员会进行链确认

如果为了提高效率和规模，我们必须缩小委员会的范围，我们可以进行以下调整：

我们把“finalization (最终敲定)” 更名为“confirmation (确认)”，以反映单个确认不再代表真正的最终确定性

与选择最新确认块不同，我们选择确认块链头最长的确认块（但拒绝回滚除提交前瞻确认的块以外的块，因此提交前瞻确认代表真正的最终确定性）

获取验证程序集；您应该只使用状态信息，而不是；委员会前瞻；确认以前的信息

视图的数量应该是插槽的数量（这样可以更容易地推断出相同的验证器集试图在不同的链上达成一致意见的情况，这只能在某些确认被破坏时发生）

该方案保留了上述所有特征，但也引入了一个新特征：如果一个块获得多个确认（例如，该块最终确定，并且链的子块获得k-1确认，因为总共k个连续确认将影响该块），撤销区块需要违反多个委员会的共识保证。这允许来自多个委员会的安全级别累积：回滚K确认需要提交大小*存款大小*K/3 ETH，以实现K=提交。只有在前瞻之后，委员会才会有差异。

还需要注意的是，在任何情况下，为了P2P子网的安全性，前瞻机制都是值得使用的，因此设计它是一个好主意，如果需要，可以让客户端决定如何处理确认回滚问题。

具体数值的例子