Exchange Ranking
Top Exchanges
24h Volume Ranking
Popularity Ranking
Exchange BTC Balance
Proof of Reserves
Decentralized Exchanges
Funding Rate
Funding Heatmap
Liquidation Data
Max Pain
Long/Short Ratio
Whale L/S Ratio
Binance/Okex/Huobi L/S
Bitfinex Margin L/S
ETF Tracker
Solana ETF
XRP ETF
Hong Kong ETF
Bitcoin Treasuries
Crypto Reversal
Ethereum Reserves
HyperLiquid Wallet Analysis
Hyperliquid Whale Watch
Large Transactions
On-chain Movement
Bitcoin ROI
Stablecoin Market Cap
Options Analysis
News
Articles
Economic Calendar
Features
Wallet
Contract Calculator
Security
Collections
Watchlist
Following
BTC Bitcoin Core 32.0：开发周期落幕，安全与效率并重
Bitcoin Core 32.0 标志着一个重要开发周期的结束。虽然此次更新中最为显眼的变化未必是最具技术深度的亮点，但其潜在价值不容忽视。目前，候选版本（Release Candidate）已正式发布，开发团队计划于10月10日推出最终稳定版。本次更新的重点包括：更优化的验证机制、重构后的 HTTP 服务器以及多项关键的安全修复。此外，一次由人工智能辅助的审计工作还引发了一段颇具启发性的测试历程——最初的诊断结果并未完全揭示问题的全貌。
核心亮点速览
- 发布进度：经过数月的开发，Bitcoin Core 32.0 已进入最终贡献者测试阶段。
- 性能优化：通过并行加载特定数据，区块验证在底层得以进化，这对运行独立节点的操作员尤为有益。
- AI 协同审计：AI 模型 Kimi K3 协助发现了 HTTP 服务器的潜在弱点，随后开发人员证实该漏洞可能影响更多连接。
- 补丁迭代：首次修复方案虽保护了内存，但在某些持久连接上引入了显著的延迟。经过多轮调整，最终方案在安全性与性能间取得了平衡。
- 用户影响：普通用户几乎感知不到变化；而开发者和节点操作员将受益于更安全、更高效的基础设施。
更快的区块验证：在不改变比特币运作机制的前提下提升效率
Bitcoin Core 允许计算机自行验证交易和网络区块，无需将任务委托给外部服务。因此，32.0 版本主要影响节点操作员、开发者以及基于此基础设施构建的服务。
最显著的性能改进体现在区块验证环节。为了验证交易，软件必须获取其花费的前序输出（即著名的 prevouts）。当这些数据存储在磁盘上时，读取过程可能会拖慢处理速度。新版本允许从链状态数据库（chainstate database）中并行预加载这些数据。默认情况下启用八个线程，最大支持十六个。对于配置较低的设备，可以将此数值设为零以禁用该机制。
需要明确的是，这一改进不会加快区块链的整体生成速度，也不会缩短区块间隔时间。它仅针对节点本地完成的工作进行优化。虽然在界面上这种技术细微差别难以察觉，但对于日复一日维护基础设施的人员来说，这种提升是切实可感的。
AI 辅助审计发现隐患，人类专家进一步深挖
故事始于贡献者 Matthew Zipkin（化名 pinheadmz）。在使用 Kimi K3（一个也被比特币红队使用的 AI 模型）对新 HTTP 服务器进行审计时，他偶然发现了一个可能导致内存耗尽的场景。
问题在于，服务器在处理请求的同时，仍在继续读取客户端发送的数据。恶意客户端可以利用这一点，保持请求活跃并不断发送数据，导致数据在内存中累积。Zipkin 最初认为该攻击需要身份认证才能实施。然而，代码审查改变了这一看法。开发者 jeanpablojp 对 REST 接口进行了测试，发现16个未经认证的连接可以在一分钟内将节点的内存消耗从约 46 MB 激增至近 3 GB。
这证实了 AI 确实发现了一个问题，但并未就此止步。人类专家进一步推动了测试，发现了更广泛的攻击向量。这种人机协作的价值远大于单纯比较谁发现的漏洞更多。
修复内存问题带来的新挑战
Zipkin 的第一反应遵循着简明的逻辑：当请求正在被处理时，无需继续将后续数据吸入应用程序内存，这些数据可以等待系统侧通过 TCP 压力自然减缓发送者的速度。他在 GitHub PR #36123 中指出：“解决方案是在我们忙于处理请求时，甚至不读取套接字。”
然而，首个补丁存在缺陷。jeanpablojp 测量发现，在持久连接上，中位延迟从约 0.14 毫秒飙升至 53 毫秒。虽然该修复保护了内存，但不必要地延迟了部分请求。
经过修订和重新测试，情况得到了改善：16个未认证的 REST 连接在90秒内仅增加约 3 MB 的内存占用（此前为 3.2 GB），同时约 50 毫秒的惩罚也随之消失。当然，并非没有代价。在一台处于非活动状态且遭受持续流水线攻击的节点上，有评审员测得吞吐量从每秒 383 次请求降至 18.9 次。尽管这是一个非常特定的场景，且评审员表示在实际客户端中未见类似案例，但安全性显然占据了上风，这是一种以可测量的轻微妥协换取隐蔽风险消除的做法。
节点操作员对10月发布的预期
32.0 版本不仅仅涉及上述内存问题。如果时间表如期执行，还将带来几项不那么引人注目但同样重要的变更：
- PSBT v2 支持：四个与部分签名交易相关的命令将默认使用 PSBT v2。需要旧版本的应用程序仍可请求旧格式。
- HTTP 服务器重写：新的 HTTP 服务器替换了 libevent，应用了更严格的规则，并将同时连接的 HTTP 客户端数量限制为16个。此外，重建后的 txindex 事务索引所占磁盘空间将减少至原来的一半以下。
- 钱包功能增强：新增 exportwatchonlywallet 命令，允许导出观察只读钱包所需的信息，而无需携带私钥。
- 安全修复：修复了 walletnotify 漏洞。在非 Windows 系统上，拥有相应权限的身份验证 RPC 用户曾可通过伪造钱包名称来执行命令。现在这些名称将被视为字面量处理。
对于轻量级应用的普通用户而言，这些变化不会干扰日常使用。但对于运行区块链节点的人员来说，这些细节至关重要。
10月10日前值得记住的关键点
- Bitcoin Core 32.0 的目标发布日期为 2026年10月10日，该日期在最终测试期间仍可能调整。
- 区块验证将默认使用8个线程预加载数据，最多支持16个，且不改变区块生产速率。
- 修正后，16个未认证的 REST 连接在90秒内仅增加约 3 MB 内存（此前为 3.2 GB）。
- 四个钱包命令将默认采用 PSBT v2，同时保留请求前一个版本的能力。
- 完全重建的 txindex 将占用不到一半的磁盘空间，新的 HTTP 服务器增加了多项额外安全措施。
时间表上还出现了一个有趣的巧合。当 Bitcoin Core 瞄准10月发布之际，以太坊正在准备其区块链的重大演进 Glamsterdam。Sepolia 测试网预计将于10月6日进行测试（前提是 devnets 上的现有 bug 得到修复），主网升级仍预计在第四季度，12月发布的可能性依然存在。两个不同的项目，采用了相同的方法：测试，偶尔崩溃，大量修复，最后交付成果。
