IPFS Kubo 0.39.0: 使用 Optimistic Provide 加速內容發佈
IPFS Kubo 0.39.0: 使用 Optimistic Provide 加速內容發佈
IPFS Kubo v0.39.0 引入了 Optimistic Provide，這是一種將內容發佈延遲從平均 15 秒降低到 1 秒以下的技術。透過將僵化的 DHT walk 終止條件替換為統計啟發式方法，此更新實現了近乎即時的內容可發現性，同時減少了 40% 的網路開銷。
傳統 IPFS 發佈中的效能瓶頸
在 IPFS Amino DHT 中進行內容發佈傳統上需要兩個階段：首先是 DHT Walk，用以尋找與某個數據在全網範圍內最接近的 20 個節點（使用 XOR distance metric），接著是 Follow-Up 階段，將提供者記錄（provider record）推送到這 20 個節點。
從歷史上看，DHT Walk 階段一直是主要的瓶頸。傳統演算法要求在終止之前必須等待三個最接近的已發現節點的回應。在一個具有高變動性（high churn）的無許可網路中，這些特定的節點往往無法連線，迫使系統進行回溯並查詢更遠的節點。這種僵化性通常導致中位數延遲約為 20 秒，某些操作甚至需要超過兩分鐘。
Optimistic Provide 如何運作
Optimistic Provide 以三個關鍵機制取代了決定論式的等待，藉此加速 "provide" 操作：
1. 網路規模估算
為了做出機率性決策，節點必須首先估算網路總規模。Kubo v0.39.0 實作了一種輕量級的估算演算法，該演算法利用現有的路由表刷新機制，不會產生額外的網路開銷。
透過假設 Peer ID 是均勻分佈的，系統使用 Beta distributions for Order Statistics 將每個在查詢結果中的節點視為一個獨立的網路規模估算值。為了防止局部密度偏差（即位於密集區域的節點會高估網路規模），演算法會對路由表中非滿載桶（non-full buckets）的數據點進行指數級降權。
2. 預測性終止
有了可靠的網路規模估算後，節點可以在 DHT walk 期間做出機率性決策：
- 單一節點儲存： 當發起者遇到一個在統計上極有可能（90% 置信度）屬於全網最接近的 20 個節點之一時，它會立即儲存記錄，而不是等待 walk 結束。
- Walk 終止： 一旦發起者有 90% 的把握認為目前的 20 個最接近節點已構成全域最接近的集合，它就會立即終止 walk，跳過等待三個最接近節點確認的需求。
3. 提早返回
由於預測性終止跳過了傳統回溯演算法的過濾效果，可能會在 follow-up 階段包含更多無法連線的節點。為了防止單個無回應的節點導致使用者體驗停滯，Kubo 現在會在 20 個節點中有 15 個確認儲存後立即將控制權返回給使用者。
其餘的五個請求會在背景中非同步地繼續進行。研究顯示，將複製因子從 20 降低到 15 對記錄的可獲得性影響微乎其微。
對效能與可用性的影響
部署 Kubo v0.39.0 後，內容上傳延遲大幅下降，從平均約 15 秒降至約 0.7 秒。
記錄可用性
記錄的可用性並未受到顯著損害。透過樂觀方式選擇的節點在統計上與目標 key 足夠接近，足以維持可檢索性。此外，Reprovide Sweep 機制會在背景中執行精確的 PUT 操作，以修正任何初始放置的不精確性，從而確保長期的記錄穩定性，且不影響初始的使用者體驗。
目前的限制
- 無法撥號的節點： Amino DHT 中約 50% 的節點身份宣稱使用私有 IP 地址。這些節點會使網路規模估算值膨脹，導致更保守的終止閾值並降低效能增益。
- Cold Start： 節點在啟動後需要進行部分路由表刷新，才能生成網路規模估算值，這會造成數秒到數分鐘的延遲。
未來改進方向
為了進一步優化演算法，ProbeLab 團隊提出了三項增強功能：
- Peer Filtering： 在公共網路上運作時，從估算中移除僅使用私有 IP 地址的節點。
- Reprovide Sweep Integration： 利用 Reprovide Sweep 的網路枚舉功能，將準確的節點數量直接提供給樂觀提供演算法。
- Disk Persistence： 將最新的網路規模估算值儲存到磁碟中，以消除重啟後的 cold start 延遲。