Prysm 中 Safe Head 的快速确认规则（上）
本文档重点介绍我们在 Prysm 中实现的快速确认算法，这是更广泛探索的第一部分。我们称之为第一部分，是因为这项工作仍处于早期阶段——目前已有白皮书和安全证明，但尚未经过全面审查，而且据我们所知，目前还没有其他客户端实现该算法。与所有实现一样，算法中也存在一些 bug 和错误。在本文中，我们将介绍我们在 Prysm 中的实现，并分享在主网运行过程中的一些有趣观察。
参考：
- 以太坊 PoS 确认规则，作者：Aditya Asgaonkar，Francesco D'Amato、Roberto Saltini、Luca Zanolini 和 Chenyi Zhang 参与贡献
- 以太坊共识协议的快速确认规则，作者：Aditya Asgaonkar、Francesco D'Amato、Roberto Saltini、Luca Zanolini 和 Chenyi Zhang
- Aditya Asgaonkar 和 Terence 编写的Prysm 快速确认实现代码
- Terence 的Prysm Forkchoice 实现讲解
背景
什么是安全头？
在以太坊上，安全区块是指被认为不会发生短期重组的最新区块，这意味着它不太可能因分叉而被其他区块取代。当一个区块植根于一个已证明的检查点并获得足够多的验证者证明时，它最终会变得安全。传统上，客户端将最新的已证明的检查点（也是 LMD GHOST 分叉选择算法的起点）称为安全区块，或将最新的未实现的已证明的检查点（无论是否已在链上实现）称为安全区块。安全区块允许链上的消费者安全地推进，而无需等待需要更长时间才能实现的最终性。
如何获得安全头？
执行层客户端（例如 Geth、NethermindETC）公开专用的 RPC 端点来查询区块头、安全区块头以及最终确定的执行区块。区块链实时数据的消费者可以决定如何根据这些信息采取行动：
- 最终确定的头部：
eth_getBlockByHash("finalized", ...) - 安全头：
eth_getBlockByHash("safe", ...) - 头部：
eth_getBlockByHash("latest", ...)
安全头是如何传递给EL的？
安全区块头通过引擎 API从共识层传递到执行层，具体来说，是在区块头更新期间通过engine_forkchoiceUpdated方法传递。不同的 CL 客户端对安全的理解可能有所不同，例如使用 1.) 最新的合理检查点，而其他客户端（例如默认的 Prysm）则使用 2.) 最新的未实现合理检查点。在本文中，我们将探讨一种替代方案：使用 3.)快速确认的区块作为安全区块。
{ "jsonrpc" : "2.0" , "method" : "engine_forkchoiceUpdatedV2" , "params" : [ { "headBlockHash" : "0x..." , "safeBlockHash" : "0x..." , ← this is the safe head "finalizedBlockHash" : "0x..." } , { "timestamp" : "0x..." , "random" : "0x..." , "suggestedFeeRecipient" : "0x..." } ] , "id" : 1 }什么是快速确认区块？
快速确认区块是指在同步网络（证明消息到达时间少于 8 秒）和有限的对抗能力下，即使在最终确定之前，也极有可能保留在规范链上的区块。快速确认规则为用户和应用程序提供了一种启发式方法，使其能够在区块提议后的几秒到一分钟内将其视为已确认。它通过检查The Block是否已获得足够多的可观察验证者投票并满足特定的安全阈值来做到这一点。与通过罚没条件保证不可逆性的最终性不同，快速确认基于网络条件和验证者行为，提供了更快但更弱的保证。
Prysm 实现
本节概述了 Prysm 在实验性PR中实现的安全区块头。由于该实现仍处于积极开发阶段，可能会有所变更，您可以直接跳至测试观察部分。为了启用快速确认作为安全区块，必须设置两个标志：
- 选择安全块模式：
-safe-block=fast-confirmation（默认值：unrealized-justified） - 指定拜占庭Threshold：
-fast-confirmation-byzantine-threshold=33（默认值：33）- 这里的拜占庭指的是恶意行为，例如拒绝证明、在冲突的子树上投票ETC。
快速确认时间表
在时隙n的第 0 秒，在理想情况下，Prysm 信标节点会定期调用UpdateHead更新头信息。从n - 1的第n-1秒开始，它开始收集、验证和统计及时块时隙n-1证明信息。如果一切顺利， n-1的The Block可以在 8 秒内快速确认（假设拜占庭Threshold低于 30%，我们稍后会解释为什么会这样计算）。
修改 forkchoice 和 node 对象
Forkchoice F o r k c o i c e对象现在缓存一个新字段：safe head root。
节点N o d e添加了新的方法，用于计算从起始 slot 到当前 slot 可能获得的最大支持率。该方法基于委员会权重和 slot/epoch 结构：
- 如果范围在单个 epoch 内，则返回总支持度为： CommitteeWeight × SlotCount C o m m i t t e e W e i g h t × S l o t C o n t 。
- 如果范围跨越整个时期，则返回一个时期的权重： CommitteeWeight * 32 C o m m i t t e e W e i g h t ∗ 32 。
- 如果它进入一个新的纪元而没有完全跨越它，它会根据每个纪元段中的时隙数按比例计算支持。
在更新最佳后代时，该函数会接收当前槽的秒数和当前链的委员会权重
- 如果前一个插槽的最佳子项被快速确认，它会递归地将BestConfirmedDescendant Best ConfirmedDescendant设置为最深的确认子项。
- 如果未确认，则直接分配最佳子项或将BestConfirmedDescendant Best ConfirmedDescendant设置为nil nil 。
这确保了快速确认状态在链中向后流动。
最后，为了确定一个节点是否被确认，它会将未应用提议者提升的节点权重与安全Threshold进行比较。逻辑检查如下：
- 该节点的槽位必须早于当前槽位。
- 它计算最大可能的支持度和提议者提升权重。
- 确认条件为：
voteOnlyWeight > ( maxPossibleSupport + proposalerBoostWeight ) / 2 + maxPossibleSupport / 3仅投票权重> (最大可能支持+提议者支持权重) / 2 +最大可能支持/ 3
在哪里：
提议者BoostWeight = (委员会权重*提议者得分Boost ) / 100提议者Boost权重= (委员会权重∗提议者得分Boost ) / 100
观察＃1
（以下所有数据均在 2025 年 4 月 13 日至 2025 年 4 月 14 日期间获取）
满意情况：对于在时隙n准时提出的有效区块，到时隙n+1开始时，The Block通常仅通过订阅聚合证明子网就能获得大约97%的验证者支持。
在此图中，假设从 slot n开始， node0在 slot n-1处阻塞， node1在 slot n-2:
区块延迟情况：如果n区块的The Block延迟发布，那么到n+1开始时，它将无法获得足够的支持。在这种情况下，快速确认通常需要3 个以上的时间，前提是后续区块会重组延迟发布的区块。
观察＃2
正如预期的那样，信标槽重组比安全块重组发生得更频繁，在过去 12 小时内观察到 8 次信标重组和 0 次安全块重组。
观察＃3
正如预期，快速确认（安全）区块的出现频率高于未实现的合理化（安全）区块，而后者又高于最终确认区块。这反映了确认速度与安全保障强度之间的权衡——快速确认提供了更快的保障，但保障强度较低；而最终确认提供了最强的保障，但延迟时间较长。
这是按小时显示的视图，其中绿色代表已确认的时期，黄色代表未实现的已确认时期，蓝色代表快速确认的时期，橙色代表最新时期。如图所示，快速确认的时期紧跟最新时期，而已确认和未实现的已确认时期则往往滞后：
这是 30 分钟的视图：
观察＃4
最新的头部槽和安全槽之间的差异通常在每小时视图中平均为 2 个槽，在 5 分钟窗口内范围为 2 到 4 个槽：
观察＃5
当使用 33% 的拜占庭Threshold时，单个 slot 内就无法确认区块。这是由于更严格的确认条件：
vote > (max_support + pb_score) / 2 + max_support * 0.33直观地讲，这意味着The Block需要：
- 50%（LMD GHOSTThreshold）
- 20%（提议者增幅的一半）
- 33%（拜占庭Threshold）
总计达到103% ，超过了 100% 的最大可能投票权重。
为了将Threshold推广到多个时隙，我们将其建模为：
threshold = ((n * 0.5 ) + 0.2 + (n * 0.33 )) / n其中n是The Block提出以来的时隙数。此公式包含以下内容：
-
n * 0.5：LMD 投票要求 n * 0.33：拜占庭行为的安全缓冲区0.2：固定提议者提升贡献
随着n增加，提议者提升的影响力逐渐减小，Threshold收敛到0.83。这意味着，要在两个时隙内快速确认一个区块，它必须获得至少 93% 的委员会总权重。
| 自提案以来的槽数（n） | LMD 投票 (n * 0.5) | 提议者提升 (/2) | 拜占庭Threshold（n * 0.33） | 全部的 | 归一化Threshold（总计/n） |
|---|---|---|---|---|---|
| 1 | 0.50 | 0.20 | 0.33 | 1.03 | 1.03 |
| 2 | 1.00 | 0.20 | 0.66 | 1.86 | 0.93 |
| 3 | 1.50 | 0.20 | 0.99 | 2.69 | 0.89 |
| 4 | 2.00 | 0.20 | 1.32 | 3.52 | 0.88 |
| 5 | 2.50 | 0.20 | 1.65 | 4.35 | 0.87 |
正如此图所示，上图显示了来自n-1区块，其中黄色表示需要快速确认的Threshold，绿色表示未应用提议者提升的节点权重。该区块始终低于Threshold，且始终短 2% 到 4%，因此无法确认。下图中，The Block来自n-2 ，其权重比Threshold高 1% 到 2%，因此可以确认。
观察#6
在 25% 的拜占庭Threshold下，我们可以在不到一个 slot 的时间内（大约 8 秒）确认一个区块。重新查看一下头 slot 减去安全 slot 的图表，以及节点 0 权重与安全Threshold图表。
后续事项
安全区块的重组永远都是不可接受的。例如，如果交易所依赖安全区块处理提现，重组可能会导致双重支付。在我们的实验中，我们观察到了安全区块的重组，但仅限于初始同步到链头期间。这似乎更多的是一个实现问题。一个潜在的解决方案是，仅当The Block具有当前 slot 时间戳时才应用快速确认算法（h/t potuz），否则，回退到使用未实现的合理算法来确保安全。
- 今天，Prysm 的 PR 中已经提到了这一点
论文中描述的快速确认安全证明将受益于更多人的关注。该证明接受的审核和审查越多越好——参见第1点。安全区块的重组可能会很危险，具体取决于它们在实践中的使用方式。
如果有人有任何疑问或反馈，请随时联系我们。我们将继续努力，确保此实现可用于生产环境，进行长期测试，并发布包含最新发现的第二部分报告。
