Utreexo

安娜想把以前收到的比特币发给彼得，因此她的交易要引用那笔先前的收款。金额及其花费条件构成一条独立记录，称为输出；尚未花费时，它就是 UTXO。新交易的输入包含指向该先前输出的引用，以及花费它所需的数据。节点必须检查记录确实存在，而且安娜还没有把它花掉。通常，节点维护 UTXO set，记录所有当前未花费输出，而不是个人账户和余额。数据库越大，磁盘工作越多。Thaddeus Dryja 于 2019 年提出 Utreexo，希望减轻这种本地负担。 [1] [6] [8]

首先，为每条记录计算哈希，得到数据的短校验指纹。在默克尔树中，指纹两两组合后再次计算哈希，直到得到顶端指纹，即根。Utreexo 使用多棵这样的树；验证节点可以保存它们的根，而不必保存完整列表。对于安娜的输出，节点收到数据以及包含必要相邻指纹的证明，再据此计算到根的路径，与自己已经跟踪的状态比较。因此，仅有发送者的说法是不够的。这种结构称为密码学累加器，可以证明某条记录属于某个集合。不过，根不是压缩备份，不能解压还原出全部原始记录。 [1] [2]

节点先计算收到的数据的哈希，再用证明检查这些数据与自己跟踪的状态之间的联系。不能因为数据来自熟悉的服务器，就接受无效证明。数字签名利用私钥这个秘密数值证明付款获得授权，同时不泄露私钥。脚本规定花费某个输出时必须满足的条件。即使成员证明有效，也不能代替对签名、脚本、金额以及其他交易和区块规则的验证。Utreexo 处理的是状态存储，并没有允许节点跳过这些检查。 [2] [5] [8]

仍然要有人保存足够的数据，才能构造证明。库文档区分了 prover 和 verifier：前者保存完整的默克尔树林，后者只需保存根。验证者可以缓存部分证明，但仅凭根无法生成任意证明。因此，数据并没有消失，只是在参与者之间重新分配了保存责任。 [2]

区块把交易组成一批，加入共同历史记录。输出被花费后，会从跟踪的集合中删除；新的未花费输出则会加入。证明也会随之变化。针对旧状态保存的证明，在后续区块出现后可能需要更新才能使用。链重组时，网络转而采用另一条有效分支，替换原有区块历史的一部分。实现必须处理证明更新、并发交易以及链重组时的回退。证明不是下载一次就永久有效的证书。 [2] [3]

Pruned Node 会在验证后丢弃较早的区块数据，但传统上仍保留当前 UTXO 数据库。Utreexo 针对的正是这份数据库。因此，两者节省的是不同资源，也可以结合使用。无论区块裁剪还是小型累加器，都不意味着节点没有处理历史就完成了历史验证。区块历史、当前状态和初始验证方式是三件不同的事。 [6] [5]

设想一个新节点没有从头验证区块，而是从别人提供的状态开始运行。它实际上假定这个初始状态正确。小型累加器不会消除这份信任：后续证明正是相对于已接受的状态进行检查。因此，在 AssumeUTXO 中，接受 snapshot，即某一时刻的状态快照，与随后在后台验证历史是两回事。utreexod 文档描述的默认启动方式使用程序中固定的状态。这本身并不等于独立验证了此前所有区块。如何启动是单独的选择，不是 Utreexo 的固有属性。 [7] [3]

utreexod 是使用 Utreexo 验证比特币网络的一种实现。在 2026 年 10 月 17 日查阅时，其文档将它标为 beta，并不建议在主网上用它处理不可忽略的资金。文档也列出 --noassumeutreexo，可关闭从假定状态启动的方式。这不是安装建议：使用前应核实最新版本、运行模式、程序来源和恢复方式。 [3]

基本设计不要求改写比特币的货币规则，也不要求修改已有区块。但证明仍需要有人生成、传输和更新，因此参与节点需要相应的软件与通信支持。更小的本地状态可以帮助低成本设备运行。它并不自动意味着每个区块能装更多交易、所有人的手续费都会降低，或所有节点都会切换到新格式。 [1] [4]

磁盘上的数据减少，可能意味着更多网络传输，以及对数据及时可用的依赖。正确验证的节点会拒绝伪造证明，但提供者仍可能不发送所需数据，从而拖慢验证。运营者因此要综合比较存储、传输、缓存、初始状态验证和故障时的行为。Utreexo 可以降低自主验证的成本，却不会让数据缺失变得无关紧要。 [3] [4]