引言 在分布式哈希表（DHT）中发布内容历来是一项缓慢的操作，尤其是在以下情况下：i) 网络规模庞大， ii) 参与网络的节点频繁变化。IPFS 的 Amino DHT 也不例外，符合这两个条件。ProbeLab 团队多年前通过广泛的测量识别了这个问题，并提出了一种优化方案，该方案被证明能提高性能，即将内容发布的时间缩短了一个数量级，同时减少了 40% 的网络开销。这个优化被称为乐观提供（Optimistic Provide），最近作为默认功能在 IPFS 的 Kubo 0.39.0 中发布！该研究发表于 IEEE INFOCOM 2024，我们建议读者查看发布以获取更多更详细的信息。在此博客中，我们提供了由我们团队提出的技术概述，包含基本的技术细节，当然还有证明我们初始声明有效性的结果。感谢 IPShipyard 团队在整个过程中给予的支持，以及最终推动这一功能投入生产的努力。根据结果，这次努力是值得的。 TL;DR 乐观提供的基本思想如下：在遍历 DHT 时，立即与可能是 20 个全网最近邻的对等节点存储记录。当发现的 20 个最近邻的集合可能构成全网最近邻时，立即终止 DHT 遍历。在大多数（不是全部） PUT RPC 成功后将控制权返回给用户，并在后台继续处理剩余的请求。第 1 点和第 2 点需要了解总的网络规模，我们通过利用路由表刷新机制的轻量估算方法来获得这一信息，以避免额外的网络开销。乐观提供显著减少了上传延迟，从超过 13 秒（通常接近 20 秒）减少到不足 1 秒，为 IPFS 的性能带来了巨大的价值和影响。这在实际中意味着：内容发布者现在几乎可以实时发布他们的内容，即在内容推送到网络后约 1 秒。这是一个重大的改进，相比于之前超过 10 秒的情况，开发者、用户和应用提供者可以实时重新迭代和调试。 传统提供操作 为了理解这些优化是如何工作的，我们首先需了解传统的“提供”操作。在基于 Kademlia 的分布式哈希表（DHT）中，例如 IPFS 使用的 Amino 网络，存储一条记录需要识别与该数据标识符最接近的 k 个对等节点，其中 k 在 Amino DHT 中设置为 20。在这个背景下，“接近”并不是由地理距离定义的，而是由 XOR 距离度量来定义的。该度量通过对对等节点的唯一 PeerID 与数据的内容标识符（CID）进行按位 XOR 操作来计算这个距离。一个节点从一组硬编码的引导对等节点开始，填充其本地路由表。找到这 20 个最近邻的过程被称为 DHT 遍历（DHT Walk）。这都是一个迭代的搜索，节点查询其本地路由表以寻找最近的已知对等节点，并要求它们提供更接近的候选节点。这个循环继续，直到发起者从其发现的三个最近邻得到成功响应。一旦遍历终止，跟进阶段开始：发起者向这 20 个最近邻推送提供者记录，以确保数据可用性，即使一些节点离开网络。因此要点是：提供过程包括两个阶段 DHT 遍历 找到全网 20 个最近邻 跟进 推送记录到这 20 个节点 性能瓶颈 虽然该系统是稳健的，但历史上是缓慢的，通常需要数十秒甚至几分钟才能完成。我们在 ProbeLab 的研究发现主要的延迟是 DHT 遍历的终止条件。“传统”算法是刚性的：在 DHT 遍历阶段，它坚持等待从三个发现的最近邻收到响应。在一个无权限的网络中，由于节点频繁变化，这些特定的对等节点通常是无法到达的。然后系统“回溯”，查询距离更远的对等节点来填补空缺，而实际的 20 个最近邻可能已经被发现。下面的图表展示了来自欧洲的提供操作总持续时间的累积分布函数，欧洲是传统上速度最快的地区。原始图表可以在此找到。图表显示中位延迟约为 ~20 秒，在最糟糕的情况下，单个提供操作可能需要超过两分钟。这种性能特征对延迟敏感的应用是不可接受的，而这正是我们试图通过乐观提供解决的问题。 乐观提供 乐观提供通过用统计技术替换刚性等待来解决缓慢的提供操作。