文章摘要
ProbeLab团队提出"乐观提供"优化方案，将IPFS内容发布速度提升10倍以上，同时减少40%网络开销。该方案已默认集成于Kubo 0.39.0，相关研究发表于IEEE INFOCOM 2024。
文章总结
好的，这是根据您的要求，对原文进行中文重述和精简后的版本。
标题：乐观提供：我们如何将IPFS内容发布速度提升10倍
核心摘要
在分布式哈希表（DHT）中发布内容传统上非常缓慢，尤其是在网络规模大且节点频繁变动的情况下。IPFS的Amino DHT就面临此问题。ProbeLab团队通过研究提出了一项名为“乐观提供”（Optimistic Provide）的优化方案，该方案能将内容发布时间缩短一个数量级以上，同时减少40%的网络开销。该功能已作为默认设置在IPFS的Kubo 0.39.0版本中发布。
“乐观提供”的核心思想有三点： 1. 在遍历DHT时，立即将记录存储给那些很可能是全网最接近的20个节点。 2. 当发现的一组最接近的20个节点很可能就是全网最接近的节点时，立即终止DHT遍历。 3. 在大部分（而非全部）存储请求成功后，就将控制权交还给用户，剩余请求在后台继续完成。
这些优化需要知道全网节点总数，我们通过一种轻量级的估算方法获得该数据，且不产生额外网络开销。
“乐观提供”将上传延迟从超过13秒（常接近20秒）大幅降低到不足1秒。这意味着内容发布者现在可以近乎实时地发布内容，这对于需要快速迭代和调试的开发者和应用来说是一个重大改进。
传统提供操作与性能瓶颈
传统的“提供”操作分为两个阶段： 1. DHT遍历：找到全网范围内最接近目标数据的20个节点。 2. 后续推送：将记录推送给这20个节点。
该系统的性能瓶颈在于DHT遍历的终止条件过于死板：它必须等待已发现的最接近的三个节点都给出响应。在一个节点频繁变动的无许可网络中，这些特定节点常常无法访问，导致系统需要“回溯”查询更远的节点，而实际上最接近的20个节点可能早已被发现。这导致中位延迟约20秒，最差情况甚至超过两分钟，对延迟敏感的应用非常不友好。
乐观提供的具体机制
“乐观提供”通过三个关键机制解决了上述问题：
网络规模估算：每个节点利用其路由表刷新时收集的数据，通过一个轻量级的、经过偏差校正的邻近模型来本地估算全局网络规模，不产生额外网络开销。该方法通过分析节点ID的分布规律（Beta分布）来估算，并通过对非满桶的数据点进行指数降权来修正密度偏差，从而得到更稳定的估算结果。
预测性终止：在DHT遍历过程中，节点利用网络规模估算值来计算当前发现的节点或节点集合“足够接近”目标数据的概率。一旦有90%的把握认为某个节点属于全网最接近的20个节点之一，就立即存储记录；一旦有90%的把握认为当前已发现的20个最接近节点集合就是目标集合，就立即终止遍历。这消除了传统算法中因等待不可达节点而导致的绝大部分延迟。
提前返回：在后续推送阶段，系统不再等待全部20个节点确认存储，而是在15个节点确认后就交还控制权给用户。剩余的5个请求在后台异步完成。选择15这个阈值是基于先前研究，表明将复制因子从20降低到15对IPFS网络中的记录可用性影响微乎其微。
结果与局限性
结果：在部署了包含“乐观提供”的Kubo v0.39.0后，上传延迟从平均约15秒骤降至约0.7秒。同时，记录的可检索性并未受到影响，GET错误率与经典基线相当。
局限性： * 依赖准确的网络规模估算：如果估算严重失准，会影响记录存储的准确性。目前，网络中约50%的节点只通告私有IP地址（不可达），这会导致网络规模被高估，使优化效果打折扣。 * 冷启动问题：新启动的Kubo节点需要先完成至少部分路由表刷新才能进行估算，这可能需要几秒到几分钟。
改进方向： 1. 过滤掉只通告私有IP的节点，避免其影响估算。 2. 利用“重新提供扫描”（Reprovide Sweep）功能获取准确的节点数，反馈给“乐观提供”算法。 3. 将最新的网络规模估算值持久化到磁盘，以便节点重启后能立即使用。
总结与展望
“乐观提供”从根本上重新定义了在IPFS上发布内容的体验。它实现了亚秒级的初始存储，使内容几乎立即可被发现，而“重新提供扫描”则在后台静默地确保所有记录被精确放置。这解决了IPFS长期存在的性能瓶颈，实现了超过一个数量级的加速，同时保持了记录可用性并减少了网络开销。
最直接的建议是：如果您运行Kubo，请更新到v0.39.0或更高版本。目前只有约17%的公共Kubo节点默认启用了此功能。未来的开发工作将集中在解决上述局限性，并探索将该统计框架应用于加速GET操作等其他场景。
评论总结
根据评论内容，总结如下：
主要观点与论据：
性能与速度问题：多位评论者关注IPFS的查找速度慢（评论1：“took several minutes to find a CID”）。评论2指出，通过异步化“加速”发布可能误导用户，因为实际内容尚未完全可用（“the records haven't yet been published”）。评论7强调性能差是主要障碍，包括刷新风暴、稀疏路由表和不可达节点（“horrendous performance... refresh storms, sparse routing tables”）。
安全与隐私问题：评论3批评IPFS默认泄露内部和外部IP地址到DHT（“leaking your whole internal and external IP allocations”），并质疑其安全姿态。
内容删除问题：评论4指出IPFS无法强制删除内容（“no way to delete stuff from IPFS”），用户无法控制服务器关闭后的内容存留。
生产环境使用情况：评论5质疑IPFS是否真正被用于生产环境（“Is anyone still... used IPFS in production?”），认为除技术演示外缺乏实际依赖。
架构与改进建议：评论6认为DHT架构存在缺陷，建议将网络拓扑编码到PeerID中（“encode network topology into the PeerID”），并提及使用BGP或Geo DNS引导新节点。
用户群体与声誉：评论7指出IPFS用户多为加密项目（“crypto-grift projects”），导致声誉受损，普通用户不愿采用。
平衡性总结：评论整体对IPFS持批评态度，主要聚焦性能、安全、删除机制和实际应用问题。少数评论（如评论6）认可改进努力，但强调架构性缺陷。无正面评价。