XRP Ledger (XRPL) 正接近啟用一項升級，該升級將允許組織將單一帳戶的控制權分配至多個委託帳戶，從而限制任何單一營運金鑰的權力。

PermissionDelegationV1_1 專為經常處理交易、但不希望日常營運系統中存在能控制整個帳戶之金鑰的組織而設計。例如，穩定幣發行方可能需要一個系統來核准客戶信託線（帳本持有發行資產的機制）、另一個系統處理付款，以及一個保護更嚴密的設置來管理帳戶安全。該修正案將允許這些職責分配至不同的 XRPL 帳戶。

其「銀行式」元素在於職責分離。這並不代表獲得監管批准或已獲銀行確認採用。被入侵的委託帳戶仍可能在其被分配的角色內被濫用，但攻擊者不會自動獲得主帳戶持有的所有權力，從而降低單一外洩營運金鑰可能造成的損害。

XRPL 將在鏈上強制執行每項權限

根據 XLS-75 規範，分配權限的帳戶為委託人。它提交一筆 DelegateSet 交易，指定第二個帳戶及該帳戶可執行的操作。此關係儲存在一個 Delegate 帳本條目中。

委託帳戶以其自己的金鑰簽署、標明其代表操作的帳戶，並支付交易費用。XRPL 會拒絕超出已記錄權限的請求，委託人稍後也可更新或移除該權限。

官方文件列出了交易類型權限以及更細緻的細粒度權限，每個委託帳戶最多可獲得十項。可用的細粒度控制是先定義的，因此組織無法任意建立自訂限制。委託帳戶也必須維持有資金的帳戶，且每項委託都會建立一個鏈上物件，增加委託人的所有者儲備要求，即帳戶為其擁有的每個帳本物件必須持有的最低 XRP 數量。

敏感權力，包括變更簽署金鑰或任命新委託帳戶，均不可委託。無法立即進入開放帳本的交易將直接失敗，而非進入佇列。

二十九票啟動了有條件的倒數計時

根據即時修正案追蹤器，PermissionDelegationV1_1 於 9 月 21 日進入其 14 天啟用期，獲得 XRP Ledger 35 個受信任驗證節點中 29 個的支持。修正案是帳本變更其規則的內建機制，持續的驗證節點支持是讓新協議程式碼上主網的關鍵。至少需要 28 個驗證節點持續支持，若低於該水準，計時器將重置。CoinDesk 報導，若支持不中斷，預計啟用時間為 10 月 5 日 11:18 UTC。

該程式碼已存在於 XRPL 伺服器軟體中，但在啟用前無法在主網上使用。獨立的 Batch V1.1 修正案遵循相同的兩週流程，但它涉及的是關聯交易而非帳戶權限。

委託機制並非多重簽署的替代方案

多重簽署決定需要多少個獲批准方授權一項操作，而權限委託則限制營運帳戶可請求的操作。組織可以將兩者結合，例如將委託帳戶限制為付款，同時要求多人核准每筆付款。

金鑰遭入侵後，多重簽署可防止單一被竊簽署者達到核准門檻，而委託則可在委託帳戶遭入侵後限制攻擊者可用的交易類型。但兩種控制都無法驗證業務指示本身是否合法。

原始版本在抵達主網前即失敗

一位社群測試者發現，第一個 PermissionDelegation 實作在某些條件下，即使委託交易簽署不當，也可能向另一個帳戶收取交易費用。重複提交高費用交易可能會在未揭露受害者私鑰的情況下減少其 XRP 餘額。

該缺陷在測試中被發現，該修正案從未在主網上啟用。官方漏洞披露報告指出並無任何線上用戶資金損失。

Coindoo 先前曾探討權限委託為何隨 xrpld 3.3.0 修正案以修訂形式回歸。新的投票顯示驗證節點現在願意考慮啟用替代版本。

啟用並不代表機構採用

錢包與託管服務提供商仍須建立用於建立、審查及撤銷委託權限的介面。目前尚無任何具銀行部署的公告，機構仍須自行決定哪些帳戶獲得哪些權限。

合規決策也將保持在帳本之外。公司仍須透過自身系統執行身份驗證、制裁審查與風險評估。XRPL 只會強制執行哪個委託帳戶可提交最終授權，而不會判斷該客戶是否應獲得核准。

該功能的使用可透過公開的 Delegate 條目觀察到，但將地址與公司連結可能需要自願揭露。委託帳戶也需要 XRP 作為儲備與費用，但啟用本身並不會建立使用量或對該代幣的自動需求。

實際生產使用是下一項考驗

若驗證節點支持保持不變，證據將來自錢包整合、新的 Delegate 條目以及具名部署。這些訊號將顯示組織是否需要協議層級的區分，以分離帳戶所有權與日常營運。

這次投票使限量帳戶存取成為可能。其價值將取決於組織對這些權限的配置有多嚴謹，以及他們是否在示範之外實際使用該功能。

本文僅供參考，不構成財務、法律或安全建議。驗證節點支持與啟用時間可能發生變化。