新节点第一次同步时，进度条常常先以极快的速度冲到接近链尖，然后突然慢下来开始啃真正的区块数据。这不是卡顿，而是比特币节点同步策略的真实形状：头先行。节点先把整条链的区块头拉完、选出累计工作量最大的合法链，再回头补每个块的完整交易。理解这个顺序，才能看懂同步日志、排查”卡在某个高度”的问题，也能明白为什么重组在节点视角里总是便宜的动作。
区块头为什么值得单独先行？答案在体积比上。一个区块头固定 80 字节：版本号、前块哈希、默克尔根、时间戳、难度目标位、随机数，六项而已。而主网一个满块动辄上兆字节。也就是说，用几十万分之一的代价，节点就能先把”这条链的形状”——每个块的父子关系、累计工作量、时间戳序列——完整拿到手。先建目录再读正文，整个同步过程因此获得一个关键能力：在碰任何一笔交易之前，先独立复核工作量证明。每个头里的难度目标位可以逐块验算，累计工作量最大的链在哪、哪条分支是孤链，在纯头的层面就有唯一答案。等区块体下载进来时，节点已经知道该把每个块挂到树上的哪个位置。
第二个能力是抗欺骗。假设节点不分两步、直接对着某个对端递来的区块流照单全收，一个恶意对端可以用”看似连续但内容篡改”的块序列把节点引上一条假链，或者故意喂更慢但”故事更顺耳”的历史。头先行加工作量裁决把裁决权从”谁递块”挪回”谁的算力证据多”：请求区块体之前，节点已经知道目标链的哈希承诺；区块的默克尔根与区块头绑定，块体里任何一笔交易被改动都会让默克尔根对不上而整块作废。头先行不改变任何共识规则，它只是让共识规则以最低成本最先落地。
实现层面有两条节奏值得知道。其一，头消息是有配额的：一次 headers 消息最多携带两千个区块头，节点向单个对端按批次要头，并对响应设超时—— Bitcoin Core v31.0 源码 net_processing.cpp 里定义了收到 getheaders 响应的等待窗口以及”头同步阶段的超时基准为 15 分钟、每个未到达头追加 1 毫秒”的放宽逻辑：链越长、落后越多，允许的等待越宽。其二，区块体的下载是并行分摊的：节点在已确认的链上按高度顺序派发下载任务，v31.0 源码规定每个对端同时最多 16 个在途块（MAX_BLOCKS_IN_TRANSIT_PER_PEER 常量取 16），并根据”其他对端也在下载同一高度”的数量动态延长单块超时，避免多端重复拉同一块浪费带宽。同步速度因此主要受最慢对端与磁盘吞吐牵制，而不是单连接带宽。
头先行还顺带解释了重组为什么便宜。链尖附近出现分叉竞争时，节点手里两边都只有头：比较两条分支谁的累计工作量大，只需要头里的难度位做加法，毫秒级就有结论。输了的那条分支被标记为孤块候选，它的交易要么已经在内存池等着被打包，要么随分叉回退后重新排队——区块体根本不需要重下。假如没有先行拿到全部头，每次分叉都意味着现场下载两边完整区块来”试吃”，重组将从毫秒判断变成分钟级搬运。这也是为什么日志里”block from peer considered potential tip”发生在区块体落地之前。
顺带澄清与两个功能的接口。assumevalid 那类”跳过历史脚本验证”的快进选项，跳过的只是区块体阶段的签名检查，头阶段的工作量复核一行都跳不过去——快进模式下节点依旧验完每个头的算力证据。剪枝模式（prune）也不影响头先行：头链必须完整（八十字节的链史无论如何都留全），被裁掉的只是区块体文件。换句话说，头先行是所有节点形态共同的骨架，磁盘策略只决定块体在你机器上停留多久。
最后是一个普通用户能直接感知的建议：看同步进度时别只盯百分比，注意日志和 getblockchaininfo 里”验证高度”与”区块头高度”两个数。头高度追上链尖而验证高度落后，说明你处在正常下载块体阶段，剩下的只是时间与带宽；两个高度一起卡住不动，才是要查网络对端、防火墙或磁盘的健康问题。同步卡很久的人有一半在做前者，却以为自己在处理后者。
风险提示：本文描述节点同步机制与参数语义，参数值以所用 Bitcoin Core 版本源码为准；内容不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。