sendheaders：节点之间“有新块了”，从喊编号改为直接递清单

一次公告，两个回合的旧礼数

比特币节点之间通报新区块的传统方式，是发一条 inv 清单消息，里面写上区块的哈希。收到公告的节点如果没见过这块，还要再发一条 getheaders 请求去要区块头，验证父块、难度、时间戳之后才决定追不追。一个回合的往返，在毫秒都重要的区块传播链路上就是硬成本。更要命的是，等对方“喊完编号再问我”意味着：网络里所有节点都靠同一句喊号同时起跑，而区块真正的内容此刻往往已经在某些节点的队列里躺着了。

sendheaders：把清单随喊号一起递过来

BIP130 定义了一条内容全空的消息，只有命令字 sendheaders。节点在连上对手后发出它，等于声明“以后有新块，请把区块头直接推给我”。收到这条声明的节点获得许可（注意是“被允许”而非“必须”），在新块到达时把区块头连同它认为对方连接所需的补充区块一并发送。整个过程跳过 inv 加 getheaders 的一来一回，节点拿到区块头的速度和区块本体进入网络的时刻几乎贴合。公告方仍保留普通 inv 路径的权利，接收方也照常保留验证与否的判断权。

一个往返值多少

传播延迟每缩短一圈，同一高度上“后到的诚实节点”看到的就更多是已连上父链的区块，而不是需要现场重建的孤儿候选。孤块与陈旧的根源是传播的时间差——两条几乎同时被挖出的分支在拓扑上相撞，谁的节点先收到谁赢。公告提速不直接改写概率，但把公告环节的固有等待削减之后，同样的网络直径内，信息差被压缩。后续更激进的方案（例如把整块压缩成短 ID 集合的压缩区块）走的也是同一方向：让区块“到达”与“重建”之间的间隙趋近于零，而 sendheaders 处理的是这些方案都覆盖不到的第一秒。

实现自由与用户视角

规范明确允许实现附加约束，比如只在连接建立后的一段时间内接受 sendheaders 声明，以限制声明方通过反复声明操纵行为。对运行节点的人来说，这个开关早已默认开启：你在日志里看到的多是一次性握手痕迹，而非可选项。真正值得记住的是它体现的演化哲学——不改共识规则、不动数据格式，只在“人怎么打招呼”这一层做文章，就能白捡传播效率。

常见误区

• 误区一：“连的节点多就一定能先看到新块。”公告方式与对等拓扑共同决定首次到达延迟，数量堆不出低延迟。
• 误区二：“sendheaders 会泄露我的地址簿。”消息本身零负载，不携带任何额外身份或地址信息。

本文描述的是协议消息层的机制，不构成投资建议。

把它放回区块传播的整条流水线上

新区块到达一个节点要走几步：收到某形式的公告、取得区块头、验证父块与规则、把区块头继续转发给邻居、同时尝试用最短路径补齐完整交易集。sendheaders 只优化公告方式，其余环节各有对应的机制在管：取得完整交易集靠短 ID 与提前预存的交易，补齐缺口靠直接点名请求缺失交易，防恶意拖延靠请求超时与重排。这些机制层层叠加，才把空块之外普通区块的端到端传播压进一两秒的量级。值得顺手澄清一个流传的说法：孤块并非“坏事”，它是出块随机性与网络延迟的必然产物，协议对重组的容忍正是去中心化设计的成本核算。真正被各类传播优化削弱的，是“人为拉大时间差”的套利空间——谁也不能靠让公告多绕一步来给自己阵营的竞争块争取优势。对节点运维者，这个领域可调的参数早已归入默认值，日志里若出现持续的区块请求超时，更值得怀疑的是带宽与对等拓扑，而非某条公告消息本身。