XRPL 呼籲節點運營商在驗證器清單洪水後升級至 xrpld 3.2.1

標題：XRPL 在「宣言洪水」壓力網絡資源後敦促緊急升級節點 Ripple 工程總監 Vijay Khanna 於 8 月 2 日敦促 XRP 帳本節點運營商立即安裝 xrpld v3.2.1，因開發人員於 7 月 31 日發現驗證節點「宣言洪水」。此快速熱修補程式限制節點處理、儲存和分享來自未知驗證節點身份的宣言資料，防止攻擊者耗盡節點的記憶體、儲存空間、頻寬和 CPU 資源，同時確保帳本正常運作，直至運營商部署修補程式。 事件經過 - 7 月 31 日，開發人員觀察到大量來自未知身份的驗證節點宣言。儘管帳本仍正常關閉，但此事件對節點資源與點對點通訊造成壓力。 - 目前無公開證據顯示資金被盜、交易被篡改或共識失敗。開發人員尚未發布 CVE，亦未公佈與此事件相關的財務損失估計。 - XRPL 運營團隊表示將進行技術事後分析；截至 8 月 2 日，洪水的來源、總量及具體資源影響仍未披露。 為何驗證節點宣言至關重要 - 驗證節點宣言是經過密碼學簽名的記錄，將驗證節點的穩定主身份與日常驗證訊息使用的臨時金鑰綁定。當運營商輪換臨時金鑰時，會發布由主金鑰簽名的新宣言，以便同儕驗證變更。 - 在熱修補程式之前，xrpld 可接受、快取並重新廣播針對其未識別驗證金鑰的結構正確宣言。攻擊者可利用此行為建立大量未知身份，迫使同儕浪費記憶體、儲存空間、頻寬與處理能力來處理這些資料。程式碼倉庫將此問題描述為宣言傳播濫用。 xrpld 3.2.1 的內容 - 官方 xrpld 3.2.1 版本（日期為 7 月 31 日；於 8 月 1 日初簽署並發布）包含 13 個檔案中的六次提交。其中四次提交直接限制對不可信宣言的處理，主要防護措施如下： - 在節點完全解碼前即拒絕過大的宣言，降低每個惡意物件的 CPU 負擔。 - 嚴格限制單一網路訊息中允許的不可信宣言數量——在接收時與準備發送給同儕時均適用。過大的批次將被捨棄，但不會斷開未升級的同儕連線，以提升升級相容性。 - 每個節點快取的未知驗證身份數量上限為 100。一旦達到上限，新的未列名宣言將被拒絕，但已信任且被記憶的驗證節點仍可正常處理。 - 調整不可信宣言資訊的保留與散播方式，專注於阻止未列名同儕的散播，而非已配置/信任驗證節點的宣言。此舉在阻擋無限制快取增長的同時，保留了合法驗證金鑰輪換功能。 運營商指引與升級注意事項 - Khanna 建議驗證節點與基礎設施運營商盡快升級至 v3.2.1。建議流程：執行正常軟體更新，等待一至兩分鐘確認 xrpld 正在運行，然後再次重啟服務。第二次重啟有助於清除修補前保留在記憶體中的未知宣言。 - 運營商亦應確認其系統信任 Ripple 當前的 GPG 套件簽署金鑰。Ripple 已於 2 月 18 日更換該金鑰；未信任新金鑰的節點可能無法接收自動升級。 - 此更新僅針對基礎設施運營商（交易所、託管方、錢包後端、資料供應商及運行 XRPL 伺服器的企業）。一般 XRP 持有者無需轉移資金、輪換金鑰或採取任何行動。 背景與下一步 - 此熱修補程式緊接於更廣泛的 xrpld v3.2.0 部署（6 月 15 日）之後，該版本將參考伺服器名稱由 rippled 改為 xrpld，並要求運營商更新設定。驗證節點對 v3.2.0 的採用率高於整體節點網路；此次宣言洪水為剩餘運營商提供了另一個強力理由，以升級至 v3.2.1。 - XRPL 運營團隊承諾將發布技術事後分析報告，詳細說明活動首次被發現的時間、是否有節點無法使用、宣言總量以及運營商採用修補程式的速度。在該報告發布前，確認細節僅限於 v3.2.1 的修復內容及要求運營商升級並重啟的請求。 結論 若您運行 XRPL 基礎設施，請將此視為緊急事項：立即升級至 xrpld 3.2.1，並遵循兩步重啟建議以清除任何保留的不可信宣言。對於更廣泛的 XRPL 社群而言，此事件似乎是一次資源耗盡嘗試，而非協議被攻破——但即將發布的事後分析報告對於確認完整範圍至關重要。