AssumeUTXO 快照同步：新节点第一次同步到底'假设'了什么

全节点同步慢在”重放历史”

新节点要从创世块开始逐块重新执行所有交易，才能建立”现在哪些钱可花”的账本（UTXO 集合）。这条初始块下载路线是去信任的基石，代价是数小时到数天的验证时间。AssumeUTXO 的想法：先拿一份别人生成的 UTXO 快照当起点，把历史验证挪到后台慢慢做，让节点几分钟内就可用。

机制三步

第一步在源码：每个受支持的快照高度对应一个硬编码哈希，由开发者在评审中核对写入代码——你信任的不是下载站，而是随二进制一起审进主分支的那串哈希。第二步加载：Bitcoin Core 26.0 起提供 loadtxoutset，读取 dumptxoutset 生成的快照文件，校验哈希后把它装进一个独立的快照链状态，节点立刻从快照高度往链尖追块。第三步后台验证：原有链状态同时在后台从创世块全量验证，getchainstates 能看到两条线各自的高度，后台追平快照底块后合并，完全信任恢复。

“假设”的到底是什么

你假设的只有一件事：源码里那串哈希对应的 UTXO 集合是对的。快照文件本身来自第三方下载（HTTP 或种子）无所谓，哈希校验兜底；快照高度之后的一切区块照旧逐块验证，与任何其他节点没有任何区别。这份信任假设与主程序里的 assumevalid 属同一族：用评审过的常数换启动速度，信任窗口有明确的边界和到期时间——后台验证完成那天，假设就作废。

与检查点的分野

旧节点同步早就有检查点机制：在若干历史高度钉住区块哈希，之后的块不必检查历史工作量证明的累计细节。检查点假设的是”这条链在这些块上是对的”，AssumeUTXO 假设的是”这个高度的余额表是对的”，两者可叠加使用，但后者把可花余额的起点显式化了，验证从”继续信任链”变成”限期证明起点”。

运维与误区

快照文件可以在加载完成后立刻删除省空间；剪枝节点也能用快照，这是它与传统 IBD 在磁盘规划上的重要差别。三个常见误区：第一，把快照同步的节点当轻节点——它依旧全量验证快照高度之后的每个块，边界只在此前；第二，找不到”官方快照站”就慌——项目刻意不指定唯一来源，你可以从任何已同步节点自己导出再比对哈希；第三，拿 getchainstates 里较低那条线的进度判断”同步失败”——后台验证按设计就慢，追平前节点对快照之后的数据同样可信可用。机制描述以 v26 起的主线行为为准，未来版本对流程的简化以发布说明为准。本文只做机制科普，不构成任何投资建议。

快照文件本身长什么样

快照是一个紧凑的二进制序列：UTXO 集合按出点排序逐条写入，每条包含金额、高度、是否 coinbase 与脚本公钥，头部带版本与基础块哈希。dumptxoutset 用 latest 类型对当前链尖生成，用 rollback 类型回退到指定高度生成——后者正是重新算出源码中硬编码哈希、自证快照可信度的工具，你可以在自己的节点上重算并比对，不必信任任何发布页。加载成功后快照文件可以删除，因为内容已经装进内存并落进数据库。需要提醒的是内存规划：加载瞬间数据库与内存压力偏高，loadtxoutset 文档建议放宽 RPC 客户端超时，慢盘机器要预留比常规同步更多的观察时间。对自动化部署，判断”何时可以对外服务”的正确信号不是快照线追平，而是后台链状态与快照底块汇合、getchainstates 只剩一条线的时刻——那时你的节点重新拥有从创世块以来的完整自证能力。若中途后台验证发现历史与快照哈希矛盾（理论上极难发生），节点会明确报错而不是静默降级，此时应保留现场并检查快照文件与二进制版本是否配套。