导语：本文由Arbitrum前技术大使、智能合约自动化审计公司Goplus Security前联合创始人罗奔奔执笔，深入解析Arbitrum One的技术架构。
在先前发布的《前Arbitrum技术大使解读Arbitrum的组件结构（上）》中，我们已经探讨了Arbitrum核心组件中的排序器、Validator、Sequencer Inbox合约、Rollup Block以及非交互式欺诈证明等关键要素。本文将聚焦于与跨链消息传递及抗审查交易入口相关的核心组件。
正文：在前文中我们提到，Sequencer Inbox合约作为”快箱”，专门负责在Layer1上接收排序器发布的交易数据包Batch。与之相对应的是被称为”慢箱”的Delayed Inbox（简称Inbox）。接下来我们将深入解析Delayed Inbox等跨链消息传递相关组件的工作原理。
跨链与桥接的运作机制
跨链交易主要分为L1到L2（充值）和L2到L1（提现）两个方向。需要注意的是，这里的充值和提现并不局限于资产跨链，还包括纯消息传递。与传统跨链桥接不同，Rollup与以太坊主网之间的跨链具有本质区别——Layer2的状态完全由记录在Layer1上的数据决定，只要使用Rollup官方跨链桥，其安全性就由Rollup协议本身保障。
这种特性揭示了Rollup的本质：从用户角度看它像一条独立链，但实际上Layer2更像是Rollup为用户提供的快速展示窗口，其真实的链式结构仍然记录在Layer1上。可以说L2是”建立在Layer1上的一条链”。
可重试票据机制
跨链交易具有异步和非原子性的特点，这意味着交易结果不能像单链交易那样即时确认。为解决这个问题，Arbitrum引入了可重试票据（Retryable Ticket）机制。通过官方桥充值时，ETH和ERC20都会使用这种机制。
可重试票据的生命周期包含三个阶段：首先在L1上通过Delayed Inbox合约的createRetryableTicket()方法创建并提交票据；在理想情况下，排序器会自动在L2上兑付票据；若遇到L2 gas价格激增等特殊情况导致自动兑付失败，用户需在7日内手动兑付，否则可能面临票据过期或需要支付续租费用的情况。
值得注意的是，提现流程虽然与充值存在对称性，但不涉及Retryables概念。这是因为提现需要用户手动与Outbox合约交互，且不存在票据过期问题，只要过了挑战期，随时可以领取资产。
ERC-20资产跨链的Gateway系统
ERC-20资产跨链面临诸多复杂问题：代币在L1/L2的部署方式、地址映射关系、特殊功能代币的处理等。Arbitrum通过Gateway系统解决了这些难题。该系统包含成对出现的L1/L2 Gateway组件，由Gateway Router维护代币地址映射关系，并提供StandardERC20 gateway、Generic-custom gateway等多种类型，满足不同ERC20代币的桥接需求。
以WETH跨链为例，直接桥接会导致L2上的WETH无法解封装为ETH。WETH Gateway通过在跨链前解封装为ETH，到目标链再重新封装，确保了WETH设计原理的一致性。这种设计思路也适用于其他具有复杂逻辑的代币。
慢收件箱的抗审查特性
Delayed Inbox（慢箱）与SequencerInbox（快箱）形成互补。慢箱不仅处理L1到L2的充值行为，还具备抗审查功能。用户提交到慢箱的交易通常会在10分钟内被排序器处理，若遭遇恶意忽略，可通过force inclusion功能在24小时后强制将交易包含进L2交易序列。
慢箱的核心功能包括：depositETH()用于简单ETH充值；createRetryableTicket()提供更灵活的充值选项；forceInclusion()则确保交易最终能被包含进L2账本，这对强制提款等场景尤为重要。
出站箱的提现管理
Outbox作为提现记录管理系统，主要功能包括：在挑战期结束后，用户通过提交Merkle Proof完成提现；通过spent mapping防止提现请求被重复执行。这种机制类似于防止重放攻击的Nonce计数器。
ETH充提流程详解
ETH充值流程：用户调用慢箱的depositETH()函数，资金转入bridge合约；排序器监听到充值消息后更新L2状态，并将交易包含进批次提交给快箱合约。
ETH提现流程：用户在L2调用ArbSys合约的withdrawEth()销毁ETH；排序器将请求发送至快箱；Validator创建包含该交易的Rollup Block；挑战期结束后，用户调用Outbox.executeTransaction()领取资产。
快速与强制提现方案
为规避官方桥的挑战期等待，用户可选择第三方跨链桥方案：原子锁交换通过点对点资产互换实现即时提现；见证人跨链桥通过监控Layer2状态提供快速服务，但安全性相对较低。
强制提现通过forceInclusion功能对抗审查：用户通过inbox.sendL2Message()提交提现请求，24小时后调用forceInclusion()强制包含交易。arbitrum-tutorials提供了使用Arb SDK实现强制交易的详细指南。
声明：文章不代表CHAINTT观点及立场，不构成本平台任何投资建议。投资决策需建立在独立思考之上，本文内容仅供参考，风险 自担！转载请注明出处：https://www.chaintt.cn/10848.html
