5分钟了解MIT比特币改进方案Utreexo，手机运行全节点不再是梦

写在前面： Utreexo是由闪电网络（LN）论文作者之一Tadge Dryja提出的，它是一种适用于比特币的哈希累加器方案，目前该方案主要是由MIT数字货币计划在负责资助开发，而本文作者Calvin Kim则是该项目的活跃开发者之一，在这篇文章中，他简单解释了Utreexo的原理，并总结了该方案的4大优点以及2个负面影响。

（图片来自：tuchong.com）

快速概述：在Utreexo中，一个全节点能够为每个区块只保留一个哈希，而传统的修剪版全节点则必须为每个区块保留所有的UTXO。

为了理解Utreexo，我们首先要了解哈希树是如何工作的。这里要研究的就是默克尔树（Merkle tree），它也是比特币所使用的哈希树。

一棵拥有8个子叶的默克尔树看起来会是这样的：

图1:典型的默克尔树

比特币中，最下面一行的所有数字都是交易ID（TXID），00与01的连接哈希结果就是08，13则是10与11的连接哈希结果。

目前在比特币中，默克尔树被用于在区块头中生成默克尔根（merkle root）。而Utreexo采用了默克尔树的概念，并将其应用于UTXO。需要注意的是，Utreexo不会替换区块头中的默克尔树。

目前，要运行一个比特币全节点，你必须存储所有存在的UTXO，而在Utreexo中，你运行的全节点只需要存储UTXO的根。然后这棵树看起来会是这样的：

图2:仅存储根数据的Utreexo树，注意，所以其它的哈希都被删除了

如果用户想要花费UTXO 07，他们必须向你证明交易的存在。这将通过提供（06, 07, 10, 12）来完成。然后验证节点将使用接收到的哈希创建一棵单独的树：

图3:用于验证的树，注意如何从该树计算出根

Utreexo稍微会复杂一点，它的工作方式与此示例有所不同，但这是其概念的一个简单版介绍，其解释了如何只存储一个哈希（而不是所有的哈希），但仍然是一个全节点。

  Utreexo能够带来的优点   优点1、可实现几千字节的全节点，且在硬盘驱动器（hdd）的同步速度可与固态硬盘（ssd）一样快 目前，全节点有两种类型：存档型（Archival）和修剪型（pruned）。在修剪型全节点中，用户只保留未使用的交易输出（也称为UTXO）。而Utreexo允许另一种称为致密状态节点（或CSN）的全节点模式，在其中，我们只存储根信息和钱包信息。这使得一个全节点的数据可小于1 KB，而当前比特币使用的全节点，用户需存储的数据是以GB单位来衡量的。

随着比特币应用的增加，仅存储属于用户UTXO的能力就变得越来越重要。由于一个用户至少需一个UTXO（而且出于隐私原因，需要更多的UTXO），这将导致UTXO的增加。从下表中，我们可以清楚地看到UTXO经历的增长。

图4 :UTXO计数，排除OP_RETURN

另外，由于致密状态节点（或CSN）可以在少于千字节的大小内表示整个Utreexo状态，因此无需在初始区块下载期间查询磁盘。这使得初始区块下载仅发生在RAM上，从而让hdd节点能够像ssd节点一样快速同步。 优点2、允许初始区块下载的并行化 UTXO快照是指在特定的区块高度保存所有UTXO状态。这方面的一个潜在应用是assumeUTXO项目，它允许从快照高度同步区块链。而快照的主要障碍，在于其大小是相当大的，目前约为5GB，并且其大小将随着“优势1”中状态的增长而增长。对于Utreexo，在最坏的情况下[1]，小于1 KB是可能的（最好的情况大约是100字节）。使用Utreexo进行UTXO快照是非常简单的，ZKvM项目已经实现了Utreexo，并且正使用它通过在区块头中包含Utreexo树根来保存区块链状态。

由于快照的实现已经变得非常经济，因此在每个区块高度都有一个快照就变得可行的了。如此，我们就可以并行完成区块链同步的实现，这意味着一台计算机（或CPU核心）可以从区块高度0同步到300,000，而另一台计算机可以从区块高度300,001同步到600,000。而随着CPU的优化及GPGPU的兴起，这种异步区块同步，将有助于进一步减少启动比特币全节点所需的时间。 优点3、Utreexo可增强比特币的安全性（允许将共识代码与数据库分离） libconsensus项目旨在将共识代码从Bitcoin Core 中分离出来，以便： 可以更改非共识代码，而不必担心会破坏共识；允许在不同的比特币实现中使用一种共识API； 但由于很难将数据库（leveldb）与共识代码分开，因此它最终被废弃掉了。

这是一个非常重要的问题，因为在2013年，Bitcoin Core从Berkeley DB转移到了levelDB，并遭遇了一次意外的临时硬分叉，一次意外的临时软分叉以及一次硬分叉(BIP50)。

目前，比特币的共识依赖于levelDB的正常运行，这意味着如果levelDB不能正常工作，则可能会存在使用另一个数据库的分叉。

而使用Utreexo之后，你可以根据Utreexo树验证传入交易或区块，而不需要数据库。这通过使用随附的证明检查传入交易正在花费的UTXO的存在性。 优点4、部署不需要分叉 在缩小区块链大小方面，由Boneh等人提出的RSA累加器，确实要比Utreexo更有效，然而，实现这种方案必须要用到软分叉。而对于比特币这样的保守系统而言，即使是软分叉也是需要非常小心的，也因此，这些类型的累加器很难被应用于比特币。而 Utreexo的部署，是不需要任何分叉的，用户只需通过运行Utreexo节点来选择性使用Utreexo即可。

  Utreexo会带来的缺点   缺点1:带宽需求会额外增加20% 假设情况下，有人生活在一个非常偏远、且带宽非常小的地区，而其使用了一台强大的计算机来同步一个比特币节点，那么Utreexo带来的不是帮助，而是一种伤害。前面提到的证明必须与TXO一起发送，这导致从对等节点下载的数据会多出20%左右。

从这个意义上讲，Utreexo可被看作是带宽和存储需求之间的一种权衡。如果你认为存储价格（hdd，ssd）与互联网速度（及成本）相比是更大的障碍，那么Utreexo可以有助于去中心化。而如果你认为互联网速度是一个更大的障碍，那么Utreexo会有损去中心化。 缺点2 ：Utreexo存档节点的附加存储要求 所谓Utreexo存档节点，是指存储Utreexo节点所需上述证明的现有比特币存档节点。

这种节点会存储： 从创始区块开始的所有区块；从创始区块开始的所有证明； 因为#2的原因，这将给存档节点带来额外的存储负担。如果一个Utreexo存档节点存储每个区块的所有证明，这将是大约100%的额外数据存储。

然而，这可以通过不为每个区块存储证明而得到改善。比方说可以为奇数区块存储证明，如果节点从偶数区块中请求证明，则进行“重同步”。例如，如果请求区块566的证明，则Utreexo存档节点将： 检索区块566；检索在区块565处形成的Utreexo树；将来自区块566的交易应用于Utreexo树，然后重新生成证明；将生成的证明发送给请求它的节点； 然后，这可以进一步进行优化，比如每10个区块存储证明，依此类推，从而进一步减轻了存储负担。

最终，用户可以在cpu使用和存储之间进行权衡取舍。如果用户可以访问廉价的数据存储，他们可以选择存储所有区块的所有证明。如果用户的存储空间有限，但其有空闲的CPU时间，则可以选择减少存储量并进行更多计算。

  结论  

总结来说，Utreexo和其他方案一样，代表了权衡。我相信，Utreexo将通过让用户选择最适合自己的折衷方案，从而有助于让比特币实现更高程度的去中心化。

目前开发者们正在积极开发Utreexo（github.com/mit-dci/utreexo），对于任何贡献，我们都将不胜感激:)

非常感谢Tadge Dryja、Ruben Somsen、Paul Grau以及Janus Troelsen审阅了本文。

脚注：

1.在Utreexo当中，你有时必须保留多个根，不同区块高度保留的根数量是不同的。在Utreexo论文以及MIT比特币博览会Utreexo简介视频中，有关于这个问题更详细的解释。?

本文链接：https://www.8btc.com/article/582470转载请注明文章出处

—-

编译者/作者：玩币族

玩币族申明：玩币族作为开放的资讯翻译/分享平台，所提供的所有资讯仅代表作者个人观点，与玩币族平台立场无关，且不构成任何投资理财建议。文章版权归原作者所有。