核心关键词:Optimism、乐观 Rollup、L2 扩容、L1-L2 桥、欺诈证明、CanonicalTransactionChain、OVM Fraud Verifier、跨域信使
什么是乐观 Rollup?
区块链的扩容总有选修两条路:要么让单层更快,要么把一部分计算搬到别处。
乐观 Rollup 走的正是第二条路。简单来说,它让昂贵的 以太坊主网(L1) 只做两件事:
- 记录压缩后的批量数据(几十笔交易压成一笔);
- 在争议期内存储「谁对谁错」的裁决思路,并执行 欺诈证明。
在 L1 之外,「更快」的 L2 节点(Sequencer)会打包大量交易,定时把状态根提交到主网。由于主网 先信任、后质疑,整个过程被命名为 乐观(Optimistic)。若没人提交欺诈证明,提交的状态就会被生效;反之,该批次回滚,提交者押金被罚没,验证者获得奖励。
这种「经济博弈 + 时间锁」既减少了主网运算,又沿用其安全性,是目前 Rollup 赛道的核心技术路线。
Optimism 合约架构:三大版图及其职责
要让 L2 体验安全流畅,智能合约分工得精切:
- L1-L2 双向资产桥
将 ETH / ERC-20 资产锁定在 L1,对应铸造,并在需要时反向赎回。 - 批次与交易处理
Sequencer 在 L2 聚合成块 → CanonicalTransactionChain 追加到 L1 → 最终确认。 - 争议处理与欺诈证明
用户发现错误后可提交证明,触发 OVM_FraudVerifier 清除错误批次。
以下分层拆解实际代码。
L1-L2 桥:锁仓、铸币与烧毁逻辑
存入流程(L1StandardBridge.sol)
function _initiateETHDeposit(
address _from, address _to,
uint32 _l2Gas, bytes memory _data
) internal {
bytes memory message = abi.encodeWithSelector(
IL2ERC20Bridge.finalizeDeposit.selector,
address(0),
Lib_PredeployAddresses.OVM_ETH,
_from, _to, msg.value, _data
);
sendCrossDomainMessage(l2TokenBridge, _l2Gas, message);
emit ETHDepositInitiated(_from, _to, msg.value, _data);
}简读:用户在 L1 桥打 ETH,合约把参数塞进一条跨域消息;L2 对应逻辑收到后 mint 等于值的 OVM_ETH,完成充值。
取出流程(L2StandardBridge.sol)
用户把 L2 的代币 burn 掉,发送跨域消息至 L1。L1 桥验证无误后释放锁定资产——对称而简洁。
跨域信息传递:如何在两条链之间“传话”
由于 L1 与 L2 之间没有原生共识,Optimism 用 CanonicalTransactionChain 执行「信号 + 中继」模式:
- 任何地址都可调用
enqueue把需要上链的 L2 交易排队; - Relay(中继器)监听事件,把消息异步推送给 L2 排序器;
- L2 接收后处理交易,并把批次再回写至 L1,从而完备合法性。
代码片段(CanonicalTransactionChain.sol):
function enqueue(
address _target, uint256 _gasLimit, bytes memory _data
) external {
bytes32 txHash = keccak256(abi.encode(msg.sender, _target, _gasLimit, _data));
queueElements.push(QueueElement({
transactionHash: txHash,
timestamp: uint40(block.timestamp),
blockNumber: uint40(block.number)
}));
emit TransactionEnqueued(msg.sender, _target, _gasLimit, _data,
queueElements.length - 1, block.timestamp);
}补充要点:
- 队列 仅追加,保证顺序不可篡改;
- 中继器目前是中心化,但开放去中心化路线图在 Roadmap 之内。
Rollup 批次:Sequencer 如何打包 & 提交
Sequencer 的角色类似临时区块制作者:高速出块、压缩数据,并在间隔期内用 appendSequencerBatch 批次落账 L1。
简化流程:
- 排序器收集 N 笔交易 → 生成 交易根
_transactionRoot; - 调用
_appendBatch,存进 batches 合约; - 附加哈希、上下文等元数据,为后续争议期留底。
片段:
function _appendBatch(
bytes32 _transactionRoot, uint256 _batchSize,
uint256 _numQueuedTransactions,
uint40 _timestamp, uint40 _blockNumber
) internal {
IChainStorageContainer batchesRef = batches();
bytes32 batchHeaderHash = Lib_OVMCodec.hashBatchHeader(header);
batchesRef.push(batchHeaderHash, latestBatchContext);
}一旦落账,交易顺序便固定在 L1,任何人均可在 争议期内 检验其正确性。
👉 想进一步理解 Sequencer 与去中心化路线图的时间表?
欺诈证明:如何用代码打败恶意状态更新
角色分配
- 验证者:保持节点在线,监听状态根;
- 恶意排序者:提交错误的状态根并抵押;
dispute 流程示意图
- 验证者提交 前/后状态根、对应批次头部及 Merkle 证明;
- OVM_FraudVerifier 进行一致性校验;
- 若状态根不一致,
deleteStateBatch触发回滚,同时 BondManager 罚没押金并拨给验证者。
关键函数:
function finalizeFraudVerification(
bytes32 _preStateRoot,
ChainBatchHeader memory _preStateRootBatchHeader,
...
) public {
require(
_postStateRoot != transitioner.getPostStateRoot(),
"State transition has not been proven fraudulent."
);
_cancelStateTransition(_postStateRootBatchHeader, _preStateRoot);
}一句话总结:“任何状态更新都只在一周内『临时生效』”;只要有人肯出验证算力,系统随时可回滚。
常见问题 FAQ
Q1:用户在 L2 能否绕过 Sequencer,直接提交交易到 L1?
是的。若能承受更高 Gas,可直接将交易 enqueue 进 CanonicalTransactionChain,Sequencer 必须在有限时间内将其列入批次。
Q2:乐观 Rollup 能抗 51% 攻击吗?
L1 的欺诈证明最终依赖以太坊共识。即便 L2 被集体作恶,仍可在挑战期内拉回到 L1 最终确认的安全层面,因此额外继承了以太坊的多数算力安全。
Q3:争议期为何设定为 7 天?
经验值。七天足够让社区中的理性节点发现并提交欺诈证明,同时不会让用户等待过久。该参数未来可治理投票动态调整。
Q4:存储在 L1 的「压缩数据」到底有多大?
一笔原生 ETH 转账放在 L1 仅占 12 字节(包含 nonce、签名等信息后的压缩版),比主网的 100+ 字节足足压缩 90% 以上。
Q5:存入 ETH 时的跨域消息会不会永远卡在桥里?
不会。消息附带 L2 Gas Limit,若 Sequencer 长期不执行,用户可通过强制包含机制 forceInclusion 把交易强制落账,经济激励可确保其被处理。
Q6:ERC-20 代币与 ETH 的桥接是否代码高度重复?
原理一致,但代币桥闭了对 token 地址、接口标准的额外校验(如 supportsInterface 与 l1Token 对应关系),所以统一至 L1StandardBridge/L2StandardBridge 体系即可兼容。
结语:未来展望
乐观 Rollup 的理念简单却优雅:以「争议窗口」赢得时间,用经济模型替代高频验证。Optimism 已计划:
- 去中心化 Sequencer —— 多节点轮换出块;
- Cannon 欺诈证明 —— 极简 VM,可在浏览器节点运行;
- 升级通道 —— 用户可自愿选择新版本或留在旧链。
当这些蓝图逐一落地,「速度快 + 够便宜 + 够安全」的理想 L2 将真正飞入寻常百姓家。
准备好与数十万开发者一起动手体验了吗?👇