ROL:干货 | 技术比较:Optimistic Rollup vs. ZK Rollup(Part-1)

作者:?AlexGluchowski

翻译:?阿剑

编者注:原标题为《干货|OptimisticRollupvs.ZKRollup:一探究竟,Part-1》

声明:本文的作者自ZK-Rollup的概念形成以来就一直在开发ZK-Rollup,因此不可避免会带有一些偏见。不过,我的经验也让我很适合从技术的角度深入分析和比较这两种解决方案。

摘要

OptimisticRollup是一种近期提出的、旨在扩展以太坊上智能合约通用性吞吐量的技术。如果开发相对较快的话,它就可以为迁移现有的dApp和服务提供一种简单的方案,而且为此付出的安全性/可扩展性牺牲也不会太大。它能帮助Eth1.0适应不断增长的需求。

而ZKRollup是一种更复杂的技术。今时今日它可以用于代币转移和定制化的应用。不过,真要用它来实现通用性智能合约,就需要更长时间,甚至需要更多研究工作来把EVM高效封装进零知识证明。不过好事情是,一旦ZKRollup开发完成,现在所有的以太坊dApp和服务都可以平滑迁移到ZKRollup上,无需花太多力气。

ZKRollup可以解决OptimisticRollup上的几个根本问题:

消除了令人厌恶的尾部风险:通过复杂但可行的攻击方法从OR中盗取资金

将提取资金的时间从1-2周缩减到几分钟

支持快速的交易确认和退出,而且体量几无上限

默认保护隐私

对ZKRollup来说,OptimisticRollup的出现是个好消息。迁移到Layer-2扩展方案上需要对钱包、预言机、dApp和用户习惯的巨大变更。OptimisticRollup可以帮助整个生态为这样的迁移作好准备,并为那些当前还没有办法构建到ZKRollup之上的应用提供了扩展途径。这就给了ZKRollup时间来成长、使ZKRollup的普及可以尽可能顺利,同时保持以太坊的增长势头。

Rollup101

什么是Rollup?

Rollup是一种类似于Plasma的Layer-2扩展方案:用主链上的单个合约来保管所有的资金,并保存一条指向“侧链”状态的简洁密码学承诺。侧链的状态是由用户以及链下运营者来维护的,不会占用Layer-1的存储空间。

Rollup与Plasma有所不同的是,Plasma会面临交易数据可用性的问题。而Rollup则通过在Layer-1网络上为每一笔交易公开一些数据解决了这个问题。因此,几千笔交易可以被打包到一个Rollup区块中。虽然这种方法的开销是O(n),也就是说它的开销会随着交易数量的增加而严格线性增长,但它也提供了实用的100倍吞吐量提升,因为CALLDATA的开销要比Layer-1的存储和计算便宜很多。

Rollup也一再被VitalikButerin认可为他最喜欢的Layer-2扩展方案。

根据状态转换有效性的保证方式不同,可区分出来两种Rollup方案:ZKRollup以及OptimisticRollup。两种方案的简史在?此文?中有清晰的阐释。

什么是ZK-Rollup?

在一个ZK-Rollup系统中,运营者必须为每一次状态转换提供一个简洁的零知识证明;该证明将由主链上的Rollup合约来验证。这样的一个SNARK证明了存在一些交易,这些交易是由发起人正确签名过的,并且正确地更新了相关账户的余额,并使旧的默克尔根值变为代表新状态的新值。这就杜绝了运营者提交无效状态或篡改状态的可能。

可以在EthResearch论坛?和MattLabs博文?处找到更多技术细节。你也可以尝试一下MatterLabs用于ERC-20代币转账的ZKRollup在线demo。

什么是OptimisticRollup?

在一个OptimisticRollup系统中,运营者发布新的状态根时无需每次都接受Rollup智能合约的检验。相反,每个人都假设状态转换是正确的。不过。如果有人发布了一次不正确的状态转换,其它运营者或者用户都可以指出不合法的交易并回滚不正确的区块、惩罚恶意验证者。

OR的理念是由JohnAdler首先构想出来的。读者可以在这篇OptimisticRollupAMA中发现更多细节。向PlasmaGroup的伟大成果致敬!

开始比较吧!

灵活性:通用性计算

OptimisticRollup

虽然OR可以用于专用性计算,PlasmaGroup最重要的创举其实是OVM:Optimistic虚拟机。OVM可以支持任意智能合约逻辑的实现。几乎所有在以太坊上可以执行的计算都可以在OVM上执行,包括智能合约的可组合性。它也可以给予EVM、EWASM或任何其它虚拟机。

OVM的一大长处是,如果与EVM搭配使用,大家就可以用Solidity来写码。因此,大部分现有的代码库都可以轻松移植到OR上。

如果OVM能直接重用现有的EVM字节码的话是最理想的,但可能没有那么简单。一个合适的实现应该要改变交易数据格式,还需要一个类似于Truebit/PlasmaLeap的复杂挑战/响应协议来接收错误性证明,这就很有可能导致与EVM的区别,否则便不能处理极端情况。这也意味着,要让现有的合约能适应OVM,还有一些工作要做。

另一个实现上的难点来源于一个事实:对大型区块的错误性证明所要求的Gas可能会大于Layer-1区块的Gas上限。那么这些错误性证明就必须被打散为多条ETH交易。

ZKRollup

迄今为止,所有ZK-Rollup现有的实现都只支持专用性操作比如代币转移或者原子化互换。这里面有几个原因。第一,现在还没有技术能够高效地实现不同零知识证明方案的简洁递归证明合成,但是想在一个区块内对不同智能合约做聚合执行又必然需要这样的技术。我们现在最好的方案就是椭圆曲线循环运算?加上Groth16,它需要对长字段进行运算,在用于大型计算时是完全没有效率的。

第二,即便我们有了更短的字段,Groth16也需要一个受信任初始设置流程,而且每个智能合约、每个新版本都需要独立的一个!显然,这绝对是不现实的。我们现在只有一种不需要受信任初始设置的高效零知识证明方案,就是基于FRI的STARKs,但是其中验证者仅对一小部分问题类型才是简洁的。一个STARK验证者必须执行被证明的计算语句的所有约束至少一次,这就意味着我们不能对一组异构的智能合约进行迭代运算。

不过所有这一切都会在SNORKs到来之后改变,这是一种新一代的零知识证明方案,它背后的密码学原语与前辈们的稍有不同——最值得注意的是多项式承诺方案。这一技术是由SeanBowe提出的,一开始命名为?Sonic;2019年夏天,代号为?PLONK?和?Marlin?的技术继承了这条路线。这几种技术都有一个共同特点:虽然整个方案仍然需要受信任初始设置,但这时候的初始设置是普遍性的且可升级的,只要做一次,就可以被任意数量的不同项目随时重用。

不过,这些证明系统所用的Kate多项式承诺方案,仍然需要高效的椭圆曲线循环运算来进行递归,这个高效运算现在还不能实现。这就是为什么我们对一些最新的、完全简洁且透明的证明系统,,例如Halo、SuperSonic、Fractal以及一些MatterLabs团队正在开发的新东西,感到非常兴奋的原因。长话短说:在ZKP上构建通用性智能合约系统的障碍在最近已被消除。ZKRollup完全可以支持像EVM一样的编程模式。第一批合约可能会要求定制化的DSL,虽然对于Solidity开发者来说,学习时间不会超过1天。最终来看,如果ZKP证明者技术维持当前的进步速率,我们可以预期所有现有的以太坊合约都可以轻松、高效地迁移。

可扩展性&交易费用

OptimisticRollup

根据JohnAdler的说法,当前的估计是在EIP2028/伊斯坦布尔升级激活之后,可以达到每笔交易只需4kgas

换算一下,TPS可上升到约100

有了BLS签名聚合技术之后,TPS可以上升到约500

如果愿意打破EVM的兼容性,理论上的吞吐量可以直逼ZKR的上限

现实的吞吐量估计:

500TPS。

对现在来说可能也蛮够用了。

ZKRollup

当前,在Matter测试网上,每笔转账交易的公开数据成本是16字节;在EIP2028/伊斯坦布尔升级激活之后,每笔交易要消耗272gas

此外,还有一个需要平摊的证明成本,当前的估计是300kgas

即便我们估计最坏的情况,需要付出100万gas的证明成本,预计天花板也是2140TPS

在一些讨论中,我听到有人提出ZKP包括了大量的计算开销,因此是非常昂贵的。实际上,相比起Gas的生产费用,计算开销是微不足道的;因为Gas的生产要兼顾抗审查性、去中心化,它的数量才是真正的瓶颈。我们也预计,这个负面因素的影响会大幅减弱。

现实的吞吐量估计:

超过2000TPS——就快赶上Visa了。

不过,对于大部分应用场景来说,ZKRollup都能提供更大的开销节约力度,因为可以免去在公开数据中存储较大的数据块,只要这些数据不是重建状态转换delta所必需的就好。这里的核心观念是这样的:虽然OR总是需要用户发布完整的交易输入,在ZK中我们可以有所选择:1)发布交易输入,删去不影响状态转换的见证数据;或者2)只发布交易输出。这样的选择可以相当优雅地实现,无需引入多少复杂性。

重要例子:

在多签名钱包、类似Argent的账户抽象型钱包或者去中心化交易所中,用户需要提交签名,以供合约验证。这些签名对状态更新也没有用,所以也可以从公开数据中省去。

像Gnosis的Dfusiondutch去中心化交易所这样的合约需要大量的数据集输入,这些数据集不会直接影响存储,只用来验证计算结果。

ETH2.0实现以后因为Rollup都会驻留在单个分片中,所以CALLDATA的成本应该不会有太大改变。除非带宽整体变得更加便宜。

郑重声明: 本文版权归原作者所有, 转载文章仅为传播更多信息之目的, 如作者信息标记有误, 请第一时间联系我们修改或删除, 多谢。

链链资讯

[0:0ms0-2:489ms