Ripple 工程總監 Vijay Khanna 於 8 月 2 日敦促 XRP Ledger 節點營運商安裝 xrpld 3.2.1 版本，此前開發人員於 7 月 31 日觀察到驗證者宣言洪水事件。
此熱修復限制了節點處理、儲存和共享從未知驗證者身份接收的數據的方式。
根據 XRP Ledger Operations 的說法，在該事件期間，XRP Ledger 繼續正常關閉帳本。因此，現有證據指向節點資源和點對點通訊所承受的壓力，而非已確認的資金損失、交易篡改或帳本共識失敗。開發人員尚未發布與此事件相關的 CVE 識別碼或財務損失估計。
驗證者宣言是經過密碼學簽署的記錄，用於將驗證者穩定的主身份與其用於每日驗證訊息的臨時金鑰連接起來。當營運商輪換這些臨時金鑰時，他們會發布一個由主金鑰簽署的新宣言，以便其他節點可以驗證此變更。
在熱修復之前，節點可以接受、快取並重新廣播與其不識別的驗證者金鑰相關聯的結構有效宣言。攻擊者可以利用這種行為，製造許多未知身份，並迫使同行節點耗費記憶體、儲存空間、頻寬和處理能力來處理數據。公共程式碼記錄將此缺陷描述為宣言傳播問題。
官方 xrpld 3.2.1 版本發布日期為 7 月 31 日，並於 8 月 1 日初作為最新簽名版本發布。它包含橫跨 13 個變更檔案的六個提交，其中包括直接限制不受信任宣言處理的四個提交。
第一項防護措施在節點完全解碼超大驗證者宣言之前將其拒絕。這減少了攻擊者透過發送大於軟體預期尺寸的單獨物件所能觸發的處理工作。
第二項限制了在一個網路訊息中攜帶的不受信任宣言數量。該限制適用於節點接收數據時，以及它們為同行節點準備宣言訊息時。超大的批次將被丟棄，而不會自動斷開未修補節點的連接，這有助於已升級和舊的節點在推出期間保持連接。
第三項變更限制了節點宣言快取中持有的未知驗證者身份數量。最終程式碼將上限設為 100。一旦達到該容量，軟體將拒絕與新的未列出金鑰相關聯的宣言，同時繼續處理受信任或先前已識別的驗證者。
該補丁還改變了不受信任宣言資訊的保留和傳播方式。受信任的驗證者數據仍然可用，因為這些限制針對的是未列出的同行閒聊，而非來自已配置或經批准的驗證者的宣言。這種區別允許正常的驗證者金鑰輪換繼續進行，同時阻止未經檢查的快取增長。
Khanna 建議驗證者和其他基礎設施營運商「盡快」升級到 3.2.1 版本。他的指示要求進行正常的軟體更新，然後等待一到兩分鐘，並檢查 xrpld 是否正在運行。營運商隨後應再次重啟服務。
第二次重啟對於在安裝修復程式之前可能保留了未知宣言的節點至關重要。更新會改變未來的處理方式，而重啟已修正的伺服器有助於確保舊的記憶體中或先前保留的數據不會繼續影響營運。
營運商可能還需要確認他們的系統信任 Ripple 當前的套件簽名金鑰。發布說明指出，Ripple 已於 2 月 18 日輪換了用於簽署 xrpld 套件的 GPG 金鑰。未信任替換金鑰的現有安裝可能無法成功接收自動升級。
此更新適用於基礎設施提供商，而非普通 XRP 持有者。用戶無需因宣言問題而移動 XRP、更改錢包金鑰或創建新帳戶。交易所、託管機構、錢包後端、數據提供商以及運行自己 XRPL 伺服器的企業應確認其節點版本和重啟狀態。
XRP Ledger Operations 表示，技術「事後分析報告將很快發布」。截至 8 月 2 日，該項目尚未發布該報告，因此發送者的身份、傳輸的宣言數量以及受影響節點的確切資源使用情況仍未公開。
該報告還應澄清開發人員何時首次檢測到該活動、是否有任何節點變得不可用以及營運商採用 3.2.1 版本的速度。儘管帳本繼續關閉，緩慢的補丁採用可能會使個別伺服器暴露於新的洪水攻擊，即使共享帳本保持運作。
此熱修復在 XRPL 較大的 3.2.0 版本推出後不久發布。該版本於 6 月 15 日發布，將參考伺服器從 rippled 更名為 xrpld，並引入了基礎設施變更，要求營運商更新軟體和服務配置。
如先前報導，3.2.0 版本最初在驗證者中的傳播速度快於更廣泛的節點網路。宣言洪水為剩餘營運商提供了超越該版本並安裝熱修復的新理由。
同時，在相關報導中，David Schwartz 將其 XRPL 基礎設施遷移到 3.2.0 版本，因為開發人員正在為網路準備新的伺服器命名和協議功能。早些時候，正如 crypto.news 報導，節點營運商還面臨與修正案激活相關的 3.1.3 版本截止日期。
下一個經證實的更新將是承諾的事後分析報告和新的軟體採用數據。在此之前，已確認的回應仍僅限於 3.2.1 版本、其四項宣言控制措施以及要求營運商完成升級和重啟過程。
