XRP Ledger Batch V1.1 逼近啟動門檻,資產管理公司積極準備
重點速覽
- •XRP Ledger Batch V1.1 允許使用者將最多八筆關聯交易歸入同一父操作之下,該操作要嘛全部完成,要嘛完全取消。
- •此修正案目前獲得追蹤的 35 個驗證節點中 30 個的支持,已超過 80% 絕對多數門檻,若支持度連續十四天維持,可能於 9 月 29 日啟動。
- •RippleX 工程負責人 Ayo Akinyele 表示,商業專案已經在採用此功能,並以付款交割結算與附加平台手續費作為關鍵應用場景。
- •Batch V1.1 在 Batch V1.0 因二月份發現的關鍵簽名驗證缺陷而撤回後重返;該缺陷從未控制過正式帳本,也未直接造成用戶資金損失。
- •修訂後的程式碼已於 8 月 6 日隨 xrpld 3.3.0 版本發布,並經由 AI 輔助分析、Sherlock 攻擊競賽,以及 Halborn 與 Common Prefix 的評估進行審查。

Ripple 表示,資產管理公司正在為 XRP Ledger Batch V1.1 做準備,這是一項支付升級,可讓多筆關聯交易以單一、全有或全無的操作方式結算。該修正案可將最多八筆 XRP Ledger 交易歸入同一父操作之下,使所有交易要嘛全部完成,要嘛整組取消。此升級允許資產轉移、支付與平台手續費作為單一操作一併結算,或一併失敗。
根據 XRPL Dashboard 的資料,目前追蹤的 35 個驗證節點中有 30 個支持此功能,票數已超過啟動所需的 80% 絕對多數門檻。修正案需要 28 票才能啟動倒數,該程序已於 9 月 15 日 14:06:41 UTC 開始。根據 XRP Ledger 的修正案機制,協議變更必須在驗證節點間獲得持續的絕對多數支持後才會生效,此機制旨在確保變更上線前達成廣泛共識。若支持度在連續十四天內維持在所需的 80% 門檻之上,則可能於 9 月 29 日啟動。
RippleX 工程負責人 Ayo Akinyele 表示,商業專案已經在以 XRP Ledger Batch V1.1 為前提進行開發。
條件式啟動路徑
這次投票為 Batch V1.1 提供了一條條件式上線路徑。驗證節點倒數期間隨時改變立場。若支持度跌破 80%,時鐘即停止,且在修正案重新達到門檻後,必須重新開始為期十四天的計時。
Batch V1.1 將交易歸入一個父操作之下。使用者最多可提交八筆關聯交易,且每筆交易保留其個別細節。全有或全無的設定可防止群組中任何單筆交易失敗時出現部分結算。
不同於多步驟流程,這種群組操作為交易對手提供了明確的結算條件:若其中一腿失敗,帳本不會完成另一腿。這種設計可簡化 XRP Ledger 上基金、交易平台與代幣發行方的結算流程,並為開發者提供一種合併轉帳的方式,無需依賴回呼或人工對帳。此功能本身並不保證被採用,因為專案仍需完成測試、合規與準備工作。
付款交割驅動應用場景
這種群組功能對於建構數位市場的資產管理公司尤其重要。基金可以在同一帳本操作中轉移代幣化資產並同時收取款項,使 Batch V1.1 在原子結算中扮演直接角色。
Akinyele 指出付款交割(Delivery-versus-Payment)是關鍵應用場景。這種方式將資產交付與支付連結起來,而不是要求一方先行發送,可降低交易中結算不完整的風險。
Ripple 也指出手續費是另一項應用。交易所、錢包與市場平台可在客戶交易上附加服務費用,讓支付與手續費作為一個群組操作一併處理。
RippleX 尚未公布使用此功能的商業專案名稱。Akinyele 表示,待合作夥伴正式確定計畫與上線時程後,將公布更多細節,並補充說啟動將使開發工作更接近正式上線。
因安全缺陷撤回後重返
這次的預定啟動是在 Batch V1.0 撤回之後。研究人員於二月發現一個關鍵的簽名驗證缺陷。在某些條件下,程式碼可能提前停止檢查簽名,讓攻擊者得以在未經授權的情況下納入來自其他帳戶的交易。
在開發者撤回該修正案時,驗證節點尚未啟動原始版本。因此有缺陷的程式碼從未控制過正式運行的帳本,該缺陷也未直接造成用戶資金損失。
RippleX 利用此次事件重新設計了簽名與授權模型的部分內容。替代版本已於 8 月 6 日隨 xrpld 3.3.0 版本布,Ripple 表示目前審議中的程式碼與該版本一致。
審查範圍擴大至 AI 輔助分析與 Sherlock 攻擊競賽。安全公司 Halborn 與 Common Prefix 進行了評估,RippleX 在尋求驗證節點批准前也進行了內部對抗性測試。該公司表示,擴大的審查程序促成了此修正案重返投票。
Akinyele 表示,團隊提高了審查標準、修復了缺陷,並提交 Batch V1.1 進行另一輪驗證節點投票。
根據目前的時程,修正案窗口將持續至 9 月 29 日。支持度必須在整個期間維持在 80% 或以上。任何跌破該水準的情況都會暫停啟動,並需在支持度恢復後重新進行倒數。
來源:Blockonomi