Layer 2 Rollup 架构与数据可用性机制

Rollup 是一种基于以太坊的 Layer 2 扩容机制：其核心思想是将昂贵的**事务执行（Execution）下沉至链下，而将关键的状态承诺（State Commitment）与数据可用性（Data Availability, DA）**锚定在以太坊 Layer 1 主网。

在架构层面，Rollup 在以太坊 L1 上表现为一组普通的智能合约（Smart Contracts）。无论是 Optimistic Rollup（OP）还是 Zero-Knowledge Rollup（ZK），系统安全性均最终受制于 L1 验证合约的裁决逻辑、资产金库的托管模型以及底层数据发布层的生命周期约束。

跨层数据互信与资金转移的不对称性

跨层资产转移在 L1 \(\rightarrow\) L2 与 L2 \(\rightarrow\) L1 方向上存在天然的计算与信任不对称性。

sequenceDiagram
  autonumber
  actor User as 用户
  participant L1Contract as L1 桥接托管合约 (Escrow)
  participant L1Consensus as L1 共识层 (Finality)
  participant L2Sequencer as L2 排序器 / 节点
  participant L2Contract as L2 映射代币合约

  Note over User, L2Contract: L1 -> L2 充值流程（天然确定性）
  User->>L1Contract: deposit() 锁定资金
  L1Contract->>L1Consensus: 产生 L1 充值事件并等待 Finalized
  L2Sequencer->>L1Consensus: 监听 L1 日志事件
  L2Sequencer->>L2Contract: 在 L2 铸造 / 解锁等额映射代币 (秒级入账)

  Note over User, L2Contract: L2 -> L1 提款流程（需解决信任证明）
  User->>L2Contract: withdraw() 销毁 L2 资产
  L2Sequencer->>L1Contract: 提交包含提款事件的 L2 状态根 (State Root)
  alt Optimistic 官方桥
    Note over L1Contract: 强制等待 7 天挑战期 (Fraud Proof Window)
    L1Contract->>User: 挑战期结束且无人质疑，释放 L1 资产
  else ZK 官方桥
    L2Sequencer->>L1Contract: 提交 ZK 有效性证明 (Validity Proof)
    Note over L1Contract: 合约执行 verifyProof() 验证通过
    L1Contract->>User: 立即放行提款 (无需等待 7 天)
  else 第三方流动性桥 (Fast Bridge)
    Note over User, L1Contract: 做市商 LP 监听 L2 事件，直接在 L1 自有资金垫付给用户
  end

1. L1 \(\rightarrow\) L2 充值：确定性秒级入账

当用户从以太坊 L1 向 Layer 2 充值时：

• 用户调用 L1 桥接合约的 deposit()，将资产锁入托管金库（Escrow），并触发充值事件（Deposit Event）。
• 信任根源：所有 L2 验证节点与排序器（Sequencer）在底层全天候运行着以太坊 L1 节点。由于以太坊 L1 的安全级别高于 L2，L2 节点能够无条件信任 L1 的状态转移。
• 最终性判定：一旦该笔 L1 交易达到区块确定性（Finalized，通常在 PoS 机制下经历 2 个 Epochs 约 12.8 分钟；在轻量场景下依赖一定区块确认数），L2 排序器便可 100% 确认资产转移不可逆，立即在 L2 为用户铸造或释放对应的映射代币。

2. L2 \(\rightarrow\) L1 提款：证明机制与延迟分化

以太坊 L1 节点不会也不可能去全量运行或同步所有 L2 的虚拟机状态。因此，当用户在 L2 发起提款并将资产销毁后，L1 合约必须通过严谨的逻辑验证该状态转移的合法性。

A. 官方规范桥（Native / Canonical Bridge）

• Optimistic Rollup（欺诈证明机制）：
  • L2 排序器仅将一批交易执行后的最终状态根（stateRoot）发布至 L1。
  • 由于 L1 合约无法即时断定该状态根是否真实，必须进入7 天挑战期（Fraud Proof Window）。
  • 任何诚实验证者若发现状态根与交易数据执行结果不符，可在 7 天内向 L1 提交欺诈证明发起争议仲裁。
  • 提款请求必须在 7 天无人质疑后，方可由 L1 金库释放资金。
• ZK Rollup（有效性证明机制）：
  • 排序器在提交状态根的同时，提交一份由链下证明系统生成的零知识证明（Validity Proof，如 Groth16、PLONK 或 STARK）。
  • L1 验证合约在链上执行代数验证算法。一旦验证通过，即在数学上确保了该批次内所有交易（包括提款）均合法有效。
  • 用户提款仅受限于批次打包与 ZK 证明生成的物理时间，无需经历 7 天挑战期，验证通过后即可立即解锁。

B. 第三方流动性快速桥（Fast Bridges，如 Across、Hop 等）

第三方桥能够在数秒至数分钟内完成 L2 到 L1 的资金跨转，其本质是引入流动性做市商（LP）承担回款时间成本与资金垫付风险：

1. 做市商在本地运行了独立的 L2 全节点，能够即时感知并自行验证用户的 L2 销毁行为真实有效，不存在双花。
2. 只要该笔 L2 交易被排序器确认为不可逆（或对应的数据批次在 L1 敲定），做市商便直接在 L1 使用自有现货流动性垫付给用户，并扣除少量通道手续费。
3. 官方桥 7 天后解锁的资产，最终由做市商协议自身回收入账。

L1 上的 Rollup 合约架构与状态记账

在以太坊 L1 上，Rollup 并没有特殊的底层系统协议，其核心就是一组遵循特定规范部署的智能合约系统。

graph TD
  subgraph L1 智能合约集群
    Portal[Rollup Portal / Bridge Escrow<br/>资产锁定金库]
    RollupCore[Rollup 核心逻辑合约<br/>批次流水索引 & 状态提交]
    Verifier[验证器合约<br/>OP 交互仲裁 / ZK 电路验证]
  end

  subgraph 提交内容
    SR[状态承诺: State Root]
    BlobData[EIP-4844 Blob 数据<br/>交易压缩批次]
  end

  RollupCore -->|校验与调用| Verifier
  RollupCore -->|放行提款指令| Portal
  SR -->|写入存储| RollupCore
  BlobData -.->|KZG 承诺校验| RollupCore

1. 合约持久化记录的核心状态数据

L1 核心 Rollup 合约维护的核心状态极其有限且紧凑：

2. OP 体系合约与 ZK 体系合约的底层职责对比

Optimistic 仲裁合约（以 OP Stack / Arbitrum 为例）

• 乐观接收状态根：允许被授权的定序者直接推入新的 stateRoot，合约无条件记录并启动倒计时计时器。
• 管理交互式欺诈证明（Interactive Fraud Proof）：当挑战者对某状态根提出异议时，合约切换为二分查找交互模式（Bisection Game）。
• 单步指令证明执行器（One-step Prover）：双方在链下不断二分折半，最终在 L1 仲裁合约中定位到引发分歧的单条指令。L1 验证合约在链上模拟执行该条指令，判断原始提议者是否造假，若造假则回滚该状态根并没收其质押保证金。

ZK 验证合约（以 Scroll、Starknet、zkSync 为例）

• 严苛的数学门禁：合约不提供任何宽限期，拒绝未经证明的状态更新。
• 集成密码学配对验证器（Pairing / Verifier Contract）：

  function verifyBatches(
      uint256 prevBatchIndex,
      bytes32 prevBatchRoot,
      uint256 newBatchIndex,
      bytes32 newBatchRoot,
      bytes calldata proof
  ) external {
      // 1. 断言前置状态连续性
      require(stateRoots[prevBatchIndex] == prevBatchRoot, "Invalid parent root");
      
      // 2. 将 publicInputs（包含新旧状态根、L1 数据哈希等）与 proof 一并传入验证器
      bytes32 publicInputHash = keccak256(abi.encode(prevBatchRoot, newBatchRoot, ...));
      bool valid = verifier.verifyProof(proof, publicInputHash);
      require(valid, "Invalid ZK validity proof");
      
      // 3. 验证通过，状态转移确立
      stateRoots[newBatchIndex] = newBatchRoot;
  }
  

EIP-4844 Blob 机制与数据可用性（DA）的真相

1. 为什么 Rollup 全面转向 Blob？

在 Cancun 升级之前，Rollup 必须将交易压缩数据作为 calldata 强行塞入 L1 交易中。calldata 会永久占用以太坊执行层节点的内存与磁盘，成本极高。

EIP-4844 引入了Blob 携带交易（Type-3 Transaction）：

• 每个 Blob 大小为 128 KB，每个区块目前支持挂载多达 6 个 Blob。
• 与 EVM 执行层完全解耦：EVM 内部代码无法直接读取 Blob 的具体明文数据，仅能通过操作码 BLOBHASH 获取其 32 字节的 KZG 版本化哈希（versionedHash）。
• 数据发布费用进入独立的动态定价费用市场（Blob Gas），使得 L2 提交 DA 的成本相较于常规 Calldata 下降了 90% 以上。

2. Blob 的临时性生命周期与剪枝（Pruning）

必须明确的核心事实是：Blob 数据并不具备以太坊主网的永久存储保证。

• 18 天生命周期：以太坊共识层节点对 Blob 的保留周期固定为 4096 个 Epochs（约 18 天）。
• 物理自动丢弃：超过 18 天后，全网验证者节点会将该 Blob 数据从本地磁盘中物理剔除，不再对 P2P 网络提供同步服务。

3. 极端灾难恢复（Disaster Recovery）的局限性

过去社区常有一种简化认知：“因为 Rollup 数据全部上链，即使 L2 节点全部消失，用户也能从 L1 恢复出完整的 L2 链。”

在引入 Blob 机制之后，这种假设在工程现实中必须重新修正：

1. 无法直接恢复完整的全历史事务记录（Full Transaction Trace）： 若某 Layer 2 的官方定序器、节点运营商集体发生物理灾难瘫痪，且外界第三方归档节点（如区块浏览器、专业存储服务商）均未备份历史数据：
   • 18 天前的历史 Blob 已经在以太坊共识层中被清理。
   • 新加入的节点无法仅凭以太坊 L1 节点恢复出所有的历史交易明细、智能合约部署代码细节与事件日志（Events）。
2. L1 上永久存留的确定性边界： 以太坊 L1 永久保存的仅有：
   • 历次批次确认后的最终状态根（Finalized State Root）。
   • 资产桥接金库中真实的物理抵押资产。
3. 逃生通道（Escape Hatch / Forced Exit）的实际运作： 在极端情况下，用户要证明“我在 L2 上拥有这 10 个 WETH”，必须提供该账户叶子节点连接到最新 stateRoot 的默克尔审计证明（Merkle Proof）。 若用户自身未在本地缓存近期的状态树证明数据，且由于 Blob 剪枝导致全网无历史归档，用户将无法重构出这棵证明树，面临资产无法退出的现实风险。

因此，现代 Rollup 体系的去中心化评估，不能仅看是否使用了以太坊作为 DA，还必须考察其是否有独立的数据可用性委员会（DAC）、长效分布式归档网络（如 IPFS、Arweave、BitTorrent 等协议对历史 Blob 的持久化镜像）以及强制提款机制的设计完整性。

定序器（Sequencer）架构与去中心化演进

在理论模型中，Rollup 的安全性依赖以太坊 L1 验证，但在生产现实中，定序器是用户体验与系统信任假设的核心交汇点。

1. 中心化定序器的权力边界与隐患

目前绝大多数主流 Rollup（包括 Arbitrum One、OP Mainnet、Base、Scroll 等）均采用由官方单一实体运营的中心化定序器集群。理解定序器的权力边界是评估 L2 风险的前提：

2. 强制包含与 L1 逃生通道（Forced Inclusion / Escape Hatch）

为了对抗中心化定序器的审查风险，成熟的 Rollup 协议必须在 L1 合约中设计强制包含机制：

sequenceDiagram
  autonumber
  actor User as 受审查用户
  participant L1Inbox as L1 延迟收件箱 (Delayed Inbox)
  participant Sequencer as L2 定序器
  participant L2Chain as L2 状态机

  User->>Sequencer: 发送 L2 交易 (遭定序器恶意拒绝/忽略)
  User->>L1Inbox: 直接在 L1 调用 forceInclusion(txData)
  Note over L1Inbox: 记录交易并开启倒计时强制窗口 (如 24 小时)
  alt 定序器在窗口期内履职
    Sequencer->>L1Inbox: 主动抓取延迟收件箱交易
    Sequencer->>L2Chain: 打包进下一个 Batch 提交
  else 定序器超时拒绝打包
    User->>L1Inbox: 触发强制入块执行 (Force Enqueue)
    Note over L1Inbox, L2Chain: L1 合约强制接管排序流水线，冻结常规提议并强制同步该交易
  end

• 延迟收件箱（Delayed Inbox / Enqueue Queue）：用户若被 L2 拒绝服务，可直接支付 L1 Gas 在主网合约中提交该交易。
• 强制推进保护：协议设置确定性的宽限窗口（Grace Period，如 24 小时）。若定序器在超时后仍未将收件箱交易纳入最新批次，L1 合约将拒绝接受定序器后续提交的任何常规批次，强制优先结算被审查的交易。

3. 定序器去中心化演进路径

社区目前在探索三种主流的定序器去中心化方案：

A. 共享定序网络（Shared Sequencer Network）

• 代表实现：Espresso、Astria。
• 架构机制：Rollup 不再自行维护定序节点，而是将交易流转发给一个独立的去中心化 PoS 共识网络（通常采用 HotStuff 或 CometBFT 协议）。
• 核心优势：多个不同的 Rollup 可以接入同一套共享定序器，从而在定序层原生实现**跨 Rollup 原子交互（Cross-Rollup Atomicity）**与防套利协同。

B. 基于 L1 排序（Based Rollup / L1-sequenced）

• 架构机制：彻底废除独立的 L2 定序网络，直接将 L2 交易的排序权委托给以太坊 L1 验证者（Proposers/Searchers）。
• 核心优势：完全继承以太坊 L1 的抗审查性、活跃度与去中心化安全，系统无额外信任假设。
• 代价权衡：丧失了毫秒级的 L2 链下软确认体验，交易确认延迟与以太坊 L1 出块节拍（12 秒）高度绑定。

C. 动态验证者轮替（PoS Leader Election）

• 架构机制：在 L2 建立原生的代币质押与领导者选举池，每隔固定周期（Epoch）基于 VRF 伪随机数选举出下一任出块定序器，并对违规行为（如双签、断护）实施罚没（Slashing）。

Rollup 架构安全审计检查清单

• L1 提款验证机制：确认官方桥释放资产严格依赖有效性证明通过断言，或经历了完整的防作恶挑战周期。
• 状态根更新权限与治理穿透：排查 stateRoot 提交接口是否存在权限滥用，治理多签升级是否配置了具有充分安全窗口的时间锁（Timelock）。
• 强制退出与抗审查通道：验证在 L2 排序器离线或恶意审查交易时，用户是否能直接在 L1 调用 forcedWithdraw() 强制提款。
• Blob 版本化哈希绑定：确认 L1 合约在接收状态根时，严格将 BLOBHASH 与批次元数据进行了密码学校验，防止提交空哈希或解耦数据欺骗。
• 数据剪枝灾备机制：评估生态是否存在针对 18 天 Blob 剪枝的去中心化持久归档方案，防止灾难发生时状态重构失败。

参考文献与规范

• EIP-4844: Shard Blob Transactions
• EIP-1559: Fee market change for ETH 1.0 chain
• 以太坊官方文档 · Layer 2 Rollups
• Vitalik Buterin: An Incomplete Guide to Rollups