前Arbitrum技术大使解读Arbitrum的组件结构（上）
本文是Arbitrum前技术大使 及 智能合约自动化审计公司Goplus Security前联创
@BenWAGMI
对Arbitrum One的技术解读。
由于Arbitrum的结构太复杂，全文在尽可能简化的基础上，还是超过了1万字篇幅，所以分成了上下两篇，建议作为参考资料收藏转发！
11
19
55
Replies
Rollup排序器简述
Rollup扩容原理概括为两点：
成本优化：将⼤部分运算与存储任务移交至L1链下，也即L2上。L2大多是运⾏在单台服务器，也即排序器（Sequencer/Operator）上的⼀条链。
排序器在观感上接近于一台中心化服务器，舍弃“去中心化”来换取TPS与成本上的优势。
1
0
2
安全保障：L2上的交易内容与交易后的状态，会同步⾄以太坊L1，通过合约来校验 状态转换有效性
以太坊上会保留L2的历史记录，排序器即便永久宕机，他⼈也可以通过以太坊上的记录，还原出整个L2的状态
Rollup安全性基于以太坊。排序器如果不知道某个账户的私钥，就无法成功盗取或篡改该账户的资产余额
1
0
0
虽然排序器作为系统中枢带有中⼼化色彩，但在成熟度比较高的Rollup方案中，中心化排序器仅能实施交易审查等软性作恶⾏为，或者恶意宕机，
比如路印协议和DeGate，有采用相应的⼿段实现抗审查（比如强制提款或排序证明等）
1
1
2
防止Rollup排序器作恶的状态校验⽅式，分为欺诈证明和有效性证明两类
使⽤欺诈证明的Rollup⽅案称为OP Rollup（OPR）
Arbitrum One是典型的OPR，它部署在L1上的合约，并不主动验证提交过来的数据，乐观地认为这些数据没有问题。如果提交的数据有错误，L2的验证者节点会主动发起挑战
1
0
0
因此OPR也暗含一条信任假设：任意时刻⾄少有⼀个诚实的L2验证者节点。⽽ZKR的合约则通过密码学计算，主动但低成本地验证排序器提交的数据。
本文会深度介绍乐观式Rollup中的龙头项目——Arbitrum One，覆盖整个系统的方方面面，仔细阅读完后你将对Arbitrum和乐观式Rollup/OPR有深刻的理解。
1
0
1
Arbitrum核心组件与工作流程
核心合约：
Arbitrum最重要的合约包括SequencerInbox, DelayedInbox, L1 Gateways, L2 Gateways, Outbox, RollupCore, Bridge 等。后续将详细介绍
排序器Sequencer：
接收用户交易并进行排序，计算交易结果，并迅速返还给用户回执。用户体验就如同Web2平台
1
0
1
同时，排序器会在以太坊链下即时广播最新的L2 Block，任何一个L2节点都可以接收。但此时，这些L2 Block不具备最终性，可以被排序器回滚
每隔几分钟，排序器会将排序后的L2交易数据压缩聚合成批次（Batch），提交至Layer1上的收件箱合约SequencerInbox，以保证Rollup协议的运转
1
0
0
一般而言，被提交至Layer1上的L2数据无法回滚，可以具备最终确定性。
从以上流程中我们可以概括：Layer2有自己的节点网络，但这些节点数量稀少，且一般没有公链惯用的共识协议，所以安全性是很差的，
必须要依附于以太坊来保证，数据发布的可靠性与状态转换的有效性。
1
0
0
Arbitrum Rollup协议：
定义了Rollup链的区块RBlock 的结构，链的延续方式，RBlock的发布，以及挑战模式流程等⼀系列的合约。
注意，这⾥说的Rollup链并不是大家理解的Layer2账本，而是Arbitrum One为了施展欺诈证明机制，而独立设置的一条抽象出来的“链状数据结构”。
1
0
0
⼀个RBlock可以包含多个L2区块的结果，⽽且数据也迥异，它的数据实体 RBlock 存储在RollupCore的⼀系列合约中。
如果⼀个 RBlock 存在问题，Validator将⾯向该RBlock的提交者对其进⾏挑战。
1
0
0
验证者Validator：
Arbitrum的验证者其实是Layer2全节点的特殊子集，目前有白名单准入
Validator根据排序器提交至SequencerInbox合约的交易批次batch，来创建新的RBlock（Rollup区块，也叫断⾔assertion），并监控当前Rollup链的状态，对排序器提交的错误数据进⾏挑战。
1
0
0
主动型的Validator需要事先在ETH链上质押资产，有时我们也称其为Staker。
不进⾏质押的Layer2节点虽然也可以监控Rollup的运⾏动态，向⽤户发送异常报警等，但⽆法在ETH链上直接对排序器提交的错误数据进行⼲预。
1
0
0
挑战：
步骤可以概括为多轮互动式细分、单步证明。
在细分环节，挑战双⽅先对有问题的交易数据进⾏多轮回合制细分，直⾄分解出有问题的那⼀步操作码指令，并进⾏验证。
“多轮细分-单步证明” 这种范式，被认为是欺诈证明中最节省gas的实现⽅式。所有环节都在合约控制之下，没有⼀⽅可以作弊。
1
0
0
挑战期：
由于OP Rollup的乐观optimistic本质，每个RBlock提交上链后，合约并不主动检查，预留给验证者一段时间窗⼝期去证伪。此时间窗⼝即为挑战期，在Arbitrum One主⽹上为1周。
挑战期结束后，该RBlock才会被最终确认，块内对应的从L2传递到L1的消息（比如通过官方桥执行的提款操作）才能被放行
1
0
1
ArbOS, Geth, WAVM：
Arbitrum采用的虚拟机名为AVM，包含Geth和ArbOS两部分。Geth是以太坊最常⽤的客户端软件，Arbitrum对其进⾏了轻量化的修改。
ArbOS负责所有L2相关的特殊功能，如⽹络资源管理、⽣成L2区块、与EVM协同⼯作等。我们将两者的组合视为⼀个Native AVM，也就是Arbitrum采用的虚拟机。
1
0
0
WAVM是把AVM的代码编译为Wasm后的结果。Arbitrum挑战流程中，最后的那个“单步证明”，验证的就是WAVM指令。
1
0
1
L2交易生命周期
一笔L2交易的处理流程如下：
1.用户向排序器发交易
2.排序器对待处理交易进数字签名等数据验证，剔除无效交易，并进行排序和运算
3.排序器将交易回执发给⽤户（⾮常快），但这是在ETH链下进行的“预处理”，并不可靠。对于信任排序器的⽤户，可乐观的认为交易已完成，不会回滚
1
0
0
4.排序器将预处理后的交易原始数据，⾼度压缩后封装为⼀个Batch（批次）。
5.每隔⼀段时间（受到数据量、ETH拥堵程度等因素影响），排序器会向L1上的 Sequencer Inbox 合约发布交易Batch。此时可认为，交易已拥有最终性Hard Finality。
2
0
0
Sequencer Inbox合约
合约会接收排序器提交的交易batch，保证数据可⽤性。
深⼊地看，SequencerInbox中的batch数据完整记录了Layer2的交易输入信息，即使排序器永久宕机，任何⼈都可以根据batch的记录还原Layer2的当前状态，接替故障/跑路的排序器。
1
0
0
Sequencer Inbox合约⼜称快箱，排序器专门向其提交已预处理的交易，且只有排序器可向其提交数据。
Validator会监听SequencerInbox合约，每当排序器向该合约发布Batch后，就会抛出一个事件
Validator监听到这个事件发生，就会去下载batch数据，在本地执⾏后，向ETH链上的Rollup协议合约发布RBlock
1
0
0
Arbitrum的bridge合约内有个叫累加器accumulator的参数，会针对新提交的L2 batch，以及慢Inbox上新接收的交易数和信息，进行记录。
（下图是Batch的具体信息，data字段对应着Batch数据，这部分数据尺寸很大，截图没显示完）
1
0
0
SequencerInbox合约有两个主要函数：
add Sequencer L2Batch From Origin()，排序器每次都会调用该函数，向Sequencer Inox合约提交Batch数据。
force Inclusion()，该函数任何人都可以调用，用于实现抗审查交易。这个函数的生效方式，会在后面谈到Delayed Inbox合约时详细解释。
1
0
0
Gas定价
显然，L2交易不可能免费，因为这会引来DoS攻击，另外则是排序器本身的运⾏成本，在L1上提交数据都会有开销
⽤户在Layer2发起交易时，gas费结构如下
占用Layer1资源产生的数据发布成本，主要来自于排序器提交的batch（每个batch有很多用户的交易），成本最终由交易发起者们均摊
3
0
0
数据发布产生的手续费定价算法是动态的，排序器会根据近期的盈亏状况、batch⼤⼩、当前以太坊gas价格进⾏定价。
用户因占用Layer2资源产生的成本，设定了⼀个可以保证系统稳定运⾏的，每秒处理的gas上限（⽬前Arbitrum One是700万）。
L1和L2的gas指导价格均由ArbOS跟踪并调整，公式暂时不在此赘述。
1
0
1
乐观式欺诈证明
所谓的乐观式证明中，合约不会去检查提交到L1的输出状态是否正确，乐观地认为一切都是准确无误的。
乐观证明系统会假设，在任意时刻都有⾄少⼀名诚实的Validator，如果出现错误的状态，则通过欺诈证明进⾏挑战。
1
0
0
这么设计的好处是，不需要主动验证每⼀个发布到L1上的RBlock，避免浪费gas。实际上对于OPR⽽⾔，对每⼀个断⾔进⾏验证也是不现实的
因为每个 Rblock都包含着一或多个L2区块，要在L1上去对每笔交易重新执⾏⼀遍，与直接在L1上执行L2交易无异，这就失去了Layer2扩容的意义
1
0
0
欺诈证明虽然不能像零知识证明那样具有⾼度的简洁性，但Arbitrum使⽤了⼀种“多轮分割-单步证明”的轮流式交互流程，最终需要证明的仅仅是单⼀的虚拟机操作码，成本相对较⼩。
1
0
1
Rollup协议
我们先来看一下，发起挑战和启动证明的入口，也即Rollup协议是如何工作的。
Rollup协议的核心合约是RollupProxy.sol，在保证数据结构一致的情况下，使用了一个罕见的双重代理结构，一个代理对应两个实现RollupUserLogic.sol和RollupAdminLogic.sol
1
0
0
另外还有ChallengeManager.sol合约负责管理挑战，OneStepProver系列合约来判定欺诈证明。
在RollupProxy中，记录由不同Validator提交的一系列RBlock（aka断言），也即下图中的方块：绿色-已确认，蓝色-未确认，黄色-已证伪。
1
0
0
RBlock中包含了自上一个RBlock以来，一个或多个L2区块执行后的最终状态。这些RBlock在形态上构成了一条形式上的Rollup Chain（注意与L2账本本身相区别）
在乐观情况下，这条Rollup Chain应该是没有分叉的，因为有分叉意味着有Validator提交了彼此冲突的Rollup Block
1
0
1