XRPL私有樞紐連線衝上423個 濫用指標趨近於0

XRP帳本(XRPL)一個私有樞紐的同時連線數衝上423個,顯示網路基礎設施在經歷「Manifest洪水」事件後逐漸回穩。同一時間,代表惡意流量的「Abuse」指標也降到趨近於0的水準。

身兼Ripple榮譽首席技術長的大衛·施瓦茲(David Schwartz)公佈了這份私有樞紐的觀測數據,測量期間為8月25日至9月8日。根據他公開的資料,這個樞紐平均維持約400個同時連線,尖峰時一度達到423個。

這項數據反映的是7月底XRP帳本發生Manifest洪水事件後,網路基礎設施的最新狀況。不過施瓦茲提醒,這只是單一私有樞紐的觀測結果,並不能代表整個XRP帳本網路的整體狀態。

所謂Manifest,是把驗證者(Validator)身分與簽名金鑰綁在一起的資訊。根據XRP帳本官方發布的漏洞報告,7月31日前後,大量Manifest訊息在節點間的P2P網路中擴散,導致許多節點的連線中斷。

官方報告強調,帳本的共識機制與交易處理過程並未因此停擺,也沒有出現資金損失、私鑰外洩或帳本完整性遭破壞的情況。

問題的核心並非共識失敗,而是「Peer層」的資源耗盡。Peer層是節點之間維持連線、交換資訊的網路層級,一旦這一層的資源使用量暴增,即使共識機制正常運作,部分節點的連線穩定性仍可能受影響。

官方報告列出了幾種可能原因,包括舊版節點數量短時間集中增加、過時的Manifest快取殘留,以及經過修改的「xrpld」版本涉入其中。不過報告並未確認實際成因,也沒有鎖定特定行為者。

報告同樣沒有斷定這次Manifest洪水究竟是蓄意攻擊,還是測試過程中產生的失誤。因此,現階段還不能將這起事件直接歸咎於特定攻擊者。

開發團隊在7月31日推出「xrpld 3.2.1」版本。發布說明指出,新版本修正了驗證者Manifest傳播過程中可能導致記憶體與運算資源過度消耗的問題。

官方也建議節點營運者在升級後執行一次正常重啟。事後報告說明,團隊透過限制未受信任驗證者Manifest的儲存量,並對單一Manifest大小、每則訊息的項目數量與快取規模都設下上限,來因應這次事件。

隨後推出的「xrpld 3.3.0」進一步調整了相關限制的細節。本站先前已針對XRP帳本3.3.0修正方案的驗證過程進行過報導(相關報導)。

施瓦茲公開的樞紐數據顯示,修補程式上線後,該樞紐的連線狀態已經趨於穩定,「Abuse」指標同期也降到接近0。

評論:這組數字說明修補確實發揮作用,但單一樞紐的觀測範圍有限,不能直接推論整個XRP帳本網路已完全恢復正常,兩者不能畫上等號。

這起事件顯示,即便帳本共識與交易處理維持正常,Peer連線與Manifest處理等基礎設施層級的問題,依然可能影響網路整體的可用性。接下來需要持續觀察的是,這次的修補與Manifest處理限制,是否能在各節點的實際運作環境中長期維持效果。