Utreexo实现道路上的进展

在 2020 年 7 月放出的最新演示中，我们表示 Utreexo 项目将在 btcd（比特币的一种 Go 语言实现）中实现 Utreexo 累加器。现在，我很高兴能郑重地宣布，这个实现已经准备好发布下一个演示了。在这次发布中，我们可以演示一种叫做 “致密状态节点（Compact State Node，CSN）” 的新型修剪模式。

我在 2020 年 4 月发表的文章 “ELI5: Utreexo – A scaling solution”（中文译本）中，我陈述了 CSN 可以提供的诸多好处。这些主张包括：

1. 只需下载几千字节就可以成为一个新的全节点，机械硬盘（HDD）同步起来和固态硬盘（SSD）一样快
2. 允许在节点初次加入网络、下载区块时并行化下载
3. 让共识过程可以独立于数据库的实现，从而增强比特币的安全性（当前比特币软件的数据库是谷歌开发的）
4. 不需要实施硬分叉，就可以将 Utreexo 引入比特币网络

按照当前的开发进度，第 3 项和第 4 项好处已经实现了。第 1 项算是部分实现了，因为节点体积进一步削减的瓶颈在于非 Utreexo 的数据。第 2 项好处则还在开发中。

为什么好处 # 3 很重要

通过让共识运行独立于数据库的实现，来加强比特币的安全性（比特币实现当前使用的数据库是由谷歌公司开发的）

这几年来，提升比特币安全性的一个重要焦点，就是移除比特币的所有对外依赖。所谓对外依赖，就是一些并非由比特币开发者编写、但对比特币软件的运行是必要部分的代码。对外依赖在所有安全敏感的的项目中都是要尽可能避免的，因为它们可能是 bug 的来源。这种风险可以通过审核依赖库、维持使用经过审核的代码备份来缓解。但是，这种办法也不是完美的，对外依赖也不如使用比特币开发者直接编写、测试和审核的代码。因此，比特币开发者一直在移除对外依赖（移除对 OpenSSH 代码的依赖就是一例）。

当前，最大的对外依赖就是数据库，因为 UTXO 集和区块索引都是存储在数据库中。现在比特币软件使用的数据库来自谷歌，叫做 “LevelDB” 。因此 LevelDB 没有 bug 就对比特币的安全性至关重要。如果 LevelDB 中有 bug，它可能允许某人多重花费同一笔钱，或者导致意料之外的分叉。实际上，在 2013 年，Bitcoin Core 软件中对 Berkeley DB（在 LevelDB 之前使用的数据库软件）的错误运用就导致了旧的 Bitcoin Core 节点在读取 225430 号区块时出错，最终导致了一次意料之外的分叉。

（上面提及的 UTXO 集是当前所有可以花费的比特币资金的数据表示。这个 UTXO 集对比特币安全性是生死攸关的，因为它直接就是比特币共识的一部分；移除对 LevelDB 的依赖可以极大地提升比特币的韧性。）

实现好处 #3

总的来说，需要一个数据库是因为 UTXO 集合中有超过 6000 万条 UTXO，而所有 UTXO 都必须被跟踪而且能快速访问，因为缓慢的访问会降低初次区块下载的速度。数据库软件经常用在这种需要快速访问大量微小数据的情形。

不过，有了 Utreexo CSN，我们就完全不需要数据库了。相反，我们只需让 UTXO 的发送者提供该 UTXO 以及相应的 Utreexo 累加器证据，证明该 UTXO 存在即可。因此，我们不再需要在 Utreexo CSN 实现中跟踪一个 UTXO 集。又因为我们不需要跟踪 UTXO 集，我们可以将 LevelDB 从比特币共识的另一个关键部分中移除。

下图是当前的区块验证与 Utreexo CSN 区块验证的区别：

唯一的区别在于，Utreexo CSN 的区块验证不需要访问数据库。相反，它是验证 Utreexo 证明。