AssumeUTXO

彼得正在启动自己的第一个 Full Node，也就是自行检查 Bitcoin 规则的程序。区块把交易组成一批，加入共同历史记录。普通启动方式需要先走完漫长的历史。AssumeUTXO 让他从准备好的 UTXO set 开始：这是尚未花费的交易输出集合，每个输出包含金额和花费条件。快照记录某个特定区块之后的状态。它不是全部付款的档案，也不能证明彼得的电脑已经检查了整个过去。 [1] [3]

不能因为文件名看起来可信，就认定快照正确。通过 loadtxoutset 加载时，Bitcoin Core v29.0 会检查格式、基础区块（快照所对应的区块）和支持的参数。它还会计算 UTXO 内容的 hash，也就是密码学指纹，并在激活前与预期值比较。因此，即使文件被起了一个可信的名字，经过篡改的内容也不能凭此通过检查。 [2] [3] [6]

接受快照后，节点从这个状态继续，验证后续区块，并可以追到链的当前末端。它不会照单全收：花费条件和允许新增的比特币数量等规则仍然要检查。好处在于，通往当前网络状态的这条路径不必等待更早历史全部处理完。不过，这并不意味着那些历史已经在本地验证过。 [1] [6]

与此同时，第二个状态根据历史区块逐步建立，从起点走到快照的基础区块。这是依据历史进行的独立计算，不是把下载的清单再复制一份。因此，程序会暂时维护两个进度不同的状态。技术命令 getchainstates 可以显示它们。活动状态追上最新区块，本身并不能证明后台工作也已经结束。 [1] [8]

预期 hash 和支持的基础区块属于特定的软件版本。在彼得的节点自行算完历史之前，它依赖这项内置信息的正确性。比较 hash 可以检查内容是否一致，但仅凭这一点无法证明这些内容来自有效的历史。如果预期状态错误，节点提前投入使用时就会建立在这个错误假设之上。这也是为什么，后续的历史验证不能与加载时的文件检查混为一谈。 [2] [6]

文件可以来自另一位运营者，但这不赋予他决定节点接受什么状态的权力。决定因素是与软件支持的数值一致，而不是提供者的承诺。也不能加载任意区块的任意快照：支持范围取决于软件版本和网络。Hash 检查既不能保证对方一定交付文件，也不能免去下载和处理所消耗的时间、带宽和磁盘空间。 [2] [4] [7]

后台工作到达同一个基础区块时，节点会计算自行建立的 UTXO set 的 hash，再与快照的预期 hash 比较。这不是拿今天的状态与旧照片对比：双方对应的是同一个历史位置。如果不一致，这里描述的实现会停止节点，并停止使用由快照推导的状态。它不会隐藏差异，也不会把不一致报告成验证成功。 [1] [6]

AssumeUTXO 主要改变的是节点多早能够使用。历史下载和验证仍然继续，期间还要暂时维护两个状态数据库，因此处理器和磁盘仍有负担。Pruned Node 通过删除已处理的旧区块文件来节省空间，并不会省略规则检查。Pruned Node 也能使用快照，但节省存储有自己的限制。某些辅助索引必须从最早的历史开始处理，所以节点更早可用，不代表所有连接的应用也立刻准备完毕。 [5] [7]

UTXO set 保存的是未花费输出的信息，不是授权花费所需的私钥。数字签名利用私钥这个秘密数值证明付款获得授权，同时不泄露私钥。UTXO set 不是钱包备份，不能找回丢失的 Seed Phrase，也就是采用这种机制的钱包所使用的恢复词。旧付款也未必马上出现：查找它们可能需要快照之前的区块。备份密钥、查找自己钱包的历史，以及验证网络状态，是三件不同的事。 [1] [7]

相似的名称容易引起混淆。AssumeUTXO 从加载的状态起步，在后台补算更早的历史。assumevalid 则会在特定条件下省略部分历史脚本检查，也就是包括签名在内的花费条件检查。这是一项独立优化，也可能影响历史验证；单凭 AssumeUTXO 已完成，不能判断它是否被关闭。阅读教程时，要区分节点从哪里开始、实际检查了什么，以及各项检查何时结束。 [5] [6]