Rollup项目的SNARK景观

Posted 2023-01-16 mutourend

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还需要考虑：
  • 系统设计以及工程化
  • 开发者经验
  • 用户体验
  • 生态及社区开发
  • 去中心化程度
  • 市场及品牌营销等等