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

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

在上一篇文章《前Arbitrum技术大使解读Arbitrum的组件结构（上）》，我们介绍了Arbitrum核心组件中的 排序器、Validator、SequencerInbox合约、Rollup Block、非交互式欺诈证明的作用，而在今天的文章中，我们将重点讲解Arbitrum核心组件中与跨链消息传递及抗审查交易入口相关的组件。

正文：此前的文章中，我们曾提到，Sequencer Inbox合约专门在Layer1上接收排序器发布的交易数据包Batch。同时，我们指出，Sequencer Inbox又被称作快箱，与之相对的是慢箱Delayed Inbox（简称Inbox）。下面，我们将对Delayed Inbox等与跨链消息传递相关的组件进行细致解读。

跨链与桥接的原理

跨链交易可分为L1到L2（充值）与L2到L1（提现）。注意这⾥所说的充值和提现未必与资产跨链相关，可以是不直接附带资产的消息传递。所以这两个词仅仅表示跨链相关行为的两个⽅向。

跨链交易与纯L2交易相⽐，跨链交易在L1和L2这两个不同的系统中进⾏了信息互换，因此过程更复杂。

另外，通常我们说的跨链⾏为，是在两个毫不相关的⽹络上，⽤⻅证⼈模式的跨链桥进⾏的跨链，这种跨链的安全性取决于跨链桥的运营者，历史上基于见证人模式的跨链桥被盗事件频繁发生。

⽽在Rollup与ETH主⽹之间的跨链⾏为，与上述跨链有本质不同，因为Layer2的状态是由记录在Layer1上的数据决定的，只要你使⽤的是Rollup官⽅的跨链桥，其在运作结构上是绝对安全的。

这也凸显出Rollup的本质，它只是在⽤户角度看，像⼀条独立的链，但实际上所谓的“Layer2”只是Rollup对⽤户敞开的快速展示窗⼝，它的真实链式结构还是刻录在Layer1上。所以，我们可以认为L2算半条链，或者说是“在Layer1上创造出的一条链”。

可重试票据 Retryables

需要注意，跨链都是异步和非原子性的，它不可能像在一条链上一样做完一笔交易确认后就知道结果，也不能保证另一侧一定会在某个时间点发生某些事。因此跨链有可能因为一些软性问题而失败，但只要使用正确的手段，诸如可重试票据（Retryable Ticket），就不会发生资金卡住等硬性问题。

可重试票据是通过Arbitrum官方桥充值时，用到的基本工具，ETH和ERC20的充值都会使⽤到。其⽣命周期分为三步：

1. 在L1上提交票据。在Delayed Inbox合约中使用createRetryableTicket()方法创建充值票据，并提交。

2. L2上自动兑付。大部分情况下，排序器可以自动帮用户兑付票据，无需后续的手动操作。

3. L2上手动兑付。部分边缘情况，如L2上gas价格突然激增，票据上预付的gas不够，则无法自动兑付。此时需要用户手动操作。

注意，如果自动兑付失败，需要在7日内手动兑付票据，否则要么票据将会被删除（资金会永久损失），要么需要为票据的保存支付一定费用来续租。

另外，对于Arbitrum官方桥的提现流程，虽然和充值行为在流程上有一定对称相似性，但并没有Retryables这个概念，一方面可以从Rollup协议本身理解，另一方面我们可以从一些区别进行理解：

提现的过程中不存在自动兑付，因为EVM没有定时器或自动化，而L2上可以实现自动兑付，是排序器帮忙实现的，所以L1上用户要手动与Outbox合约交互，以Claim取回资产。

提现也不存在票据过期的问题，只要过了挑战期，可以在任意时间领取。

ERC-20资产跨链 Gateway

ERC-20资产的跨链是复杂的。我们可以思考几个问题：

一个在L1上部署的代币，它在L2上要如何部署？

它的L2对应合约需要预先手动部署，还是系统可以自动为跨过来的、但尚未部署合约的代币 自动部署资产合约？

L1上的ERC-20资产，在L2对应的合约地址是什么？是否该和L1一致？

在L2上原生发行的代币，如何跨链至L1？

拥有特殊功能的代币，如可调整数量的Rebase型代币，自增长生息代币，如何跨链？

我们不打算全部回答这些问题，因为展开太过复杂。这些问题仅是用来说明ERC20跨链的复杂性。

目前非常多扩容方案使用的都是白名单+手动清单的方案，来规避各种复杂的问题和边界情况。

Arbitrum使用了Gateway系统，解决了大部分ERC20跨链的痛点，具有以下特性：

Gateway组件在L1和L2成对出现。

Gateway Router负责维护Token L1Token L2之间的地址映射，以及some tokensome gateway之间的映射。

Gateway本身可分为StandardERC20 gateway，Generic-custom gateway，Custom gateway等等，用以解决不同类型的和功能ERC20的桥接问题。

我们以比较简单的WETH跨链为例，来说明自定义gateway的必要性。

WETH是一种ETH的ERC20等价物。Ether作为主币，很多dApp中的复杂功能是无法实现的，因此需要一个ERC20的等价物。向WETH合约内转入一些ETH，它们会被锁在合约内，并生成出相同数量的WETH。

同理，也可以销毁WETH，取出ETH。显然，流通的WETH和锁仓的ETH数量永远是1：1的。

如果现在把WETH直接跨链到L2上，我们会发现一些奇怪的问题：

无法在L2上把WETH进行Unwrap变成ETH，因为L2上并没有锁仓对应的ETH。

Wrap功能可以使用，但这些新生成的WETH如果跨回到L1，也无法在L1上解封装为ETH，因为L1和L2上的WETH合约不是“对称的”。

显然这违反了WETH的设计原理。那么WETH在跨链时，不论是充值还是提现，都需要先Unwrap成ETH后，再跨到对面，然后Wrap成WETH。这个也就是WETH Gateway的作用。

其他有更复杂逻辑的代币同理，需要更复杂和精心设计的Gateway才能正常在跨链环境下工作。Arbitrum的自定义Gateway继承了普通Gateway的跨链通信逻辑，并允许开发者自定义与代币逻辑相关的跨链行为，可满足大部分需求。

慢收件箱Delayed Inbox

与快箱也即 SequencerInbox相对应的是慢箱 Inbox （全称Delayed Inbox）。为什么要有快慢之分呢？因为快箱是专⻔接收排序器发布的L2交易Batch的，所有未经排序器在L2网络内预处理的交易，都不该出现在快箱合约中。

慢箱的第⼀点作⽤是，处理L1到L2的充值⾏为。⽤户通过慢箱进⾏充值，排序器监听到后再反映在L2上，最终这笔充值记录会被排序器包含进L2的交易序列中，并提交⾄快箱合约Sequencer Inbox。

在这个例⼦中，⽤户直接向快箱提交充值交易是不合适的，因为提交到快箱Sequencer Inbox中的交易，会干扰到Layer2正常的交易排序，然后会影响到排序器的工作。

慢箱的第⼆个作⽤，是抗审查。用户直接提交⾄慢箱合约中的交易，排序器⼀般会在10分钟内归集到快箱中。但如果排序器恶意忽略你的请求，慢箱还有⼀个强制归集force inclusion功能：

如果交易被提交至Delayed Inbox中，经过24小时，慢箱中的交易仍未被排序器包含至交易序列中，用户可以在Layer1上手动触发force inclusion函数，把被排序器忽略掉的交易请求，强制归集到快箱Sequencer Inbox中，之后就会被全体Arbitrum One节点监听到，会被强制包含进Layer2交易序列里。

我们刚才提到过，快箱⾥的数据就是L2的历史数据实体。所以在被恶意审查的情况下，通过慢箱可以让交易指令最终包含进L2账本中，这涵盖了强制提款等逃离Layer2的场景。

由此可以看出，对任何⼀个⽅向和层次的交易，排序器最终都⽆法永久审查你。

慢箱Inbox的几个核心函数：

depositETH()，最简单的充值ETH的函数。

createRetryableTicket()，可用于ETH和ERC20以及消息的充值。相较depositETH()而言，有更高的灵活性，例如可指定充值后L2的收款地址等。

forceInclusion()，也即强制归集功能，任何⼈都可以调⽤。该函数会校验，提交至慢箱合约中的某笔交易，是否过了24小时还没被处理。如果条件满⾜，则将对消息进⾏强制归集。

不过需要注意，force Inclusion函数实际上位于快箱合约中，只是为了⽅便理解，我们将其放在慢箱这⾥⼀起讲解。

出站箱Outbox

出站箱Outbox只与提现有关，可以理解为提现行为的记录和管理系统：

我们知道，Arbitrum官方桥的提现需要等待约7天的挑战期结束， Rollup Block 最终敲定后，提款行为才可以实施。⽤户在挑战期结束后，向Layer1上的Outbox合约提交相应的Merkle Proof，它再与其他职能的合约通信（如解锁其他合约中锁定的资产），最终完成提现。

OutBox合约会记录哪些L2到L1的跨链消息已经被处理过，以防止有人反复提交执行过的提现请求。它通过mapping(uint256 => bytes32) public spent，记录提现请求的spent Index与信息对应关系，如果mapping[spentIndex] != bytes32(0)则该请求已被提现过。原理类似于防止重放攻击的交易计数器Nonce。

下⾯我们将以ETH为例完整讲解充值与提现的流程。ERC20与之不同的仅仅是⾛了Gateway，就不再赘述。

ETH充值

1. 用户调用慢箱的depositETH()函数。

2. 该函数会继续调用bridge.enqueueDelayedMessage()，在bridge合约中记录该消息，并将ETH发送往bridge合约。所有的ETH充值资金，都保管在bridge合约中，相当于一个充值地址。

3. 排序器监听到慢箱中的充值消息，将充值操作反映⾄L2数据库中，⽤户可以在L2网络看到自己充进来的资产。

4. 排序器将该笔充值记录包含进交易批次batch，提交给L1上的快箱合约。

ETH提现

1. ⽤户在L2上调⽤ ArbSys合约的withdrawEth()函数 ，在L2上销毁相应数量的ETH。

2. 排序器将该提现请求发送⾄快箱。

3.Validator节点根据快箱中的交易序列，创建新的Rollup Block，其中会包含上述提款交易。

4. Rollup Block度过了挑战期并被确认后，⽤户可以在L1上调用Outbox.execute Transaction()函数，证明参数由前面提到的ArbSys合约给出。

5. Outbox 合约确认⽆误后，解锁bridge中相应数额的ETH发送给⽤户。

快速提现

使⽤乐观Rollup官方桥提现就会出现等待挑战期的问题。我们可以⽤私营的第三方跨链桥来规避这个问题：

原⼦锁交换。这种⽅式只是在双⽅在各⾃的链内进⾏了资产的互换，并且具有原⼦性，只要⼀⽅提供了Preimage，双⽅⼀定可以得到应有的资产。但问题是流动性⽐较稀缺，需要点对点地寻找对⼿⽅。

⻅证⼈跨链桥。⼀般类型的跨链桥都属于⻅证⼈桥。⽤户提交⾃⼰的提现请求，提现⽬的地指向第三方桥的运营者或流动性池。⻅证⼈发现跨链交易已提交到L1的快箱合约后，就可以直接在L1端向⽤户转账。这种⽅式本质上是⽤另⼀套共识系统来监视Layer2，并根据其已提交至Layer1上的数据进⾏操作。问题是，这种模式下的安全系数不如Rollup官方桥⾼。

强制提现

force Inclusion()强制归集功能用于对抗定序器的审查，任何L2本地交易、L1到L2交易和L2到L1交易，都可以使用该功能实现。定序器的恶意审查严重影响了交易体验，大部分情况下我们会选择提现离开L2，因此下面以强制提现为例介绍forceInclusion的用法。

回顾在ETH提现步骤中，只有步骤1、2是涉及到定序器审查的，所以只需要更改这两步：

调用L1上慢箱合约中的inbox.sendL2Message()，输入参数就是在L2上调用withdrawEth()时需要输入的参数。该消息会共享给L1上的bridge合约。

等待24小时的强制归集等待期后，调用快箱中的force Inclusion()进行强制归集，快箱合约会检视bridge中是否有对应消息。

最终用户可以在Outbox中提现，其余步骤由同正常的提现相同。

另外，arbitrum-tutorials中也有使用Arb SDK的详细教程去指导用户如何通过forceInclusion()去进行L2本地交易和L2到L1交易。