定序器和审查阻力
Sequencer是专门指定的Arbitrum全节点，在正常情况下，负责将用户的交易提交到L2。原则上，链的 Sequencer 可以采用不同的形式；正如 Arbitrum One 目前的情况，Sequencer 是一个单一的、集中的实体；最终，排序功能将提供给一个分布式排序委员会，该委员会就排序达成共识。然而，无论其形式如何，Sequencer 都有一个不适用于系统任何其他部分的基本限制：它必须在自己的安全假设下运行；也就是说，原则上，它不能直接从第 1 层获得安全性。这就提出了一个问题，即当 Sequencer 行为不当时，Arbitrum Rollup 如何保持其抗审查性的主张。
在这里，我们将描述 Sequencer 通常如何运行的机制，以及任何用户如何完全绕过 Sequencer 直接从第 1 层提交任何 Arbitrum 交易（包括启动 L2 到 L1 消息以提取资金的交易）。因此因此，即使 Sequencer 完全没有响应甚至是恶意的，该机制也能保持审查抵抗力。
核心收件箱
当我们谈论“将交易提交到 Arbitrum 链中”时，我们是在谈论将其包含到链的核心收件箱中，由 Bridge 中的 sequencerInboxAccs 字节数组表示。一旦交易被包含在核心收件箱中，它们的顺序是固定的，执行是完全确定的，我们可以不信任地将结果状态视为具有 L1 级最终性（参见“交易生命周期”）。 Sequencer 的角色（或缺乏角色）严格关注之前发生的事情；即，交易如何进入核心收件箱。我们将把交易可能采用的路由分为两种情况：行为良好的 Sequencer 和有故障的 Sequencer。
快乐/常见案例：Sequencer 已上线且表现良好
在这里，我们首先假设 Sequencer 是完全可操作的，并且以尽可能安全和及时的方式处理用户交易的目的运行。 Sequencer 可以通过两种方式接收用户的交易——直接通过 RPC 请求，或通过底层 L1。
如果用户发布“标准”Arbitrum 交易（即与 L2 原生 dapp 交互），用户将直接向 Sequencer 提交已签名的交易，就像用户在与 L1 交互时向以太坊节点提交交易一样.收到它后，Sequencer 将执行它并几乎立即向用户发送收据。不久之后——通常不超过几分钟——Sequencer 将把用户的交易包含在一个批次中，并通过调用 SequencerInbox 的 addSequencerL2Batch 方法之一将其发布到 L1 上。请注意，只有 Sequencer 才有权调用这些方法；事实上，这种任何其他方都不能直接包含消息的保证正是赋予 Sequencer 提供即时“软确认”收据的独特能力的关键所在。一旦成批发布，交易就具有 L1 级最终确定性。
或者，用户可以通过将其发布到底层 L1 上来将其 L2 消息提交给 Sequencer。如果用户希望与 L2 消息一起执行一些 L1 操作并保持两者之间的原子性，则此路径是必需的——这里的教科书示例是通过桥接的代币存款（在 L1 上托管，在 L2 上铸币）。用户通过发布调用收件箱合约上相关方法之一的 L1 交易（即向 L1 节点发送普通交易）来实现此目的；即，sendUnsignedTransaction。这会在我们称之为“延迟收件箱”的地方添加一条消息（由 Bridge 合约中的 delayedInboxAccs 表示），这实际上是一个队列，消息在被移至核心收件箱之前等待。 Sequencer 将在交易被包含在延迟的收件箱中约 10 分钟后发出 L2 收据（延迟的原因是为了最大限度地减少短期 L1 重组的风险，这可能会导致 L2 重组并使 Sequencer 的 L2 无效收据。）同样，最后一步是 Sequencer 将 L2 消息包含在批处理中——当调用批处理提交方法时，Sequencer 指定延迟收件箱中要包含的消息数——完成交易。
总而言之——无论哪种情况，用户首先将他们的消息传递给 Sequencer，Sequencer 确保消息到达核心收件箱。
不愉快/不常见的情况：Sequencer 没有完成它的工作
现在让我们假设 Sequencer，无论出于何种原因，完全无法执行其提交消息的任务。用户仍然可以通过两个步骤获得他们的交易：
首先，他们如上所述通过 L1 将 L2 消息提交到延迟收件箱：请注意，尽管原子跨链消息是使用延迟收件箱的常见情况，但原则上它可以用于提交任何 L2 消息。
一旦进入延迟收件箱，我们显然不能依赖 Sequencer 将交易包含在批处理中。相反，我们可以使用 SequencerInbox 的 forceInclusion 方法。一旦消息在延迟收件箱中停留了足够长的时间，就可以调用 forceInclusion 将其从延迟收件箱移动到核心收件箱中，此时它已完成。至关重要的是，任何帐户都可以调用 forceInclusion。
目前，在 Arbitrum One 上，提交和强制包含之间的延迟时间大约为 24 小时，由 maxTimeVariation.delayBlocks / maxTimeVariation.delaySeconds 指定。来自 L1 的强制包含将直接影响任何未确认的 L2 交易的状态；保持保守的高延迟值确保它只应在特殊情况下使用。
除了延迟本身之外，forceInclusion 路径还存在交易排序不确定性的缺点；即，在等待消息的最大延迟通过时，恶意的 Sequencer 原则上可以直接在它前面发布消息。然而，Sequencer 最终无法阻止它被包含在核心收件箱中，此时它的排序已经完成。
虽然缓慢、“不愉快”的路径不是最优的，而且很少（如果有的话）是必要的，但它作为一个选项的可用性确保 Arbitrum Rollup 始终保留其不信任的安全模型，即使系统的许可部分出现故障也是如此。