一个开发者把文件推上 IPFS，然后看着终端发呆。十几秒过去了，ipfs add 还没返回。等到终于有了 CID，分享给朋友，对方又因为节点还没来得及把记录扩散到 DHT 里而打不开链接。这个场景在 IPFS 生态里重复了八年。
2026 年 5 月，IPFS 博客刊登了一篇文章，标题直白：「Optimistic Provide：我们如何将 IPFS 的内容发布速度提升了 10 倍」。背后的数据是：内容发布的延迟从中位数约 20 秒跌落至不到 1 秒，网络开销同时降低 40%。这项优化的论文早在 2024 年就发表在 IEEE INFOCOM 上，但直到 Kubo v0.39.0 才作为默认行为合入生产代码。
这篇文章不是简单复述博客内容。我们想弄清楚三个问题：慢在哪里？统计方法为什么能替代一个运行了八年的确定性算法？以及代价是什么？
慢在哪儿：DHT Walk 的终止条件
要理解提速的突破口，得先看清传统 provide 操作到底做了什么。IPFS 使用 Amino DHT——一种基于 Kademlia 协议的分布式哈希表。当节点要将一段内容（由 CID 标识）“宣告”到网络中时，它需要找到网络中 XOR 距离最接近该 CID 的 20 个对等节点，并向它们推送 provider record。这 20 个节点相当于内容的”公告栏”，后续任何检索请求都会通过同样的 DHT 路由找到它们。
这个过程拆成两步：
- DHT Walk：从本地路由表出发，迭代查询已知的对等节点，每次请求对方返回更接近目标 CID 的候选节点。Walk 的终止条件是收到三个最接近目标 CID 的对等节点的响应。
- Follow-Up：Walk 结束后，向最终确定的 20 个节点逐个推送 provider record。
瓶颈出在 Walk 的终止条件。在一个充满动态加入和离开节点的无许可网络中，“三个最近节点全部响应”是一个苛刻的要求。那些恰好落在前三的节点随时可能掉线，算法就回溯到更远的节点重新查询，而实际上真正的前 20 个节点可能早就被发现并确认了——只是还在傻等那三个”最最近”的确认。
ProbeLab 团队的测量数据显示，一次典型的 provide 操作，中位数延迟约 20 秒。在欧洲这个传统上最快的区域，仍有约 5% 的操作超过 60 秒，极端情况下甚至超过两分钟。对于一个期望用户打开网页就能立刻访问内容的协议来说，这个数字构成了一道硬门槛。
解法：统计推断替代刚性等待
Optimistic Provide 的核心思路是：用基于网络规模估计的统计推断，替代”必须等到三个最近节点确认”的刚性规则。它由三个机制组成。
网络规模估计。 个体节点需要知道全局网络大概有多少个对等节点，才能判断当前发现的节点距离目标 CID 是否”足够近”。传统思路是爬取全网络——这在无许可网络中开销巨大且不可行；或者依赖中心化统计——需要信任第三方。ProbeLab 的方案是利用路由表刷新操作中已有的数据：Kubo 节点在刷新期间会对每个桶执行一次随机 key 的查找，每次返回离该 key 最近的 20 个节点的距离分布。由于 peer ID 均匀分布，这些距离服从 Beta 分布的有序统计量——一个查找返回 20 个节点，就是 20 个独立的网络规模估计样本。若干次查找取平均，就能得到一个与地面真值（通过 ProbeLab 的 Nebula 爬虫获得的对等节点数量）高度吻合的估计。同时还用指数加权修正稀疏桶引入的密度偏差。
预测性终止。 有了可靠的网络规模估计，节点在 DHT Walk 过程中可以做两层概率判断。第一层，每次遇到一个新对等节点，如果该节点距离目标 CID 小于某个由网络规模估算的阈值（90% 置信度），就立即向其存储 record。第二层，每次收到查询响应后，检查当前已发现的 20 个最近节点的平均距离是否低于预测阈值——如果成立，说明这 20 个节点极大概率就是网络全局最接近的 20 个，Walk 直接终止，不再等待三个”最近节点”的确认。
提前返回。 传统算法因回溯而过滤掉不可达节点的副作用消失后，Follow-Up 阶段反而遇到了新问题：至少一个节点的 PUT 请求超时是常态。Optimistic Provide 的做法是，一旦 15 个节点确认存储就立刻返回控制权给用户，剩余 5 个请求在后台异步完成。选择 15 而不是 20，是基于 ProbeLab 前期研究得出的结论：在 IPFS 网络中，记录可用性对 15 到 20 的复制因子差异不敏感。
再配一个后台修正：Reprovide Sweep
Optimistic Provide 用速度换了一点 placement 精度：它可能把记录推到统计意义上”够近”但并非绝对最近的对等节点上。为此，Kubo 已有的 Reprovide Sweep 机制扮演了校准角色——它会在后台以较低频率执行一次精确的 PUT 操作，把记录重新放到最精确的节点集合上。把二者合在一起看：Optimistic Provide 负责即时可用，Reprovide Sweep 负责最终精确。
数字说话
ProbeLab 在其自建的监控工具中持续追踪多个性能指标。他们将探测节点更新到 v0.39.0 后，上传延迟从平均约 15 秒断崖式跌落到约 0.7 秒——一个数量级以上的改善。GET 错误率与经典基线相当，说明检索可靠性没有因为走”近路”而受损。
网络开销方面，由于 Walk 提前终止避免了大量冗余查询，整体网络消息量减少了 40% 以上。
这些数字回答了一个自然的问题：如果只是把等待换成后台执行，为什么不早就这么做？答案是，传统算法无法判断”什么时候等到了头”——它缺乏判断”已经找到正确节点”的能力。网络规模估计给了它这个能力。
不是没有代价
这项优化全程依赖一个准确的网络规模估计。如果估计偏移过大，距离阈值会失准，placement 精度会下降。目前存在两个主要干扰源：
第一，Amino DHT 中约 50% 的对等节点只广播了私有 IP 地址，从公网无法拨通。当前实现中这些节点仍然参与网络规模估计，导致数值偏高——但偏高只让阈值变得更保守，降低的是性能收益的上限而非破坏可用性。
第二是冷启动问题：新启动的 Kubo 节点需要至少完成部分路由表刷新才能运行估计，这可能需要几秒到几分钟。团队提议了三项改进：过滤仅私有 IP 的节点、让 Reprovide Sweep 反向馈送精确的对等节点数量、以及将最新估计值持久化到磁盘。
截至 2026 年 3 月，只有约 17% 的公网可达 Kubo 节点运行着 v0.39.0 及以上版本——这意味着 IPFS 网络中的大多数节点仍在支付经典 provide 操作的全部时间成本。
超越 IPFS
这项工作的意义不止于一个协议的性能优化。Optimistic Provide 的技术框架——基于路由表刷新数据的轻量网络规模估计、利用 Beta 分布有序统计量的概率终止条件——并不绑定 IPFS。任何基于 Kademlia 的 DHT 部署都可以采纳同样的思路。团队在文章末尾鼓励其他 DHT 网络的维护者评估这一框架是否能为自己的网络带来类似收益。
这个优化的另一个副产品是它让 IPFS 有资格进入更多延迟敏感的用例。以往，十几秒的发布延迟使得 IPFS 难以被用于实时协作、即时通讯、直播流分发等场景。亚秒级的 publish 延迟把这些门重新打开了一条缝——真正的瓶颈可能不再在 publish 这一步，而转移到内容检索和传输。
回头看，ProbeLab 做的最关键的一件事是花了大量时间测量——搞清楚慢到底慢在哪里。DHT Walk 的终止条件才是问题所在，这一洞察来自对网络行为大量测量数据的分析，而非直觉。一个良好的测量习惯，在这个故事里比算法技巧本身更值钱。
本文的素材来自公开信息和社区讨论。如果你对这个话题有更深入的一手经验，欢迎指出文中的不足。
参考链接：
- Optimistic Provide: How We Made IPFS Content Publishing 10x Faster — IPFS Blog
- Optimistic Provide — ProbeLab Blog
- ProbeLab’s Notable IPFS Performance Results — Week 07, 2026
- Kubo v0.39.0 Release Notes
- IPFS in the Fast Lane: Accelerating Record Storage — IEEE INFOCOM 2024
- Optimistic Provide — GitHub (original idea and code)
- Speed Up the IPFS DHT with Optimistic Providing — libp2p Discussion