Bitcoin Core 32 进入最终测试：验证提速、手续费估算变化与安全修复

Bitcoin Core 32 进入最终测试：验证提速、手续费估算变化与安全修复

比特币网络最常用的节点软件 Bitcoin Core 正在进入下一个大版本发布前的最后一道关卡。根据项目发布的生命周期安排，Bitcoin Core 32.0 的第一个候选版本（RC1）已于 9 月 14 日被打上标签，开发团队计划在 10 月 10 日发布正式稳定版。

这次升级并不改变比特币的共识规则，因此不会触发全网范围的硬分叉或软分叉激活。但它会改变节点处理区块、估算交易手续费以及钱包构建交易的方式——这些看似“底层”的改动，最终会影响普通用户支付的手续费高低、交易所与托管服务的钱包集成，以及节点运营者的资源成本。

对比特币生态而言，Bitcoin Core 的每次大版本更新都是一次事实上的“压力测试”：作为使用最广泛的节点实现，它的行为变化会通过矿池、交易所、托管商和钱包服务层层传导。32.0 的特殊之处在于，它没有把筹码押在某个吸引眼球的共识层特性上，而是集中修补那些长期影响用户体验和运营安全的“基础设施问题”——手续费估算滞后、节点同步慢、第三方依赖过多，以及两个在正式版前被及时堵住的安全漏洞。

手续费估算：从“看历史”到“看当前”

Bitcoin Core 目前估算一笔交易该付多少手续费，主要参考已经打包进区块的交易所附带的手续费水平。这种基于已确认交易的估算方法有一个天然滞后：当网络拥堵缓解后，估算值仍会反映此前高价交易，用户可能继续多付钱。

32.0 版本新增了一个基于内存池（mempool）的估算器，观察仍在等待确认的交易手续费，并将两套估算结果进行比较，在网络条件允许时推荐更低的手续费。根据草案版发布说明，这会让手续费估算在网络拥堵消退后更快下降，而不是继续锚定早期区块中的昂贵交易。

这一改动的影响需要分两层看。对普通用户而言，钱包给出的“建议手续费”有望更贴近实时网络状况，尤其在拥堵周期结束后的回落阶段，用户不必再为已经消散的排队买单。对依赖 Bitcoin Core 命令构建交易的托管服务和交易所来说，则需要确认自身系统能正确解析新的估算逻辑——任何把手续费估算结果写死进风控或提币流程的服务，都应该在升级前重新测试边界情况。

区块验证提速与中继限流调整

在区块处理层面，32.0 允许节点在验证区块时通过多个处理线程同时从数据库获取交易数据，默认启用 8 个线程。这一并行化改动减少了节点在追赶区块链时等待磁盘数据的时间。Bitcoin Core 贡献者 Mike Schmidt 在社交平台 X 上表示，这使得初始同步速度最高可提升至原来的 3 倍。

对节点运营者来说，初始同步速度的意义在于降低新节点入网的门槛和时间成本；而对已经同步完成的节点，区块验证阶段的并行读取同样能缩短处理突发大块时的延迟。这一优化不改变验证结果，只是让验证过程更少被磁盘 I/O 阻塞。

同一版本还移除了 libevent 这一外部依赖库，延续 Bitcoin Core 削减第三方依赖的方向。减少外部依赖的直接收益是缩小攻击面、降低供应链风险，并让跨平台构建更可控。该版本还集成了 libsecp256k1 0.8.0 的特性，签名验证速度最高可提升 11%，同时附带新的 Silent Payments（BIP 352）模块，用于增强支付隐私——发送方可以为每笔付款生成一次性收款地址，降低链上收款地址被关联分析的风险。

交易中继管理也有调整：此前 Bitcoin Core 对每个对等连接分别限制可接受的未确认交易数量，32.0 改为全网统一的中继速率限制。开发者称，这能在交易量激增时让节点的 CPU 和内存使用更稳定，降低垃圾交易攻击的风险。从“按连接限流”到“按节点限流”，本质上是把防御粒度从单条链路提升到整体资源预算，避免攻击者通过建立大量连接绕过单连接阈值。

两个安全漏洞在正式版前被修复

此次 RC 周期内，开发者修复了两个安全问题，其中一个是自 Bitcoin Core 24.0 起就存在于非 Windows 系统上的命令执行漏洞。

该漏洞的触发条件是用户启用了 walletnotify 功能——该功能会在钱包发生交易时自动运行指定命令，常被用于触发提币处理、记账或通知流程。在这种配置下，拥有创建钱包权限的已认证用户可以给钱包设置特殊构造的名称，在特定条件下让主机执行命令。32.0 将钱包名称视为纯文本，不再允许名称中的部分内容被解释为命令。

需要强调的是，这一漏洞要求攻击者已经拥有节点的已认证访问权限，因此它不是远程代码执行漏洞。但它的风险在于权限 escalation：在多用户共享节点、或把部分 RPC 权限委托给第三方运维的场景下，受限用户可能借此突破原本的权限边界。这也是为什么 Bitcoin Core 文档长期提醒，任何拥有 RPC 凭据的客户端都应被视为对节点及其所在主机拥有实质性控制权。

其二是新版 Web 服务器中的内存耗尽缺陷。32.0 替换了 Bitcoin Core 原有的 Web 服务器，用于处理其他应用与节点通信的请求。测试显示，16 个未认证的 REST 连接可在约一分钟内把测试节点的内存占用从 46 MB 推高到约 3 GB；一次 90 秒的测试在修复前消耗约 3.2 GB 内存，修复后仅约 3 MB。这一修复对暴露在公网、允许外部访问 REST 接口的节点尤为重要——未认证连接即可触发内存暴涨，意味着修复前这类节点面临被低成本 DDoS 的风险。

钱包与 PSBTv2 默认切换的兼容影响

32.0 还将把四个用于创建部分签名交易（PSBT）的命令默认改为使用 PSBT version 2（BIP 370）格式。这类交易通常在钱包软件与硬件签名设备之间传递，之后才完成比特币发送。

PSBTv2 相比旧版本扩展了更多字段，能更好地协调多方签名、硬件钱包和复杂脚本场景下的未签名交易。应用程序仍可以请求旧版格式，但直接围绕这些 Core 命令构建的服务需要确认自身支持 version 2，否则可能在升级后出现交易构建异常。

对大多数只使用图形界面钱包的普通用户，这一默认值切换几乎无感；真正需要行动的是依赖多签、硬件钱包或托管方案的服务商。它们应当在测试网或回归测试环境中先行验证自身签名流程，确认能正确解析和生成 PSBTv2 交易，再安排生产环境升级。这也是本轮升级中最需要提前做好兼容性测试的部分。

后续观察：节点生态的升级节奏

Bitcoin Core 长期占据比特币全节点软件的主导地位，但节点运营者对软件变更的敏感度正在上升。CoinDesk Research 在 2025 年区块链行业报告中提到，更保守的衍生版本 Bitcoin Knots 的公开节点数量从约 400 个激增至 5000 多个，约占全部可公开访问节点的 22%，反映出部分运营者倾向于选择变更节奏更慢的实现。

32.0 不触及共识层，理论上升级阻力小于需要全网协调的协议层变更。但手续费估算、PSBT 默认格式和 Web 服务器替换都属于会影响下游应用的行为变化，任何一处的兼容疏漏都可能在升级初期引发局部故障。

接下来值得观察的是：10 月 10 日正式版发布后，交易所、托管商和钱包服务商的升级节奏，以及内存池估算器上线后用户实际支付手续费的变化幅度。如果估算器能显著降低拥堵回落期的手续费支出，它可能成为用户感知最明显的一次“隐形升级”。