1. 引言

前序博客有：

SNARK Design

主要参考Justin Thaler 2022年8月在a16z crypto专题研讨会上的系列讲座：

SNARK Design, Part II, with Justin Thaler | a16z crypto research talks

2. Rollup的前端

当前各Rollup项目的前端情况为：

1）StarkWare为程序员提供了名为Cairo的高级编程语言：
- 可借助标准前端技术将Cairo程序编译转换为“circuits电路”；
- Cairo类似于功能有限的汇编语言。程序员必须知道SNARK-specific issues，如：
  - Arithmetic是基于某大素数的模运算；
  - 不支持 $>, <$ 等不等关系运算；
  - 采用“non-deterministic advice”等等。
2）其它Rollup项目（如zkSyn2.0——Matter Labs、Scroll、Polygon Hermez等）则寻求让程序员使用Solidity：
- 将Solidity程序编译转换为“circuits电路”。
- 近期这几个项目均已发布测试网。

2.1 性能及安全性考虑

性能及安全性考虑：

为了获得small circuits，很多项目都生成了一些错综复杂的手写“gadgets”，如：
- 针对通用指令的optimized circuits：
  - 如zkSync 1.0仓库中有约5千行的Bellman代码：https://github.com/matter-labs/zksync/blob/master/core/lib/circuit/src/circuit.rs
  - zkSync 1.0所基于的“Franklin-crypto gadget library”，当使用curve BN256构建recursively compose PlonK时将非常复杂。BN256为当前以太坊支持的pairing-friendly曲线。还有一些其它未完成的EIP提议一些对recursive SNARKs更友好的曲线。
  - 技术原因，当composition中包含BN256时，需要在电路内实现“big-integer” arithmetic，对应超过5千行的Bellman gadgets代码：https://github.com/matter-labs/franklin-crypto/tree/dev/src/plonk/circuit/bigint

zkRollup（validity-Rollup）“rely on Math, not Validators”，但是相应的math可能包含了几万行手写的circuit specifications。这些手写代码中可能存在bug，未来长期来看，需要为其引入形式化验证来进行自动化审计。也可能会将更多的责任推给程序员，如，StarkNet的Cairo front-end的正确性已可进行形式化验证[AGLST21]，但是Cairo语言将很多“SNARK-aware programming”责任推给了程序员。

2.2 不同前端方法之间的差异性

不同前端方法之间存在差异性：

StarkWare的前端会生成“universal通用”电路：
- 该电路将待运行的Cairo程序作为public input，然后基于witness进行“编译和运行”。具体参看Hello Cairo！。
- 以一个电路来支持所有Cairo程序：使得不同的应用可共享同一个 $V$ 合约。
- 但是相比于为每个应用单独生成电路来说，这种通用电路通常会更大一些。类似于（von-Neumann）CPU架构 vs. ASIC。开销主要来源于2方面：
  - 1）即使程序的每步仅执行一条指令，也会为每一步重复CPU的整个transition function。差异性类似于CPU与ASIC的区别。
  - 2）程序必须“编译”并允许在电路内部。若程序简单，则编译开销问题不大，并支持运行许多步（即big batch size）。
- 针对大电路运行SNARK的主要开销由 $P$ 负责，而相应的验证开销随电路大小而增长的速度会相当慢。
还有其它方法来实现一个 $V$ 合约对应所有程序：如名为“computation commitments”或“holography”的pre-processing circuit。

3. Rollup的后端

当前各Rollup项目的后端情况为：

1）StarkWare的后端采用 FRI多项式承诺 ➕ constant-round polynomial IOP。
2）基于PlonK的各项目：
- 2.1）zkSync采用PlonK（使用KZG多项式承诺）
- 2.2）Polygon Zero采用PlonK，但使用FRI多项式承诺
- 2.3）Zcash Orchard采用PlonK ➕ Bulletproofs多项式承诺，以实现transparency。【Rollup项目不会采用该方案，应Bulletproofs $V$ 不是work-saving的，不适合用于链上验证场景。】
3）专注于对 $P$ 进行硬件加速的各项目。

4. Rollup项目案例学习：StarkNet和StarkEx

Rollup项目案例学习：StarkNet和StarkEx。学习的目的是：对延迟、gas节约、吞吐量、安全性有所了解。

StarkNet为StarkWare的public smart-contract L2，会向以太坊提交validity proofs。在2022年8月初时，TVL值仅65万刀，但在持续增长，详细参看https://l2beat.com/scaling/tvl。

StarkEx为permissioned，application specific。在2022年8月初时，TVL值为6.96亿刀，大多数在dYdX中（约6.14亿刀）。

StarkNet与多个StarkEx应用共享同一个prover，如：

Immutable X
Sorare
Deversifi
Celer

这些StarkEx应用共享的prover名为SHARP——其 $P$ 是不开源的， $V$ 为以太坊链上合约且是开源的。

4.1 SHARP性能

SHARP的性能指标主要有：

1）延迟：2022年8月时，SHARP约需要8小时来生成证明。
- 8小时为交易到达StarkNet 与相应proof在L1上验证的最小延迟。
- 最大延迟约为14小时。约需要8小时来fill batches（且区块约每2小时提交到StarkNet）。
2）每个batch的 $V$ cost：2022年8月初时，Gas cost约为 $0.46$ ETH/proof verification。
- Proofs平均以38笔以太坊交易来验证。可参看数据源https://etherscan.io/address/0xff6b2185e357b6e9136a1b2ca5d7c45765d5c591，以及https://l2fees.info/l1-fees。
3）batch size：基于StarkWare发送的脚印数，每个batch约为9万笔交易。StarkNet的平均交易数低于800。大多数交易来源于Immutable（约85%），其次来源于Sorare（约10%）。
4）相比于no rollup的gas saving：Justin Thaler初步估算SHARP的gas saving为100x。也参看博客StarkNet Alpha is Coming to Mainnet。不过这没有将 $P$ 的计算开销对应的美金考虑在内，仅考虑了proof verification对应的gas费。
- 有经验的Cairo程序员可对StarkEx client程序进行优化。
- StarkWare声称其为dYdX节约500~1000x的gas费，为特定的mass-NFT-minting操作，可节约2万x的gas费。不过，并不清楚这些应用的延迟latency指标。

4.2 SHARP安全性

SHARP声称其SNARK安全性为80 bits：

但是，其运行的FRI安全性仅有48 bits，仅在aggressive conjectures的soundness（假设simple attack is optimal）的情况下：
- 最终的多项式承诺的proved安全性最多为22 bits。
用 $P$ 来解决某32-bit Proof of Work puzzle，声称其具有32 bits security：
- 即使该conjecture为true。为使为任意desired false statement声称a convincing proof 的概率达到 $2^{-48+b}$ ，瓶颈在于解决 $2^b$ 个不同的32-bit PoW puzzles：
  - 1）借助约 $2^{64}$ hash evaluations，伪造证明的概率为 $2^{-16}$ 。
  - 2）借助约 $2^{80}$ hash evaluations，伪造证明的概率约为 $1$ 。
有经济动力进行相关攻击：
- 2018年，AWS上SHA1 evaluation的开销约为100万美金。
- 原则上false proof可用于窃取L2上的所有资金。
- 若L2上有1千亿美金，期待的攻击战利品为1500万刀。
- 攻击者可通过摧毁来获利，即使其永远不花费其窃取的资金。

low security的原因在于：

SHARP verifier仅进行12次”FRI verifier queries“。
更少的FRI queries意味着更短的SNARK proof以及更快的 $V$ 。但并不意味着对 $P$ 的加速。
为节约gas费，基于SHARP的 Rollup方案设置了 aggressive security：
- 基于其conjecture，128-bit security对应的proof size和 $V$ cost将增加约2倍；
- 若是proved 128-bit security，对应的proof size和 $V$ cost将增加约4~5倍。

4.3 本案例的额外知识

当今，所有的post-quantum（PQ）SNARK的proof size 要比 shortest non-PQ SNARK的proof size 大得多：

随着security参数的增加，proof size将线性增加。
这也是为何StarkWare is aggressive with security的原因：
- 有必要与non-post-quantum service就gas开销进行竞争？

即使是基于aggressive security conjectures，PlonK proof的proof size 比 FRI-base proof 小一个量级：

PlonK proof的验证开销约为51万 gas，等价为25笔转账交易。

若classical security为substantially worse，那post-quantum security会更好么？

”Future-proof“？”now-proof“？
当今的STARK proof要比以太坊密码学上更低的classical security。

Rollup要想胜出，需考虑SNARK $P$ time：

数小时的延迟在某种情况下可接受，但有些情况下不行。
随着batch size增大以及交易数增多，痛点将更复杂。
（低估？的）研究方向：若 $P$ cost大幅改进，更大的proof也可以：
- 更快的 $P$ ，意味着指定的latency具有更大的batch，意味着具有更好的摊销gas cost。

5. Rollup项目案例学习：zkSync 1.0

zkSync 1.0的区块浏览器为https://zkscan.io/。在该浏览器内，显示了每笔交易的时间戳：

每个batch的commitment和CALLDATA提交到L1的时间戳。
以及何时该batch在L1上验证固化。

zkSync 1.0的proof通常对应数千笔交易。latency约为数小时，主要原语等待batch填满的时长。zkSync文档中提及其生成proof的时长约为10分钟。

6. Rollup思考

SNARK的前端和后端的不同选择决定了相应的性能和安全性。
但是除SNARK之外，Rollup还需要考虑：
- 系统设计以及工程化
- 开发者经验
- 用户体验
- 生态及社区开发
- 去中心化程度
- 市场及品牌营销等等

Rollup项目的SNARK景观