离线导块参数 loadblock：没有外网的比特币节点怎么补账本

一、先把”离线导块”和”离线签名”分开

这两个词经常被混在一起说，实际解决的是两个完全不同的问题。离线签名解决的是”私钥不接触联网机器”；离线导块解决的是”这台节点没有可用的互联网出口”。前者关心的是密钥暴露面，后者关心的是数据怎么搬进来。 Bitcoin Core 在启动参数里为后者留了一个专门的口子：-loadblock=<file>，官方说明只有一句话——启动时从外部文件导入区块。它读的是节点自己写出来的那种区块数据文件，不是任意格式。

二、它到底在什么时候起作用

关键在于时机。这个参数只在进程启动阶段被处理一次，属于”开机补作业”型选项：节点先正常加载已有的区块目录和链状态，再把指定文件里的区块依次喂进正常的验证流程。也就是说，从这一刻起，这些区块要走的路径和从网络收到的区块完全一样——查父块、验默克尔根、逐笔验签、更新未花费输出集合，任何一条共识规则都不因为”来自本地文件”而豁免。

这就推导出几个实用结论。第一，文件放错顺序不重要，内容本身有严格的前后依赖，缺了父块就先卡在缺的那一环。第二，导入失败不会”回滚一半”，而是按标准流程拒绝无效区块并记录日志，排查方向和网络同步时一致。第三，它不会跳过同步状态：如果你的节点还差三万个区块，指望拷两个文件追平是不现实的，一次能补的量取决于文件本身装了多少块。

三、文件从哪里来

最省事的来源就是另一台正常同步的 Bitcoin Core 节点。数据目录下的 blocks/ 里放着成批的区块文件，命名规则是固定的十六进制分段。把其中一段拷贝出来，在目标节点的配置里用 datadir 指好位置，用该参数指向具体文件，启动即可。需要注意两点：文件体积随分区段差异很大，移动介质要留出余量；拷贝过程最好带校验，一个坏字节会让这一段之后的区块全部验证失败。

有些做法是先把节点切到只写文件的中间角色，跑一阵再导出，本质上是同一件事：让文件里的区块高度、哈希和链上前后关系保持完整，导入端才有可对接的接口。

四、什么场景值得这么折腾

第一种是没有稳定外网的环境：隔离网段的审计节点、内网合规留存节点、野外或船载等弱网站点。这些场景的共同点是”数据可以慢，但不能来路不明”，物理介质反而比不可靠的链路更可控。

第二种是排障。怀疑某个区块在传播路径上被截断或损坏时，把已知正确的文件在本地重放一遍，可以快速区分”网络传输问题”和”本机数据问题”，比反复重下整个链省时间。

第三种是气隙环境的账本核对。一台只读性质的节点负责回答”某个地址在某天之后还有没有动过”，它不需要联网，只需要账本是完整的。

五、边界与代价

必须清楚这个参数不能做什么。它不提供任何隐私保护——为了把缺口补齐，节点最终通常还是要连网；它也不改变索引策略，如果目标节点开了交易索引或区块过滤器索引，导入过程会顺带维护这些索引，磁盘和内存开销比裸同步更高，一次可承受的跨度相应下降。

还有两点容易被忽略。其一是信任边界：文件来自哪台机器，就把那台机器的正确性假设带进来了。正确的做法是导入端仍按最重链规则独立判定，不要为了省事去关掉签名检查或降低校验等级。其二是版本差异：跨大版本搬运时，新区块目录的布局和组织方式有过调整，旧节点读新格式或反过来都可能直接报错，搬运前先确认两端版本，比事后 debug 划算得多。

把这三段连起来看，-loadblock 的定位非常窄也非常清楚：它是一个补数据的入口，不是一个同步方案，更不是一个隐私方案。适合它的场景只有一个特征——数据必须进得来，同时不希望这条通路是长期常开的网络通道。