Utreexo实现道路上的进展

需要做的代码变更非常小，区块验证函数的大部分内容都可保持原样。在检查完累加器证据之后，当前经过验证的 UTXO 数据（为验证当前区块所必需）被转化成现正使用的 UTXO 集缓存结构，叫做 “ UtxoViewpoint”（在 Bitcoin Core 软件中则是 “CCoinsView”），然后传递给现正使用的验证函数。

好处 # 4 的重要性

为比特币引入 Utreexo 不需要分叉

需要一次分叉来增加新功能是比特币这样的去中心化系统的一个很大的挑战（风险）。在比特币上施行硬分叉基本上是不可能的，因为从启用一个新功能中获得的好处不足与对冲链分裂的风险。软分叉也是很难推行的，因为需要社区的大部分人买账才行。

另一方面，如果一项新功能只需选择加入即可使用，不需要分叉，则这样的功能的开发工作也会变得简单许多。“BIP-152：致密区块转发” 即是一个很好的例子：它被广泛接收了，而且不需要分叉来引入。喜欢致密区块转发功能的用户可以主动开启，又因为这项功能是选择性加入了，其他不感兴趣的人无需做任何变更。

实现好处 # 4

这是最容易实现的一个主张，因为在 Tadge Dryjx 第一次写作 Utreexo 论文的时候，这个问题就已经解决了。我们通过使用叫做 “桥节点（bridge node）” 的传统节点来沟通 Utreexo 节点和现有的比特币节点，从而避免软分叉。

在遇到非 Utreexo 节点的连接时，桥节点的表现与当前的比特币全节点没有区别。不过，当 Utreexo 连接连入时，它将在为之提供普通区块的同时提供相应的 Utreexo 证明。

我们的发布文档中也提到，Utreexo 的二进制代码中硬编码了它只会连接到我们运行的桥节点，免得干扰比特币的测试网络。

好处 # 1 的重要性

只需下载几千字节就可以成为一个新的全节点，机械硬盘（HDD）同步起来和固态硬盘（SSD）一样快

上面提到的 UTXO 集是运行一个全节点的必要前提。不过，随着用户数量的增加以及比特币被分割成越来越小的数额，UTXO 集的体积也日益增大。当前，UTXO 集的大小约为 4 GB，但它还会逐渐扩大，可能会变成普通亲民设备无法处理的规模。如果比特币想容纳更多用户，给 UTXO 集瘦身就是至关重要的。

在当前的比特币节点中，任意一个 UTXO 被区块引用时，节点都要检索出这个 UTXO，无论是从硬盘中检索，还是从内存的缓存中解锁。这就是比特币当前面临的瓶颈之一，因为节点的硬盘速度可能较慢。在剪枝节点（pruned node）中，它更是一种约束，因为当区块被修剪掉，缓存的 UTXO 会写入到硬盘中。结果是剪枝节点在同步时会比不修剪的节点要慢，如比特币开发者 Pieter Wuille 在此处所述。

有了 CSN，就不存在这种迟滞了，因为根本没有在硬盘中读取 UTXO 集的需要。结果是，CSN 在不同的存储设备上的表现会一致，不论是 nvme 固态硬盘还是机械硬盘。

好处 # 1 的开发进展

“只需几千字节就能运行一个全节点” 尚未实现，因为其它元数据（包括区块头）也又几百 MB 的大小。即时链状态本身很小，要想实现 “几千字节的全节点”，其它数据也显得不可小视。在这一个版本中，我们的最终成果是几百 MB。

跟 Bitcoin Core 相比，只比较链状态的规模的话，就如下图所示：

如你所见，Utreexo CSN 的链状态体积只有 424 字节，因此，对于整个节点的体积来说，基本上可以忽略不记。实际上，用来记录已知对等节点以备在重启时连接的 peers.json 文件，都有 205 kb，是链状态的约 483 倍。

这里还有 Bitcoin Core 剪枝节点和 Utreexo CSN 节点在使用 NVMe 固态硬盘和机械硬盘时候的性能表现。

测试的方法是让被测试的节点连接另一个本地的 Utreexo 桥节点，并且桥节点会从一个单独的 NVMe SSD 上读取数据。做测试的网络是 testnet3，Bitcoin Core 使用了假设有效（assumevalid）模式，设到区块号 186 4000 处；CND 也实现了 assumevalid 模式，并设到区块号为 186 4000 处。测试在 testnet3 达到 190 6000 高度时完成。