手续费终于看上内存池了——Bitcoin Core 本周动态 #55

liumuhui 3小时前阅读数 1 #区块链

bitcoin++ 是一个国际性的 bitcoin 开发者会议系列。"Insider Edition" 是我们的新闻栏目，报道 bitcoin++ 宇宙内外正在发生的事情。

比特币上周回顾

手续费终于看向 mempool - 本周 Bitcoin Core #55

准确的手续费让我开心……

大家好，我是 Kevkevin。我是一名开源开发者，也是 Insider Edition 的记者。上周，我审阅了 Bitcoin Core 仓库中的几个 pull request。

周四是 32.0 的 feature freeze。stickies-v 甚至不得不在会议中途发 PSA 提醒大家。然后今天早上，趁着冻结的余温还在，ismaelsadeeq 合并了基于 mempool 的手续费估算。

多年来，estimatesmartfee 只盯着确认历史，而无视就在眼前的 mempool。mempool 空空如也、估算值陈旧偏高，你多付了手续费，多付的部分却回不来。新的估算器会查看 mempool 的顶部区块并取一个百分位数——经济模式下取第 75 百分位，保守模式下取第 50 百分位——但只用于降低旧的 Block Policy Estimator 已经给出的数值。往你的 mempool 里塞垃圾交易的矿工无法抬高手续费。PR 中的历史数据：高估减少了约 29%，成功率为 73% 且零高估。

cfields 为向量化的 chacha20 申请冻结例外。与会众人表示放到 33.0 就好。Co-author 署名问题也占掉了会议的一大块时间。更多内容见下文。另外，上周那句“请大家 review 一下”的 txindex PR 这次真的合并了，所以这个索引成功瘦身了。

已合并的 PR

每周都有若干改动正式加入 Bitcoin Core。本周，有多个改动被合并。以下是我本周觉得比较有意思的一些。

txindex：对 key 做哈希并打包 position 以减少磁盘占用，作者 andrewtoth

上周我请大家 review 这个 PR。这周它合并了。

当前的 txindex 使用完整的 32 字节 txid 作为 key，在主网上目前大约占 66 GB。andrewtoth 改用 5 字节加盐 siphash 前缀，并把 tx position 打包进 key 中，与 txospenderindex 使用相同的技巧。这将索引大小降到约 26 GB——不到原来的一半。哈希冲突会发生（他在主网上测量到数十万个双向冲突，外加少量三向冲突和一个四向冲突），但代价只是一次额外的磁盘读取、一次反序列化和一次哈希。查询耗时仍保持在 0.2ms 左右。

现有节点可以保留旧条目并追加新格式的小条目，也可以清空 indexes/txindex 后重新索引。在他的机器上索引速度也更快了：1 小时 19 分钟对比 1 小时 50 分钟。如果你运行的是 pruned 节点，后续进展：#36002 希望让 txindex 在 pruned 模式下工作。

fees：引入基于 Mempool 的手续费估算以减少高估，作者 ismaelsadeeq

ismaelsadeeq（Abubakar Sadiq Ismail）为 #27995 已经努力了一段时间。这就是最终落地的版本，在 feature freeze 的次日早上合并。

诀窍在于单向棘轮机制。mempool 估算器会构建一个区块模板，取其中的百分位 feerate，并且只允许用来削减 Block Policy Estimator 给出的数值。旧估算器不像原始 mempool 快照那样容易被操纵，因此采用 Finney 式攻击往你的 mempool 里塞交易的矿工无法抬高 Core 推荐的手续费。既然 RBF/CPFP 已经真正可用（TRUC、ephemeral anchors、cluster-size-2 package RBF），低估现在是更安全的失败模式：之后可以加价；而一旦多付，多出的手续费就没了。

它还拒绝信任你的 mempool，除非最近 6 个区块看起来你看到了矿工所见到的大部分交易——即从 mempool 中移除的交易权重与区块权重之比高于 75%。在 tip 不变的情况下，估算结果最多每 7 秒缓存一次。剩下的误差情况是突发的大量交易流入，而旧估算器对此反应较慢，PR 估计这种情况约占 26% 的时间。实时统计：https://bitcoincorefeerate.com/stats

始终有改动在被实时更新和审阅。以下是一些仍然开放、等待 review 的值得关注 PR。

validation：在连接区块的同时预取区块，作者 l0rinc

l0rinc 在周四的会议上提到了这个 PR。Feature freeze 已经发生，但他和其他人将这类改动视为优化而非新功能。它在 HDD 上表现出色。

目前，区块读取和解码发生在区块连接之前，尽管加载主要是 I/O 密集型，而验证是 CPU 密集型。

这是对 #35295 的后续工作，后者将区块连接期间的输入 prevout 获取并行化。

修复方案： 让区块加载通过一个 block fetcher 进行路由，添加同步的 1 区块预读，然后将读取操作移至一个惰性启动的单 worker 线程池，该线程池在多次激活之间持续存在。在该 worker 上排队最多 2 个读取任务。这个 PR 刻意保持 1 个 reader 和固定为 2 的队列大小，以避免并发磁盘读取并限制初始接口范围。

致谢： 这个想法来自 bitcoindev1337，他已经实现过类似的解决方案并报告了相当的结果。

在 HDD 上进行 reindex-chainstate，耗时从约 8.6 小时降到约 6.3 小时（约 1.37 倍）。SSD 上的 IBD 也获得了约 15% 的提升。急需 reviewer，而且 IRC 中的 co-author 讨论正是从这个 PR 开始的，所以除非 fanquake 真的写了代码，否则也许别用 Co-authored-by 给他惊喜。

IRC 会议记录

每周四都会举行一次 IRC 会议。以下是该会议的一些简要记录。

---- Topic 1 ---
stickies-v: #topic Fuzzing WG 更新 (dergoegge, marcofleon)
dergoegge: 没有更新

--- Topic 2 ---
stickies-v: #topic Benchmarking WG 更新 (l0rinc, andrewtoth)
l0rinc: #35889 已合并，类似的后续是 #36032
l0rinc: #35531 也已合并，#36002 是让它支持 pruned 节点的后续工作
l0rinc: 正如此前在这里提到的，#36000 自那之后已开启
l0rinc: 它在 HDD 上表现尤其出色
hodlinator: 不错！
l0rinc: 正如此前在这里提到的，我在研究能否在未来的 PR 中用各种与线程上下文无关的 CheckBlock 验证来扩展它
l0rinc: sipa: 你提到你在考虑把验证重新设计成多线程的，这会和那个冲突吗？
stickies-v: 你说的“与线程上下文无关的 CheckBlock 验证”是什么意思？
sipa: l0rinc: 目前不打算做那个
l0rinc: #36000 在不同的线程上加载区块，所以我们基本上可以免费在那里做一些检查（那些不需要额外连接上下文的检查）
l0rinc: 我就说这么多，谢谢
stickies-v: 我明白了，就是在多个线程上跑 CheckBlock
l0rinc: 是的

--- Topic 3 ---
stickies-v: #topic QML GUI WG 更新 (johnny9dev)
johnny9dev: 在 #871 向 gui-qml “staging” 分支提交了第一个 PR
johnny9dev: 想法是利用我们在构建该项目过程中学到的一切，用干净、可合并的历史来重构该项目。我还需要完善描述部分
johnny9dev: 前 2 到 3 个 PR 可能是最有趣的，因为它们将确立核心部分（构建、测试、应用生命周期和基础模型）
johnny9dev: 所以我认为这就是推动其上游化的计划。我会给这些 PR 充足的时间，让任何可能感兴趣的人都能进行 review
johnny9dev: 而且我觉得现在是开始的好时机
johnny9dev: 目前就这些

--- Topic 4 ---
stickies-v: #topic QA WG 更新 (brunoerg)
brunoerg: 没有更新
cfields: 提议议题：vectorized-chacha20 的潜在 feature-freeze 例外

--- Topic 5 ---
stickies-v: #topic vectorized-chacha20 的潜在 feature-freeze 例外 (cfields)
cfields: 很抱歉拖到最后一刻才提出来，但我想知道大家是否有意愿为 vectorized chacha20 实现开一个 feature freeze 例外。它能把 chacha20 提速 1.5-3 倍（取决于平台/编译器），这是目前 flame graph 中显现出来的最明显的痛点之一。我几个月前就开了这个 PR，但一直在观望上游 GCC 的动向（他们正在开发一项重大的向量化改进，我做这个 PR 时原以为那里已经有这样的改进。他们回复了我的 bug 报告，我相信这些改进终会落地，但目前还没有，所以我决定转向）。我正在做一个 128 位版本（在 l0rinc 的帮助下），应该在各处都有更好的性能（不过等 GCC 加把劲之后，可以用更好的 256 位版本替换它）。
cfields: 如果大家有兴趣为 v32 做一些集中 review，我可以承诺下周投入时间来做这件事。
cfields: #34083
sipa: 下周对我来说时间不合适，我觉得我没法承诺参与 review
cfields: 这件事没什么紧急的，只是作为 32 发布的一个提速改进会很不错。
l0rinc: 严格来说这不是 feature，优化可以算作 bugfix——我可以继续 review
stickies-v: 这看起来是个很酷的改进，不过我觉得放到 33 里发布也同样很酷？
cfields: 好，我没问题。
l0rinc: 两者我都无所谓，反正我们还有其他几个优化排着队呢
cfields: 让它搁置这么久是我的错。
cfields: 谢谢。下一个议题 :)
stickies-v: 所以是的，PSA：今天是 feature freeze

--- Topic 6 ---
stickies-v: 我们要不要再多聊聊 co-authorship 这件事？我自己其实不太在意，但它似乎已经被提起好几次了
stickies-v: 我认为有一群人把它当作一种工具，用来弄清楚谁最了解某段代码/谁是该去找的人；另一群人则把它当作给予认可/表达感谢的一种方式
stickies-v: 哦对了，还有人提到它可以作为一种表达版权的方式
sr_gi: 有什么背景？
sipa: stickies-v: 我只是拿它和版权作为门槛来做个比较
stickies-v: sr_gi: https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2026-08-18#1247067 （以及随后几天）
sipa: 我把它看作一种给予认可的方式，而对这种认可来说合理的门槛，似乎大致对应于某人可以主张版权的那个临界点
l0rinc: 版权在这里是个糟糕的例子：#35794：美国版权局相关指引第 5 页
l0rinc: > 申请人不应仅仅因为使用了某项 AI 技术或某家公司提供的技术，就把该 AI 技术或该公司列为作者或共同作者。
stickies-v: 当有人贡献了大量代码时我会用它，或者在极少数情况下，即使没有代码或代码很少，但有大量的架构/设计想法促使我改变方向时我也会用
l0rinc: 我也把它看作一种给予认可的方式，用来感谢那些帮助塑造成果的人。一个很好的近期例子是
 Rob 在寻找这些东西上花费了大量时间和金钱，我们至少能做的就是把他的名字加为 coauthor 来认可他的工作。
sr_gi: 我自己也一直在用它来表达认可，尤其是当别人开启了这项工作而我后来接手时，但基础仍是他们的（例如 Erlay 的 Gleb）
sipa: 此话怎讲？AI 工具没有版权，我们也不会把它们列为 co-author。
sipa: 所以这个类比似乎是成立的。
l0rinc: AI 是工具，我们也不会把 clang-tidy 列为 coauthor
l0rinc: 我们还不需要感谢 AI（至少现在还不用）
sipa: 我不确定你是在同意我还是在反驳我。
l0rinc: 我想我基本上是同意的
dzxzg: 我不知道这是否需要有一个明确定义的含义，每个人的用法可能都略有不同，但大家都用它表示某种变体的“这个人帮助促成了这个改动”。更详细的东西可能需要由作者和（所谓的）coauthor 逐案协商解决
sipa: 我的立场是，如果某人可以合理地主张版权，你就应该将其列为 co-author。
stickies-v: sipa: 对我来说这听起来是个不错的启发式判断
sipa: 这是一种给予认可的方式，但针对的是实际贡献的代码，而不是想法。
sipa: 这并不意味着 co-author 理解整个 commit。
l0rinc: 我非常反对版权，所以这个类比让我起鸡皮疙瘩
johnny9dev: 只是说明一下，我会在 gui-qml staging 的 commit 中大量使用 co-authored-by，因为我要把庞大的历史压缩成易于消化的形式。这些 co-authors 都曾以某种重要方式参与构建相关部分。我会确保只有在我相信对方能够讲解所引入的功能时，才将其列为 co-author。
l0rinc: 用这种方式感谢人有什么坏处吗？反对的理由到底是什么，是因为它被解读为分摊责任吗？
shiza: 我看到说是和 grants 有关
sipa: l0rinc: 好吧，那就把它理解为“贡献了一段至少 5-10 行的非平凡代码”
l0rinc: 那 1-5 行为什么要避免？就像上面提到的，是因为 grant 吗？
sipa: l0rinc: 我觉得给任何贡献了想法、帮忙做了 benchmark 或其他事情的人署名都很奇怪，这是一个协作项目，每个人都在彼此的基础上构建。Authorship 的门槛比那更高。
sipa: 或者只是建议了几处单行修改。
fanquake: 是啊。我对 #36000 的反对意见是，我几乎没看过那段代码，所以我不明白为什么我要成为 co-author
shiza: 2026-08-14 21:28:42 aj 我们现在用 co-author 是指“写了这个 commit 里的部分代码”还是“对设计做出了贡献”？我以为是指前者，但我见过一些似乎更偏向后者的情况？这个区别对某些人的 grant KPI 重要吗？
fanquake: 我猜 AJ 在这里同样感到困惑，#35920，关于请求将自己添加为 co-author 的事
sr_gi: l0rinc: 读了 stickies-v 分享的那篇文章，我认为问题在于没有给予认可，而不是给予了认可，但我还没读完整个历史
lightlike: 当人们期望别人按自己对待他人的方式把自己添加为 coauthors，而对方政策更严格并拒绝了请求时，不同的政策就会成为问题。
fanquake: *关于请求将其他人添加为 co-author 的事
l0rinc: “Authorship 的门槛比那更高”——如果某人做出了有意义的贡献，那种情况下我会直接把他列为主要作者，比如：#35752
sipa: 你可以在不是某个 commit 主要作者的情况下贡献大量有意义的代码
stickies-v: 好了，我觉得这个话题可以收尾了
stickies-v: 还有其他要讨论的吗？
l0rinc: 感谢大家的反馈
stickies-v: #endmeeting

完整会议记录请点击这里阅读