以太坊 layer2: optimism 源码学习 (一)
作者:林冠宏 / 指尖下的幽灵。转载者,请: 务必标明出处。
GitHub : https://github.com/af913337456/
出版的书籍:
前序:
对于区块链每个阶段的风口产品,我都会挑选其中某个研究其源码,当作学习并增加经验。早前看的是
zkSync
,难度巨大而能力有限,遂转于Optimism
。
本次是系列文章,这是第一篇。
这里就不说什么是 Layer2 了,可以去网络搜索其它文章来阅读。在 Layer2 的扩容方案中目前有 3 种,Rollups
是其中一种,称为打包
。打包又分两大派别:
- 乐观打包,Optimistic rollups;
- 零知识打包, ZK rollups。;
这两派的风格各异,特点突出。Optimistic rollups
对智能合约
的支持可以说是完全兼容,而 ZK rollups
目前对智能合约支持不友好,但是在交易提款
上链这块非常快、更安全却计算量巨大,技术难度复杂。关于它们的对比
,我后续再写篇文章详细说说
目录:
- Op 简介
- Op 的程序组件
- 如何使用 Op
- 源码分析 --- 充值与提现
- L1 合约层源码
- L2 层源码
- 提现
1. 正题,Op 简介
Layer2 是公链下的第二层。比如安卓系统下的底层软件。
Optimism,下面简称 Op,是基于 Optimistic rollups
方案所实现的 Layer2 应用,下面简称 L2。作用是帮助 以太坊
扩容以及加速交易。
特点如下:
- 提款到 Layer1 的周期,约一周。下面简称 L1;
- 速度,L2 内交易,极快,手续费很低;
- 通用性,EVM 兼容,基于以太坊的修改
- 技术复杂度,简单;
- 链下成本,低。链上成本,高;
- 交易安全保证,基于默克尔树--树根哈希的
欺诈证明
; - 源码:https://github.com/ethereum-optimism/optimism
2. Op 的程序组件
虽说 Op 是个 L2 应用,但它的组成程序组件非常多。我这里列出会和我本文内容相关的组件:
合约
,这些会被部署在 L1 公链上面,由 L2 组件或用户来调用,包含不限于有:L2 侧链
,基于 geth 源码改造的链,运行在 Op 生态里;L1StandardBridge.sol
垮链桥合约,用来处理充值 Token 到 Op 地址或从 Op 地址提现到 L1 地址 所用;CanonicalTransactionChain.sol
规范处理L2 --> L1
的交易,下面简称CTC
;L1CrossDomainMessenger.sol
跨链信使合约,里面主要编写进行了各种要触发跨链事件的函数。
DataTransportLayer
,定时扫描 L1 区块,从中获取到TransactionEnqueued
事件,并存储到LevelDB
数据库;Sequencer
:- 接受用户发来 L2 的交易;
- 定期从数据库中获取
DataTransportLayer
存储的TransactionEnqueued
事件数据,并把交易在 L2 链中执行,使之正常被打包到 L2 区块中;
Batch-Submitter
,定期从 L2 区块中将交易数据以打包的形式组装到交易:- 打包批量交易
txBatch
提交到 L1 的CTC
合约; - 打包批量状态
stateBatch
提交到 L1 的StateCommitmentChain.sol
- 之后这些交易进入
等待挑战
窗口,挑战方式就是欺诈证明
;
- 打包批量交易
Relayer
,定时从 L2 区块中过滤交易中的SentMessage
事件数据:- 判断当前交易是否过了挑战时间;
- 为此交易生成证明,调用 L1 上的
L1CrossDomainMessenger.relayMessage
函数,使之完成合约检查
然后在内部调用目标合约,最终在 L1 完成 L2 交易的最终目的;
它们的组合通讯流程图如下:
注:
目前所有的 Op 组建,都由官方运行着,欺诈证明还在完善。用户必须要相信官方不会做恶。
3. 如何使用 Op
使用 Op 网络分两种情况:
- 直接使用原生 Token 进行交易,即以太坊,那么:
- 需要先在 L1 访问
L1StandardBridge.sol
进行充值到 Op; - 充值结束后,到账了,可以进行 Op 网络内的交易活动;
- 提现到 L1 的地址;
- 流程到这里闭环
- 需要先在 L1 访问
- 其他协议,比如 ERC-20:
- 先去 Op 网络部署对应的合约;
- 在 L1 的
L1StandardBridge.sol
充值 Token 到 L2 地址; - 到账后,便可自由交易。提现动作和 ETH 的一样。
4. 源码分析 --- 充值与提现
充值部分 --- L1 合约层源码
按照流程,用户需要调用 L1 上的 L1StandardBridge.sol
智能合约充值,如下图所示:
注意,payable
就是 solidity 语法中标明可以接收 ETH 的语法糖。此时充值 ETH 到了 Op 的 L1StandardBridge 跨链桥合约中。
上图,函数走完了,都没有痕迹告诉我们如何在为 L2 的地址充值了 ETH,我们只需要留意其中的 IL2ERC20Bridge.finalizeDeposit.selector
这一行。这里设置了一个 L2 到时需要调用的函数。
上图,结合我们前面的结论 DataTransportLayer
,会定时扫描 L1 区块,从中获取到 TransactionEnqueued
事件,并存储到 LevelDB
数据库。
所以在 _sendXDomainMessag
内部,最终会触发 emit TransactionEnqueued
事件。L1 层面的闭环结束
ERC-20 的充值也是一样的,只是函数不一样。如下图:
// TransactionEnqueued 事件在 enqueue 内发生
function _sendXDomainMessage(
address _canonicalTransactionChain,
bytes memory _message,
uint256 _gasLimit
) internal {
// slither-disable-next-line reentrancy-events
ICanonicalTransactionChain(_canonicalTransactionChain).enqueue(
Lib_PredeployAddresses.L2_CROSS_DOMAIN_MESSENGER,
_gasLimit,
_message
);
}
充值部分 --- L2 层源码
在这里我们主要看 Sequencer
的是如何执行 TransactionEnqueued
中的交易到 L2 的。
在 Sequencer
的启动中,首先是它会进入一个定时从数据库中获取交易的函数,如下图所示:
接下来的调用链是: s.sequnece --> syncQueueToTip --> syncQueue --> syncQueneTransaction
如下图所示,在 syncQueneTransaction
中,调用 GetEnqueue
从远程接口即 DataTransportLayer
服务中获取目标交易数据。最后执行 applyTransaction
执行交易
回到前面合约层的 IL2ERC20Bridge.finalizeDeposit.selector
这一句,最后交易的执行会走到 L2 合约层的 L2ERC20Bridge
合约的 finalizeDeposit
函数,如下图所示,最终 mint 操作完成充值流程,至此闭环。
提现
内容比较多,提现留给下一篇。持续关注
我的“区块链”技术书籍:《区块链以太坊DApp开发实战》
、支付宝收款码 https://www.cnblogs.com/linguanh/gallery/825997.html
微信:https://www.cnblogs.com/linguanh/gallery/image/321906.html
银行卡:6217007200076746554 , 林冠宏