XRPL Dashboard 於 9 月 26 日 04:43 UTC 被檢視時,記錄到其追蹤的 35 個受信任驗證節點中有 30 票贊成。此票數為 BatchV1_1 修正案開啟了新的核准窗口——但單憑這一點並不會完成啟用流程。

重點整理:

• BatchV1_1 重新獲得 35 票中的 30 票驗證節點支持。
• 先前為期兩週的核准時鐘已重置。
• 現在至少需要維持 29 票。
• 10 月 9 日是最早的條件性日期。
• 鏈上啟用才能確認升級。

即使票數回升,日期仍然重置

BatchV1_1 曾於 9 月 15 日達到 30 個支持的驗證節點。按照原定時間表,這將使啟用落在 9 月 29 日左右。隨後多數支持於 9 月 25 日被移除,並於同日稍後重新形成,使預估日期推遲約 10 天。

Dashboard 顯示了先前多數支持被移除以及新多數支持被記錄的標記帳本(flag ledger),但並未透露為何發生此次暫時性變動,也未說明個別驗證節點的理由。已確認的事實就是重置本身:一項修正案需要在整個窗口期間獲得不中斷的支持,即使其票數隨後回升至相同水準。

這使得 10 月 9 日成為基於帳本當前多數支持記錄得出的條件性預估。在啟用之前,該日期仍可能再次變動。

30 票贊成僅高出門檻一票

XRPL 的門檻常被簡稱為「80% 支持」,但規則實際上更為嚴格:修正案需要獲得受信任驗證節點超過 80% 的支持。在 Dashboard 監測的 35 個驗證節點中,28 票恰好等於 80%。BatchV1_1 需要 29 票贊成才能建立或維其多數。

目前的 30 票約等於 85.7%,僅比 29 票的要求多出一票。若從 30 票降至 29 票,倒數計時將不受影響;若降至 28 票,則會在相關標記帳本觸發另一次重置。

XRPL 的修正案流程在標記帳本前後檢查票數,通常約每 15 分鐘一次。這些標記帳本作為定期檢查點用以衡量支持度,而兩週的時鐘只在票數保持在門檻之上時運行。一旦修正案連續兩週獲得超過 80% 的支持,該變更將永久適用於後續的帳本版本。

伺服器程式碼與主網規則是不同的階段

Coindoo 先前曾解釋 BatchV1_1 如何協調關聯的支付指令。此次重置引出的問題並非該實用功能本身。目前的問題是,修正後的修正案能否完成驗證節點流程,使這些交易規則得以在主網生效。

修正案在伺服器軟體中可用後,即有資格接受驗證節點投票,而主網行為只有在網路啟用後才會改變。正因這種分離,Dashboard 上的日期應被視為治理進度的即時預估,而非產品發布公告。

先前的安全撤回為何在此時重要

BatchV1_1 是較早的 Batch 修正案的修正後繼任版本;後者在研究人員發現授權缺陷後,於主網啟用前被撤回。原始版本從未生效,因此該問題並未使主網用戶資金面臨風險。

根據 XRPL 漏洞揭露,替代版本對簽名與授權檢查進行了修改,並在重新進入投票前接受了進一步審查。此事件也顯示了該流程如何按設計運作:已在伺服器軟體中可用的程式碼,仍可在改變主網規則之前被叫停。全新的 14 天窗口是該修訂實作當前的治理考驗。

需要關注的確認在帳本上

只有在多數支持維持整個窗口期間,10 月 9 日才具有意義。確認將來自帳本記錄的 EnableAmendment 偽交易,此後 BatchV1_1 將成為後續帳本的主網有效規則。

在該事件出現之前,值得關注的更新是驗證節點多數支持的延續性。Dashboard 提供了當前倒數的有用視圖,但帳本的啟用記錄才將決定修正後的 Batch 修正案是否真正跨入線上 XRPL 基礎設施。

本文僅供資訊參考,不構成財務或投資建議。驗證節點支持度與修正案狀態可能隨時變動。