最近zkEVMRollup以及整个ZK生态的热度确实非常高(DevconBogota基本是ZK+MEV+其他),以至于大多数以太坊研究者或多或少忽视了OptimisticRollup的发展,以及在第二代中这些有趣的设计细节。
为什么还需要看OptimisticRollup?
a)OP还是ZK？
尽管Vitalik早在几年前就认定了zkEVMRollup是未来,同时各家zkEVM(Scroll,zkSync,Hermez,Consensys)也如雨后春笋一般冒出来,但OptimisticRollup仍是目前Rollup生态的绝对主力,拥有80%Layer2的市场占有率以及前十Layer2方案的半壁江山。
zkEVMRollup的终局性扩容方案的存在，会让OptimisticRollup完全被淘汰吗？
OptimisticRollup和zkEVMRollup并非水火不容的存在,而是在长期内(甚至永久性的时间内)会是互补的方案。
对于App-rollup来说,Optimistic机制在开发与部署上仍然是最简洁易用的方案。
b)OP和ZK未成熟
OptimisticRollup的开发进度领先zkEVMRollup两年左右。但我们OptimisticRollup的标杆Arbitrum与Optimism都没有在主网完全上线开放的正式版FraudProof。
据Vitalik所说,以太坊基金会PSE的zkEVM电路有34469行代码。这庞大的代码量需要非常漫长的开发和持续的测试来进行打磨。我们在几年内都无法完全依赖ZK系统所带来的安全性。
c)OP+ZK
早在半年以前，Optimism的Kelvin就开始在推特上频繁地讨论Optimism结合zkVM的可行性。
他说Optimism的Bedrock不会只是OptimisticRollup的客户端,而是Rollup客户端。为了完全保证Rollup的整体安全性,客户端(或许和Arbitrum最近的收购有关系?)与证明的多样性(ValidityProof与FraudProof)才是Rollup真正的未来。
Vitalik则完善了Kelvin的方案,认为可以通过(OP+ZK)+Governance的2+1组合来实现可靠的Rollup。
在zkEVM完全稳定和成熟前,工作流程如下:
发布区块
等待24小时
a)如果期间没有欺诈挑战,发布ZKP,完全Finalize区块。b)如果有挑战,则引入Governance通过2of3的模型来裁定最终结果。
在zkEVM稳定与成熟后:
发布区块
定期发布ZKP。
a)如果ZKP在指定期间正常发布,则依其为准。b)如果ZKP并未在期间正常发布(Proverfailure或有bug),则先引入Optimistic机制,直到ZK机制恢复。
这两种方案都需要Optimistic机制的存在,从而保证整个Rollup系统的liveness和safety。
因此Optimistic机制的发展仍然是Rollup宇宙版图中的重头戏。
1.第二代OptimisticRollup
第二代OptimisticRollup一词源于ArbitrumNitro的白皮书标题。略早与Nitro发布的OptimismBedrock也算是第二代OptimisticRollup。
两者的整体差异其实不大(如果你读Arbitrum和Optimism的blog,甚至会觉得是不是一样的),本质上都是与自己的一个新的majorrelease。第二代与第一代的差别也无外乎是如下优化:
开发者体验:更强的EVM等效性和兼容性,L1互操作性…
用户体验:更高的吞吐量,更低的gas…
但是在设计细节上仍然有取舍的不同,我们可以在这些差异上看到Arbitrum与Optimism在构建下一代OptimisticRollup上的推敲。
第二代OptimisticRollup设计选型对比
Arbitrum与Optimism的开发人员分别对两者的架构进行了比较和对比,这里我们就仅讨论与用户或应用开发者有关的点:
a)区块时间
区块时间设计的选择主要是两种:固定时间或者可变时间。可以理解成PoS和PoW的以太坊的区别。
Optimism:固定时间(2秒)
固定时间可以保证使用区块(block.number)来作为时间戳的合约的稳定性,比如Sushiswap的Masterchef合约。这些合约不用时间戳可能是考虑到矿工对时间戳有控制权(算是Selfishmining或者MEV？)。
第一代的Optimism采用了可变时间+1tx/block的设计,因此由于时间计算的问题,Stargate的奖励发放就出现了一些问题。
对于1tx/block的老设计,Optimism认为由于区块头的存在,存储链的开销太大了,除此之外状态根也需要频繁更新,成本过高。
Arbitrum:可变时间
可变时间设计主要是为了减小tx确认的延迟。目前一秒最多可以创建4个区块,如果没有tx则跳过,因此是可变时间。
对于以block。number进行计时的合约,Arbitrum上block。number会直接返回以太坊的区块编号,因此不会有稳定性和适配上的问题。除此之外Arbitrum也提供了相应的预编译来提供L2的区块编号。
b)Geth的定位
Geth是以太坊的执行客户端,占据了约80%的节点总量。
Optimism:作为独立引擎
将Geth作为独立执行引擎,而非库处理。好处就是可以完全重用之前的基础设施,同时可以无缝切换到其他执行客户端。
Arbitrum:作为库
由于Arbitrum有更多的L2特定状态,例如L1和L2的gas定价,以及retryableticket,因此将Geth作为库处理,使用hooks进行调用。
c)L1-L2消息inclusion延迟
Optimism:~2分钟
Bedrock的延迟是几个L1块的长度,最坏的情况是延迟十分钟。
Bedrock的架构更像一个L1,极端情况下可以通过reorg自己来应对L1的reorg。
超过10分钟没被L2包含的tx就直接被判定为无效了。
Arbitrum:10分钟
Nitro延迟十分钟处理,如果超过十分钟,可以通过L1调用来强制包含tx。
Nitro的目标是为了用户体验,让L2永远不需要reorg。
两者都是在不同角度对用户体验进行了取舍。
d)L1-L2消息重试机制
消息重试机制主要就是为了解决L1-L2跨链过程中,L1确认了,L2失败的问题。
Optimism:合约中实现
开发者可以参考L1OptimismPortal的实现,或者在合约内定义自己的重试机制。
Arbitrum:节点中实现
重试机制在ArbOS节点中实现。
e)L2费用算法
L2的gas计算基本上就是L2executiongas+L1calldatacost。
Optimism:重用EIP-1559
好处就是钱包和其他基础设施可以无缝接入。
Optimism对L2gas的计算基本上是将L2executiongas的成本压到了最低(99%都是calldatacost)。
Arbitrum:使用定制系统
由于之前提到的可变区块时间设计,因此gas定价更加复杂,所以没有采用EIP-1559。
f)L1费用算法
Optimism:
L1gas水平到L2的传输几乎是即时的。目前Sequencer的收益基本完全来源于L1gas费用的乘数,EIP-4844后,它们的收入会来自MEV。
未来会通过L1-L2的消息传递来传输这部分数据,从而保证安全性(成为协议一部分,且可被挑战)。
Arbitrum:
Arbitrum的L1费用算法通过L1gas的平均值来收取费用,且通过自己的控制系统来从实际支付的费用中来获取反馈,从而保证L1gas收取和支出的稳定。
整体策略中也包括,为了避免Sequencer过度收费,因此在gas价格低时才发布batch。
除此之外,两者也探讨了很多具体架构和技术细节上的区别,但内容过于domain-specific且与用户和应用开发者无关,因此大家可以自行观看。
3.Rollup的未来依然是Optimistic的
最近zkEVMRollup以及整个ZK生态的热度确实非常高(DevconBogota基本是ZK+MEV+其他),以至于大多数以太坊研究者或多或少忽视了OptimisticRollup的发展,以及在第二代中这些有趣的设计细节。
Optimistic作为Rollup的领头部队,正在L2UX和DX上进行试验性的开拓和开创性的创新。它们所做的可以为zkEVMRollup铺好地基。
在未来两到三年,甚至更长的时间内,zkEVMRollup完全可用之前,Rollup的主导地位仍会是由Optimistic占据,且80%的新Rollup(App-rollup)则会采用更为成熟和可用的Optimistic机制。
即使是在长期zkEVMRollup成熟后,为了Rollup的整体liveness和safety,Optimistic依旧会是整个系统中的重要基石。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。