Rollup前端
Rollup前端主要分为两大类
第一类为StarkWare，采用Cairo语言进行开发，并借助前端技术将Cairo代码编译为电路
Cairo本质上是一个功能受限的汇编语言，开发者必须知道与SNARK相关的特性（比如算术运算总是以模素数形式计算，不支持大于小于，等于不等于之类的关系运算之类的特性）
第二类则要求开发者编写Solidity上的智能合约，比如zkSyn2.0、Scroll、Polygon Hermez等项目
但是相关项目还未在测试网上发布完整的前后端程序（zkSync2.0在2022年2月启动了测试网，但是只有前端，只能生成和执行电路，无法生成证明）
对于Rollup的性能与安全性而言，为了获得比较小的电路，许多项目都是手写一些很复杂的玩意，比如项目中需要用到bn254曲线时，需要用到处理大整数的工具，因此会在电路中包含5千多行的Bellman代码
由于rollup的有效性依赖于数学，而非验证器，但是数学必然会包含成千上万的手写代码（以及对应的bug），因此未来需要引入形式化验证来进行代码审计（比如Cairo的前端可用$[AGLST21]$进行审计），或者直接将责任推给开发者
此外，不同的rollup前端之间也有不同的差异，比如StarkWare的前端会生成通用电路，该电路将待运行的Cairo程序作为公共输入，之后利用witness进行编译和运行（具体可以看Medium上StarkWare官号发的博客）
而且StarkWare还有一个好处，所有的Cairo程序可以用同一个电路来执行，不同的应用可以用同一个Verifier来验证，但是这也意味着此类通用电路会比其他的专用电路更大，此类通用电路也有下列两个方面的开销
- 即使程序每步仅执行一条指令，CPU也需要执行一次转换函数（transition function）
- 程序必须编译为电路，并在电路内执行：如果程序比较复杂，则编译的开销也不小
不难看出，SNARK在处理大电路的时候，其主要开销来自于Prover
如果不想利用上述方式，还可以用一类称为计算承诺（computation commitments）或holography的预计算电路来将所有的程序用于同一个智能合约
Rollup后端
现阶段Rollup的后端大多数采用Plonk协议来构造，具体如下
- StarkWare：FRI多项式承诺+常数轮多项式IOP
- zkSync：Plonk+KZG多项式承诺
- PolygonZero：Plonk+FRI多项式承诺
- Zcash Orchard：Plonk+Bulletproof多项式承诺（以实现透密性）
此外还有部分项目针对Prover进行了硬件加速以优化其效率
Zcash Orchard中用到的Bulletproof的Verifier的开销很大，因此不适用于rollup的场景
StarkNet/StarkEx
接下来介绍一个rollup项目来了解rollup
StarkNet是StarkWare的公共Layer 2智能合约，该合约会向以太坊提交合法的证明，2022年8月时StarkNet的价值仅为约65万美元 TVL，不过目前在持续增长（2023.3月已经接近800万美元 TVL，数据来源：L2BEAT – The state of the layer two ecosystem）
TVL：Total Value Locked，总锁仓价值，Defi行业用于衡量Defi项目的热度和实力的指标
StarkEx的智能合约未获得许可（permission），且是针对于具体应用的，因此运行了更长时间，其TVL达到了3.66亿美元（2023年3月数据），其中大部分在dYdX中
StarkNet和StarkEx之间共用多个Prover，称为SHARP，比如Immutable X，Sorare，Deversifi，Celer等等，这些SHARP都是闭源的，但是对应的SHARV为部署在以太坊上的智能合约，且是开源的
2022年8月左右，SHARP构造一个证明需要大约8个小时（交易到达StarkNet到对应证明发布到Layer 1上的最短延迟），最大延迟约为14小时，其中需要大约8小时来填充批次，每个批次的Verifier的gas开销大约是每个验证0.46以太币（每个证明平均需要38以太币的交易费来完成验证，数据来源：Etherscan）
对于SHARP的批处理大小而言，StarkWare的批处理大小取决于发送的交易数（每批大约有9万笔交易），而StarkNet的平均交易数低于800，且大多数来源于Immutable
与无rollup的应用相比，尽管无rollup可以更节约gas开销，大约是100倍的关系，不过这里没考虑Prover计算开销，仅考虑验证的gas开销（具体可以看StarkWare的Medium），有经验的Cairo开发者可以对StarkEx的客户端进行优化以减少gas开销
StarkEx声称其为dYdX节约了500至1000倍的gas开销和mass-NFT-minting大约两万倍的gas开销，但是不太清楚此类节约gas的方式是否会对其延迟有影响
对于安全性而言，SHARP声称其采SNARK的安全级别为80比特，但是当其运行FRI时，假设部分侵略性行为成立，此时的安全级别仅为48比特，最终得到的多项式承诺的安全性仅为22比特
此时如果希望将安全级别提高32比特，可以让Prover解决一个32比特的PoW难题，此时Prover需要解决$2^b$个不同的PoW难题才能以$2^{-48+b}$的概率伪造一个证明，此时Prover计算$2^{64}$次Hash可以将成功率提高至$2^{-16}$，$2^{80}$次Hash可以以几乎1的概率伪造一个证明
需要考虑攻击成本，2018年的算力在AWS上计算$2^{64}$次SHA1的成本大约为100万刀，理论上来说只需要伪造一个证明就可以偷取Layer 2的所有证明
安全性低的原因在于SHARP的Verifier只执行了12次FRI请求（越少的请求意味着更短的证明长度和更快的验证，但是没用，Prover该慢还是慢），此外，基于SHARP的rollup也为了节约gas开销设置了特殊的安全性（128比特的安全性的证明大小和Verifier开销会翻倍，若是已证明的128比特，这两个开销则会增加4至5倍）
其他小知识
目前所有的后量子SNARK（PQ-SNARK）的证明大小远大于非后量子的SNARK，且由于证明大小与安全参数呈线性关系，这意味着StarkWare需要在抗量子和gas开销之间做权衡
此外，想要充分利用rollup的优势，必须进一步优化Prover的计算效率，由于不是所有的场景都可以容忍8小时的延迟，越快的Prover意味着相同延迟内可以处理更多的交易数量，从而可以更好的均摊gas开销，Prover效率可以通过硬件优化的方式来提高Prover的效率，但是也要钱呀
有一个小项目：zkSync 1.0，访问网址即可zkscan
References
$[1]$ SNARK Design, Part I, with Justin Thaler | a16z crypto research talks
$[2]$ SNARK Design, Part II, with Justin Thaler | a16z crypto research talks
$[3]$ SNARK Design Part III with Justin Thaler | a16z crypto research talks