如之前在最终性中讨论的一样，由于Arbitrum的运行是乐观式的，在挑战期结束之前以太坊并不能立即确认正确结果。
这一点并不会给Rollup内的运行带来任何问题或增加任何延迟。Arbitrum Rollup协议管理着断言的状态树，允许验证者通过持续构建树的解构来维持状态更新，即使所结点没有确认也可以继续推进。这意味着诚实的验证者可以自信地推进链的状态（同时也具有强制的能力），以太坊最终会确认哪个分支是正确的，任何验证链状态的人都能马上知晓，哪个分支最终会被接受。
协议中受到确认延迟影响的是L2到L1的信息，尤其是提现。因为提现一旦生效Arbitrum是无法撤销的，系统不能在没有以太坊确认的情况下就完成提现。
当提取ETH或ERC20代币时，可以利用币均一化的特性来避免延迟。也就是说，依赖第三方提供的流动性来进行快速提现（可能会收取小部分服务费）。总体来看，提现可以使用桥，也可以使用in-flight提款（飞行提款）或者原子锁交换（并没有任何直接的『提现』动作发生）。
要实现可交易提款，用户首先需要初始化一笔提款；第三方流动性提供者可以立即通过验证Arbitrum链来验证这笔提款是有效的（也就是一定会最终化）。然后流动性提供者就可以购买这笔提款，在L1上进行支付。
代币桥中包含了该实现：
* @notice Allows a user to redirect their right to claim a withdrawal to a liquidityProvider, in exchange for a fee.
* @dev This method expects the liquidityProvider to verify the liquidityProof, but it ensures the withdrawer's balance
* is appropriately updated. It is otherwise agnostic to the details of IExitLiquidityProvider.requestLiquidity.
* @param liquidityProvider address of an IExitLiquidityProvider
* @param liquidityProof encoded data required by the liquidityProvider in order to validate a fast withdrawal.
* @param initialDestination address the L2 withdrawal call initially set as the destination.
* @param erc20 L1 token address
* @param amount token amount (should match amount in previously-initiated withdrawal)
* @param exitNum Sequentially increasing exit counter determined by the L2 bridge
* @param maxFee max mount of erc20 token user will pay for fast exit
*/
function fastWithdrawalFromL2(
address liquidityProvider,
bytes memory liquidityProof,
address initialDestination,
address erc20,
uint256 amount,
uint256 exitNum,
uint256 maxFee
) external override
要通过原子锁交换来实现快速提现，用户直接在Arbitrum向流动性提供者付款，流动性提供者再将资金在L1上给用户。Hashed time locked contracts(HTLCs)，哈希时间锁定合约，确保这两个操作最终是原子性的，要么都发生要么都不发生，不存在中间态，以保证免信任。
这两种方式的变体也可以为多个不同的L2链提供快速转账（例如两个不同的Arbitrum链）。
流动性提款对均一化的代币而言是可行的。但对于流动性提供者无法提供等价物的非同质化的代币，其提款仍会收到系统性延迟的限制。类似地，当有人想从Arb链向L1发消息时（也就是该消息会以异步方式处理），同样也会受到该延迟影响。
← 确认与最终性
→ 总览