Skip to content

Latest commit

 

History

History
71 lines (51 loc) · 5.54 KB

排序器和抗审查性.md

File metadata and controls

71 lines (51 loc) · 5.54 KB

排序器和抗审查性

排序器是一个特殊的 Arbitrum 全节点,在正常情况下,负责将用户的交易提交到 L2 系统。原则上,一个链的排序器可以采用不同的形式;正如 Arbitrum One 目前所代表的那样,排序器只是集中式的;最终,排序器将由各独立的分布式委员会组成最后达成共识。然而,无论其形式如何,定序器都有一个基本限制,它不能跟 Arbitrum 系统的任何其他部分有关联:它必须在自己的安全假设下运行;即它不能直接从第 1 获得安全性。这就引出了一个问题,即当定序器行为不端时,Arbitrum 如何保持其抗审查性的特性。

在这里,我们将描述任何用户如何完全绕过排序器以直接从L1提交任何 Arbitrum 交易(包括启动资金提取的交易)的机制,从而即使定序器完全没有响应或作恶也能保持抗审查性。

核心收件箱

当谈论“将交易提交到 Arbitrum 链中”时,那么我们说的就是将其包含到链的核心收件箱中,由SequencerInbox中的inboxAccs字节数组表示。 一旦交易被包含在核心收件箱中,它们的顺序就一成不变,它们的执行是完全确定的,我们可以无需信任地将结果状态视为具有 L1 级别的最终性(有关更多信息,请参阅洞察 Arbitrum )。排序器的角色是关注之前发生的事情;即交易如何进入核心收件箱。 我们将把一个交易可能采取的路线分为两种情况:一个表现良好的排序器和一个有故障的排序器。

快乐/常见案例: 排序器是活的并且表现良好

在这里,我们首先假设排序器是完全正常运转的,并且以尽可能安全和及时地处理用户交易。排序器可以通过两种方式接收用户的交易——直接通过 RPC 请求,或者通过底层的 L1。

如果用户发布"标准" Arbitrum 交易(即与 L2 原生 dapp 交互),用户将直接将签名交易提交给排序器,就像用户在与 L1 交互时向以太坊节点提交交易一样。收到交易后,排序器将执行它并几乎立即向用户发送收据。不久后,通常不超过几分钟,排序器会将用户的交易包含在一个批次中,并通过调用SequencerInbox的addSequencerL2Batch方法将其发布到 L1。需要注意的是,只有排序器有权调用这些方法,此时交易具有 L1 级别的最终确定性。

或者,用户可以通过底层 L1 来发布信息提交到 L2 的排序器。如果用户希望在执行 L2 消息时还执行 L1 的一些操作并保持两者之间的原子性,则通过这种方式是必要的。这里书本的示例是通过网桥进行代币存款(L1 上的存款,L2 上的铸币),用户通过调用Inbox合约上的相关方法来发布 L1 交易(即向 L1 节点发送正常交易)来实现,即 sendUnsignedTransaction(发送未签名的交易)。这会在我们称之为“延迟收件箱”的地方添加一条消息(由 Bridge 合约中的inboxAcc表示),它实际上是一个队列,消息在发送到核心收件箱之前等待. 在交易被包含在延迟收件箱中大约 10 分钟后,排序器将发出 L2 收据(这种延迟的原因是为了最大限度地降低短期 L1 重组的风险,这可能会使排序器的 L2 收据无效。)同样,最后一个步骤是让排序器将 L2 消息包含在一个批次中——当调用批量提交方法时,排序器指定延迟收件箱中要包含多少条消息即最终确定交易。

总而言之——无论哪种情况,用户首先将他们的消息传递给排序器,排序器确保它到达核心收件箱。

不愉快/不常见的情况:排序器没有做好它的工作

现在让我们假设排序器,无论出于何种原因,完全无法执行其提交消息的任务。用户仍然可以通过两个步骤获得他们的交易:

首先,他们通过 L1 将他们的 L2 消息提交到前面所述的延迟收件箱中:需要注意的是,虽然原子跨链消息是使用延迟收件箱的常见情况,但原则上它可以用于提交任何 L2 消息。

一旦进入延迟的收件箱,我们显然不能依赖排序器将交易包含在批处理中。相反,我们可以使用SequencerInboxforceInclusion 方法。一旦消息在延迟收件箱中的时间足够长,就可以调用 forceInclusion 将其从延迟收件箱移动到核心收件箱中,到这里它已最终确定。至关重要的是,任何地址都可以调用 forceInclusion

目前,在 Arbitrum One 上,从提交交易到强制包含之间的延迟时间大约为 24 小时,由maxDelayBlocksmaxDelaySeconds变量指定。来自 L1 的强制包含将直接影响任何未确认的 L2 交易的状态;为了保守,保持这个延迟的时间较大确保它只在特殊情况下使用。

除了延迟本身之外,forceInclusion 路径还存在交易排序不确定性的缺点;即在等待消息最大延迟通过时, 恶意排序器理论上可以直接在其前面发布消息。然而,排序器最终无法阻止它被包含在核心收件箱中,而此时它的排序已完成。

虽然缓慢、“不愉快”的路径并不是最优的,但是应该很少。但它作为一个选项的,即使系统部分出现故障,让 Arbitrum 始终保持其无需信任的安全模型和可用性上还是有必要的。

区块编号和时间

ArbGas与运行时