IOG 开发用于在 Cardano 上验证 RISC Zero 和 SP1 证明的 ZK 包装器

Input Output Research 正在开发一个零知识包装器，旨在将 Cardano 应用与 RISC Zero、SP1 及其他在 BN254 椭圆曲线上生成 Groth16 证明的系统连接起来。

这一原型解决了一个密码学兼容性缺口，该缺口目前阻碍了 Cardano 智能合约高效验证许多由成熟 ZK 工具生成的证明。该工作仍处于技术可行性阶段，部分组件正为最早在 2027 年初进行潜在工程化落地做准备。

Groth16 包装器将 BN254 证明转换为适配 Cardano

区块链零知识基础设施中有很大一部分使用基于 BN254 的 Groth16 证明。由于 Ethereum 支持该曲线，开发者框架、应用与 ZK 虚拟机也被推动采用同一密码学标准。

相比之下，Cardano 支持 BLS12-381 运算。尽管 Groth16 可用于这两种曲线，但在缺乏新的协议功能或不在 Plutus 智能合约中进行高开销算术的情况下，基于 BN254 生成的证明无法在 Cardano 上得到高效验证。

该原型在两种环境之间引入了递归包装层。它接收一个基于 BN254 的有效 Groth16 证明，并生成一个基于 BLS12-381 的第二层证明，使 Cardano 能以网络已支持的密码学运算来验证结果。

该转换不要求用户信任执行方。外层证明会确认针对特定验证密钥与公开输入确有一个有效的原始证明。Cardano 在不重复原始计算的情况下即可检验这一断言。

当前工具链支持 RISC Zero 与 SP1 这两种零知识虚拟机，它们允许开发者运行通用程序，并生成紧凑的证明以表明这些程序被正确执行。

面向各来源的插件将其输出转换为通用格式。随后，包装引擎在 BLS12-381 上重述该声明，并生成可集成进 Cardano 应用的验证器代码。

Input Output Research 以 Groth16 和 Plonk 作为外层证明系统进行了测试。Groth16 完成包装过程更快，且生成的证明更小，但需要为包装电路进行可信设置。Plonk 避免了电路特定的设置，但需要显著更长的链下证明时间。

两种方案都能生成符合 Cardano 链上验证预算的最终证明。因此，主要权衡在于证明生成与设置需求，而非通过 Plutus 进行的最终验证。

RISC Zero 与 SP1 或可支持跨链验证

与 RISC Zero 和 SP1 的兼容性将使 Cardano 开发者能够使用现有 ZK 程序与库，而无需为 Cardano 的密码学环境重构每一项计算。

研究中包含的一个示例是证明某个 Ethereum 账户的 ERC-20 余额。RISC Zero 执行所需的 Ethereum 逻辑，从已提交的网络状态中提取余额并生成证明。随后，包装器将该输出转换为 Cardano 验证器可验证的形式。

相同的架构还可用于确认选定的 Ethereum 或 Bitcoin 状态、验证外部程序的执行，或为发生在 Cardano 之外的计算提供密码学证据。

研讨会还讨论了基于 SP1 的 Helios（一个 Ethereum 轻客户端）的潜在实现。此类系统可在零知识环境中证明 Ethereum 共识的执行，并提交一个紧凑结果供 Cardano 应用验证。

这些能力可支持依赖其他区块链可靠信息的轻客户端、桥、rollup 与跨链协议。该包装器本身不转移资产，也不作为桥运行。它提供一层可被其他应用集成进其自身架构的验证组件。

这一方法也有助于减少重复的开发工作。团队无需将每项计算都实现为 Cardano 原生的 ZK 电路，而是可以使用 RISC Zero 或 SP1 生态的受支持软件，并在链上验证前转换最终证明。

该工具链仍是供实验用的原型。其示例涵盖证明生成、递归包装以及相应 Cardano 验证器的创建，而要投入生产还需要工程化工作、安全审查，以及对外层证明系统的最终决策。

Plonky3 与 Halo2 明确剩余的验证工作

研讨会还展示了通过 Cardano 智能合约验证 Plonky3 证明的可行性研究。

Plonky3 是一个面向 STARK 系统的模块化证明框架。它主要依赖哈希函数与有限域运算，而非许多 SNARK 系统使用的椭圆曲线运算，这使其与 Cardano 的后量子研究密切相关。

一个拟议应用是后量子签名聚合。这些签名单个可能需要数十千字节，而一个 ZK 证明可以将多份签名合并为单个结果，从而减少必须在链上存储或验证的数据量。

另一个潜在用例涉及在未来从当前椭圆曲线签名迁移之后的历史 UTXO。持有人有望在不公开种子的情况下，证明其知晓与某个地址关联的种子。

可行性研究发现，直接在链上验证 Plonky3 仍超出 Cardano 的单笔交易限制。一个优化的测试证明大小约为 186 千字节，约需 2.2 亿内存单位与 750 亿 CPU 单位。

由于各个查询子证明可以分别检查，研究人员估计整个过程可被划分到约 23 笔交易中。还讨论了作为替代方案的 Hydra 执行与乐观式验证模型，后者仅在收到质询后才检查完整证明。

另一项 Halo2 成本估算器针对开发流程的早期阶段。该工具可计算预期的证明大小、验证密钥大小，以及在 Cardano 上验证拟议电路所需的密码学运算。

开发者可在完成完整应用之前，对电路进行建模或测试诸如 SHA-256 等组件。通过这些估算，团队可以识别高成本组件，并在构建证明器与 Cardano 验证器之前调整设计。

目前，Groth16 包装器是从研究计划走向开发者实际使用的最直接途径。若其进入工程化实施阶段，Cardano 应用即可在无需等待各外部系统引入原生 BLS12-381 支持的情况下，验证成熟 zkVM 生态的输出。Plonky3 则需要不同的架构，将验证划分到多笔交易中、移入 Hydra，或通过基于质询的设计来激活。