Polkadot Dispute Distribution 子系统详解：争议投票的可靠广播、限速防滥用与批量导入机制

区块链【免费下载链接】polkadotPolkadot Node Implementation项目地址https://gitcode.com/gh_mirrors/po/polkadot点击查看免费下载本指南以 Polkadot 实现者指南中的 dispute-distribution 设计文档 为骨架结合当前仓库中 dispute-distribution 子系统源码 的发送端sender、接收端receiver、协议类型定义与测试实现系统讲解争议dispute消息如何在验证者之间可靠分发、如何通过应用层确认保证投递、如何用按对端限速rate limiting与投票批量导入batching抵御恶意节点攻击。读完本文你将掌握该子系统的完整数据流从DisputeDistributionMessage::SendDispute到DisputeCoordinatorMessage::ImportStatements、两条请求/响应协议的线格式以及文档中给出的限速与批处理参数在源码中的真实取值与计算依据。一、子系统定位让所有相关验证者感知争议并拿到投票在 Polkadot 平行链共识中当一个候选区块同时存在 valid 与 invalid 两种互相矛盾的投票时就产生了争议。争议必须被及时、可靠地扩散到所有关心它的验证者——既包括争议发生时所在会话里参与平行链共识的验证者他们需要参与争议投票也包括当前会话的权威节点他们不需要投票但需要把相关语句打包进区块。dispute-distribution子系统正是负责这件事的模块它确保所有相关验证者都会知道某场争议的存在并拥有对应的投票。原文档给出了该设计的五条核心目标对节点临时不可用保持弹性resilient to nodes being temporarily unavailable让节点尽快感知争议make sure nodes are aware of a dispute quickly相对高效不对网络造成过大压力relatively efficient对垃圾消息spam具备弹性resilient when it comes to spam简单且无趣simple and boring争议发生时系统必须正常工作。从源码结构看该子系统由两个半部组成与设计目标一一对应见 lib.rs发送端DisputeSender跟踪活跃争议为每场争议维护一个SendTask把我们的投票投递给争议会话中的所有平行链验证者以及当前出块的权威节点并在失败后重试接收端DisputesReceiver以独立长任务运行等待网络请求、过滤非验证者与超速节点、批量导入投票并把导入结果作为应用层确认回执发给发送方。二、消息接口输入与输出原文档明确列出了子系统的输入输出消息定义见 子系统消息类型 与 overseer-protocol 文档输入DisputeDistributionMessage当前仓库中实际仅有一个变体SendDispute(DisputeMessage)见 messages.rs即告诉分发子系统把一份争议消息分发出去。输出DisputeCoordinatorMessage::ActiveDisputes向争议协调器查询当前仍活跃的争议列表用于重试与清理DisputeCoordinatorMessage::ImportStatements把收到的或本地产生的投票导入争议协调器DisputeCoordinatorMessage::QueryCandidateVotes查询某个候选的投票情况配合 Vote Recovery 协议补齐缺失投票RuntimeApiMessage获取会话信息、验证者集合等运行时数据。在源码中接收端对每个导入请求都会携带pending_confirmation: Some(pending_confirmation)的 oneshot 通道DisputeCoordinatorMessage::ImportStatements的定义见 messages.rs协调器导入完成后返回ImportStatementsResultValidImport或InvalidImport这正是应用层确认回执的来源。三、线协议Wire Format设计文档强调争议分发不能基于 gossip而必须使用请求/响应协议 应用层确认以便最大程度确认投票确实送达了所有相关验证者——请求是负载投票/语句响应是确认confirmation。协议名称由 genesis hash 与 fork id 共同拼装源码 request_response/mod.rs 中的generate_name会生成形如/hex_genesis_hash/fork_id/send_dispute/1的完整协议名无 fork id 时前缀仅为/hex_genesis_hash。3.1 争议发送协议Disputes协议名/genesis_hash/fork_id/send_dispute/1。请求负载文档中的结构定义struct DisputeRequest { /// The candidate being disputed. pub candidate_receipt: CandidateReceipt, /// The session the candidate appears in. pub session_index: SessionIndex, /// The invalid vote data that makes up this dispute. pub invalid_vote: InvalidDisputeVote, /// The valid vote that makes this dispute request valid. pub valid_vote: ValidDisputeVote, } /// Any invalid vote (currently only explicit). pub struct InvalidDisputeVote { /// The voting validator index. pub validator_index: ValidatorIndex, /// The validator signature, that can be verified when constructing a /// SignedDisputeStatement. pub signature: ValidatorSignature, /// Kind of dispute statement. pub kind: InvalidDisputeStatementKind, } /// Any valid vote (backing, approval, explicit). pub struct ValidDisputeVote { /// The voting validator index. pub validator_index: ValidatorIndex, /// The validator signature, that can be verified when constructing a /// SignedDisputeStatement. pub signature: ValidatorSignature, /// Kind of dispute statement. pub kind: ValidDisputeStatementKind, }响应enum DisputeResponse { Confirmed }在源码中的落点网络协议层定义了pub struct DisputeRequest(pub UncheckedDisputeMessage)与enum DisputeResponse { Confirmed }并声明其协议为Protocol::DisputeSendingV1见 request_response/v1.rs。负载类型UncheckedDisputeMessage的字段与文档中的DisputeRequest完全一致见 node/primitives/src/disputes/message.rs。值得注意的细节负载在网络上传送时签名尚未校验因此叫做UncheckedDisputeMessage。接收端在start_import_or_batch中通过payload.0.try_into_signed_votes(info.session_info)恢复出两份SignedDisputeStatement见 receiver/mod.rs。而DisputeMessage::from_signed_statements这个智能构造器会在构造阶段做一整套一致性检查——两个语句必须针对同一候选、同一会话、valid/invalid 语句的种类必须正确、候选回执哈希必须与语句中签名哈希一致、验证者索引必须与SessionInfo中的ValidatorId对应见 message.rs从而在源头就杜绝绝大多数编程错误。3.2 投票恢复协议Vote Recovery协议名/genesis_hash/fork_id/req_votes/1。请求struct IHaveVotesRequest { candidate_hash: CandidateHash, session: SessionIndex, valid_votes: Bitfield, invalid_votes: Bitfield, }响应struct VotesResponse { /// All votes we have, but the requester was missing. missing: Vec(DisputeStatement, ValidatorIndex, ValidatorSignature), }需要说明的是这是设计文档中规划的第二条请求/响应协议定位为低优先级、兜底的恢复通道。从当前仓库的协议枚举request_response/mod.rs看DisputeSendingV1已经落地而req_votes相关类型尚未在v1.rs中实现说明该协议目前仍停留在设计层面或由后续版本引入。阅读源码时请以设计文档为语义参考切勿把未实现的线格式当作已上线能力。四、发起一场争议Starting a Dispute一场争议由节点发出第一条DisputeRequest线消息而启动该消息必须同时包含一个 invalid 投票和一个 valid 投票。dispute-distribution子系统通过接收DisputeDistributionMessage::SendDispute消息来获知需要把消息发出去该消息必须携带本地节点的 invalid 投票以及某个 valid 投票例如一条 backing 语句。为什么一定要附带一个 valid 投票设计文档的解释很关键不管接收方是否已经同步链、是否见过 backing/approval 投票只要看到同时存在相互矛盾的投票就能判断这是一场有效争议。当然节点仍然需要自行检查这些争议投票是否足够新鲜而非陈旧的。源码印证发送端收到SendDispute后调用start_sender把DisputeMessage转换为DisputeRequestlet req: DisputeRequest msg.into();并以candidate_hash为键在disputes: IndexMapCandidateHash, SendTaskM中登记见 sender/mod.rs。使用IndexMap正是为了保持争议的插入顺序以便按重要性顺序发送。五、参与一场争议Participating in a Dispute接收端收到DisputeRequest后会通过DisputeCoordinatorMessage::ImportStatements触发投票导入见 receiver/mod.rs。争议协调器负责判断本地节点是否需要参与该争议一旦它完成判断会再发一条DisputeDistributionMessage::SendDispute给分发子系统。从这里开始参与流程与发起流程完全一致只有一个区别若本地节点判定该候选有效那么这条SendDispute消息会携带本地节点签名的 valid 投票外加最初收到的那份 invalid 投票若本地节点判定候选无效则对应地携带本地签名的 invalid 投票。注意设计文档特别强调争议有效性的检查完全依赖dispute-coordinator来完成——这是防垃圾消息的第一道也是最重要的一道闸门we rely on dispute-coordinator to check validity of a dispute for spam protection。六、消息发送对象、可靠性与顺序Sending of messages从分发子系统的视角看发起与参与争议非常相似一旦收到SendDispute就尽力把数据发出去。6.1 发给谁发送对象有两类源码get_relevant_validators给出了精确实现见 send_task.rs争议发生所在会话的全部平行链验证者从candidate_receipt.descriptor.relay_parent对应的会话信息中取出discovery_keys截取验证者数量部分排除本地节点自身当前会话的全部权威节点authorities遍历所有活跃头active heads对应的会话把每个会话的权威 discovery key 并集加入发送集合。权威节点不参与争议投票但必须看到语句以便把它们打包进区块。会话边界era/session change意味着这个发送集合是动态变化的新会话的验证者需要被告知已存在的争议。SendTask在构造时以及每次会话变化时都会调用refresh_sends重新计算接收者集合剔除已失效的投递、补充新增的权威见 send_task.rs。6.2 可靠性只有收到确认才认为送达发送端对每个接收者维护DeliveryStatusPending(RemoteHandle)或Succeeded见 send_task.rs并通过send_requests为每个接收者生成一个OutgoingRequest批次、挂起等待响应的后台任务wait_response_task见 send_task.rs。可靠性语义如下只有收到DisputeResponse::Confirmed才把该接收者的状态置为Succeeded若发送失败RequestError则该接收者的投递记录被移除、has_failed_sends置位等待下一轮重试只要争议还活着就持续重试每轮重试前发送端会通过DisputeCoordinatorMessage::ActiveDisputes向协调器查询所有仍活跃的争议列表get_active_disputes见 sender/mod.rs一旦争议不再活跃已得出结论或过期handle_new_active_disputes会通过retain清理掉过期的SendTask并同步回收相关状态见 sender/mod.rs。6.3 顺序设计假设SendDispute消息按重要性排序到达因此dispute-distribution保证网络消息按相同顺序发出包括重试时也保持顺序。这正是disputes使用IndexMapCandidateHash, SendTask、按插入顺序迭代的原因handle_new_active_disputes中的注释也明确写着 Iterates in order of insertion。6.4 发送限速Rate Limit为了不触发接收端的限速否则自己的消息会被丢弃且声誉被降低发送端实现了人工限速。源码中定义了两组关键常量见 lib.rs/// Rate limit on the receiver side. pub const RECEIVE_RATE_LIMIT: Duration Duration::from_millis(100); /// Rate limit on the sender side. pub const SEND_RATE_LIMIT: Duration RECEIVE_RATE_LIMIT.saturating_add(Duration::from_millis(50));发送端每次新建SendTask对应一条新的争议消息以及每轮重试前都会等待SEND_RATE_LIMIT150ms实现为基于futures_timer::Delay的RateLimit若被限速会打印Sending rate limit hit, slowing down requests日志见 sender/mod.rs。多出的 50ms 是为了给接收端留出安全余量。发送端限速的意义还在于每个SendTask会向每个验证者发一条消息因此按 peer 的限速只能通过限制新任务的创建频率来实现。七、接收端限速、批量导入与防滥用接收端是整个子系统对抗恶意节点的前线。设计文档列出了接收端的五个目标尽快把新争议交给 dispute-coordinator以便正确安排优先级尽量按争议批量导入投票保证导入性能防止恶意节点通过大量消息耗尽节点资源防止恶意节点发送海量消息/伪造争议阻碍我们给真正的争议下结论限制恶意节点利用批处理逻辑拖延投票导入的能力。目标 1 与目标 2 看似矛盾但设计给出了优雅的折中首次获知某候选的新争议时立即导入让协调器马上知情并获得有效性反馈确认有效后再把后续投票收进批量此时时间约束宽松得多。源码中的start_import_or_batch正是如此find_batch返回FoundBatch::Created时立即构造PreparedImport导入返回FoundBatch::Found时则调用batch.add_votes把投票追加进既有批次见 receiver/mod.rs。7.1 诚实节点的行为观察设计文档对垃圾消息防护的推理基础是两条观察每个诚实验证者每个候选/每场争议只会发送一条消息超时重发造成的重复除外诚实验证者在投票前需要完整恢复可用性availability并验证候选。由此可推断诚实验证者通常不会以高频发送消息因此可以实施保守的限速把恶意节点刷垃圾消息的伤害压到最低。关于会话变化时的情形——可能需要一次性把大量已存在的争议告知新验证者集合——文档用观察 1 按 peer 的限速化解假设限速为每个发送者每 200ms 一条即每秒 5 条5 条消息意味着 5 场争议。那么无论恶意行为者做什么我们每秒都能给 5 场争议下结论消息按序发送时即便不完全有序平均也是每秒 5 场。这已经足够好假设所有争议都得出valid结论即便要累计 100 场有效争议才开始禁用验证者也只需 20 秒即可开始处罚作恶者。文档同时坦承一个反例某些平行链负载很轻恢复与验证可能比导入争议更快因此限速值不宜设得过低更深层的问题是攻击者高频制造争议导致节点跟不上参与——这属于更基础的层面问题参见 polkadot 仓库中关于该问题的 issue #5898此处不展开外部链接。对离线较久的节点同一论证同样成立且影响更小假设 2/3 节点在线即使最坏情况下 1/3 离线、无法快速导入投票也不影响共识。7.2 接收端限速的具体机制接收端限速采用每个 peer 一个有限容量队列的结构源码为PeerQueues见 peer_queues.rs关键常量#[cfg(not(test))] pub const PEER_QUEUE_CAPACITY: usize 10;处理流程对应dispatch_to_queues见 receiver/mod.rs校验发送方确为有效权威通过authority_discovery.get_authority_ids_by_peer_id(peer)查询若不是验证者直接丢弃消息、返回错误响应并施加COST_NOT_A_VALIDATOR的声誉惩罚把消息放入该 peer 的队列若队列已满超过PEER_QUEUE_CAPACITY丢弃消息并施加COST_APPARENT_FLOOD轻微声誉惩罚足以让真正刷屏者被断开又不至于误伤偶尔超速的诚实节点。PeerQueues维护四条不变量源码注释明确列出见 peer_queues.rs队列容量上限、空队列即删除、pop_reqs每RECEIVE_RATE_LIMIT100ms最多返回一次Ready、空队列时永远Pending。也就是说每 100ms 从每个有消息的 peer 队列取出队头一条消息进行处理——这就是限速 公平调度的合体。此外接收端在导入前还做了多层防线见 lib.rs 与 receiver/mod.rs 的声誉常量丢弃非验证者节点的消息需要AuthorityDiscovery服务丢弃发送速率过高的节点的消息过滤重复消息一段时间窗口内丢弃签名明显非法的投票COST_INVALID_SIGNATURE标为Malicious对被判定为无效导入的 peer 施加COST_INVALID_IMPORTMalicious级并拉黑。设计文档还指出Substrate 层面本应内置限速当时尚未实现见 substrate issue #7750且即使实现也可能不可配置、对争议分发而言阈值过高——这就是为什么本子系统要在应用层自建限速。7.3 批量导入Batching为达成目标 2批量导入接收端把同一候选的投票聚合进一个Batch实现见 batch.rs流程为收到消息时先检查该候选是否已有批次没有则立即导入假定这涉及新争议打开一个批次开始收集该候选的后续消息不再立即转发持续收集直到最近BATCH_COLLECTING_INTERVAL内到达的去重后新投票数低于MIN_KEEP_BATCH_ALIVE_VOTES即把整批发给 dispute-coordinator批次还有硬性寿命上限MAX_BATCH_LIFETIME源码中为DISPUTE_REQUEST_TIMEOUT - 2s见 batches/mod.rs防止投票涓涓细流拖垮导入同时限制同时存在的批次数目为MAX_BATCHES 1000见 batches/mod.rs。相关常量在源码中的真实取值测试环境下会放宽见 receiver/mod.rs/// 非测试环境 pub const MIN_KEEP_BATCH_ALIVE_VOTES: u32 10; pub const BATCH_COLLECTING_INTERVAL: Duration Duration::from_millis(500);Batch.tick的判定逻辑见 batch.rs若本周期新投票数 ≥MIN_KEEP_BATCH_ALIVE_VOTES且未到best_before批次存活并安排下一次 tick否则PreparedImport::from(batch)输出为就绪导入。Batch.add_votes用HashMapValidatorIndex, SignedDisputeStatement区分 valid/invalid 投票允许验证者双投并在插入成功时递增votes_batched_since_last_tick——去重是保证MIN_KEEP_BATCH_ALIVE_VOTES机制不被刷屏破坏的关键两个投票都重复时返回Err接收端对完全冗余消息既不确认也不惩罚因为可能是有恶意节点抢先冒充发送以损害诚实节点声誉见 receiver/mod.rs。7.4 内存攻击的定量分析设计文档给出了一套完整的攻击场景推演证明限速 批处理在千级验证者规模下是安全的。假设MIN_KEEP_BATCH_ALIVE_VOTES 10、BATCH_COLLECTING_INTERVAL 500ms、RATE_LIMIT 100ms1/3 验证者恶意1000 个验证者约 330 个恶意者每个恶意者每 100ms 发一条消息每秒 10 条。攻击开始时他们能打开约3300 个批次每批仅含 2 票内存占用可忽略但批次存活要求每 500ms 有新票进来首批存活需要每批每 500ms 有 10 票每条消息 2 票即每批每秒 10 条消息即每个批次需要 10 个攻击者供养。于是批次数量被压回约 330每批 20 票第二秒起为继续增长内存攻击者必须维持每批每秒 10 条消息批次数等于攻击者数约 330因此存在约330 个批次的硬上限每批最多 330 票。按每个签名/投票约 100 字节估算最坏内存占用约330 × 330 × 100 ≈ 10 MiB若验证者规模到10,000内存占用就进入GB 级——文档因此提示超大验证者集时可能需要更严格的限速或要求更高的保活投票速率对 1000 验证者约 1000 的批次上限在实践中几乎不可能触达因此因资源上限而丢弃潜在有效争议的概率极低。文档还讨论了两个进一步的加固方向当前为简洁起见暂缓实现其一当协调器对首次导入返回拒绝时立即冲刷对应批次并导入以 CPU 换内存若再次被判无效则立即降低发送方声誉其二攻击者也可以持续给新候选投票来压垮协调器——这同样被限速 协调器拒绝导入时降低声誉所缓解。八、节点启动设计文档明确节点启动时无需特殊处理。分发子系统期望争议协调器通过SendDispute消息告知所有正在进行的争议。源码印证了这一点DisputeSender在每次ActiveLeavesUpdate信号update_leaves到来时都会刷新活跃会话并向协调器请求ActiveDisputes随后handle_new_active_disputes为每个未知争议启动SendTask见 sender/mod.rs。lib.rs 中的注释也说明这是为了即使在重启后也能把我们的投票发出去。同时DisputeSender会启动一个后台任务get_active_disputes异步等待协调器响应避免阻塞主循环。九、Backing 与 Approval 投票Backing 和 approval 投票在到达/产生时由相应子系统通过争议协调器导入并不经由 dispute-distribution。设计前提是正常运行下每个节点都知晓 backing 与 approval 投票并为此进行优化。但争议必须快速、可靠地得出结论因此当节点缺少 backing/approval 投票时它可以向告知它该争议的那个节点请求缺失投票——这正引出下面的弹性机制Vote Recovery。十、弹性Vote Recovery 协议上述主协议已覆盖大多数场景但文档指出三个必须覆盖的缺口非验证者节点可能对尚未上链的投票感兴趣节点可能错过投票尤其是 backing/approval 投票而从链上恢复它们既困难又昂贵涉及运行时升级与无类型 extrinsic更关键的是era 变化后从 approval-voting 的角度看新权威集合没有义务查看旧approval 投票因此它们可能根本没见过这些投票无法导入协调器也就不会有权威把它们写进链上。为覆盖这些场景设计引入第二条请求/响应协议线格式见上文 3.2 节以低于主协议的优先级处理。节点在感觉自己缺失投票时可以主动发起IHaveVotesRequest典型触发时机包括超时后仍未见多数派达成或收到某争议候选却不知道任何 backing/approval 投票。IHaveVotesRequest接收方的处理流程设计文档检查发送方是否缺少我方已知的投票——若有用这些投票响应检查发送方是否知道我方未知的投票——若有把我们的已知投票封装成IHaveVotesRequest回发过去记录该 peer 的知识knowledge供后续判断使用。何时发送IHaveVotesRequest每当被DisputeDistributionMessage::FetchMissingVotes指示时只要争议仍活跃大约每区块一次向某个随机验证者发送。垃圾消息考量节点只接受每个验证者每个 slot 一次的此类请求更频繁的请求、针对陈旧数据的请求可以自由丢弃来自非验证者节点的请求按 best-effort 处理即可。如前所述该协议在当前仓库中仍属设计层面的内容阅读时请注意区分设计意图与已落地实现。十一、运维与监控注意事项Considerations设计文档强调争议分发是关键路径并给出三条运维要求跟踪可用验证者连接数当未连接上大多数验证者时发出警告跟踪发送失败次数并记录警告日志由于争议罕见且 TCP 是可靠协议每次发送失败都应当在日志中告警并计入某个 Prometheus 指标。源码印证DisputeSender内置metrics见 sender/mod.rs每次TaskFinish都会调用on_sent_request(result.as_metrics_label())上报成功/失败接收端也有on_received_request、on_imported(label, count)等指标见 receiver/mod.rs。指标定义与 Prometheus 注册见 metrics.rs。发送失败时wait_response_task会把TaskResult::Failed(err)回传on_finished_send记录 trace 日志并标记重试见 send_task.rs。十二、不可用候选的争议Disputes for non available candidates设计文档将对不可用候选发起争议列为未来可能的能力并说明其需求完全不同不具时间紧迫性我们只希望某个作恶者最终被 slash不存在把坏数据 finalize 的风险数据提供责任不同由于没有可用性数据发起争议的节点需要先提供被争议数据随后做过检查的节点也成为数据提供者从而分散负载使阻止争议得出结论随时间推移越来越难。假设攻击者无法永远 DoS 一个节点争议终将成功——而这正是全部诉求。即使攻击者以某种方式阻止了此类争议也没有实际危害因为根本没有严重的攻击发生。十三、总结dispute-distribution是 Polkadot 争议处理链路中的快递员发送端保证投票按重要性顺序、带确认地送达所有相关验证者与权威SendDispute→SendTask→ 重试直至争议结束接收端通过权威校验 → 每 peer 限速队列 → 首次即时导入 后续批量导入的流水线在让协调器尽快感知新争议的同时用数学上可论证的限速参数RECEIVE_RATE_LIMIT 100ms、MIN_KEEP_BATCH_ALIVE_VOTES 10、BATCH_COLLECTING_INTERVAL 500ms、MAX_BATCHES 1000把恶意刷屏的伤害约束在可忽略的内存与 CPU 开销内。若要深入其实现细节建议按以下路径阅读源码子系统骨架与常量 lib.rs → 发送端 sender/mod.rs 与 send_task.rs → 接收端 receiver/mod.rs → 限速队列 peer_queues.rs → 批次管理 batches/mod.rs 与 batch.rs协议与消息类型的落点分别在 request_response/v1.rs、request_response/mod.rs、disputes/message.rs 与 messages.rs。测试实现见 tests/mod.rs可用来验证上述数据流的端到端行为。赞分享区块链【免费下载链接】polkadotPolkadot Node Implementation项目地址https://gitcode.com/gh_mirrors/po/polkadot点击查看免费下载相关推荐Polkadot 争议协调器Dispute Coordinator子系统深入解析投票记录、参与调度与垃圾防御Polkadot 争议协调器Dispute Coordinator子系统深入解析投票记录、参与调度与垃圾防御 导读 本文以 Polkadot 节点实现中的区块链interact.js Inertia 惯性插件完全指南配置参数、源码原理与平滑结束实战interact.js Inertia 惯性插件完全指南配置参数、源码原理与平滑结束实战 interact.js 的 Inertia 模块为拖拽drag与区块链Polkadot 节点实现解析PVF Pre-checker 子系统PVF 预检查投票机制Polkadot 节点实现解析PVF Pre checker 子系统PVF 预检查投票机制 导读 本文基于 roadmap/implementers gu区块链上一篇ESPHome蓝牙网关3步跑通BLE传感器接入MQTT下一篇Lip Gloss v2 终端样式引擎详解Sliver 客户端主题与 TUI 布局的底层支撑创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考