Ripple 建議撤回 XRP Ledger 待審的 XChainBridge 修正案，因為其結論是主要用例已由 Axelar 提供服務，且更廣泛的開發者需求尚未出現。
摘要
- 在 Axelar 完全取代其預期的 XRP Ledger EVM 側鏈角色後，Ripple 建議撤回 XChainBridge。
- 待審的修正案將在連接的帳本之間使用獨立見證伺服器添加原生資產橋。
- Ripple 估計，移除 XChainBridge 可從 XRPL 伺服器代碼庫中刪除超過 10,000 行程式碼。
- Ripple 控制一個驗證者投票，目前無法單方面撤回或啟動該修正案。
- 擁有活躍 XLS-38 專案的開發者可以在社區正式完成撤回程序之前提交證據。
RippleX 的高級軟體工程師 Mayukha Vadari 於 8 月 27 日宣布了這項建議。XChainBridge，也稱為 XLS-38，仍處於 XRPL 驗證者投票過程中，尚未在主網上啟動。
Ripple 估計，撤回該提案將允許開發者從 xrpld（為網絡提供支援的伺服器軟體）中刪除超過 10,000 行程式碼。目前尚未刪除任何程式碼，且 Ripple 無法獨立完成此過程。
XRP Ledger 不再需要 XLS-38 用於其 EVM 側鏈
XLS-38 旨在提供一個協議級框架，用於在 XRP Ledger 和連接的網絡之間轉移 XRP 和發行的資產。其預期用戶包括公共側鏈、私有帳本、許可網絡和實驗性鏈。
該系統依賴獨立見證伺服器來監控每個連接帳本上的事件。見證者提交證明，確認資產在目標網絡上可用之前已被鎖定或銷毀。
該提案的主要用例之一是將 XRPL 主網與其以太坊虛擬機兼容的側鏈連接。Ripple 後來選擇 Axelar 來提供該連接。
XRPL EVM 側鏈於 2025 年 6 月啟動，以 Axelar 作為其主網橋。Axelar 的驗證者網絡驗證跨鏈消息，並將側鏈與 XRPL 和其他支援的區塊鏈連接起來。
Ripple 表示，EVM 側鏈現在通過 Axelar“更好地解決”。這仍然是公司的技術評估，而不是通過獨立安全比較得出的結論。
開發者需求疲弱改變了 Ripple 的評估
Ripple 最初保留 XLS-38，因為開發者仍可將其用於 Axelar 未設計支援的私有側鏈和專業網絡。
然而，該公司表示，幾乎沒有發現需要原生橋的活躍專案的證據。沒有生產部署公開將 XLS-38 視為其計劃運營的關鍵。
維護非活動實現仍需要開發者更新 xrpld 時進行審查、測試和兼容性工作。Ripple 認為，這造成了持續的維護負擔，而沒有提供相應的主網效益。
該建議並不意味著更廣泛的 XRPL 生態系統已放棄互操作性。Ripple 指出 Axelar、Wormhole、零知識系統和第 2 層設計是適合不同安全和隱私要求的替代方法。
跨鏈系統也引入了獨特的風險。如前所述，自2021年以來，橋接漏洞已造成超過40億美元的報告損失，使得驗證設計和操作安全成為核心考量。
Ripple無法自行移除XChainBridge
官方XRPL註冊表將XChainBridge列為待處理的修正案，預設為「否」投票。Ripple僅在網絡的獨立參與者中操作一個驗證者投票。
XRPL修正案通常需要超過80%的受信任驗證者在連續兩週內支持才能啟動。在當前預設配置中有35個驗證者，至少29個贊成票將超過該門檻。
因此，Ripple的建議既不會立即撤回修正案，也不會強迫其他驗證者反對它。驗證者獨立決定其基礎設施支持哪些修正案。
這種分離與其他XRPL提案一致。在相關報導中，Ripple對借貸修正案的支持並未確立其啟動，因為這些提案仍需更廣泛的驗證者門檻。
撤回將通過分階段的軟體變更進行
Ripple提議從一個拉取請求開始，在xrpld代碼庫中將XChainBridge標記為過時。升級到該版本的伺服器將自動投票反對啟動。
隨著驗證者安裝更新軟體，支持度將下降。一旦活躍驗證者認識到該修正案已過時，開發者可以在後續版本中移除XChainBridge實現及相關的fixXChainRewardRounding代碼。
尚未公佈拉取請求截止日期、軟體版本或最終移除日期。時間取決於社區反饋、代碼審查和驗證者升級。
Ripple已要求使用XLS-38構建的開發者或組織提供具體用例。一個可信的主動部署可能導致公司在分階段撤回開始前重新考慮其建議。
