OPT:第二代 Optimistic Rollup 有何特征？_TIMI

?为什么还需要看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宇宙版图中的重头戏.

第二代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:作为dl引擎.将Geth作为dl执行引擎,而非库处理.好处就是可以完全重用之前的基础设施,同时可以无缝切换到其他执行客户端.

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且与用户和应用开发者无关,因此大家可以自行观看.

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依旧会是整个系统中的重要基石.

标签：OPTTIMIPTITIMOPTC币TimicoinReptilianOptimus OPT3

世界币热门资讯