Rollup项目的SNARK景观

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 V V合约。
    • 但是相比于为每个应用单独生成电路来说,这种通用电路通常会更大一些。类似于 (von-Neumann)CPU架构 vs. ASIC。开销主要来源于2方面:
      • 1)即使程序的每步仅执行一条指令,也会为每一步重复CPU的整个transition function。差异性类似于CPU与ASIC的区别。
      • 2)程序必须“编译”并允许在电路内部。若程序简单,则编译开销问题不大,并支持运行许多步(即big batch size)。
    • 针对大电路运行SNARK的主要开销由 P P P负责,而相应的验证开销 随电路大小 而增长的速度会相当慢。
  • 还有其它方法来实现一个 V V 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 V V不是work-saving的,不适合用于链上验证场景。】
  • 3)专注于对 P P 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 P P是不开源的, V V V为以太坊链上合约且是开源的。

4.1 SHARP性能

SHARP的性能指标主要有:

  • 1)延迟:2022年8月时,SHARP约需要8小时来生成证明。
    • 8小时为交易到达StarkNet 与 相应proof在L1上验证的最小延迟。
    • 最大延迟约为14小时。约需要8小时来fill batches(且区块约每2小时提交到StarkNet)。
      Rollup项目的SNARK景观_第1张图片
  • 2)每个batch的 V V V cost:2022年8月初时,Gas cost约为 0.46 0.46 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 P 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 P P来解决某32-bit Proof of Work puzzle,声称其具有32 bits security:
    • 即使该conjecture为true。为使 为任意desired false statement声称a convincing proof 的概率达到 2 − 48 + b 2^{-48+b} 248+b,瓶颈在于解决 2 b 2^b 2b个不同的32-bit PoW puzzles:
      • 1)借助约 2 64 2^{64} 264 hash evaluations,伪造证明的概率为 2 − 16 2^{-16} 216
      • 2)借助约 2 80 2^{80} 280 hash evaluations,伪造证明的概率约为 1 1 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 V V。但并不意味着对 P P P的加速。
  • 为节约gas费,基于SHARP的 Rollup方案设置了 aggressive security
    • 基于其conjecture,128-bit security对应的proof size和 V V V cost将增加约2倍;
    • 若是proved 128-bit security,对应的proof size和 V V 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 P P time:

  • 数小时的延迟在某种情况下可接受,但有些情况下不行。
  • 随着batch size增大以及交易数增多,痛点将更复杂。
  • (低估?的)研究方向:若 P P P cost大幅改进,更大的proof也可以:
    • 更快的 P P 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还需要考虑:
    • 系统设计以及工程化
    • 开发者经验
    • 用户体验
    • 生态及社区开发
    • 去中心化程度
    • 市场及品牌营销等等

你可能感兴趣的:(零知识证明,零知识证明)