XRPL 修復關鍵的主網前缺陷，但客戶端應用仍面臨風險

XRP Ledger (XRPL) 驗證者已將 BatchV1_1 設置為在 9 月 29 日 UTC 時間 14:06:41 啟動，將一次安全性險境轉變為網絡修訂過程及其周邊軟體的實時測試。

在 9 月 22 日，xrpldashboard 顯示 35 個受信驗證者中有 30 個支持該修訂，超過其顯示的 28 票門檻。大多數驗證者在 9 月 15 日首次出現在帳本上。

根據 XRPL 的修訂規則，支持率必須在兩週內保持在 80% 以上。若降至 80% 或以下，則結束多數期間，因此啟動日期仍然是有條件的。

9 月 29 日是 XRPL 的驗證者過程、參考實現和客戶生態系統是否能將一個危險的主網前缺陷轉變為可用的原子交易基礎設施的首次生產測試。

驗證者防火牆在主網前運作

原始的 Batch 修訂從未在 XRP Ledger 主網上啟動。今年 2 月，研究人員在修訂仍處於投票階段時發現了一個關鍵的授權缺陷，並建議驗證者投票反對。

XRPL Labs 的官方漏洞披露聲明指出，沒有資金面臨風險。

該缺陷存在於檢查授權批次的帳戶的循環中。如果代碼遇到一個新創建帳戶的簽名者，且其密鑰與該帳戶匹配，則立即返回成功，而不是繼續檢查其餘的簽名者。

攻擊者可以將該有效簽名者放在第一位，然後添加一個偽造的條目，聲稱授權一個受害者帳戶。如果該修訂已經生效，則未經檢查的受害者交易可能會在沒有受害者密鑰的情況下執行。

XRPL 的回應分為兩個階段。版本 3.1.1 標記原始 Batch 和 fixBatchInnerSigs 修訂不受支持，阻止其啟動。BatchV1_1 隨後用重寫的授權路徑和額外的防禦措施取代了它們。

這一事件是在軟體發布和協議啟動之間的邊界上捕捉到的失敗。

XRPL 基金會的最終 XLS-56 規範現在要求多帳戶批次包含內部交易通常需要的 BatchSigners 的確切完整集，除了授權外部交易的正常簽名的帳戶。

缺失、額外、重複或錯誤排序的條目會導致拒絕。

每個 BatchSigner 還簽署不僅僅是內部交易的鬆散集合。有效載荷將簽名綁定到外部帳戶、其序列號或票證、所選的批次模式、每個內部交易的有序哈希以及 BatchSigner 帳戶。

多簽名條目還綁定每個嵌套簽名者帳戶。這防止有效簽名被提升到不同的外部交易或重新分配給其他參與者。

合併的參考實現增加了對該設計的強制執行，包括簽名者排序和唯一性檢查、交易計數邊界、拒絕直接提交的內部交易以及對帳本重放的保護。

這些變更共同解決了已披露的過早成功漏洞以及其他方式，這些方式可能使格式錯誤或重放的批次數據跨越授權邊界。

一個批次包含兩到八個內部交易。每個內部交易不攜帶簽名或費用，並被標記為無法獨立提交。外部批次精確選擇四種模式中的一種：

• ALLORNOTHING: 每個內部交易必須成功，否則它們的狀態變更不會提交。
• ONLYONE: 第一個成功的內部交易是唯一被應用的。
• UNTILFAILURE: 交易按順序應用，直到一個失敗。
• INDEPENDENT: 每個內部交易無論其他交易的結果如何都會被嘗試。

BatchV1_1 可以支持原子性的全有或全無流程，但並非每個批次在狹義上都是原子性的。開發者也可以將其用於有序回退或獨立捆綁。

啟動將風險轉移到實現上

最直接的整合陷阱是，外部批次即使在一個或多個內部交易失敗的情況下也能返回 tesSUCCESS。客戶端必須檢查每個內部交易的元數據和結果代碼，以確定發生了什麼。

這一區別在非 ALLORNOTHING 模式下尤為重要，因為部分或獨立執行是故意的。

BatchV1_1 支持於 8 月 6 日在 xrpld 3.3.0 中發佈。一旦修訂啟用，不理解新規則的伺服器將被修訂阻塞。在升級之前，它將無法可靠地驗證帳本或參與共識。

針對 xrpl.js 提出的問題記錄顯示，版本 5.0.0 使用舊的有效載荷構建批次簽名，省略了外部帳戶、序列和參與者綁定。啟用 BatchV1_1 的節點拒絕了這些簽名，並返回 temBAD_SIGNATURE。

xrpl.js 的版本歷史記錄在版本 5.1.0 中記錄了兼容的支持。

XRPL 修復的 BatchV1_1 修訂在驗證者拒絕早期簽名循環設計後接近條件啟用測試。

錢包和索引器行反映了詳細 XLS-56 規則中的整合指導。該協議可以拒絕格式錯誤的簽名，但無法強迫錢包清楚地解釋複雜的批次，或強迫探索器在上下文中呈現每個內部結果。

該規範還標記了前置交易作為仍在調查的領域。更強的授權防止一方偽造另一個帳戶的批准，但並未消除將多個面向市場的操作打包成一個有序提交所產生的所有風險。

9 月 29 日將證明什麼

如果大多數人支持，啟用將顯示 XRPL 的驗證者過程能夠阻止危險的修訂，將操作員路由到禁用的版本，並在稍後通過相同的治理機制移動修復的替代品。

這也將開始對伺服器、簽名庫、錢包和數據基礎設施是否就新交易格式及其結果達成一致的現實世界測試。

這不會證明應用程序已經採用了 BatchV1_1，或用戶希望這一功能，或網絡交易需求將會增加。修訂投票和軟件發佈確立了協議的可用性，但並不提供額外購買 XRP 的證據。

有用的信號將在啟用後出現：過時的節點是否被阻塞，簽名失敗是否集中在舊客戶版本上，錢包是否清晰地呈現多帳戶批次，以及探索器是否在不將外部成功誤認為完全執行的情況下報告內部結果。

XRPL 的驗證者成功阻止了原始批次缺陷進入主網，通過了首次測試。條件性的 9 月 29 日啟動詢問生態系統是否從這次險境中學到了足夠的知識，以安全地運行替代方案。

本內容僅供參考，不構成任何金融、投資、法律或稅務建議。文中提及的任何活動、獎勵、線上活動或相關資訊，不應被視為對購買、出售或交易任何加密資產的推薦、招攬或邀請。加密資產具有高波動性，存在價值損失風險。WEEX服務、產品及相關活動的可用性可能因地區而異。用戶在參與前有責任確保符合當地適用法律法規。