头先行同步：比特币节点为什么先啃完区块头再下正文

新装的比特币全节点第一次同步链，屏幕上滚动的是区块高度和百分比。多数人以为这个过程是『从创世块开始一块块往下载』——两千年代的比特币浏览器插件确实这么干过。现代 Bitcoin Core 早就换了两段式的头先行（headers-first）策略：第一段先把整条链的区块头以极快的速度拉到本地并验证，第二段再回头把每个区块的完整正文补齐。这个顺序颠倒看似只是工程优化，实际改变了同步的安全性质、带宽曲线和故障模式。看懂两段流程，日志里那些 downloading blocks、high connection id 与断点恢复才读得明白。

先认清两种数据的体量差

一个区块在网络上分两层存在。区块头是固定 80 字节的骨架：版本号、前块哈希、默克尔根、时间戳、难度目标（nBits）和随机数（nonce）——仅凭这些字段就能独立验证这个块『按规则被挖出来』了吗。区块正文则是几兆到几兆不等的全量交易清单，验证它要做完整的脚本执行、签名校验、UTXO 查找。数字上：整条比特币链的区块头总量只有几百兆，十万分之几的体积里浓缩着全部工作量证明证据；正文则是几百千兆。头先行的全部聪明就建立在这个不对称上——花几分钟到一小时先拿到并验证一条无法伪造的骨架，再放心把肉慢慢补上。

第一段：把骨架链拉直

节点向对端发 getheaders，附上自己已知的若干锚点哈希；对端回一条 headers 消息，最多塞 2000 个头。节点收到后逐个检查三件事：难度目标是否满足按周期重算的规则、实际哈希是否低于目标值（工作量证明本体）、时间戳与中位数规则是否合规——不跑任何交易、不碰脚本，纯粹哈希计算，因此验证速度能跟着网络跑满。验证通过就挂进本地的头链索引，再以链尾继续发起下一轮 getheaders。对端撒谎怎么办？伪造头过不了工作量证明关卡：没有算力的对端连一个合法头都造不出，能递上来的头链就是真链；分段递送中途分叉也不怕，头先行天然比较累计工作量，选最重的链，轻链残段自动搁浅。这一段结束时，节点已经对『哪条链最长、每个区块的哈希承诺是什么』有了完整、可独立验证的答案——尽管它手里还一个交易都没有。

第二段：按承诺领正文

骨架在手，正文按队列拉取：节点从最高处往低处排 getdata 请求（高块先下，方便更早赶上网络前沿；早期版本也支持从低往高，策略会变但逻辑不变），从多个对端并行下载，每块到手逐笔验证交易与默克尔根。关键的安全红利在这里兑现：正文到手先算默克尔根和区块哈希，跟骨架里已验证的承诺比对——对端塞进来的任何篡改交易都会改变默克尔根进而改变区块哈希，一个字节的改动都让这块与头对不上、被丢弃重下。也就是说，第二段是『明知标准答案再抄写』的核对过程，单个恶意对端送假块的成本是找回原块字节级的难度。这正是头先行相对逐块同步的本质安全升级：老式逐块模式里，节点在追上头之前对『正确历史』毫无独立判断能力，前几十个块全凭前几个连接说了算。

进度条背后：队头阻塞、孤块与中断恢复

运维视角下头先行有几条值得知道的行为。断点续传是免费的：区块头表与已下正文都持久化在数据目录，重启后从未完成队列继续，不会从头再来。高块优先意味着中途网络分区时，本地视图可能『顶部新底部旧』地短暂不一致——同步完成的标志是底部也补齐、状态数据库追平。孤块场景照常成立：两个对端各递来同一高度的不同合法块，正文验证都有效，节点按累计工作量裁决正史，另一块进入孤儿库等待被后续链收养或废弃。防卡死的细节：某高度正文若总是验证失败，节点会换对端重试并记录不良行为分数，反复耍赖的连接会被断开并临时封禁——同步风暴里的惩罚机制与日常 P2P 的 misbehaving 记分共享同一本账。磁盘侧的对应物是 prune 模式：允许在保留骨架与近期数据的前提下扔掉旧正文，让『全节点验证』可以在有限磁盘上维持头先行带来的安全底线。

与快照类同步的关系

头先行解决的是『默认信任为零』的同步。追求速度的场景有另一族方案：assumeutxo 类快照同步把某高度附近的 UTXO 集打包给你，跳过其下正文的逐块重验，配合照常进行的头验证换取数量级的提速——它信任的是发布快照时的软件版本而非某个第三方服务器，性质上仍是共识规则内的选择。两类方案常配合出现：先头先行追平头链，再用快照或常规下载补状态，日志里表现为两段进度。判断标准始终是同一句：哪些事你自己验了，哪些事你委托给了默认发布线。