本周比特币核心#44：IRC上提及的核心开发者

bitcoin++ 是一个国际比特币开发者大会系列。"内幕版"是我们的新闻编辑室，报道 bitcoin++ 世界内外的动态。

上周比特币

IRC 中提及的 CoreDev - 本周比特币核心 #44

本周比特币核心内部，开发者们从某个未知度假地归来

大家好 👋，我是 kevkevin。我是一名开源开发者，也是内幕版的记者。上周，我回顾了 Bitcoin Core 仓库中的几个 pull request。

本周的每周 IRC 会议中，CoreDev 被提及了几次。那里一定有一些不错的讨论。请务必阅读末尾的 IRC 日志以了解更多信息。

已合并的 PR

每周都有多个变更被正式添加到比特币核心。本周合并了 11 个变更。以下是我觉得有趣的一些。

• cli: 用简单的 http 客户端替换 libevent 使用 作者 fjahr 作为完全移除 libevent 依赖工作的一部分，Fabian Jahr 提交了这个 PR，用简单的 HTTP 客户端替换了 libevent 的使用。

在他的变更中，他用一个直接使用 Sock 类的简单同步实现替换了基于 libevent 的 HTTP 客户端。

• fuzz: 针对 CDBWrapper 作者 andrewtoth CDBWrapper 抽象了比特币核心与其数据库之间的交互，当前是 LevelDB，但之前是 BerkeleyDB。没有专门的测试工具针对 CDBWrapper。Andrew Toth 提交了这个模糊测试 PR，为此包装器添加了覆盖。

此外，Toth 指出 OSS-Fuzz 有一个针对 LevelDB 的测试工具，但它会失败，似乎未被维护。在比特币核心上为其添加测试工具将为我们解决这个问题。

总有一些变更正在进行实时更新和审查。以下是一些仍在开放并寻求审查的值得关注的 PR。

• 重构: 添加 util::Result 失败类型和合并结果值的能力 作者 ryanofsky

在 LoadChainstate 方法中添加 `util::Result` 支持以返回更多错误信息，并作为初始应用使用它。后续的 PR #25722 和 #29700 更广泛地使用它来从钱包和内核函数返回错误和警告。

IRC 会议记录

每周四有一次 IRC 会议。以下是该会议的一些简短记录。

stickies-v: #topic 模糊测试工作组更新 (dergoegge)
dergoegge: 没有更新

stickies-v: #topic 内核工作组更新 (sedited)
sedited: 发布了一个新的 rust-bitcoinkernel 版本，使用手动生成的绑定代替之前自动生成的绑定（减少了构建时的依赖）。
sedited: 除此之外，也许 stickies-v 有什么要说的？
stickies-v: 他没有

stickies-v: #topic 基准测试工作组更新 (l0rinc, andrewtoth)
_andrewtoth_: 有一个关于 leveldb 的 bug 被报告了 https://github.com/bitcoin/bitcoin/issues/35298。
_andrewtoth_: 一个潜在的修复在 https://github.com/bitcoin-core/leveldb-subtree/pull/61。
_andrewtoth_: l0rinc 还发现该修复将 HDD 上的 reindex-chainstate 速度提升了 17%。
_andrewtoth_: 缺点是从磁盘使用峰值来看，磁盘使用增加了大约 11%。目前一次 IBD 需要 12 GB，这个 PR 将其增加到 15 GB。但对于已经同步的节点，磁盘使用的增加将非常缓慢。
_andrewtoth_: 可以在同步后手动运行 -forcecompactdb 来降低磁盘使用，但我认为我们应该接受链状态稍微多占用一些磁盘空间，而不是每小时重写整个数据库。
_andrewtoth_: 对此有什么想法吗？
fanquake: 你能简要说明一下这个 bug 吗？我的理解是我们不断地重写（数百 GB）链状态，从而严重磨损用户的磁盘？
Murch[m]: 这大大增加了修剪节点所需的最小磁盘空间 :-/_
Murch[m]: s/:-/_/:-/\/
stickies-v: 另外，你说的 12GB IBD 磁盘使用是什么意思？这似乎……太少了？
_andrewtoth_: 寻道压缩是一种机制，由于大量读取，它会压缩 leveldb 中的文件
Murch[m]: stickies-v: 仅针对 UTXO 集
stickies-v: 哦，我明白了。谢谢
_andrewtoth_: 由于我们写入很少，但读取很多，这会导致所有写入的文件都被压缩到最低层
_andrewtoth_: 这在 v30 之前每天都在发生，但 v30 现在大约每小时写入一个小文件
_andrewtoth_: 以前每天发生一次就已经是 bug 了，现在更糟糕了
Murch[m]: 可以把压缩前允许的读取次数增加吗？
_andrewtoth_: 寻道压缩的目的是针对旧的机械硬盘，它们寻道一个文件需要 10ms
_andrewtoth_: Murch: 有可能，由 willclark 建议
_andrewtoth_: 另一个选择是将 forcecompactdb 变成一个 RPC，可以定期调用
Murch[m]: 能不能把这个功能完全关闭，然后大约每周调用一次？
_andrewtoth_: 但对于向后移植，我们可以建议用户在完全同步后运行 forcecompactdb
_andrewtoth_: 我认为不值得每周调用一次。每周新写入的数据量小于 200MB。而这样做会每周重写整个数据库。
_andrewtoth_: 我认为如果用户注意到磁盘使用增加，他们可以那时再调用？
Murch[m]: 我明白了，但这不会导致链状态随时间逐渐膨胀约 25% 吗？
_andrewtoth_: 随着时间的推移，从当时的磁盘使用峰值算起，增加 11%
_andrewtoth_: 历史上链状态的峰值使用大约是 13.5 GB？所以一次 IBD 将比那个多 11%
_andrewtoth_: 如果你今天运行，你会得到一个压缩过的数据库，所以会比今天多 11%
Murch[m]: 啊，我明白了，所以 15 GB 就是这么来的
sedited: 每周重写一次似乎也没问题？
dzxzg: 能不能在数据库缓存完全刷新时启用压缩，而在间隔刷新时禁用它？
darosior: 在我们的 LevelDB 分支中调整这个参数只会影响磁盘使用，完全不影响性能？
abubakarsadiq: > 但对于向后移植，我们可以建议用户在完全同步后运行 forcecompactdb
abubakarsadiq: 为什么我们不能在向后移植补丁中自动化这个操作？
fjahr: 我们有多大把握 11% 真的是峰值？我假设目前有一些测量结果，但在某些我们可能遗漏的系统或环境下，情况可能更糟？
darosior: 也可以只在启动时执行，如果比设置计时器更容易的话？
_andrewtoth_: 这个问题特别不希望它在启动时执行 https://github.com/bitcoin/bitcoin/issues/29662
_andrewtoth_: 关于性能：数据库树中会有更多文件，但我们为所有这些文件都配备了布隆过滤器，所以跳过文件的开销很小
_andrewtoth_: sedited: 我认为不重写是 leveldb 的预期操作。如果用户在意 11% 的磁盘空间（我们在区块目录中有比链状态大 100 倍以上的空间），他们可以运行这个选项？
_andrewtoth_: dzxzg: 这还取决于用户的 dbcache 设置
Murch[m]: 嗯，不每小时重写 10 GB 似乎是这个问题最紧迫的方面。
_andrewtoth_: 我的观点是，寻道压缩是一个 bug，应该直接移除
darosior: 按照 LevelDB 认为的正常操作运行，并提供一个优化磁盘空间的机制（无论是哪种），这对我来说听起来不错。
_andrewtoth_: abubakarsadiq: 我认为我们不应该自动化它，我认为我们只需要向用户通报可能存在更高的磁盘空间，让他们根据自己的意愿运行 forcecompactdb
darosior: 通过机制向用户提供选项，无论是作为启动选项还是 RPC 命令。
darosior: 机制指的是*
_andrewtoth_: 启动选项已经存在，但我认为 RPC 更理想
_andrewtoth_: 但对于向后移植，启动选项也可以
Murch[m]: 如果已经有启动选项了，那么实现一个 RPC 应该不会太重，我想
_andrewtoth_: Murch: 是的，我相信 l0rinc 已经在做这件事了
_andrewtoth_: fjahr: PR 中有测量结果，以及更详细的解释
abubakarsadiq: _andrewtoth_: 我的问题是为什么？具体来说，我假设每个人都想获得更多磁盘空间；这样做是否有我们想使用户选择加入（opt into）的隐患？
Murch[m]: 有趣的问题。那么你的缓解方法对我没问题
_andrewtoth_: 我不认为情况会变得更糟，但希望有更多人审查
Murch[m]: abubakarsadiq: 我的理解是，用户担心增加的写入会耗尽他们 SSD 有限的写入能力
_andrewtoth_: abubakarsadiq: 代价是更多的磁盘 IO。每次都会重写几十 GB。只有在你做了一次全新的 IBD 时才真正节省 3GB。否则，你会为了微小的节省而重写一切。
dzxzg: 特别是对于修剪节点：我假设如果人们使用 prune=650 运行，他们可能会在意
Murch[m]: _andrewtoth_: 也许在 IBD 结束时进行一次自动压缩是合理的
stickies-v: 是的，在 IBD 之后进行一次似乎是合理的默认行为？
stickies-v: 如果可能的话，我倾向于不为此添加 RPC
abubakarsadiq: _andrewtoth_: Murch[m]: 现在明白了，谢谢。
darosior: 我认为启动选项应该足够了，是的
darosior: 在 IBD 之后做听起来也不错
_andrewtoth_: 我们能否方便地跟踪用户是否是从创世块开始同步并到达链尖的？
stickies-v: leveldb 是一个实现细节，通过我们公开的稳定接口暴露它有点混乱
cfields: +1 避免添加 RPC。我认为能够有意且正确地使用它的人数是个位数。
darosior: AFK
Murch[m]: 吃午饭？^^
stickies-v: 即使是启动选项，我也可能觉得过于复杂，除非有明确的需求
_andrewtoth_: 好的，未记录的启动选项已经存在，但我们可以找到一种方法，在用户首次到达链尖时执行压缩。
cfields: stickies-v: 同意。对于任何选项也是如此。如果我们不能决定何时自动执行，我们就不能期望用户知道何时手动执行。
abubakarsadiq: +1 cfields: 我认为如果我们能替用户做出这个决定，那会更理想。
Murch[m]: +1 cfields
stickies-v: 还有别的事吗，_andrewtoth_？
_andrewtoth_: 关闭了 #31132 并重新打开为 #35295。那里得到了一些很好的审查，我需要处理（谢谢！），欢迎更多审查。我就说这些，谢谢！
stickies-v: 感谢你全面的概述，听起来你得到了一些有用的反馈

stickies-v: #topic 静默支付工作组更新 (Novo__)
theStack: libsecp SP 模块 PR https://github.com/bitcoin-core/secp256k1/pull/1765 在 coredev 之后获得了一些动力和新的审查者（谢谢！）。在核心方面，Novo__ 现在基于该模块打开了 #35301 和 #35302（分别是之前 #28122 和 #28201 的第二次尝试）。非常欢迎审查。
johnny9dev: 抱歉，我得走了。这是我的 QML 更新。https://github.com/orgs/bitcoin-core/projects/1/views/3 已更新。我们正在稳步前进，并且仍然有望在 6 月中旬/末达到一个我们认为值得开始从更广泛的群体获取反馈的状态。

stickies-v: #topic 移除 Libevent (pinheadmz, fjahr)
pinheadmz: 正在解决 #35182 中的一些边缘情况。24/7 运行模糊测试。
pinheadmz: Antithesis 发现了我以为已经修复的问题，但今天早上做 DoS 测试时实际上又触发了它。这是析构函数中的一个断言，我认为我们可以放宽它，只需删除那些关闭时间过长（>60秒）的连接。在推送之前可能还需要 hodlinator 的意见……
pinheadmz: Janb84 的 grok-claude 发现了一些不难修复但很难测试的问题，因为 httpserver.cpp 中有很多讨厌的全局状态，所以我正在尝试决定这个 PR 中包含什么，以及把什么推迟到后续 PR。毫无疑问，第一个后续的“去全局化”http 重构将会非常令人满意。
pinheadmz: fjahr？
fjahr: 我只是尽快处理 #34342 上的审查评论。感觉已经非常接近完成了，感谢审查者们 :)
stickies-v: 好了，看来这就是本周工作组更新的全部内容了
stickies-v: 还有什么要讨论的吗？
jurraca: 几件关于 ASmap 的事情
jurraca: 寻求一个额外的 ACK https://github.com/bitcoin-core/asmap-data/pull/48
jurraca: 打开了一个 PR，将原型 asmap.sigs 仓库合并到 bitcoin-core/asmap-data，正如在 CoreDev 讨论的那样 https://github.com/bitcoin-core/asmap-data/pull/50
jurraca: 下一次协作运行定于 6 月 4 日，距离今天两周 https://github.com/bitcoin-core/asmap-data/issues/51
Murch[m]: 今天早上 BIPs 仓库的 CI 工作似乎非常慢。我假设这只同样适用于比特币核心 PR。有人知道发生了什么吗？
fanquake: 我想提一下 #35319
instagibbs: +1 fanquake
fanquake: 我的理解是，“正常”的 -privatebroadcast 使用实际上可能会泄露你的 IP。
fanquake: 我想知道我们是否应该以某种方式提醒用户（邮件列表/网站？）。
fanquake: 如果这里存在某种隐私期望，似乎是合理的。
Murch[m]: 另外，对于本次聊天中的任何 BIP 作者。我开始了 BIP 元数据审查，这是 BIP3 部署的后续工作。如果你有任何信息性 BIP 应该是规范性 BIP，你可能会看到一个相关的 PR（或者你可以自己打开！）。同样，任何已经处于草稿状态多年的 BIP，将被提议移至完成或关闭状态（如果适用），或者将寻求进一步的输入。
fanquake: 而且似乎还没有就如何修复/测试达成共识。
Murch[m]: 所以，如果你愿意帮忙，请在这方面审视你自己的 BIP。
instagibbs: +1 至少有一些沟通，这是一个全新的可选功能，所以影响希望是有限的。
eugenesiegel: 有几个不同的测试，我还没有……
sedited: instagibbs 你能提供一个简要说明吗？
Murch[m]: fanquake: 你说的“正常”是什么意思？我以为这种情况发生在连接从 BIP324 降级到传统 P2P 流量时？
instagibbs: sedited: 在 v2->v1 降级时（如果对等方未能建立 v2 连接），如果我们使用 Tor 出口节点，我们会直接向那个目标对等方泄露我们的 IP。
instagibbs: 换句话说，除非你连接到诚实的 v2 节点，否则它就会出问题。
instagibbs: 或者隐藏服务节点。
_andrewtoth_: 或者诚实的 v1 节点。
_andrewtoth_: *任何 v1 节点
fanquake: （而且我猜考虑到这是公开信息，监视者会开始尝试利用）
eugenesiegel: 有几个不同的测试，我还没有看过 instagibbs 的最新测试。我倾向于任何可以在不修改非测试代码的情况下进行测试的功能测试。至于修复，我认为传递一个默认为 nullopt 的 optional 会鼓励调用者忘记设置它？所以也许我们可以让它显式化？vasild 的补丁做到了。
eugenesiegel: 有效，只是在考虑如何使其健壮。
_andrewtoth_: 实际上只有在明网上的恶意 v2 节点才会导致泄露。
Murch[m]: 甚至不需要 v2 节点，你只需要伪造你的服务位。
instagibbs: eugenesiegel 我尝试做了仅测试代码的更改。
instagibbs: 但我不是网络专家，希望更多人来看。
eugenesiegel: Murch: 没错，第三方也可能为某些对等方这样做。
instagibbs: “或者诚实的 v1 节点”不，你会向诚实的 v1 节点泄露你的 IP 地址，你只是希望没人查看日志 :)
instagibbs: 哦，如果位没有被填充，对。
_andrewtoth_: instagibbs: 对于 v1 节点也会泄露你的 IP？但它是通过代理并且没有降级？
Murch[m]: 等等，它总是对 v1 对等方失败？我以为只有在降级时。那就更糟糕了。
instagibbs: 我收回我的话，需要重新记忆那部分的工作原理。
cfields: 我知道这远远超出了范围，但我在 CoreDev 上提过几次…… 隐私交易中继本可以是一个很好的机会，来启动独立的、短暂的、仅 Tor 的 CConnman/PeerManager 实例来处理广播。我怀疑否则我们会继续遇到边缘情况 :(
cfields: 只是为将来考虑一下。
eugenesiegel: 据我所知，它只在降级并且使用特定的 -proxy 选项时失败。虽然如果有 v1 对等方，第三方可以修改服务位，强制你连接 v2，然后降级。
eugenesiegel: 所以，“-proxy=127.0.0.1:9050”是安全的。”-proxy=127.0.0.1:9050=tor”是不安全的。
eugenesiegel: 我不知道这个功能有多广泛，我认为 Sparrow 用了它？我认为在邮件列表中发帖可以帮助告知人们这个问题。
_andrewtoth_: 默认代理选项的行为是什么？也就是说用户没有设置？
eugenesiegel: _andrewtoth_: 我不确定，用户是否需要设置 -proxy 来启用 Tor？
_andrewtoth_: 不需要，根据 bitcoind -h，默认是“禁用”。
_andrewtoth_: 默认也允许通过出口节点进行 pb 连接到明网。
eugenesiegel: bitcoind 如何知道控制端口？它是否设置为默认值？
instagibbs: 还有 4 分钟（这个对话无论如何都需要继续）
stickies-v: 我现在要宣布会议结束，因为时间快到了，当然你们可以继续。感谢大家的贡献。

在此阅读完整会议记录

发布

• 本周无发布

感谢阅读。请务必下周再次关注，获取比特币核心的最新动态！

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

• 原文链接： insider.btcpp.dev/p/core...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～