Solana 乐观确认机制深度解析vote(X,S) 原语、乐观惩罚条件与安全性证明【免费下载链接】solanaWeb-Scale Blockchain for fast, secure, scalable, decentralized apps and marketplaces.项目地址: https://gitcode.com/GitHub_Trending/so/solana乐观确认Optimistic Confirmation是 Solana 在传统 PoH 出块与最终确定性之间引入的低延迟安全层当网络中超过 2/3 质押权重就同一区块投出范围覆盖该区块的投票时客户端即可将该区块视为乐观确认并可以近乎确定性地相信它不会被回滚——除非有验证者被惩罚。本文以仓库提案文档 optimistic_confirmation.md 为骨架结合 optimistic-confirmation-and-slashing.md 及 core/src/optimistic_confirmation_verifier.rs、core/src/cluster_info_vote_listener.rs 等源码实现完整讲解其投票原语、可惩罚的乐观冲突条件、切换证明Switching Proof以及形式化安全证明并对照当前仓库中的实际实现说明该机制如何在共识与 RPC 层落地。读完本文你将掌握乐观确认的精确数学定义、验证者何时会被判定为可惩罚、以及该机制如何在保证不回滚的同时把活性liveness代价控制在可接受范围。一、动机在最终确定性之前获得可信的快速确认Solana 的共识采用 PoHProof of History驱动的 slot 出块机制区块最终被根化rooted需要经历确认与锁定期。在 optimistic-confirmation-and-slashing.md 中设计者给出了引入乐观确认的出发点验证者必须持续沿着自己当前所在的分叉投票除非它能构造出证明其当前分叉可能无法达到最终确定性。构造该证明的方式是收集除自身分叉以外所有分叉上的有效投票。如果这些有效投票所代表的质押权重超过1/3 XX为协议被破坏时至少会被惩罚的质押比例那么当前分叉可能无法累积到2/3的最终确定性。验证者对该证明做哈希生成一个见证 witness并随自己对另一分叉的投票一起提交。但若已有2/3的投票指向同一个区块则任何验证者都不可能构造出上述证明因此没有任何验证者能够合法切换分叉该区块将最终被确认。简言之乐观确认把2/3 多数转化为一把锁——多数锁定之后少数既无法合法离开也无法证明多数可能失败从而实现了不可能回滚。二、核心原语带引用槽位的投票vote(X, S)原文档首先对投票结构做了形式化扩展。所有投票都写成vote(X, S)X引用槽位reference slot即该验证者在本分叉上最近一次带切换证明proof of switching投票所对应的最新祖先槽位。S被投票的槽位及其锁定期的有序列表(s, s.lockout)。关键约束只要验证者连续投出的票彼此互为后代都在同一条分叉链上X就保持不变一旦验证者投出一个不是前一张票后代的槽位sX就会被重置为新的s。也就是说X记录的是这条链上最后一次明确切换的起点从而让所有后续投票都能被追溯到同一个分叉参考点。约定S.last vote.last表示S中的最后一个槽位。由此可以定义每个投票的范围Range(vote(X, S)) [X, S.last]即该投票覆盖的槽位区间从引用槽位到最新投票槽位。三、乐观惩罚Optimistic Slashing条件为了防止验证者骑墙——即在两个范围重叠的分叉上同时投票——原文档定义了Optimistic Slashing惩罚条件。直觉如下如果一个验证者提交了vote(X, S)那么它不应在另一个与之重叠的分叉上投过票。更具体地说它不应再投出vote(X, S)使得区间[X, S.last]与[X, S.last]重叠且X ! X。以下 ASCII 图展示了这种可惩罚的双重投票vote(X, S)与vote(X, S)------- | | --------- -------- | | | | | ------- | | | | | | | ------ | | | | X | | | | | | ------ | | | | ------ | | | | | | X | | | | ------ | | | | | | | ------ | | | | | | S.last | | | | ------- | ------ | | s | | | | ------ | | | ------ | | S.last | | | | -------图中即为可惩罚的投票对vote(X, S)与vote(X, S)示例为什么这是可惩罚的图中对S.last的投票必然晚于对S.last的投票由于锁定期机制更高的投票必然更晚发出。因此投票序列必然是X ... S.last ... S.last。这意味着验证者在投出S.last之后、投出S.last之前曾在某个槽位s S.last X处切回了另一条分叉。既然如此对S.last的投票就应该以s作为引用槽位而不是X——因为s才是这条链上最后一次切换。形式化地对同一验证者的任意两个不同投票vote(X, S)与vote(X, S)必须满足以下全部条件否则验证者将被惩罚X S.lastX S.lastS中的所有s彼此互为祖先/后代S中的所有s亦彼此互为祖先/后代各自链内一致若X X则S与S必须是父子关系S是S的父链或反之若X X则必须满足X S.last、S.last S.last并且对S中所有s都有s lockout(s) X若X X则必须满足X S.last、S.last S.last并且对S中所有s都有s lockout(s) X。最后两条规则的本质就是两个投票的范围不得重叠。一旦重叠说明验证者在同一段历史区间内在两条不同分叉上都有投票记录属于双重投票行为。四、切换证明Switching Proof合法离开当前分叉的唯一途径验证者可以合法切换其引用槽位但必须附带切换证明SP(old_vote, new_vote)其中old_vote是验证者此前的最近一次投票。切换证明必须引用old_vote从而把该旧投票的范围记录下来使得该范围内任何其他冲突切换都变成可惩罚的。同时切换本身仍必须尊重锁定期。一个有效的切换证明需要表明网络中超过 1/3 的质押权重在old_vote.last处仍处于锁定状态。证明是一组元素(validator_id, validator_vote(X, S))的列表要求列表中所有validator_id的质押之和 1/3对每个(validator_id, validator_vote(X, S))存在S中的某个槽位s使得s既不是validator_vote.last与old_vote.last、new_vote.last的共同祖先s不是validator_vote.last的后代s s.lockout() old_vote.last即该验证者在old_vote.last时刻仍被锁定在槽位s上。在缺少有效切换证明的情况下切换分叉属于可惩罚行为。这条规则正是乐观确认安全性的核心支柱多数方一旦锁定少数方在逻辑上既无法构造证明因为凑不齐 1/3 的锁定质押也无法偷偷离开。五、三个关键定义乐观确认、最终化与回滚原文档给出了三组精确术语乐观确认Optimistic Confirmation当一个区块B获得了超过 2/3 质押权重的投票且每一张投票v的Range(v)都覆盖B.slot即X B.slot v.last时称B达到乐观确认。最终化Finalized当至少一个诚实验证者已经根化rooted区块B或其某个后代时称B已最终化。回滚Reverted如果存在另一个既不是B的父块也不是B后代的区块B被最终化则称B被回滚。六、核心保证与形式化证明6.1 保证一个已达到乐观确认的区块B不会被回滚——除非至少有一个验证者被惩罚。这是全文要证明的核心定理。证明思路矛盾法假设区块B在槽位B n达到了乐观确认但同时存在一个既非B父块也非B后代的区块B被最终化没有任何验证者违反惩罚条件。由乐观确认定义 2/3的验证者各自投过一张形如Vote(X, S)、满足X B v.last的票。称这一集合为乐观验证者集Optimistic Validators。对其中任意验证者v若它有两张票Vote(X, S)与Vote(X, S)都覆盖B即X B S.last且X B S.last则必有X X——否则两张票的范围会在B处重叠违反乐观惩罚条件。由此定义乐观投票集Optimistic Votes对每个乐观验证者取它所有满足X B S.last的投票中S.last最大的那张极大投票。由于上面证明了X的唯一性这个极大投票是良定义的。6.2 Lemma 1锁定在非祖先槽位 ⇒ 引用槽位必须在 B 之后Claim对乐观验证者集成员V的投票Vote(X, S)若S中存在槽位s满足s s.lockout Bs不是B的祖先或后代那么必有X B。直观示意X为乐观投票中的引用槽位B为乐观确认区块------- | | --------- -------- | | | | | ------- | | | | | | ------ | | | | | | X | | | | ------ | | | ------ | | | | | | B (Optimistically Confirmed) | | | | ------ | | | ------ | | | | | | S.last | | | | ------- | ------ | | X | | | | ------ | | | | | ------ | | S.last | | | | ------ | | | ------ | | s s.lockout | | -------证明反证法假设验证者V投出了这样的Vote(X, S)s s.lockout Bs与B无关且X B。设Vote(X, S)是V在乐观投票集中的那张票则由定义X B S.last。由于假设X B故X S.last。按惩罚规则X与X的关系只能是X X或X XCaseX X因s不是B的祖先或后代而X是B的祖先故s ! X又因S.last是B的后代s也不是S.last的祖先或后代。由于S.last从s下降而来S.last不可能与S.last构成祖先/后代关系于是由惩罚规则可推出X ! X矛盾。CaseX X直觉上Vote(X, S)发生在Vote(X, S)之前。由假设s s.lockout B X且s不是X的祖先则当该验证者首次尝试提交切换到X的投票形如Vote(X, S)时会违反锁定期约束。两种情形都被排除故假设不成立Claim 成立。6.3 Lemma 2被最终化的 B 必须晚于所有乐观投票的引用槽位Claim对乐观投票集中任意投票Vote(X, S)必有B X。示意------- | | -------- --------- | | | | | ------- | | | | ------ | | | | | | X | | | | ------ | | | ------ | | | | | | B (Optimistically Confirmed) | | | | ------ | | | ------ | | | | | | S.last | | | | ------- | ------ | | B(Finalized) | | | | -------证明由乐观投票集定义X B S.last。因为X是B的父块而B不是B的父块或祖先所以B ! X且B不是X的父块。若假设B X由于B已被根化且不是X的父块验证者本不应能够投票给不下降自B的更高槽位X——这违反锁定期约束矛盾。故只能B X。6.4 安全性证明Proof of Safety目标是证明乐观验证者集中至少有一个验证者违反了惩罚规则。要使B被根化必须有 2/3质押投票给B或其后代。而乐观验证者集也占 2/3的质押因此必有 1/3的质押验证者同时满足根化了B或其某个后代投过一张v Vote(X, S)且X B v.last的票。记这批验证者为Delinquent违规嫌疑集合。为根化B其中每个验证者V都必须做过某种切换投票Vote(X_v, S_v)满足S_v.last BS_v.last是B的后代因而不可能是B的后代既然S_v.last不是B的后代则X_v既不能是B的后代也不能是B的祖先。同时V也在乐观投票集中投过Vote(X, S)满足S.last B X。由 Lemma 2 知B X又S_v.last B故S_v.last X。因为X_v ! X由上面第三点X_v与B无关而X是B的祖先按惩罚规则可得X_v S.last进而由S.last B知对所有这些切换投票X_v B。现在按时间排序这些切换投票取乐观验证者集中第一个提交了满足X B的切换投票Vote(X, S)的验证者VDelinquent 是乐观验证者集的子集故这样的验证者必然存在。设Vote(X, S)是V在乐观投票集中的极大投票。因X B X故X X按惩罚规则得X S.last。为了执行这次切换到X的投票V必须出示切换证明SP(Vote(X, S), Vote(X, S))证明 1/3的质押在其最新投票S.last处仍被锁定。将这个 1/3与乐观投票者集占 2/3的事实结合可知至少有一位乐观验证者W的投票Vote(X_w, S_w)被包含在V的切换证明中且S_w中存在槽位s满足s不是S.last与X的共同祖先s不是S.last的后代s s.lockout S.last。由于B是S.last的祖先进一步有s不是B与X的共同祖先s s.lockout B。而W也是乐观投票者集的成员应用Lemma 1于W的投票Vote(X_w, S_w)其中存在满足s s.lockout B且s不是B祖先的槽位s得到X_w B。因为验证者V把Vote(X_w, S_w)包含在它切换到X的证明中说明W提交Vote(X_w, S_w)的时点早于V提交切换投票Vote(X, S)。但Vote(X, S)被定义为乐观投票者集中第一个满足X B且X不是B后代的投票——这与W更早提交了同样满足X_w B的投票相矛盾。矛盾完成故至少有一位验证者违反了惩罚规则乐观确认的安全性得证。七、安全性与活性权衡为什么是 2/3 与 1/3X7.1 安全性余量optimistic-confirmation-and-slashing.md 明确指出安全余量为1/3 X其中X是协议被破坏时至少会被惩罚的最小质押比例。只要协议被破坏会导致惩罚验证者就没有动机去构造切换证明乐观确认的不回滚保证就越强。7.2 活性代价最多 2X引入乐观确认的代价是最坏情况下活性被削减2X。若网络中不可用掉线/故障的节点比例超过1/3 - 2X网络可能停摆只有等故障比例回落到1/3 - 2X以下才会恢复最终确认。当前主网将阈值百分比设置为4.66%这意味着当故障节点达到23.68%时网络可能停止最终确认。对于主要由高可用系统构成的 Solana 网络这一级别的可用性滑坡被认为几乎不可能发生——文档给出的估算为1:10^12量级假设 5 个各占 4.7% 质押、可用性 0.995 的节点。7.3 实测安全统计文档还给出了主网长期观测数据平均每 slot 投票数约670,000,000 / 12,000,000即 64 个投票验证者中约 55 个参与投票含出块者故障导致的漏块。当客户端看到约 86%55/64的验证者确认某区块时可以预期要让该区块无法完成最终确认网络中必须有约(86 - 66.67 4.67)% ≈ 24%的质押被惩罚。八、为什么是 SolanaVDF 时间假设的价值该方案理论上也可构建在其他网络上但 Solana 的实现复杂度显著更低因为Solana 的投票拥有可证明的、基于 VDF可验证延迟函数的超时机制。切换证明需要对哪些验证者仍处于锁定状态做出时间性论断在缺乏强时间假设的网络中构造这样的证明并不容易。Solana 的 PoH 恰好为这些证明提供了可靠的时序基础。九、惩罚路线图从可观察到自动惩罚原提案明确承认惩罚是难题尤其在追求最低延迟时更难例如验证者理想上应在内存同步到磁盘之前就发出并传播投票这显著抬高了本地状态损坏的风险。根本目标在节点恶意违反安全规则时惩罚 100%在常规运行中惩罚 0%。实现路径先实现不带任何自动惩罚的惩罚证明。当前常规共识出现安全违规后网络会停摆团队可分析数据、确定责任方并在重启后提议惩罚对应质押乐观确认采用类似策略——乐观确认的安全违规极易被观察unrooted 的乐观确认槽位但正常情况下未必导致网络停摆。一旦观察到违规验证者将在下一 epoch 冻结受影响质押并决定下一次升级是否执行惩罚。长期愿景在证明乐观安全违规后交易应能收回部分惩罚抵押品。届时每个区块实际上都由网络投保。十、源码实现从提案到运行中的验证者10.1 投票状态与锁定期vote_state投票原语vote(X, S)中的S槽位 锁定期列表在 programs/vote/src/vote_state/mod.rs 中实现VoteStateUpdate携带有序的lockouts列表锁定期随连续投票成倍增长、过期槽位会被剔除见test_vote_lockout、test_process_new_vote_state_lockout_violation等测试。引用槽位与锁定期约束共同保证了前文惩罚规则中s lockout(s)类条件的可验证性。10.2 票数追踪与阈值判定cluster_info_vote_listener在 core/src/cluster_info_vote_listener.rs 中process_vote对每笔投票事务做如下处理对应源码L640-L721取vote.last_voted_slot_hash()作为last_vote_slot / last_vote_hash忽略 root 之前的槽位只统计slot root的投票只有投票事务中最后一个槽位slot last_vote_slot才计入乐观确认——原因正如源码注释所述更早的槽位可能存在切换且无法得知其哈希调用track_optimistic_confirmation_vote()将 (槽位, 哈希, 验证者, 质押, 总质押) 插入该槽位的optimistic_votes_trackerHashMapHash, VoteStakeTracker见L81-L95当reached_threshold_results[1]为真即超过 2/3 阈值时将该槽位推入new_optimistic_confirmed_slots并通过BankNotificationSender广播BankNotification::OptimisticallyConfirmed(last_vote_slot)。10.3 违规检测optimistic_confirmation_verifiercore/src/optimistic_confirmation_verifier.rs 实现了提案中违规可观察的落地OptimisticConfirmationVerifier维护unchecked_slots已乐观确认但尚未被根化的槽位集合在根银行推进时调用verify_for_unrooted_optimistic_slots检查这些槽位是否最终被根化若乐观确认槽位未被根化同槽不同哈希或所在分叉未成为 root 且 blockstore 中未记录为 root则通过log_unrooted_optimistic_slots输出形如Optimistically confirmed slot {slot} was not rooted的告警日志与optimistic_slot_not_rooted指标报告投票质押占比——这正是提案所述违规极易观察的工程化实现。测试test_get_unrooted_optimistic_slots构造了双分叉结构验证了同分叉 root 不告警、异分叉 root 告警的完整行为。10.4 RPC 与订阅层optimistically_confirmed_bank_trackerrpc/src/optimistically_confirmed_bank_tracker.rs 是乐观确认对外的出口它运行solOpConfBnkTrk线程消费BankNotification事件维护最新乐观确认银行OptimisticallyConfirmedBank并将BankNotification::OptimisticallyConfirmed转换为SlotNotification::OptimisticallyConfirmed推送给 RPC 订阅者供客户端钱包、交易所、索引器实时感知该槽位已乐观确认。至此从验证者投票、阈值判定、违规检测到对外通知的完整链路均与提案定义严格对齐。十一、总结乐观确认机制用一组简洁的投票原语vote(X, S)、Range(v)、切换证明和两条约束范围不得重叠、切换必须附带证明把2/3 多数投票转化为不可逆的安全承诺安全侧 2/3质押锁定某区块后任何切换都会被证明为可惩罚区块在无惩罚的前提下不可能回滚形式化证明见 optimistic_confirmation.md 的 Lemma 1、Lemma 2 与 Proof of Safety活性侧代价被严格限定为2X当前配置下即便近 24% 的验证者故障网络仍可继续最终确认工程侧提案中的每个抽象都在当前仓库有对应实现与测试支撑从 vote_state 的锁定期账本、cluster_info_vote_listener.rs 的阈值追踪到 optimistic_confirmation_verifier.rs 的违规检测与 optimistically_confirmed_bank_tracker.rs 的通知服务。感兴趣的读者可进一步阅读同目录下的相关提案 block-confirmation.md 与 slashing.md以完整了解 Solana 从区块确认到惩罚机制的整体设计。【免费下载链接】solanaWeb-Scale Blockchain for fast, secure, scalable, decentralized apps and marketplaces.项目地址: https://gitcode.com/GitHub_Trending/so/solana创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考