带提示的P-384签名：让Nitro链上验证更便宜可行

liumuhui 3小时前阅读数 1 #区块链

TL;DR： 对 base/nitro-validator 库的重新设计，使 Fusaka 升级后的 EVM Nitro Enclave 证明在链上再次可行，而且比之前更便宜。以太坊的 Fusaka 升级对 MODEXP 重新定价（EIP-7883），并将每笔交易的上限设为 1670 万 Gas（EIP-7825），这使得原来的 base/nitro-validator 运行成本过高。我们通过带提示的 P-384 签名验证恢复了它：昂贵的模逆运算在链下计算，并以 calldata 形式传入，合约只需对它们进行检查。这大幅削减了 Gas，同时没有增加对链下提示生成器的任何信任。

为什么要在链上验证 Nitro 证明？

越来越多的应用正在将计算移到链下。当这些计算需要可信时，在可信执行环境（TEE）——例如 AWS Nitro——中运行通常是最干净的选择。TEE 在隔离环境中运行代码，并生成关于哪个代码运行了以及在什么环境中运行的签名声明，该声明与输出、nonce 或 enclave 公钥等应用数据绑定。

在链上验证这一声明，才是它的强大之处。合约不必信任声称“我运行了正确的代码”的运营者，而是可以验证一份将输出与特定 enclave 镜像加密绑定的证明。这可以解锁以下模式：

外部验证 — 接受来自经批准的链下验证器的声明、证明或状态承诺。
自定义执行引擎 — 在 EVM 之外运行专门逻辑，并验证结果来自经批准的 enclave 代码。
私有计算 — 在 enclave 内运行拍卖、匹配、评分或策略检查，只在链上暴露签名结果。
预言机和风险流水线 — 接受在可度量的数据处理环境中计算出的更新。
Enclave 背书的签名者 — 仅在验证了生成这些密钥的 Nitro 证明之后才授权密钥。
跨链桥、结算和 Keeper — 基于经批准的 enclave 代码的签名来门控特权操作。

最大的问题是 Nitro 证明使用的是 P-384 曲线签名，而遗憾的是，Base 和以太坊 L1 所依赖的最新 EVM 并不支持将该曲线作为预编译。因此，P-384 签名验证目前在链上极其昂贵，甚至到了不可行的地步。

Fusaka 改变了什么

在 Fusaka 之前，链上 Nitro 验证成本高昂但可行。一次 P-384 签名检查大约花费 790 万 Gas。一次完整的冷证明需要五次签名检查、CBOR/COSE 解析、X.509 处理和证书缓存，总计约 5300 万 Gas，分散在多笔交易中。

Fusaka 从两个方面改变了计算方式：

EIP-7883 上调了大额 MODEXP 调用的定价。
EIP-7825 将每笔交易的上限设为 1670 万 Gas。

在新的定价方案下，一次无提示的 P-384 验证跃升至 约 5060 万 Gas——仅此一项就已超过单笔交易上限。一次完整证明需要五次这样的验证：总计 约 2.67 亿 Gas。原来的库根本无法再运行了。

所以，我们改变了工作的单位。

昂贵之处：570 次巨大的幂运算

为什么 Fusaka 之后一次 P-384 验证要花费约 5060 万 Gas？由于没有预编译，ECDSA 验证需要在链上进行椭圆曲线运算。验证者必须重建曲线上的一个点，并检查其 x 坐标是否与签名匹配。

该实现使用仿射坐标，点加法和点倍乘通过有限域除法计算斜率。除法需要计算标量域的逆元：

a / b mod m = a · b⁻¹ mod m

而计算逆元需要使用费马小定理，以 384 位的指数（约为 10¹¹⁵ 量级的数）进行幂运算：

b⁻¹ = b^(m − 2) mod m

一次签名检查大约需要重复 570 次这样的运算！

对于 P-384，m 要么是域素数 p，要么是群阶 n——两者都是约 384 位的素数，也都约为 10¹¹⁵ 量级。每次签名中约 570 次的幂运算，正是 Gas 消耗的大头。

但求逆运算有一个有用的不对称性：

计算逆元是昂贵的。
检查逆元是便宜的。

如果有人声称 inv 是 b 的逆元，合约可以通过一次乘法和一次相等性检查来确认：

b · inv == 1 mod m

这就是提示（hints）背后的全部核心思想。

我们的解决方案：经检查的提示

我们不在链上计算每个逆元，而是在链下算好，再以 calldata 中的提示形式传入。对于每一次除法，验证者都会读取下一个 48 字节的提示，并在使用前对其进行检查：

需要  a / b mod m
  →  读取下一个提示 inv
  →  校验 b · inv == 1 mod m
  →  使用 a · inv mod m

提示永远不会被信任。错误的提示会回滚。被截断的提示流会回滚。包含多余未使用提示的流会回滚。调用者最多浪费自己的 Gas，却无法让验证者接受它原本会拒绝的签名。

这是安全的，因为相关的 P-384 模数——域素数 p 和群阶 n——都是素数。在素域中，每个非零值都恰好有一个逆元，因此任何通过 b · inv == 1 mod m 检查的提示就是合约本会通过 b^(m − 2) 计算出的同一个逆元。提示改变的是验证者获取逆元的方式，哪些签名有效则不受影响。

文章配图

该系统由三个合约组成，每个合约各司其职：

P384Verifier 负责 ECDSA-P-384 的数学运算和提示检查。另外两个合约通过外部调用来调用它，以保持在 EIP-170 大小限制之下。
CertManager 对照固定的 AWS Nitro 根证书验证 X.509 证书，通过 P384Verifier 验证非根签名，缓存已验证的证书元数据，并强制执行撤销。
NitroValidator 解析 COSE/CBOR 证明文档，通过 CertManager 遍历证书包，并对照缓存的叶密钥验证最终的证明签名。

无提示版入口会故意回滚，因此 Gas 消耗情况十分明确：生产环境的调用者使用 verifyCACertWithHints、verifyClientCertWithHints 和 validateAttestationWithHints，不会意外回退到昂贵的路径。

冷验证和热验证

一份 Nitro 证明包含一个证书包和一份叶证书。根 CA 固定在 CertManager 中，因此永远不需要链上验证。冷路径验证并缓存其余部分，每笔交易一个签名：

区域 CA
可用区 CA
签发者 / 实例 CA
叶证书
COSE 证明文档签名

这是跨五笔交易的五次 P-384 检查。一旦证书链和叶证书被缓存，来自同一叶证书的后续证明就走热路径：单笔交易验证文档签名，并确认缓存的证书存在、未过期、链正确且未被撤销。

实测 Gas

在 Base 上，完整的冷序列可以在五笔交易内完成，每笔都轻松低于 16,777,216 Gas 上限：


交易	操作	提示字节	Gas 消耗
1	缓存区域 CA	27,456	6,825,140
2	缓存可用区 CA	27,408	7,053,669
3	缓存签发者 / 实例 CA	27,408	6,813,103
4	缓存叶证书	27,504	6,825,004
5	验证证明文档	27,312	13,775,541

逆元作为提示通过 calldata 传入。每个逆元 48 字节，一次签名验证会根据签名数据消耗 569–573 个逆元，因此每个提示流约 27 KB。上面这些收据中的数字已包含 Calldata 成本。

安全模型

关键性质：提示只是公开的提议，而非受信任的见证者。

合约会在使用前检查每个逆元，因此错误的提示无法影响椭圆曲线运算——最多只会导致回滚。验证者还会强制执行提示消耗的精确性，因此调用者既不能遗漏必需的逆元，也不能夹带未使用的数据。

提示机制本身是无信任的，但一份证明的有效性仍然依赖于对 AWS Nitro 硬件的整体信任。

应用策略由应用自行决定。NitroValidator 证明某份证明由有效的 Nitro 证书链签名，并返回解析后的字段，消费应用自行决定信任哪些 PCR、模块 ID、nonce、时间戳和公钥。

公开构建

该实现已在 base/nitro-validator 开源。该仓库包括：

带提示的 P384Verifier、CertManager 和 NitroValidator；
一个零依赖的 Node.js 参考提示生成器；
Foundry 测试，涵盖有效证明、格式错误的提示、过期证书、撤销、解析器边界情况，以及链下/链上提示流等价性；以及
一个用于冷路径和热路径的 Base Sepolia 演示。

该库已由 Cantina 独立审计，你可以阅读完整报告此处。

请将附带的 JavaScript 视为参考实现，而不是后端依赖——合约接口就是普通的 calldata，因此你可以将提示生成器移植到你已运行的任何技术栈上。

下一步计划

Base 自身目前在生产环境中使用零知识（ZK）证明来验证 Nitro 证明，因为那是 Fusaka 升级后链上验证 Nitro 证明唯一已知的实用方式。这种带提示的 P-384 方法让 Nitro 证明在 Base 上无需新的预编译或 ZK 证明服务即可落地，我们计划在未来将这种方法用于 Base 规范跨链桥的证明系统，取代在链上验证 Nitro 证明时对 ZKP 的需求。

这个库也并非 Base 专属。任何需要在 Fusaka 升级后的链（例如以太坊主网和许多其他链）上运行的 EVM 用例，都能从中受益。任何想要信任 Nitro enclave 的 EVM 应用都可以使用相同的模式：验证 AWS 证书链、验证证明签名、检查返回的度量值，并将结果绑定到自己的策略中。