XRP Ledger v3.2.0 部署——採用增加但關鍵修正案仍落後
目錄
您可能想知道的事
1) 在啟用 XRP Ledger 升級時，驗證節點（validator）的支持如何與整體節點採用情形不同？
2) 即便節點已安裝新的 v3.2.0 軟體，鏈上修正案 fixCleanup3_2_0 為何仍然重要？
主要議題
XRP Ledger 已推出伺服器軟體 v3.2.0，此版本明確旨在降低運營成本、提升穩定性並讓協議對機構參與者更具吸引力。該升級包含效能改進及一系列程式碼變更，以簡化節點運作並支援較新的鏈上功能。早期指標顯示，網路中最重要的參與者——位於預設唯一節點名單（UNL）內的驗證節點——已有明顯採用。不過，在更廣泛的活躍節點中，採用率仍屬溫和；而一項將多項安全修復與功能保護納入的正式鏈上修正案，目前在投票支持度上明顯低於軟體安裝率。軟體部署與修正案投票之間的這種區別，是理解此次升級現況的關鍵。
從高層來看，XRP Ledger 將兩個相關但不同的程序區分開來。首先，像 v3.2.0 這樣的伺服器軟體會分發給運行節點的運營者：這些機器負責儲存與轉發分類帳資料。安裝軟體是讓節點能受益於效能與運營改進的技術步驟。其次，修正案透過鏈上投票實施，這是正式在網路上啟用協議層面變更和某些安全防護的方式。分類帳要求位於 UNL 的驗證節點持續支持該修正案，修正案才會啟動。由於存在這兩條路徑，軟體可能在節點運營者間迅速部署，而鎖定協議行為的相應修正案則在治理過程中落後，兩者不必同步。
目前的網路量測突顯了這種分歧。在大約 833 個參與持有與傳播分類帳資訊的活躍節點中，約有 43% 被觀察到運行 v3.2.0，而約 51% 仍停留在先前的 v3.1.3 發行版。這些數字顯示，雖然有相當比例的節點已升級，但多數廣義節點尚未完成轉換。相較之下，驗證節點層級的採用情況則呈現不同面貌。分類帳維持由 35 個驗證節點組成的預設唯一節點名單，這些節點被視為決定協議啟用的可信來源。在這 35 個節點中，已有 31 個升級到 v3.2.0——約 89%——超過網路慣常用來判定升級已充分採納的 80% 支持門檻。由於軟體相關行為的啟用依賴於驗證節點的持續背書，因此 UNL 內的高比例是網路是否視為實際已更新的決定性指標。
儘管軟體版本在驗證節點間已獲多數支持，修正案程序並未同步推進。名為 fixCleanup3_2_0 的特定修正案正在進行鏈上投票。該修正案將多項以安全為導向的修復與行為調整打包，旨在保護並穩定分類帳的新功能。包內項目包括單一資產保管庫（vaults）、受權去中心化交易所、通用代幣（MPTs）以及借貸協議的保護與改進——後者是一種可針對資金池提供抵押貸款的鏈上借貸機制。修正案的另一重要元素是引入內部檢查，以防被刪除的帳戶留下孤立或零散資料，這類安全問題可能對長期運營造成影響。
之所以需要該修正案，是因為僅安裝伺服器軟體並不會改變決定交易與分類帳狀態如何被驗證的鏈上規則。驗證節點必須同時運行更新的軟體並在鏈上投票支持該修正案，這些正式的規則變更才能生效。目前雖然許多驗證節點已安裝 v3.2.0，但對 fixCleanup3_2_0 的投票仍相對較低。這種不匹配意味著若修正案達到啟動門檻，拒絕支持該修正案的驗證節點可能會陷入被修正案封鎖的狀態——若沒有同時升級並投票支持，將可能被共識孤立。
像 Ripple 這類與分類帳開發有歷史淵源的支付公司等利益關係者已公開投票支持 fixCleanup3_2_0。Ripple 的支持顯示主要生態系行為者認為該修復套件對於保護與成熟化新功能很重要。然而，整體投票趨勢仍顯示部分驗證節點在採取行動上存在謹慎或延遲。原因可能包括營運者的風險管理措施、內部測試的需要、治理上的審議或只是分批升級的時程安排。最終效果形成一個兩步的採用流程：先執行已升級的節點軟體，再另行在鏈上批准修正案。
從運營角度看，這種分階段推進有利有弊。分階段讓驗證節點能先驗證節點層級的相容性並觀察實際行為，才承諾協議層的變更，可降低突如其來的全面切換所帶來的未知互通性風險。然而，軟體部署與修正案支持之間的延遲也可能延長網路無法完全受惠於修正案所帶來的安全與功能防護的時間窗。這段延長的期間會讓某些新功能在沒有修正案所建立的額外保護下運作。
簡言之，v3.2.0 的推出顯示 XRP Ledger 在朝向更高效率與機構就緒方向有健康的進展，特別是由預設 UNL 內驗證節點的採用推動。然而，包含 fixCleanup3_2_0 的安全強化與功能保護，在鏈上投票達到正式啟動要求之前仍無法完全實現。營運者與觀察者因此應將軟體安裝與修正案投票視為互補但不同的網路升級生命週期步驟。
重點摘要表
| 面向 | 描述 |
|---|---|
| 軟體版本採用 | 約 43% 的活躍節點在網路上運行 v3.2.0，而約 51% 仍停在 v3.1.3。 |
| 驗證節點採用 | 在 35 個預設 UNL 驗證節點中，31 個（約 89%）已升級到 v3.2.0，超過用於判斷升級就緒性的 80% 門檻。 |
| 鏈上修正案 | fixCleanup3_2_0 將多項針對保管庫、MPT、借貸與資料清理的安全修復打包，但其投票支持度遠低於軟體安裝率。 |
| 啟動條件 | 修正案要啟動，需要超過 80% 的 UNL 驗證節點連續兩週的持續支持。 |
| 不合規風險 | 未升級或未對修正案投票的驗證節點，風險是被修正案封鎖並可能失去共識連線。 |
後續……
展望未來，XRP Ledger 的演進將取決於節點運營者、驗證節點與生態系利害關係者之間的持續協調。驗證節點對 v3.2.0 的快速採用模式，顯示出網路有完成升級週期的可能途徑，但軟體部署與修正案投票之間的差距則指出需更清晰的治理協調或進一步測試，才能促使更多驗證節點達成合規。如果鏈上修正案取得必要票數，網路將獲得重要的安全保護與功能防護；反之，若投票差距持續拉長，則可能延長新功能的運營風險。觀察者應同時監控節點軟體遙測與鏈上投票數據，以評估分類帳何時能完全實現 v3.2.0 及其相關修復所預期的效益。
