以太坊:L2 扩容技术详解:Optimistic Rollups 与 ZK Rollups_Pudgy Pups Club

$ARB即将上线,L2也得到了更多重视,最近关于OP和ZK两种解决方案孰优孰劣的争论越来越多,有人说OP是正统,有人说ZK更安全,本文将深入探讨两种流行的二层扩容方案,以及最近备受瞩目的Arbitrum。这是一篇技术导向性的文章,我将重点阐述它们的工作原理和特点,并用通俗易懂的语言进行讲解,以帮助大家更好地理解和评估这些扩容方案。

1.扩容方案概述

随着区块链技术的快速发展,可扩展性问题成为了阻碍区块链广泛应用的主要障碍之一。为了提高网络的吞吐量和降低交易费用,扩容就是一件必须要解决的事情。扩容方案通常分为两大类:一类是链下扩容,通过在底层区块链之上构建新的协议层来实现扩容;另一类是链上扩容,通过优化底层区块链协议本身来提高吞吐量。

链上扩容方案可以分为分片、选择更高效的共识算法和协议优化等。其中分片是将区块链网络分割成多个相互独立的子链,每个子链可以并行处理交易。这样,整个网络的吞吐量会随着子链数量的增加而线性增长,分片也是以太坊2.0路线图中关键的一步,分片之后TPS和Gas才能得到真正的优化。最近这几年共识算法的创新很少见了,像之前提出的POS、DPOS、DAG等都是相对于POW的创新,相比于POW,它们可以减少网络资源消耗,提高交易处理速度,同样,以太坊也选择了这条路。第三个方案是对底层区块链协议进行优化,例如调整区块大小、区块产生时间等,可以在一定程度上提高网络的吞吐量,比如比特币的隔离见证升级。

链游专用L2 Paima现已上线Cardano网络:4月4日,据官方消息,区块链游戏专用二层网络 Paima 现已上线 Cardano 网络,支持将构建在其他网络上的区块链游戏迁移至 Cardano。Paima 表示,网络上的所有游戏都是非托管的,资金保留在用户钱包中,不必转移到游戏钱包中。[2023/4/4 13:44:16]

链下扩容方案可以分为状态通道、Plasma和Rollups。状态通道允许用户在链下进行交易,仅在通道开启和关闭时与主链进行交互,这极大地减少了链上交易数量,从而提高了吞吐量,像RaidenNetwork和LightningNetwork就是分别针对以太坊和比特币的状态通道扩容产品。Plasma是一种子链方案,允许用户将资产从主链迁移到子链,并在子链上进行交易,子链周期性地将其状态更新提交给主链,以确保安全性,比如OMGNetwork。Rollups是将多笔交易打包成单个证明,并提交到主链。这样,主链仅需验证证明而无需处理每笔交易,从而提高了吞吐量。典例是zkSync和Optimism,Arbitrum同样也是基于OP的产品。

以太坊L2 NFT平台Mint Square上线StarkNet主网:8月3日消息,以太坊L2 NFT平台Mint Square宣布上线StarkNet主网。用户可通过Argent X钱包和Braavos钱包登录平台,并进行NFT铸造。[2022/8/3 2:55:24]

2.OptimisticRollups和zk-Rollups

2.1zk-Rollups

zk-Rollups是一种基于零知识证明的二层扩容方案。首先由RollupOperator组件将多个链下交易聚合成一个批次,之后使用零知识证明生成一个简洁的证明文件,这个证明可以验证整个批次的交易的有效性,而不需要逐一检查每笔交易;然后将证明及与该批次相关的数据提交到主链,主链通过验证证明的正确性,确保交易是有效的;主链验证通过后,链上合约会根据证明中的数据更新链上的状态。这意味着,尽管交易是在链下进行的,但链上状态仍然得到了更新,确保了数据的一致性。

以太坊L2 NFT平台Mint Square宣布集成zkSync网络:4月7日消息,以太坊L2NFT平台Mint Square宣布集成zkSync网络,现已发布测试版。测试版现包含NFT铸造和交易功能。[2022/4/7 14:09:33]

注:零知识证明是一种密码学概念,它允许一个证明者向验证者证明某个陈述为真,而无需透露任何关于该陈述的其他信息。简而言之,零知识证明可以让一个人证明他拥有某种信息,而不需要透露这个信息本身。

2.2OptimisticRollups

OptimisticRollups是一种基于乐观性验证的二层扩容方案,即默认提交的区块是正确的,除非有人提出质疑。它同样需要RollupOperator将许多链下交易聚合成一个批次,之后计算批次交易产生的新状态并生成一份链下状态更新;然后将链下状态更新、相关数据提交到主链,这个状态默认是正确的,不需要额外验证;但是在状态更新提交后,会有一个固定的挑战期,在此期间,任何人都可以通过提供欺诈证明来质疑提交的状态更新的有效性,与被质疑状态的相关的整个交易将通过EVM运行检验,如果证明状态更新是错误的,提交者会被惩罚,同时链上状态会回滚到正确的状态;如果在挑战期内没有人质疑状态更新,或者质疑被证明是错误的,那么链上状态会根据提交的状态更新进行更新。

路印协议已于L2 AMM启动ETH-USDC池:1月14日,路印协议Loopring官方宣布,L2 AMM上的ETH-USDC池已经启动。[2021/1/14 16:09:26]

2.3ZK与OP比较

ZK和OP各有各的特点,我从下面5个不同角度对他们进行了分析,以供各位根据自己的倾向去评判:?

1.交易验证方式:

OP:通过欺诈证明验证交易。OP假设交易默认是有效的,除非有人提交证据证明某笔交易无效。这需要链下用户和节点持续监测,以确保RollupOperator没有作恶。

ZK:通过零知识证明验证交易。ZK生成一个简洁的证明来确保批次中的交易有效性,无需逐一检查每笔交易。

2.安全性:

OP:由于默认假设交易有效,可能存在一定的安全风险,需要链下用户和节点积极监测交易以确保安全性。

ZK:基于零知识证明的验证方式为ZK提供了较高的安全性,因为它需要生成一个证明来确保交易的有效性。

Shapeshift创始人:在某种类型的L2 ETH上锚定BTC会更合适:8月25日,推特网友分享数据称:现在以太坊上锚定比特币的数量比闪电网络(Lightning)多40倍。经过2年多,闪电网络仍未能整合、创新和被采用。数字资产交易平台Shapeshift创始人兼首席执行官Erik Voorhees对此表示,这是一个有趣的统计数据,但是以太坊上的比特币仍然需要支付昂贵的tx费用,而在Lightning中则没有。以太坊基础层上的比特币并不能与闪电网络相提并论。在某种类型的L2 ETH上锚定BTC会更合适。[2020/8/25]

3.吞吐量与性能:

OP:与ZK相比,OP通常具有较快的链下交易处理速度,但链上验证可能需要更长时间,因为需要等待欺诈证明的挑战周期。

ZK:虽然生成零知识证明需要一定的计算资源,但ZK的链上验证速度较快,因为一旦证明生成,主链就可以快速验证。

4.通用性

OP:OP完全兼容EVM,众多DAPP可以直接迁移,方案整体的计算复杂度低,更适用于通用的智能合约执行和复杂计算。

ZK:虽然零知识证明技术在发展中,但目前它在通用智能合约和复杂计算方面的应用受到一定限制。

5.成本:

OP:通常具有较低的链下交易成本。

ZK:生成零知识证明需要一定的计算资源,可能导致较高的链下交易成本。

总的来说,OptimisticRollups和zk-Rollups分别具有各自的优缺点,OptimisticRollups更适合处理复杂的智能合约场景,具有较好的以太坊兼容性;而zk-Rollups在安全性和隐私保护方面具有优势。

3.Arbitrum

Arbitrum是一种基于OptimisticRollups的二层扩容解决方案,它结合了OptimisticRollups的优势,并对仲裁过程进行了创新和优化,在处理质疑和仲裁时采用了二分查找技术,降低了仲裁过程的复杂性和成本。

在上文提到在乐观性验证系统中,当有人对某个提交的区块提出质疑时,就要启动仲裁过程。质疑者需要指出区块中存在的一个具体错误,例如交易执行的结果不正确、状态更新错误等。

为了高效地找到错误的位置,二分查找将错误可能出现的范围分为两半,质疑者需要选择错误出现在哪一半,并继续向下查找。例如,如果质疑者认为错误出现在区块的前半部分,那么他们需要提供该部分的状态更新证明;在每次迭代中,质疑者和验证者将错误可能出现的范围继续分为两半,质疑者需要在每次迭代中指出错误出现在哪一半,并提供相应的证明,验证者则需要提供相应的反驳证据;通过不断的二分查找迭代,质疑者和验证者将错误可能出现的范围逐渐缩小;最终,当范围缩小到一个具体的交易或状态更新时,质疑者需要提供详细的证据来证明错误的存在,验证者则需要提供相应的反驳证据;经过一系列的二分查找迭代和证据交换,如果质疑者能够成功证明区块中存在错误,那么区块将被认定为无效,如果验证者能够成功反驳质疑者的证据,那么区块将被认定为有效。在这个过程中,错误的一方将损失押金,而胜利的一方可能会获得奖励。

综上所述,二分查找仲裁可以缩小错误范围,这个过程在链下执行,而链上只需要验证最后的争议部分,从而减少了链上的交易处理成本,但是这个过程也延长了处理时间,所以在发生仲裁的情况下Arbitrum比Optimistic更便宜,但也更慢。

4.总结

很多同一赛道的竞争对手都呈现一者重技术,一者重生态的格局,OP和ZK有些像Aptos和SUI,最后哪家胜利就看用户的投票了。

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

区块博客

[0:0ms0-5:726ms