一文读懂OpStack最新的RollUp代码流程

一.概述

op-stack 的 rollup 模块由两个核心组件组成，一个是 op-batcher, 另一个是 op-proposer; op-batcher 将数据 rollup 到 EIP4844 或者以太坊交易的 CallData 里面；op-proposer 将批次交易的状态根提交到 DisputeGameFactory 并创建一个争议游戏，以供后续的欺诈证明进行欺诈证明处理。

1.rollup 架构图

op-batcher 负责将 L2 批次数据提交到 L1，根据 手续费消耗 选择最优提交方式：

采用tx calldata(交易调用数据)方式写入L1（一般成本较高，但简单，当网络交易量少的时候，可能手续费低于Eip4844）。

采用EIP-4844（blob 交易）将L1作为DA 层（一般成本会更低）。

op-alt-da 提供第三方 DA 支持：

数据可以提交到 Celestia / EigenDA等DA层。

最终生成 DA commitment（数据提交承诺）提交到 DataAvailabilityChallenge 合约，保证 L2 数据可用性和可以恢复性。

L2 状态提交到 L1：

op-proposer 负责提交 stateroot（状态根）到DisputeGameFactory合约，用于 L1 记录 L2 状态的最终结果。

DisputeGameFactory 处理 欺诈挑战，在挑战期内，任何人可以提交欺诈证明。

<!--StartFragment-->

♥️Batch 数据的压缩流程

♥️♥️获取到区块之后把区块赛到 l.channelMgr.AddL2Block(block) ---->s.blocks.Enqueue(block) , channelManager 的 Enqueue 里面

♥️♥️l.channelMgr.TxData(l1tip.ID()) 获取数据 frame 往一层 rollup

<!--EndFragment-->

<!--StartFragment-->

♥️交易的状态处理：Rollup 交易完成之后会将交易 receipt 放到 receiptsCh 里面

♥️♥️如果交易已经完成，那就将交易处理成 TxpoolBlocked

♥️♥️l.setTxPoolState(TxpoolGood, l.txpoolBlockedBlob)

♥️♥️handleReceipt 处理成功和失败交易，失败进行修剪之后，下次重新 rollup

<!--EndFragment-->

三.op-proposer 提交细节流程

1.StateRoot 提交代码架构

<!--StartFragment-->

状态根获取

op-proposer 通过 optimism_outputAtBlock 从 op-node 获取 L2 区块的状态根（state root），这个状态根表示 L2 在某个高度的全局状态哈希（类似 L1 以太坊区块的 stateRoot）。这里分为两种情况：

老版本没有欺诈的证明的是按照一定区块链间隔，将 stateroot 提交到 L2OutputOracle 合约，以方便 L2->L1 的提现验证；

新版本的提交到 DisputeGameFactory 处理欺诈争议，提交到 L1 的 L2 状态根并不会立即被视为最终确定（finalized），而是存在一个争议窗口期，任何人都可以在 争议窗口期（Challenge Period） 内提交欺诈证明（Fraud Proof），证明某个状态根是无效的。

争议解决流程

如果无人挑战：争议窗口结束后，状态根自动视为有效，L2 的状态更新被 L1 认可。

如果有人挑战：DisputeGameFactory 启动争议机制（可能是单步执行挑战机制）；如果挑战成功，该状态根将被撤销，并可能导致回滚 L2 状态；挑战失败则状态根继续有效，挑战者可能会被惩罚（罚没质押）。

<!--EndFragment-->

2.提交细节流程

<!--StartFragment-->

获取L2需要提交的状态数据（FetchL2OOOutput & FetchDGFOutput）。

调用 rollupClient.OutputAtBlock 处理L2状态数据通过 sendTransaction 提交到 L1，并选择进入L2OutputOracle 还是 DisputeGameFactory；老版本没有欺诈证明的提交到 L2OutputOracle；有欺诈证明的版本提交到DisputeGameFactory 合约。

四.本文小结

OpStack 的 Rollup 模块由op-batcher 和op-proposer 组成，分别负责 L2 交易数据的提交 和 L2 状态根的提交。

op-batcher负责将 L2 批次数据提交到 L1，并根据手续费消耗 选择最优方式，包括tx calldata（EIP-4844 blob 交易）或 第三方 DA（Celestia/EigenDA），最终生成 DA commitment 确保 L2 数据可恢复op-proposer 负责将L2状态根（StateRoot）提交到 L1，并接入DisputeGameFactory 处理欺诈挑战。新版本中，状态根不会立即被 Finalized，而是进入挑战期，任何人可提交欺诈证明（Fraud Proof）。

如果 无人挑战，则状态根自动生效；如果有人挑战，系统启动争议机制，成功则回滚 L2 状态，失败则挑战者受罚。这种机制确保了L2状态的最终性、安全性和可验证性，继承L1的安全性，同时提升L2交易效率并降低成本。

<!--EndFragment-->