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 条目以及具体的部署。这些信号将表明机构是否需要在协议层面将账户所有权与日常运营分离。

此次投票使有限账户访问成为可能。其价值将取决于机构对这些权限配置得多么严格，以及它们是否在演示之外实际使用该功能。

本文仅供参考，不构成财务、法律或安全建议。验证节点支持和激活时间可能发生变化。