1. 引言
随着 Willow（低成本量子计算能力）的发布，量子计算对以太坊的威胁似乎正在加速显现。Asanso 和 PMiller 的文章总结了这一风险及可能的应对方案。这些方案包括基于格的签名（如 Dilithium 和 FALCON，其中 FALCON 更适合链上约束）、STARK 以及全同态加密（FHE）。密码学研究界普遍认为，格密码将成为未来非对称协议的基础，而 STARK 已经在 ZKEVM 实现竞赛中胜出（如 Scroll、Starknet 和 ZKsync 所采用）。
这些协议的共同点在于，都需要在素数域上进行高效的多项式乘法，并依赖 NTT（即一种适用于素数域的特殊 FFT）。过去，优化重点主要集中在椭圆曲线域上的 Montgomery 乘法器（无论是硬件还是软件）；而在后量子时代，NTT 的优化将成为实现高性能 PQ 系统的关键。
随着后量子（PQ，post-quantum）密码时代的临近，确保像以太坊这样的区块链系统能够高效验证 PQ 签名变得至关重要。许多 PQ 方案的核心操作之一是 数论变换（NTT, Number Theoretic Transform） ，它在加速密码计算中发挥着基础性作用。在任何密码库中，快速乘法器（fast multiplier） 都是最底层的关键操作，其是最底层的函数，通常通过汇编或密码加速器进行优化。传统密码加速器依赖于在大域（256 到 512 位）上的快速乘法，通常以 Montgomery 乘法器为核心操作；而格密码则在较小域上的多项式上进行运算，因此需要对硬件架构进行更新。
ZKNOX团队一直在探索如何使以太坊上的PQ 签名验证更加节省 gas。ZKNOX团队最新的工作重点是用 Yul 实现 NTT，对其性能进行基准测试，并提出应对以太坊 PQ 挑战的长期解决方案。
2. 在 Yul 中优化 NTT 以实现高效的 PQ 验证
NTT 是许多基于格的 PQ 签名方案中的关键组件，包括 FALCON 和 DILITHIUM，它们是 NIST PQC 竞赛中的两个主要候选方案。为了在以太坊上实现高效验证，ZKNOX团队使用 Yul（以太坊的低级中间语言）实现了 NTT，从而能够更精细地控制 gas 优化。
本基准测试显示了显著的性能提升：
- 完整的 FALCON 签名验证现在仅消耗约 3.6M gas------相比之前的实现大幅降低
- 对于 DILITHIUM 以及其他依赖 NTT 的 PQ 方案，也观察到了类似的性能提升
尽管这些优化使实验更加高效，并显著提升了性能，但其成本在长期来看仍然过高，不足以支持以太坊 PQ 的规模化应用。
3. 将 NTT 作为以太坊预编译的必要性
尽管ZKNOX团队基于 Yul 的实现已经显著降低了 gas 成本，但 PQ 签名验证的开销仍然是实际应用中的主要瓶颈。因此，ZKNOX主张将 NTT 纳入以太坊预编译（precompile） 。该提案目前已以预草案形式提交为 EIP-7885: Precompile for NTT operations -- Proposal to add a precompiled contract that performs number theoretical transformation (NTT) and inverse (InvNTT)。
3.1 为何需要预编译？
预编译是一种在协议层实现的、类似智能合约的函数，相比在 Solidity 或 Yul 中执行相同逻辑，具有更低的 gas 成本。将 NTT 作为预编译引入可以：
- 大幅降低 PQ 签名验证的 gas 成本
- 支持多种 PQ 方案，而不是局限于单一算法
- 增强以太坊的密码灵活性（crypto-agility），从而在新标准出现时能够平滑过渡
3.2 迈向具备密码灵活性的以太坊
与其将以太坊绑定在某一个 PQ 方案上，引入 NTT 预编译能够为更广泛的 PQ 采用奠定基础。这种方式确保以太坊在密码学不断发展的过程中保持灵活性与安全性。
通过让 NTT 高效且易于使用，正在迈向一个可扩展、抗量子的以太坊------在为后量子时代做好准备的同时，不牺牲可用性。
3.3 降低 STARK 结算成本
STARK 是一种用于扩展以太坊的零知识技术，被 ZKEVM Layer2（如 Starknet、Succinct）广泛使用。在 STARK 的结算过程中同样需要使用 NTT。Anatomy of a STARK, Part 6: Speeding Things Up博客中描述了 NTT 在构建高效 STARK 验证器中的作用。除了 PQ 密码学之外，EIP-7885 还能够降低 STARK 结算成本。
4. 结论（Conclusion）
后量子安全并非遥远的担忧------它是一个必须在当下解决的紧迫挑战。ZKNOX团队在 Yul 中对 NTT 的优化展示了实现低 gas PQ 验证的潜力，但从长远来看，解决方案需要对以太坊协议进行修改。
ZKNOX团队认为，引入 NTT 预编译 是迈向后量子密码灵活性（PQ crypto-agility）以及ZK 转型 的合理下一步。欢迎以太坊社区、研究人员和开发者参与NTT as PostQuantum and Starks settlements helper precompile讨论，共同推进这一关键升级。
5. NTT-EIP 附加信息
相关代码实现见：
ZKNOX团队提供了一个优化版本的 FALCON，实现基于优化后的 NTT。该实现不仅可以加速 STARK 验证，还可应用于其他基于格的原语（如 Dilithium、Kyber 等）。尽管将 FALCON 作为渐进式预编译（progressive precompile）是可行的，但其成本仍然较高。如果通过客户端实现（如在 Geth 分支中集成 NTT-EIP），以太坊有望成为一个同时对 PQ 和 ZK 友好的链。该研究得到以太坊基金会的支持。
该代码库中包含 NTT 变换的 EIP 提案，以及对应的 Python 参考实现和 Solidity 实现。
以太坊早期选择了单一方案（secp256k1）作为签名算法。随后，随着专用硬件和不同证明系统的发展，各种 EIP 被提出以支持不同曲线，形成了"多曲线生态"。也曾尝试通过更高层抽象的 EIP 一次性支持多种方案，如 EWASM、SIMD、EVMMAX 或 RIP7696（按通用性和复杂度递减排序）。
与直接选择某个具体签名方案相比，将 NTT 作为 EIP 引入，可以为所有依赖它的方案带来大幅 gas 优化：
- 优点（pros） ：
- 对所有相关协议带来显著性能提升
- 提供更高的密码灵活性（crypto-agility）
- 缺点（cons） ：
- 需要在具体实现中进行封装
- 相比针对单一方案的专用 EIP，不是最优解
- 不是无状态（stateless）的
5.1 NTT 概述
NTT 作用于一组数值序列（通常是多项式系数），在模运算体系中将其映射到另一个域，使卷积运算（如多项式乘法）变得更简单高效，类似 FFT 在信号处理中的作用。不同于 FFT 在复数域中使用单位根，NTT 在有限域或环中使用单位根。
NTT 基于离散傅里叶变换（DFT），定义为：
X [ k ] = ∑ j = 0 N − 1 x [ j ] ⋅ ω j ⋅ k m o d q X[k] = \sum_{j=0}^{N-1} x[j] \cdot \omega^{j \cdot k} \mod q X[k]=j=0∑N−1x[j]⋅ωj⋅kmodq
其中：
- x [ j ] x[j] x[j]：长度为 N N N 的输入序列
- X [ k ] X[k] X[k]：变换后的序列
- q q q：素数模数
- ω \omega ω：模 q q q 下的 N N N 次原始单位根，满足：
ω N ≡ 1 m o d q 且 ω k ≢ 1 m o d q ∀ 0 < k < N \omega^N \equiv 1 \mod q \quad \text{且} \quad \omega^k \not\equiv 1 \mod q \;\; \forall \; 0 < k < N ωN≡1modq且ωk≡1modq∀0<k<N
NTT 的计算采用类似 Cooley--Tukey 算法的方法，时间复杂度为：
O ( N log N ) O(N \log N) O(NlogN)
NTT 算法通过模运算将序列 ( x [ j ] ) (x[j]) (x[j]) 转换为 ( X [ k ] ) (X[k]) (X[k])，并且是可逆的，可以通过逆 NTT（INTT）恢复原始序列。逆变换过程类似，但需要除以 N N N（模 q q q 意义下），并使用 ω − 1 \omega^{-1} ω−1（ ω \omega ω 的模逆）。
以下算法摘自 2016年论文 Speeding up the Number Theoretic Transform for Faster Ideal Lattice-Based Cryptography，描述了在如下环中计算 NTT 的方法：
R q = Z q [ X ] / ( X n + 1 ) R_q = \mathbb{Z}_q[X] / (X^n + 1) Rq=Zq[X]/(Xn+1)
（即负循环卷积，Negative Wrap Convolution）
逆 NTT（INTT）通过如下算法计算：
5.2 基准测试
5.2.1 Python
| 域（Field） | n n n | 递归 NTT（Tetration） | 迭代 NTT（ZKNOX） | 迭代 InvNTT（ZKNOX） |
|---|---|---|---|---|
| Falcon | 512 | 761 μs | 528 μs | 561 μs |
| Falcon | 1024 | 1642 μs | 1076 μs | 1199 μs |
| Dilithium | 128 | 165 μs | 114 μs | 113 μs |
| Dilithium | 256 | 371 μs | 258 μs | 260 μs |
| BabyBear | 256 | 531 μs | 389 μs | 404 μs |
递归形式的逆 NTT（InvNTT）由于需要进行求逆运算，其开销非常高。对于 Falcon，由于所使用的域较小，可以预计算域求逆，但其成本仍然高于迭代版本的逆 NTT。
这里的域运算尚未进行优化。在 BabyBear 的情况下，这一点尤为明显，因此该对比结果的参考意义有限。
5.2.2 Solidity
| 函数 | 描述 | gas 成本 | 测试状态 |
|---|---|---|---|
| NTT recursive | 来自Tetration falcon-solidity 的原始gas开销 | 6.9M | OK |
| InvNTT recursive | 来自Tetration falcon-solidity 的原始gas开销 | 7.8M | OK |
| Full Falcon verification | 来自Tetration falcon-solidity 的原始gas开销 | 24M | OK |
| NTT iterative | ZKNOX 实现 | 4M | OK |
| InvNTT iterative | ZKNOX 实现 | 4.2M | OK |
| Full Falcon verification | ZKNOX 实现 | 8.5M | OK |
5.2.3 Yul
通过在关键路径中使用 Yul，并结合 2023年论文 Speeding up elliptic computations for Ethereum Account Abstraction（第 3.3 节 "Hacking EVM memory access cost"）中描述的 CODECOPY 与 EXTCODECOPY 技术，可以进一步优化性能。
| 函数 | 描述 | gas 成本 | 测试状态 |
|---|---|---|---|
| ntt.NTTFW | ZKNOX_NTTFW，基于 Yul 的迭代实现 | 1.9M | OK |
| falcon.verify_opt | 使用预计算公钥的完整 Falcon 验证 | 3.6M | OK |
5.2.4 Go Ethereum（进行中）
ZKNOX 正在为该 EIP 设计节点客户端实现。
参考资料
1\] ZKNOX团队2025年2月24日博客 [Practical results on Lattice onchain verifiers](https://zknox.eth.limo/posts/2025/02/24/ETHEREUM_for_PQ_era_250224.html)