核心问题:跑赢熵,为什么比特币不能止步不前

  • bitcoinm
  • 发布于 2026-03-12 20:14
  • 阅读 6

本文详细介绍了比特币核心(Bitcoin Core)开发者为优化初始区块下载(IBD)过程所做的持续努力。文章回顾了历史上的关键改进、当前正在进行的优化以及未来的潜在方向,通过引用具体的技术细节和GitHub拉取请求(PR),展示了如何通过各种技术手段提高同步速度,以确保比特币网络的可访问性和去中心化。

核心问题:超越熵,为何比特币不能止步不前

摘自核心问题:深入分析为加速 Bitcoin Core 用户初始区块下载所做的优化和微调。

willcl-ark, l0rinc 和 hodlinator

作者:willcl-arkl0rinchodlinator

核心问题:超越熵,为何比特币不能止步不前

IBD 过程

将新节点同步到网络尖端涉及几个不同的阶段:

  • 节点发现和链选择,节点连接到随机对等节点并确定工作量最大的链。
  • 区块头下载,获取并连接区块头以形成完整的区块头链。
  • 区块下载,节点同时从多个对等节点请求属于该链的区块。
  • 区块和交易验证,每个区块的交易在处理下一个区块之前进行验证。

虽然区块验证本身本质上是顺序的,每个区块都依赖于前一个区块产生的状态,但大部分相关工作是并行运行的。区块头同步、区块下载和脚本验证都可以并发在不同的线程上进行。理想的 IBD 会最大限度地饱和所有子系统:网络线程获取数据,验证线程验证签名,以及数据库线程写入最终状态。

如果没有持续的性能改进,廉价节点未来可能无法加入网络。

引言

比特币的“不信任,就验证”文化要求任何人都可以从头重建账本。在处理所有历史交易后,每个用户都应该获得与网络其余部分完全相同的每个人资金的本地状态。

这种可重现性是比特币最小化信任设计的核心,但它也带来了显著的代价:在近 17 年后,这个不断增长的数据库迫使新用户在加入比特币网络之前做比以往更多的工作。

当引导一个新节点时,它必须下载、验证并持久化从创世区块到当前链尖的每一个区块——这是一个资源密集型的同步过程,称为初始区块下载 (IBD)。

尽管消费硬件持续改进,但保持低 IBD 要求对于通过让所有人(从 Raspberry Pi 等低功耗设备到高性能服务器)都能进行验证来维护去中心化至关重要。

基准测试过程

性能优化始于理解软件组件、数据模式、硬件和网络条件如何相互作用,从而在性能方面产生瓶颈。这需要大量的实验,其中大部分都会被丢弃。除了速度、内存使用和可维护性之间的常见平衡之外,Bitcoin Core 开发者必须选择风险最低/回报最高的变更。有效但微小的优化通常因其相对于收益的风险过高而被拒绝。

我们拥有一整套微基准测试,以确保现有功能不会出现性能下降。这些对于捕获性能退化(即单个代码片段的性能退步)很有用,但不一定能代表整体 IBD 性能。

提出优化的贡献者提供可重现的案例和跨不同环境的测量结果:操作系统、编译器、存储类型(SSD 与 HDD)、网络速度、dbcache 大小、节点配置(修剪模式与归档模式)和索引组合。我们编写一次性基准测试并使用编译器浏览器来验证哪种设置在这种特定场景中会表现更好(例如,使用哈希集合、排序集合或排序向量进行区块内重复交易检查)。

我们还定期对 IBD 过程进行基准测试。这可以通过从本地区块文件重新索引链状态和可选的区块索引来完成,或者通过从本地节点(以避免慢速节点影响计时)或从更广泛的 P2P 网络本身进行完整的 IBD。

IBD 基准测试通常显示出比微基准测试更小的改进,因为网络带宽或其他 I/O 通常是瓶颈;仅下载区块链,在全球平均互联网速度下大约需要 16 小时。

为了最大限度地可重现性,通常首选 -reindex-chainstate,在优化前后创建内存和 CPU 配置文件,并验证更改如何影响其他功能。

历史和持续改进

早期的 Bitcoin Core 版本是为小得多的区块链设计的。最初的中本聪原型奠定了基础,但如果没有 Bitcoin Core 开发者持续的创新,它将无法应对网络前所未有的增长。

最初,区块索引存储了每笔历史交易以及它们是否已被花费,但在 2012 年,“Ultraprune”(PR #1677)创建了一个专用数据库来跟踪未花费的交易输出,形成了 UTXO ,它预先缓存了所有可花费币的最新状态,为验证提供了统一视图。结合数据库从 Berkeley DB 迁移到 LevelDB,验证速度显著提高。

然而,这次数据库迁移导致了 BIP50[1] 链分叉,当时一个包含许多交易输入的区块被升级节点接受,但被旧版本拒绝,因为它过于复杂。这强调了 Bitcoin Core 开发与典型软件工程的不同之处:即使是纯粹的性能优化也可能导致意想不到的链分裂。

次年(PR #2060)启用了多线程签名验证。大约在同一时间,专门的密码学库 libsecp256k1 被创建,并于 2014 年集成到 Bitcoin Core 中。在随后的十年中,通过持续优化,它比通用 OpenSSL 库中的相同功能快 8 倍以上。

头部优先同步(PR #4468,2014)重构了 IBD 过程,首先下载累积工作量最大的区块头链,然后同时从多个对等节点获取区块。除了加速 IBD,它还消除了因不在主链中而被孤立的区块造成的带宽浪费。

2016 年 PR #9049 移除了一个看似多余的重复输入检查,引入了一个可能导致供应膨胀的共识错误。幸运的是,它在被利用之前被发现并修补了。这一事件推动了大量的测试资源投入。如今,通过差分模糊测试、广泛覆盖和更严格的审查纪律,Bitcoin Core 能够更快地发现和解决问题,此后没有报告过类似的共识风险。[2]

2017 年 -assumevalid(PR #9484)将通用区块有效性检查与昂贵的签名验证分离,使后者在 IBD 的大部分过程中成为可选,将其时间缩短了大约一半。区块结构、工作量证明和花费规则仍然得到完全验证:-assumevalid 完全跳过了对特定区块高度之前所有区块的签名检查。

2022 年 PR #25325 将 Bitcoin Core 的普通内存分配器替换为针对币缓存优化的自定义池式分配器。通过专门为比特币的分配模式进行设计,它减少了内存浪费并提高了缓存效率,在相同的内存占用下,IBD 速度提高了约 21%,同时容纳了更多的币。

尽管代码本身不会腐烂,但它所运行的系统却在不断发展。每 10 分钟,比特币的状态就会改变——使用模式转变,瓶颈迁移。维护和优化不是可选的;如果没有持续的适应,比特币积累漏洞的速度将超过静态代码库的防御能力,并且 IBD 性能会尽管硬件有所进步而稳步下降。

UTXO 规模的增大和平均区块重量的增加就是这种演变的例证。以前是 CPU 密集型任务(如签名验证)的现在常常由于链状态访问量增加(必须检查磁盘上的 UTXO )而成为输入/输出 (IO) 密集型任务。这一转变推动了新的优先级:改进内存缓存、降低 LevelDB 刷新频率以及并行化磁盘读取,以保持现代多核 CPU 繁忙。

近期优化

软件设计基于预测的使用模式,而随着网络的发展,这些模式不可避免地会与现实脱节。比特币的确定性工作负载允许我们测量实际行为并稍后进行纠正,确保性能与网络增长保持同步。

我们正在不断调整默认值以更好地适应实际使用模式。以下是一些示例:

  • PR #30039 增加了 LevelDB 的最大文件大小——单个参数更改使 IBD 速度提高了约 30%,因为它更好地匹配了链状态数据库(UTXO )的实际访问方式。
  • PR #31645 将刷新批次大小加倍,减少了 IBD 最密集写入阶段的碎片化磁盘写入,并在 IBD 中断时加快了进度保存。
  • PR #32279 调整了内部 prevector 存储大小(主要用于内存脚本存储)。旧的 SegWit 前阈值优先考虑旧的脚本模板,牺牲了较新的模板。通过调整容量以覆盖现代脚本大小,避免了堆分配,减少了内存碎片,并且脚本执行受益于更好的缓存局部性。

所有这些都是具有可衡量验证影响的小而精准的更改。

除了参数调整之外,一些更改还需要重新思考现有设计:

  • PR #28280 改进了修剪节点(丢弃旧区块以节省磁盘空间)处理频繁内存缓存刷新的方式。原始设计要么转储整个缓存,要么扫描它以查找修改过的条目。选择性地跟踪修改过的条目使修剪节点在使用最大 dbcache 时速度提高了 30% 以上,在默认设置下速度提高了约 9%。
  • PR #31551 引入了区块文件的读/写批处理,减少了许多小型文件系统操作的开销。区块文件访问速度提高了 4 到 8 倍,不仅改进了 IBD,也改进了其他 RPC。
  • PR #31144 通过处理 64 位块而不是逐字节操作,优化了现有可选的区块文件混淆(用于确保数据不以明文形式存储在磁盘上),从而再次加快了 IBD 速度。由于混淆基本上是免费的,用户不再需要在安全存储和性能之间做出选择。

其他次要的缓存优化(例如 PR #32487)使得可以添加以前被认为过于昂贵的额外安全检查(PR #32638)。

类似地,我们现在可以更频繁地将缓存刷新到磁盘(PR #30611),确保节点在崩溃时永远不会丢失超过一小时的验证工作。适度的开销是可以接受的,因为早期的优化已经使 IBD 显著加快。

PR #32043 目前作为 IBD 相关性能改进的跟踪器。它汇集了十多个正在进行的工作,从磁盘和缓存调整到并发性增强,并提供了一个框架来衡量每个更改如何影响实际性能。这种方法鼓励贡献者不仅提供代码,还提供可重现的基准测试、分析数据和跨硬件比较。

未来优化建议

PR #31132 在区块验证期间并行化交易输入获取。目前,每个输入都从 UTXO 中按顺序获取——缓存未命中需要磁盘往返,从而产生 IO 瓶颈。该 PR 引入了跨多个工作线程的并行获取,使 -reindex-chainstate 速度提高了约 30%(在具有 450MB dbcache 的 Raspberry Pi 5 上大约 10 小时)。作为一个副作用,这缩小了小 dbcache 值和大 -dbcache 值之间的性能差距,可能允许内存适中的节点以与高内存配置几乎相同的速度同步。

除了 IBD,PR #26966 还使用可配置的工作线程并行化区块过滤器和交易索引的构建。

保持持久化的 UTXO 紧凑对于节点的无障碍性至关重要。PR #33817 尝试通过删除一个可能不需要用于比特币特定用例的可选 LevelDB 功能来略微减小它。

SwiftSync[3] 是一种实验性方法,利用我们对历史区块的后见之明。了解实际结果后,我们可以根据每个遇到的币在目标高度的最终状态进行分类:那些仍然未花费的(我们存储的)和那些在该高度已被花费的(我们可以忽略的,仅验证它们出现在任何匹配的创建/花费对中)。预生成的提示编码了这种分类,允许节点完全跳过对短生命周期币的 UTXO 操作。

比特币向所有人开放

除了综合基准测试,最近的一项实验[4]在通过 WiFi 由电池组供电的降频 Raspberry Pi 5 上运行了 SwiftSync 原型,在 3 小时 14 分钟内完成了 888,888 个区块的 -reindex-chainstate。具有同等配置的测量结果显示,在最近的 Bitcoin Core 版本中,完整验证速度提高了 250%[5]。

累积多年的工作转化为真正的影响:现在可以在廉价硬件上不到一天的时间内完成近百万个区块的完整验证,尽管区块链持续增长,但仍保持了可访问性。

自主主权比以往任何时候都更容易实现。

不要错过拥有核心期刊的机会——其中包含许多核心开发者撰写的文章,解释了他们自己正在进行的项目!

本文是《比特币杂志》最新印刷版《核心期刊》中的“编辑寄语”。我们在此分享它,作为对整期内容所探讨思想的抢先预览。


[1] https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki

[2] https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures

[3] https://delvingbitcoin.org/t/swiftsync-speeding-up-ibd-with-pre-generated-hints-poc/1562

[4] https://x.com/L0RINC/status/1972062557835088347

[5] https://x.com/L0RINC/status/1970918510248575358

本文中列出的所有拉取请求 (PR) 都可以通过此处编号查询:https://github.com/bitcoin/bitcoin/pulls

相关文章

印刷版

核心期刊:你的节点 vs. 数字荒野

核心期刊:你的节点 vs. 数字荒野

2026 年 3 月 18 日

商业

Boltz 交易所为闪电网络用户推出原子 USDT 兑换

Boltz 交易所为闪电网络用户推出原子 USDT 兑换

2026 年 3 月 18 日

特色

从 5 美元到 75,000 美元:比特币圣帕特里克节价格展示了比特币的疯狂之旅

从 5 美元到 75,000 美元:比特币圣帕特里克节价格展示了比特币的疯狂之旅

2026 年 3 月 17 日

上一页下一页

Bitcoin Magazine

比特币投资组合跟踪器和媒体更新

在 Google Play 获取在 App Store 下载

比特币比特币BTC/USD

$68,480.00

24小时 %:

-2.0%

24小时最高:

$70,074.00

24小时最低:

$68,146.00

数据加载错误。请检查控制台获取详情。

查看 150+ 比特币图表

  • 原文链接: bitcoinmagazine.com/prin...
  • 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
点赞 0
收藏 0
分享
本文参与登链社区写作激励计划 ,好文好收益,欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
bitcoinm
bitcoinm
江湖只有他的大名,没有他的介绍。