XRP帳本已發布xrpld 3.2.1版本，這是一個生產環境熱修復，旨在阻止驗證器清單氾濫對網絡部分點對點基礎設施造成的壓力，該事件發生於2026年7月31日。xrpld是參與者運行XRPL節點和驗證器所使用的參考服務器軟件。區塊鏈持續不間斷地關閉帳本，確認共識機制在個別節點承受異常數據負載的情況下仍完全正常運作。

XRP帳本運營團隊通過其官方X帳號宣布了此次發布：

XRP Ledger 3.2.1 is now available. This fixes the manifest flood observed on Friday, July 31. The XRPL continued closing ledgers normally throughout. A post-mortem will follow soon for the community. Nodes previously accepted, stored and re-broadcast an unlimited number of… pic.twitter.com/ZOdT8REQCw — XRP Ledger Operations (@XRPLOperations) August 1, 2026

節點管理員被指示立即安裝熱修復，並在初始安裝後不久執行第二次重啟。更新後的構建引入了控制措施，防止不可信的驗證器數據消耗過多的內存、帶寬、存儲空間和處理能力。

清單氾濫如何影響XRPL對等基礎設施

XRPL依賴於一組驗證器，每個運營者通過唯一節點列表（UNL）指定為可信。只有節點UNL上的驗證器直接參與該節點的共識決策。驗證器清單將驗證器的永久主身份鏈接到共識輪次中使用的臨時簽名密鑰。這一架構使運營者能夠定期輪換工作密鑰，同時保持主憑證離線並維持驗證器的既有網絡身份。

早期版本的xrpld對節點可以接受、存儲和轉播的與未知驗證器密鑰關聯的清單數量沒有上限。由於每個節點無論信任狀態如何都會將清單數據轉發給其連接的對等節點，大量不可信數據在網絡中傳播並積累在本地緩存中。

該事件影響的是對等層消息傳播，而非帳戶餘額、單筆交易或帳本驗證規則。這一區別對區塊鏈架構而言具有重要意義：共識層故障可能導致鏈停止，而對等層故障僅降低連接性，不會損害帳本完整性。儘管XRPL繼續按計劃處理交易和最終確定帳本，但對等連接的壓力降低了連接性，並減緩了整個網絡的信息分發。

版本3.2.1中的四項防護措施

版本3.2.1引入了涉及13個文件的六次提交。這些更改在四個關鍵點實施控制，在這些位置，過大或重複的清單流量可能對節點造成負擔：

1. 解碼前大小拒絕。 xrpld現在會在解碼過程開始之前，拒絕超過預期編碼大小的單個清單，防止過大的輸入觸發不必要的計算工作。

2. 不可信批次丟棄。 節點現在會丟棄包含過多不可信清單的傳入批次。重要的是，軟件避免自動斷開發送過大批次的舊版本對等節點，這降低了升級窗口期間網絡分片的風險。

3. 對等節點問候限制。 熱修復限制了兩個節點建立新對等連接時交換的批量清單問候。可信記錄保持完全可用，而不可信的閒聊數據在發送和接收路徑上均被限制。

4. 未知密鑰存儲上限。 每個節點最多可存儲與未知驗證器密鑰關聯的100條清單。達到此上限後，更多條目將被拒絕，不可信清單不再持久化到磁盤。

必需的第二次重啟和簽名密鑰驗證

安裝更新後，管理員被指示等待大約一到兩分鐘，並確認xrpld保持正常運行。在進行下一步之前，不需要完全同步。

確認更新後的服務正在運行後，運營者必須第二次重啟xrpld。運營團隊將此次第二次重啟描述為升級程序中必不可少的最後一步。

運行打包安裝的管理員還應驗證Ripple當前的軟件簽名密鑰。Ripple於2026年2月輪換了用於簽署xrpld包的GPG密鑰，這意味著尚未信任替換密鑰的系統可能無法接收自動升級。

該熱修復不引入任何網絡修正案，也不改變任何交易處理規則。相反，它在每個階段——解碼、轉播、緩存或永久存儲之前——對不可信對等數據建立嚴格邊界。通過限制清單大小、批次數量、連接問候和未知密鑰存儲，XRP帳本已封堵了7月31日氾濫事件中使用的四個利用路徑。該事件表明，即使在共識繼續正常運作的情況下，對等層濫用仍可對個別服務器造成壓力，這是一類其他區塊鏈網絡也通過對等協議加固來解決的漏洞。

完整的故障回顧報告預計將與社區分享。