Arbitrum 是怎么处理跨链消息传递，以及抗审查交易的？其跨链桥模型是怎样的？

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

在上一篇文章《前 Arbitrum 技术大使解读 Arbitrum 的组件结构（上）》，我们介绍了 Arbitrum 核心组件中的 排序器、Validator、Sequencer Inbox 合约、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 L1<->Token L2 之间的地址映射，以及 some token<->some 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 交易。