zk-SNARKs-与-zk-STARKs的技术演进与工程实践

本文围绕两类主流零知识证明系统的构造原理、信任假设及工程化路径展开深度剖析，旨在为正在评估或部署 zk-Rollup、隐私身份验证等方案的开发者提供清晰的技术决策框架。

摘要

零知识证明（Zero-Knowledge Proof, ZKP）允许证明者在不泄露陈述本身内容的前提下，向验证者 convincing 地证明某个断言的真实性。在区块链领域，zk-SNARKs（Succinct Non-Interactive Arguments of Knowledge）与 zk-STARKs（Scalable Transparent Arguments of Knowledge）构成了当前最主流的两条技术路线。zk-SNARKs 以极小的证明体积和毫秒级的验证速度著称，但其代价是通常需要一次性的可信设置（Trusted Setup）；而 zk-STARKs 通过 FRI（Fast Reed-Solomon Interactive Oracle Proof of Proximity）协议与抗碰撞哈希函数，彻底摆脱了对可信设置的依赖，并在量子计算威胁下展现出更强的生存能力，代价则是证明体积显著增大、验证开销略高。本文从密码学原语、协议构造、工程实现、生态成熟度四个维度对两者进行系统性对比，详细拆解了zk-SNARKs中从QAP/QSP到Groth16、PLONK以及Halo2的演进脉络，同时深入解析了zk-STARKs所依赖的代数编码理论与FRI低度测试机制。在工程实践层面，文章梳理了Circom/SnarkJS、Noir、Cairo等开发框架的技术特征与适用场景，并通过zkSync Era与StarkNet两个主网级zk-Rollup方案的案例，揭示两类证明系统在实际吞吐量、延迟、硬件成本等方面的真实权衡。文章最后探讨了递归证明（Recursive Proof Composition）、硬件加速及zkVM统一愿景对未来格局的潜在重塑。

一、引言：零知识证明何以成为区块链扩容与隐私的关键基座

区块链的可扩展性困局，本质上是一个验证成本的分摊问题。在以太坊等公链的Layer 1上，每一个全节点都必须重新执行每一笔交易以验证其合法性。这种全局重执行模型虽然带来了极强的安全冗余，却也导致了吞吐量的刚性天花板。当链上交易量激增时，gas费用随之飙升，用户体验急剧恶化，开发者被迫将大部分计算密集型逻辑迁移到链下。

但这又引入了一个新的信任瓶颈：链下计算的执行者——无论是中心化的服务器还是去中心化的委员会——理论上都可能作恶。如何在不重新执行全量计算的前提下，向链上智能合约证明链下计算结果的正确性？零知识证明提供了这个密码学答案。通过将一笔复杂的链下计算（例如成千上万笔转账的批量处理）编码为一个可证明的算术电路，证明者可以生成一个体积远小于原始计算过程的加密证明，链上合约只需以固定且极小的开销验证该证明，即可确信链下计算被忠实执行。

基于这一范式，zk-Rollup 应运而生。它将大量交易在链下聚合执行，并定期向主链提交一个状态根和一个有效性证明（validity proof）。由于以太坊主链仅需验证证明而非重放交易，数据压缩比可达数个数量级，而安全性仍然锚定于底层主链的共识机制。

在零知识证明的众多构造方案中，zk-SNARKs 与 zk-STARKs 占据了现实部署的绝对主流。理解两者的技术差异、工程权衡与演进方向，是任何一个希望深入 zk-Rollup、隐私保护身份（zkKYC）、机密支付（Confidential Transfer）或 zkBridge 领域的从业者无法绕过的课题。这两类系统的差异绝非简单的"有设置"与"无设置"的二元对立；其背后牵扯到椭圆曲线配对、多项式承诺、哈希函数假设、量子抗性、递归能力、开发工具链成熟度乃至社区治理哲学等多维度的深刻分野。

以下章节将沿着从数学原语到工程落地的路径，对两者展开逐层剖析。

二、核心技术解析：两条路线的构造原理与深层差异

2.1 zk-SNARKs：基于椭圆曲线配对的简洁论证

zk-SNARKs 的定义性特征可以被拆解为三个关键词：Succinct（证明体积极小，通常仅数百字节）、Non-Interactive（证明生成后，验证者无需与证明者进行多轮交互，单次消息即可完成验证）、Argument of Knowledge（具备知识可靠性：证明者不仅证明了断言为真，还证明了其"知晓"满足该断言的 witness）。

2.1.1 从计算到电路：R1CS 与 QAP 的编码桥梁

任何希望被zk-SNARKs证明的计算，首先必须被转化为一个等价的代数问题。这一过程通常经过两层编码：

1. 高级语言 → 约束系统：开发者使用 Circom、Noir 或 ZoKrates 等专用语言编写程序，编译器将其转化为 R1CS（Rank-1 Constraint System）或类似的算术约束系统。R1CS 由一系列形如 A * B = C 的二次约束构成，每个约束对应电路中的一个逻辑门。
2. 约束系统 → 多项式：通过拉格朗日插值，R1CS 中的三个向量矩阵被编码为三个多项式 A(x)、B(x)、C(x)，使得原约束系统的可满足性问题等价于寻找一个 witness 多项式 W(x)，满足 A(x) * B(x) = C(x) 在某个特定的根集合上成立。这个多项式恒等式的检验，构成了 zk-SNARK 证明的核心。

2.1.2 可信设置的诅咒与救赎：从 Groth16 到 PLONK

在早期的 zk-SNARK 构造（如 Groth16）中，需要一个称为 Common Reference String (CRS) 的公开参数。CRS 的生成过程要求若干参与方各自生成并销毁一段随机数（toxic waste）。只要至少一名参与者诚实删除其随机数，整个系统的安全性即可保障；反之，若所有参与者串通保留，则 CRS 的后门可能被利用，导致伪造证明。著名的 "Powers of Tau" 仪式通过多轮多方计算（MPC）将信任分散到数百乃至数千名参与者身上，极大地降低了单点作恶的概率，但并未从根本上消除信任假设。

这一"诅咒"催生了两条救赎路径。其一，寻找通用且可更新的可信设置（Universal and Updatable CRS）。PLONK 方案是这一路径的里程碑。PLONK 使用了一种通用的 CRS（即对任意不超过某一大小的电路都适用），并且允许后续参与者在已有 CRS 之上追加自己的随机性进行"更新"，从而持续稀释初始设置的信任依赖。其二，完全消除可信设置。这便是 zk-STARKs 的路线。此外，Halo2 利用 承诺-打开-递归 的技术路线，实现了无需任何可信设置的 zk-SNARK，这是对传统 SNARK 范式的根本性突破。

2.1.3 证明的生成与验证：一次密码学压缩

在基于配对的 zk-SNARK（如 Groth16）中，证明的生成过程本质上是对 witness 多项式进行椭圆曲线点乘和配对运算。证明者使用其私有 witness（例如交易的输入金额、地址、私钥签名等敏感数据）和 CRS，计算出若干椭圆曲线群元素（通常 2 到 3 个），这些群元素即构成了最终提交给验证者的证明。

验证者的计算则更为轻量：它仅需将证明中的群元素与 CRS 中的公开参数进行若干次椭圆曲线配对运算。在 Groth16 中，验证仅需约 3 次配对和少量群乘法，在现代硬件上可在毫秒级完成。证明体积也极为紧凑：约 200 字节。这种极低的链上验证成本，是以太坊生态早期 zk-Rollup（如 zkSync Lite）选择 Groth16 的核心原因。

下图详细展示了基于 Groth16 的证明生成与验证的完整交互流程：

sequenceDiagram
    participant P as 证明者 (Prover)
    participant CRS as 公共参考串 (CRS)
    participant V as 验证者 (Verifier)

    P->>P: 1. 将计算编码为 R1CS/QAP
    P->>P: 2. 构造 witness 向量 w
    P->>CRS: 3. 获取 CRS (g^α, g^β, g^δ, g^τ^i...)
    P->>P: 4. 计算多项式 A(τ), B(τ), C(τ)
    P->>P: 5. 计算 H(τ) = (A(τ)B(τ)-C(τ))/Z(τ)
    P->>P: 6. 生成证明 π = (A, B, C)
    P->>V: 7. 发送证明 π + 公开输入 x
    V->>V: 8. 验证配对等式 e(A,B)=e(C,g^δ)·e(公开部分)
    V-->>P: 9. 返回验证结果 (Accept/Reject)

图1：zk-SNARKs（Groth16）证明生成与验证序列图

从上至下解读这一流程：

1. 电路编码阶段（消息1-2）：证明者首先将待证明的任意的计算逻辑（例如"我拥有足够的余额完成这笔转账，并且签名有效"）通过算术化编译器（如 circom）转换为 R1CS 约束系统，进而构造出 QAP 多项式表示。同时，证明者准备好 witness 向量 w，其中包含了所有公开输入（如交易金额、接收方地址）和私密输入（如私钥、原始余额）。
2. CRS 读取（消息3）：证明者获取预先生成好的 CRS。对于 Groth16，CRS 的结构是固定的，一旦生成就无法更新，且其安全性依赖于生成过程中"toxic waste"被至少一方销毁。
3. 核心计算（消息4-6）：这是证明生成中最计算密集的部分。证明者需要在目标多项式 Z(τ) = (τ-1)(τ-2)...(τ-n) 的根上验证 A(x) * B(x) - C(x) = H(x) * Z(x) 这一恒等式。通过在秘密点 τ 处求值，并利用 CRS 中的 g^τ^i 元素，证明者计算出群元素 A、B、C，这三个元素共同构成最终的证明 π。
4. 单向提交（消息7）：zk-SNARK 的关键优势在于非交互性。证明者只需一次性向验证者发送数百字节的证明 π 和公开输入 x，无需后续的多轮挑战-应答。
5. 配对验证（消息8-9）：验证者通过检查一个双线性配对等式来确认证明的有效性。这个等式的数学结构保证了：如果证明是通过正确的 witness 和 CRS 生成的，等式成立；如果 witness 不正确或证明被篡改，计算离散对数的困难性使得伪造证明在计算上不可行。验证者不需要任何私密信息，其计算量与电路大小无关，仅取决于公开输入的数量。

2.1.4 椭圆曲线配对的数学根基与局限

zk-SNARKs 对验证效率的极致追求，建立在一个相对高级的密码学假设之上：双线性配对（Bilinear Pairing）。配对将一个椭圆曲线群 G1 上的元素与另一个群 G2 上的元素映射到目标群 GT 上的一个元素，并且保持乘法运算结构的同态映射。目前广泛应用于生产环境的是 BN-128、BLS12-381 等配对友好曲线。这些曲线的安全性基于椭圆曲线离散对数问题（ECDLP），而 ECDLP 在已知的通用量子计算机算法（Shor 算法）面前是脆弱的。因此，基于配对的 zk-SNARKs 不具备后量子安全性。虽然大规模量子计算机仍是中长期威胁，但这已足以促使一部分对长期安全敏感的项目向 zk-STARKs 或基于格（Lattice）的后量子方案迁移。

2.2 zk-STARKs：基于哈希与代数编码的透明论证

zk-STARKs 由 Eli Ben-Sasson、Alessandro Chiesa 等研究者于 2018 年正式提出，其设计哲学与 zk-SNARKs 截然不同：它放弃了椭圆曲线配对，转而完全依赖抗碰撞哈希函数（如 SHA-256、Blake2s、Rescue/Poseidon）和代数编码理论（特别是 Reed-Solomon 码），从而实现了完全的透明性——无需任何可信设置。

2.2.1 从多项式到 Reed-Solomon 码：错误生成码的密码学运用

STARK 的证明构造同样将计算问题转化为多项式恒等式的检验，但路径大不相同。在 STARK 中，计算执行轨迹（execution trace）被表示为一个 low-degree 的多项式 f(x)。为了验证该多项式确实正确编码了原始计算，STARK 使用 FRI 协议来向验证者证明：

1. f(x) 的度数被某个上界 d 所限制；
2. f(x) 满足计算所施加的一系列约束（如状态转换约束、边界约束）。

为了抵抗恶意证明者提交一个表面上满足约束但度数极高的多项式，STARK 将原始评估域通过一个称为 codeword 的 Reed-Solomon 码进行编码：将低度多项式 f 在一个远大于其度数的域 L 上求值，生成一个码字 RS[f]。根据编码理论，一个低度多项式的码字与其最近的低度码字之间的距离是远的；而一个高度多项式的码字则必然靠近某个高度码字。FRI 协议通过一种类似于二分法的折叠-承诺-查询机制，让验证者以极高的概率确信证明者所承诺的多项式确实具有低度数。

2.2.2 FRI 协议：折叠、承诺与一致性查询

FRI（Fast Interactive Oracle Proof of Proximity to a low-degree polynomial）是 zk-STARK 的引擎。它并非一个单一的步骤，而是一个多轮交互的协议（虽然在实际工程中可通过 Fiat-Shamir 变换转为非交互式）。其核心思想可以概括为"分而治之的低度测试"：

在一个包含 N 个点的评估域上，证明者声称其向量是一个度数小于 d 的多项式的评估值。验证者并不直接检查所有 N 个点（那将是线性的验证成本），而是要求证明者将问题"折叠"到一个更小的域上。具体而言，对于每一轮：

• 证明者将其当前的多项式 f(x) 分解为偶次项和奇次项之和：f(x) = f_even(x^2) + x * f_odd(x^2)。
• 验证者发送一个随机挑战 α。
• 证明者构造一个"折叠多项式" f_fold(x^2) = f_even(x^2) + α * f_odd(x^2)，其度数大致减半。
• 这一过程重复 log(d) 轮，直到多项式的度数足够低，以至于验证者可以直接检查。

在每一轮中，证明者通过 Merkle 树承诺其在该轮评估域上的所有点。验证者在每一轮中只随机抽样查询少量点，并通过 Merkle 路径验证这些点未被篡改。如果原始多项式的度数确实足够低，折叠过程将保持一致；如果度数超标，则每一轮折叠都有固定概率暴露不一致性。经过足够多的轮次和查询，总 soundness error 可以被压至可忽略的程度。

flowchart TD
    A[证明者: 原始轨迹多项式 f(x)，度数 < d] --> B[在域 L0 上求值并 Merkle 承诺 C0]
    B --> C[验证者: 发送随机挑战 α1]
    C --> D[证明者: 计算折叠多项式 f1(x²)=f_even(x²)+α1·f_odd(x²)]
    D --> E[在域 L1 上求值并 Merkle 承诺 C1]
    E --> F[验证者: 发送随机挑战 α2]
    F --> G[证明者: 继续折叠至 f2, 度数 ≈ d/4]
    G --> H{重复 log(d) 轮}
    H --> I[最终轮: 度数足够低，直接证明]
    I --> J[验证者: 随机抽样查询各轮 Merkle 路径]
    J --> K[验证一致性 & 低度性质]
    K --> L{通过?}
    L -->|是| M[接受证明]
    L -->|否| N[拒绝证明]

图2：FRI 协议核心运作流程图

对上图的逐模块展开解读：

• 模块 A-B（初始化与承诺）：证明者首先将链下计算的执行轨迹编码为一个多项式 f(x)。例如，在一个简单的状态机中，x 可以代表时间步，而 f(x) 代表该时间步的所有寄存器值。协议要求这个多项式的度数远低于评估域的大小。证明者选择一个远大于度数的域 L0（通常大小为 d 的 2-8 倍，具体取决于所需的安全性参数），在 L0 的所有点上对 f(x) 求值，并计算这些值的 Merkle 树根 C0，将根发送给验证者。这个 Merkle 承诺是关键：它绑定（bind）了证明者，使得证明者后续无法根据验证者的查询随意修改已承诺的值。
• 模块 C-G（多轮折叠与再承诺）：验证者发送一个随机域元素 α1 作为挑战。证明者根据挑战计算折叠多项式，将度数为 d 的问题转化为度数为 d/2 的问题。证明者在新域 L1（大小约为 L0 的一半）上重新求值并生成新的 Merkle 根 C1。验证者再发送 α2，进入下一轮。这一过程重复约 log2(d) 次。每一轮折叠都将问题的规模减半，最终将原始的低度测试问题压缩到一个可以直接检查的常量规模。
• 模块 H（迭代结构）：整个折叠过程是 FRI 的核心。它的数学保证依赖于 Reed-Solomon 码的最小距离特性：如果证明者试图作弊（提交一个高度数多项式），那么每一轮折叠都会在评估域的某处产生与真实低度码字的不一致点。这些不一致点在验证者的随机抽样中以极高概率被捕获。
• 模块 I-K（最终验证）：在足够多的轮次后，证明者可以直接向验证者展示最终的小规模多项式。验证者不需要信任这个最终多项式本身，而是回溯检查：它在每一轮中随机选择少数几个索引，要求证明者提供这些索引在所有相关轮次中的值及其 Merkle 路径。验证者确认：
  1. Merkle 路径与该轮承诺的根一致（证明未被篡改）；
  2. 每轮中的值满足该轮的折叠方程（数学一致性）。
• 模块 L-N（判决）：如果所有抽样点均通过，验证者接受；只要有一个点失败，就拒绝。soundness error 取决于抽样数量和域的扩张率，可以通过参数调整达到 2^-128 或更低。

2.2.3 证明体积、时间与透明性的三角权衡

zk-STARKs 的透明性带来了一系列连锁反应。

优势方面：

• 无需可信设置：CRS 的生成完全可公开审计，不存在 toxic waste。
• 后量子安全：其安全性仅依赖哈希函数的抗碰撞性，而当前没有已知的量子算法能有效破坏通用哈希函数的抗碰撞性。
• 更弱的密码学假设：不依赖椭圆曲线配对的特殊结构，仅使用通用密码学原语。

代价方面：

• 证明体积大：一个典型的 zk-STARK 证明大小在 50KB 到 200KB 量级，比 zk-SNARK 的 200 字节大了数百到数千倍。这对于需要频繁将证明发布到链上合约的场景（如 zk-Rollup的calldata成本）是一个显著劣势。
• 验证成本更高：虽然 STARK 验证是 polylogarithmic 级别，但常数因子较大，通常需要数万到数十万次哈希运算（根据工程实践经验），而 SNARK 的验证则是数次配对（ms 级）。
• 证明生成更慢：由于 FRI 涉及大量多项式求值和 Merkle 树构建，在同等电路规模下，STARK 的证明生成时间通常长于优化的 SNARK 实现（不过这也取决于具体硬件和优化水平）。

2.3 横向对比：一场多维度的技术权衡

上表并非简单的优劣对比，而是工程决策的坐标系。对于将证明体积和验证成本视为第一优先级、且能接受可信设置 ceremony 的项目（如早期的 zkSync、Loopring），zk-SNARKs 是不二之选。而对于强调密码学透明性、不信任任何 ceremony、或需要长期抵抗量子计算威胁的基础设施（如 StarkNet、某些政府或企业级身份验证系统），zk-STARKs 的额外证明体积和验证开销是换取无需许可的信任基底的合理对价。

三、工程实践：从理论到主网级部署的跨越

密码学理论的正确性只是第一步。将零知识证明系统推向生产环境，意味着开发者必须面对编译器稳定性、证明生成延迟、硬件资源消耗、调试工具和生态成熟度的全方位考验。

3.1 zk-SNARK 开发栈：Circom、Noir 与 Halo2

Circom / SnarkJS 这套组合是目前最成熟的 zk-SNARK 工程栈。Circom 是一种专门用于编写电路的领域特定语言（DSL）。它的设计哲学接近硬件描述语言（如 Verilog）：开发者需要显式地定义每一个加法门、乘法门和约束线。这种底层操控带来了极致的优化空间——经验丰富的电路工程师可以通过巧妙地复用约束、减少 witness 变量数量，来显著缩小电路规模和证明生成时间。zkSync Lite 和早期的 Tornado Cash 均是基于 Circom 构建。

但 Circom 的学习曲线陡峭，且极易出错。一个常见的陷阱是非预期的 underconstraint：开发者写了一个乘法约束 a * b = c，却忘记约束 a 和 b 的位宽，导致恶意证明者可以通过模运算的 wrap-around 行为绕过逻辑。类似地，范围证明、布尔约束、信号排序等基础性操作都需要开发者手动处理。

Noir 由 Aztec 团队推出，代表了更高级抽象的方向。Noir 语法趋近于 Rust，支持条件分支、循环、数组等高级结构，编译器自动将其转化为底层的算术约束。它的目标是让不具备密码学背景的普通开发者也能编写可验证的程序。其代价是编译器生成的电路通常不如手写 Circom 紧凑，但在大多数应用场景下，开发效率的提升远比电路优化带来的边际收益更有价值。

Halo2 则是 Zcash 基金会与 Electric Coin Company 推动的基于 PLONK 的框架，其最革命性的贡献在于实现了递归证明而无需可信设置。通过基于 IPA（Inner Product Argument）的多项式承诺，Halo2 允许一个证明去验证另一个证明，从而将无限累积的 witness 压缩到恒定大小。这一特性为 zk-EVM 和无限压缩的 zk-Rollup 提供了关键的理论基础。

3.2 zk-STARK 开发栈：Cairo 与 Winterfell

Cairo 是 StarkWare 为 zk-STARK 量身定制的 Turing-完备编程语言。与 Circom 不同，Cairo 将内存模型、寄存器操作和代数约束深度整合，其编程模型更接近于传统的汇编或中级语言。Cairo 的设计哲学是"一次编写，到处证明"：程序的执行本质上是生成一个满足 AIR（Algebraic Intermediate Representation）约束的 witness，而这个 witness 的可满足性由 STARK 证明器来保证。

Cairo 1.0 引入了大量现代语言特性（如类型安全、所有权、更丰富的标准库），显著改善了开发者体验。

Winterfell 是 Facebook（现 Meta）推出的 Rust 语言 STARK 证明/验证库。相比 Cairo 的语言-虚拟机-证明器一体化方案，Winterfell 更像是一个底层的密码学库，允许开发者在自己的 Rust 应用中嵌入 STARK 证明生成与验证逻辑。对于需要深度定制证明系统的团队，Winterfell 提供了更大的灵活性。

3.3 性能基准：理论与实测的鸿沟

在密码学论文中，zk-SNARKs 的验证复杂度通常被描述为 O(1)（常数时间，与电路大小无关），而 zk-STARKs 为 O(polylog(n))。这给人一种错觉：无论电路多复杂，SNARK 验证总是瞬间完成，而 STARK 只是"略慢"。

现实更为微妙。O(1) 中的常数因子在工程上差异巨大。Groth16 的验证大约需要 3 次椭圆曲线配对和少量的群乘法，在现代 CPU 上耗时约 1.5 毫秒。STARK 的验证虽然是对数级，但每次需要执行数万次哈希运算。在 x86 服务器上，一次中等规模（约 10^5 条约束）的 STARK 验证可能耗时 20-50 毫秒。在链上环境中，以太坊的预编译合约（如 ecPairing）使得 SNARK 验证的 gas 成本极低（约 300k gas），而 STARK 验证所需的哈希运算在 EVM 上的 gas 开销则显著更高。这正是 StarkNet 选择自建 L2 链而非依赖以太坊合约直接验证 STARK 的核心原因之一——它需要一个针对 STARK 验证优化的执行环境。

证明生成则是另一个战场。对于 zk-Rollup，证明者通常是专业的测序节点（sequencer），运行在高端服务器甚至 GPU/FPGA 上。一篇 2023 年的实践报告显示，在消费级 GPU 上为 10,000 笔 ERC-20 转账生成一次 zk-SNARK 证明（PLONK）耗时约 1-3 分钟；而同等规模的 STARK 证明则可能需要 5-15 分钟，但不需要任何可信设置 ceremony。这种时间差异对于批量提交的节奏有直接影响。

四、案例分析：zkSync Era 与 StarkNet 的工程取舍

理论上的权衡最终落实在具体的协议设计中。zkSync Era 和 StarkNet 作为当前以太坊生态中两大最具影响力的 zk-Rollup，分别代表了 zk-SNARK（及其演进形式）和 zk-STARK 的工程化最高水准。

graph TB
    subgraph zkSync_Era["zkSync Era (zk-SNARK / Boojum)"]
        A1[ sequencer 收集用户交易 ] --> A2[ 执行交易 & 生成状态差分 ]
        A2 --> A3[ Boojum 证明系统 <br/> 基于 PLONK/HyperPLONK ]
        A3 --> A4[ 生成 ~500 字节证明 ]
        A4 --> A5[ 向以太坊主网提交 proof + calldata ]
        A5 --> A6[ 以太坊合约验证 proof <br/> ~200k gas, <10ms ]
    end

    subgraph StarkNet["StarkNet (zk-STARK / Cairo VM)"]
        B1[ sequencer 收集用户交易 ] --> B2[ Cairo VM 执行 & 生成执行轨迹 ]
        B2 --> B3[ STARK 证明器证明 Cairo 执行正确性 ]
        B3 --> B4[ 生成 ~80-150KB 证明 ]
        B4 --> B5[ 将数据发布至 L1 <br/> calldata / blobs ]
        B5 --> B6[ L1 合约或 L2 验证者验证 STARK ] 
    end

    C[以太坊 Layer 1] --> A6
    C --> B6

图3：zkSync Era 与 StarkNet 的 zk-Rollup 交易生命周期与证明提交流程架构图

对该架构图的详细解读：

zkSync Era 侧（左半部分）：

1. 交易收集与执行（A1-A2）：zkSync 的 sequencer 收集来自用户的 L2 交易，在虚拟机中执行这些交易，并计算出新的状态根以及状态差分。这里的执行环境与以太坊并非逐指令等价的 EVM，而是一个功能等效的 zkVM，支持 Solidity/Vyper 代码的编译部署。
2. 证明生成（A3）：zkSync 从 1.0 时代的 Groth16 迁移到了自研的 Boojum 证明系统。Boojum 本质上是基于 PLONKish 算术化方案的现代化实现，支持更高效的递归聚合。这意味着 zkSync 可以先为每个区块（或每批交易）生成一个小证明，然后将这些证明递归地聚合成一个最终的大证明，显著摊薄了单批交易的证明生成成本。
3. 极小证明与低 gas 验证（A4-A5）：zk-SNARK 路线的终极优势在这一环节体现得淋漓尽致。最终提交到以太坊主链的证明仅数百字节，作为 calldata 或直接作为合约调用的参数，占用的链上空间极小。验证合约通过 ecPairing 等预编译合约执行配对验证，gas 成本可控制在 20 万以下，耗时在毫秒级，对主链的压力几乎可以忽略。
4. 主链锚定（A6）：一旦以太坊上的验证合约接受了证明，zkSync 的新状态即获得了与以太坊主网同等级的最终性（finality）。这是 Validium 与 zk-Rollup 的关键区别：zkSync Era 将数据可用性（DA）也发布到了主链（通过 calldata 或 EIP-4844 blob），因此任何用户都可以从公开的 L1 数据重建 L2 状态。

StarkNet 侧（右半部分）：

1. Cairo VM 执行（B1-B2）：StarkNet 的显著差异在于其执行层采用 Cairo VM，这是一个专为可证明性设计的寄存器机架构。Solidity 代码不能直接在 Cairo VM 上运行，必须经过转译或重写为 Cairo 语言。这种"原生 zk"的设计虽然牺牲了与 EVM 的即插即用兼容性，但获得了对 STARK 证明更友好的执行模型——所有的 Cairo 程序执行都天然产生一个适合 FRI 协议处理的代数中间表示（AIR）执行轨迹。
2. STARK 证明生成（B3）：StarkNet 的证明器接收 Cairo 执行轨迹，生成证明其正确性的 zk-STARK。由于 STARK 不需要可信设置，StarkNet 网络的证明器可以完全无需许可地参与运行，没有任何 ceremony 的后顾之忧。
3. 数据发布与验证（B4-B6）：这里体现了 STARK 的主要劣势：证明体积通常在 80KB 到 150KB 量级。EIP-4844（Proto-Danksharding）的引入对此有所缓解——StarkNet 现在可以将证明和状态差分打包进 blob，显著降低了 L1 数据发布的成本。验证端，StarkNet 在其 L2 环境中原生支持 STARK 验证运算；而 L1 上的验证合约则通过执行大量哈希运算来检查 FRI 承诺和查询路径。这个验证过程的 gas 消耗显著高于 SNARK，但仍在可接受范围内，且随着 blob 交易的低成本化，整体经济效益持续改善。

这两个案例清晰地展示了同一目标（构建以太坊上的有效 zk-Rollup）下不同技术路线所带来的链上 footprint、最终确认延迟、EVM 兼容性和开发迁移成本的系统性差异。对应用开发者而言，选择基于 zkSync Era 部署意味着几乎无缝的以太坊工具链复用；而选择 StarkNet 则意味着进入 Cairo 生态，接受当前相对有限的库和工具，但换取完全透明的信任模型和更长期的密码学鲁棒性。

五、未来展望：递归、硬件加速与 zkVM 的终极竞合

零知识证明系统的演进远未止步于当前 SNARK 与 STARK 的二元分立格局。若干前沿方向正在从根本上重塑其工程边界和适用范围。

递归证明 composition 是其中最具变革性的概念之一。在 Halo2 和更近期的 Nova/Supernova 框架中，一个证明系统被设计为可以高效地验证另一个同类证明。这意味着，一个 zk-Rollup 可以为每一个单个交易生成一个微小证明，然后将交易证明两两聚合为区块证明，再将区块证明进一步聚合为日证明、周证明——最终提交到主链的始终是一个恒定大小的证明。递归证明不仅压缩了链上数据，还创造了全新的应用形态，例如 区块链轻客户端（用户设备上可以持有一个最新区块头的递归证明，无需同步全量历史），以及 zkBridge（跨链桥可以通过零知识证明来证明另一条链的共识状态，而无需信任中继节点集合）。

硬件加速 正在抹平 STARK 与 SNARK 在证明生成速度上的差距。零知识证明的生成本质上是大规模并行友好的：大量独立的有限域运算、椭圆曲线点乘、FFT（快速数论变换）和哈希计算都可以被 GPU 高度并行化。更进一步，FPGA 和 ASIC 正在进入这一领域。Ingonyama、Cysic 等团队推出了专门针对 MSM（Multi-Scalar Multiplication，椭圆曲线点乘之和）和 NTT（Number-Theoretic Transform，有限域上的 FFT）优化的硬件加速器。在专用硬件的加持下，原本需要数分钟生成的证明可以被压缩到秒级甚至亚秒级，这为单位时间内处理更大规模交易、降低测序节点的资本开支打开了空间。

zkVM 的统一竞赛 代表了更深层的融合趋势。当前，zkSync 的 VM、StarkNet 的 Cairo、Polygon 的 zkEVM、Scroll 的 zkEVM 各自采用不同的指令集和证明系统，形成了事实上的"零知识孤岛"。业界正在向一个更宏大的愿景迈进：一个通用的、与 LLVM 等价的零知识虚拟机，任何高级语言（Rust、C++、Solidity）都可以被编译为其中间表示，然后由后端的证明系统自动生成 SNARK 或 STARK。RISC-V 指令集因其开源、简洁和广泛的工具链支持，正在成为 zkVM 中间层的热门候选。RISC0、Succinct Labs 的 SP1 等团队正在构建基于 RISC-V 的 zkVM，试图将证明系统的选择（SNARK 还是 STARK？Groth16 还是 PLONK？）从应用层完全抽象到底层。如果这一愿景落地，开发者将不再需要关心自己的代码究竟是"Cairo 程序"还是"Circom 电路"，而只需用熟悉的语言编写逻辑，由编译器和证明器自动完成可验证性的封装。

最后，后量子密码学（PQC）的进程将持续影响两类系统的长期价值。尽管实用的量子计算机尚不存在，NIST 已公布了首批后量子密码学标准。zk-STARKs 基于哈希函数的特性使其天然具备后量子安全性，而 zk-SNARKs 则需等待基于格（Lattice）或纯哈希函数的新构造来补齐短板。在可以预见的未来，对监管极度敏感、需要 10 年以上信任周期的基础设施（如国家级数字身份、央行数字货币的隐私模块）可能会更早地向 STARK 或其后量子兼容变体倾斜。

六、结语

zk-SNARKs 与 zk-STARKs 的竞争与互补，本质上是密码学世界中"效率优先"与"透明优先"两种哲学在工程层面的投射。zk-SNARKs 凭借数十年的优化积累，在证明体积和验证速度上建立了短期内难以逾越的壁垒，成为当前 zk-Rollup 和隐私支付方案的主力军。zk-STARKs 则以其无需信任设置、极简的密码学假设和量子抗性，为需要最高信任级别和长期安全承诺的应用提供了不可替代的选项。

对于开发者而言，这一选择不是非此即彼的排他性决策，而是基于具体约束条件的帕累托优化：你的应用对链上 calldata 成本有多敏感？你的用户能否容忍数分钟的最终确认延迟？你的系统是否必须运行在一个对"toxic waste"零容忍的监管环境中？你的威胁模型是否包含十年后的量子攻击者？这些问题的答案，将自然指向最适合的证明系统。而随着硬件加速抹平生成延迟、递归证明压缩提交频率、通用 zkVM 抹平开发差异，两条路线之间的功能性鸿沟正在缩小，而它们各自在密码学哲学层面的独特价值，将在更长的技术周期中持续闪耀。

本文技术参考资料来源于公开学术文献、开源项目文档及公开技术报告，部分性能数据参考了各项目团队公开披露的基准测试结果。