使用 Utreexo 累加器加快区块链验证速度

摘要:在这篇文章中,100x 集团的受资助人 Calvin Kim 宣布了使用 Utreexo 客户端加速比特币初始区块下载(IBD)的成功案例。虽然速度的提高取决于个人的本地硬件和瓶颈,但初始下载和验证的速度比 Bitcoin Core 依然高出 62%。由于许多优化还没有实现,预计速度会持续提高。Calvin 继续讨论 IBD 如何被分割成多个任务,从而由多台计算机进行。最终的计划是用 C++ 实现 Utreexo,并将其并入比特币核心。虽然这可能是一个漫长的过程,但 C++ 的实现已经开始了。

This image has an empty alt attribute; its file name is 1-1024x726.png

我很高兴地宣布,Utreexo 项目已经准备好分享我们对提高比特币完整区块链验证过程(即初始区块下载(IBD))的速度的改进。我们已经完成了基于 utcd 的失序区块验证节点的 alpha 版本的实施,这是我们对 btcd(用 Go 编写的比特币节点)的分叉,并将这个节点与 Bitcoin Core 21.0.0 版本进行了基准测试。

在我们的测试中,与 Bitcoin Core 21.0.0 版本(默认模式)相比,只要用户不受带宽限制,我们就能以 62% 更快的速度完成 IBD。我们预计这个速度差异将增加,因为还有更多尚未实现的优化可用。我们的失序区块验证节点还允许用多台计算机进行 IBD,与目前其他的比特币节点实现相比,提供了独特的优势。

一个单独的文章很快就会发布,它解释了我们如何能够用 Utreexo Accumulators 进行失序块验证。

为什么这种提速很重要?

IBD 是加入比特币网络作为规则执行者的第一步。它是下载和验证从 2009 年的创世区块到今天的所有区块的过程。验证每一个区块的行为是非常重要的,因为这可以防止不良行为者破坏比特币网络的共识规则,其中可能包括:

  1. 凭空造币。
  2. 改变比特币的最大供应量。
  3. 偷窃他人的币。

通过信任第三方节点(例如:交易所运行的节点、第三方钱包等)来参与比特币网络是可能的。然而,这可能会损害用户整个比特币网络。用户会受到损害,因为受信任的第三方可能会骗取用户的资金。比特币网络作为一个整体也会受到损害,因为如果没有足够的用户在网络中运行完整的节点,确保规则得到遵守,规则破坏者可能会在比特币网络中破坏共识规则而不被发现。作为规则执行者参与比特币网络的作用怎么强调都不为过,这既是为了用户的自身安全,也是为了整个网络的安全。要以规则执行者的身份加入比特币网络,IBD 是每个人必须完成的第一步。

正因为如此,如果把 IBD 作为参与规则执行者的入门门槛降到最低,对网络和用户是非常有利的。这意味着一个人应该能够完成 IBD,并尽可能快地成为一个规则执行者。目前 Utreexo 累加器的测试和进展表明,成为统治者执行者的准入壁垒将大大降低。

基准测试

该基准测试是通过一个具有千兆连接的本地节点提供的数据来完成的。

CPU

Ryzen 3600

内存 

Samsung 32GB DDR4 2666MHz

储存

1TB HP SSD EX950 M.2 NVMe

Bitcoin Core 版本

v21.0.0

Linux 内核版本

5.7.19

bitcoin.conf 设置

-dbcache=24000-maxmempool=1000

This image has an empty alt attribute; its file name is 2-1024x386.png

在千兆位连接上,utcd 能够比 Bitcoin Core v21.0.0 的 IBD 速度快大约 36%。 我们目前尚未在 utcd 中实施 Utreexo Proof 缓存,utcd 正在下载大约 900GB 的数据。在千兆的连接上,这至少需要 2 小时左右。我们从 Utreexo 的原始论文中知道,在 Utreexo 证明被缓存的情况下,下载所需的数据将为 450~500GB 左右。下面是同样的 IBD 测试,在同一台机器上的服务节点,模拟我们实施 Utreexo 证明缓存后的性能。

This image has an empty alt attribute; its file name is 3-1024x376.png

正如您从图表中所看到的,速度大约提高了 62%。

我们还用完整的签名验证对这两个节点进行了基准测试。

This image has an empty alt attribute; its file name is 4-1024x377.png

有了完整的签名验证后,我们可以看到 utcd 慢了大约 15%。这是由于签名检查是一个完全的瓶颈,占用了大约 80% 的时间。这可以从下面的火焰图中看出。

This image has an empty alt attribute; its file name is 5-1-1024x272.png

在 utcd 和 Bitcoin Core 都调用 libsecp256k1 的情况下,增加 15% 的时间是合理的,因为 Go 调用 C 语言(cgo)有不可忽略的开销。

虽然在我的测试中,Utreexo 累加器在验证所有签名时对 IBD 的速度没有帮助,但将来有了 Taproot 就不会出现这种情况了。Taproot 允许批量验证块中的所有签名(由于 Schnorr 签名的性质),使签名验证速度大大加快。这将导致瓶颈随着时间的推移向磁盘访问转移。因此,即使 Utreexo 累加器在所有签名被验证时没有帮助,我们相信它们在未来会有帮助。

另外,请注意,如果用户的 CPU 是多核的,从而被磁盘访问的瓶颈所困扰,Utreexo 累加器会有帮助。用户在硬盘驱动器上运行他们的比特币节点,也会看到速度的提高,因为他们也会受到磁盘的瓶颈限制。

多机器初始区块下载基准

分割工作并使用多个计算资源(CPU、GPU、单核 CPU 等)同时进行工作,这被称为并行计算。通过 Utreexo 累加器,您可以用多台计算机完成 IBD。多机 IBD 有两个关键组成部分:一个协调器和一个工作器。

协调器的工作是跟踪哪些区块已经被验证。它将尚未验证的区块分配给工作器。工作器收到需要验证的区块,并返回这些区块确认是否有效。这种来回操作一直持续到整个链被验证为止。

只需要有一个协调器,这个协调器可以分配多个工作器。

This image has an empty alt attribute; its file name is 6-1024x639.png

协调器也是一个工作器;它也验证区块。三台工作器与协调器相连,它们与协调器节点同步验证区块。值得注意的是,工作器和协调器不一定是台式机。他们可以是任何计算设备,如智能手机。

This image has an empty alt attribute; its file name is 7-1024x657.png

多机 IBD 的一个潜在用例可能是在我们不使用手机和笔记本电脑的时候。一个用户可以在晚上使用他们的手机来帮助他们的树莓 PI 节点同步。一个家庭也可能使用他们所有可用的计算设备串联起来,完成 IBD。

下面的基准测试是两台机器协同工作完成 IBD 的结果。

机器 1

CPU

Ryzen 3600

内存

Samsung 32GB DDR4 2666MHz

储存

1TB HP SSD EX950 M.2 NVMe

机器 2

Macbook Pro M1 – 8GB Unified Memory (MacBookPro17,1)

This image has an empty alt attribute; its file name is 8-1024x428.png

用两台机器,我们能够比 Bitcoin Core v21.0.0 更快地完成带有完整签名检查的 IBD。

增加更多的工作器

在多机 IBD 中,所有工作器和协调器之间必须进行任务协调。这反过来又增加了更多的工作要做。这种协调所花费的时间被称为并行开销。如果并行开销需要很长的时间,它就会限制你对一个任务的并行化程度。

失序区块验证的平行开销是头文件的下载。在千兆的连接上,头文件的下载需要4.403 秒。由于 IBD 的整个时间是 426 分钟(用于完整的签名检查),可并行化的百分比是 99.982%。我们可以用这个信息来看看在使用更多的计算机时,阿姆达尔定律的预期最大提速是多少。

在相当数量的 AMD Ryzen 3600 计算机的运行情况下,提速几乎是完美的(如多一台机器提速 1 倍)。下面的线性图很好地显示了这一点。

This image has an empty alt attribute; its file name is 9-1-1024x559.png

头部下载是使用 Utreexo 累加器的 IBD 中唯一的顺序部分,需要为带有 Check Sequence Verify 的交易提供 Median Time Past(除其他事项外)。目前的实现方式是让多机  IBD 中使用的所有机器做一个单独的头部下载。我们计划将这些数据放在 Utreexo 证明中,以摆脱所有工人的头文件下载,这样只有协调器节点需要这样做。这将增加更多计算资源的速度优势。

失序区块验证的局限性

由于使用 Utreexo 累加器的 IBD 需要发送额外的数据(大约 20%),这可能会增加网速已经成为瓶颈的用户进行 IBD 的时间。然而,对于那些网络连接不是瓶颈,并有 20% 以上带宽的用户来说,他们将从失序初始块下载中获益匪浅。在 Utreexo 累加器的研究中也有进展,这将大大减少您需要下载的额外数据的数量。关于这一点,在未来工作部分有更多介绍。

未来工作

较小的 Utreexo 证明

使用 Utreexo 累加器的最大缺点是 Utreexo 证明不小。这既增加了存档的 Utreexo 节点必须存储的大小,也增加了 Utreexo 节点的带宽使用。Bolton BaileySuryanarayana Sankagiri 最近发表的一篇论文表明,我们在批量处理 Utreexo 证明方面的效率并不高。在他们的论文中,他们表明他们能够将证明的大小减少 4.6 倍。这种节省将有助于减少存储和带宽使用的增加。

Tadge Dryja 已经根据 Bolton Bailey 和 Suryanarayana Sankagiri 的研究结果起草了一个新的 Utreexo 累加器设计,我们将在今年实施这个新设计。

千里眼(Clairvoyant)缓存算法

Utreexo 论文中探讨的现有缓存算法将下载的额外数据减少到 20% 左右。然而,我们可以用理论最优缓存算法,或称千里眼缓存算法做得更好。这种算法通常是不可能实现的,因为它需要对未来事件的了解。然而,有了 IBD,我们所连接的对等节点确切地知道未来会发生什么,因此这种算法可以被实现。这个项目目前由 Claire Bao 和 Tadge Dryja 负责。

C++ 的执行

Utreexo 项目的最终目标是将 Utreexo 累加器的功能包含在 Bitcoin Core 中。然而,由于 Utreexo 累加器的参考代码库是用 Go 编写的,所以必须用 C++ 编写一个实现。这个项目被称为 libutreexo,由 Niklas Gögge 领导。他也在用 libutreexo 对 Bitcoin Core 进行分叉,探索 Utreexo 累加器如何融入 Bitcoin Core 的代码库中。

验证我的主张

我用来运行这些基准测试的代码可以在 github.com/mit-dci/utcd 上找到。请参考 repo 中的 readme 来复制我所做的测试。

总结

验证比特币区块链的整个历史的能力是非常重要的,因为它既加强了用户自己的安全,也加强了整个比特币网络的安全。通过 Utreexo 累加器,我相信我们能够让用户更容易做到这一点。虽然在终端用户可以使用之前还有很多工作要做,但我们从开始以来已经走了很长一段路。如果您想加入我们使区块链验证更快,请在 github.com/mit-dci/utreexo 加入我们。