去中心化、安全性和可扩展性是区块链的三大核心属性。根据区块链不可能三角理论，区块链架构只能在三者中实现两项。以太坊在设计上侧重于去中心化和安全性，因此在可扩展性方面表现较差。目前，以太坊每天处理 100 多万笔交易，导致交易费用高昂，推动了对以太坊扩展解决方案的需求。

目前有多种不同类型的以太坊扩展解决方案，每种都有其权衡与安全模型，包括 L1 分片、L2 状态通道、Plasma、侧链、汇总协议 和 Validium。由于分片技术的演进缓慢且实施复杂，侧链和 Validium 无法继承以太坊的安全性和数据可用性。综合来看，以太坊生态系统目前主要使用汇总（Rollups）扩展解决方案。

至今，Beosin 已成为 ETH L2 的安全合作伙伴，如 Manta Network 和 StarkNet。在过去的审计中，多个知名区块链通过了 Beosin 的链安全审计，包括 Ronin Network、Manta Network、Merlin Chain、Clover、Self Chain、Crust Network 等。Beosin 现发布 ETH L2 的审计解决方案，为 ETH L2 生态系统提供全面的安全审计服务。

以太坊 L2 通过汇总协议将数百笔交易打包成一次性交易提交到以太坊主网，从而将交易费用分摊给所有汇总协议用户，降低了每个用户的费用。汇总协议的交易数据会提交到 L1，但执行过程由汇总协议独立完成。通过将交易数据提交到 L1，汇总协议能够继承以太坊的安全性，因为一旦数据上传到 L1，回滚汇总协议的交易就必须回滚到 L1 上。

目前，汇总协议有两种主要实现方式：

1. 乐观汇总协议：通过经济激励和博弈论验证交易，例如 Arbitrum、Base、OP、Blast 等。
2. 零知识汇总协议：使用零知识证明确保安全性和隐私性，例如 Scroll、Linea、zkSync、StarkNet 等。

乐观汇总

简介

乐观汇总（Optimistic Rollups）是一种通过将计算和状态存储移至链下来扩展以太坊的方法。它在链下执行交易，但将交易数据作为调用数据或 blob 发布到以太坊主网。

乐观汇总在以太坊上部署一个称为汇总合约的智能合约，用于管理汇总的状态、追踪用户余额、处理存款、提现以及争议解决。交易由链下的排序器（sequencer）收集并汇总，将多笔交易打包成一个汇总区块，区块中包含账户状态的新摘要和加密证明（默克尔树根）。排序器随后通过提供默克尔树根和调用数据，将汇总区块提交到主链上。

乐观汇总被称为“乐观”的原因是它假设链下交易是有效的，并且不会发布交易批次的有效性证明。相反，它依赖欺诈证明机制来检测错误计算的交易。在将汇总批次提交到以太坊后，会有一个时间窗口（称为质疑期），在此期间，任何人都可以通过计算欺诈证明来质疑某笔汇总交易的结果。欺诈证明包含验证者认为有问题的特定交易细节。

如下图所示，目前大多数汇总协议的质疑期为 7 天，最短为 1 天。

在质疑期内，任何人都可以通过计算欺诈证明质疑交易结果。如果交易无效，汇总区块将被撤销，质疑者将获得奖励，而排序器将受到惩罚。

如果汇总批次在质疑期内未受到质疑（即所有交易均已正确执行），则该批次被视为有效并在以太坊上接受。其他人可继续扩展未确认的汇总区块，但需注意，如果交易基于之前发布的错误执行，交易结果将会被回滚。

最后，用户需要向汇总合约提交提现请求，将资金从 L2 提现至 L1。合约会验证用户在汇总上的余额是否充足，并相应地更新其主链余额。

领先的 L2 网络

1. Arbitrum

通过生态建设和空投，Arbitrum 很快成为 ETH L2 中最活跃的网络，TVL（总锁仓量）超过 27 亿美元。在大规模空投之后，Arbitrum 团队推出了 Arbitrum Orbit 计划，鼓励开发者使用 Arbitrum 相关技术构建 L3。Beosin 已完成对 ArbSwap 和 Arbipad 的安全审计，助力 Arbitrum 生态的安全发展。

1. Optimism

尽管 Optimism 的生态活跃度不如 Arbitrum，但其于 2023 年推出的 OP Stack 作为构建模块化 L2 的完整解决方案，获得了广泛的行业认可。超过 25 个 L2 网络基于 OP Stack 构建，包括 Base、Mantle、Manta、OP BNB 和 Celo 等明星项目。基于 Optimism 的 DIPX Finance 和 Starnet 已通过 Beosin 的安全审计。

1. Base

Base 是基于 OP Stack 的 L2 网络，在生态活跃度和 TVL 方面仅次于 Arbitrum。此前，Beosin 已详细分析了 Base 的架构和安全风险，并审计了 Surf Protocol 和 EDA，帮助项目方和用户规避安全风险。

1. Blast

在“Big Bang”开发者竞赛结束后，Blast 的 TVL 飙升至 20 亿美元以上，跻身 L2 赛道。Beosin 在 Blast 主网上线前分析了其网络安全性。由于 Blast 未实现欺诈证明，资产被存放在多签钱包中，而非汇总桥，因此存在高度中心化风险。Beosin 审计了多个 Blast 生态项目，如 Wand Protocol、Zest 和 Kalax。

架构分析

OP Stack 作为成熟的乐观汇总框架，通过提供完整的软件组件、工具和框架，简化了构建乐观汇总链的复杂过程。以下以 OP Stack 框架为例，分析乐观汇总的典型架构。

● 执行节点：Op-geth 是以太坊的一个扩展执行客户端，负责处理 L2 特定功能，例如接收来自 L1 的代币存款。该层定义了负责执行状态变化的所有功能。在这里，状态转换是基于从汇总节点（排序器和验证者）通过引擎 API 接收到的输入触发的。

● Rollup 节点：包括排序器和验证者。整理者负责将 L2 处理的交易进行批处理并发布到 L1。排序者定义了 L2 链上交易被收集和发布的方式。验证者/验证人检查批处理交易的有效性，并在检测到欺诈时提交证据。

● 欺诈证明：Cannon 是 Geth 的升级版本，负责在欺诈检测和证明阶段运行 EVM。它本质上是一个链上争议引擎，通过 API 与排序器和验证者协调，以证明虚假交易。

● 批处理提交：排序器将所有已处理的交易一次性批处理，经过验证者的验证后，排序器将批处理的交易提交至 L1。

● 桥合约：部署在以太坊和 L2 上，允许用户在 L1 和 L2 之间传递消息和转移资产。

在乐观汇总的技术架构下，确保用户资产在 L1 和 L2 之间移动时的安全性至关重要。以下是关于用户如何在这两层协议之间访问资产以及系统如何保持这些交易的完整性和安全性的详细说明。

● 资产桥接到汇总协议：用户将资金存入 L1 上的汇总链桥合约。链桥合约将交易中继到 L2，在乐观汇总协议中铸造等量的资产，并将其发送到用户选择的地址。 用户生成的交易（如从 L1 到 L2 的存款）通常会排队，直到排序器重新将其提交到汇总合约。然而，为了保持抗审查性，如果交易延迟超过了允许的最大时间，乐观汇总允许用户直接向链上汇总合约提交交易。

● 从汇总协议提现资产：由于欺诈证明机制，从乐观汇总协议到以太坊的提现过程更加复杂。如果用户发起从 L2 到 L1 的提现交易以提取 L1 上管理的资金，他们需要等待质疑期结束，通常持续约 7 天。 当用户在汇总协议上发起提现请求时，交易将被包含在下一个批处理中，用户在汇总上的资产将被销毁。一旦批次在以太坊上发布，用户可以计算一个默克尔证明，以验证其退出交易是否包含在区块中。接下来用户需要等待延迟期结束，在 L1 上完成交易并将资金提取至主网。

为了避免在提现时等待一周，乐观汇总协议的用户可以向流动性提供者（LP）请求预付款，LP 接管待处理的提现，并向用户支付 L1 上的资金，收取一定费用。流动性提供者可以通过自行检查链上数据，验证用户提现请求的有效性，然后释放资金。这样，他们可以确保交易最终会被确认，从而实现信任的可验证性。

审计项目

L2 是一个完整的区块链系统，因此公链的常规审计也适用于乐观汇总协议，详细内容见本文结尾的附录。

此外，由于其特殊性，乐观汇总协议还需要进行以下额外审计：

● 数据可用性证明：确保 L2 的交易数据在 L1 上可用，以防止数据丢失。

● 数据同步机制：检查 L1 和 L2 之间的数据同步机制是否健全，能否处理如网络分区等异常情况。

● 欺诈证明合约：验证欺诈证明合约的实现是否正确。

● 挑战期机制：检查质疑期的时长是否合理，欺诈证明能否在规定时间内完成。

● 欺诈证明提交过程：检查欺诈证明的提交过程是否安全。

● 存取款过程：检查从 L1 到 L2 和从 L2 到 L1 的存款和提现流程，确保流程的安全性。

● 资产铸造和销毁：检查 L2 上的资产铸造和销毁逻辑，以确保与 L1 资产的正确对应关系。

● 流动性提供者机制：如果存在流动性提供者（LP）机制，需要审查 LP 的操作流程及其安全性。

零知识汇总

简介

零知识汇总协议（ZK Rollup）是一种基于零知识证明的 L2 扩展解决方案。它主要在链下执行复杂的计算和生成证明，在链上验证证明并存储部分数据，以确保数据的可用性。

零知识汇总协议是一种“混合扩展方案”，它是一个在链下独立运行的协议，但从以太坊中获取安全性。具体而言，以太坊网络会强制执行零知识汇总协议上状态更新的有效性，并保证每次 汇总状态更新时的后台数据可用性。汇总协议的状态由部署在以太坊网络上的智能合约维护。为了更新这一状态，零知识汇总协议节点必须提交有效性证明进行验证。有效性证明是一种加密保障，确保提议的状态变化确实是执行了一批给定交易的结果。这意味着零知识汇总协议只需要提供有效性证明来完成以太坊上的交易，而无需发布所有交易数据。

从零知识汇总协议转移资金到以太坊没有延迟，因为一旦零知识汇总协议合约验证了有效性证明，退出交易就会立即执行。相反，从乐观汇总协议提现会产生延迟，因为任何人都可以使用欺诈证明来质疑一笔退出交易。

领先的 L2 网络

1. zkSync

zkSync 是由 Matter Labs 团队于五年前推出的 L2 解决方案。它利用零知识证明技术实现高效的交易验证，并已筹集 2 亿多美元。zkSync 是使用零知识汇总的生态活动最为活跃的 L2 网络之一，同时 zkSync 也引发了一些争议。Beosin 曾对其领先的 DeFi 项目 SyncSwap 进行了审计，涵盖了代码质量、合约逻辑和安全性、运营模型等方面。

1. StarkNet

StarkNet 使用 ZK-STARK 构建 L2，以提高交易速度并降低交易费用。StarkNet 拥有原生虚拟机（Cairo VM）和开发语言 Cairo，以帮助开发者更安全、更便捷地编写智能合约。Beosin 已成为 StarkNet 的官方安全合作伙伴，完成了 Option Dance 和 Reddio 的安全审计。2024年 8 月 13 日，Reddio 完成了由 Paradigm 领投的种子轮融资，以构建高性能的并行 EVM L2 网络。

1. Scroll

Scroll 通过零知识证明技术进行扩展，并利用硬件加速生成和验证零知识证明，旨在实现字节码级的 EVM 兼容性。这意味着开发者可直接使用 Solidity 和以太坊相关的开发工具来构建智能合约。

架构分析

零知识汇总协议的常见框架包括汇总协议和桥接合约、整理者、聚合器、转发器和生成零知识证明的 Roller 网络。具体架构如下图所示：

• 汇总合约和桥接合约：
  Rollup 合约负责提供汇总交易的数据可用性，验证 zkEVM 的有效性证明，并允许用户在以太坊和汇总协议之间转移资产。它接收来自整理者的 L2 状态根和区块，状态根存储在以太坊状态中，而 L2 区块数据则作为以太坊的调用数据保存。
  桥接合约部署在以太坊和 L2 上，允许用户在 L1 和 L2 之间传递消息和转移资产。

• Sequencer（排序器）：
  Sequencer 提供 JSON-RPC 接口，接受 L2 交易，定期从内存池中提取一批交易进行处理，生成新的 L2 区块和状态根。其实现通常基于 Go-Ethereum（Geth），确保最佳兼容性和最高安全性。

• Coordinator（协调器）：
  当整理者生成新区块时，协调器会被通知，并从整理者处接收该区块的执行跟踪记录。执行跟踪记录随后被发送到 Roller 网络中的随机选定的 Roller，以生成有效性证明。

• Relayer（中继器）：
  中继器监控部署在以太坊和 L2 上的汇总合约和桥接合约。主要职责包括：1）通过监控汇总合约跟踪 L2 区块的数据可用性和验证情况；2）监控以太坊和 L2 桥接的存取事件，并将消息中继到另一端。

• Roller 网络：
  Roller 网络中的 Roller 作为证明者，负责为零知识汇总生成有效性证明。它首先从协调器接收区块执行跟踪记录，将其转换为电路见证，然后使用硬件加速为每个 zkEVM 生成证明，最后使用证明聚合将多个证明汇聚为一个单一证明。

在零知识汇总的技术架构下，要确保用户资产在 L1 和 L2 之间转移的过程中是安全的，这一点至关重要。以下详细介绍了用户如何在两个协议之间访问资产，以及系统如何维护这些交易的完整性和安全性。

• 资产桥接到汇总协议：
  用户通过将代币存入部署在网络链上的零知识汇总合约来进入汇总协议。该交易需要由项目方提交到汇总合约。如果待处理的存款队列开始占满，零知识汇总操作员将接受这些存款交易并将其提交到汇总合约。一旦资金存入汇总协议，用户就可以开始交易处理。
  用户可通过哈希其账户来验证汇总协议上的余额，将哈希值发送到汇总合约，并提供与当前状态根验证的默克尔证明。

• 从汇总协议提取资产：
  用户发起退出交易，将其汇总协议上的资产发送到指定账户进行销毁。如果操作员将交易添加到下一个批次中，用户可以向链上合约提交提现请求。提现请求包括：

  1. Merkle 证明，证明用户的交易已被添加到交易批次中的销毁账户；
  2. 交易数据；
  3. 批次根；
  4. 用于接收存入资金的 L1 网络地址。
• 汇总合约对交易数据进行哈希，检查批次根是否存在，并使用默克尔证明检查交易哈希是否属于批次根的一部分。合约执行退出交易，并将资金发送到用户在 L1 网络上选择的地址。

审计项目

L2 是一个完整的区块链系统，因此区块链的常见审计项目同样适用于零知识汇总协议，具体内容详见本文附录。此外，由于零知识汇总的特殊性，还需进行一些额外的审计：

• 系统安全性证明： 检查所使用的零知识证明方案的安全性和正确性（例如 Groth16、Plonk、Halo2、zk-STARK 等）。
• 电路安全： 检查电路设计和实现中可能存在的漏洞，主要包括以下内容：
  1. 约束不足的电路
  2. 约束过多的电路
  3. 非确定性电路
  4. 算法溢出/下溢
  5. 位长不匹配
  6. 未使用的公共输入被优化掉
  7. 冻结的核心：零知识证明伪造
  8. 可信设置泄露
  9. 已分配但未约束
  10. 不安全的组件使用
  11. 变量精度
• 证明生成和验证： 审查证明生成和验证的过程，以确保其效率和安全性。
• 数据可用性证明： 确保 L2 交易数据在 L1 上可用，以防数据丢失。
• 数据同步机制： 检查 L1 和 L2 之间的数据同步机制是否健全，能否处理网络分区等异常情况。
• 存取过程： 检查从 L1 到 L2 以及从 L2 到 L1 的存取过程，以确保流程的安全性。
• 资产铸造和销毁： 检查 L2 上的资产铸造和销毁逻辑，确保与 L1 资产的正确对应。
• 扫描外部依赖和已知漏洞： 零知识汇总协议通常依赖于第三方的加密和数学库或工具，因此需要对这些依赖项的安全性进行全面审查，并检测和验证已知的漏洞。

附录

区块链与 L2 通用审计项目：

• 整数溢出： 检查整数溢出和整数下溢。
• 循环： 检查程序循环条件是否合理。
• 无限递归调用： 检查程序递归调用的退出条件是否合理。
• 竞争条件： 检查并发状态下对共享资源的访问。
• 异常崩溃： 检查是否存在导致程序主动退出的异常抛出代码。
• 除以零漏洞： 检查是否存在除以零的情况。
• 类型转换： 检查类型转换是否正确，转换过程中是否丢失重要信息。
• 数组越界： 检查是否存在访问数组边界外元素的情况。
• 反序列化漏洞： 检查反序列化过程中是否存在问题。
• 函数实现安全： 检查 RPC 接口的实现是否存在安全风险，是否与 RPC 接口的功能设计一致。
• 敏感 RPC 接口权限设置是否合理： 检查敏感 RPC 接口的访问权限设置。
• 加密传输机制： 检查是否使用了加密传输协议，如 TLS。
• 请求数据格式解析： 检查请求数据的格式解析过程。
• 钱包解锁攻击： 当节点解锁钱包时，RPC 请求窃取资金。
• 传统 Web 安全： 检查以下漏洞：跨站脚本（XSS）/模板注入/第三方组件漏洞/HTTP 参数污染/SQL 注入/XXE 实体注入/反序列化漏洞/SSRF 漏洞/代码注入/本地文件包含/远程文件包含/命令执行注入等传统漏洞。
• 网络节点身份认证和识别机制： 检查是否存在节点身份识别机制，节点身份识别机制是否可以被规避。
• 路由表污染： 检查路由表是否可以被随意插入或覆盖。
• 节点发现算法： 检查节点发现算法是否均衡且不可预测，例如距离算法是否不均衡。
• 连接使用审计： 检查 p2p 网络连接的数量限制和管理是否合理。
• 日食攻击： 评估日食攻击的成本和危害，如有必要，提供定量分析。
• Sybil 攻击： 评估投票共识机制，并分析投票资格检查策略。
• 窃听攻击： 检查通信协议是否泄露隐私。
• 外来攻击： 评估节点是否能够识别相同类型的链节点。
• 时间劫持： 检查节点的网络时间计算机制。
• 内存耗尽攻击： 检查是否存在大内存消耗。
• 硬盘耗尽攻击： 检查大文件的存储位置。
• 套接字压力攻击： 检查对链接数量的限制政策。
• 内核句柄耗尽攻击： 检查内核句柄创建的限制，例如文件句柄。
• 持久性内存泄漏： 检查内存泄漏问题。
• 哈希算法安全： 检查哈希算法的碰撞抵抗能力。
• 数字签名算法安全： 检查签名算法及其实现的安全性。
• 加密算法安全： 检查加密算法及其实现的安全性。
• 随机数生成器安全： 检查密钥随机数生成算法的合理性。
• BFT 实现安全： 评估 BFT 算法的实现安全性。
• 分叉选择规则： 检查分叉选择规则以确保安全。
• 中心化程度测试： 识别系统设计中是否存在过度中心化的设计。
• 激励审计： 评估激励对安全性的影响。
• 双花攻击： 检查共识机制是否能防御双花攻击。
• MEV 攻击审计： 检查区块打包节点的 MEV 对链公平性的影响。
• 区块同步过程审计： 检查同步过程中的安全问题。
• 区块格式解析过程审计： 检查格式解析过程中是否存在安全问题，例如解析错误导致崩溃。
• 区块生成过程审计： 检查区块生成过程中的安全问题，包括默克尔树根的构建是否合理。
• 区块验证过程审计： 检查区块签名项和验证逻辑是否充足。
• 区块验证逻辑审计： 检查区块验证算法和实现是否合理。
• 区块哈希碰撞： 检查区块哈希碰撞的构建方式及其处理是否合理。
• 区块处理资源限制： 检查孤立区块池、验证计算、硬盘寻址等资源限制是否合理。
• 交易同步过程审计： 检查同步过程中的安全问题。
• 交易哈希碰撞： 检查交易哈希碰撞的构建方式及其处理方式。
• 交易格式解析： 检查格式解析过程中的安全问题，例如解析错误导致崩溃。
• 交易有效性检查： 检查每种交易的签名项和验证逻辑是否充足。
• 交易处理资源限制： 检查交易池、验证计算和硬盘寻址等资源限制是否合理。
• 交易可变性攻击： 检查交易是否可以通过更改内部字段（如 ScriptSig）来改变交易哈希，而不影响交易的有效性。
• 交易重放攻击审计： 检查系统对交易重放的检测能力。
• 合约字节码检查： 检查虚拟机合约验证过程的安全性，如整数溢出和死循环。
• 合约字节码执行： 检查虚拟机字节码执行过程的安全性，如整数溢出、死循环等。
• Gas 模型： 检查每个原子操作的费用是否与资源消耗成正比。
• 日志完整性： 检查关键信息是否被记录。
• 日志安全： 检查日志处理是否不当造成的安全问题，例如整数溢出。
• 日志包含隐私信息： 检查日志中是否包含密钥等隐私信息。
• 日志存储： 检查日志记录内容是否过多，是否消耗了节点资源。
• 节点代码供应链安全： 检查所有第三方库、组件及公链框架版本的已知问题。

声明：

1. 本文转载自[beosin]，著作权归属原作者[beosin]，如对转载有异议，请联系Gate Learn团队，团队会根据相关流程尽速处理。
2. 免责声明：本文所表达的观点和意见仅代表作者个人观点，不构成任何投资建议。
3. 文章其他语言版本由Gate Learn团队翻译， 在未提及Gate.io的情况下不得复制、传播或抄袭经翻译文章。