协议演进 / BIP/比特币改进提案 / BIP-332

BIP-332 过时链尖中继

定义可选的 staletip P2P 消息，向对等节点公告近期过时分支的压缩区块头，并标明是否愿意提供对应区块数据。本 BIP 目前处于草案状态。

一、档案卡

二、放在哪一族

P2P 区块中继的旁支族，处理的是“没能成为主链的区块”这一平时被丢弃的信息。既有的 headers、inv、block 等中继消息都是围绕活跃链（active chain）设计的：它们不表达“这一支是落败的过时分支”、该以哪个已知区块为重建起点、发送方是否能提供该分支的区块数据。BIP-332 因此另设一条专用消息，而不复用现成消息去硬凑。

它的协商机制不另起炉灶，而是依赖：

BIP-434：对等节点功能协商，本篇用它来协商 staletip 功能支持，未协商成功不得发送

BIP-324：v2 P2P 加密传输协议，本篇明确不为 staletip 预留它的 1 字节消息类型 ID

BIP-325：Signet，测试网络部分专门讨论了默认 signet 上过时分支的特殊情况

它在定位上是一项可选的对等服务：节点完全验证活跃链、正常服务对等节点，都不需要知道任何过时分支。

三、它要解决什么

矿工偶尔会产出过时区块（stale blocks）：区块本身或其区块头有效，却没有成为节点活跃链的一部分。这类区块目前基本被网络沉默地丢弃，但它们其实是有用的信号。

首先，过时区块的出现率反映新区块传遍全网矿工的速度，出现率异常升高可能是多种网络问题的症状：传播退化或拥塞、网络分区，或自私挖矿等对抗性挖矿行为。

其次，若某个过时区块与当前活跃链尖累计工作量相同，活跃链尖可能被重组为该过时区块的子区块；节点若已提前下载（甚至已验证）该区块，重组会更快。过时区块的内容还能揭示不同矿池之间出块策略的差异。

原文同时强调：这些好处对网络运行并非必需，因此本篇把它设计为可选功能，性能要求低、资源上限严格。

基本术语：活跃链是节点当前选定的最佳链；过时分支是从某个已知区块派生、但其链尖不在活跃链上的一串有效区块头；过时链尖（stale tip）就是该分支的最后一个区块头。

四、规则本身

4.1 staletip 消息

新增一条可选的 P2P 消息 staletip，载荷由三部分组成：

• fork_point（uint256）：分叉点区块哈希，即第一个压缩区块头的“前一区块哈希”所指的区块，必须是接收方已知的区块，通常是过时分支与接收方活跃链的最后一个共同区块，也可以是双方预计都已知的过时分支上的更靠后的区块，此时只发未知的后缀；
• headers：CompressedHeader 向量，按链顺序构成 fork_point 之后的一条单一线性分支，最后一个就是过时链尖；每条竞争分支要单独发一条 staletip；
• have_block（bool）：发送方是否愿意提供该过时分支的区块数据。置真表示发送方当前拥有过时链尖（最后一个头）的完整区块数据并愿意经正常区块下载机制提供，也应愿意提供其拥有的该分支更早区块；置假则对可用性不作任何声称。发送方不应在预期请求会失败时把该标志置真。

布尔值只允许单字节 \x00 或 \x01，其他编码为畸形。向量长度用 CompactSize 编码，只支持最小编码。

4.2 压缩区块头

CompressedHeader 是 48 字节结构，等于普通区块头序列化去掉“前一区块哈希”：依次为 version（4 字节）、merkle_root（32 字节）、time（4 字节）、bits（4 字节）、nonce（4 字节）。省略前一哈希每头省 32 字节，因为它可以从 fork_point 出发逐个重建：以前一个重建出的哈希为 prev_hash 依次组装，后一个头的哈希又成为再下一个的起点。原文解释，为何不进一步压缩 nVersion、nTime、nBits、nonce：这些字段与共识相关且随链变化，压缩带来的重建复杂度与分歧风险不划算。

因为过时链尖非常罕见，本篇不为 staletip 预留 BIP-324 的 1 字节消息类型 ID：每条公告本身至少带 32 字节分叉点与一个 48 字节头，省下 12 字节命令名开销微不足道，而 1 字节 ID 空间有限，应留给高频消息。

4.3 协议常量（推荐上限）

• MAX_STALETIP_HEADERS = 20：单条 staletip 中压缩头的推荐上限，覆盖对重组检测有用的短分支，避免长期追踪持续性分叉；
• STALETIP_RECENT_WINDOW = 1000 个区块：过时链尖距接收方活跃链尖的推荐最大距离，约 7 天；
• MAX_ADVERTISED_STALETIPS = 10：向一个对等节点公告“此前已知的”过时链尖的推荐上限。按此三限，初次告知一个新对等节点的带宽在 10kB 以内。

这些上限被定位为本地资源管理与带宽策略，而非严格的线路规则：不同节点目标不同，可采用更严的上限，单个公告超限本身不应导致惩罚对方。

4.4 用 BIP-434 协商

本篇定义一个 BIP-434 功能 ID BIP332，其功能数据必须恰好 1 个字节，即布尔值 prefers_blocks：\x00 表示偏好只要区块头、不要为等区块数据而延迟公告；\x01 表示偏好带区块数据可用性的公告。数据长度不对或字节取值非法的，接收方必须忽略该对等节点的该功能公告，但不应仅因此断开。

实现本篇的节点必须先用 BIP-434 协商，未广告有效 staletip 功能的对等节点不得发 staletip；收到未协商者的 staletip 应忽略，反复发送者可被断开。广告该功能只表示愿意接收，不构成发送或提供区块数据的义务——比如只做研究收集的节点可以只收不发。原文还解释了为何用 BIP-434 而非协议版本号提升或无协商直接发新消息：版本号提升会把该功能与无关的 P2P 变化绑在一起、暗示过宽的能力；无协商发送则要靠所有节点都安全忽略未知消息。BIP-434 提供的是更窄的能力信号。

4.5 发送、接收与活跃链尖公告

发送侧要点：只公告近期、且未违反区块头共识规则的过时链尖；无法确信对方已知 fork_point 时不得发送；fork_point 应选得尽量让 headers 向量短；不要公告距自己活跃链尖超过 1000 区块的链尖，或长于 20 个头的分支；应设工作量门槛，避免该消息沦为低成本垃圾通道；对连接建立时已知的存量链尖，公告不超过 10 个，优先选累计工作量最大者（工作量相同取最近学到的），也可按对等节点随机抽样以提高全网多样性；同一链尖不对同一对等节点重复公告；尊重对方的 prefers_blocks：对方为 \x00 时应及时发送不等待区块数据，为 \x01 且本方打算取数据时应推迟发送直到拿到数据，除非会显著延迟传播。

接收侧要点：载荷无法严格解析（非最小 CompactSize、截断、非法布尔、尾随字节）应拒绝，畸形载荷可断开；fork_point 未知应拒绝（忽略），反复发未知分叉点者可断开；headers 为空应拒绝；处理时必须限制资源投入，超限的公告可忽略或部分处理，单个超限公告不应惩罚对方，反复超限可限速或断开；通过本地拒绝服务检查后，应重建并验证区块头，单个无效头应忽略而不惩罚。have_block 为真且本方偏好收集完整数据时，应按正常方式（如从重建出的过时链尖向已知区块回溯发 getdata）索取缺失区块。学到新过时链尖后应转告其他已协商的对等节点，但不对同一节点重复公告、不回告来源节点。处于初始区块下载中的节点不应公告、可以忽略收到的消息。

另一个配套要求是活跃链尖的公告方式：为了让对方能推断你的活跃链尖、判断你是否已知某分叉点，实现本篇的节点应始终把自己的新活跃链尖公告给所有对等节点；为省带宽，可用 inv 消息代替 headers 或紧凑区块消息。若收到的过时分支累计工作量超过本方活跃链，应把重建出的区块头送入正常的区块头处理逻辑——这时它对本方可能就不再“过时”了。

实现还应提供彻底关闭该功能的配置选项，并可分别开关过时头的中继与过时区块数据的请求/提供。

4.6 测试网络的额外收紧

测试网络的工作量证明防护较弱、拒绝服务面更大，实现方可只对主网启用本功能。

默认 signet 预计约每天重组一次、分支长度随机，过时链尖在那里并不罕见，长于 20 个头的分支不会经 staletip 中继，而回退到正常区块头同步，实现也可为 signet 提高上限。signet 的区块签名放在 coinbase 交易里，只凭区块头无法验证，因此在 signet 上：没有可用于验证签名的区块数据时不得发 staletip；对 have_block 为假的公告可断开对方；协商时应把 prefers_blocks 设为 \x01。低难度下变换 nBits 可能得到另一个有效区块，这类“变体头”应视为重复，只公告最先见到的那个。

testnet3 与 testnet4 都允许低难度区块，可能出现大量最低难度的有效过时链尖。为此，在这两个网络上应只公告链尖本身难度高于最低难度的过时链尖，也可以采用更高门槛（例如 1,000,000）。

五、谁必须动

普通持币人：无事可做。功能完全可选，节点软件应提供一键关闭。原文专门讨论了隐私影响：协商与中继行为可能让节点更易被指纹识别，把洋葱地址与 IPv4 地址关联起来；对此担心的用户，整体禁用是最佳做法。

全节点与矿工：节点实现者按上述规则实现协商、发送、接收与资源上限。原文给矿工一条特别提醒：运营私有交易池的矿工，将其交易经 staletip 传播出去通常有害无益——赢了过时区块竞赛也只让别人重组稍快，输了则把私有交易白白送给竞争矿工，因此处理自挖区块的节点大概率应整体禁用该功能。原型实现见原文给出的 Bitcoin Core 分支。

钱包开发者：不涉及。钱包不参与过时链尖的中继。

共识层：不涉及。过时分支本就不在活跃链上，本篇只是让节点之间交流这些分支的信息。

六、现在算不算数，以及一个常见误读

状态为 Draft（草案），版本 0.1.0。它还是一份早期草案：消息格式、协商方式与各项上限都以草案文本为准，不能当作已部署的网络行为来预期。原文未声称已有节点普遍启用，本页不臆测采用情况。

常见误读：

“节点收到 staletip 公告，就等于承认对方那条分支，可能会被带偏主链。”

不对。过时分支的定义就是不在活跃链上；接收方要独立重建并验证区块头，无效或超限的公告一般是忽略而非惩罚。只有当某条被公告的分支累计工作量真的超过本方活跃链时，才把它送入正常的区块头处理逻辑按既有共识规则裁决——那已经不是 staletip 本身在决定链的选择了。

七、延伸

• 阅读版：https://bips.dev/332
• 官方原文：https://github.com/bitcoin/bips/blob/master/bip-0332.md
• 相关：BIP-434 对等节点功能协商、BIP-324 v2 P2P 加密传输、BIP-325 Signet
• 仓库总目录：https://github.com/bitcoin/bips

本页内容整理自 bitcoin/bips 仓库与 bips.dev，事实已与仓库核对；解读仅供学习参考。