本周比特币核心#45

INSIDER 发布于 2026-05-30 阅读 89

本周比特币核心开发进展:合并了25个PR,其中Sjors的PR解耦了矿工启动默认值与运行时选项,为多进程挖矿接口奠定基础;aw Chow的PR明确了验证接口的线程安全规则。IRC会议讨论了fuzzing、内核、基准测试工作组进展,包括链状态数据库定期压缩策略、libevent移除、QML GUI预览版计划等。

bitcoin++ 是一个国际性的比特币开发者会议系列。"Insider Edition" 是我们的新闻编辑室,报道 bitcoin++ 世界内外的动态。

上周比特币资讯

本周 Bitcoin Core #45

本周比特币开发者照常工作……

大家好 👋 我是 kevkevin,一名开源开发者和 Insider Edition 的记者。上周,我回顾了 Bitcoin Core 仓库中的几个拉取请求。

已合并的拉取请求
每周,都会有若干变更正式合入 Bitcoin Core。本周有 25 个变更被合并。以下是我觉得有趣的几个。
  • 重构:将矿工启动默认值与运行时选项分离Sjors 提交。Sjors 将矿工的初始启动配置与其运行时的选项隔离开来。

    • 问题所在: 区块模板构建器与全局节点状态紧密耦合,导致编写干净的测试或分析代码变得困难。

    • 修复方法: 将这些启动默认值抽取到一个独立的结构中,从而可以单独进行测试。

    • 大局观: 这是 多进程(IPC) 挖矿接口的结构性基础工作。通过分离这些选项,独立的挖矿进程最终可以独立运行,而无需深入读取 bitcoind 的内部内存状态。

  • 钱包:使用所有数据构造 ScriptPubKeyMan,而非逐步加载achow101 提交。在这个 PR 中,Ava Chow 通过明确编写并强制执行验证接口的线程和锁定规则,处理了关键的技术债务。该接口处理诸如区块连接、断开或交易进入内存池等通知,但之前其并发性要求模糊不清,为潜在的数据竞争或死锁留下了隐患。

通过明确这些线程安全保证并在代码中直接添加严格的断言,此更新防止了未来开发者引入微妙的并发错误。这是一项稳定性和代码质量的改进,确保节点的后台通知系统在 Core 继续向更模块化架构演进时保持健壮。

总是有变更在实时更新和审查中。以下是一些仍在寻求审查的值得注意的 PR。

util::Result 增加返回更多错误信息的能力,并在 LoadChainstate 方法中作为初步应用。后续的 PR #25722#29700 将更广泛地使用它来返回钱包和内核函数的错误和警告。


IRC 会议记录
每周四都会举行 IRC 会议。以下是该会议的一些简短记录。
stickies-v: #topic 模糊测试工作组更新 (dergoegge)
dergoegge: 无更新
stickies-v: #topic 内核工作组更新 (sedited)
sedited: #32427 又有了些审查活动,还需要更多。
sedited: 我变基了我的分支,用于从验证(以及内核库)中拆分出 mempool/策略代码:https://github.com/sedited/bitcoin/tree/mempoolout_rebase
sedited: 不过对拆分后的代码仍然不满意,用于重新访问内存池并获取锁的接口非常笨拙。
stickies-v: 不错,我会尽快回去审查 32427,这对内核来说是一个不错的改进。
sedited: 不确定人们一开始对这种拆分有多感兴趣。代码组织上的好处还不错,但除此之外,对于 Bitcoin Core 软件的实用性有点值得怀疑。
darosior: "内存池驱逐?——是的,但你想的那个不是"
darosior: 不是*
sedited: 确实 :)
darosior: 如果这对内核库有好处,而且 Bitcoin Core 不会更差,那不是挺好的吗?
stickies-v: 是的,我认为这对内核用户来说是一个相当大的改进。
sedited: 我可能会把它作为一个 RFC PR 开放,保持变基是个挑战,但定期确保这种拆分本身是可行的也是好事。
stickies-v: 也许 RFC 问题更合适?
sedited: 不确定,我认为大多数人表面上都会同意这是好事,所以我觉得更需要衡量的是重构的代价。
stickies-v: 从 issue 链接一个分支似乎没问题,但你不需要浪费时间在变基和处理小问题上。
stickies-v: 不管怎样。
stickies-v: 还有其他事吗?
sedited: 就这些。
stickies-v: #topic 基准测试工作组更新 (l0rinc, andrewtoth)
andrewtoth_: l0rinc 不在,但他说他正在做一个自动压缩的 PR。
andrewtoth_: 我转达了 darosior 关于使用最小链工作作为触发条件的想法。
andrewtoth_: 我也开始认为大约每周一次的自动压缩会是好的。
sedited: 仅仅反复检查 isibd 有什么问题吗?
andrewtoth_: 那也会在每次启动时触发,不太理想。
sipa: andrewtoth_: 一周的区块数据大约是 2 GB,每周完全重写一次会增加多倍的写入量。
sipa: 还是说我们必然已经有很多了?
andrewtoth_: sipa: 如果不压缩,链状态每周增加不到 200 MB。
andrewtoth_: 呃,我不太明白你说的区块数据有什么关系?
sipa: 是的,我只是想衡量每周完全重写一次链状态会增加多少磁盘活动。
darosior: 我认为是指磁盘 IO?
andrewtoth_: 我认为目前每次完全压缩大约会产生 10-15 GB 的写入 IO。
sipa: 是的,这比我们不做预计增加的量要多出数倍。
Murch[m]: 为什么是每周一次,而不是每月一次?
andrewtoth_: 我们当然可以讨论频率。也可以每月一次。
stickies-v: 那每三周一次怎么样?
sipa: IBD 结束后重写一次,我认为影响更大。
darosior: stickies-v: 哈哈。
sipa: stickies-v: 当最后一个区块哈希以 12 个零位结尾时。
sedited: ^^
andrewtoth_: 是的,我同意 IBD 结束时的压缩很重要。但是,定期为用户节省一次完全压缩额外 11% 的空间是否值得?
Murch[m]: sipa: 如果不在同一个高度进行就更好了。
b10c: murch: 同意。
darosior: 每月一次似乎没问题,这样就不需要在 IBD 结束时再做了。
sipa: 是的,抱歉,我不是想开始讨论……我只是不太相信定期做会有多大好处,而且可能仍然会增加大量的磁盘活动。
sipa: Murch[m]: 当然,那是个玩笑 :)。
andrewtoth_: 我认为只有 IBD 结束后才做很重要,因为用户可能会关机,之后再也不会连续运行一个月。
Murch[m]: 例如,IBD 完成后做一次,然后计划在随机的 3500–5000 个区块后再做一次。
Murch[m]: 如果所有节点都在同一个高度做,可能不好。
andrewtoth_: Murch: 我认为这几乎就是 l0rinc 现在采用的方法。
darosior: andrewtoth_: 你建议两者都做?我本来希望二选一。
Murch[m]: 从上周的话题来看,我的印象是完整 IBD 结束时数据库膨胀了几个 GB。
Murch[m]: 所以,跟踪你开始了一次新的 IBD,并在追赶上链尖后做一次,这听起来很有用?
andrewtoth_: 我原本想两者都做,是的……
darosior: 如果我们在 IBD 结束时做一次,你觉得在此基础上定期做还有多大帮助?比如,在区块约 950k 时做一次,那么在区块约 1M 时再做一次能真正节省多少磁盘空间?
andrewtoth_: 如果必须选一个,我会选 IBD 结束后。
andrewtoth_: 磁盘空间的 11%。
andrewtoth_: IBD 结束后立即做可以节省约 30%,然后会缓慢上升到总共 11%。
andrewtoth_: 定期压缩可以削减那 11%。
Murch[m]: 然后大约每周 200 MB?
andrewtoth_: Murch: 直到 11%,会被封顶。
darosior: 好吧,我没有意见。我觉得不管怎样影响都不大。
andrewtoth_: 我觉得 IBD 结束后可以作为初步变更,然后我们再来讨论定期压缩的频率。
Murch[m]: 嗯,每周似乎有点激进,但不管怎样这比每小时做一次要好得多。
andrewtoth_: 好的,谢谢大家的反馈。
andrewtoth_: 另外,#35295 收到了一些很好的审查,谢谢!我会尽快处理。
andrewtoth_: 我就说这些。
stickies-v: #topic Libevent 移除 (pinheadmz, fjahr)
pinheadmz: #35182 已经很接近了。昨天处理了一些小问题,并重新开始了集成测试。已经有一些小的后续 PR 在队列中。
pinheadmz: 从客户端移除 Libevent 已经合并了,耶!
pinheadmz: 希望能在发布前有足够时间合并,以便发现任何问题。
pinheadmz: 我就说这些。
stickies-v: #topic QML 图形界面工作组更新 (johnny9dev)
johnny9dev: 我们仍按计划在六月进行“预览”版未签名构建。相关工作可以在 https://github.com/orgs/bitcoin-core/projects/1/views/2 找到,我今天早上更新了,所以是准确的。我们有来自 pseudorandom 和 epicleafies 的钱包更新,以及来自我的节点错误对话框和区块状态更新正在审查中。之后的高优先级任务是将项目更新到 v31,并验证设置和
johnny9dev: 入门流程与 bitcoin-qt 安装兼容。
johnny9dev: 我就说这些。
stickies-v: 好的,感谢大家的更新。
stickies-v: 还有其他要讨论的吗?
abubakarsadiq: novo 让我转达静默支付的更新。
instagibbs: 据我所知,31.x 的补丁版本因为 #35319 而受阻,所以我们尽量完成它?
abubakarsadiq: https://github.com/bitcoin-core/secp256k1/pull/1765 必须合并后,我们才能在 Core 上合并静默支付,但欢迎对 https://github.com/bitcoin/bitcoin/pull/35301 和 https://github.com/bitcoin/bitcoin/pull/35302 进行审查。
stickies-v: 是的,instagibbs 说得好。
Murch[m]: 关于压缩的一个后续:如果机制是计划在特定高度进行,你可以将第一次压缩安排在一次略高于最佳头链链尖的高度,但延迟压缩直到我们不再处于 IBD 状态。
Murch[m]: 或者,只是计划在常规的~几千个区块间隔进行,但等到不再处于 IBD 状态才做,这样就能在 IBD 后做一次。
eugenesiegel: 我尝试制作一个基于 p2p_private_broadcast.py 的功能测试,但进展不顺利。我在 Socks5 代理和重连代码上遇到了问题,希望 vasild 有更好的方法。
instagibbs: vasild,你的测试版本预计何时完成?即使还有一些清理工作待办。
andrewtoth_: Murch: 我们需要确保只触发一次,所以可以使用一个仪表,比如之前的工作 < 最小工作,现在的工作 > 最小工作,这样可能就能实现。
andrewtoth_: 否则会在每次启动时触发。
stickies-v: 我将在这里结束会议,但讨论可以继续。

点击此处阅读[完整会议](https://achow101.com/ircmeetings/2026/bitcoin-core-dev.2026-05-28_16_00.log.html)

* * *

##### **版本发布**

- 本周无发布

* * *

> 感谢阅读。请务必在下周再次关注 Bitcoin Core 的更新!

_如有任何评论、建议或错误,请随时联系或评论_

>- 原文链接: [insider.btcpp.dev/p/this...](https://insider.btcpp.dev/p/this-week-in-bitcoin-core-45)
>- 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~

相关文章

0 条评论