此前的文章中，我们曾提到，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取回资产。
- 提现也不存在票据过期的问题，只要过了挑战期，可以在任意时间领取。
- 一个在L1上部署的代币，它在L2上要如何部署？
- 它的L2对应合约需要预先手动部署，还是系统可以自动为跨过来的、但尚未部署合约的代币 自动部署资产合约？
- L1上的ERC-20资产，在L2对应的合约地址是什么？是否该和L1一致？
- 在L2上原生发行的代币，如何跨链至L1？
- 拥有特殊功能的代币，如可调整数量的Rebase型代币，自增长生息代币，如何跨链？
目前非常多扩容方案使用的都是白名单+手动清单的方案，来规避各种复杂的问题和边界情况。
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直接跨链到L2上，我们会发现一些奇怪的问题：
- 无法在L2上把WETH进行Unwrap变成ETH，因为L2上并没有锁仓对应的ETH。
- Wrap功能可以使用，但这些新生成的WETH如果跨回到L1，也无法在L1上解封装为ETH，因为L1和L2上的WETH合约不是“对称的”。
我们刚才提到过，快箱⾥的数据就是L2的历史数据实体。所以在被恶意审查的情况下，通过慢箱可以让交易指令最终包含进L2账本中，这涵盖了强制提款等逃离Layer2的场景。
由此可以看出，对任何⼀个⽅向和层次的交易，排序器最终都⽆法永久审查你。
慢箱Inbox的几个核心函数：
- depositETH()，最简单的充值ETH的函数。
- createRetryableTicket()，可用于ETH和ERC20以及消息的充值。相较depositETH()而言，有更高的灵活性，例如可指定充值后L2的收款地址等。
- forceInclusion()，也即强制归集功能，任何⼈都可以调⽤。该函数会校验，提交至慢箱合约中的某笔交易，是否过了24小时还没被处理。如果条件满⾜，则将对消息进⾏强制归集。
- 我们知道，Arbitrum官方桥的提现需要等待约7天的挑战期结束， Rollup Block 最终敲定后，提款行为才可以实施。⽤户在挑战期结束后，向Layer1上的Outbox合约提交相应的Merkle Proof，它再与其他职能的合约通信（如解锁其他合约中锁定的资产），最终完成提现。
- OutBox合约会记录哪些L2到L1的跨链消息已经被处理过，以防止有人反复提交执行过的提现请求。它通过
- mapping(uint256 => bytes32) public spent，记录提现请求的spent Index与信息对应关系，如果mapping[spentIndex] != bytes32(0)则该请求已被提现过。原理类似于防止重放攻击的交易计数器Nonce。
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官方桥⾼。
- 调用L1上慢箱合约中的inbox.sendL2Message()，输入参数就是在L2上调用withdrawEth()时需要输入的参数。该消息会共享给L1上的bridge合约。
- 等待24小时的强制归集等待期后，调用快箱中的force Inclusion()进行强制归集，快箱合约会检视bridge中是否有对应消息。
