第一次使用以太坊时，你可能会遇到两个问题：一笔简单操作为什么要支付不低的手续费？钱包显示交易成功后，为什么跨链提现还需要等待？
理解 Layer 2，简称 L2，需要把交易执行、数据发布、结果验证和资产结算放在一起看。本文以以太坊生态的 Rollup 为主线，从基础概念讲到实际使用和开发中的细节。
一、Layer 2 到底是什么？
Layer 1，也就是 L1，是基础区块链。以太坊主网负责自身的共识、数据和状态，为建立在其上的系统提供结算基础。
L2 将一部分交易处理移到基础层之外，同时通过基础层上的协议约束结果。在以太坊生态中，Rollup 是重要的 L2 路线：交易在 L2 执行，相关数据与状态承诺提交到以太坊，结算规则由 L1 合约执行。Ethereum 的网络介绍也强调，应检查网络与以太坊的数据及安全关系，而不是只看项目名称。
本文中的“链下执行”是指相对于以太坊 L1，在 L2 系统中执行，不等于把结果交给普通网站数据库决定。
| 维度 | 以太坊 L1 | 基于以太坊的 Rollup |
|---|---|---|
| 交易执行 | 由 L1 执行层处理 | 在 L2 执行环境处理 |
| 用户账户与状态 | 存在于以太坊主网 | 存在于对应 L2 网络 |
| 结果约束 | L1 共识与执行规则 | L1 合约、证明机制及其他实际部署条件 |
| 使用体验 | 直接使用主网资源 | 分摊批次成本，通常获得更低费用 |
**同一个钱包地址可以出现在多个 EVM 网络上，但各网络的余额、合约和交易历史分别存在。**在主网拥有 ETH，不会自动让另一个网络出现相同余额。
二、为什么需要 Layer 2？
区块链的吞吐量受到计算、带宽、存储和节点验证能力的共同约束。如果只提高主网容量，运行节点可能需要更强的硬件，从而提高独立验证的门槛。
L2 的做法是让大量执行工作在独立环境中完成，再将可验证的结果和必要数据交给基础层。它主要通过三种方式降低用户成本：
- 分离执行与结算：每笔 L2 交易不需要由所有 L1 节点重新执行完整业务逻辑。
- 批量处理：多个用户共同分摊一次数据发布和结算的固定成本。
- 压缩数据：减少提交到 L1 的字节数。
可以把它类比为拼车：每个人仍有独立目的和费用，但可以共同分摊一段运输成本。这个类比只解释成本分摊，具体安全仍由协议保证。
三、一套 Rollup 由哪些部分组成？
不同项目会合并或拆分组件，下面按职责理解：
| 组件 | 主要职责 | 需要区分的边界 |
|---|---|---|
| 排序器 Sequencer | 接收交易、确定顺序、提供快速回执 | 排序权不等于任意修改合法状态的权力 |
| 执行节点 | 按规则执行交易并维护 L2 状态 | RPC 回执不等于结果已经在 L1 完成结算 |
| 批次提交器 Batcher | 压缩并发布批次数据 | 数据发布与状态验证可以发生在不同时间 |
| 状态提议者 | 提交状态承诺或断言 | 承诺本身只是对状态的声明 |
| 挑战者或证明者 | 挑战错误断言，或生成有效性证明 | 两条技术路线的验证方式不同 |
| L1 合约 | 验证、处理争议、执行跨层消息与资产释放规则 | 合约漏洞和升级权限仍会影响安全 |
Scroll 的架构文档将系统划分为结算、排序和证明三个层次，可作为理解这些职责的具体案例。
一笔普通 L2 交易可以用下面的简化流程理解：
用户签名交易
↓
提交到 L2 RPC / 排序器
↓
L2 执行并返回交易回执
↓
批次数据发布到以太坊
↓
状态结果经过对应的证明或争议流程
↓
满足协议条件后，执行 L1 结算或跨层消息
实际实现会有流水线和并行处理，不能把这张图理解为所有项目都严格按同一顺序串行运行。OP Stack 交易流程提供了一个具体实现的说明。
四、Optimistic Rollup：通过争议机制约束结果
Optimistic Rollup 允许先提出状态结果，在规定窗口内接受挑战。它不要求每个新结果都先附带有效性证明；发生争议时，协议按照故障证明或欺诈证明规则处理错误执行。Ethereum 的 Optimistic Rollup 文档介绍了这一路线。
可以把基本过程理解为：
- 提议者声明某批交易执行后的状态。
- 其他参与者利用可用数据重新执行并检查。
- 发现问题时，在期限内提交挑战。
- 协议依据争议结果接受或拒绝相关断言，并按规则处理保证金。
这里的“乐观”是协议流程的名称。安全依赖挑战机制实际启用、数据可获取，以及至少有诚实参与者能够及时提交并完成有效挑战等条件。
不同系统的争议协议并不相同。例如，Arbitrum BoLD使用其自身的有界争议机制，并开放验证参与。不能仅凭“支持欺诈证明”一句介绍判断完整部署状态。
五、ZK Rollup：用有效性证明验证状态转换
ZK Rollup 使用密码学证明，让 L1 验证某次状态转换是否满足约定的计算规则。证明生成通常比验证复杂，因此可以将大量执行工作与相对紧凑的验证过程分开。Ethereum 的 ZK Rollup 文档解释了该机制。
例如，某批交易将状态从 A 更新到 B，证明者需要生成能够通过验证的证明，将这次变化绑定到协议规定的执行规则和输入。验证者不必逐笔重放完整计算，也能检查该声明。
需要注意三个边界：
- **ZK Rollup 不会自动隐藏转账内容。**扩容系统使用有效性证明时，交易和余额仍可能公开可见。
- **证明正确不等于业务逻辑正确。**如果合约、证明电路或规则本身存在缺陷，证明无法替开发者修复它们。
- **没有相同的争议等待窗口，不代表立即提现。**仍需等待批次、证明生成、提交、L1 确认及对应桥的执行条件。
六、两种 Rollup 路线有什么区别？
| 维度 | Optimistic Rollup | ZK / Validity Rollup |
|---|---|---|
| 验证方式 | 提出结果，允许按规则挑战 | 验证状态转换的有效性证明 |
| 核心条件 | 数据与有效挑战路径可用 | 证明系统、验证器和数据路径正确 |
| 计算开销 | 执行、监控及争议处理 | 执行、证明生成及证明验证 |
| 原生提现 | 通常受争议及桥规则约束 | 受证明提交、确认及桥规则约束 |
| 虚拟机支持 | 取决于具体实现 | 同样取决于具体实现 |
| 隐私保护 | 不是默认属性 | 也不是默认属性 |
这个表用于比较机制。实际网络可能采用多个证明系统或额外验证组件，具体安全和等待时间应以当前部署为准。
七、数据可用性与 Blob 为什么重要？
数据可用性不只是“保存一个哈希”
状态承诺可以帮助校验结果，但只有哈希，无法凭空恢复交易输入或账户状态。数据可用性关注的是：参与者是否能够获得验证或重建状态所需的数据。Ethereum 的数据可用性文档解释了这一问题。
Blob 是什么？
EIP-4844定义了携带 Blob 的交易，为 Rollup 等用途提供专门的数据发布能力。Blob 数据不直接作为普通 EVM 可读取的合约存储，其费用机制也与普通执行 Gas 有区别。
Blob 的作用是降低和扩展数据发布成本，但它不是永久文件仓库。协议要求的数据可用窗口与长期历史保存是两件事；归档、同步和历史查询仍需要相应基础设施。
Rollup、Validium 和侧链如何区分？
| 类型 | 状态验证方式 | 数据与安全关系 |
|---|---|---|
| Rollup | 在 L1 上通过争议或有效性机制约束结果 | 将重建状态所需数据发布到 L1 的数据机制 |
| Validium | 使用有效性证明 | 数据在 L1 之外，增加外部数据可用性假设 |
| 侧链 | 通常由独立验证者和共识维护 | 与 L1 通过桥等机制连接，依赖自身安全模型 |
数据不可用时，Validium 用户可能难以重建状态或完成退出，即使错误状态不能轻易通过证明。Validium 文档与侧链文档分别说明了这两类设计。判断时应核对具体模式；同一套技术栈可能支持不同的数据配置。
八、交易确认、最终性和提现分别意味着什么？
钱包显示“成功”，通常表示交易已在对应 L2 状态中执行。后续还可能经过多个阶段：
| 阶段 | 大致含义 | 业务上的影响 |
|---|---|---|
| 排序器回执 | 排序器接收或执行了交易 | 可以更新界面，但仍依赖排序器提供的信息 |
| 数据已发布 | 批次数据进入 L1 | 可依据发布的数据推导相应 L2 链 |
| L1 数据最终确认 | 承载数据的 L1 区块获得最终性 | 降低相应 L1 重组带来的不确定性 |
| 状态或消息可结算 | 满足证明、争议和桥的条件 | 才能完成相应的 L1 资产释放或消息执行 |
这些阶段的名称、顺序和组合因协议而异。OP Stack 的最终性文档给出了 unsafe、safe 和 finalized 等术语的具体含义。它们不能直接等同于“资产已可从桥中提取”。
开发者应按业务后果选择等待条件：普通页面反馈可以更快，大额入账、跨链释放和不可逆发货则需要更严格的确认策略。
九、资产怎样进入和离开 L2？
原生桥的一般流程
以常见锁定与铸造模型为例：用户在 L1 桥中存入资产，跨层消息被 L2 处理后，用户获得对应余额或代币表示。提现时，在 L2 发起退出，再经过证明或争议等流程，最后在 L1 领取。具体实现可能采用不同资产处理方式。
**跨链不是把同一个代币对象搬到另一个数据库。**它涉及多条链之间的消息、验证和资产负债关系。Ethereum 的桥接文档介绍了不同桥的机制与风险。
快速桥为什么可以更快到账？
常见做法是由流动性提供者先在目标网络垫付资产，再完成后续结算。用户获得更快到账体验，同时承担服务商流动性、消息验证或其他桥机制的风险。
例如，Base 的桥接说明区分了标准桥、快速桥和消息协议。等待时间应按具体路径检查，不能把某个网络的窗口推广到所有 L2。
实际操作时，至少核对来源网络、目标网络、代币合约、到账数量和下一步所需的 Gas。部分平台支持直接提现到目标 L2，但必须确认该币种当前支持的网络。
十、L2 手续费由什么组成？
可以先使用一个帮助理解的成本分解：
用户支付的 L2 交易费
≈ L2 执行成本
+ 分摊的数据发布成本
+ 网络实现规定的其他费用
这不是所有网络通用的报价公式。以 OP Mainnet 费用文档为例，费用包含执行、L1 数据与相应的运营费用组成，具体规则随升级演进。
实际费用还受到批次压缩、L1 数据需求、L2 拥堵和交易复杂度影响。转账、兑换和部署合约消耗的资源不同，所以比较网络成本时应使用相近操作。
可以用一个纯假设例子理解分摊：若一批交易共用 6 个费用单位，包含 300 笔操作，平均固定分摊为 0.02 个单位。但真实收费还会按字节数、执行量及协议参数变化，不会机械地对每个用户均摊。
十一、“继承以太坊安全”需要哪些实际条件？
Rollup 的安全性需要逐项检查：
- 证明与争议：机制是否已部署，谁可以提交结果、证明或挑战？
- 数据路径：必要数据发布在哪里，遇到数据扣留时怎么办？
- 升级权限：谁能替换验证器或桥合约，是否有延时和退出机会？
- 排序器故障：停机或审查交易时，是否存在可操作的替代路径？
- 退出能力：退出依赖哪些参与者、工具、费用和时间条件？
OP Stack 的特权角色文档列出了升级和暂停等权限；强制交易文档说明了绕过排序器提交交易的具体机制。具备这类路径也不意味着所有普通用户都能立即、零成本退出。
还应分别评估 L2 协议、跨链桥、应用合约和钱包授权。底层结算机制不会自动保护一个有漏洞的借贷合约。
十二、有哪些值得学习的具体实现？
下面选择三个实现作为阅读入口，不进行收益或安全排名：
| 网络 | 学习重点 | 官方阅读入口 |
|---|---|---|
| Arbitrum One | Nitro 执行架构与 BoLD 争议机制 | Inside Arbitrum Nitro |
| OP Mainnet | OP Stack 的数据推导、最终性和费用 | OP Stack 文档 |
| Scroll | 排序、证明与以太坊结算的分工 | Scroll Architecture |
阅读项目时，区分技术栈、具体网络和部署配置。使用相同技术栈，不代表证明、数据可用性、升级权限或桥参数完全相同。
十三、开发 L2 应用需要注意什么？
兼容 EVM，也需要验证具体行为
许多 Solidity 工具可以复用，但应核对目标网络的操作码、预编译、Gas 估算和系统合约差异。RPC 方法、日志范围限制和索引服务也可能不同。Nitro 文档是研究某个执行实现的入口，不能替代目标链自己的差异说明。
将“网络”加入数据模型
数据库中的资产不能只按代币符号识别。一个更合理的标识包含：
资产标识：chainId + tokenContractAddress
交易标识：chainId + transactionHash
账户状态：chainId + accountAddress
原生 Gas 资产需要独立表示；同名稳定币也可能属于不同发行或跨链版本。
把跨链消息当成异步任务
跨层消息不能当作一次跨网络的同步函数调用。应用需要记录来源交易、目标消息、当前阶段和失败原因，并设计重试、去重、超时及用户通知。
例如，订单可以依次处于“已提交”“来源交易确认”“目标链处理中”“目标执行成功”“需要处理异常”等状态。来源链成功只表示流程完成了其中一部分。
按网络测试故障情况
除了正常路径，还应验证 RPC 超时、排序器不可用、重复回调、交易替换、重组、Gas 不足和跨链消息延迟。至少在测试网走通进入网络、调用应用及退出的完整过程。
十四、常见误区
| 说法 | 更准确的理解 |
|---|---|
| 费用低的链都是 L2 | 需要检查其结算、证明与数据模型 |
| L2 就是一台中心化服务器 | 排序器可以集中运营，但合法状态受协议约束；还要评估实际权限 |
| 所有 L2 都使用 ETH 付 Gas | Gas 资产取决于具体网络配置 |
| L2 成功后，L1 一定立即承认结果 | 快速回执、数据最终性和可结算状态存在区别 |
| 使用 ZK 就会隐藏余额 | 隐私需要专门设计 |
| EVM 兼容就能不经测试直接部署 | 需要核对执行、费用、系统合约和基础设施差异 |
| L2 使用量增长必然推动代币升值 | 需要单独分析代币权利、供给与价值捕获机制 |
十五、建议的学习顺序
- 理解以太坊账户、交易、Gas 和区块最终性。
- 使用测试网观察一笔 L2 交易及其 L1 数据提交。
- 分别阅读一套争议协议和一套有效性证明流程。
- 走通桥的存入、消息处理和提现步骤。
- 写一个展示交易不同阶段的小工具。
- 对照权限、数据和退出条件分析一个具体网络。
评估一个 L2 时，可以始终追问四个问题：**谁执行交易，数据放在哪里，结果怎样验证，发生故障时怎样退出？**把答案落实到实际部署，才能理解它提供的性能与所依赖的安全条件。
