Bitcoin Core 在 getmininginfo 中加入 bestblockhash 以避免模板竞态
来源发布日期: 2026-09-14 · 编辑分析发布日期: 2026-09-19
合并后的改动让挖矿软件从同一次 RPC 快照取得链尖哈希与下一目标数据。
分析与实际影响
本节为本站分析及示例计算，与来源报道分开呈现。
合并了什么
Bitcoin Core 拉取请求 #36081 于 2026 年 9 月 14 日合并到 master。它在 getmininginfo RPC 返回中新增 bestblockhash 字段。挖矿软件原本可从 next 对象读取下一高度、nBits 和目标值，现在还能确定这些数值所对应的准确链尖。这是已合并的开发代码，并不表示所有生产节点都已经提供该字段。
两次 RPC 调用之间的竞态
此前，需要链尖哈希和下一块目标的软件通常先调用 getmininginfo，再调用 getbestblockhash 或 getblockchaininfo。两次调用之间链尖可能改变，于是程序把一个链尖的哈希与另一个链尖计算出的目标拼在一起。作者特别指出难度调整边界附近的同高度重组，因为竞争链尖可能对应不同的下一 nBits。即使概率低，只要数据用于构建区块模板，也不能忽视。
为何单一快照更安全
在同一个内部链状态锁下返回相关字段，可为调用方提供一致快照。哈希相当于版本标记：下游软件能把下一目标字段绑定到特定链尖，并在新链尖出现时识别数据过期。这不会消除重组，也不能替代 getblocktemplate；它只是移除 RPC 边界上一处可避免的不一致，让矿池软件更容易验证所使用的状态。
不会立即进入生产
合并到 master 代表进入开发主线。运营者必须确认最终包含该提交的正式版本，以及所用发行版是否回移植。客户端应检测 bestblockhash 是否存在，而不能直接假定，尤其是在混合节点集群中。安全上线应保留旧的两次调用回退并增加一致性检查，用记录的响应测试解析器，并在生产依赖该字段前更新监控。
矿池开发测试
应测试正常链尖前进、同高度重组、难度调整边界和节点重启。即使高度没变，只要 bestblockhash 改变，就必须使缓存模板失效。缺失或格式错误的哈希不应让服务崩溃，应记录节点版本和字段可用性。矿池由多个 Bitcoin Core 节点支持时，故障切换不能混合不同节点快照。监控还应统计过期响应和回退路径使用次数，在拒绝工作增加前暴露兼容问题。
实际意义
该补丁很小，却体现一条实用系统原则：必须一起解释的数据，应带有共同版本上下文返回。矿池采用后不会增加算力，但能减少一类狭窄的模板状态竞态，并让诊断更清晰。应关注它最终进入哪个正式版本，分阶段加入客户端支持，并保留现有安全检查。GitHub 拉取请求是合并状态、代码审查和提交历史的权威记录。开发团队还应区分“字段已经合并”“字段出现在正式发布版”“节点已完成升级”和“矿池客户端已经使用”四个阶段。任何一个阶段都不能代表后续阶段已经完成。混合版本环境中，可以在启动时读取节点版本并执行一次能力探测，把结果暴露到监控面板。若字段不存在，旧路径应重新读取并比较链尖，发现不一致时丢弃快照并重试，而不是继续生成模板。若字段存在，也仍需处理链尖在响应返回后立即变化的正常情况，因此模板缓存必须绑定哈希并设置更新机制。测试资料应包含高度相同但哈希不同的响应，以验证系统不会只比较高度。发布到生产前，先在影子实例或低风险连接上运行，比较新旧路径输出，记录差异和延迟。该改动解决的是数据一致性，不是区块传播、Stratum 延迟或矿机硬件错误，排障时不要把所有拒绝份额都归因于这一竞态。接口使用方还应明确 bestblockhash 的语义是当前最佳区块哈希，而不是模板唯一标识或工作提交 ID。应用可以把哈希、高度、nBits、target 和响应时间存入同一结构，并禁止不同结构之间字段交叉复用。收到新 tip 通知后，应原子地废弃相关缓存；若发生同高度重组，仅比较高度的逻辑会漏掉变化。多节点架构可以记录响应来自哪个节点，避免负载均衡器把第一次调用和第二次调用路由到不同后端。升级测试不仅要验证成功返回，还要覆盖旧节点不认识新字段、代理过滤字段、JSON 类型错误、连接中断和节点尚未同步等情况。监控可以显示每个后端最后链尖、更新时间和模板年龄，并在节点分歧时阻止自动选择过旧模板。该字段不会替代矿池对 coinbase、交易集、时间和版本位的常规验证，也不会解决矿机到 Stratum 服务器之间的网络延迟。正式发布前，开发者应跟踪 Bitcoin Core 发布说明和 RPC 文档，不要让 master 分支行为成为没有版本约束的生产依赖。回滚方案要保留旧解析路径和兼容测试，确保升级一个节点不会中断整个矿池。务必阅读此类消息时，应把已经发生的事实、开发中的代码、监管许可、预测和作者分析分别标记。来源页面可能在发布后补充说明，因此引用时要保存访问日期、标题和关键标识。涉及数字的结论应保留原始单位，换算结果注明公式和四舍五入方式。运营者不应仅凭一篇报道改变整个矿场配置，而应先确定消息是否适用于自己的设备、软件版本、司法辖区和电价合同。测试必须从单台设备、单个节点或影子环境开始，设定成功指标、停止条件和回滚路径。实施后同时观察矿池接受份额、设备日志、功耗、网络状态与财务数据，避免单一面板造成误判。若官方来源与二手报道冲突，应以可核验的官方记录为基础，并明确仍未知的部分。对于尚未进入正式版本、尚未获得最终批准或只有早期样本的数据，文章中的条件语气非常关键。长期决策需要后续验证，包括正式发布说明、完整法律文本、实际成交或完整难度周期。保存这些证据不仅方便审计，也能避免团队日后把旧假设当成当前事实。
来源: Bitcoin Core ↗
挖矿计算器 ↗
