我们如何将IPFS内容发布速度提升10倍

背景

IPFS（星际文件系统）是一个去中心化的内容寻址网络，其核心组件之一是基于 Kademlia 的分布式哈希表（DHT）——Amino DHT。在 DHT 中发布内容（即"provide"操作）需要将内容的路由记录存储到网络中距离该内容标识符（CID）最近的 20 个节点上。然而，这一操作在大型且节点频繁上下线的网络中历来非常缓慢，往往需要十几秒甚至数分钟才能完成。

ProbeLab 团队多年前通过大规模测量发现了这一问题，并提出了一种名为 Optimistic Provide 的优化方案。该方案能够将内容发布时间降低一个数量级以上，同时减少 40% 的网络开销。相关研究已发表在 IEEE INFOCOM 2024 上，而该功能终于在 IPFS 的 Kubo 0.39.0 版本中作为默认行为上线。

核心内容

传统 Provide 操作的流程

在理解优化方案之前，需要先了解传统 provide 操作的工作方式。

在 Amino DHT 中，存储一条记录需要找到距离数据标识符（CID）最近的 k 个节点（k=20）。这里的"距离"不是地理距离，而是通过节点 PeerID 与 CID 进行异或（XOR）运算得到的 XOR 距离。

整个 provide 过程分为两个阶段：

• DHT Walk（遍历阶段）：从一组硬编码的引导节点开始，节点填充本地路由表，然后通过迭代查询逐步逼近目标——节点向本地路由表中已知的最近节点询问更近的候选节点，循环往复，直到发起者收到所发现的三个最近节点的成功响应为止。
• Follow-Up（跟进阶段）：遍历结束后，发起者将 provider 记录推送给全部 20 个最近节点，以确保即使部分节点离线，数据仍然可用。

性能瓶颈所在

ProbeLab 的研究发现，延迟的主要来源是 DHT Walk 的终止条件。

传统算法非常"死板"：在 DHT Walk 阶段，它坚持等待所发现的三个最近节点的响应。在一个无需许可的网络中，节点频繁上下线（churn），这三个特定的节点往往不可达。系统此时会"回溯"，去查询更远的节点来填补空缺，而实际上那 20 个真正的最近节点可能早已被发现。

从欧洲地区（传统上最快的地区）测量的 provide 操作总耗时的累积分布函数来看，中位数延迟约为 20 秒，最坏情况下单次 provide 操作可超过两分钟。这种性能特征对延迟敏感型应用来说是难以接受的。

Optimistic Provide 的三大机制

Optimistic Provide 通过用统计启发式方法取代僵化的等待策略来解决上述问题。自 Kubo v0.39.0 起成为默认行为，通过以下三个关键机制实现亚秒级的记录存储：

1. 网络规模估计

单个节点需要本地估算全局网络规模。团队设计了一种轻量级估计算法，它搭便车利用了节点已经在收集的数据——路由表刷新机制，因此不产生任何额外的网络开销。

在路由表刷新过程中，节点会为每个维护的桶查找一个随机键（在 Kubo 中共 16 次查找），外加节点自身的 ID。每次查找返回的是距离随机目标键最近的网络级节点，因此一轮刷新自然产生了一组跨越不同尺度的节点距离样本。

核心洞察是：假设节点 ID 均匀分布，那么对于任意给定键，其最近的 20 个节点的距离遵循可预测的统计分布——具体而言是顺序统计量的 Beta 分布。这意味着一次返回 20 个节点的查找可以产生 20 个独立的网络规模估计值（而非仅一个），跨少数几次查找取平均后，结果与团队 Neula 爬虫的真实计数吻合良好。

一个复杂之处在于：在自身键空间邻域内查询（路由表刷新机制的做法）会引入密度偏差——处于密集区域的节点会高估全局网络规模，处于稀疏区域的则会低估。团队通过指数级降权非满桶的数据点来进行偏差修正。

2. 预测性终止

在 DHT Walk 过程中，发起者利用网络规模估算值来计算概率：当它有 90% 的把握确定已发现一个属于全网 20 个最近节点的节点时，立即存储记录；当它有 90% 的把握找到了目标集合时，立即终止遍历。

3. 提前返回

在 Follow-Up 阶段，系统不需要等待全部 20 个节点确认存储。当其中一部分（如 15 个）节点确认后，就将控制权交还给用户，剩余请求在后台异步继续，确保记录最终完全复制，同时不让用户等待。

效果

Optimistic Provide 将上传延迟从超过 13 秒（经常接近 20 秒）大幅降低到不足 1 秒，为 IPFS 的性能带来了巨大价值和影响。

关键要点

• 核心问题：传统 DHT provide 操作在大型、高 churn 网络中极慢，中位数延迟约 20 秒，根源在于 DHT Walk 阶段僵化地等待三个最近节点的响应，而这些节点在无需许可网络中常常不可达。
• Optimistic Provide 三要素：① 基于路由表刷新的零开销网络规模估计（利用 Beta 分布顺序统计量 + 偏差修正）；② 90% 置信度下的预测性终止遍历；③ Follow-Up 阶段部分确认后即提前返回用户，剩余请求后台完成。
• 性能提升：内容发布时间从 >10 秒降至约 1 秒，网络开销同步降低 40%。
• 网络规模估计方法：搭便车路由表刷新机制，每轮 16+1 次查找，每次查找返回 20 个节点各产生一个估计值，通过指数降权修正密度偏差，结果与 Nebula 爬虫的真实计数高度吻合。
• 学术背书：相关研究发表于 IEEE INFOCOM 2024，功能已在 Kubo 0.39.0 中作为默认行为上线。
• 致谢：IPShipyard 团队在功能落地到生产环境的过程中提供了支持。

意义与影响

Optimistic Provide 的落地标志着 IPFS 内容发布从"可用"迈向"实时可用"。对于开发者、用户和应用提供方而言，内容推送到网络后约 1 秒即可完成发布，这意味着他们可以实时迭代和调试，这在之前 >10 秒的延迟下是不可想象的。

从更广泛的角度看，这一优化为 IPFS 生态中延迟敏感型应用（如实时内容分发、即时消息、动态网站托管等）的铺平了道路。同时，该方案的核心思路——利用统计推断替代确定性等待、搭便车已有协议机制避免额外开销——对去中心化系统的性能优化具有普遍的参考价值。