分析BFT与提议者承诺的预确认

在之前的一篇 文章 中，我们介绍了Espresso Sequencer：一个去中心化的高性能共享排序平台，它简化了在rollups之间实现原子性、可组合性和互操作性的复杂性。Espresso Sequencer是由L1验证者运行的外部自愿协议。作为我们协议的一部分，Espresso Sequencer原生地为rollup用户提供BFT预确认。BFT预确认由如Espresso的 HotShot 等BFT共识算法的安全性和生存性保证支持。在这篇文章中，我们将分析另一种外部自愿的预确认协议：提议者承诺（“PP”）预确认。

提议者承诺预确认的架构

提议者承诺预确认最初被介绍为“ 基于预确认。”与需要整个验证者集达成共识的BFT预确认不同，PP预确认只需要来自单个验证者的批准（即来自基础排序协议的“提议者”的批准）。下面的协议描述反映了我们对PP预确认范式的理解，填补了在实现原始提案时需要解决的许多细节。关于基础排序协议所做的唯一假设是，它通过提议者的轮换进行操作。

选择提供PP预确认的验证者被称为 preconfers。通过选择加入，preconfers同意参与一个由外部管理的协议，如果他们不遵守他们的预确认承诺，就可能被削减。每个rollup可以自定义PP预确认的排序和削减条件以满足其个体需求。Preconfers按顺序排序，以其在排序协议中的下一个提议者位置为基础，并可以提供多种预确认类型，从反映在特定状态根上的交易执行的严格承诺，到仅涉及交易包含的较弱承诺。某些类型的预确认，如针对指定状态根的执行承诺或基于意图的执行承诺，仅由下一个preconfer提供，因为只有他们掌控着最新的rollup状态。其他形式的预确认，如仅排序或包含承诺，可以由任何preconfer提供。某些rollup可能会决定仅允许某些类型的预确认。否则，由preconfers自行决定提供哪些类型的预确认[1]。

用户与preconfers之间的交换

获取PP预确认分为三个步骤：

步骤1：发送预确认请求。用户向下一位preconfer发送一个 预确认请求（off-chain）。至少，preconfer请求必须包含用户的交易和一个预确认费用。正如我们之前 文章 中所描述，交易和费用可以进行原子打包，使得没有用户的交易，这笔费用无效。这防止了一个preconfer拒绝用户的请求但仍然在其中包含用户的费用付款的攻击。这个包可以进一步扩展附加的有效性数据，如执行条件或预期的preconfer的公钥。根据用户请求的承诺类型，他们可能还需要在请求中包含额外的数据, 如最新状态根或从preconfer处看到的排序号。

用户可以选择向多个preconfers发送预确认请求，以防第一个preconfer错过他们的位置，增加了处理相同交易的双重承诺的需要。这意味着应该有一个机制，在交易在之前的块中执行时作废请求费用[2]。

步骤2：预确认请求的批准/拒绝。接下来，preconfer从用户那里接收预确认请求，并必须决定是返回承诺还是拒绝请求。preconfer必须验证预确认请求是有效的，以及预确认费用是否足够。我们稍后将讨论确定费用足够性的困难。如果preconfer决定接受请求，他们将返回一个可削减的承诺给用户。这个承诺至少包括对用户请求的签名。根据提供的承诺类型，preconfer可能需要在承诺中包含额外的数据，比如一个更新的状态根或排序号。他们还可能需要将这些数据公开流式传输，以便其他用户可以进行未来的预确认请求。

步骤3：用户对预确认的验证。最后，用户接收并验证承诺。至少，用户验证preconfer的签名。根据承诺的类型，用户可能还需要使用来自preconfer的额外数据来验证他们的请求条件是否满足。如果这种验证失败，用户可以提交该承诺以进行削减。

上述三个步骤构成用户和preconfer之间的具有约束力的协议。将交易和预确认费用打包，使得一者没有另一者无效，消除了用户和preconfer之间额外公平交换协议的需要。稍后，我们将讨论如果preconfer未能及时回复承诺可能会发生什么。

包含和执行

PP预确认首先被包含在一个排序块中，然后执行，如下所述。

图1：PP预确认协议流程

提议者排序中的下一个preconfer不一定是排序协议的下一个块提议者。无损一般性，假设提议者是均匀选择的。如果 \(\frac{1}{\rho}\) 个排序验证者选择成为preconfers，预计平均每个preconfer将成为一次提议者每 \(\rho\) 块。预确认和未预确认的交易都可以包含在任何排序块中，但所有交易在任何preconfer成功提议一个块之前都排队等待执行[3]。

非preconfers可以在他们的块中任意包含他们想要的交易，包括其他验证者预确认的交易。非preconfers无需了解PP预确认协议。

preconfers也可以在他们的块中包含他们想要的交易，只要他们的预确认承诺得到了遵守。preconfers必须包括它们所做的任何预确认，除非以下条件之一适用：

• 预确认的交易被作废且不会被执行。这可能发生在一个相互冲突的交易在早期的块中执行。如果存在冲突交易示例：具有相同nonce的不同交易、用户解除捆绑并作为非预确认交易提交的相同交易，或早期preconfer包含的交易。preconfer可能需要参与仲裁以证明交易被正确作废。
• 预确认的交易被包括在之前的块中。在这种情况下，衍生管道将负责将该交易正确插入下一个rollup区块中的预确认交易排序。实际上，预确认交易在preconfer的块之前，可能会存在实际限制限制其出现的块数。

一旦preconfer的块被网络排序，rollup的衍生管道（我们在之前的文章中描述）将结合从最后一个preconfer的块到当前preconfer的块合并块，形成下一个规范的 rollup 块。衍生管道可以针对每个rollup进行定制，以强制执行某种排序策略，同时遵守预确认。一个特别的衍生管道排序策略如下：在预确认承诺之后对所有未承诺交易进行排序，并在预确认交易中，首先按排序承诺（如果使用）排序，然后按它们在块中出现的顺序排列（可以是preconfer块或常规块）。rollup的衍生管道排序策略需要在所有情况下都是确定性的。精确定义这种策略可能是个非平凡的任务。任何参与PP预确认的rollup都需要更新其当前衍生管道以处理新的排序策略。

一旦衍生管道得出规范块，该块就会被执行。

对提议者承诺预确认的讨论

PP预确认是一个新兴的 提案。它与生态系统参与者和MEV因素的交互尚未完全了解。此探索旨在阐明它可能发展的几个方向。

preconfers是否有动力提供快速预确认？

PP预确认提案的主要动机是为用户提供快速的与网络速度相匹配（约100毫秒）的预确认。

在任何排序协议中，提议者的动力是提出他们能够提出的最有价值的块。通常，就像今天的以太坊一样，提议者将其构建职责拍卖给指定的“构建者”，这些构建者优化找到从交易中提取最大可提取价值（MEV）以构建出最有价值的块。为了构建最有价值的块，构建实体需要解决一个 离线 MEV最大化问题。在离线MEV问题中，构建者可以一次考虑一组全可能的交易，只输出一个块。如果构建者在提交块的最后期限之前得知新交易，则他们可以将这些新交易添加到所有可能交易的集合中，并重建整个块。

然而，preconfers必须解决一个稍微不同的、 在线 MEV最大化问题。preconfers可以在其部分的任何时间接收到预确认请求。在他们收到请求时，他们可能不知道可以包含在其块中的所有交易 - 在收到当前请求和他们的块提议截止时间之间，他们可能会收到未来的预确认请求和额外的非预确认交易。因此，preconfers必须决定是否在没有完整信息以确定订单请求是否为整个块的MEV最大化决策的情况下，为给定的费用预确认请求。preconfers必须逐步构建其块，并在他们所承诺的每个承诺中重复解决此在线MEV最大化问题，以确定用户的费用是否足够。

因此，preconfers可能选择两种行为：preconfers可能决定仅向用户提供包含承诺，而不是严格的排序或执行承诺。这样，他们可以避免重复的在线MEV问题，而倾向于解决一个更简单的离线MEV最大化问题。preconfers还可能选择推迟向用户发送预确认承诺，以便他们有更多时间评估在线MEV问题[4]。

一个潜在的解决方案是允许用户在preconfers未能及时响应时“过期”其预确认请求。然而，用户可能希望在稍后的时间提交交易，preconfers可以利用这一点来可能地抢跑用户。或者，preconfers可能会受到激励以提供快速预确认，以便在其部分期间收取最大费用。但这仍然需要他们在某种程度上评估在线MEV问题，目前还不清楚preconfers将选择哪种行为。

拍卖的是什么？

无论rollup选择的特定排序策略如何，基础排序协议的提议者可能有多种机会与构建者交互并以影响rollup交易排序的方式拍卖块空间。市场可能在这些机会周围演变，但目前还难以预测，包括例如：当构建者向preconfers请求包含承诺的交易时，以及在他们的preconfer块之前的块中打包仅承诺的交易时，当他们请求preconfers的排序承诺或通常打包未承诺的交易时。preconfers本身也很可能将其preconfer权利拍卖给更复杂的构建者实体。

解决MEV最大化问题的preconfers需要一定程度的复杂性。因此，很可能在以太坊中出现的PBS类似机制随后会在PP预确认中被引入。在此背景下，用户还必须计算在线MEV问题以知道发送给preconfer的适当费用。用户可以自行解决这个问题，这可能相当困难，或者他们可以将定价外包给信任的中继或preconfer本身。

PP预确认是否改善了用户体验？

虽然用户可能 潜在 地收到快速的预确认，但他们的交易执行可能会经历增加的延迟。如上所述，preconfers平均每 \(\rho\) 块作为排序协议的提议者，这意味着大多数交易，无论是否预确认，都必须等待 \(\rho\) 块才能执行。预确认提议者的比例尚不清楚。用户可能面临由于PP预确认所导致的更糟糕延迟，以进一步了解其交易执行状态。此外，选择不获取预确认的用户可以更容易地被预确认的交易超越。如果大量L1验证者选择参与预确认，并且大量用户发现预确认是有用的，那么对rollup延迟的负面影响可能会减轻，然而，由于rollup衍生管道无法在L1最终事件之后启动，额外的延迟仍然存在。这种情况的发展方向还有待观察。

根据提供的预确认类型，preconfers可能只能同时处理一个用户请求。例如，在严格执行承诺的情况下，preconfers必须公开流媒体传递最新执行状态，以使用户了解请求承诺时他们的交易将以哪个状态执行。因此，在拥塞时期，用户可能难以跟上来自preconfers的最新数据，这使得他们很难成功请求更严格的预确认形式。rollup特定的构建者也许会将请求进行打包，但那样获得快速预确认的好处可能会减小。在任何情况下，这种严格预确认都倾向于更加复杂的用户或靠近preconfers的用户。

如上所述，每个rollup定义其自己的PP预确认排序政策、削减条件和允许的预确认类型。验证者在每个rollup基础上选择加入，并可能选择仅提供一部分预确认类型。因此，寻求特定预确认类型或跨rollup保证的用户可能很难找到会满足其需求的preconfer。正如上面提到的，仍不清楚preconfers是否会受到激励提供严格的执行类型承诺，因为这要求他们解决在线MEV问题。目前PBS构建者是否能够在新的PP预确认模式中仍然提供执行承诺也尚不明确。可能的情况是，虽然preconfer平均每 \(\rho\) 块成为提议者，但提供用户所需服务的preconfers可能更少。一个潜在的、不完整的解决方案是rollup组建预确认联盟，几个rollup同意统一他们的PP预确认设计，以便验证者能够选择同时为多个rollup进行预确认。

最后，PP预确认的交易并不是最终的； preconfer有可能遵守他们所有的预确认，但其块在链中被重组，从而破坏了预确认保证。在这种情况下，preconfer削减没有帮助，因为对preconfers因不在其控制之内的重组而进行削减是不公平的。

BFT预确认和PP预确认的对比

BFT rollup排序和PP rollup排序都运行可选的外部协议，L1验证者可以选择参与，并且两者都需要rollup进行集成。然而，它们的操作方式不同，并为rollup和用户提供不同的权衡。

PP预确认的一个关键设计选择是将基础排序协议视为黑盒，以减少实现的复杂性。PP预确认旨在通过让preconfers在其预确认期间作为可削减的集中排序器操作来提供快速预确认。只要单个preconfer诚实，用户的预确认承诺将会被遵守。另一方面，BFT预确认采取不同的方式，通过使用BFT共识协议的内部细节提供不同的预确认保证。虽然这种方法的实现更复杂，但具有几个关键的好处：

• BFT排序，通过其原生提供BFT预确认，导致更快的rollup管道。虽然从PP预确认中获得的承诺可能在理论上比BFT预确认更快（假设我们在分析中提出的担忧得到解决），使用BFT排序的rollup在接收到共识协议的承诺输出后，可以立即开始其衍生管道。而使用PP预确认的rollup则必须等到preconfer的块被提议（可能需要几个块）并在排序协议上得到确认后，才能启动衍生管道。这可能在rollup生产流程中引入不可忽视的延迟，尤其是由于并非所有验证者都选择作为preconfers。
• BFT预确认由整个Espresso Sequencing网络的经济安全支持，该网络由L1验证者的一部分组成，而不是单个验证者的安全性。为了不遵守BFT预确认，网络的权益必须被破解，超过 \(\frac{1}{3}\)，而PP预确认仅需单个验证者的抵押金。

最后，BFT预确认和PP预确认是完全可组合的。两个协议可以并行运行，为用户提供不同水平的预确认保证，同时，在这两者中，构建者都有新的机会与验证者进行交互并竞标模块空间。

1. Preconfers需要公开宣传他们提供的哪些预确认服务。可能会形成一个市场，用于聚合此信息以供用户使用。 ↩︎

2. 重复交易将自动作废，因为它们包含相同的交易nonce。然而，preconfer在作出预确认承诺时可能不知道先前的preconfer已同意在其块中包含用户的交易。因此，未来的preconfer可能会由于可能被认为有效的交易而失去费用。如何解决这个问题尚未明确。 ↩︎

3. 根据rollup的特定排序策略，执行承诺的预确认可能会立即被执行，而不必等到下一个preconfer块，如果1.) 执行承诺是preconfer为该部分给出的第一个承诺，或2.) 在此承诺之前的所有执行承诺已经执行。 ↩︎

4. 当preconfers接收到多个特定状态根的执行请求时，preconfers可能等待以返回承诺，以便他们可以选择提供最高费用的请求，或者创造其他MEV机会。例如，preconfer可以推迟接受某个承诺请求，以便他们可以潛在收到可以与preconfer自己的交易一起进行反运行的其他交易。 ↩︎

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