Philip DiSarro 报告 Aiken 的 CIP-113 实现中存在两处严重缺陷

Philip DiSarro，Anastasia Labs 的创始人兼 CEO、CIP-143 的作者，于 7 月 24 日表示，他在审查 Cardano 的 CIP-113 可编程代币框架的 Aiken 实现时发现了两处严重漏洞。在同一条线程中，他发布了更新的基准测试，对比了 Aiken 代码库与由 DiSarro 和 Input Output 团队开发的原始 Plutarch 实现。该披露发布时，CIP-113 仍处于 Last Check 阶段，其实现仍在进行安全审查。

在 CIP-113 基准测试中 Plutarch 的成本更低

发布的基准文件在 Cardano 的最大交易预算下比较了两种实现，即 100 亿 CPU 单位和 1400 万内存单位。Aiken 与 Plutarch 最终都会编译为 Cardano 节点执行的 Untyped Plutus Core。

在五个重点场景中，Plutarch 的总 CPU 和内存消耗均更低。

在标准转账测试中，Aiken 的 CPU 使用量是 Plutarch 的 1.19 倍，内存使用量是 1.17 倍。在所展示的场景中差异最大的是一个将扣押操作、外部脚本与 50 个公钥输入相结合的测试，其中 Aiken 的 CPU 消耗是 3.23 倍，内存消耗是 2.36 倍。

在 16 次 swap $NIGHT DEX 测试中，两种实现均未超出 Cardano 的交易限制。Plutarch 使用了可用 CPU 预算的 6.66% 和内存预算的 11.68%，Aiken 则分别为 7.59% 与 15.25%。

DiSarro 的发布还包括线性推算，用于估计一笔交易可容纳的元素数量。估算显示，Plutarch 可容纳 658 个输入而 Aiken 为 162 个，472 个输出而 Aiken 为 334 个，36,489 个代币而 Aiken 为 1,661 个，527 个策略而 Aiken 为 160 个。这些数字是基于测试得到的执行成本推算出的脚本容量，而非主网实际吞吐量的测量值。

在已编译脚本的对比中，七类中的六类 Plutarch 脚本更小。directoryNodeSpending 脚本在 Plutarch 中为 331 字节，在 Aiken 中为 1,698 字节。唯一的例外是 programmableLogicGlobal，Aiken 生成的脚本为 3,157 字节，Plutarch 为 3,437 字节。

CIP-113 为 Cardano 原生资产引入可编程规则

CIP-113 提出一种框架，在无需更改账本或硬分叉的情况下，为 Cardano 原生资产添加可编程的验证规则。发行方可以定义在代币转账、铸造与销毁过程中执行的条件。

这些规则可以包括允许列表、拒绝列表、转账限制、时间锁以及可选的冻结或扣押功能。该框架面向需要对所有权与流转进行管控的稳定币、代币化证券与现实世界资产。

按照拟议架构，可编程代币将托管在共享的智能合约地址上，而所有权通过质押凭证来表示。链上注册表将每个代币策略与其转移规则、发行逻辑以及任何授权的第三方控制关联起来。

钱包需要解析质押凭证以正确显示余额。去中心化交易所、索引器、区块浏览器及其他应用也需要支持这一额外的验证流程，用户才能通过现有的 Cardano 基础设施与可编程代币交互。

Aiken 与 Plutarch 提供了不同的开发路径，但都会编译为相同的链上代码格式。Cardano 的开发者文档将 Aiken 描述为易上手的起点，内置测试并具备专用语法。Plutarch 是基于 Haskell 的嵌入式语言，可让开发者对生成代码与执行成本进行更细致的控制。

DiSarro 撰写了 CIP-143, Interoperable Programmable Tokens，并与 Input Output 团队合作完成了其最初的 Plutarch 参考实现。Cardano Foundation 代码库称，当前的 Aiken 验证器是从该实现迁移而来，并为更广泛的 CIP-113 框架进行了适配。

他直接参与了最初的架构与代码库，这使得此次新的基准对比置于该项目的发展脉络之中。CIP-143 现已在并入候选 CIP-113 后被标注为非活动状态，而后者仍处于 CIP 编辑的 Last Check 审查阶段。

两项已报告的漏洞尚待技术披露

DiSarro 表示，他对 Aiken 实现的审查发现了两处在审计过程中被遗漏的严重漏洞。他的线程未说明受影响的代码、可能的攻击路径、潜在影响或修复状态。

该代码库已包含初次审计的公开发现，其中包括两项已关闭且标记为严重的问题。第 56 号问题描述了一种路径，新铸造代币可能在第三方操作期间逃离可编程托管。第 64 号问题则讨论了通过相同的管理功能导致无关 UTxO 受到污染的可能性。

这些发现是在初次审计期间报告的，在没有进一步技术披露之前，不能将其认定为 DiSarro 之后报告的两项漏洞。

在 CIP-113 评审讨论中也提出了安全担忧。一位贡献者于 7 月 20 日表示，审计遗漏了多处高严重性漏洞，且某些拟议的可用性变更引入了额外的安全问题。在随后的 CIP 评审中，与会者同意下一步应在提案仍处于 Last Check 阶段时开展更全面的审计。

Cardano Foundation 的代码库称，初次审计及后续复审中的发现已在主分支完成修复。不过，最终审计报告尚未发布。在报告、更加广泛的测试与进一步专家评审完成之前，该代码库将当前实现标注为不适合在生产环境中用于真实资产。

在 CIP-113 的实现推进到真实资产部署之前，仍有三项具体成果待完成：发布最终审计报告，披露并修复 DiSarro 报告的两项漏洞，以及完成在 CIP 流程中提出的更广泛安全审查。这些成果将决定在提案合并之前纳入哪些代码与规范变更，并据此评估该实现能否进入生产使用。