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

作者：罗奔奔，前Arbitrum技术大使，极客web3贡献者

本文是Arbitrum前技术大使 及 智能合约自动化审计公司Goplus Security前联合创始人罗奔奔 对Arbitrum One的技术解读。

因为中文圈子里涉及Layer2的文章或资料，缺乏对Arbitrum乃至OP Rollup的专业解读，本文试图通过科普Arbitrum的运转机理，填补这一领域的空缺。由于Arbitrum本身的结构太复杂，全文在尽可能简化的基础上，还是超过了1万字篇幅，所以分成了上下两篇，建议作为参考资料收藏转发！

Rollup排序器简述

Rollup扩容的原理可以概括为两点：

成本优化：将⼤部分运算与存储任务移交至L1链下也即L2上。L2大多是运⾏在单台服务器也即排序器（Sequencer/Operator）上的⼀条链。

排序器在观感上接近于一台中心化服务器，在“区块链不可能三⻆”中舍弃“去中心化”来换取TPS与成本上的优势。 ⽤户可以让L2来代替以太坊处理交易指令，成本比在以太坊上交易要低得多。

（图源：BNB Chain）

安全保障：L2上的交易内容与交易后的状态，会同步⾄以太坊L1，通过合约来校验 状态转换的有效性。同时，以太坊上会保留L2的历史记录，排序器即便永久宕机，他⼈也可以通过以太坊上的记录，还原出整个L2的状态。

从根本上来说，Rollup的安全性是基于以太坊的。排序器如果不知道某个账户的私钥，就无法用该账户的名义发起交易，或者无法篡改该账户的资产余额（即便这么做了，也很快被识破）。

虽然排序器作为系统中枢带有中⼼化色彩，但在成熟度比较高的Rollup方案中，中心化排序器仅能实施交易审查等软性作恶⾏为，或者恶意宕机，但在理想状态的Rollup⽅案中，有相应的⼿段进⾏遏制（比如强制提款或排序证明等抗审查机制）。

（路印协议在L1上的合约源码中设置的，供用户调用的强制提款函数）

而防止Rollup排序器作恶的状态校验⽅式，分为欺诈证明（Fraud Proof）和有效性证明（Validity Proof）两类。使⽤欺诈证明的Rollup⽅案称为OP Rollup（Optimistic Rollup，OPR），⽽因为一些历史包袱，使⽤有效性证明的Rollup往往被称为ZK Rollup（Zero-knowledge Proof Rollup，ZKR)，而不是Validity Rollup。

Arbitrum One是典型的OPR，它部署在L1上的合约，并不主动验证提交过来的数据，乐观地认为这些数据没有问题。如果提交的数据有错误，L2的验证者节点会主动发起挑战。

因此OPR也暗含一条信任假设：任意时刻⾄少有⼀个诚实的L2验证者节点。⽽ZKR的合约则通过密码学计算，主动但低成本地验证排序器提交的数据。 

（乐观Rollup运转方式）

（ZK Rollup运转方式）

本文会深度介绍乐观式Rollup中的龙头项目——Arbitrum One，覆盖整个系统的方方面面，仔细阅读完后你将对Arbitrum和乐观式Rollup/OPR有深刻的理解。

Arbitrum的核心组件与工作流程

核心合约：

Arbitrum最重要的合约包括SequencerInbox, DelayedInbox, L1 Gateways, L2 Gateways, Outbox, RollupCore, Bridge等。后续将详细介绍。

排序器Sequencer：

接收用户交易并进行排序，计算交易结果，并迅速（通常<1s）返还给用户回执。用户往往在几秒内就能看到自己的交易在L2上链，体验就如同Web2平台。

同时，排序器还会在以太坊链下即时广播最新产生的L2 Block，任何一个Layer2节点都可以异步的接收。但此时，这些L2 Block不具备最终确定性，可以被排序器回滚掉。

每隔几分钟，排序器会将排序后的L2交易数据进行压缩，聚合成批次（Batch），提交至Layer1上的收件箱合约SequencerInbox，以保证数据可用性和Rollup协议的运转。一般而言，被提交至Layer1上的L2数据无法回滚，可以具备最终确定性。

从以上流程中我们可以概括：Layer2有自己的节点网络，但这些节点数量稀少，且一般没有公链惯用的共识协议，所以安全性是很差的，必须要依附于以太坊来保证，数据发布的可靠性与状态转换的有效性。

Arbitrum Rollup协议：

定义Rollup链的区块 RBlock 的结构，链的延续方式，RBlock的发布，以及挑战模式流程等⼀系列的合约。注意，这⾥说的Rollup链并不是大家理解的Layer2账本，而是Arbitrum One为了施展欺诈证明机制，而独立设置的一条抽象出来的“链状数据结构”。

⼀个RBlock可以包含多个L2区块的结果，⽽且数据也迥异，它的数据实体 RBlock 存储在RollupCore的⼀系列合约中。如果⼀个 RBlock 存在问题，Validator将⾯向该RBlock的提交者对其进⾏挑战。

验证者Validator：

Arbitrum的验证者节点其实是Layer2全节点的特殊子集，目前有白名单准入。