1. 引言
在之前的Practical results on Lattice onchain verifiers文章中，讨论了以太坊迈向后量子未来所面临的关键问题。本文将重点介绍 ZKNOX 在过去几周中实现后量子签名方案------FALCON 和 DILITHIUM------方面的工作。
在基于格的签名方案中，DILITHIUM 和 FALCON 已被 NIST 选定为数字签名算法的替代方案。FALCON 相比 DILITHIUM 更快且更紧凑，因此更适用于链上应用。然而，从实现角度来看，FALCON 的签名算法更加复杂，而 DILITHIUM 的签名算法更适合硬件实现，预计在不久的将来可以在安全元件（secure element）中落地。这些因素促使ZKNOX团队同时实现了 DILITHIUM。
2. 面向 EVM 的版本
2.1 性能分析
在完整实现之前，ZKNOX团队对这两种算法的关键组件进行了初步评估。此前的Practical results on Lattice onchain verifiers文章 已经介绍了核心操作------多项式乘法------以及如何利用数论变换（NTT，Number Theoretic Transform）进行优化。ZKNOX 成功将之前一个 Solidity 实现的 NTT 从 2000 万 gas 降低到 150 万 gas。在采用优化后的 NTT 后，验证的剩余成本主要来自哈希计算。
FALCON 使用 SHAKE 作为其哈希函数，但由于 EVM 原生不支持 SHAKE，因此必须进行模拟实现。即便使用优化后的 Yul 实现，SHAKE 核心置换（permutation）仍然需要约 100 万 gas，从而使完整 FALCON 签名的总成本达到约 1000 万 gas。为了解决这一问题，ZKNOX团队提出了在安全性等价的前提下更节省 gas 的替代方案：ETHFALCON 和 ETHDILITHIUM。
2.2 伪随机数生成器
在密码学中，具有可配置输出长度的哈希函数称为 XOF（可扩展输出函数，Extendable Output Function）。FALCON 规范使用 SHAKE 作为 XOF，以生成无偏且无碰撞的有效多项式。然而，SHAKE 并未作为 EVM 的原生操作码提供（参见An Ethereum Virtual Machine Opcodes Interactive Reference列表），因此其实现成本较高（每次从 nonce 转换为多项式需超过 400 万 gas）。一些方案尝试以非标准方式用 Keccak 替代 SHAKE，通过内部状态更新派生输出。在与 FALCON 作者之一 Zhenfei Zhang 讨论后，ZKNOX团队决定采用一种标准化的计数器模式生成方法来替代该方案。
2.3 编码
FALCON 的原始签名会经过一个压缩函数 ，可以将其大小减少约 30%。在常规环境中，这一计算开销可以忽略，但在 Solidity 中，这类位级操作较为复杂，使得链上压缩效率较低。因此，Tetration 选择直接使用原始签名作为输入。
在标准 FALCON 中，签名编码是唯一的，这是通过对系数符号进行编码来保证的。然而，Tetration 的方法重新引入了*签名可变性（malleability）*问题，攻击者可以将一个有效签名替换为另一个有效签名（类似于 Mt. Gox 事件中 ECDSA 的漏洞）。为缓解该问题，ZKNOX 提议固定第一个系数的符号，从而保证编码唯一性。
2.4 恢复版本
FALCON 相比 DILITHIUM 的一个关键优势在于，它可以支持类似 ECDSA 的基于恢复的验证模型 。ZKNOX 提出了一种 FALCON 的恢复版本，通过修改哈希函数规范，使其使用公钥的 NTT 表示。这使得验证过程中只需要执行正向 NTT 变换，从而避免了逆 NTT 的计算。
3. 持续进行的工作
3.1 面向 PQZK 的未来
以太坊的长期愿景之一是实现 零知识（ZK）终局（endgame） 。在非原生域上运行的 ZK 电路会引入额外的证明成本。为了解决这一问题，ZKNOX团队提出了基于 M31 和 BabyBear 域的 ZK 友好替代方案 ，并针对 基于 STARK 的证明系统 （如 STWO 和 RISC0）进行了优化。ZKNOX的目标是为私密支付场景提供一条从 BabyJubJub、JubJub 和 Bandersnatch 曲线迁移到 ZKFALON 和 ZKDILITHIUM 的路径。关于更换域带来的安全性影响，将在后续文章中讨论。
3.2 使用 EVMMAX 降低 gas 消耗
在撰写本文时，Ipsilon 正在尝试使用 EVMMAX 预编译（EIP-6690）来进一步加速 NTT 运算。初步分析表明，可能实现约 4 倍的加速（降低至约 50 万 gas）。不过该方案仍处于实验阶段，因为 EVMMAX 尚未正式规划。
4. 结果
上述修改在降低验证成本的同时，也使公钥和签名尺寸相较于 NIST 标准版本有所增加：
| 方案 | 公钥 | 签名 | 说明 |
|---|---|---|---|
| FALCON | 897 B | 666 B | 来自 NIST 标准 |
| ETHFALCON | 1,024 B | 1,064 B | 解压与 NTT 增加了尺寸，但降低了验证成本 |
| DILITHIUM | 1,312 B | 2,420 B | 来自 NIST 标准 |
| ETHDILITHIUM | 20,512 B | 9,248 B | 展开与 NTT 增加了尺寸，但降低了验证成本 |
下表总结了实现结果。虽然 ETHFALCON 已经过优化，但在 gas 优化方面仍有提升空间：
| 函数 | 描述 | Gas 成本 | 测试状态 |
|---|---|---|---|
| ZKNOX_ethfalcon.sol | 面向 EVM 的 FALCON | 1.9M | ✅ |
| ZKNOX_ethdilithium.sol | 面向 EVM 的 DILITHIUM | 8.8M | ✅ |
| ZKNOX_falcon.sol | 符合 NIST 标准的 FALCON | 7M | ✅ |
| ZKNOX_dilithium.sol | 符合 NIST 标准的 DILITHIUM | 13M | ✅ |
| ZKNOX_zkdilithium.sol | ZK 友好的 DILITHIUM | N/A | WIP |
| ZKNOX_zkfalon.sol | ZK 友好的 FALCON | N/A | WIP |
4.1 FALCON：链上优选，签名端噩梦
正如预期，FALCON 在验证方面是最高效 的方案，同时具有最小带宽开销。然而，在 Python 中实现其签名器的过程中，也暴露了硬件实现将面临的挑战：内存消耗较高，并且高斯采样依赖复杂的浮点运算。
与硬件厂商的讨论表明，由于这些实现难度，业界对 DILITHIUM 表现出更强的偏好。不过，在以太坊链上约束条件下，FALCON 仍然是验证阶段的首选方案。
4.2 DILITHIUM：效率较低，但具备关键优势
在链上验证方面，DILITHIUM 相比 FALCON 更慢，占用空间约为其 4 倍，gas 成本也更高。但它具备以下优势：
- 签名实现更简单： 安全元件厂商更容易实现 DILITHIUM，使其更有可能实现广泛部署。
- ZK 友好性： 经过适配的 DILITHIUM 在 ZK 场景下比 FALCON 更高效。
- MPC 兼容性： DILITHIUM 更适合多方计算（MPC），有助于在基于 TSS 的钱包（如 Unruggable Wallets）中更容易落地。
| 特性 | FALCON ✅/❌ | DILITHIUM ✅/❌ |
|---|---|---|
| Gas 效率 | ✅ | ❌ |
| 带宽 | ✅ | ❌ |
| 签名端复杂度 | ❌ | ✅ |
| ZK 适配性 | ❌ | ✅ |
| MPC 友好性 | ❌ | ✅ |
4.3 2 分钟测试
在不到 2 分钟内完成：生成密钥、签名，并在链上使用 FALCON 进行验证。
- 进入 ZKNOX FALCON 仓库
- 执行
make install，然后执行make test - 使用以下命令生成密钥、对消息签名，并通过链上合约进行验证
bash
# 使用 'falcon' 或 'ethfalcon' 生成公私钥
./sign_cli.py genkeys --version='falcon'
# 为消息 "This is a demo" 生成签名
./sign_cli.py sign --privkey='private_key.pem' --data=546869732069732061207472616e73616374696f6e
# 使用下方指定的合约地址在链上验证签名（确保 --version 与地址匹配）
./sign_cli.py verifyonchain \
--pubkey='public_key.pem' \
--data=546869732069732061207472616e73616374696f6e \
--signature='sig' \
--contractaddress='0xD088Ede58BD1736477d66d114D842bDE279A41Fa' \
--rpc='https://sepolia.optimism.io'该合约地址对应于在 Solidity 中实现 FALCON 的合约。运行后应输出：
text
0x0000000000000000000000000000000000000000000000000000000000000001这样就完成了第一次链上后量子签名验证。
5. 结论
得益于 ZKNOX 的工作，链上后量子验证已经具备实验可行性。尽管在 L2 上 gas 成本是可以接受的，但对于大多数 L1 场景来说仍然过高（除非用于验证高价值交易）。团队将继续推进 ZK 版本的开发，并计划开始嵌入式实现。
参考资料
1\] ZKNOX团队2025年3月21日博客 [ETHDILITHIUM and ETHFALCON for Ethereum PQ Era](https://zknox.eth.limo/posts/2025/03/21/ETHFALCON.html)