前Arbitrum技术大使解读Arbitrum组件结构（下）

由于中文社区对Layer2协议相关的文章或资料，特别是Arbitrum和OP Rollup缺乏专业解读，本文旨在通过解释Arbitrum的运行机制来填补这一空白。由于Arbitrum本身的复杂性，全文即使在尽可能简化后，仍然超过一万字。因此分为两部分，建议保存并分享作为参考资料。”

Rollup Sequencer 概述

Rollup 缩放的原理可以概括为两点：

成本优化：将大部分计算和存储任务转移到第2层，第2层在L1下运行。 L2 主要运行在单个服务器上，称为定序器/运算符，形成单独的链。

排序器在感知上几乎就像一个中心化服务器，放弃了“区块链不可能三位一体”中的去中心化，以获得 TPS 和成本上的优势。用户可以使用L2代替以太坊来处理交易指令，与以太坊上的交易相比，成本要低得多。

（来源：BNB链）

安全保障：L2上的交易内容和交易后状态同步到以太坊L1，并通过状态转换合约验证其有效性。同时，以太坊保留了L2的历史，因此即使定序器永久崩溃，其他人也可以通过以太坊记录重建L2的整个状态。

从根本上来说，Rollup 的安全性依赖于以太坊。如果排序器不知道账户的私钥，它就无法代表该账户发起交易或操纵该账户的资产余额（即使尝试，也会很快被检测到）。

虽然排序器作为中心枢纽具有中心化的一面，但在成熟的 Rollup 解决方案中，中心化排序器只能从事软恶意活动，例如交易审查或恶意崩溃。在理想的Rollup场景中，有相应的措施来约束此类行为，例如强制提款或反审查机制的序列证明。

（路印协议在L1的合约源码中设置了强制提现功能供用户调用）

防止 Rollup 排序器恶意行为的状态验证机制分为两类：欺诈证明和有效性证明。使用Fraud Proof的Rollup解决方案被称为OP Rollup（Optimistic Rollup，OPR），而使用Validity Proof的解决方案由于历史包袱，通常被称为ZK Rollup（Zero-knowledge Proof Rollup，ZKR）而不是Validity Rollup。

Arbitrum One 是一种典型的 OPR，部署在 L1 上，合约不会主动验证提交的数据，乐观地假设数据是正确的。如果提交的数据有错误，L2验证节点会主动发起挑战。

因此，OPR 隐含着一种信任假设：在任何给定时间，至少有一个诚实的 L2 验证节点。另一方面，ZKR 合约通过密码计算主动且廉价地验证排序器提交的数据。

（Optimistic Rollup操作方法）

（ZK Rollup操作方法）

本文深入介绍了 Optimistic Rollup 中的领先项目——Arbitrum One，涵盖了整个系统的方方面面。仔细阅读后，您将对Arbitrum和Optimistic Rollup/OPR有深刻的理解。

Arbitrum 核心组件和工作流程

核心合约：

Arbitrum 中最重要的合约包括 SequencerInbox、DelayedInbox、L1 Gateways、L2 Gateways、Outbox、RollupCore、Bridge 等。这些将在下面的章节中详细介绍。

定序器：

排序器接收用户交易，对其进行排序，计算交易结果，并快速（通常<1s）将收据返回给用户。用户通常会在几秒钟内看到 L2 上的交易，提供类似于 Web2 平台的体验。

同时，排序器立即在以太坊链下广播最新生成的 L2 区块。任何 Layer2 节点都可以异步接收这些 L2 块。然而，这些 L2 块此时还没有最终确定性，可以被定序器回滚。

每隔几分钟，排序器就会压缩排序后的 L2 交易数据，将其聚合成批次，并提交到 Layer1 上的 SequencerInbox 合约，以确保数据可用性和 Rollup 协议的运行。一般情况下，提交给Layer1的L2数据是不可回滚的，具有最终确定性。

从上面的过程我们可以总结出：Layer2有自己的节点网络，但是这些节点数量稀疏，而且一般没有公链常用的共识协议，所以安全性很差。它必须依靠以太坊来保证数据发布的可靠性和状态转换的有效性。性别。

仲裁汇总协议：

这是一系列合约，定义了Rollup链区块RBlock的结构、链的延续方式、RBlock的释放以及挑战模式流程。注意，这里所说的Rollup链并不是大家理解的二层账本，而是Arbitrum One为了实现防欺诈机制而独立设立的一个抽象的“链状数据结构”。

一个RBlock可以包含多个L2块的结果，数据也有很大差异。其数据实体RBlock存储在RollupCore中的一系列合约中。如果 RBlock 存在问题，Validator 将向 RBlock 的提交者发起挑战。

验证器：

Arbitrum 的验证器节点实际上是第 2 层完整节点的特殊子集，目前可以访问白名单。

Validator根据sequencer向SequencerInbox合约提交的交易批次创建新的RBlock（Rollup区块，也称为断言），并监控当前Rollup链的状态并对sequencer提交的错误数据提出质疑。

Active Validator 需要提前在 ETH 链上质押资产。有时我们也称其为Staker。不进行质押的二层节点虽然也可以监控Rollup的运行动态并向用户发送异常警报，但无法直接干预ETH链上排序器提交的错误数据。

挑战：

基本步骤可以概括为多轮交互分割和一步证明。在分割过程中，挑战方首先对有问题的交易数据进行多轮分割，直至分解出有问题的操作代码指令并进行验证。 “多轮分割-一步证明”的范式被Arbitrum开发者认为是最节省gas的欺诈证明实现。所有环节均受合约控制，任何一方不得作弊。

挑战期：

由于OP Rollup的乐观本质，每个RBlock提交到链上后，合约并不会主动检查，给验证者留下了作假的窗口期。这个窗口期就是挑战期，在Arbitrum One主网上需要1周的时间。挑战期结束后，RBlock将最终得到确认。只有区块内从L2传递到L1的相应消息（例如通过官方桥进行的提现操作）才能被释放。

ArbOS、Geth、WAVM：

Arbitrum使用的虚拟机称为AVM，包括Geth和ArbOS。 Geth是以太坊中最常用的客户端软件，Arbitrum对其进行了轻量级的修改。 ArbOS 负责所有与 L2 相关的特殊功能，例如网络资源管理、生成 L2 块、与 EVM 配合等。我们将两者的组合视为 Native AVM，也就是 Arbitrum 使用的虚拟机。 WAVM 是将 AVM 代码编译成 Wasm 的结果。在 Arbitrum 挑战过程中，最后的“一步证明”验证了 WAVM 指令。

这里，我们可以用下图来表示上述组件之间的关系和工作流程：

L2 上的事务生命周期

一笔交易在L2上的处理流程如下：

1. 用户向定序器发送交易指令。

2. 排序器首先将待处理的交易验证为数字签名等数据，剔除无效交易，并进行排序和计算。

3. 排序器将交易收据发送给用户（通常非常快），这只是 ETH 链下排序器进行的“预处理”。处于Soft Finality状态，不可靠。但对于信任定序器的用户（大多数用户）来说，他们可以乐观地认为事务已经完成并且不会回滚。

4. 排序器将预处理后的原始交易数据高度压缩，封装成Batch。

5. 每隔一段时间（受数据量和 ETH 拥堵等因素影响），排序器会向 L1 上的 Sequencer Inbox 合约发布交易批次。此时，可以认为该交易具有Hard Finality。

定序器收件箱合同

合约将接收排序器提交的交易批次，以确保数据可用性。如果我们深层次地看的话，Sequencer Inbox 中的批量数据完整地记录了 Layer2 的交易输入信息。即使定序器永久宕机，任何人都可以根据批次记录恢复第 2 层当前状态，并更换故障/运行的定序器。

从物理的角度来理解，我们看到的L2只是batch在SequencerInbox中的投影，光源是STF。由于光源 STF 不易改变，因此阴影的形状仅由作为对象的批次决定。

Sequencer Inbox 合约被称为快速盒子。排序器专门向其提交预处理后的交易，并且只有排序器可以向其提交数据。对应的快盒是慢盒Delayer Inbox，其功能将在后续流程中介绍。

验证器将始终监控 Sequencer Inbox 合约。每当定序器向合约发布批次时，就会产生一个链上事件。 Validator检测到该事件发生后，会下载批量数据。本地执行后，RBlock将发行至ETH链上的Rollup协议合约。

Arbitrum 的桥接合约有一个称为累加器的参数，它记录了新提交的 L2 批次，以及慢速 Inbox 上新收到的交易的数量和信息。

（排序器不断地将批次提交到排序器收件箱）

（该批次的具体信息；数据字段对应批次数据。这部分数据量很大，截图无法完全显示。）

SequencerInbox 合约有两个主要功能：

从 Origin() 添加 Sequencer L2Batch

sequencer每次都会调用该函数，将Batch数据提交到Sequencer Inox合约。

强制包含()

该函数可以被任何人调用，用于实现抗审查交易。该功能的生效方式将在后面讲Delayed Inbox合约时详细解释。

以上两个函数将调用bridge.enqueueSequencerMessage()来更新桥合约中的累加器参数。

汽油定价

显然，L2 交易不可能是免费的，因为这会导致 DoS 攻击。另外，排序器L2本身就有运营成本，在L1上提交数据也会有开销。当用户在第 2 层网络内发起交易时，Gas 费用结构如下：

占用Layer1资源产生的数据发布成本

这个成本主要来自于排序者提交的批次（每个批次有很多用户交易），成本最终由交易发起者平均分担。数据发布生成的费用定价算法是动态的，排序器将根据近期盈亏状况、批量大小以及当前以太坊 Gas 价格进行定价。

用户占用二层资源产生的费用

为保证系统稳定运行，设置了TPS的gas limit（目前Arbitrum One为700万）。 L1和L2的Gas指导价均由ArbOS跟踪和调整，公式暂不详述。

虽然具体的gas价格计算过程比较复杂，但用户不需要了解这些细节，就能明显感觉到Rollup交易费用比ETH主网便宜很多。

乐观欺诈证明

回想一下上面的内容，L2其实只是排序器提交的交易输入批次在快箱中的投影，即：

交易输入 -> STF -> 状态输出。输入已经确定，STF不变，那么输出结果也确定了。欺诈证明和Arbitrum Rollup协议系统是将输出状态根以RBlock（又名断言）的形式发布到L1并对其进行乐观证明的系统。

在L1上，有排序器发布的输入数据和验证器发布的输出状态。我们仔细考虑一下：是否有必要将 Layer 2 的状态发布到链上？

因为输入已经完全决定了输出，并且输入数据是公开可见的，所以提交输出结果状态是不是显得多余？但这种想法忽略了L1和L2两个系统之间状态结算的实际需要，即L2向L1的提现行为需要状态证明。

在构建Rollup时，核心思想之一就是将大部分计算和存储放在L2上，以避免L1的高成本。这意味着L1不知道L2的状态，它只帮助L2。排序器发布所有交易的输入数据，但不负责计算L2的状态。

提现行为本质上是根据L2给出的跨链消息，从L1合约中解锁相应的资金，转入用户的L1账户或者完成其他事情。

这时候Layer1合约会问：你在Layer 2上的状态是什么，如何证明你确实拥有你声明要转让的资产？这时用户必须提供相应的Merkle Proof等。

因此，如果我们构建一个没有提现功能的 Rollup，理论上是可以不将状态同步到 L1 的，也就不需要欺诈证明等状态证明系统（尽管可能会导致其他问题）。但在实际应用中，这显然是不可行的。

所谓乐观证明，合约并不检查提交给L1的输出状态是否正确，而是乐观地认为一切都是准确的。乐观证明系统假设任何时候至少有一个诚实的验证者。如果出现错误状态，将通过欺诈证明对其提出质疑。

这种设计的优点是不需要主动验证每一个发给L1的RBlock，避免浪费gas。事实上，对于OPR来说，验证每一个断言是不现实的，因为每个Rblock都包含一个或多个L2块，并且每笔交易都必须在L1上重新执行。这和直接在L1上执行L2交易没有什么区别，这使得Layer 2扩展变得毫无意义。

ZKR不存在这个问题，因为ZK Proof是简洁的。它只需要验证一个很小的Proof，不需要实际执行很多与Proof对应的交易。因此，ZKR的经营情况并不乐观。每次状态发布时，都会有一个 Verifier 合约进行数学验证。

虽然欺诈证明无法像零知识证明那样简洁，但 Arbitrum 采用了“多轮分段-一步证明”的回合交互流程。最终需要证明的只是单个虚拟机操作代码，成本也比较小。

汇总协议

我们首先看一下发起挑战和开始证明的入口，即Rollup协议是如何工作的。

Rollup协议的核心合约是RollupProxy.sol，它采用了罕见的双代理结构，同时保证了数据结构的一致性。一个agent对应RollupUserLogic.sol和RollupAdminLogic.sol的两个实现，无法用Scan等工具很好的解析。

此外，ChallengeManager.sol合约负责管理挑战，OneStepProver系列合约用于确定欺诈证明。

（来源：L2BEAT官网）

这显示了在 RollupProxy 中记录了一系列由不同 Validator 提交的 RBlock（又名断言），如下图所示：绿色-确认、蓝色-未确认、黄色-伪造。

RBlock 包含自最后一个 RBlock 以来执行一个或多个 L2 块后的最终状态。这些RBlock形成了一个正式的Rollup Chain（注意L2账本本身是不同的）。乐观情况下，这条 Rollup Chain 应该不会出现分叉，因为分叉意味着 Validator 提交了冲突的 Rollup Block。

为了提出或同意某个断言，验证者需要首先为该断言质押一定数量的 ETH，并成为一名 Staker。这样，当发生挑战/欺诈证明时，失败者的抵押品将被削减。这是保证验证者诚实行为的经济基础。

图片右下角的111号蓝色块最终会被砍掉，因为它的父块104号（黄色）是错误的。

此外，验证者A提出了106号Rollup区块，但B不同意并提出质疑。

B发起挑战后，ChallengeManager合约将负责验证挑战步骤的分段：

1. 切分是双方轮流互动的过程。一方对某个Rollup Block中包含的历史数据进行分段，另一方指出数据片段的哪一部分有问题，这个过程类似于二分法（实际上是N/K），不断逐步缩小范围。

2. 之后可以继续定位有问题的交易和结果，然后进一步细分为交易中存在争议的机器指令。

3. ChallengeManager合约仅检查原始数据分段后生成的“数据碎片”是否有效。

4. 当挑战者和被挑战者找到要挑战的机器指令时，挑战者调用oneStepProveExecution()函数，并发送一步欺诈证明，证明该机器指令的执行结果存在问题。

一步证明

一步证明是整个Arbitrum欺诈证明的核心。我们来看看一步证明具体证明了什么。

这需要先了解 WAVM。 Wasm Arbitrum 虚拟机是由 ArbOS 模块和 Geth（以太坊客户端）核心模块编译而成的虚拟机。由于L2与L1有很大不同，因此原始Geth核心必须稍作修改并与ArbOS配合使用。

因此，L2上的状态转换实际上是ArbOS+Geth Core的共同工作。

Arbitrum的节点客户端（排序器、验证器、全节点等）将上述ArbOS+Geth Core处理程序编译为节点主机可以直接处理的本机机器代码（适用于x86/ARM/PC/Mac/等）。

如果将编译后得到的目标语言改为Wasm，则将得到验证者生成欺诈证明时使用的WAVM，并且验证一步证明的合约也模拟了WAVM虚拟机的功能。

那么为什么生成欺诈证明时需要编译成 Wasm 字节码呢？主要原因是，要验证一步防欺诈的合约，需要使用以太坊智能合约来模拟一个可以处理某一组指令集的虚拟机VM，而WASM很容易对合约实现模拟。

但是，WASM 的运行速度比 Native 机器代码稍慢，因此 Arbitrum 的节点/合约仅在生成和验证欺诈证明时才会使用 WAVM。

经过前几轮交互分割，一步证明最终证明了WAVM指令集中的一步指令。

从下面的代码可以看出，OneStepProofEntry首先判断待证明指令的操作码属于哪一类，然后调用相应的证明者如Mem、Math等，将单步指令传递到证明者合约中。

Hash后的最终结果将返回给ChallengeManager。如果hash与Rollup Block上记录的指令操作后的hash不一致，则挑战成功。如果一致，则说明Rollup Block上记录的这条指令的执行结果没有问题，挑战失败。

在第 2 部分中，我们将分析 Arbitrum，甚至是处理 Layer2 和 Layer1 之间的跨链消息/桥接功能的合约模块，并进一步阐明真正的 Layer2 应如何实现抗审查性。

免责声明：

1. 本文转载自[微信]。所有版权归原作者[罗笨笨]所有。如对此转载有异议，请联系Gate Learn团队，他们将及时处理。
2. 免责声明：本文表达的观点和意见仅代表作者个人观点，不构成任何投资建议。
3. 本文由 Gate Learn 团队翻译成其他语言。除非另有说明，否则禁止复制、分发或抄袭翻译文章。