详解 OP Stack Rollup 流程及对应代码

Optimism Bedrock 是 OP Stack 的当前版本。Bedrock 版本提供了用于启动生产质量的 Optimistic Rollup 区块链的工具。此时，OP Stack 不同层的 API 仍然与 Stack 的 Rollup 配置紧密耦合。

Op-stack 主要的 rollup 由两个服务来承担。

• op-batcher：负责将每隔一段时间读取 sequencer 上的交易内容，rollup 到链上 DA
• op-proposer：负责将交易状态 rollup 到合约。

Rollup 架构

op-batcher

op-batcher 执行流程图

loadBlocksInfoState 执行逻辑

loadBlocksInfoState 负责读取，从前一次读取的块开始的所有块，即还未读取的块。

其整体流程如下

代码如下：

loadBlocksIntoState 完成了以下动作

1、获取 sequencer 中的同步状态

2、153 行，调用calculateL2BlockRangeToStore函数

• calculateL2BlockRangeToStore 获取并判断需要提交的最新 L2 的 start 和 end 块号，起始的区块为 L2 当前安全的最高块，结束区块为 L2 当前最高的不安全的区块。

3、164 行,拿到提交的开始块和结束区块之后，从起始区块开始获取区块信息，调用loadBlockIntoState 函数获取区块

• loadBlockIntoState 检查区块信息以及 geth 信息，无误后，在 200 行,调用 AddL2Block 函数将区块加到 channelManager 的 blocks []*types.Block 中。

4、165 行至 168 行，校验区块是否需要重新提交，若需要，将 l.lastStoredBlock 置成 eth.BlockID{}；173 行，否则就将 l.lastStoredBlock 置成 eth.ToBlockID(block)；latestBlock 置成 block；

5、177 行，L2BlockToBlockRef 从 L2 块引用源中提取基本的 L2BlockRef 信息，根据区块号判断必要时回退到创世信息

publishStateToL1 执行逻辑

publishStateToL1 将队列中的所有交易提交到 L1，直到队列中没有交易或者出现错误为止。

代码如下：

1、publishStateToL1 会循环将队列里的交易发送到 Layer1 网络。

2、377 行调用publishTxToL1。

publishTxToL1 是提交单个交易到 L1 的逻辑，publishTxToL1 方法获取要提交的数据数据构建交易发送到 Layer1 网络，并将发送出去的交易扔到 receiptCh chan TxReceipt[T] channel 里面。

关于【详解 OP Stack Rollup 流程及对应代码】的延伸阅读

• 长推：复盘精彩刺激的 $RCH 大战

  昨晚，$RCH与BTW进行了精彩的大战，项目方上线了产品并给LP添加了700ETH，但被聪明钱抢跑。随后，神盘出现，币价从0.2上涨到1u。项目方背景强大，有大机构背书，链上交易活跃。Sofa.org推出了两个产品，Earn和Surge，用户可以利用期权策略进行理财和预测未来走势。产品实力强大，能力超过web3团队。

• 长推：$RCH 能不能到20亿？无预留、无权限、燃烧通缩、上所才是起点

  $RCH是新兴项目，初始加入池子的ETH价值300万，现市值7000万。若跌回1块，市值为2000万，上限无法预测。项目方烧了750ETH，加其他支出，合计400万。预计市值达15M，产品和资方有潜力，交易量高，无VC抛压和项目方币。预计上市后，市值5亿-40亿。

1. 429 行，l1Tip：获取当前 L1 提示作为 L1BlockRef。假定传递的上下文是生命周期上下文，因此它在内部使用网络超时进行包装。
2. 434 行，recordL1Tip：将上一个 L1BlockRef 更换成 l1Tip 获取到的最新的 L1BlockRef
3. 437 行，TxData：收集需要 rollup 的交易数据；TxData 返回应提交给 L1 的下一个 tx 数据。目前，每个事务仅使用一帧。如果待处理的通道已满，则仅返回该通道的剩余帧，直到成功完全发送到 L1。如果没有挂起的帧，它将返回 io.EOF。
4. 447 行，sendTransaction 将交易发送到一层，并把交易发送状态更新到 receiptCh chan TxReceipt[T] channel 里面；sendTransaction 使用给定的「数据」创建交易并将其提交到批处理收件箱地址。它目前使用底层的「txmgr」来处理交易发送和价格管理。这是一种阻塞方法。不应同时调用它。

handleReceipt

handleReceipt 获取从 channel 处理交易的状态，并将成功处理的交易从 channel 里面移除。

代码如下：

op-proposer

执行流程图

详细执行流程

FetchNextOutputInfo

FetchNextOutputInfo: 获取 L2 上的区块的 output，方便后续组装提交。返回的 output 结构如下：

type OutputResponse struct {Version               Bytes32     json:"version"OutputRoot            Bytes32     json:"outputRoot"BlockRef              L2BlockRef  json:"blockRef"WithdrawalStorageRoot common.Hash json:"withdrawalStorageRoot"StateRoot             common.Hash json:"stateRoot"Status                *SyncStatus json:"syncStatus"}

代码如下：

1. 224 行，NextBlockNumber：获取下一批次需要提交的区块区间，区间计算为 latestBlockNumber() + SUBMISSION_INTERVAL SUBMISSION_INTERVAL 的值可以在部署 L2OutputOracle 合约的时候指定。
2. 230 行，调用FetchCurrentBlockNumber，获得当前区块的区块号
3. 236 行至 241 行, 上面检查完 nextCheckpointBlock 符合规则之后，调用FetchOutput去 L2 上获取需要提交的 stateRoot

FetchCurrentBlockNumber 代码如下：

1、254 行，SyncStatus：获取 L2 块的 SafeL2 和 FinalizedL2 的状态和块信息，

FetchOutput 代码如下：

2、279 行，OutputAtBlock: 根据块高获取 output, 里面包含 stateRoot，这里最终是调用 eth_getProof 去计算并获取 stateRoot，代码调用流程可以参考上图。提示: 这里并不是一个块提交一次 stateRoot, 而是根据 SUBMISSION_INTERVAL 配置的值来计算一批块的 stateRoot，最终将 stateRoot 提交到 L2OutputOracle 合约

send Transaction

• sendTransaction：使用 output 构建 stateRoot 提交交易，将交易提交到一层链， 下面是交易打包的数据细节

return abi.Pack(    "proposeL2Output",    output.OutputRoot,    new(big.Int).SetUint64(output.BlockRef.Number),    output.Status.CurrentL1.Hash,    new(big.Int).SetUint64(output.Status.CurrentL1.Number))

代码如下：

免责声明：本文仅代表作者个人观点，不代表链观CHAINLOOK立场，不承担法律责任。文章及观点也不构成投资意见。请用户理性看待市场风险，以及遵守所在国家和地区的相关法律法规。
图文来源：Rayer，如有侵权请联系删除。转载或引用请注明文章出处！

标签：ETHOptimismRollup代码