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

• 区块链

本指南以 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：协调器导入完成后返回ImportStatementsResult（ValidImport或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转换为DisputeRequest（let req: DisputeRequest = msg.into();），并以candidate_hash为键在disputes: IndexMap<CandidateHash, SendTask<M>>中登记（见 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）：

1. 争议发生所在会话的全部平行链验证者：从candidate_receipt.descriptor.relay_parent对应的会话信息中取出discovery_keys，截取验证者数量部分，排除本地节点自身；
2. 当前会话的全部权威节点（authorities）：遍历所有活跃头（active heads）对应的会话，把每个会话的权威 discovery key 并集加入发送集合。权威节点不参与争议投票，但必须看到语句以便把它们打包进区块。

会话边界（era/session change）意味着这个发送集合是动态变化的：新会话的验证者需要被告知已存在的争议。SendTask在构造时以及每次会话变化时都会调用refresh_sends重新计算接收者集合，剔除已失效的投递、补充新增的权威（见 send_task.rs）。

6.2 可靠性：只有收到确认才认为送达

发送端对每个接收者维护DeliveryStatus（Pending(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使用IndexMap<CandidateHash, 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_LIMIT（150ms），实现为基于futures_timer::Delay的RateLimit，若被限速会打印"Sending rate limit hit, slowing down requests"日志（见 sender/mod.rs）。多出的 50ms 是为了给接收端留出安全余量。发送端限速的意义还在于：每个SendTask会向每个验证者发一条消息，因此按 peer 的限速只能通过限制新任务的创建频率来实现。

七、接收端：限速、批量导入与防滥用

接收端是整个子系统对抗恶意节点的前线。设计文档列出了接收端的五个目标：

1. 尽快把新争议交给 dispute-coordinator，以便正确安排优先级；
2. 尽量按争议批量导入投票，保证导入性能；
3. 防止恶意节点通过大量消息耗尽节点资源；
4. 防止恶意节点发送海量消息/伪造争议，阻碍我们给真正的争议下结论；
5. 限制恶意节点利用批处理逻辑拖延投票导入的能力。

目标 1 与目标 2 看似矛盾，但设计给出了优雅的折中：首次获知某候选的新争议时立即导入（让协调器马上知情并获得有效性反馈），确认有效后再把后续投票收进批量，此时时间约束宽松得多。源码中的start_import_or_batch正是如此：find_batch返回FoundBatch::Created时立即构造PreparedImport导入，返回FoundBatch::Found时则调用batch.add_votes把投票追加进既有批次（见 receiver/mod.rs）。

7.1 诚实节点的行为观察

设计文档对垃圾消息防护的推理基础是两条观察：

1. 每个诚实验证者每个候选/每场争议只会发送一条消息（超时重发造成的重复除外）；
2. 诚实验证者在投票前需要完整恢复可用性（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）：

1. 校验发送方确为有效权威：通过authority_discovery.get_authority_ids_by_peer_id(peer)查询；若不是验证者，直接丢弃消息、返回错误响应并施加COST_NOT_A_VALIDATOR的声誉惩罚；
2. 把消息放入该 peer 的队列：若队列已满（超过PEER_QUEUE_CAPACITY），丢弃消息并施加COST_APPARENT_FLOOD（轻微声誉惩罚，足以让真正刷屏者被断开，又不至于误伤偶尔超速的诚实节点）。

PeerQueues维护四条不变量（源码注释明确列出，见 peer_queues.rs）：队列容量上限、空队列即删除、pop_reqs每RECEIVE_RATE_LIMIT（100ms）最多返回一次Ready、空队列时永远Pending。也就是说，每 100ms 从每个有消息的 peer 队列取出队头一条消息进行处理——这就是"限速 + 公平调度"的合体。

此外，接收端在导入前还做了多层防线（见 lib.rs 与 receiver/mod.rs 的声誉常量）：

• 丢弃非验证者节点的消息（需要AuthorityDiscovery服务）；
• 丢弃发送速率过高的节点的消息；
• 过滤重复消息（一段时间窗口内）；
• 丢弃签名明显非法的投票（COST_INVALID_SIGNATURE，标为Malicious）；
• 对被判定为无效导入的 peer 施加COST_INVALID_IMPORT（Malicious级）并拉黑。

设计文档还指出：Substrate 层面本应内置限速（当时尚未实现，见 substrate issue #7750），且即使实现也可能不可配置、对争议分发而言阈值过高——这就是为什么本子系统要在应用层自建限速。

7.3 批量导入（Batching）

为达成目标 2（批量导入），接收端把同一候选的投票聚合进一个Batch（实现见 batch.rs），流程为：

1. 收到消息时，先检查该候选是否已有批次；没有则立即导入（假定这涉及新争议）；
2. 打开一个批次，开始收集该候选的后续消息，不再立即转发；
3. 持续收集，直到最近BATCH_COLLECTING_INTERVAL内到达的去重后新投票数低于MIN_KEEP_BATCH_ALIVE_VOTES，即把整批发给 dispute-coordinator；
4. 批次还有硬性寿命上限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用HashMap<ValidatorIndex, 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 = 100ms，1/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 协议

上述主协议已覆盖大多数场景，但文档指出三个必须覆盖的缺口：

1. 非验证者节点可能对尚未上链的投票感兴趣；
2. 节点可能错过投票（尤其是 backing/approval 投票），而从链上恢复它们既困难又昂贵（涉及运行时升级与无类型 extrinsic）；
3. 更关键的是，era 变化后，从 approval-voting 的角度看，新权威集合没有义务查看"旧"approval 投票，因此它们可能根本没见过这些投票，无法导入协调器，也就不会有权威把它们写进链上。

为覆盖这些场景，设计引入第二条请求/响应协议（线格式见上文 3.2 节），以低于主协议的优先级处理。节点在感觉自己缺失投票时可以主动发起IHaveVotesRequest，典型触发时机包括：超时后仍未见多数派达成，或收到某争议候选却不知道任何 backing/approval 投票。

IHaveVotesRequest接收方的处理流程（设计文档）：

1. 检查发送方是否缺少我方已知的投票——若有，用这些投票响应；
2. 检查发送方是否知道我方未知的投票——若有，把我们的已知投票封装成IHaveVotesRequest回发过去；
3. 记录该 peer 的知识（knowledge），供后续判断使用。

何时发送IHaveVotesRequest：

1. 每当被DisputeDistributionMessage::FetchMissingVotes指示时；
2. 只要争议仍活跃，大约每区块一次向某个随机验证者发送。

垃圾消息考量：节点只接受"每个验证者每个 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，可用来验证上述数据流的端到端行为。

• 区块链