拓冰网站定制 
区块链【免费下载链接】polkadotPolkadot Node Implementation项目地址https://gitcode.com/gh_mirrors/po/polkadot点击查看免费下载本指南以 Polkadot 实现者指南Implementers Guide中的 Chain Selection 章节为核心系统讲解平行链中继parachain host如何在出块与最终性finality之间做出一致、且能抵御一定比例恶意节点的链选择决策。文章完整覆盖viable / stagnant / reverted / finalizable四个核心性质的精确定义、叶子选择规则leaf-selection rule、包含指定区块的最佳链规则best-chain-containing rule并结合仓库中polkadot-node-core-chain-selection子系统源码说明这些规则在代码中的落地方式。读完本文你将能理解 Polkadot 节点如何选择出块目标、如何参与 GRANDPA 投票以及验证人节点内部的链选择子系统是如何被驱动和实现的。一、为什么需要链选择出块与最终性的交汇区块链中的链选择chain selection过程用于决定在哪个区块上继续出块以及对哪个区块进行最终性投票。这个过程必须满足两个要求节点间的一致性所有诚实节点应当对当前最佳链有趋同的认知否则网络会不断分叉对恶意节点的韧性链选择过程要能容忍一定比例的不遵守规则的恶意节点不能因少数节点的异常行为而让整个网络走向错误的分叉。Polkadot 的平行链中继同时使用区块生产系统BABE和最终性小工具GRANDPA。相应地其链选择策略由两个关键组件构成叶子选择规则leaf-selection rule当验证人轮到出块时应当依据该规则选出最佳的可行叶子best viable leaf作为构建新块的父块。最终性约束finality constraints当验证人参与最终性投票时存在一个可投票的最低区块通常是已最终化区块。验证人先按叶子选择规则选出最佳链再对其应用最终性约束最终得出实际投出的票。要深入理解这两个组件必须先建立viable可行与finalizable可最终化区块的形式化定义。二、性质定义viable、viable leaf、stagnant、reverted 与 finalizable这些定义是整篇链选择协议的地基也直接映射为 链选择子系统源码 中的ViabilityCriteria数据结构。2.1 viable可行一个区块被认为是viable当且仅当以下所有条件成立它是已最终化区块本身或从已最终化区块派生descends from the finalized block它不是stagnant停滞的它不是reverted被回退的。2.2 viable leaf可行叶子一个区块被认为是viable leaf当且仅当以下所有条件成立它是viable的它没有任何viable的后代。换句话说可行叶子是可行链上的端点——所有可行后代都已被挖掘完毕的区块它才是适合作为出块基础的候选。2.3 stagnant停滞一个区块被认为是stagnant当满足以下任一条件它未最终化、未获得批准not approved并且在2 分钟内没有被批准它的父区块是stagnant的。这一性质刻画了被网络抛弃的区块如果某个区块迟迟得不到批准投票的确认节点就会放弃它转而构建另一条链。在源码中这个 2 分钟窗口由常量STAGNANT_TIMEOUT: Timestamp 120秒定义见 lib.rsApproval枚举的三种状态Approved / Unapproved / Stagnant则精确对应定义中的已批准 / 未批准但未停滞 / 未批准且停滞见 lib.rs。2.4 reverted被回退一个区块被认为是reverted当满足以下任一条件它未最终化并且包含一个在争议dispute中落败的候选candidate它的父区块是reverted的。该性质直接对应代码中的explicitly_reverted标记见 lib.rs当争议协调子系统Dispute Coordinator通知某个候选在争议中落败后包含该候选的区块会被显式标记为回退其所有后代随之变为非 viable。2.5 finalizable可最终化一个区块被认为是finalizable当且仅当以下所有条件成立它是viable的它的父区块若未最终化是finalizable的它要么已最终化要么已获得批准approved它要么已最终化要么不包含任何处于未决争议unresolved disputes或已输掉争议的候选。可以这样理解finalizable 是可以放心投票最终化的区块。它比 viable 更严格——在可行之外还要求批准已经到位且没有争议阴影。这组约束正是最终性投票规则见下文第五节中第二层过滤的数学基础。三、叶子选择规则Leaf-Selection Rule3.1 区块的隐式权重协议假定每个区块都有一个可用于比较的隐式权重或分数weight / score其具体来源取决于共识引擎BABEPolkadot 使用的出块引擎权重由链上包含的主插槽primary slots数量决定PoW权重取工作量最大或GHOST 权重最高的链。在源码中权重通过polkadot_node_primitives::BlockWeight表示叶子条目LeafEntry由weight、block_number、block_hash三元组构成且排序规则明确为先按权重降序、再按区块号见 lib.rsimpl PartialOrd for LeafEntry { fn partial_cmp(self, other: Self) - Optionstd::cmp::Ordering { let ord self.weight.cmp(other.weight).then(self.block_number.cmp(other.block_number)); if !matches!(ord, std::cmp::Ordering::Equal) { Some(ord) } else { None } } }LeafEntrySet内部维护一个有序向量插入时按序定位、删除时按哈希查找见 lib.rs这使得取最高分叶子成为 O(1) 级别的廉价查询。3.2 规则本体基于上述定义叶子选择规则非常简单取我们已知的、分数最高的可行叶子。若出现平局则选择区块哈希字典序lexicographical更小的那个。该规则的代码落点位于 backend.rs 的find_best_leaf_containing与LeafEntrySet::into_hashes_descending()叶子集合按权重降序迭代天然满足最高分优先的语义而哈希字典序的平局裁决则体现在有序集合的插入位置与顺序遍历中。四、包含指定区块的最佳链规则Best-Chain-Containing Rule最终性小工具通常还会强加一个额外要求对包含某个特定区块的链进行投票。这个区块称为required block必需区块。虽然它通常是最近最终化的区块但也可能是未最终化的区块。当收到这样的请求时处理逻辑分为三种情况详见 backend.rs 的实现find_best_leaf_containingrequired 区块就是最佳最终化区块直接选择最佳的可行叶子best viable leaf。required 区块未最终化且非 viable选择 required 区块本身不再深入。这通常意味着网络中将会最终化某些不好的东西——在批准approvals与争议disputes机制正常运转时这不会发生但协议仍为这种极端情形预留了处理路径。required 区块未最终化且 viable按分数降序遍历所有可行叶子选出第一个在其链中包含 required 区块的叶子。**反向遍历backwards iteration**是实现检查包含关系的朴素方法若未最终化链变得很长Merkle Mountain-RangesMMR将是更高效的替代方案。源码中的contains_ancestor函数见 backend.rs实现了朴素的反向祖先检查从head出发沿parent_hash逐级回溯直至找到ancestor或到达树的边界。注释同时坦诚地指出了复杂度该实现是 O(N²)N 为未最终化区块数与叶子数的乘积但在实践中未最终化区块数量级很小通常为个位数极难超过 1000因此朴素实现已经足够若未来需要可通过跳表skip-list优化祖先检查。值得一提的是该函数对required 为较旧的最终化区块会返回None——因为树中不保留已最终化链的信息此时调用方应当unwrap_or(required)即直接投票给 required 区块见 lib.rs 的注释说明。五、最终性约束从最佳叶子到实际投票选定叶子之后链需要被约束到required 区块与最高的 finalizable 祖先二者中的较大者maximum of the required block or the highest finalizable ancestor。这个约束在 Polkadot 中如何实际执行答案在 GRANDPA 投票规则文档 中。GRANDPA 的常规投票规则是每个验证人选择自己知道的最长链然后通过多轮投票收集在线验证人的共识。其执行链路如下低层 GRANDPA 逻辑提供required 区块通过ChainSelectionMessage::BestLeafContaining查询包含该区块的最佳叶子若结果为None则直接对 required 区块投票第一层约束链选择子系统给出的 viable 叶子未必 finalizable。为避免对任何未批准区块投票通过ApprovalVotingMessage::ApprovedAncestor查询给定区块的最高已批准祖先第二层约束将ApprovedAncestor返回的区块哈希与候选列表反转后传给DisputeCoordinatorMessage::DetermineUndisputedChain从而确定finalizable区块这就是验证人的最终投票目标。这套先选叶子 → 查已批准祖先 → 过滤争议链的流程正是协议文档中应用最终性约束得到实际投票的工程实现。GRANDPA 投票规则的完整实现可进一步查阅 relay_chain_selection.rs其中BestLeafContainingCanceled等错误分支与ChainSelectionMessage::BestLeafContaining的调用见 L298-L392。六、链选择子系统的工程实现协议的可行叶子视图由Chain Selection 子系统负责维护其完整说明见 实现者指南中的子系统章节代码位于 node/core/chain-selection。6.1 数据视图以最终化区块为根的树子系统包装一个数据库组件维护未最终化链的视图并记录每个区块的性质是否viable、是否stagnant、是否reverted同时维护一个更新后的可行叶子集合以便廉价查询。数据以树的形式组织见 tree.rs 的模块注释树的根隐式为最终化区块不存储在树中最终化区块的每个直接后代各自构成一棵子树随着最终化区块推进被孤立的子树被整体剪除pruned。6.2 驱动事件与消息子系统需要在以下时机更新未最终化链的信息每种更新的朴素实现需要 O(n_unfinalized_blocks) 次磁盘操作未最终化区块少时开销不大若达到数百上千个则需要更精巧的算法事件 / 消息处理逻辑OverseerSignal::ActiveLeavesUpdate找出新激活叶子隐式引用的所有新区块并加入视图按ChainApiMessage::BlockWeight获取权重更新可行叶子集合见 lib.rs 的handle_active_leaf内部通过determine_new_blocks回溯未导入区块OverseerSignal::BlockFinalized删除所有孤儿链的数据更新从新最终化区块派生的所有元数据与可行叶子集合注意最终化一个 reverted 或 stagnant 区块会使其后代失去该状态因为这些性质的定义不包含最终化链见 tree.rs 的finalize_blockChainSelectionMessage::Approved更新被批准区块的批准状态若区块由停滞变为 viable其所有后代的元数据也需更新见 tree.rs 的approve_blockChainSelectionMessage::Leaves返回所有适合构建新块且没有合适子区块的叶子哈希按分数降序排列ChainSelectionMessage::BestLeafContainingrequired 区块未知或非 viable 时返回None否则按权重降序遍历叶子返回第一个在链中包含 required 的叶子见 backend.rsChainSelectionMessage::RevertBlocks表示某争议已对某平行链候选作出不利裁决消息携带包含被争议候选的各区块的区块号区块哈希向量这些区块被标记为 reverted其后代全部标记为非 viable见 tree.rs 的apply_single_reversion与revert_single_block_entry_if_present周期性任务检测停滞区块将其停滞状态应用到所有后代更新可行叶子集合见 tree.rs 的detect_stagnant与prune_only_stagnant6.3 关键常量与配置源码中的关键常量与配置项如下STAGNANT_TIMEOUT: Timestamp 120区块在 120 秒内未获批准即被放弃节点转而构建其他链lib.rsSTAGNANT_PRUNE_DELAY: Timestamp 25 * 60 * 60在仅剪除模式PruneOnly下停滞条目延迟 25 小时剪除以避免与最终性流程相互干扰lib.rsMAX_STAGNANT_ENTRIES: usize 1000单次停滞检测循环最多清理的停滞条目数lib.rsStagnantCheckInterval停滞检查的周期默认5 秒——这是减少数据库读取与保证验证人对停滞区块认知基本一致之间的平衡点假定网络延迟为 D两个验证人视图的最大差异为 D 5slib.rsStagnantCheckModeCheckAndPrune检查并剪除或PruneOnly仅剪除默认值用于清理禁用停滞检查后遗留的条目lib.rsConfig结构体包含数据库列号col_data、停滞检查间隔与模式通过ChainSelectionSubsystem::new(config, db)构造lib.rsrevert_to(hash)将树回退到指定区块且不允许回退到最后一个最终化区块之前lib.rs 与 tree.rs。6.4 后端的抽象与覆盖层子系统通过Backendtrait 抽象底层存储数据库列、内存后端等提供load_block_entry、load_leaves、load_stagnant_at、load_blocks_by_number、原子write等接口见 backend.rs。OverlayedBackend则是一个内存覆盖层在提交到底层存储之前可以在其上应用临时变更保证查询与临时写入之间的一致性见 backend.rs最终通过into_write_ops()生成一组写操作WriteBlockEntry、WriteViableLeaves、DeleteStagnantAt等原子落盘。子系统的正确性由 tests.rs2119 行测试代码保障测试通过共享的TestBackend内存实现 写唤醒队列驱动子系统验证叶子集合、停滞状态、最终化剪枝与回退逻辑的正确性例如assert_contains_only断言后端仅包含指定区块、assert_stagnant_at_state断言停滞条目状态tests.rs。七、消息与信号流全景将以上内容串成一条完整链路节点内部的链选择数据流如下出块侧BABE 轮到验证人出块 → overseer 广播ActiveLeavesUpdate→ 链选择子系统导入新区块、更新可行叶子集合 → 验证人查询ChainSelectionMessage::Leaves取最高分叶子作为出块父块批准侧批准投票子系统对区块批准后发送ChainSelectionMessage::Approved→ 区块及其潜在的后代恢复 viable 状态争议侧争议协调子系统发现某候选落败后发送ChainSelectionMessage::RevertBlocks→ 相关区块被标记 reverted、后代非 viable节点切换出块目标最终性侧GRANDPA 通过ChainSelectionMessage::BestLeafContaining取得含 required 区块的最佳叶子再经ApprovalVotingMessage::ApprovedAncestor与DisputeCoordinatorMessage::DetermineUndisputedChain应用最终性约束最终投出对 finalizable 区块的票。所有的消息类型定义可参阅 子系统消息定义链选择相关协议文档见 实现者指南的 overseer 协议章节。八、总结Polkadot 的链选择协议通过一组形式化性质viable、viable leaf、stagnant、reverted、finalizable把该在哪个区块上出块和该为哪个区块投票这两个看似独立的问题统一起来叶子选择规则负责选出最高分的可行叶子供出块使用最终性约束在可行叶子之上叠加已批准与无争议两层过滤得到 finalizable 区块供 GRANDPA 投票使用而node/core/chain-selection子系统则以树视图、有序叶子集合与停滞检测等机制在工程上高效地维护这份视图并通过清晰的子系统消息协议与批准、争议、最终性等模块协同。理解这套协议也就理解了 Polkadot 节点在分叉之间保持共识一致性的核心机制。赞分享区块链【免费下载链接】polkadotPolkadot Node Implementation项目地址https://gitcode.com/gh_mirrors/po/polkadot点击查看免费下载相关推荐stylelint selector-id-pattern 规则详解用正则约束 ID 选择器命名规范stylelint selector id pattern 规则详解用正则约束 ID 选择器命名规范 selector id pattern 是 stylel代码质量静态分析前端Uvicorn HTTP/1.1 协议实现全解析h11、httptools 与 zttp 的选择与原理Uvicorn HTTP/1.1 协议实现全解析h11、httptools 与 zttp 的选择与原理 Uvicorn 是 Python 生态中基于 ASGI后端Web框架IronClaw 通信投递解析契约候选目标选择、校验边界与确定性规则深度解析IronClaw 通信投递解析契约候选目标选择、校验边界与确定性规则深度解析 IronClaw 将谁发起的通信ingress identity、以什人工智能AI 应用交互助手AI Agent上一篇BannerlordCoop联机模组与好友共享骑马与砍杀2战役的终极指南下一篇BannerlordCoop多人联机模组从单人征战到团队协作的革命性架构设计创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Polkadot 链选择协议深度解析：叶子选择规则、最终性约束与实现原理
区块链【免费下载链接】polkadotPolkadot Node Implementation项目地址https://gitcode.com/gh_mirrors/po/polkadot点击查看免费下载本指南以 Polkadot 实现者指南Implementers Guide中的 Chain Selection 章节为核心系统讲解平行链中继parachain host如何在出块与最终性finality之间做出一致、且能抵御一定比例恶意节点的链选择决策。文章完整覆盖viable / stagnant / reverted / finalizable四个核心性质的精确定义、叶子选择规则leaf-selection rule、包含指定区块的最佳链规则best-chain-containing rule并结合仓库中polkadot-node-core-chain-selection子系统源码说明这些规则在代码中的落地方式。读完本文你将能理解 Polkadot 节点如何选择出块目标、如何参与 GRANDPA 投票以及验证人节点内部的链选择子系统是如何被驱动和实现的。一、为什么需要链选择出块与最终性的交汇区块链中的链选择chain selection过程用于决定在哪个区块上继续出块以及对哪个区块进行最终性投票。这个过程必须满足两个要求节点间的一致性所有诚实节点应当对当前最佳链有趋同的认知否则网络会不断分叉对恶意节点的韧性链选择过程要能容忍一定比例的不遵守规则的恶意节点不能因少数节点的异常行为而让整个网络走向错误的分叉。Polkadot 的平行链中继同时使用区块生产系统BABE和最终性小工具GRANDPA。相应地其链选择策略由两个关键组件构成叶子选择规则leaf-selection rule当验证人轮到出块时应当依据该规则选出最佳的可行叶子best viable leaf作为构建新块的父块。最终性约束finality constraints当验证人参与最终性投票时存在一个可投票的最低区块通常是已最终化区块。验证人先按叶子选择规则选出最佳链再对其应用最终性约束最终得出实际投出的票。要深入理解这两个组件必须先建立viable可行与finalizable可最终化区块的形式化定义。二、性质定义viable、viable leaf、stagnant、reverted 与 finalizable这些定义是整篇链选择协议的地基也直接映射为 链选择子系统源码 中的ViabilityCriteria数据结构。2.1 viable可行一个区块被认为是viable当且仅当以下所有条件成立它是已最终化区块本身或从已最终化区块派生descends from the finalized block它不是stagnant停滞的它不是reverted被回退的。2.2 viable leaf可行叶子一个区块被认为是viable leaf当且仅当以下所有条件成立它是viable的它没有任何viable的后代。换句话说可行叶子是可行链上的端点——所有可行后代都已被挖掘完毕的区块它才是适合作为出块基础的候选。2.3 stagnant停滞一个区块被认为是stagnant当满足以下任一条件它未最终化、未获得批准not approved并且在2 分钟内没有被批准它的父区块是stagnant的。这一性质刻画了被网络抛弃的区块如果某个区块迟迟得不到批准投票的确认节点就会放弃它转而构建另一条链。在源码中这个 2 分钟窗口由常量STAGNANT_TIMEOUT: Timestamp 120秒定义见 lib.rsApproval枚举的三种状态Approved / Unapproved / Stagnant则精确对应定义中的已批准 / 未批准但未停滞 / 未批准且停滞见 lib.rs。2.4 reverted被回退一个区块被认为是reverted当满足以下任一条件它未最终化并且包含一个在争议dispute中落败的候选candidate它的父区块是reverted的。该性质直接对应代码中的explicitly_reverted标记见 lib.rs当争议协调子系统Dispute Coordinator通知某个候选在争议中落败后包含该候选的区块会被显式标记为回退其所有后代随之变为非 viable。2.5 finalizable可最终化一个区块被认为是finalizable当且仅当以下所有条件成立它是viable的它的父区块若未最终化是finalizable的它要么已最终化要么已获得批准approved它要么已最终化要么不包含任何处于未决争议unresolved disputes或已输掉争议的候选。可以这样理解finalizable 是可以放心投票最终化的区块。它比 viable 更严格——在可行之外还要求批准已经到位且没有争议阴影。这组约束正是最终性投票规则见下文第五节中第二层过滤的数学基础。三、叶子选择规则Leaf-Selection Rule3.1 区块的隐式权重协议假定每个区块都有一个可用于比较的隐式权重或分数weight / score其具体来源取决于共识引擎BABEPolkadot 使用的出块引擎权重由链上包含的主插槽primary slots数量决定PoW权重取工作量最大或GHOST 权重最高的链。在源码中权重通过polkadot_node_primitives::BlockWeight表示叶子条目LeafEntry由weight、block_number、block_hash三元组构成且排序规则明确为先按权重降序、再按区块号见 lib.rsimpl PartialOrd for LeafEntry { fn partial_cmp(self, other: Self) - Optionstd::cmp::Ordering { let ord self.weight.cmp(other.weight).then(self.block_number.cmp(other.block_number)); if !matches!(ord, std::cmp::Ordering::Equal) { Some(ord) } else { None } } }LeafEntrySet内部维护一个有序向量插入时按序定位、删除时按哈希查找见 lib.rs这使得取最高分叶子成为 O(1) 级别的廉价查询。3.2 规则本体基于上述定义叶子选择规则非常简单取我们已知的、分数最高的可行叶子。若出现平局则选择区块哈希字典序lexicographical更小的那个。该规则的代码落点位于 backend.rs 的find_best_leaf_containing与LeafEntrySet::into_hashes_descending()叶子集合按权重降序迭代天然满足最高分优先的语义而哈希字典序的平局裁决则体现在有序集合的插入位置与顺序遍历中。四、包含指定区块的最佳链规则Best-Chain-Containing Rule最终性小工具通常还会强加一个额外要求对包含某个特定区块的链进行投票。这个区块称为required block必需区块。虽然它通常是最近最终化的区块但也可能是未最终化的区块。当收到这样的请求时处理逻辑分为三种情况详见 backend.rs 的实现find_best_leaf_containingrequired 区块就是最佳最终化区块直接选择最佳的可行叶子best viable leaf。required 区块未最终化且非 viable选择 required 区块本身不再深入。这通常意味着网络中将会最终化某些不好的东西——在批准approvals与争议disputes机制正常运转时这不会发生但协议仍为这种极端情形预留了处理路径。required 区块未最终化且 viable按分数降序遍历所有可行叶子选出第一个在其链中包含 required 区块的叶子。**反向遍历backwards iteration**是实现检查包含关系的朴素方法若未最终化链变得很长Merkle Mountain-RangesMMR将是更高效的替代方案。源码中的contains_ancestor函数见 backend.rs实现了朴素的反向祖先检查从head出发沿parent_hash逐级回溯直至找到ancestor或到达树的边界。注释同时坦诚地指出了复杂度该实现是 O(N²)N 为未最终化区块数与叶子数的乘积但在实践中未最终化区块数量级很小通常为个位数极难超过 1000因此朴素实现已经足够若未来需要可通过跳表skip-list优化祖先检查。值得一提的是该函数对required 为较旧的最终化区块会返回None——因为树中不保留已最终化链的信息此时调用方应当unwrap_or(required)即直接投票给 required 区块见 lib.rs 的注释说明。五、最终性约束从最佳叶子到实际投票选定叶子之后链需要被约束到required 区块与最高的 finalizable 祖先二者中的较大者maximum of the required block or the highest finalizable ancestor。这个约束在 Polkadot 中如何实际执行答案在 GRANDPA 投票规则文档 中。GRANDPA 的常规投票规则是每个验证人选择自己知道的最长链然后通过多轮投票收集在线验证人的共识。其执行链路如下低层 GRANDPA 逻辑提供required 区块通过ChainSelectionMessage::BestLeafContaining查询包含该区块的最佳叶子若结果为None则直接对 required 区块投票第一层约束链选择子系统给出的 viable 叶子未必 finalizable。为避免对任何未批准区块投票通过ApprovalVotingMessage::ApprovedAncestor查询给定区块的最高已批准祖先第二层约束将ApprovedAncestor返回的区块哈希与候选列表反转后传给DisputeCoordinatorMessage::DetermineUndisputedChain从而确定finalizable区块这就是验证人的最终投票目标。这套先选叶子 → 查已批准祖先 → 过滤争议链的流程正是协议文档中应用最终性约束得到实际投票的工程实现。GRANDPA 投票规则的完整实现可进一步查阅 relay_chain_selection.rs其中BestLeafContainingCanceled等错误分支与ChainSelectionMessage::BestLeafContaining的调用见 L298-L392。六、链选择子系统的工程实现协议的可行叶子视图由Chain Selection 子系统负责维护其完整说明见 实现者指南中的子系统章节代码位于 node/core/chain-selection。6.1 数据视图以最终化区块为根的树子系统包装一个数据库组件维护未最终化链的视图并记录每个区块的性质是否viable、是否stagnant、是否reverted同时维护一个更新后的可行叶子集合以便廉价查询。数据以树的形式组织见 tree.rs 的模块注释树的根隐式为最终化区块不存储在树中最终化区块的每个直接后代各自构成一棵子树随着最终化区块推进被孤立的子树被整体剪除pruned。6.2 驱动事件与消息子系统需要在以下时机更新未最终化链的信息每种更新的朴素实现需要 O(n_unfinalized_blocks) 次磁盘操作未最终化区块少时开销不大若达到数百上千个则需要更精巧的算法事件 / 消息处理逻辑OverseerSignal::ActiveLeavesUpdate找出新激活叶子隐式引用的所有新区块并加入视图按ChainApiMessage::BlockWeight获取权重更新可行叶子集合见 lib.rs 的handle_active_leaf内部通过determine_new_blocks回溯未导入区块OverseerSignal::BlockFinalized删除所有孤儿链的数据更新从新最终化区块派生的所有元数据与可行叶子集合注意最终化一个 reverted 或 stagnant 区块会使其后代失去该状态因为这些性质的定义不包含最终化链见 tree.rs 的finalize_blockChainSelectionMessage::Approved更新被批准区块的批准状态若区块由停滞变为 viable其所有后代的元数据也需更新见 tree.rs 的approve_blockChainSelectionMessage::Leaves返回所有适合构建新块且没有合适子区块的叶子哈希按分数降序排列ChainSelectionMessage::BestLeafContainingrequired 区块未知或非 viable 时返回None否则按权重降序遍历叶子返回第一个在链中包含 required 的叶子见 backend.rsChainSelectionMessage::RevertBlocks表示某争议已对某平行链候选作出不利裁决消息携带包含被争议候选的各区块的区块号区块哈希向量这些区块被标记为 reverted其后代全部标记为非 viable见 tree.rs 的apply_single_reversion与revert_single_block_entry_if_present周期性任务检测停滞区块将其停滞状态应用到所有后代更新可行叶子集合见 tree.rs 的detect_stagnant与prune_only_stagnant6.3 关键常量与配置源码中的关键常量与配置项如下STAGNANT_TIMEOUT: Timestamp 120区块在 120 秒内未获批准即被放弃节点转而构建其他链lib.rsSTAGNANT_PRUNE_DELAY: Timestamp 25 * 60 * 60在仅剪除模式PruneOnly下停滞条目延迟 25 小时剪除以避免与最终性流程相互干扰lib.rsMAX_STAGNANT_ENTRIES: usize 1000单次停滞检测循环最多清理的停滞条目数lib.rsStagnantCheckInterval停滞检查的周期默认5 秒——这是减少数据库读取与保证验证人对停滞区块认知基本一致之间的平衡点假定网络延迟为 D两个验证人视图的最大差异为 D 5slib.rsStagnantCheckModeCheckAndPrune检查并剪除或PruneOnly仅剪除默认值用于清理禁用停滞检查后遗留的条目lib.rsConfig结构体包含数据库列号col_data、停滞检查间隔与模式通过ChainSelectionSubsystem::new(config, db)构造lib.rsrevert_to(hash)将树回退到指定区块且不允许回退到最后一个最终化区块之前lib.rs 与 tree.rs。6.4 后端的抽象与覆盖层子系统通过Backendtrait 抽象底层存储数据库列、内存后端等提供load_block_entry、load_leaves、load_stagnant_at、load_blocks_by_number、原子write等接口见 backend.rs。OverlayedBackend则是一个内存覆盖层在提交到底层存储之前可以在其上应用临时变更保证查询与临时写入之间的一致性见 backend.rs最终通过into_write_ops()生成一组写操作WriteBlockEntry、WriteViableLeaves、DeleteStagnantAt等原子落盘。子系统的正确性由 tests.rs2119 行测试代码保障测试通过共享的TestBackend内存实现 写唤醒队列驱动子系统验证叶子集合、停滞状态、最终化剪枝与回退逻辑的正确性例如assert_contains_only断言后端仅包含指定区块、assert_stagnant_at_state断言停滞条目状态tests.rs。七、消息与信号流全景将以上内容串成一条完整链路节点内部的链选择数据流如下出块侧BABE 轮到验证人出块 → overseer 广播ActiveLeavesUpdate→ 链选择子系统导入新区块、更新可行叶子集合 → 验证人查询ChainSelectionMessage::Leaves取最高分叶子作为出块父块批准侧批准投票子系统对区块批准后发送ChainSelectionMessage::Approved→ 区块及其潜在的后代恢复 viable 状态争议侧争议协调子系统发现某候选落败后发送ChainSelectionMessage::RevertBlocks→ 相关区块被标记 reverted、后代非 viable节点切换出块目标最终性侧GRANDPA 通过ChainSelectionMessage::BestLeafContaining取得含 required 区块的最佳叶子再经ApprovalVotingMessage::ApprovedAncestor与DisputeCoordinatorMessage::DetermineUndisputedChain应用最终性约束最终投出对 finalizable 区块的票。所有的消息类型定义可参阅 子系统消息定义链选择相关协议文档见 实现者指南的 overseer 协议章节。八、总结Polkadot 的链选择协议通过一组形式化性质viable、viable leaf、stagnant、reverted、finalizable把该在哪个区块上出块和该为哪个区块投票这两个看似独立的问题统一起来叶子选择规则负责选出最高分的可行叶子供出块使用最终性约束在可行叶子之上叠加已批准与无争议两层过滤得到 finalizable 区块供 GRANDPA 投票使用而node/core/chain-selection子系统则以树视图、有序叶子集合与停滞检测等机制在工程上高效地维护这份视图并通过清晰的子系统消息协议与批准、争议、最终性等模块协同。理解这套协议也就理解了 Polkadot 节点在分叉之间保持共识一致性的核心机制。赞分享区块链【免费下载链接】polkadotPolkadot Node Implementation项目地址https://gitcode.com/gh_mirrors/po/polkadot点击查看免费下载相关推荐stylelint selector-id-pattern 规则详解用正则约束 ID 选择器命名规范stylelint selector id pattern 规则详解用正则约束 ID 选择器命名规范 selector id pattern 是 stylel代码质量静态分析前端Uvicorn HTTP/1.1 协议实现全解析h11、httptools 与 zttp 的选择与原理Uvicorn HTTP/1.1 协议实现全解析h11、httptools 与 zttp 的选择与原理 Uvicorn 是 Python 生态中基于 ASGI后端Web框架IronClaw 通信投递解析契约候选目标选择、校验边界与确定性规则深度解析IronClaw 通信投递解析契约候选目标选择、校验边界与确定性规则深度解析 IronClaw 将谁发起的通信ingress identity、以什人工智能AI 应用交互助手AI Agent上一篇BannerlordCoop联机模组与好友共享骑马与砍杀2战役的终极指南下一篇BannerlordCoop多人联机模组从单人征战到团队协作的革命性架构设计创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考