驗證者支持短暫下滑，XRP Ledger 錯誤修復延至 11 月

目錄

• 你可能想知道
• 主要內容
• 重點摘要表
• 後續發展……

你可能想知道

• 為什麼驗證者支持短暫下滑會延後 XRP Ledger 的錯誤修復？
• 這項修補程式會變更什麼？其狀態與提議中的借貸系統有何關聯？

主要內容

驗證者支持短暫下滑，延後了 XRP Ledger 最新錯誤修復的啟用時間。這項變更原預計於 Oct. 23 上線，但一段時間內支持不足，導致必要的倒數計時重設。XRPLWin 列出的修訂啟用時間為 Nov. 4 的 14:46 UTC。

這次延遲反映出 XRP Ledger 處理規則變更的方式。驗證者是獨立伺服器，負責就哪些交易有效，以及哪些網路更新獲得支持達成共識。提議的變更要達到核准門檻，必須獲得網路預設信任的 35 個驗證者中超過 80% 的支持。也就是說，至少需要 29 個驗證者投贊成票。

支持度並非只測量一次。驗證者支持情況約每 15 分鐘檢查一次，而且必須連續 14 天每次檢查都達到門檻。若任何一次檢查的支持度低於要求，14 天的計時就會重新開始。因此，即使支持度很快恢復，短暫中斷仍可能延後啟用時間。

這項名為 fixCleanup3_4_0 的修補程式，在第一次啟用嘗試期間，支持度接近最低門檻。週一，它剛好獲得 29 張贊成票，沒有任何餘裕應對驗證者離線或停止投贊成票的情況。當時預定於 Oct. 23 的 09:34 UTC 啟用。

投票數下滑後，原定時程有所變動。根據 XRPL Dashboard，週三 12:54 UTC 的檢查時，僅有 26 個驗證者被記錄為支持這項修復。結果低於所需的 29 票，因此持續進行中的核准期無法繼續。

到了 14:46 UTC，支持度已回升至 29 票，新的倒數計時隨之開始。XRPLWin 現在將這項修復列為預定於 Nov. 4 的 14:46 UTC 啟用。此後，支持者已增至 35 個受信任驗證者中的 31 個。提案因此比門檻多出兩票，相較於第一次嘗試時毫無餘裕，情況有所改善；不過，在整個核准期內仍必須持續符合要求。

目前可用的追蹤工具並未指出哪些驗證者停止支持這項變更。只有在檢查時網路收到投票，該票才會計入。因此，驗證者若在不巧的時刻離線或重新啟動，其對票數的影響可能與主動投票反對提案相同。公布的數據顯示支持程度，但無法證明支持度暫時下滑的原因。

xrpld 3.4.0 的發布說明指出，這項修補程式涵蓋兩個方面。首先，它修補了代幣建立漏洞。在特定條件下，原本僅獲准銷毀發行者代幣的帳戶，仍可能建立新代幣。這項修正旨在防止這種非預期結果，並讓代幣相關權限依預期運作。

其次，這項修補程式調整了借貸程式碼判斷貸款是否逾期或違約的方式。這些計算對管理固定期限及既定還款條件貸款的系統至關重要。更新邏輯有助於確保貸款狀態評估一致，但錯誤修復預定啟用，並不代表更廣泛的借貸系統已經上線。

這段借貸程式碼與 Ripple 自 June 起向銀行和支付公司介紹的系統有關。在提議的模式中，貸方將 XRP 或其他代幣存入金庫，再由經紀商將這些資產借出固定期限。此安排串連數位資產託管與借貸流程，因此準確計算金庫和貸款資料對系統運作十分重要。

截至 Thursday，這套更廣泛的借貸系統尚未上線。它必須獲得足夠的驗證者支持，並完成另一段獨立的核准倒數計時，才能啟用。來源指出，該借貸系統距離啟動自身的啟用倒數計時，仍差 10 票。因此，錯誤修復與借貸系統應視為相關但不同的更新：修補程式可能改善相關程式碼，但更大型的功能仍在等待所需支持。

這一連串事件說明，網路治理可能影響技術變更的時程。提案或許目的明確，也看似即將啟用，但流程仍取決於計入核准的驗證者是否持續支持。在這個案例中，票數從 29 降至 26，中斷了倒數計時；之後升至 31，雖然增加了目前的票數餘裕，仍無法免除持續符合核准要求的必要。

對關注這項變更的使用者和組織而言，關鍵在於區分「預定啟用」與「已完成啟用」。Nov. 4 是 XRPLWin 列出的修訂時間，並不表示啟用已經發生。在支持度未能維持完整 14 天且更新尚未生效之前，這項修補程式仍處於待處理狀態。公布的數據呈現驗證者支持度的某個時間點，而核准機制則決定這些支持能否長期維持在足夠水準。

重點摘要表

後續發展……

接下來值得關注的是，fixCleanup3_4_0 的驗證者支持度能否在重新開始的核准期內持續高於要求，以及借貸系統能否取得足夠票數，啟動自身的倒數計時。這是兩個不同的里程碑：錯誤修復的支持度已回升至 35 票中的 31 票，而更廣泛的借貸功能仍未達到其所述要求。

更廣泛來看，以驗證者為基礎的網路或許能受益於更清晰的工具，用來呈現支持度隨時間的變化，並區分刻意的投票決定與暫時的伺服器故障或重新啟動。提高透明度有助於觀察者理解提案為何失去票數，而不會假設每一張未收到的票都代表反對。持續探索可靠的監控方式、透明的治理流程，以及經過審慎測試的金融軟體，有助於網路以兼顧問責與韌性的方式進行技術變更。

核心教訓是，網路升級不只取決於修補程式的品質，也仰賴負責核准的驗證者持續協調。