压缩区块为什么能加快传播：短交易 ID 与集合差集

整块广播贵在哪

比特币的新区块过去要整块发给每个对端：一个装了几千笔交易的区块接近两兆字节，同一个块要对每个连接重复发送，带宽在区块到达的瞬间出现尖峰。而绝大多数接收节点其实早就通过内存池交易转发“见过”这些交易了——真正的新信息只有区块头、交易清单和少数缺席交易。BIP152 压缩区块协议利用的就是这个信息不对称，Bitcoin Core 自 0.13 版本起在兼容对端之间自动启用。

一次压缩区块交互的样子

发送方把区块拆成三部分：区块头、少数“预填交易”（通常是 coinbase 等你大概率没有的交易），以及其余每笔交易一个短交易 ID。短 ID 的生成方式：把连接级的一个随机数拼上区块头做哈希，用它作密钥对每笔交易的 wtxid 跑 SipHash-2-4，截取 6 字节。接收方拿这份短 ID 列表与自己内存池逐一对比，对得上的直接复用本地交易，对不上的用一次 getblocktxn 请求取回，重组出完整区块后照常全量验证。整个过程把带宽尖峰换成了对内存池做一次哈希查找，协议细节见 BIP152。

高带宽与低带宽两种模式

节点对最多三个对端开启高带宽模式：区块一到，连短 ID 一起直接推过来，理想情况下本地一次往返都不用，重建延迟可压到半个网络往返以内；其余对端保持低带宽模式，先照常发区块头公告，被索要时再发压缩版本，省带宽但多花一到几个往返。随机数按连接独立，意味着中间人无法利用短 ID 碰撞稳定定位某笔交易在哪条连接，这是协议为隐私与攻击面设计的细节。对家用节点，压缩区块让“新区块像水一样流过节点”成为日常体验，而它依赖的前提是——你的内存池要足够满。

隐性的策略趋同压力

压缩区块的收益来自“你和发送方大多持有相同的交易”。如果你的节点主动拒收或提前丢弃某类交易（本地费率下限过高、自定义拒绝策略），这部分交易就总要走补拉取路径，你的节点收到该区块必然更慢，在极端情况下更容易站错链边，参见 getchaintips如何识别链分叉？。0.13 发布说明明确点出这一副作用：与全网主流转发策略差异过大的节点，会在陈旧区块竞争中处于劣势。这被普遍视为一种温和的压力，推动各家节点的默认策略向“主流内存池行为”靠拢；节点连接健康度可配合 getnetworkinfo如何看节点连接？ 检查，内存池状态读法见 getrawmempool怎么读取内存池？，完整同步判定见 比特币全节点同步到什么程度才算完成？如何验证区块链完整。

本文讨论网络协议机制，涉及数据均来自公开规范与发布说明，不构成投资建议。

家用节点的两点体会

一是磁盘与带宽的真实感受：压缩区块把块转发从“整块复制粘贴”变成“清单加补漏”，家用百兆带宽也能顺畅跟随链头，过去的带宽尖峰在新版本里平缓得多。二是别把加速同步误认为网络健康：压缩区块优化的是转发路径的稳态延迟，历史区块的初始同步仍走普通下载逻辑，两者互不相干，同步进度判断仍应使用 getblockchaininfo怎样判断同步？。若你想观察自己节点是否在用该协议，可留意连接日志中 sendcmpct 的协商记录；协议对端不支持时自动退回旧方式，这不影响正确性，只影响速度。把它理解成“内存池与区块之间的缓存协议”，你大概率会重新意识到：节点软件里每一处看似微小的设计，都是全网十几年运行的共同成果。