Ripple建議撤回XRPL跨鏈橋接提案XChainBridge(XLS-38)

瑞波(Ripple)日前建議XRP帳本(XRP Ledger, XRPL)社群撤回長期未啟用的跨鏈橋接提案XChainBridge(XLS-38)。瑞波並非單方面撤除這項提案,實際刪除仍需經過驗證節點共識與開源社群審查程序。

Ripple X開發者(RippleX Developers)大衛·富林(David Fuelling)於27日發表公開文章,建議一併整理XChainBridge與相關提案fixXChainRewardRounding。他表示：「這項建議並非單方面決定」,並說明「瑞波在XRPL上只是眾多投票者之一」。這段發言顯示,撤回與否最終仍取決於XRPL整體治理程序,而非瑞波單方意志。

此次事件與其說是瑞波技術路線圖的調整,不如說是XRPL治理機制如何處理長期未啟用功能的一次案例。焦點在於,當標準與程式碼長期閒置卻未正式啟用時,網路該透過何種程序將其廢止。

XLS-38是2023年2月22日定案的XRPL標準草案,設計上透過鎖倉與發行機制,搭配見證伺服器(witness server),在主網與側鏈之間轉移資產。

見證伺服器負責觀察兩條鏈上發生的事件並提交證明,藉此讓跨鏈轉移得以成立。在橋接架構中,一條鏈必須能夠信任另一條鏈上資產已被鎖定或銷毀的事實,因此監看方式與證明提交機制成為關鍵設計環節。

瑞波已於2024年6月選定Axelar作為XRPL EVM側鏈的橋接方案。當時公司表示,XLS-38仍會保留作為投票對象,但瑞波旗下的UNL驗證節點將持續投下反對票,並在12至15個月內觀察開發者端的實際需求。

瑞波在這篇公開文章中說明,在這段觀察期內,並未出現足以支持啟用XChainBridge的具體專案或明確需求。公司判斷,XRPL EVM側鏈與XRPL主網之間的橋接需求,目前已透過Axelar整合獲得滿足。

技術維運負擔也是建議撤回的原因之一。瑞波認為,XChainBridge功能若持續以未啟用狀態留在xrpld程式碼中,將造成維護負擔,也容易讓新加入的開發者感到混淆。

瑞波表示,一旦完成撤回程序,xrpld可望刪除超過一萬行程式碼。本社此前已報導過XRPL核心伺服器軟體更名為xrpld的歷程。

整體程序將分階段進行。首先,xrpld程式碼庫會提交一項拉取請求(pull request),將XChainBridge功能標記為Obsolete（已廢止）。

該項變更一旦合併,採用該版本的伺服器無論節點營運者如何設定,都不會再投票支持XChainBridge。之後隨著驗證節點陸續更新至新版本,一旦所有活躍驗證節點都將此提案標記為obsolete,XChainBridge的相關程式碼便可正式刪除。

目前撤回程序尚未完成。根據xrpldashboard,截至韓國時間28日凌晨4時33分47秒,XChainBridge狀態仍顯示為in-flight（審議中）,在35個受信任驗證節點中,僅有5個投下贊成票。

XRPL官方Known Amendments頁面同樣將XChainBridge列為尚未啟用的提案,預設投票值為No（反對）。不過需要留意的是,相關提案fixXChainRewardRounding在開發分支文件中已被標註為retired（已終止）,狀態與XChainBridge並不相同,兩者應分開檢視。

這項建議對XRPL EVM側鏈使用者不會帶來直接影響。瑞波說明,EVM側鏈與XRPL主網之間的橋接業務仍由Axelar負責處理。

社群討論焦點也隨之從「是否需要這座橋」轉向「程式碼維護與治理成本」。XChainBridge最終是否撤回目前尚未定案,下一步將是xrpld程式碼庫提出Obsolete設定提案,並交由社群審查。