2025比特币全节点性能评测：五大实现同步速度大比拼

2025比特币节点性能测试

正如我过去多次提到的，用完全验证节点来支持你的比特币钱包，能为你提供比特币用户可用的最强安全与隐私模型。七年前，我开始每年对各种节点实现进行一次全面比较，以观察它们在完全验证区块链时的表现。现在是时候看看自上次测试以来发生了什么变化！

我用作基准测试的电脑是2018年时的高端现货硬件。当时价格约为2000美元。如今大约600美元就能组装出来。值得注意的是，我的测试结果绝不代表某个特定实现可能达到的最快同步时间：如果你在一台过去几年组装的新电脑上同步，其速度应明显快于我的基准机器。我坚持使用这台机器的唯一原因是为了确保多年来的一致性，使得每年的结果都能与之前的测试直接比较。

需要注意的是，默认情况下，没有任何比特币实现会严格完全验证整个链历史。作为性能优化手段，大多数实现在某个时间点之前不验证签名。这被认为是安全的，因为那些区块和交易已被大量工作量证明所覆盖，对其进行伪造在经济上不切实际。如果有人想创建一个在那个时间点之前包含无效交易的区块链，其所需的挖矿资源成本将高到足以从根本上打破网络运行的某些安全假设。

为了进行这些测试，我需要尽可能控制变量；有些实现可能跳过验证区块链中更长时期的签名。因此，我进行的测试并未使用默认设置——我更改了一个设置以强制检查所有交易签名，并且通常会调整其他设置以充分利用我机器上更多的CPU核心和RAM。

此外，为了确保公共网络上对等节点的带宽不成为瓶颈和不一致性的潜在来源，对于不“贪婪”占用对等节点带宽的实现（大多数如此），我是在本地网络上的两个节点之间进行同步。

比特币区块链中的数据量随着每个新区块的添加而持续无情地增长，因此节点实现不断优化代码以防止新节点的初始同步时间变得过长，是一场永无止境的斗争。毕竟，如果启动一个新节点的成本或时间消耗变得不合理，更多有意这样做的人会选择放弃，这将导致网络整体健壮性的中心化和削弱。

我之前的性能测试是同步到区块819,000，而今年的测试是同步到区块928,000。在这两年期间，区块链的总大小从530GB增加了34%，达到707GB。因此，我们可以预期，没有进行任何性能改进的实现，其同步时间会比两年前长约34%。

如果我的机器拥有无限的带宽和磁盘I/O，我们理论上能期待的最佳同步时间是多少？由于要到达区块928,000，你需要执行32.38亿次ECDSA验证操作，而我的机器通过libsecp256k1库执行每次操作大约需要5,130纳秒……如果带宽和磁盘I/O不是瓶颈，我的机器验证整个区块链将需要4.6小时。

现在来看结果！

Bitcoin Core 30.0

Bitcoin Core无疑是维护得最好的客户端实现，并且拥有最可靠的发布节奏——大约每6个月一次。版本30是两个月前发布的。完全同步使用了：

18.1 GB RAM
179 GB 磁盘读取
1.2 TB 磁盘写入
690 GB 下载量

我的 bitcoind.conf 配置：

1
2
3
4


connect=<本地节点IP地址>
assumevalid=0
dbcache=24000
disablewallet=1

btcd v0.25.0

btcd 上个月刚刚发布了一个新版本。完全同步使用了：

13.4 GB RAM
6.1 TB 磁盘读取
11.4 TB 磁盘写入
690 GB 下载带宽

我注意到它仍然没有真正利用超过一半的可用CPU周期，所以我认为仍然有一些容易实现的优化空间。我认为 “utxocachemaxsize” 配置参数是我上次测试之后新增的；我注意到由于这个设置，btcd 最终使用了更多的RAM和显著更少的磁盘I/O。

我的 btcd.conf 配置：

1
2
3
4


nocheckpoints=1
sigcachemaxsize=1000000
utxocachemaxsize=24000
connect=<本地节点IP地址>

Gocoin 1.11.0

Gocoin 上个月也发布了一个新版本。有趣的是，它在运行666分钟后崩溃了。按照其当时的速度，如果gocoin没有崩溃，它本应在13小时内完成同步。为了根据文档获得最大性能，我做了几项更改：

安装了 secp256k1 库并使用 sipasec.goset 构建了 gocoin。
根据下面的说明设置了几个新配置。

我的 gocoin.conf 配置：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


LastTrustedBlock: 00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048
AllBalances.AutoLoad:false
UTXOSave.SecondsToTake:0
Stats.NoCounters:true
Memory.CacheOnDisk:false
Memory.GCPercTrshold: -1
Memory.MemoryLimitMB: 24000
Memory.UseGoHeap: true
MaxSyncCacheMB: 6000
ConnectOnly:<本地节点IP地址>

在最初因内存不足而崩溃后，我尝试使用几个不同的配置参数重新同步，比如降低内存限制和使用磁盘缓存来尝试度过这个瓶颈点，但gocoin似乎是一个非常耗费内存的实现，并且持续崩溃。

Gocoin 仍然拥有所有节点实现中最好的仪表板。在崩溃前的11小时6分钟内，gocoin使用了：

30.5 GB RAM
589 GB 下载带宽
513 GB 磁盘读取
1.2 TB 磁盘写入

Gocoin 的性能仍然与 Bitcoin Core 相当，不过我要指出，它是由单个开发者在没有同行评审的情况下维护的，因此你应该谨慎地将其作为生产服务运行。

Libbitcoin Node 4.0.0

我们等待4.0.0版本的发布已经好几年了；虽然它尚未正式发布，但我从 master 分支的提交 63b20361 进行了构建。我第一次尝试构建时遇到了错误，但我很快确定问题是我在编译时使用了我的硬件不支持的CPU扩展指令集。所以我最终使用以下命令构建 libbitcoin： CFLAGS="-msse4.1 -mavx2 -O3" CXXFLAGS="-msse4.1 -mavx2 -O3" ./install.sh --prefix=/path/to/libbitcoin/build/ --build-dir=/path/to/libbitcoin/build/temp --build-secp256k1 --build-boost --disable-shared --enable-ndebug --enable-isystem --enable avx2 --enable-sse41

与所有其他测试不同，我没有让 libbitcoin 与本地网络上的节点同步，而是允许它使用默认的网络配置。这是因为 libbitcoin 已经大规模地重写了其同步逻辑，现在在寻找具有最佳可用带宽的对等节点方面表现得极其"贪婪"；如果我仅将其连接到一个本地对等节点，它实际上会同步得更慢。

我的 libbitcoin 配置：

1
2
3
4
5


[bitcoin]
checkpoint = 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f:0
milestone = 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f:0
[node]
maxheight = 928000

我前几次尝试用完全默认设置进行同步时，它在5小时后到达了区块600,000左右，然后操作系统因内存不足而终止了进程。我发现这很奇怪，因为我的（Ubuntu）操作系统报告显示 libbitcoin 进程实际使用的 RAM 并未超过1GB。

在与 Eric Voskuil 讨论后，他解释说瓶颈在于操作系统的脏页配置。Windows 会根据需求动态调整，但 Linux 和 macOS 不会。幸运的是，Linux 至少是可配置的。在默认设置下，当 RAM 使用量在10%到20%之间时，Linux 就开始强制进程刷新数据到磁盘，就像内存耗尽一样，从而导致一台32 GB RAM的机器陷入停滞。Eric 指出，他们认为32GB RAM是运行 libbitcoin 的最低要求。

以下是 libbitcoin 推荐的操作系统调整命令：

1
2
3
4


sudo sysctl vm.dirty_ratio=90
sudo sysctl vm.dirty_background_ratio=90
sudo sysctl vm.dirty_expire_centisecs=12000
sudo sysctl vm.dirty_writeback_centisecs=12000

在同步过程中，Libbitcoin Node 使用了：

112 TB 磁盘读取
2.9 TB 磁盘写入
1.5 GB RAM
710 GB 下载带宽

在完全验证同步期间，我的CPU一直处于满负荷状态，所以它显然是瓶颈。Eric 指出，导致完全验证性能缓慢的一个主要因素是我的CPU。由于它只有6核/12线程，内存映射数据库最终会受到巨大的冲击，这一点从惊人的磁盘读取量中可以明显看出。如果我有一台拥有更多核心且支持SHA指令集的现代CPU，它就不会从磁盘读取那么多数据，同步速度可能会快2到3倍。

考虑到这次更新是我们等待多年的 libbitcoin 架构重大重构，我还使用默认配置（只验证区块900,000之后的签名）进行了一次同步以比较性能。它在1小时43分钟内完成，并使用了：

23.5 GB 磁盘读取
2.5 TB 磁盘写入
1.1 GB RAM
707 GB 下载带宽

在默认验证同步期间，我的带宽一直处于满负荷状态，所以它显然是瓶颈。Libbitcoin v4 进行了许多优化，特别是在寻找最佳对等节点方面表现得尤为"贪婪"。默认情况下，它连接到100个对等节点（是 Bitcoin Core 的10倍），同时连接5个以快速建立连接（地址池中平均只有1/5的地址可用）。它还会淘汰表现不佳的对等节点，以找到更快的节点，使用的是基于标准差的算法。

Mako

距离 Mako 上一次代码提交已经过去了大约20个月。 Mako 是 Chris Jeffrey 用 C 语言编写的一个实现。为了创建生产优化版本，我通过以下命令构建项目： cmake . -DCMAKE_BUILD_TYPE=Release 并使用以下命令运行它： makod -dbcache=2048 -checkpoints=0 -connect=<局域网节点> -maxconnections=1 Mako 自上次测试以来只做了少量代码修改。CPU 使用率大约只有50%，大概是因为它只识别物理核心而非逻辑核心。我确实注意到 dbcache 选项是新的，但我觉得奇怪的是最大 dbcache 只有 2 GB。

在同步过程中，Mako 使用了：

2.4 GB RAM
113 MB 磁盘读取
7.3 TB 磁盘写入
690 GB 下载带宽

未测试的客户端实现

还有其他比特币全节点客户端可用，但由于各种原因我没有测试它们。

Bcoin - 已超过4年无人维护。
Bitcoin Knots - 前几年测试过，但与 Bitcoin Core 在性能上没有明显差异，并且通常比 Bitcoin Core 落后一到两个版本。
Blockcore - 测试了几年但一直崩溃，似乎专注于成为 Stratis 竞争币的实现。
Floresta - 我尝试过测试这个，它似乎有配置选项可以强制进行完整的历史验证，但出于某种原因，即使你禁用了 utreexo 同步，它也只会连接到支持 utreexo 的对等节点。
Parity Bitcoin - 已超过4年无人维护。
Zebra BTC - 已超过4年无人维护。

性能排名

Bitcoin Core 30.0: 12 小时 7 分钟
Gocoin 1.11.0: 13 小时 0 分钟 (预计)
Libbitcoin Node 4.0.0: 20 小时 51 分钟
Mako 41ef1040: 1 天 18 小时 4 分钟
BTCD 0.25.0: 3 天 11 小时 28 分钟

与上一轮测试的差值对比

请记住，自上次测试以来，区块链总大小增长了34%，因此我们可以预期，没有新性能改进或新瓶颈的节点，其同步时间应增加约34%。

Libbitcoin Node 4.0.0: -5 天 19 小时 45 分钟 (缩短 87%)
BTCD 0.25.0: +3 小时 32 分钟 (延长 4.4%)
Bitcoin Core 30.0: +3 小时 29 分钟 (延长 40.3%)
Gocoin 1.11.0: +4 小时 18 分钟 (延长 49.4%)
Mako 41ef1040: +14 小时 18 分钟 (延长 51.5%)

正如我们所见，大多数客户端的同步时间都超出了预期的34%增幅。然而，有两个客户端实现了巨大的性能改进，有效地抵消了过去两年区块链增长带来的额外数据处理需求。

精确比较的困难

虽然我在相同的硬件上运行每个实现，并与本地网络的对等节点同步以尽可能保持这些变量一致，但还有其他因素在起作用。

并非所有实现都具有相同类型或有效数量的缓存；例如，Mako 只支持最多 2 GB，而 Libbitcoin Node 不做显式缓存，而是依赖操作系统来为内存映射数据库正确管理缓存。
并非所有节点都执行相同的索引功能。例如，Libbitcoin Node 总是按哈希值索引所有交易——这是其数据库结构固有的特性。因此，这个全节点同步更恰当地应该与启用了交易索引选项的 Bitcoin Core 进行比较。
由于操作系统和文件系统性能等任何数量的其他变量，你的实际结果可能会有所不同。这一点在今年测试 Libbitcoin Node 时变得更加明显，因为我通过调整几个操作系统内存管理配置获得了巨大的性能提升。

结论

考虑到在公共无需许可的加密资产网络中，用户可以获得的最强安全模型是亲自完全验证整个历史，我认为跟踪这样做所需的资源非常重要。我们知道，由于区块链的性质，需要新节点（从零开始同步）进行验证的数据量将随着时间的推移持续无情地增加。我每年都在相同的硬件上运行测试，但好的一方面是，我们知道单位美元的硬件性能每年也都在提高。换句话说，仅仅因为某些实现的同步时间比我之前的测试长了50%，并不意味着运行一个节点的成本增加了50%。确保节点同步的资源需求不超过以合理成本可获得的硬件性能，这一点很重要。如果超过了，那么将会有越来越多的人群在这些系统中被"定价排除"在自我主权之外。