基于排序的预确认方案的不足——二层网络

以下是由 Lin Oshitani (Nethermind Research) 撰写。感谢 Conor 和 Aikaterini 的详细讨论和审查。 还要感谢 Ahmad 和 Brecht 的审查和评论。 这项工作部分由 Taiko 资助。 所表达的观点仅代表我个人，不一定反映审查者或 Taiko 的观点。

介绍

基于排序 (Based sequencing) 提供了一个可信的中立共享排序器层，从而实现了 rollup 之间以及 rollup 与 L1 之间的可组合性。 此外，基于预确认 (based preconfirmations) 在基于排序之上提供了快速的预确认服务，从而显著提升了用户体验。 然而，与非预确认的基于排序相比，基于预确认的简单实现会引入需要认真考虑的负外部性。 尽管在 Bell Curve 的这一集（主要是在非基于排序器的背景下）和 Chainbound 的 这篇帖子 等作品中已经强调了这些问题，但我们认为这个主题在很大程度上仍未被充分探索。

在这篇文章中，我们将分析一个简单的“稻草人”预确认设置，找出它的缺点，并阐明未来解决方案必须解决的挑战。

稻草人

稻草人基于预确认的设置如下：

• L1 提议者可以将其预确认的权利委托给某个外部实体，也可以不委托。
  • 我们使用术语 预确认者 (preconfer) 来描述提供预确认的实体，它可以是 L1 提议者本身，也可以是 L1 提议者委托的实体。
• 预确认者 通过提供两个端点来处理预确认：
  • 请求端点：供用户和搜索者 (searcher) 请求预确认。
  • 承诺端点：用于将预确认结果流式传输给公众。 它使预确认请求者能够及时收到结果，同时允许其他用户在发起自己的预确认之前及时了解最新的预确认状态。
• 用户将在请求中包含“预确认小费”，以激励 预确认者 提供预确认。
• 预确认者 主要以先到先得的方式预确认交易。

此外，由于执行承诺的设计和实施要复杂得多，因此我们只关注执行承诺。 执行承诺保证交易的精确顺序和状态。 相比之下，包含承诺只确保交易将被包含，而不指定包含的条件。

问题

我们将介绍稻草人基于预确认设计的六个问题：

• 问题 1：延迟竞争
• 问题 2：拥塞
• 问题 3：小费定价
• 问题 4：公平交换
• 问题 5：活跃性
• 问题 6：早期拍卖

问题 1：延迟竞争

谁与 预确认者 之间的延迟最低，谁就获得所有的 MEV 尾随交易利润。 这是因为他们可以：

1. 首先通过承诺端点获得链的最新状态，并且
2. 首先通过请求端点插入他们的尾随交易。

从历史上看，这种结构 激励了 延迟竞争，网络参与者努力将延迟降至最低。 最终，这将导致搜索者选择与 预确认者 共同定位或垂直整合，这会大大损害网络的 地理去中心化。

这种延迟竞争一直是现有中心化排序器长期存在的问题。 例如，Arbitrum 团队已经探索了 实施工作量证明 (PoW) 的想法，他们将快速连接授予 PoW 成功的参与者，同时对没有成功的参与者施加人为延迟。 然而，由于引入了大量的经济浪费，该提案遭到了 社区的强烈反对。

问题 2：拥塞

鉴于 L2 交易费用通常较低，搜索者可能会选择完全避免延迟竞争，而是用概率套利尝试来淹没 rollup。 这可以通过垃圾邮件套利合约来完成，该合约尝试套利，如果失败则回滚。 在费用极低的 Solana 中，据报道，验证者浪费了约 58% 的时间来处理此类失败的套利交易。

这将导致类似于 Flashbots 之前的 优先 gas 拍卖 的情况，搜索者之间的竞争会因失败的套利交易而阻塞区块空间，最终推高普通用户的 gas 费用。

问题 3：小费定价

预确认者 必须解决一个 在线 MEV 问题，他们决定是否在几乎看不到其他竞争相同位置的交易的情况下预确认交易。 例如，假设 预确认者 收到一个带有 1 ETH 小费的预确认请求。 预确认者 如何知道小费定价是否合适？ 他们应该接受小费并立即预确认，还是等待一段时间，以防有另一个带有更高小费的请求？

问题 4：公平交换

预确认者 可以扣留预确认承诺 (promise)，并且不能及时将它们返回给用户。 请注意，预确认者 有动机尽可能多地扣留预确认承诺，以最大限度地重新排序和插入交易的机会，从而增加他们的 MEV。

作为一个极端的例子，预确认者 可以在其窗口期（12 秒或更长时间）内扣留所有承诺，根据自己的意愿重新排序和注入交易，并且仅在将最终交易批次提交给 L1 时才发布承诺。

问题 5：活跃性

对于提议者将预确认权利委托给外部 预确认者 的情况，预确认的活跃性和抗审查性将完全依赖于此单个外部实体，持续时间为 预确认者 的 slot。

问题 6：早期拍卖

任何具有 L1 可组合预确认的系统（即 L1 交易的预确认）都可能导致 预确认者-构建者集成，即 预确认者 和构建者成为同一实体。 这是因为以下两个原因：

• 使用 L1 预确认，包括 CEX-DEX 套利在内的大多数跨域 MEV 将通过预确认的交易捕获。
  • 考虑到大部分 MEV 收入来自 CEX-DEX 套利，这意味着大部分 MEV 收入将通过预确认来获得。 因此，构建区块的非预确认部分的收入将大大减少。
• 预确认的 L1 交易必须包含在当前区块的顶部。
  • 在预确认的交易之前插入任何交易都可能会改变预确认预期的状态，从而可能使预确认保证无效。 这意味着构建者必须不断地将最新的预确认交易纳入其区块，这即使不是不可行，也将极其困难。

再加上预确认委托发生在提议者的 slot 之前，预确认者-构建者集成使我们进入了一个 L1 提议者在他们的 slot 提前 将他们的预确认权利 和区块构建权利 委托给同一外部实体的世界。

提前选择区块构建者，被称为 早期拍卖，与当前的 MEV-Boost PBS 管道形成鲜明对比，在当前的 MEV-Boost PBS 管道中，区块构建者是在 slot 内通过区块拍卖 即时 ( JIT) 动态选择的。 可以在 此处 找到比较 JIT 拍卖和早期拍卖的更多详细信息。

基于排序的目标是继承 L1 的安全性。 然而，通过基于预确认，我们可能会改变底层 L1 本身的安全性格局。 尽管早期拍卖可能并非完全不利（需要进一步的研究和实验），但它们代表了与当前 MEV-Boost 构建者市场的根本转变。 因此，应该非常小心地引入它们，尤其是在链下引入时，对中心化趋势的控制有限。

结论

我们观察到，预确认的简单实现可能会导致各种负外部性。 与区块链中的所有事物一样，权衡是不可避免的。 然而，应尽可能减轻此类负面影响，并且在需要时，应将其作为一种有意选择引入，而不是意外。

在 Nethermind，我们与我们的合作者一起，正在积极研究解决本文档中概述的问题的解决方案。 请继续关注更多更新！

• 预确认桑拿
• 具有多轮 MEV-Boost 的基于预确认
• 同 Slot L1→L2 消息传递

• 原文链接： ethresear.ch/t/strawmann...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～