基于Espresso：针对所有L2的临时共享排序，从基于Rollup到Validium

编写者：Ben Fisch，Espresso Systems 首席执行官兼联合创始人，发表于 2024 年 3 月 8 日

非常感谢 Justin Drake 和 Brendan Farmer 的深思熟虑的讨论、宝贵的意见和对本文的审阅。

TLDR: Espresso 提出了创建一个共享排序的市场，通过该市场，第二层链将区块空间出售给共享提案者，包括以太坊主网 EVM 本身的提案者，这些提案者通过满足多个链上的用户意图创造了多余的价值。

我们的使命一直是为以太坊第二层链带来 renewed unity。近年来，rollups 和 validiums 已为更大范围的以太坊生态系统提供了横向可扩展性和多样化的执行环境，但以此为代价造成了碎片化——rollups 中的应用程序没有与以太坊 L1 上的应用程序相同的共享流动性和互操作性。以太坊的价值在于其统一性，而非碎片化——这是对信任最小化基础设施的承诺，也是区块链技术与 Web2 的差异所在。

最终，终端用户希望拥有安全、便捷和低成本的方式互相支付、买卖 NFT、提供 DeFi 流动性、交换资产等。用户将寻找最佳方式来满足他们的意图，即使这意味着同时在多个 rollups 和以太坊 L1 上进行交互。钱包自然会支持这一点，让用户不必关注细节。在与具有较大联合性的应用程序之间，满足用户意图的方式将会是最有效的，不仅要彼此之间，还要与以太坊 L1 上的智能合约相连。

今天，rollups 通过孤立的 sequencers 独立组装交易块，并将这些块异步发布到以太坊 L1。恢复 rollups 之间的互操作性乍一看似乎有些矛盾——这不也会将它们变成一个 rollup，从而抹去它们的可扩展优势和主权吗？

共享排序作为一种路径出现，通过它，rollup 用户在实践中可以恢复在同一个以太坊链上的体验，同时保留个别 rollups 的主权、独立性和性能（包括低成本和低延迟）。与以太坊 L1 类似，rollups 是通过离散的交易块进行更新的。如果一组 rollups 共享某个时间片的排序器，则该时间片中的共享提案者为所有这些 rollups 同时提议下一个区块。这个提议者可以确保对 rollups 产生任何他想要的结果。他可以利用这种力量满足任意用户意图，包括跨 rollups 的原子性交易执行。用户要么信任提议者满足他们的意图，要么获取一个经济担保的 preconfirmation 作为保障。当与即时证明结合使用时，共享排序在 zk-rollups 中尤其强大，或者在 Polygon 的 AggLayer 设计中，因其允许协调 rollup 块的构建同时在彼此之间传递消息（同步可组合性）。Rollups 可以无限期共享一个排序器，也可以是按需的，具体取决于设计。

共享排序市场

共享排序在最一般的意义上，是一个集成于几个链（即，rollups、validiums 等）之间的机制，用于以下两个方面：

(a) 提案者分配： 确定一组提案者来提议所有链的下一个块。

(b) 最终性装置： 对提议的块进行最终确定，并向用户提供此最终性的确认。

今天，中心化排序器作为自己 rollups 的提案者。在最初的 rollup 设计中，也称为“Based Rollup”，以太坊 L1 的提案者也是 rollup 的提案者。在某些 共享排序集群 的设计中，rollups 的一组共享一组固定的提案者以及领导者选举协议，以便在他们之间轮换（例如，随机或循环）。还有另外一个选择是一个 市场，通过该市场，rollups 将区块空间出售给希望成为一个或多个链共享提案者的代理人。Espresso Systems 正在建立这样一个市场，因涉及 L1 提案者，因而与“Based Rollup”设计兼容。稍后我们将对此进行进一步说明。

至少，以太坊 L1 共识为所有 rollups 提供了最终性的最终性装置，但其确认延迟相对较长（最坏情况约为 15 分钟，尽管在实践中，块可能更快地被认为是已被 L1 共识确认的）。除了作为提案者外，中心化排序器还充当个别 rollups 的受信任最终性装置，通过签署 rollup 状态提供更快的确认。这限制了 rollups 在以太坊 L1 完成之前的回滚能力。然而，与以太坊 L1 不同，这些中心化最终性装置并未跨不同 rollups 共享。在提案者分配的市场中，需要一个共享最终性装置。

除了为共享提案者提供市场外，Espresso 还提供一个去中心化、经济安全的最终性装置，称为 HotShot，rollups 可以共享该装置，以实现比以太坊 L1 提供的更快确认。这作为一个 BFT（即权益证明）协议进行操作。已经质押抵押品参与以太坊共识的 L1 验证者，也可以通过再质押合约参与 HotShot，而不需要额外的资本要求。最终，如果所有 L1 验证者参与，那么最终性装置将拥有与以太坊本身相同的经济安全性。

去中心化、共享最终性装置的另一个优势是更快、低成本的桥接。当两个 rollups 通过 HotShot 完成时，从一个 rollup 到另一个 rollup 的桥接交易就是安全的。这是因为所有 rollup 交易都已通过 HotShot 完成，因此，状态在 HotShot 最终确认后将不会改变。桥接可以通过零知识证明或通过一个流动性提供者实现，后者简单地在一个 rollup 上接收资金并在另一个 rollup 上发送资金。最终性装置降低了流动性提供者的风险，不仅通过信号显示反向风险较低的时刻，还确保任何后续的存款逆转在源链上也将消除流动性提供者在目标链释放资金的能力。

提案者分配

提案者分配的最简单例子是在所有链上强加一个单一提案者，或者一个旋转提案者集。或者，在我们称之为 按需共享排序 的情况下，提案者分配更像是一个市场，其中链以插槽的形式出售区块空间给愿意投标的复杂方，拥有权利提议一系列 rollup 块。在按需共享排序中，任何插槽中可能的结果都是在多个提案者之间对 rollups 的分配。rollup 的治理也可以指定一个方——或去中心化协议，如分布式验证者技术 (DVT)——来对其自己的区块空间进行投标，该空间作为保留价格：rollup 的区块空间仅在超过此价格的投标中出售给外部共享提案者。这使得 rollups 能够确保捕捉到他们公平的排序收入份额。Espresso 的提案者分配机制是一种组合拍卖，我们稍后将在这篇帖子中进一步讨论。

预确认

在任何提案者分配机制中，持有同时为多个 rollup 构建下一个块权利的提案者对它们的联合状态具有掌控权——它可以充当流动性提供者，或做出承诺以满足任意用户意图，包括在不同 rollups 之间进行多笔交易的原子执行，即便根据联合状态结果的条件执行。这些被称为 预确认。用户意图的具体示例包括：

• 捕捉两个不同链上 DeFi 交易所之间的套利机会（包括以太坊 L1）。
• 找到执行资产交换的最便宜方式，这可能涉及多个 DeFi 交易所或跨多个链的流动性提供者。
• 在一个链上使用应用程序（例如，购买 NFT），通过另一个链上的资金进行而不支付桥接/交换资产，除非购买成功。

用户是否愿意信任预确认可能取决于对提案者的信任和/或经济激励的一致性（例如，违反承诺的提案者可能会遭到削减）。预确认也可以设计成起保险的作用——用户向提案者支付小费，以便在承诺被违反时能够从托管的抵押品中索赔损失，金额达到一定范围。提案者承担他将无法履行承诺的风险，并据此合理定价风险。对于支持 Polygon 的 AggLayer 等高级设计的 rollups，共享提案者也可以在范围内协调多轮 rollups 之间的消息传递，这发生在单个块内。共享提案者所创造的超额价值，可能来源于否则不会存在的交易、用户为预确认支付的小费，甚至是提案者自身进行的套利，广泛涵盖跨域的 MEV。

基于排序

最初的 rollup 设计 事实上允许 rollup 智能合约通过以太坊 L1 块进行更新，而不需要引入外部排序器，在实际操作中赋予以太坊 L1 块提议者对所有 rollups 的共享排序权利。外部排序器的引入是为了实现更高的吞吐量（通过增强数据压缩）和快速的交易预确认（基于对排序器的信任，这也是 rollups 现在正在寻求去中心化的原因）。仍然具有外部排序器的 rollups 通过允许智能合约在排序器离线过久时强迫交易继续进行，继承了以太坊 L1 的活跃性。

然而，这种原始的 rollup 设计，已经开始在 Based Rollups 的名义下恢复流行，具有一个被忽视的关键优势：更好的 L1 可组合性。被随机选中的以太坊 L1 块的提案者，在某个插槽时代锁定了所有 rollups 和 L1 状态，可以对联合 rollup 状态及影响 L1 状态的预确认进行发放。此外，在未来，当有效性证明（即 SNARKs）达到更高的吞吐量和更低的延迟时，L1 提案者能够利用 实时（即亚秒） 证明 在单个 L1 块内介入 L1 与 L2 应用程序之间的函数调用，包括在 rollups 内部转移资产。

基于排序的设计原则

Based Rollups 或 基于排序 的范围已经从最初的理念发展到包含实现更广泛愿景的替代设计。基于 Espresso 是这样一种设计。我们努力实现的理想属性包括：

• L1 活跃性和中立性： rollup 从以太坊 L1 继承活跃性和可信的中立性，而不因 L1 外部基础设施故障而造成过度延迟。
• L1 可组合性： 以太坊主网 EVM (L1) 的提案者应具备同步更新 rollup 状态的能力，最终实现任何所希望的Based Rollups 和 L1 的原子条件执行。最终，借助实时证明，该提案者应能够促进 rollups 和 L1 应用之间的同步组合性。
• 快速的（预）确认： rollups 用户应在交易被提及后取得快速的 rollup 交易确认，几乎不需要延迟。rollup 交易的确认理想情况下应几乎没有反转风险，至少是基于它们所依赖的以太坊 L1 状态的最终性。用户还应能够表达涉及 rollups 和以太坊主网 EVM (L1) 执行之间的原子依赖关系的意图，从担保提案者处获得意图满足的预确认（或者承担意图违反的低成本保险覆盖）。
• 收入（MEV）再分配： rollups 应按其边际贡献获得共同排序 MEV 的一部分，比例大于它们在孤立运行自己的排序器时可能获得的成果。

L1 可组合性与快速最终性

每个 rollup 在 L1 上都有一个智能合约用于跟踪 rollup 的状态，但可能会滞后。通过在 L1 块内调用来更新 rollup 智能合约。目前，rollup 合同通常每个以太坊块只调用一次，甚至更少。然而，如果 L1 块构建与 L2 块构建协同进行（即当 L1 提案者也是 rollup 排序器时），那么有可能在单个 L1 块内多次调用 rollup 合约。 此外，通过足够低延迟的有效性证明（即，SNARKs），同时构建 L1 块和 rollup 块的提议者可以在 L1 和 rollup 之间传递可验证消息，借此在 L1 和 rollups 的合约之间实现同步交互。虽然当前有效性证明的延迟过高，尚不支持这一点，但这种技术正在快速进步，尤其是在专用证明硬件技术的发展下。

在 L1 可组合性与快速确认 rollup 交易之间存在根本的权衡。L1 可组合性要求 L1 提案者能够在新发布的以太坊块中采取行动，立即影响 rollup 的状态。以太坊 L1 的最终性缓慢。块每 12 秒发布一次，但直到 15 分钟后才能最终确认，当时以太坊的经济安全的完整性防止了 重组（即，在这时的重组将导致以太坊的 1/3 的质押被削减）。在 rollups 上的交易结果不能早于它所依赖的最新以太坊 L1 状态之后实现最终确认。

出于这个原因，今天的一些 rollups （如 Arbitrum 和 Polygon）选择基于已确认的 L1 块而不是链的顶端来构建——L1 上的任何动作，比如桥接存款到 rollup，在该存款在 L1 上确认之前无法在 rollup 中识别。因此，rollup 排序器（可能是一个集中方，或去中心化的 BFT 协议）能够最终确认 rollup（L2）交易，并为用户提供瞬时的预确认，因为它们不依赖于任何不确定的 L1 状态。这些被称为“预确认”，因为一个恶意的排序器（无论是个别方还是协议）最终可能决定发布一个相冲突的交易块。然而，如果用户信任该排序器不要被二择（例如，基于诚实多数假设和/或经济激励关系），则交易结果是确定的。一旦排序器在 L1 上发布一个块，它在二择的能力仍然受到限制，除非 L1 重组，在发布后的 ~15 分钟内仍然存在风险。

尽管 L1 可组合性与 L2 状态的瞬时预确认之间存在矛盾，但在这两个极端之间也许存在一个幸福的中间状态。探索这一中间状态的开始，始于 Justin Drake 关于 基于预确认 的开创性文章。首先，以太坊 L1 的浅层（单块）重组非常少见，而深层重组则很罕见。虽然对于极高价值交易，这一风险可能仍然过于巨大，透过视图将预确认看作一种保险，出具预确认的各方（或协议）一般能够吸收该风险并合理对用户定价。我们将称这些为 条件预确认 以反映它们的风险根本不依赖于提供方/协议，并区别于只能通过提供者的恶意行为进行违规的预确认。用户最终在信任这两种类型的预确认（即，当预确认的作用类似于保险政策时）时会面临相同的风险，但前者的价格更高以抵消提供者的风险义务。

其次，许多 rollup 交易（例如点对点支付或资产转移）可能不依赖于受到尚未最终确认的 L1 状态的变化的部分 L2 状态。 实际上，有可能为这些交易启用快速的预确认，而不会对提供者造成风险，同时保持 L1 可组合性。然而，原始的基于排序设计未能做到这一点——通过在 L1 块中仅使用 rollup 智能合约提案的交易在 L1 块确认之前总是存在反转风险，无论是 L1 提议者提供的预确认。我们将看到，基于 Espresso 的设计如何在这篇文章的后面实现这一良好的特性。

BFT 与单方预确认

我们根据提供者的风险类型区分了预确认的类型。另一种 区分 是基于单个提供者与委员会或去中心化协议的预确认。一个针对一组 rollups 的提案者可以提供具有最低延迟的复杂预确认，但由去中心化协议支持的预确认可能会具备显著更强的经济安全性（质押抵押品），并且违反的协作需求更高。去中心化简单的预确认更容易实现，它对参与者要求不高。共享无状态最终性装置就是这样的一个例子。它仅承诺发布 rollup 块时不发生二择，不需要协议参与者计算 rollup 状态。对一组 rollups 进行的提案者也可以通过阈值密码学（如 DVT）由一个委员会控制。委员会可能在满足任意意图实现的情况下提供预确认，但这需要所有委员会参与者更高的复杂度（例如，为这些 rollups 执行、参与提案者选择拍卖等）。

基于 Espresso 的设计

基于 Espresso 的设计实现了上一节中描述的基于排序的理想愿景。与稀疏的基于排序相比，基于 Espresso 为 rollups 提供更强的预确认安全性（最终性）以及一部分排序收入。事实上，与其简单地将排序权利无偿授予 L1 提案者，基于 Espresso 的行为让 rollups 参与到一个市场中，他们可以动态销售这些权利。这是基于两个不同的理念，一个是利用可由 L1 验证者通过再质押参与的 BFT 最终性装置，一个是使用类似于 执行票 的提案者选择机制。

这一基于排序的版本提供了两种类型的预确认：提案者和验证者。提案者预确认首先产生（亚秒延迟），由共享排序器插槽中的单个提案者提供的抵押物支持，而验证者预确认则在随后 (~1-2 秒延迟)，由参与的验证者提供的抵押物支持。 除了更高的抵押金外，违反验证者预确认还需验证者之间的合谋（需要足够多控制三分之一质押的验证者）。以太坊 L1 提案者也可以通过再质押其 ETH（例如，通过 EigenLayer）作为验证者参与。

以太坊 L1 提案者也可以购买作为 L2 块的共享提案者的权利。rollup 仍然需要交易在被包含之前获得验证者预确认。与稀疏的Based Rollups 不同，这确保诚实预确认的 rollup 交易在其依赖的最后以太坊块的基础上是最终的。换句话说，除非这个过往的以太坊块被重组，或验证者的门槛没有过分恶意并愿意承受被削减的抵押利益，否则这些交易将执行。因此，验证者预确认在当今 rollups 中充当了外部排序器的类似角色。这使得提案者能够在不受到已确认的最新以太坊块影响的前提下，为纯 L2 交易提供飞速的预确认。相比之下，在稀疏的基于排序中，在某个块 \(B_t\) 中，由 L1 提案者包含的新 rollup 交易并不受制于 \(B_{t-1}\)，以此造成在发生重组时 \(B_{t}\ 的交易可能没有保证。 针对包括在 \(B_t\) 的交易的 L1 提案者预确认不能立即给予无风险的确认。

另一方面，要求 L2 交易获得验证者预确认的一个警示是，如果太多验证者离线（例如，超过三分之一），即使在以太坊 L1 仍然在线的情况下，验证者 BFT 最终性装置可能也会停滞活跃性。然而，基于 Drake 的最初设计也面临一个类似的问题，即当过多选择参与预确认提供者的 L1 验证者（也称为 preconfers）离线时（例如，如果下一个 32 个提案者中没有一个包含预确认者）。在那个设计中，预确认的交易在 rollup 中获得优先处理，当预确认者离线时，L2 将需要停滞。在这两种情况下的缓解措施是设置超时期，如果 L2 未有进展则回退至（纯基于排序的）以太坊 L1。 rollups 可以做出这一选择。

在基于 Espresso 的设计中，与稀疏的基于排序一样，当 \(B_t\) 的 L1 提案者也获得在同一时间段提议 L2 块的权利时，它便可以选择交错 L1 和 L2 交易。结合低延迟证明，它甚至可以促进 L1 合约和 L2 合约之间的同步可组合性。然而，由于依赖于近期尚未最终确认的 L1 交易，因此针对这些同步交互的预确认风险更高。因此，它可能更偏向于首先对在 \(B_{t-1}\) 块上的条件最终状态的 rollup 交易进行排序。这些交易即使在 \(B_t\) 被重组的情况下也能保证在 rollup 上执行。用户可以通过支付小费来享受这种更强的最终性，即基于 \(B_{t-1}\而非 \(B_t\) 的条件，尤其是对于在 L2 上且不依赖于 \(B_t\) 中任何 L1 活动的交易。即便没有 L2 和 L1 块之间的同步交互，共享的 L1 提案者始终可以强制执行 L1 和 L2 交易之间的原子执行条件。

另一个重要的区别是，虽然 L1 提案者可以获得提案权并给予预确认，但如果 L1 提案者在其插槽未行使该权利，另一方将取得相应权利，且其也有能力提供预确认（尽管仅适用于 L2 交易）。这在最初参与 rollup 排序和预确认的 L1 提案者比例较小的情况下尤为有利，因此 L1 到 L2 的同步交互会显著减少。

在没有有 L1 与 L2 同步交互的块中（对大多数 rollups 而言可能并非每个块），交易可以通过验证者 BFT 协议记录并可用，并周期性地结算到 rollup 合约（而非每个以太坊块）。鉴于该验证者 BFT 协议拥有比以太坊 L1 更高的吞吐量和更廉价的数据可用性，这对 rollups 的数据压缩有益。而这对 validiums 特别有利。

构建细节

在以太坊 L1 的基础上引入了两个关键组成部分。

• HotShot 最终性装置： HotShot 是一个在部分同步状态下实现安全性和活跃性的状态机复制（SMR）协议，只要参与质押的三分之一参与者不出现故障。任何安全性违例将造成三分之一的质押被削减（并且也需要协调一组控制三分之一质押的节点）。它能够乐观地在几秒内达成对块提议的最终性。我们称参与者为 验证者。该状态跟踪每个唯一域标识符（别名命名空间）的块链。它与下面的提案者选择机制保持同步，因此在任何给定状态下，它只能将块添加到由被分配的提案者签章的命名空间中。该协议的插槽称为 HotShot 槽，与（但可能比）以太坊 L1 更频繁同步。HotShot 允许质押 L1 验证者参与（例如，通过 EigenLayer）。

• 组合提案者选择： 此组件运行一个 组合彩票，将提案者分配到每个 HotShot 插槽的命名空间。HotShot 插槽有时长，并且可以在同一插槽内接受多个连续的块提议。提案者可以同时被分配到多个命名空间，我们称之为一个 捆绑 。选择机制中的参与者可以为单个命名空间和命名空间捆绑各购买彩票。组合彩票是彩票的组合拍卖的等价物，参与者对捆绑相关性进行投标；或者同样可以视为按暂时投标格局组合拍卖，具有成比例的分配。提案者分配的彩票在某个插槽的 32 L1 槽之前运行。最后，当以太坊块的 L1 提案者（在 32 个插槽之前成为已知）可以选择从被分配的提案者处购买 HotShot 提议权利。

接下来我们描述这些组件如何结合在一起。首先让我们区分两种类型的 rollup 合约调用：

• \(L1 \rightarrow L2\) 交易：函数调用依赖于并可能修改以太坊 L1 的状态。这些包括桥接存款。这不会立即写入 L2 状态，但会更新一个排队，这最终会被 \(L2 \rightarrow L2\) 交易消费。

• \(L2 \rightarrow L2/L1\)：更新 rollup 状态 st，对 L1 状态没有立即侧效应，但可能依赖于 \(L1 \rightarrow L2\) 交易的队列，并可能更新 L1 交易的队列（例如，提取），最终将在 L1 交易中消费。

1. 在 HotShot 中跟踪以太坊 L1 的状态。 虽然 HotShot 状态并未执行 rollup 交易，但协议内部有最小的状态和执行引擎。HotShot 状态将按如下方式跟踪以太坊状态。每个 HotShot 状态指向以太坊 L1 分叉的顶端，我们可以称之为 _<L1ref>。每个 HotShot 块提议有机会更新 _<L1ref> 指向新的以太坊块，如果 (a) 块位于扩展旧的 _<L1ref> 的链的顶端，或者 (b) 块位于按照以太坊的分叉选择规则更优先的更重的分叉的顶端。注意，HotShot 状态并未保证在任何给定时间跟踪以太坊的真实最新状态，且这也并不等同于让所有 HotShot 验证者对此进行投票。然而，任何诚实的 HotShot 提案者若知道最新状态则能够成功更新 HotShot 以反映这一点。这是我们所希望的关键特性。 实质上，HotShot 充当了以太坊 L1 的可信客户端。

2. HotShot中的隐式 DAG。 HotShot 块的链推导出一种基于 L1 分叉索引的 L2 状态的 DAG 结构。每一轮 HotShot 可以通过指向以太坊 L1 的某个分叉更新 _<L1ref> ，并同时添加分别的 rollup 命名空间的 L2 块。任何 L2 块的 _<L1ref> 是来自于前一个 HotShot 块的 _<L1ref>。所有共享相同 _<L1ref> 的 successive L2 块将被 rollups 解释为在 _<L1ref> 块后的及后续的 L1 块之前执行。每个 L2 块都是一个 \(L2 \rightarrow L2\) 对 rollup 合约的调用，因此可以在不对 L1 状态产生任何直接影响的情况下，向下追加到下一个 L1 块之前。 L2 块仍可能排队操作（如提取），在 L1 汇总更新其合约后会发生实际效果。L1 块也不能在不通过 HotShot 的情况下改变 rollup 合约的状态，但可以排队 \(L1 \rightarrow L2\) 交易（如桥接存款）。来自 L2 块的排队交易将在最终更新 rollup 合约的 L1 块中结算。因此，每个 HotShot 块被 rollup 的派生管道表述为在以太坊某一特定分叉上执行，并且默认情况下，只有在分叉最终产出以太坊的基础上才具备最终性。然而，作为 HotShot 块的一笔独立的交易可以选择在早期的以太坊块上基于 _<L1ref> 选择性最终。例如，如果一笔交易将其参考点定为某个以太坊块 id，则只要包括 id 的任何以太坊分叉将会执行该笔交易。若该交易不依赖于在块 id 和 _<L1ref> 之间出现的任何 \(L1 \rightarrow L2\) 交易，则执行此交易的理由特别强烈，因为它将具备更强的最终性（块 id 更不容易重组）。我们将在接下来的合约中提供更多详细信息。

3. L1 指针的提案者。 每个 HotShot 槽都有一个被分配的提案者，以更新被跟踪的以太坊状态 _<L1ref>，这也适用与其他命名空间。L1 提案者始终有能力获得这一权利。注意，尽管 _<L1ref> 的更新可以与在同一 HotShot 插槽内的 rollup 块同时进行，正如第 2 项所述，rollup 块将首先被应用（即发生在新 L1 块之前，而不是之后）。

4. L1 上的 rollup 智能合约。 L1 上的 rollup 智能合约跟踪 rollup 的状态，但可能会滞后。通过在 L1 块内部进行调用来更新 rollup 智能合约。目前, rollup 合同通常每个以太坊块只调用一次，甚至更少。然而，如果 L1 块构建与 L2 块构建协调进行，那么在单个 L1 块内，rollup 合约可能被多次调用，且与其他 L1 上的合约进行同步交互。如今，大多数 rollup 智能合约都设有指定排序器，其必须对任何合约更新签署（不是桥接交易除外）。

为了通过 Espresso 作为Based Rollup 进行集成，rollups 将用下述逻辑取代这一点。

HotShot 轻客户端。 rollup 跟踪 HotShot 状态（作为 HotShot 的轻客户端）。HotShot 形成连贯的链（它不再分叉）。

调用 rollup 合约。 rollup 合约存储 rollup 状态 st 和 L1 化合约调用的 queue，及指向最近的 HotShot 块 h 的指针，用于更新该状态。当其接收来自 L1 块内部合约调用的桥接交易时，这些交易被添加到 queue 中，但这不会立即改变 st，因为这只能通过提供从上次在当前分支上更新合约的情况下 HotShot 完成的 L2 块的执行证明来更改。在更详细的说法中，如果合约在一个 L1 块中进行调用以更新 rollup 状态，定义为 id，且当前状态为 st 并指向最后一次更新的 h，那么新的状态 st’ 提供了指向 h’ 的指针，应该为沿着 h 到 h’ 的独特分叉中所实现的所有 HotShot 完成块。 （在乐观的 rollups 情况下，rollup 合约接收 st’，然而可通过欺诈证明进行质疑；而在 zk-rollup 中则直接接收到正确推导的证明）。重要的是，HotShot 中 L2 块和 L1 引用出现的顺序决定了 L1/L2 交易的相对顺序。最终，记录 L2 状态更改的 L1 块对相对顺序没有影响，而在 L1 合约中记录的状态可能滞后于 L2 的真实状态。

L1/L2 同步交互。 在到目前为止的描述中，HotShot 仅将完整的 L1 块交错与完整 L2 块。我们增加一个功能，以便在 L1 提案者同时作为 HotShot 提案者时启用 L1 与 L2 之间的同步交互，HotShot 记录 部分 L1 状态。本质上，这使得可以从任何 _<L1ref> 块的分叉的建立交错的 L1 和 L2 交易，直到完整的 L1 块完成，并在 L1 块未在 L1 上进行提议时将被放弃。这些交易在它们被提议的 L1 块包含之前具备更弱的最终性。这位 L1 提案者可以通过从不提议记录在 HotShot 中的临时分叉而轻易重组。在此特性中的主要目标是启用 L1 与 L2 之间的同步组合性而不影响其他任何东西。我们不能简单地允许每个 L1 块在未参与 HotShot 的情况下包含 L2 交易，因为那样将打破 HotShot 在一系列 L1 块之间提供的 L2 块的最终性。相反，在以 _<L1ref> 为起点的 L1 提案者若也是 HotShot 提案者，它可以先获取 HotShot 的确认，使 _<L1ref> 成为当前以太坊链头，再逐次在 HotShot 中记录每个 \(L1\rightarrow L2\) 和 \(L2\rightarrow L2/L1\) 交易。Rollup派生管道将按序列顺序执行这些交易。在 HotShot 最终确认每个 \(L2 \rightarrow L2/L1\) 交易后，L1 提案者可以在 L1 合约中记录状态变化。 这允许在同一块内部从L1 到 L2 和从 L2 反映到 L1 的消除信息流。

其他说明：

• HotShot 插槽将与以太坊的 12 秒槽时间进行同步。
• L1 提案者获得在 HotShot 中为其免费更新 L1 引用的优先购买权。
• 组合拍卖发生在 L1 提案者确定之前，以便激励每一个人参与拍卖。
• 一旦 L1 提案者确定他们需要这个 HotShot 注册来确认完成了购买权的行使 （通过创建跟踪 L1 ROFR 的命名空间来完成). 提议该命名空间的提案者是 L1 提案者在未来 32 个块内执行他们 ROFR 的提案者 (32 块是 L1 提案者的经典提前已知的最大条目)。
• HotShot 将支持同一插槽上多个同时提案者（例如，每个命名空间一个提案者），这与 DAG-BFT 协议类似。

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