预确认网关 ~ 解锁预确认：从用户到预确认者 - Layer 2

预确认网关 ~ 解锁预确认：从用户到预确认者

非常感谢社区的审阅，特别是 George Spasov, Drew Van der Werf, 和 @g11tech

~tl;dr~

在这篇文章中，我研究了现有预确认提案中的几个问题。我引入了一个新的角色：“预确认网关”，以完全从用户那里抽象出预确认。我还探讨了网关如何促进预确认者之间协调的几个例子。

这篇文章建立在我关于Based Rollup 的交易提交的文章中的一些精选想法之上。

首先，让我们深入了解网关解决的问题，然后我们将探讨网关如何工作以及它们如何解决这些问题。

用户 → 预确认者

今天在 L2 上，交易从钱包转移到中心化的排序器。这种流动是通过 RPC 端点实现的。RPC 基础设施被用于许多链和钱包。

通过 共享排序，钱包将交易发送到共享排序器端点。

通过 基于预确认，这个简单的流程完全改变了。要请求预确认，用户和钱包需要做一些复杂的事情：

预确认小费估算

预确认对区块构建者施加了限制。通过限制构建者的设计空间，免费提供预确认对提议者来说是负 EV（较低的区块奖励）。为了补偿提议者，用户需要支付预确认小费。这个小费与 MEV 捆绑贿赂有一些相似的属性，它也可能是负的。

估算预确认小费非常复杂，因为合理的小费取决于预确认者的当前状态。将这个责任交给钱包将需要复杂的修改，这将涉及估算用户发送的每笔交易的 MEV 影响。

预确认请求路由

请求路由是决定将预确认请求发送给哪个预确认者的工作。为此，钱包需要检查 lookahead 以确定下一个预确认者是谁。

要求用户（及其钱包）管理预确认者列表并将预确认请求发送到正确的预确认者可能需要对钱包进行小的修改。重要的是，钱包将无法再支持所有交易的单个 RPC（除非此 RPC 本身实现某种路由）。

请注意，当钱包确定将交易发送到哪个排序器时，基于排序可能仍然存在这种路由复杂性。

预确认者的责任

Justin Drake 在 基于预确认 中提出的“预确认者”角色有两种截然不同的责任：

预确认处理

每个预确认者都有一个核心竞争力：定价和生成预确认承诺。预确认者的具体实现是一个 非常广泛的设计空间。 very wide design space.

预确认小费

预确认对区块构建者施加了限制。通过限制构建者的设计空间，免费提供预确认对提议者来说是负 EV（较低的区块奖励）。为了补偿提议者，用户需要支付预确认小费。这个小费与 MEV 捆绑贿赂有一些相似的属性，它也可能是负的。

其他责任

预确认 Gossip

预确认 gossiping 只是公开分享（或 gossiping）预确认承诺。

Justin Drake 提出了两个原因，说明为什么预确认者“应该”公开 gossip 预确认。

1. 解决公平交换问题

预确认中的公平交换问题是，支付预确认小费的用户不能完全保证预确认者实际上会预确认他们的交易。用户可能最终为他们永远不会收到的预确认付费。通过 gossip 预确认承诺，预确认者可以向用户（使用加密签名）表明他们已经预确认了其他用户的交易。这将避免预确认者可以收取小费而不为多个用户提供确认的场景。

这个问题在 最初的基于预确认的帖子 中进行了解释。

承诺请求和承诺存在公平交换问题。给定一个承诺请求，预确认者可能会收取预确认小费，而不与用户共享承诺。一个简单的缓解措施是让用户强制承诺公开（例如，实时流式传输），然后再发出新的承诺请求。此缓解措施解决了除最新预确认承诺之外的所有承诺的公平交换问题。

2. 预确认透明度

预确认 gossiping 还提供了排序过程的透明度。通过 gossip 预确认，其他实体可以更及时地了解预确认者的当前状态。这很重要，原因如下：

• 它允许用户（或其他参与者）更准确地评估新的预确认
• 它可以避免用相同状态的多个预确认请求来 spam 预确认者
• 它提供了对预确认者关于预确认行为的透明度（例如，他们是否在等待预确认具有更高小费的交易，或进行其他时序游戏）

预确认委托

如果预确认者已经预确认了一个完整的 slot（可能不常见，但有可能），他们将无法再预确认任何交易。在这种情况下，lookahead 中的下一个预确认者可能能够预确认该交易。不幸的是，下一个预确认者可能无法验证第一个预确认者是否真的预确认了一个完整的 slot。为了避免被罚没，下一个预确认者需要确定第一个预确认者实际上已经预确认了一个完整的 slot，否则他们可能会因安全故障而面临被罚没的风险。

委托预确认对用户体验有好处（无需两次提交交易），但对进行委托的预确认者来说也存在风险。

链式预确认

链式预确认是由 Uri Klarman 在 以太坊排序和预确认电话会议 #1 结束时提出的。这个想法是，未来的预确认者可以预确认与之前的预确认者相同的所有预确认。这是一个非常强大的想法，但目前尚不清楚如何实现它。这个元预确认过程可以提前发生。在链式预确认系统中分配安全故障的责任是一个复杂的问题。

链式预确认的一个非常好的特性是用户获得了额外的活跃性保证：如果一个预确认者离线，lookahead 中的下一个预确认者仍然提供预确认！

预确认网关

预确认网关是一个新的角色，它处理用户的预确认并管理预确认者之间的协调。

预确认网关做两件事：从用户那里抽象出预确认，并协调预确认者。预确认网关处理所有预确认者协调，以便预确认者可以专注于为用户提供预确认。

没有网关：

有网关：

网关负责以下事项：

建立、营销和维护 RPC 端点

关于基于预确认的原始帖子 介绍了预确认者将有一个端点来接收来自用户的预确认请求的想法：

端点： 预确认者可以公开宣传点对点 API 端点，以接收承诺请求并返回承诺。以延迟为代价，可以使用 p2p gossip 通道代替点对点端点。

我建议预确认网关支持一个 RPC 端点，它的工作方式与正常的 RPC 完全相同（没有额外的预确认字段）。此 RPC 可以集成到希望使用预确认的用户的钱包中，而无需任何钱包修改。

路由预确认请求

网关将跟踪活动的预确认者及其预确认请求端点。网关还将跟踪当前正在排序并负责预确认的预确认者。为此，网关需要监视 lookahead 并将其与他们的活动预确认者列表进行比较。

处理预确认小费

预确认网关面向用户的另一个职责是处理预确认小费。网关需要估算预确认的小费并将其添加到交易中以形成预确认请求。根据预确认小费的实现方式，这可能涉及一个签名以从智能合约中解锁小费，或一笔额外的交易来支付小费。对于负小费，网关将负责收取小费。

估算预确认小费

由于预确认网关具有活动预确认者的列表，因此他们可以根据与预确认者的通信来估算小费。即使这样也可能没有必要，如果网关在处理其他预确认时最近与预确认者进行了交互。在特定区块中拥有较大市场份额的预确认网关甚至可能能够仅根据其对市场的看法来估算适当的小费。

支付小费

与支付者和常规 gas 费类似，网关将赞助用户的预确认小费。网关将通过其他渠道从用户那里收到付款，如下所述。

支付小费津贴

支付小费津贴是一个链上 token 津贴，它授予预确认网关转移用户一定数量 token 的权限。

支付小费津贴将允许用户预先批准支付一定数量的预确认小费，从而消除了用户在发送交易时考虑预确认小费的需要。

许多交易（如简单的转账）可能不需要任何预确认小费。对于几乎没有或没有预估小费的交易，网关可以补贴用户的交易。

虽然设置支付小费津贴似乎很麻烦，但实际上有一种非常简单的方法可以创建一个预确认网关小费津贴系统，如果实现了负小费。

小费盈余 是指网关从用户在其生命周期内请求的预确认中获得的任何价值。预确认网关可以跟踪其用户的盈余，并将盈余用作用户支付小费津贴的一部分，即使用户什么都不做。这是用户和预确认网关之间的一种链下协议，网关可以选择支持该协议以帮助其用户。网关可以通过收取他们为用户节省的盈余费用来赚取收入。

可以通过两种方式创建小费盈余：

1. 用户请求预确认，但预确认网关估计小费为负。网关将从预确认者那里收取小费并将其保留为盈余。

2. 用户请求预确认，其中包含过高的包含小费（优先费）。网关意识到用户为他们的交易支付了过高的费用，并决定向预确认者发送一个负预确认小费。网关将保留差额作为盈余。

案例 2 有点复杂，但这是一个非常强大的想法，因为它保护用户免于支付过高的 gas 费。这也意味着，如果用户不小心支付了过高的费用，选择通过 gas 费发送预确认小费的用户将能够获得退款。

此外，如果用户没有设置小费津贴，他们可能会决定尝试通过 gas 费支付小费。

故意设置高优先费可能是与预确认网关建立小费盈余的好方法。

Gossip 预确认

预确认网关还将管理预确认承诺的 gossip (或共享)。每个预确认者将 gossip 他们的预确认承诺给网关。然后，网关将创建一个公共端点，供外部各方监视预确认。

让预确认网关处理 gossip 解锁了一些好处：

解决公平交换问题（再次）

单独 gossip 预确认承诺并不能完全解决公平交换问题。预确认者实际上可以生成他们预确认然后 gossip 的虚假预确认请求。对于外部观察者来说，看起来预确认者正在提供预确认，但他们实际上只是在预确认他们自己的 spoofed 请求。当一个真正的用户（可能通过网关）向预确认者发送预确认时，他们可能会把小费放入口袋而忽略其余的请求。

\ Spoofed 预确认640×563 84.8 KB

为了避免这种情况，用户需要能够验证预确认者实际上是否在预确认真正的请求。网关可以通过监视预确认者的 gossip 并验证预确认者是否实际上在预确认真正的请求来提供此验证。

如果发现预确认者 gossip 虚假预确认，网关可以在用户失去资金之前停止向他们发送带有小费的预确认请求。

解决公平交换问题（我保证这是最后一次）

如前所述，gossip 预确认承诺提供了对预确认者行为的透明度。这种让预确认者对其行为负责的概念可以进一步扩展。我们可以解决的下一个公平交换问题与预确认者可以进行的时序游戏有关。通过不及时响应用户的预确认请求，预确认者可以“观望”是否有更高的小费进来。在这种情况下，预确认实际上变成了一个拍卖，我们失去了预确认的速度优势。

为了避免这种最终状态，网关可以做一些事情：

• 监视预确认者的 gossip 并验证他们是否及时预确认请求，如果不是，网关可以简单地停止向他们发送预确认请求
• 在预确认者提供旧请求的预确认承诺之前，阻止向预确认者发送新的预确认请求。这将迫使预确认者及时预确认请求，否则他们将失去新的小费。
• 信任奖励： 如果预确认信任网关，网关可以escrow 预确认小费，并在他们预确认交易后才将其发布给预确认者。

透明度 + 历史数据

网关还可以提供有关预确认者已承诺（预确认）的预确认的历史数据。这对于研究目的很有用，并且可能有助于其他参与者了解特定预确认者的表现。

委托预确认

预确认网关还将负责处理某些预确认者无法预确认交易的情况。网关需要了解某个具体的预确认者将不再能够预确认某项具体交易（如果他们已经预确认了一个完整的 slot，则为所有交易）。网关将需要在 lookahead 中找到下一个预确认者并将预确认请求发送给他们。网关可能还需要根据新的预确认者调整其小费估算。

如前所述，预确认网关将拥有大量关于预确认者状态的信息，因此他们可能能够开始委托他们知道当前预确认者将无法预确认的预确认。

链式预确认

预确认网关还将处理链式预确认。链式预确认周围的 slashing 如何运作仍然是一个悬而未决的问题，但网关也可能能够处理这个问题。如果 所有预确认者都信任网关（对于其他职责来说不是必需的），那么网关可以处理预确认者的 slashing。

实践中的预确认网关以及常见问题解答

我建议 mev-boost 中继最初用作预确认网关。

中继已经受到提议者的信任，如果我们需要这样做，这可以解决快速启动问题。

为什么叫“网关”？

虽然我已经提议网关最初将与中继相同，但我故意不将其称为中继，因为我不希望保持这种强烈的关联（mev-boost 中继 = 预确认中继）。

与 mev-boost 中继有什么区别？

中继和网关之间的主要区别在于所涉及的信任。中继受到提议者的信任，可以将他们的交易包含在一个区块中。提议者（和预确认者）实际上根本不需要信任网关。事实上，预确认者甚至不需要知道网关的存在。根据网关支持的预确认者之间具体的协调机制，它们可能具有与 mev-boost 中继类似的信任要求。

预确认网关的最终目标是什么？

我个人的愿景是，顶级中继开始运行网关，用户选择他们最喜欢的网关（基于他们如何分配小费盈余等）。

随着时间的推移，可能会出现新的专业实体并获得市场份额。

最终，用户将有许多网关选择，并且将出现网关服务竞争激烈的市场。竞争将降低费用并改善用户的 UX

那么实际发送的是什么呢？

这些图表和解释中的一些假设了围绕预确认的某些实现细节。虽然尚未就所有这些达成共识，但“网关抽象预确认”的概念适用于许多可能的实现。

在上面提出的模型中，用户将签名交易发送到网关。网关将预确认请求（签名交易 + 小费 + 元数据）发送给预确认者。用户也可以将预确认请求发送给预确认者。

包含与执行预确认

用户如何指定他们对 包含与执行 预确认的偏好？ 我相信网关还可以（从检查用户的交易中）确定要从预确认者那里请求哪种类型的预确认。 如果用户想要指定这一点，还有其他方法（例如，注册系统或 URL 参数）支持这一点。

这个相同的想法实际上可以应用于网关可以实现的任何其他（可选）功能。

参考

我在撰写本文时使用了许多资源：

https://mteam.space/eth-sequencing-preconfs-resources

• 基于提议者承诺 - 以太坊的提议者承诺市场
• 避免基于预确认的意外活跃度故障

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