XRP Ledger 验证者更青睐重构后的交易打包功能，而非账户权限委托

XRP Ledger 的验证者正大力支持一项重构后的交易打包（Batch）功能，其支持率远超另一项重构后的账户权限委托（Permission Delegation）功能。尽管后者刚刚通过了第二次独立的安全审查，但前者的速度是其两倍有余。此前因存在漏洞可能导致从其他账户扣除费用而于去年被禁用的“权限委托”功能，目前获得了 35 个验证者中的 11 个支持，占比约 31%。而同样因关键缺陷于今年 2 月被撤回的“批量处理”功能，则获得了 24 个验证者的支持，占比高达 68.57%。根据规定，两项功能均需获得超过 80% 的支持率，并连续两周维持该状态方可激活。

当前支持率对比

“权限委托 V1.1”目前获得 31% 的验证者支持（35 个中的 11 个），相较于 8 月 21 日的 20%（35 个中的 7 个）有所上升。据 XRPScan 数据显示，“批量处理 V1.1”的支持率为 68.57%（35 个中的 24 个），是权限委托总支持率的两倍多。

在此次发布的六项修正案中，仅有一项名为 fixCleanup 的小型修复达到了 80% 的支持门槛，并将于 9 月 11 日激活。

差距背后的原因

这两项修正案有着相同的“伤痕”。它们都曾首次上线，随后都因在主网被利用前发现了关键漏洞而被撤回，并最终在同一个版本中以重写形式回归。该版本为 xrpld 3.3.0，于今年 8 月初作为包含六项修正案的包发布。时隔八个月，其中一项已接近激活，而另一项的支持率刚超过三分之一。第二次干净审计本应是权限委托对其过往历史的回应，但在数据层面看，这还不足以让它迎头赶上。

首次及二次故障回顾

权限委托旨在允许账户在不交出私钥的情况下移交特定任务，如去中心化交易所（DEX）交易、代币铸造以及与追回相关的合规工作。该功能最初随 rippled 2.6.1 版本推出，但在 2025 年 9 月被禁用，原因是社区成员在 devnet（开发网络）测试时发现，权限检查在签名检查之前运行。攻击者可以提交没有任何有效签名的交易，但仍会触发对受害者账户的费用扣除。修复方案重新排序了这两个检查步骤，并以“权限委托 V1.1”的形式发布。

批量处理的错误虽然不同，但后果相似。它允许来自不同账户的多达八笔交易作为一个原子单元执行。今年 2 月，研究人员和 Cantina 的自动化审查工具发现外层交易的签名验证存在缺陷，这可能使攻击者在从未持有私钥的情况下操作账户。紧急发布的 rippled 版本在几天内阻止了有缺陷的版本，并由 BatchV1_1 取代。

干净的第二次审计与持续警告

一位审查该修复方案的验证者表示，Cantina 在春季进行的为期约两周的权限委托后续审查发现了九个问题，其中两个被评为高风险，所有问题均在随后的构建中得到解决。该构建已通过五千多次测试，未出现新问题。这一具体账户信息由单一验证者传达，而非由 Cantina 或 Ripple 直接发布，除该验证者在 XRPL 安全领域的记录外，此处尚未得到独立证实。

这也并非该功能经过审计后仍遗漏问题的首次案例。另一家公司于 2025 年 6 月进行的早期审查仅发现了一个阴影变量和两条信息性备注，而在三个月后的常规 devnet 测试中出现了导致费用被扣除的漏洞。XRPL 开发者 Wietse Wind 在 11 月提出了相关观点，认为审计、黑客马拉松和开发人员测试各自能发现不同的问题，没有任何单一手段能让验证者仅凭信任而非验证进行投票。他虽未特指此次审查，但这一谨慎态度依然适用。

以上情况并不意味着权限委托是不安全的，也不意味着批量处理爬升更快证明验证者出于特定原因更信任它。批量处理可能目前对 XRPL 正在争取的机构用户更具实用性，而验证者并不公开其投票理由。数字显示的情况更为具体且难以辩驳：两项以相同方式失败、在同一版本中发布的修正案，并未以相同的速度恢复，而第二次干净的审计并未能单独缩小这一差距。随着 fixCleanup 于 9 月 11 日激活——这是验证者群体在满意后行动速度的第一个迹象——我们值得持续关注这一差距最终是否会被填补。