摘要：Optimistic Rollup 靠挑战期和欺诈证明，ZK Rollup 靠有效性证明。本文用 L2BEAT 的真实页面对照 Arbitrum One、Base 与 Starknet 的证明系统、Stage 和五维风险图，并说明官方桥提款为什么要等约一周。

Rollup 是目前以太坊二层网络（Layer2）的主流方案：交易在 L2 上执行，交易数据和状态承诺提交回以太坊主网，由主网上的合约决定 L2 的状态能不能被认可、提款能不能放行。区别在于「怎么证明 L2 的状态是对的」：Optimistic Rollup 先默认正确、留出挑战期让人举报错误；ZK Rollup 每批都附上有效性证明，主网验证通过才认账。本文用 L2BEAT 的真实页面，以 Arbitrum One、Base 和 Starknet 为例讲清两者差异和风险怎么看，不涉及任何代币行情。

如果你对 Layer1、Layer2、侧链这几个词还比较模糊，可以先看站内较早的一篇 一文读懂Layer1、Layer2及侧链解决方案；本文聚焦 Rollup 的证明机制。

目录
  1. Rollup 的共同骨架
  2. 在 L2BEAT 上看 Rollup 的分类
  3. Optimistic Rollup：先认账，挑战期内可举报
  4. ZK Rollup：每批都带数学证明
  5. 两种方案对照
  6. 五维风险图怎么读
  7. 自己核对一条 L2 的步骤
  8. 相关阅读

Rollup 的共同骨架

  1. 排序器（Sequencer）接收用户交易，在 L2 上快速出块，给用户一个「软确认」。
  2. 排序器把交易数据批量提交到以太坊（EIP-4844 之后主要以 blob 形式），任何人都能据此重放 L2 的全部状态，这叫数据可用性在以太坊上。
  3. 提议者（Proposer）把 L2 的状态根提交到以太坊上的合约。
  4. 主网合约用某种证明系统判断状态根是否可信，可信之后，L2→L1 的提款才能在主网上执行。

Optimistic 和 ZK 的分歧只在第 4 步。用户在 L2 上付的手续费也大致分两块：L2 执行费，加上分摊的 L1 数据发布成本；后者和以太坊主网的 Gas、blob 费用有关，主网计费原理见 以太坊 Gas 费怎么算。

在 L2BEAT 上看 Rollup 的分类

Optimistic 与 ZK Rollup 差在哪：用 L2BEAT 看 Arbitrum、Base-程序旅途
图1：L2BEAT Scaling Summary 的 Rollups 列表（截图时）：Base Chain 为 Optimistic / SP1，Arbitrum One 为 Optimistic / BoLD，Starknet 为 Validity / Stwo；Stage 列显示 Stage 0 或 Stage 1（界面为英文）

L2BEAT 是专门跟踪以太坊二层风险的公开站点。列表里几个关键列：

  • Proof System：Optimistic 表示乐观证明（欺诈证明），Validity 表示有效性证明（即 ZK）。下方小字是具体实现，例如 Arbitrum 的 BoLD、Starknet 的 Stwo。
  • Stage：L2BEAT 定义的去中心化成熟度。Stage 0 基本还依赖运营方或多签兜底；Stage 1 已有可运作的证明系统，但安全委员会仍保留紧急情况下的干预权；Stage 2 治理能干预的空间最小。
  • Risks：那个五瓣小饼图，下面单独解释。

页面上方另有 Validiums & Optimiums 标签页。它们的数据不发布到以太坊，因此不算严格意义上的 Rollup，风险模型不同，别混在一起比较。

Optimistic Rollup：先认账，挑战期内可举报

Optimistic 与 ZK Rollup 差在哪：用 L2BEAT 看 Arbitrum、Base-程序旅途
图2：L2BEAT 上的 Arbitrum One：Type 为 Optimistic Rollup，Stage 1，Gas token 为 ETH，Chain ID 42161；右侧为五维风险图（界面为英文）

Optimistic 的逻辑是：提议者提交状态根时要质押保证金；在挑战期内，任何发现错误的人都可以发起挑战。双方通过交互式二分把分歧缩小到一步指令，再由以太坊上的合约执行这一步来裁决，输的一方被罚没保证金。没人挑战或挑战失败，状态根在挑战期结束后被确认。

Optimistic 与 ZK Rollup 差在哪：用 L2BEAT 看 Arbitrum、Base-程序旅途
图3：L2BEAT 中 Arbitrum One 的 State validation 一节：诚实与恶意断言相互竞争，二分到一步后交给 one-step executor 在 L1 上执行裁决；状态根通过挑战期后才可用于提款（界面为英文）

对用户最直接的影响是官方桥提款要等挑战期。Arbitrum 官方文档写明：Arbitrum One 的争议窗口是 45,818 个以太坊区块，约 6.4 天，加上前后打包、确认的时间，通过官方桥提回以太坊大约需要一周；BoLD 协议把真正发生争议时的额外延迟限定在最多再一个挑战期。第三方快速桥可以绕过等待，但那是由第三方提供流动性，风险另算。

Optimistic 与 ZK Rollup 差在哪：用 L2BEAT 看 Arbitrum、Base-程序旅途
图4：L2BEAT 上的 Base：Type 为 Optimistic Rollup，Stage 1，Chain ID 8453（界面为英文）

Base 基于 OP Stack，在 L2BEAT 上同样归为 Optimistic，但证明系统一栏写的是 SP1（一种零知识证明系统）。原因是 L2BEAT 的分类规则：只要系统能够乐观地接受状态根，即使带有 ZK 组件，也归为 Optimistic 证明系统。L2BEAT 的合约说明显示，Base 当前的争议合约同时接入了 TEE 证明和 SP1 零知识证明，最终确认的等待时间取决于提交了哪几种证明。这类细节变化很快，提款前以 L2BEAT 项目页的 Withdrawals 一节和官方桥界面的预计时间为准。

ZK Rollup：每批都带数学证明

Optimistic 与 ZK Rollup 差在哪：用 L2BEAT 看 Arbitrum、Base-程序旅途
图5：L2BEAT 上的 Starknet：Type 为 ZK Rollup，Stage 1，Gas tokens 为 ETH、STRK；简介写明使用 STARK 证明、以以太坊 blob 做数据可用性（界面为英文）

ZK Rollup 的证明者在链下生成有效性证明，证明「从旧状态执行这批交易，确实得到新状态」，以太坊上的验证合约只需验证这份证明。验证通过就确认，不需要挑战期。以 Starknet 为例，L2BEAT 的说明是它使用 STARK 证明，并用以太坊 blob 做数据可用性。

代价在于生成证明计算量大、工程复杂，兼容 EVM 也更难。提款快慢取决于证明多久生成并提交一次，而不是固定的挑战期，具体以各项目官方桥显示为准。

两种方案对照

对比项 Optimistic Rollup ZK Rollup
状态怎么被认可 默认正确，挑战期内无人成功举报即确认 验证合约验证有效性证明后确认
安全假设 至少有一个诚实方会监控并及时挑战 证明系统与验证合约实现正确
官方桥提款 需等挑战期，Arbitrum One 约一周 取决于证明提交频率，无固定挑战期
L2BEAT 标注 Optimistic（如 BoLD、OPFP） Validity（如 Stwo）
本文例子 Arbitrum One、Base Starknet

五维风险图怎么读

项目页右上角的风险图分五瓣，绿色好、黄色一般、红色差：

  • State Validation：状态是否有证明系统保障、证明是否开放给任何人提交。
  • Data Availability：交易数据是否发布在以太坊上。
  • Exit Window：合约升级前，用户有没有足够时间提走资产。
  • Sequencer Failure：排序器宕机或审查你的交易时，能否绕过它强制上链。
  • Proposer Failure：提议者停摆时，别人能否接手提交状态根。

判断一条 L2「安不安全」，看这五项比看 TVS（锁仓价值）更有意义。TVS 只说明有多少资产放在里面，不说明风险。

自己核对一条 L2 的步骤

  1. 打开 L2BEAT，在 Search 中搜项目名，进入项目页。
  2. 看 Type（Optimistic / ZK）、Stage 和五维风险图。
  3. 点右侧目录的 State validation、Withdrawals，读证明机制和提款等待时间。
  4. 往下拉到 Permissions 和 Smart contracts，看谁能升级合约、升级有没有延迟。
  5. 用官方浏览器（例如 Arbiscan、Basescan）核对你在 L2 上的交易，确认你的提款处在哪个阶段。

实际操作例子：Hyperliquid 怎么入金 一文就是先把 USDC 提到 Arbitrum 再存入；另一个 L2 案例可以看 Robinhood Chain 是什么。

相关阅读

说明：L2BEAT 数据为 2026-09-26 截图时的页面内容，项目的 Stage、证明系统和提款时间会随升级变化；Arbitrum 挑战期引自 Arbitrum 官方文档。本文不构成任何投资建议。