DBA联创：区块链的架构正在不断趋同

原文标题：《We’re All Building the Same Thing》

撰文：Jon Charbonneau，DBA 联创

编译：Tia，Techub News

介绍

这篇文章分析了以下内容

异步执行——为什么高性能集成区块链（例如 Solana 和 Monad）会将执行与排序（排序）共识分离。
惰性排序——它们将如何反映惰性排序器的设计（例如，Astria）。
预先确认——以太坊 L1 上的 Preconfs 和 based rollups。
Based vs. non-based——比较 based rollups + 预先确认与 non-based rollups + base layer fallback。
通用同步可组合性——通过 atomic inclusion（来自共享排序器）+加密安全（例如，AggLayer 和/或实时证明）。
快速 based rollups——based rollups 应该只有一个 fast base layer。
时机游戏——时间就是金钱，以及这如何导致 Solana 与以太坊之间的不同终局。
去中心化以抗审查——如何通过执行拍卖将证明者与提议者分离，从而确保验证者的去中心化（通过 inclusion lists 来增强抗审查性）。

最后，最重要的是，我们将明白为什么我们都在「建造」同样的东西。

优化状态机复制（SMR）

我们将从基础开始，看看高性能区块链（例如 Solana、Monad、HyperSDK）的终局是否是惰性排序器（例如 Astria）。稍后我们将它们与基于以太坊的 rollups + preconfs 进行全面比较。

排序与执行

区块链是状态复制机。去中心化的节点各自保存并更新系统状态的副本。链的运行是由节点基于当前状态 + 新输入（例如新交易）来运行状态转换函数 (STF)，以此产生新状态。

我们将在本节中使用以下术语：

语法有效——交易格式正确，具有适当的交易结构和签名。
语义有效——交易执行有效的状态转换（例如，支付必要的费用）。
序列——确定数据的顺序和所包含的内容。
执行——根据 STF 解释数据并采取行动。
构建——从本地存储的交易中创建一个块（或部分块/碎片）。
验证——执行区块（或部分块块/碎片）所需的句法和/或语义验证。
复制——将一个块（或部分块/碎片）传播给其他验证者。

让我们放大排序和执行，因为这些是计算链状态所需的核心子任务：

此外，节点会在整个网络中验证和复制数据。节点通过对链保持一致达成共识。

然而，不同链架构的差异点在于谁负责这些任务以及何时负责这些任务（例如，区块构建和验证可能包括或不包括执行）。完成端到端一整个循环的完整状态机复制 (SMR)时间决定了系统延迟的下限。不同的结构会产生高度可变的时间，因此，为了实现低延迟和高吞吐量性能，必须有一个能够高效地流水线处理这些任务的流程（ SMR 流程）。

在以下章节中，我们将展示高效流水线的核心，即专注于执行输入而非执行结果达成共识。这需要对可包含哪些交易等限制进行放宽。然后，我们需要重新引入一些较弱的约束，以确保系统仍然可用且能够抵御攻击（例如，避免不支付费用的 DoS 攻击向量）。

传统 SMR

传统的 SMR（例如以太坊）将排序和执行紧密结合在一起。全节点持续排序并执行所有基础层交易 - 两者都是节点达成共识的先决条件。除了验证所有区块数据是否可用（并已排序）之外，节点还必须执行区块以验证：

所有交易在语法和语义上都是有效的
计算出的新状态与领导者提供的状态相匹配

验证者只有在独立验证了区块状态后才会投票并构建区块。这意味着在达成共识之前至少要执行两次（即区块生产者在构建期间执行 + 验证者再次执行以进行验证）。

在这种传统模型中，构建和验证都包含执行。

来源：Vryx：强化解耦状态机复制

流式 SMR

流式 SMR（例如 Solana）是一种高效的流水线形式，区块生产者在构建区块时不断「流式传输」区块片段（称为碎片或区块）。其他节点会不断接收和验证（包括执行）这些碎片，即使区块的其余部分仍在构建中。这允许下一位领导者更快地开始构建他们的区块。

来源：Vryx：强化解耦状态机复制

在这个流式模型中，构建和验证仍然包括排序和执行。这提高了 SMR 相对于传统 SMR 的效率，同时又不放松所有包含的事务在语义和语法上都有效的约束。

异步执行

综合方法

现在，如果我们放宽这些限制，我们能否获得更好的性能？

异步执行将执行从共识的热路径中移除 - 节点只是就数据的排序达成共识，而无需先执行该数据。这更有效率，这就是 Solana 和 Monad 都计划实现异步执行的原因。

领导者将构建和复制一个区块（或碎片），而无需执行它。然后，其他验证者将对其进行投票，而无需执行它。节点仅就交易的顺序和可用性达成共识。这已经足够了，因为给定一个确定性的 STF，每个人最终都会计算相同的状态。执行不需要维持共识 - 它可以异步运行。这可以为节点腾出执行预算（让它们有更多时间花在执行上），同时减少达成共识所需的步骤（从而减少时间）。

排序决定真相。执行只是揭示真相。 一旦排序确定，任何人都可以执行数据来揭示真相。

这可能就是为什么 Keone 相信最终每个区块链都将采用异步执行的原因，而这也是 Toly 对 Solana 的最终愿景的关键部分：

「同步执行要求所有投票和创建区块的节点都为任何区块的最坏情况执行时间做好充足的准备……共识节点在投票前可以执行更少的工作。工作可以聚合和分批，从而高效执行，不会出现任何缓存未命中。它甚至可以在与共识节点或领导者完全不同的机器上执行。需要同步执行的用户可以分配足够的硬件资源来实时执行每个状态转换，而无需等待网络的其余部分。

目前，验证者会尽可能快地重放每个区块上的所有交易，并且仅在计算出区块的完整状态后才进行投票。该提案的目标是将分叉投票的决定与计算区块的完整状态转换分开。

值得注意的是，我们还希望确保真相能够轻易地向用户揭示，这意味着对轻客户端的强大支持。其中一些设计会显著延迟执行，这会让这一过程变得具有挑战性（例如，Solana 考虑每个 epoch 只需要执行一次），而其他设计则会在较短的延迟内提供状态根（例如，HyperSDK 中的设计）。

模块化方法

这种排序和执行的分离听起来可能非常熟悉，因为这也是「模块化」方法！混合搭配专门处理不同任务的不同层。排序和执行的分离是惰性排序器（例如 Astria）的关键设计原则：

排序——排序器节点仅对 rollup 数据的排序和可用性达成共识（即，它们按顺序排列但不执行）。
执行——在排序器提交数据后，rollup 节点将执行各自的数据。

这里的主要区别在于，链节点的集成在排序后执行，而惰性排序器将其推送给完全不同且多样化的参与者。惰性排序器完全不知道 rollup 的状态机。它们从不执行这些交易。 rollup 处理异步执行。

集成方法为执行环境的用户提供了更加无缝的互操作性，但直接降低了应用开发人员的灵活性（例如，自定义虚拟机、不同的时隙时间、共识强制执行的应用特定交易定价和排序规则等）。模块化方法为开发人员拥有自定义域提供了更大的灵活性和主权，但更难统一它们之间的体验。

无论哪种情况，一个真正大而快速的管道来对数据排序是我们所需要的：

但是，您应该注意，从技术上讲，您可以将几乎任何链用作惰性排序器。毕竟，它只是一个大数据管道。rollup 可以天真地将其任意数据扔到其选择的 base layer 上（无论是以太坊、比特币、Monad 等），以隐式地将其用作排序器。然后，Rollup 节点可以在事后异步执行数据。

差异在于，我们称之为「惰性排序器」的链是专门用于这项任务的，这说起来容易做起来难（例如，支持必要的交易类型、公开简单的接口、实现 MEV 基础设施、快速时隙时间、可靠的交易包含、高带宽等）。因此，用于集成链的节点最终会执行它们包含的大部分数据，而惰性排序器则主要将其留给 rollups。

这就是为什么它并不像「为什么我们不直接使用 Solana（或任何其他链，因为这从来都不是设计目标）作为 rollup 排序器？」那么简单：

缺乏专为 rollup 设计的必要 MEV 基础设施（例如，必要的 PBS 基础设施、跨链互操作性机制、在基础层 Gas 代币中为 rollup 用户抽象费用支付的编写者等）
缺乏为 rollup 发布数据而设计的本机交易类型。
需要与原生执行环境竞争（例如，它明确设计为尽可能多地使用所提供的全部或尽可能多的数据，留下更少的空间和可靠的交易等）。
需要争夺一般开发人员的支持和升级优先级。您可能更倾向于选择专门帮助您启动 rollup 并专门为您设计协议的协议和团队，而不是大多数社区认为 rollup 有点愚蠢的协议和团队。

强化解耦 SMR

那么，我们可以通过放宽这些限制来解决这些问题吗？简而言之，是的，简单的实现确实会带来问题，例如允许无法支付费用的无效交易（如果简单实现，这将是 DoS 向量），但这些问题是可以解决的，因此它们并不是严重的问题。

我们不会在这里过多地讨论细节，但您可以参考 Patrick O'Grady 以强化解耦 SMR 在 Vryx 上所做的出色工作，Toly 的异步执行终局以及 Monad 如何实现运输成本。同样，毫无疑问，无论是在模块化方面还是在集成方面，这些问题的解决方案看起来几乎相同。

总结一下，他们可以重新引入一些更弱的约束（与具有完整验证的同步执行相比），这些约束保留了大部分性能优势，而不会留下一堆攻击。

协议内参与者与协议外参与者

重要的是，我们需要意识到，上述过程天真地只考虑了协议内的参与者。实际上，协议外的参与者在这些交易供应链中发挥着巨大的作用。这就是我们之前在传统 SMR 中看到的（协议内）验证者：

来源：Vryx：强化解耦状态机复制

但实际上，几乎所有以太坊验证者都通过 MEV-Boost 外包区块构建，排名前三的构建者（Beaver、Titan 和 rsync）构建了几乎所有这些区块。请注意，Beaver 和 rsync 审查 OFAC 交易，而 Titan 则不审查。

来源：mevboost.pics

中继负责将这些区块复制到网络的其余部分。排名前四的运营商（ultrasound、bloXroute、Agnostic 和 Flashbots）中继了绝大多数区块。bloXroute 和 Flashbots 审查 OFAC 交易，而 Agnostic 和 ultra sound 则不审查。

来源：mevboost.pics

正如我们之前讨论的那样，我们看到了非常相似的延迟优化趋势，这也不足为奇。趋势是朝着乐观中继的方向发展，它不再在复制之前执行块验证，因为它速度更快。惰性排序器可以被视为激励中继网络。

这些例子凸显了 MEV 如何扭曲这些系统中的利润激励。验证者将区块生产外包，因为经验丰富的构建者可以捕获比天真的排序区块更多的价值。

即使在异步执行下，也经常会有协议外的区块生产者在构建期间执行交易以最大化价值。例如，懒惰的排序器很可能以某种形式的 PBS 拥有利润最大化的构建器。外部区块生产者始终受到激励以完全执行和优化区块的价值，这一事实实际上在我们放松异步执行约束的设置中很有用。尽管如此，其他验证者在投票前不需要重新执行。

通用同步可组合性

定义

现在，我们能否获得模块化链提供的主权和灵活性，同时将它们重新整合，让它们感觉像一条集成链？我们可以鱼与熊掌兼得吗，还是最终只能多走几步来构建 Solana？

当听到人们谈论修复 rollup 碎片化问题时，你可能听说过关于通用同步可组合性（USC）的热门词汇。然而，你的反应可能是这样的：

这些术语的含义各不相同，有些术语经常被错误地互换使用。我们需要设定一些具体的定义。我们在跨链可组合性的背景下定义了以下必要的术语。

请注意，我们将在本报告的其余部分讨论「rollup」，但其中许多概念同样适用于其他类型的「L2」，例如 validium。我只是不想再争论「L2到底是什么」了。

在以下示例中：

R (A) = rollup A
R (B) = rollup B
T (A )(1 = R )(A)上的事务 1()
T (B )(1 = R )(B)上的事务 1()
B (A )(1 = R )(A)上的块 1()
B (B )(1 = R )(B)上的块 1()

请注意，我们在这里将「时间」定义为「时隙高度」。时间完全相对于观察者而言。我们拥有的唯一客观时间概念是共享观察者的相对排序，即共享共识（其中「共识」可能是单个参与者或分散机制）。

如果两个 rollup 都具有提供排序的共识机制，我们可以断言：

B (A )(1)在 B (A2之前)
B (B )(1)在 B (B2之前)

然而，唯一可以断言的方法：

B (A )(1与 B )(B )(1)同时发生，因此
T (A )(1)和 T (B )(1)同步发生，即如果
他们共享该给定时隙的共享共识所提供的顺序。

因此，跨链同步可组合性在定义上需要某种类型的共享排序器来满足该插槽高度的要求。没有此类排序器的链只能具有异步可组合性。

但是，请注意，我们可以实现异步原子可组合性。不幸的是，我经常注意到人们交替使用「原子」和「同步」，但它们确实是不同的术语。

解决了这个问题后，让我们看看是否可以将同步可组合性重新引入模块化链。如果可以，那么这似乎会否定集成链的价值。以下是我们将深入探讨的 TLDR：

共享排序本身可以提供同步原子包容性（这比可组合性弱得多）。
将共享排序器与某种加密安全机制（例如 AggLayer）配对可以将这种包容性保证强化为实际的可组合性。
AggLayer 为跨链安全提供的安全保障也可以在没有共享排序器的情况下使用（即在异步设置中）。
我们将看到如何使用加密经济学（直接抵押跨链交易）来模拟同步可组合性的效果，尽管资本效率较低。

原子包容性 - 共享排序

共享排序意味着，对于给定的 slot 高度，单个实体（「排序器」，又称「提议者」）拥有对多个链进行排序（即提议区块）的垄断权。重申一下，我们通常所说的这些共享排序器是惰性排序器。它们就 rollup 数据的排序和可用性达成共识，但并不执行它。它们完全不知道 rollup 的状态机。

正如我之前所写的，这意味着惰性共享排序器可以提供可信的承诺来包含跨链捆绑（即一组交易）：

原子性——要么所有交易都包括在内，要么全部不包含，并且
同步——同时（槽高度）

这使得超级构建者（即跨链构建者）在执行跨链操作时能够更有效地提取 MEV，因为他们不再需要为跨链捆绑中一笔可能失败的交易进行风险定价。这里的同步性能够隐式地为他们提供原子性。

跨链拆分

那么，在不完全信任共享排序器的构建者和 / 或活跃提议者的情况下，我们该如何做到这一点呢？如果我们为每个 rollup 发送两个独立签名的交易（T (1)和 T (2)），共享排序器仍然可以决定只包含其中一个。

例如，目前 EVM 中没有原生捆绑格式的概念，这就是为什么搜索者完全信任构建者/中继者不会解绑它们。任何在当前领导者承诺之前看到一组独立签名交易的人都可以解绑它们。这通常是可以的，因为构建者和中继者有动力维护他们的声誉并保护搜索者的捆绑包，但当这种信任被打破时（或者他们被不诚实的参与者欺骗而透露交易），解绑可能会带来令人难以置信的利润。

如果我们想要真正的跨链互操作性，我们需要更强大的安全保障。我们谈论的不仅仅是从搜索者那里拿走一些钱。如果跨链 DeFi 合约是在跨链捆绑包将受到尊重的假设下构建的，但这种信任被打破，那么结果对这些协议来说将是灾难性的（例如，在销毁和铸造的跨链桥捆绑包中，你可以省略销毁，但在另一边铸造资金）。

我们需要严密的安全保障来实现跨链互操作性。这意味着我们必须定义一种交易格式，以确保跨链捆绑中的多笔交易都被包含。如果只包含其中一项交易而没有包含另一项交易，我们需要一个安全保障，即包含的那项交易无效。

这意味着我们需要为无法解绑的跨链捆绑包创建一个新的交易结构。最简单的解决方案是「让我们为这些 rollup 创建一种新的交易类型」，但这并不容易。这需要对这些 rollup 包进行 VM 更改，从而失去向后兼容性。你还需要通过修改 rollup 包的状态机来紧密耦合 rollup 包，使得每笔交易只有在另一笔交易被包含时才有效。

但是，有一种更简洁的方法可以做到这一点。您可以让捆绑包中的每个交易也签署捆绑包哈希，然后将哈希摘要附加到空闲交易字段（例如，EVM 中的 calldata）。rollup 必须修改其派生管道来检查这些，但 VM 可以保持不变。有了这个，rollup 用户可以提交他们确定无法解绑的跨链捆绑包。尝试这样做会使它们无效。

来源：Ben Fisch

包容性保障与状态保障

有了上述内容，我们现在已经确定了惰性共享排序器的工作方式：

可以为跨链捆绑提供可信的原子同步包含承诺（即所有交易都将被包含，或都不被包含）
无法对此类交易被纳入后的结果状态提供可信的承诺（例如，有可能两笔交易都被纳入，但其他一些交易先于它发生并导致它撤销）

不幸的是，原子包容性本身的保证要弱得多。这种对原子包容性的承诺足以让构建者高度相信，他们构建的跨 rollup 区块如果得到确认，将创建他们想要的结果状态。构建者必然知道区块的结果状态，因为他们执行了该操作来构建它。

但我们仍面临一个问题——其他人怎么能确切地知道情况将会如何呢？

考虑一个例子：

我们有两个 rollup （ R (A)和 R (B)）共享同一个惰性排序器
我想在 R (A) → R (B)之间使用销毁和铸造桥，同时在 R (A)上销毁并在 R (B) 上铸造
R (B)上的铸造桥合约需要保证 R (A)上的状态转换（销毁）到 R (B)上的铸造，但合约无法知道执行时代币是否在 R (A)上被销毁，因为它无法访问 R (A 的状态)

如果我们提交了适当的捆绑包，那么惰性排序器可以保证销毁交易包含在 R (A) 的交易流中，但你不知道例如是否有另一个交易落在它前面并使其无效（意味着代币实际上并没有被销毁）。

仅仅共享一个惰性排序器不足以使链在捆绑执行期间访问彼此的状态。同步可组合性要求每个链的状态机能够在执行时访问其他链的状态（例如，R (B）上的桥合约本身需要知道 R (A)的状态。这种能力正是在单个集成链中实现完全可组合性的关键。

构建者不能只是告诉合约「相信我兄弟，一切都会好起来的。」我们看到，原子包容性对于信任构建者能够正确执行其捆绑包的搜索者来说是一个很好的工具，但它不足以抽象出跨链互操作性。

为了解决这个问题，除了共享排序之外，我们还需要添加一些其他机制：

正如我们提到的，如果捆绑包以原子方式包含，构建者个人知道最终状态会是什么。那么他们如何提供可信的承诺，让其他人相信，如果他们的交易被包含，最终状态会是什么？

他们大致有两种选择：

加密经济学——构建者可以投入大量资金来完全担保其跨链操作。这通常效率低下，可以说是模拟了可组合性，但它是展示功能的有用示例。
加密——我们可以有一种机制，提供加密保证，确保交易将产生所需的状态。

加密经济安全 - 建造者债券

让我们通过一个例子来了解加密经济学如何模拟同步可组合性的效果。使用的经典示例是跨链闪电贷。我想在 R (A)上借一笔闪电贷，用它在 R (B)上套利，然后在 R (A)上归还它，所有这些都在同一个时间段内完成。如果这些 DeFi 协议部署定制的跨链功能，并在每一侧都部署我们称之为「银行合约」，那么这是可能的：

现在来看看安全问题——R (A)和 R (B) 上的合约需要知道彼此的链状态才能安全地执行此操作，但我们没有采取任何措施来解决这个问题。好吧，这里的加密经济「解决方案」实际上是相当蛮力的——你让超级建造者充当流动性提供者并提供闪电贷的全部价值。如果交易失败，那么借贷协议无论如何都会保留他们的股份。你可以明白为什么这不是最令人满意的「解决方案」。

加密安全 - AggLayer

这是什么

AggLayer 是一个去中心化的协议，具有三大优势：

实现快速跨链可组合性的安全性 - 它生成 ZK 证明，为 AggChains 提供加密安全性，以便在异步或同步操作时以低延迟（即比以太坊块更快）实现原子跨链互操作性。该设计独特地隔离了链故障，因此它可以支持任何执行环境和证明者。
跨链资产可互换性- 它有一个共享桥，以确保跨 AggChains（即使用它的链）的资产可互换性，这样用户就不会得到一堆包装资产。桥合约位于以太坊上，即结算层。（请注意，不同的链仍然可能有不同的安全假设，下面将详细介绍。）
Gas 优化- 它 rollup 了 AggChains 的证明，以摊销多条链上的固定成本。共享存款合约还通过允许直接在 L2 到 L2 之间进行转账而无需触及 L1 来优化 Gas 成本。

资料来源：Brendan Farmer，聚合区块链

为了澄清关于 AggLayer 不是什么的两个常见误解：

AggLayer 不仅仅是一种聚合证明的服务——这很令人困惑，因为它确实聚合了证明，而且他们在名称中加入了「聚合」一词。然而，AggLayer 的目的是聚合链。对于本文的目的而言，重要的区别在于，仅凭证明聚合并不能实现我们在此处需要的安全保障。
AggLayer 和共享排序器并不是对立的设计——虽然它们不需要一起使用，但它们实际上是完美的补充，提供不同的保证。AggLayer 完全不了解 AggChains 的排序方式。它不处理链之间的任何消息传递，因此它实际上明确依赖自由市场协作基础设施（例如，中继器、构建器、隔离排序器、共享排序器等）来组成链。

现在让我们了解一下它是如何工作的。

跨链桥很糟糕

如今，在 rollup 之间进行跨链非常糟糕。假设你想在两个以太坊 optimistic rollup ORU (A)和 ORU (B)之间对 ETH 跨链：

原生跨链- 您将支付昂贵的以太坊 L1 Gas 费用（即从 ORU (A) → 以太坊 + 以太坊 → ORU (B)跨链），并且往返将需要一周以上的时间（因为存在故障证明窗口）。
直接 rollup → rollup - 您在 ORU (B)上收到的包装 ETH 实际上无法与 ORU (A)的原生 ETH 互换。通过不同跨链的路径依赖性破坏了可互换性。例如，如果 ORU (A跨链被耗尽，那么您跨链到 ORU )(B)的包装 ETH将得不到支持，而 ORU (B)上的原生 ETH则不会有问题。流动性碎片化很糟糕，所以这不是用户想要的。实际上，用户直接通过流动性提供者跨链。有人会将 ORU (B)上的 ETH 交给您，并将您的资金保留在 ORU (A)上。他们可以通过原生跨链提款并等待，但他们会收取高昂的费用以承担风险和高昂的资本成本。

您可能认为 ZK Rollups 可以立即解决这个问题，但实际上并非如此。简单的实现仍然需要您提交 L1 交易，这同样成本高昂且通常非常缓慢（例如，由于以太坊的最终确定时间、证明生成时间、实践中发布证明的频率等）。

用户不想处理这个问题。他们只想拥有资金并使用应用。跨链应该完全抽象 - 资产应该是可互换的，并且可以快速、廉价且安全地移动。

这就是共享桥合约的用武之地。共享桥合约为使用它的链打开了大门，使它们可以直接在彼此之间架起桥，而无需通过 L1。

因此，代币也可以在 AggChains 之间互换。将 ETH 从 R (A) → R (B)或 R (C) → R (B) 跨链。它不是锁定和铸造的包装资产。它是原生 ETH。这是可能的，因为所有资产都托管在一起并通过统一跨链桥结算。这是当今 L2 需要解决的一个主要痛点。

但是，请注意，如果不同的链使用不同的验证器（例如，也许您从一条安全链移到了一条有电路错误的链），那么在 R (A)和 R (B)上持有 ETH 的用户可能会有不同的风险状况。

悲观证明

AggChains 将其状态更新和证明提交给 AggLayer 质押节点，后者负责安排这些更新和证明，生成对所有消息的承诺，并创建递归证明。然后，AggLayer 生成一个聚合的 ZK 证明（他们称之为「悲观证明」），用于为所有 AggChains 结算到以太坊。由于此处的证明聚合会在任意多条链上摊销成本，因此从成本角度来看，将它们发布到以太坊以便尽快结算是切实可行的。悲观证明程序是用常规 Rust 代码编写的，使用 Succinct 的 zkVM SP1 来简化开发并实现高性能。

这些悲观的证明强化了：

链间会计——证明所有桥的不变量都受到尊重（即，没有一条链可以提取比存入的更多的代币）。
AggChains 的有效性——证明每条链都真实地更新了其状态，不存在链上的含糊不清或无效块。
跨链安全性——证明跨链交易产生的状态更新（延迟低于以太坊）是一致的，并且可以安全地结算到以太坊 L1。这包括成功同步和异步执行跨链捆绑的原子性。

这样，AggLayer 便可确保当且仅当满足上述条件时，才会在以太坊上进行结算。如果不满足这些条件，则相应的链将无法结算。因此，AggLayer 可以允许协作者（例如共享排序器或构建器）以低延迟在链之间传递消息，而无需信任该协作器以确保安全。

快速安全的跨链互操作性

AggChains 可以在异步和同步互操作性设置中使用此处提供的保证来表达相对于其他 rollup 的块有效性约束。

这将使用户能够提交跨链捆绑包，这些捆绑包必须在两侧以原子方式成功执行。不仅仅是原子包容性。您实际上是在强制要求执行它们的结果状态必须成功。这非常适合补充我们所描述的共享排序器单独缺乏的原子包容性保证。

资料来源：Brendan Farmer，聚合区块链

以我们之前的例子来说：

我们有两个 rollup（R (A)和 R (B)），它们共享同一个惰性排序器和 AggLayer
我提交一个跨链捆绑包，同时在 R (A)上销毁 ETH并在 R (B上铸造 ETH)
超级建造者为两条链建造一个区块，然后共享排序器提交该区块
R (B)上的铸造桥合约可以根据 R (A)的状态乐观地铸造 ETH （在本例中，成功执行 ETH 销毁）
这些区块和证明被提交给 AggLayer，以证明两条链都以有效的方式运行（既独立又相互关联），并且共享桥被安全使用

为了成功结算到以太坊，捆绑包的两边都必须正确执行。如果任何一方失败，那么区块将无效并且无法结算。这意味着，如果共享排序器签署了一个区块，其中 ETH 未在 R (A)上销毁，但在 R (B)上铸造了 ETH ，那么该区块将被重组。这确保了所有链的安全，并防止不诚实的跨链操作得到结算。

关于这些重组，有两点需要牢记：

它们会非常短，因为它们会立即被发现和证明。
只有当您所连接的链的协作者（例如，排序器和/或构建器）主动怀有恶意时，才会发生这种情况。

由于上述几点，重组应该极其罕见，但正因为如此，AggChains 对于想要和哪些链组合以及以什么样的信任假设拥有控制权。例如，R (A)可能会接受来自 R (B) 的链状态，并根据其排序器的共识进行组合，但对于 R (C)，它可能也希望提交证明，而对于 R (D)，他们可能希望它们以加密经济的方式保护所有跨链原子依赖关系。每条链都可以在此处做出自己的可定制权衡，以实现低延迟和活跃度。AggLayer 只是为链提供最大灵活性和最小主观性的基础，以实现安全的跨链交互。

您还可以在这里看到为什么这种设计在实践中与基于故障证明的设计不兼容。理论上他们可以这样做，但在这种情况下，可能会经历令人难以置信的深度重组。快速证明和解决所有链将最坏情况限制在非常短的时间内，这也对任何恶意尝试起到了自然的威慑作用。

异构证明器的故障隔离

重要的是，AggLayer 以独特的方式实现了完全异构的链。您可以拥有一个带有任何自定义 VM、证明器、DA 层等的 AggChain，同时安全地与所有人共享跨链。

但是这怎么可能呢？这通常是不可接受的，因为单个有故障的参与者（例如，有电路错误）通常可以欺骗跨链桥并耗尽所有资金。这就是上面提到的链间会计证明的作用所在。这些证明确保所有跨链桥不变量都得到尊重，因此即使在证明者不健全的情况下，也只有存入受影响链的资金会被耗尽。故障是完全隔离的。

可信中立

这种类型的基础设施极大地受益于可信的中立性，这就是为什么AggLayer 的完全开源代码是中立的。本着类似的精神，AggLayer 将使用 ETH 作为唯一的 Gas 代币来支付证明聚合的费用。

但它当然不是完美的。特别是在开始时，它不会完全可信地保持中立。在最终实现不变性和作为公共利益的道路上，可能会有合约可升级性。

话虽如此，它不必完全可信中立，没有什么是完全可信的。（我们将在下文的基于 rollup 中再次看到这一点。）在实践中，它可能提供了最引人注目的技术竞争愿景，并且它对锁定和租金提取采取了刻意简约的态度。目标是让 AggChains 尽可能多地保持主权，同时仍然能够抽象出信任最小化的跨链可组合性。

AggChains 不需要任何特定的 VM、执行环境、排序器、DA 层、权益代币、Gas 代币或通用治理。链可以随时退出。没有收入分成要求。您无需在其他链上部署为 L3。

在我看来，在通用 L2 之上推出 L3 大多是权宜之计，类似于 AggLayer 的架构正在构建中。但要明确的是，这是今天为什么要推出它们的理由。v1 AggLayer 只是一个简单的共享跨链合约。具有证明聚合和获得安全低延迟互操作能力的 v2 甚至还没有上线。当人们急切地想要今天发布一款能让他们获得最快分发的产品时，你不能指望他们等待数年。

实时验证

虽然距离在任何低延迟设置中实现实用还有几年的时间，但我们应该注意到，实时证明也可能与共享排序一起使用，以实现跨链安全。这也很酷，所以我们将简要介绍一下。更具体地说，「实时」证明是指比相关链的时隙时间更短的证明时间。让我们再次考虑跨链铸造和销毁的示例：

我们有两个 rollup （ R (A)和 R (B)）共享同一个惰性排序器
我想在 R (A) → R (B)之间使用销毁和铸造跨链桥，在 R (A)上销毁并在 R (B)上铸造
超级构建器会创建一个跨链区块，其中包含这些跨链交易的捆绑包。在区块内部，构建器会包含一个状态转换证明，该证明将包含在其他 rollup 中。

我们已经有了共享排序器的同步原子捆绑包含保证，现在每个合约都可以验证另一条链的状态证明，以了解它是否能成功执行。

对于实时证明，理想情况下希望证明时间仅占总时隙时间的一小部分，从而最大化「同步窗口」。这是您能够处理跨链同步操作的交易的时隙时间的一部分，因为您需要在时隙中预留足够的时间来创建证明并将其放入区块中。

资料来源：Justin Drake，实时证明

请注意，我们最终会隐式地合并或共置构建器和证明器。构建器有明显的动机来优化证明速度，以便他们可以构建到最后一秒并尽可能多地容纳他们的区块。

资料来源：Justin Drake，实时证明

如果这种对实时证明的高激励在未来几年确实实现，这当然对去中心化证明一点也不友好。在与构建者合并或共置（collocate ）时，证明者需要相对中心化。

小结

通用同步可组合性确实很酷，但它的价值到底有多大还不是很清楚。互联网都是异步的，但你永远不会感知到这一点。这是因为它速度快，复杂性被抽象了。这就是用户想要的。

我预计，像 AggLayer 这类协议的价值不仅仅在于同步设置。相反，它实际上可以充当一种跨 Rollup 链抽象。让许多链感觉更像是一条面向用户的链（例如，更多可互换的原生资产、原生跨链应用功能、快速互操作性等）。

显然，同步可组合性是具有经济价值的（例如，允许清算、更高效的套利、使用闪电贷更高效地再融资）。然而，互联网是异步的且运行良好，并且 TradFi 也是异步的。想要比 TradFi 更好是合理的，但我们应该清楚，通用同步性并不是良好执行的必要条件。构建和提供同步基础设施也需要实际成本。

我个人认为支持 USC 的最佳理由是，在实践中，它确实会带来更好的用户体验和 DevEx。不可否认，这给 Solana 等生态系统带来了巨大的好处。然而，我更希望这只是今天的问题，而不是永远的问题。

事实很简单，在现阶段，任何人都很难通过推理得出这一结论。这不是二元对立的：「加密中的一切都是同步的」或「一切都是异步的」。我认为，我们将从根本上解决这一问题并倾向通过后一种方式，但两者都可以临时存在。

基于以太坊的 Rollups

好的，现在我们应该对解决 rollups 碎片化的解决方案有了一个很好的了解。下一个问题是，我们应该如何将 base layer 纳入其中？以太坊在这里扮演什么角色？

我们将始终使用以下缩写：

BL - base layer
BR - based rollup
Preconfs - 预先确认

除非另有说明，我们将要讨论的 BL 是以太坊，BR 是以太坊 BR。但是，基本概念适用范围很广，因为您可以在任何地方启动 BR。

香草口味的 Rollups

几年前，最初计划用 BR 实现 rollup，但后来被放弃，转而采用中心化排序器，以实现低延迟和高效率。我们现在所说的基于 BR 的排序，Vitalik 当时称之为「完全无政府状态」。在以太坊的 PBS 基础设施（拥有成熟的构建者）发展之前，它相对不切实际且效率低下。

2023 年 3 月，BR 再次成为人们关注的焦点，其定义如下：

「当 Rollup 的排序由 base L1 驱动时，该 Rollup 被称为基于 L1 或按 L1 排序的 Rollup。更具体地说，一个 based rollup 也许是下一个 L1 提议者通过与 L1 搜索者和构建者协作，无需许可地将下一个 rollup 区块囊括到下一个 L1 区块中。

它们应提供以下好处：

「这种 rollup 的排序非常简单，并且继承了 L1 的活性和去中心化。此外，based rollups 与它们的 base L1 在经济上特别一致。」

具体来说，您可以获得以太坊的实时安全性：

「你继承了以太坊的抗审查性和活跃性。因此，你不仅拥有以太坊的结算保证，而且还拥有抗审查性，实时的抗审查性，不是你所知道的带有逃生舱的延迟审查，而是实时的审查。」

一旦选择了 based rollup，基于 rollup 的设计就是合乎逻辑的：

「以太坊正在最大限度地发挥这两个特性，即安全性和可信中立性，这几乎就是 Rollup 的定义吧…… Rollup 已经接受了以太坊的安全性假设。你不会添加新的安全假设。你不会陷入最薄弱的环节。你只是在重复使用现有的安全假设。其次，你已经接受以太坊作为一个可信中立的平台，否则你会选择另一条链。现在你可以问自己，为什么不是每个人都只使用 L1 排序？」

在最简单的形式中，BR 当然可以实现上述设计目标。如果 rollup 没有使用自己的排序器，那么当前的以太坊提议者会每 12 秒（以太坊的 slot 时间）决定要包含哪些内容。

然而，based sequencing 仍然有许多需要权衡，这也是为什么 rollups 通常使用自己的排序器的原因：

快速 preconfs ——Rollup 用户不想等待 12 秒以上的时间来获取以太坊区块。
安全的 preconfs——有时以太坊会阻止重组，因此用户必须等待更长时间才能确保安全，这也是用户不喜欢的。排序器可以提供不依赖于未完成的以太坊区块的 preconfs，因此即使以太坊本身经历短暂的重组也不需要重组。
高效的批量发布——排序器可以批量处理大量数据、对其进行压缩，并以成本优化的方式定期将其发布到 BL（例如，确保完全使用 blob）。

Based Rollups + Preconfs

那么，我们可以鱼与熊掌兼得吗？来看 based preconfs。

我们将在这里相对简要地解释 based preconfs，以便我们可以对 BR + preconfs 与传统 rollup 进行比较。稍后，我们将回过头来更详细地更全面地分析 preconfs。

核心思想是 BR preconfs 必须来自 BL 提议者。为了提供 preconfs，这些提议者必须提供一些抵押品（例如，再质押）并选择额外的罚没条件（即他们提供的 preconfs 确实会按照承诺上链）。任何愿意这样做的提议者都可以充当 BR 排序器并提供 preconfs 。

我们应该注意到，提议者（即验证者）实际上应该将提供 preconfs 信息的角色委托给更专业的实体，即「网关」。提供 preconfs 信息需要一个相对复杂的实体，而以太坊希望提议者保持简单。

但是，预计现有的中继也将接管这一角色。网关只会在用户和中继之间进行交互，因此添加另一个独立实体只会增加复杂性和延迟（尽管延迟也可以通过共置来解决）。中继已经受到构建者和提议者的信任，因此我们将在这里向用户添加另一个对他们的信任要求。

请注意，虽然验证者目前充当以太坊区块提议者，但正在考虑进行升级，协议本身将通过执行拍卖直接拍卖提议权。这将允许成熟的实体直接购买提议权，从而避免验证者（当前的提议者）像这里设想的那样委托给他们。

无论如何，重要的一点是，任何比以太坊共识（12 秒）更快的 preconfs 都需要可信的第三方 (TTP)。无论您的 TTP 是再质押的验证者、质押执行拍卖获胜者、委托网关还是其他任何方式，它从根本上都无法提供实时的以太坊安全性。无论 Coinbase 为您提供作为以太坊提议者的「基于 preconfs 」还是作为 rollup 排序器的「传统 preconfs 」，您都信任 Coinbase。他们同样可以建立一些 ETH 的债券，但无论哪种情况，这都与以太坊共识的安全性无关。

我们应该注意到，任何基于 preconfs 的设计都必然会偏离我们最初提出的 BR 目标（简单性和 BL 安全性）。基于 preconfs 的越来越复杂，它们无法提供以太坊的实时安全保障。

但是，如果这些 preconfs 者离线或开始审查，您应该保留通过 BL 交易直接强制交易的能力。当使用包含列表时，以太坊的这些保证应该会变得更加强大。

对于 BR - TTP 提供快速 preconfs，而 BL 提供最终的安全性。

Non-based Rollups + Based Fallback

现在让我们考虑一个传统的（即 non-based）rollup。它自己的排序器（无论是中心化还是去中心化）提供快速的 preconfs。之后，它们的用户在延迟后获得了完整的以太坊安全性。包括来自某种强制纳入或 BL fallback 机制的活跃度（账本增长 + 抗审查）。

正如我在 Rollups 是否继承安全性？中提到的：

Rollup 能够公开与其主链具有相同安全属性的确认规则。它们最多只能以主链共识的速度接收这些属性（实际上，根据 Rollup 发布到主链的频率，速度通常会慢一些）。

Rollups 还可以提供「快乐路径」的宽松确认规则（即排序器），以提供更好的用户体验，但它们拥有发生故障时的后备方案。

请注意，最终实现安全的时间是此处需要优化的关键变量：

假设 rollup 用户可以恢复到与主链等效的活跃度，即假设你可以按照与主链区块完全相同的速度进行强制包含（例如，如果 rollup 排序器正在审查你，那么你可以强制将交易包含在下一个以太坊区块中）。

实际上，通常会有短暂的延迟。如果你允许立即强制纳入，你可能会暴露有利可图的审查 MEV 以及其他复杂性。然而，有些设计可能会从主链提供近乎实时的活性保证（例如，可能以几个主链区块而不是一个区块的速度）。

本着这种精神， Sovereign Labs 进行了如下设计：

许可排序- Rollups 设置了一个许可排序器，其交易在被纳入 BL 后会立即得到处理。由于它们对 rollup 的状态有 write-lock，因此它们可以比 BL 更快地提供可靠的 preconfs 。
基于排序- 用户还可以直接向他们的 BL 提交交易，但这些交易的处理需要 N 个区块延迟（其中 N 足够小）。这大大减少了「最终安全的时间」，事实上，他们甚至因此将这种设计称为「基于软确认的排序」！（请注意，BR 的这种定义与我们之前提供的定义相冲突，即 BL 提议者必须有权对 BR 进行排序或由他们委托。）

对于非 BR - TTP 提供快速 preconfs，而 BL 提供最终的安全性。

是吗？非 BR 提供快速 preconfs，而 BL 提供最终的安全性

我们可以看到，上述两种路径都会产生相同的有效结果：

这些带有 preconfs 的 BR 不再提供以太坊的简单性或实时安全性。那么现在这一切有什么意义呢？我们为什么不加强对「传统」 rollup 的后备措施呢？「based rollup 」到底是什么？

这实际上可以追溯到我去年发表的《治理证明》一文，当时我讨论了以太坊特定的再质押的基本用例：

1) 技术（提议者承诺） ——没有办法解决这个问题。如果你想要对以太坊区块的排序做出可信的承诺，那么它必须来自以太坊验证者。MEV -Boost++是一个可能属于这一假设的例子。

2) 社交——我认为以太坊一致性的主要用例是当今大多数再质押应用，而不是经济安全池或去中心化。这就像说「看，我们是一个以太坊项目！」这就是为什么无论架构如何，区块链都一直称自己为以太坊 L2。

我们可以通过思考「BR + preconfs」相对于「传统 rollup + 快速回退」的价值是什么的背景下对其进行现代化改造。

1) 技术（提议者承诺） ——具有 preconfs 的以太坊 BR 具有一项基本的技术优势——它们可以从当前以太坊提议者那里获得关于以太坊区块内容的包含和排序的可靠承诺。这可能很有价值，原因与我们可能希望一堆 rollup 共享一个排序器的原因完全相同。如果 BL 提议者也是 BR 提议者（即排序器），那么他们可以为 BL 提供与共享排序器的任何 rollup 之间相同的原子包容性保证。它们垄断了这两条链。现在，这有多大价值？我们稍后会回到这个问题。

2) 社交（结盟/可信中立） ——喜欢还是讨厌，以太坊一致性是成为 BR 的卖点。说实话，除了「他们是 BR 人」之外，我对 Taiko 了解不多，如果他们不是 BR 人，我可能都不知道他们是谁。每个人都希望进行良好的联合营销。成为这里的先行者是有价值的，但我怀疑这不是一个持久的价值主张，也不会延续到许多未来的潜在 BR 中。同样，我们都听说过第一批 AVS，但你能说出所有当前的 AVS 吗？我不能。

从更高层次来看，你不会让所有以太坊 rollup 都选择加入（假设的）「Optimism 共享排序器」或「Arbitrum 共享排序器」。但你更有机会让它们全部选择加入「以太坊共享排序器」。没有新代币，没有新品牌，没有新共识。如果你认为所有以太坊 L2 在排序上团结起来很有价值，那么这种可信的中立性可能是实现这一目标的最强谢林点。

这种可信的中立性对于试图吸引跨生态系统用户的 rollups 开发者来说可能是最有价值的（例如，具有像 ENS 这样的基础设施的应用）。如果 Optimism 排序器会疏远 Arbitrum 用户，他们可能会犹豫是否使用它，反之亦然。

我们将在下面更详细地介绍其中的每一个。

可信中立

从社会角度来看，BR 通常被视为最符合「以太坊」的选项。抛开任何人对此价值的判断，重要的一点是，这为任何 BR 设计都预设了高度可信的中立性。

在 vanilla 情况下，设计可信中立的 BR 很容易，但正如我们所指出的，没有人真正想要这些。然后， preconfs 必然要求提议者选择额外的罚没条件。这些额外的罚没条件要求提议者使用一些额外的系统（例如，可能是 EigenLayer 再质押、Symbiotic或其他标准）来做出承诺。rollup 可能很乐意在抽象中选择可信中立的「以太坊排序器」，但如果你使用私募的项目，甚至可能是他们自己的代币，可信中立性可能会丧失。

关于抵押品，有几个悬而未决的问题：

抵押品规模

早期的设计假设提议者必须亲自提供 1000 ETH 左右的巨额抵押品。问题在于，从根本上来说，提议者总是可以违背委托和自行构建区块的承诺，在 preconfs 上含糊其辞。这可能非常有价值，而且 1000 ETH 远远高于自 MEV-Boost 成立以来观察到的最高支付额。缺点是，这当然必然会为较小的提议者设置较高的进入门槛，而较大的提议者（例如 Coinbase）可以更合理地提供 1000 ETH，同时获得其所有权益权重（> 13% 的总权益 ETH）的奖励，因为注册者可以为其所有验证者提供单一保证金。还有其他想法可以让提议者提供小得多的保证金，但当然需要权衡。这里的设计空间是不确定的。

值得注意的是，执行拍卖将缓解这种担忧，因为我们可以假设所有提议者都是能够轻松做到这一点的复杂参与者。

来源：Barnabé Monnot，从 MEV-Boost 到 ePBS 再到 APS

然而，即使是大型运营商也不愿意投入大量资金，因为潜在的活跃度问题会导致罚没（运营商方面的活跃度失败，导致我们的 preconfs 在被纳入区块之前失效，这对用户来说同样是一种安全故障，需要受到严厉的惩罚）。

抵押品类型

在这种情况下，Vanilla ETH 可能是唯一可信的中性抵押品。然而，人们自然会希望使用资本效率更高的资产（例如 stETH）。mteam 在此处描述了一些让承销商处理此转换的想法。

平台

如果「基于以太坊的 preconfs 」更像「基于 EigenLayer 的 preconfs 」或「基于 Symbiotic 的 preconfs 」，那么它就不是「可信中立」的。有些团队计划朝这个方向发展，但使用这样的平台并不是严格的要求。可以创建一个供所有人使用的通用中立标准，这样的系统似乎更适合普遍采用，成为最基本的选择。

为了使基于 preconfs 的设计能够合理地实现「可信中立」，需要采用公共物品标准。

预先确认

包容性与状态预设

现在我们将更详细地介绍 preconfs 。虽然我们之前讨论过一种特定类型的 preconfs （BR 状态 preconfs ），但我们必须注意，它们是一个完全通用的概念。除了 BR，您还可以在 BL 交易上提供 preconfs ，并且可以提供不同强度的 preconfs ：

Inclusion preconfs ——对交易最终将被纳入链上的较弱承诺。
状态 preconfs——对交易最终将被纳入链上的最强承诺以及对最终状态的保证。

后者（状态 preconfs ）当然是用户希望他们的钱包向他们展示的内容：

我将 1 ETH 兑换为 4000 美元 USDC，并支付了 0.0001 ETH 的费用

非 inclusion preconfs：

我的交易尝试将 1 ETH 兑换为 4000 美元 USDC，并支付高达 0.0001 ETH 的费用，但交易可能会成功，也可能会失败，我们拭目以待

然而，我们应该注意，在用户对非争议状态采取行动的情况下（例如，只有用户自己才能使交易无效的简单转移），inclusion preconfs 实际上可以与状态 preconfs 互换。在这种情况下，例如「Alice 向 Bob 转移的 USDC 将在接下来的几个区块中被包含」的承诺足以让钱包向用户显示「您已将您的 USDC 发送给 Bob」。

毫不奇怪，更强的承诺（状态 preconfs ）更难获得。从根本上讲，它们需要来自当前垄断提议区块的实体的可信承诺（即链状态的 write-lock ）。在以太坊 L1 preconfs 的情况下，这始终是当前的以太坊 L1 提议者。在 BR preconfs 的情况下，这大概是 BR lookhead 中的下一个以太坊 L1 提议者（因此使其成为 BR 的当前提议者），如下所述。提议者和排序者通常是可以互换的术语，前者在 L1 上下文中更常用，而后者在 L2 上下文中更常用。

定价预设

我们需要做出的另一个重大区分是这些 preconfs 涉及什么类型的状态：

无争议状态——没有其他人需要访问此状态（例如，Alice 想要将 USDC 转移给 Bob）
有争议的状态——其他人想要访问此状态（例如，ETH/USDC AMM 池中的交换）

preconfs 是对最终可能生成什么区块的限制。在其他条件相同的情况下，限制构建者的搜索空间本质上只能减少他们从订购中可能获得的潜在价值。这意味着返回给提议者的价值会减少。为了使其具有激励兼容性，网关需要收取≥潜在 MEV 的 preconfs 费以对结果进行约束。

当 MEV 损失约为 0 时（例如，在 USDC 转移中），这很简单。在这种情况下，收取一些名义固定费用可能是合理的。但我们有一个大问题——我们如何在有争议的状态下为 preconfs 定价？提前定价 preconfs 似乎比即时定价更划算。在其他条件相同的情况下，对于构建者来说，等到最后一秒才能捕捉并准确定价 MEV 是最有利可图的。

不过，我们假设有足够的用户需求来快速 preconfs 争议状态（考虑到经验丰富的搜索者和普通用户），这样有时就会出现一个对每个人都有利的清算价格。现在，你究竟如何为争议状态的交易 preconfs 定价（否则你可能会在接下来的 12 秒内随时将其包括在内），从而有可能放弃不再可能获得的更有利可图的机会？

在整个区块中流传的有争议状态的 preconfs 将与构建者创建区块的方式相冲突。准确定价 preconfs 需要实时评估现在将其纳入而不是推迟纳入对 MEV 的影响，这意味着执行和模拟可能的结果。即网关现在需要成为一个高度复杂的搜索者/构建者。

我们已经假设网关和中继将合并。如果他们需要持续为 preconfs 定价，那么他们也会与构建者合并。我们还接受了 USC 将加速构建者和证明者的合并。执行拍卖似乎也将直接将提议者权利出售给能够为其定价的成熟参与者（可能是构建者）。

这将整个以太坊 L1 和 BR 交易供应链放入一个盒子中，该盒子对该期间所有链的状态具有垄断 write-lock 。

preconf 服务的排序策略尚不明确（例如，它们是否始终运行 FCFS 或以其他方式排序）。网关还可能对所有 preconf 进行拍卖（例如，允许搜索者对 preconf 进行竞价），尽管尚不清楚这种设计会是什么样子，并且这必然意味着更高的延迟。

公平交换问题

preconfs 存在公平交换问题，因为网关实际上并没有直接受到激励去发布 preconfs 。

请考虑以下示例：

当前网关有12s垄断
用户在时隙开始时（t = 0）提交 preconfs 交易请求
网关会等到 t = 11.5 才会发布其在时隙期间做出的所有 preconfs ，并留出 500ms 的缓冲区以将它们全部放入其区块中。届时，他们可以决定在有利可图的情况下包含哪些 preconfs ，以及排除哪些 preconfs 。

在这种情况下，用户最终可能会为 preconfs 付费，即使他们直到时隙结束才真正收到它。如果网关认为包含它无利可图，它也可以简单地在时隙结束时将其丢弃。网关的这种扣留并不是客观上可归因的错误（但它可能是主观上可归因的）。

事实上，网关实际上有动机将 preconfs 信息保留到最后。哪里有信息不对称，哪里就有 MEV。保持交易私密性将使构建者能够更及时地了解世界状况，从而让他们更好地定价风险并获取 MEV。对于提供给用户的一组 preconfs 信息没有共识，因此网关不能承担责任。

需要制定标准，并期望预确认者立即公开传播所有 preconfs 信息。这样可以立即为用户提供他们想要的东西，并让其他人看到网关正在提供预期的服务。如果他们将来无法做到这一点，那么用户就不会信任他们，也不会为 preconfs 信息付费。网关的声誉很有价值。话虽如此，在这里不诚实并违背 preconfs 信息也可能非常有价值。

L1 Base Layer Preconfs

了解了一般的 preconfs 要点后，我们现在将讨论 L1 preconfs 的细微差别。虽然我们之前没有提到它们，但有些项目正在构建这些 preconfs ，它们与 BR preconfs 的交互将非常重要。

例如，Bolt 就是这样一种协议，它希望让以太坊提议者对其区块内容做出可信的承诺。已注册的提议者可以运行 Bolt sidecar 来接收来自用户的 preconfs 请求，确认这些请求，然后将此信息发送给中继器和构建器，后者可以返回遵守这些约束的区块（即，它们返回一个包含提议者给出 preconfs 的交易的区块）。

这里需要注意的是，这里描述的 Bolt v1 仅支持非争议状态的简单交易 inclusion preconfs ，其中只有用户可以使 preconfs 无效。正如我们之前讨论的那样，这些是最简单和最薄弱的承诺。

所有这些 preconfs 团队都有更大的抱负（例如，状态 preconfs 、部分区块拍卖、时隙或部分时隙拍卖），那么是什么阻碍了他们呢？

问责制——承诺违约应在链上可证明，以便进行客观罚没。证明交易纳入相对容易，但如何执行其他承诺（如插槽拍卖）则不那么明确。
资本要求——提供任意承诺意味着违反承诺的代价可能任意高。网关最终可能需要投入巨额资金（例如数千 ETH）来提供这些资金。这些资金最终可能会被集中起来，使最大的实体（例如大型贸易公司或 Coinbase）受益，而较小的实体则被排除在外。
定价——即使我们认为它是可行且有价值的，但仍有很多悬而未决的问题围绕着如何为连续流状态 preconfs 之类的东西定价。
网络参与——这也许是最重要和最基本的一点。正如我们所提到的，只有拥有状态 write-lock 的当前提议者才能提供像状态 preconfs 这样的承诺。理论上，100% 的提议者都可以选择加入这个系统并模仿它。但实际上，这不会发生。

MEV-Boost 是一款更简单的产品，拥有多年的成功经验，运行起来利润极高，参与率超过 92% （可能更高，因为这不考虑最低出价）。新的 preconfs 服务肯定会获得低得多的参与率。但即使它可以达到约 90% 的范围，对于普通用户来说，这似乎也不是一款有用的产品。你不能在 10% 的时间内告诉用户「哦，抱歉，现在没有可用的 preconfs ，请稍后再查看。」

充其量，这感觉就像状态 preconfs 只会成为老练的搜索者和交易者的一个可选工具，他们可能希望在该时段恰好有提议者选择加入时，在区块的早期获得承诺。这可能很有价值，但这里没有碎片化或用户体验解锁。

基于 L2 的 Rollup Preconfs

BR preconfs 必须来自 BL 提议者（这就是它们「基于」的原因）。这要求他们投入一些抵押品并选择额外的罚没条件（即，他们提供的 preconfs 确实会按照承诺将其上链）。任何愿意这样做的提议者都可以充当 BR 排序器并提供 preconfs 。

重要的是，这些 BR preconfs 是状态 preconfs ，而不仅仅是 inclusion preconfs 。这是可能的，因为 BR 选择了一种设计，即它们将轮换排序器垄断权交给注册成为网关的 BL 提议者。

如今，每个时隙都有一个以太坊验证者作为提议者，并且当前时期和下一个时期的提议者时间表始终是已知的。一个时期有 32 个时隙，因此我们始终知道给定时间的下一个 32-64 个提议者。该设计的工作原理是授予下一个活跃排序器（即，lookhead 中的下一个排序器）垄断权力，以对选择加入此 preconfs 系统的 BR 进行交易排序。网关必须签名才能推进 BR 链的状态。

请注意，每个提议者（即使没有选择成为网关的提议者）都有权利但没有义务纳入已由排序器（即那些选择成为网关的提议者）预先确认的交易。他们可以充当纳入者，只要他们拥有截至当时已预先确认的完整交易列表（排序器可以创建包含 BR 交易的 BL blob 并传播它们）。

来源：以太坊排序，Justin Drake

交易流程如下：

BR 用户将其交易提交给 lookhead 中的下一个排序器（下图中的槽 n+1 提议者）
排序器立即为结果状态提供预确认（例如，用户在 BR 上将 1 ETH 兑换为 4000 美元 USDC，并支付 0.0001 ETH 的费用）
此时，任何包含者都可以包含已排序的交易（下图中 slot n 的提议者就是这样做的）

来源：以太坊排序，Justin Drake

如果其他包含者不包括 preconfs ，那么给出 preconfs 的排序者可以在轮到他们作为 BL 提议者时简单地将它们包含在链上。例如，在上图中，假设时隙 n 包含者决定不包括时隙 n+1 排序者给出的 preconfs 。然后时隙 n+1 排序者将负责在提交 n+1 的 BL 块时包括它在时隙 n 和时隙 n+1 期间给出的所有 preconfs 。这使得排序者可以自信地在他们和最后一个排序者之间的整个时间段内给出 preconfs 。

为了简化上述解释，我们假设 L1 提议者将履行这一 preconfs 角色。但如前所述，情况不太可能如此。它需要一个复杂的实体来为 preconfs 定价，为所有 BR 运行完整节点，为所有 BR 交易提供 DoS 保护和足够的带宽等。以太坊希望验证者保持非常简单，因此提议者可能会将 preconfs 外包给另一个实体，就像他们今天通过 MEV-Boost 外包完整的 L1 区块生产一样。

提议者可以通过链上或链下机制委托给网关，这可以一直进行到他们的时段之前。如前所述，这一角色实际上可能会被中继接管。他们也可能需要与建造者合并。

来源：基于排序，Justin Drake

如前所述，在给定时间内只能委托一个实体作为网关。这是提供可靠状态 preconfs 所必需的。UI（例如 MetaMask 等钱包）会留意下一个网关是谁，并将用户交易发送到那里。

以太坊 rollup ——它们将以什么为基础？

现在已经有足够的背景知识了——以太坊 rollup 应该基于什么？这里实际上有两个问题：

许多以太坊 rollup 是否应该共享一个排序器？
如果是，它应该是一个基于排序器吗（即涉及以太坊 BL 提议者和周围的 MEV 基础设施）？

首先，需要注意的是，您可以临时与其他链共享一个排序器。例如，如果以太坊提议者出价最高，他们可能会为您的一个区块排序，然后如果其他 BFT 共识出价最高，他们可能会为您的下一个区块排序。然而，这仍然需要一条链完全选择加入这种可以与其他链同步运行的统一共享拍卖，因此在控制和灵活性方面仍然存在权衡（例如，共享区块时间）。只是获胜的排序器实体可以转移。

不管怎样，我们假设条件 1 得到满足。我认为我们目前有令人信服的证据表明，使用去中心化共享排序仪的需求足够大。即使他们不太关心「共享方面」，我认为能够购买现成的去中心化排序仪即服务具有极高的价值（事实上我认为这是这里最大的价值）。

这个共享排序器应该是一个基于以太坊的排序器吗？

技术（提议者承诺）

我认为使用基于以太坊的排序器没有强有力的技术依据。由于无法可靠地执行对 L1状态的 write-lock、较长的区块时间（12 秒），以及希望与 L1 交互的 BR 交易必须与其一起重组，因此 BR 和以太坊 L1 之间的任何互操作性都将受到极大限制。这里没有免费的午餐。与任何其他外部共享排序器相比，这不会解锁任何有价值的面向用户的产品。

我看到的主要价值是，将以太坊 L1 添加到这个更大的组合拍卖中可能会产生更高的总价值，并允许 L1 捕获更多价值。将这个逻辑推向极端，我们可能应该将世界上的所有东西都放在同一个拍卖中。这个通用拍卖也应该对泰勒斯威夫特演唱会门票进行排序。我还没到那一步。

这只是为了强调，创建并让每个人选择加入这一共享拍卖所带来的真正技术和社会复杂性是存在实际成本的，而在我看来，这种成本可能会超过此处任何理论上的额外价值创造。如果我们不试图将其堆叠在以太坊 L1 之上（例如，只需为此目的构建一个简单快速的共识机制），我们可以很容易地从头开始构建一个更好的技术设计。更不用说，这种组合拍卖将导致复杂性的指数级增长。

实际上，我认为这种基于先验体系架构的做法可能会对以太坊造成实质性的反生产力影响，因为当以太坊的供应链已经相对脆弱时，这种做法可能会加速 MEV 基础设施的形成。这可能会危及网络的去中心化和抗审查性——这正是使其具有价值的最根本特征。

社会（可信中立）

我确实认为基于以太坊的排序器有一个有效的社会论证。

如前所述，毫无疑问，「对齐」对于初始 BR 来说是一种卖点。这很好，但我认为这不会持续下去。成为第一个 BR 很酷，但成为第八个 BR 就不酷了。需要增加一些其他价值。

我认为基于以太坊的排序器的可信中立性可能是那个附加价值。至少，这可能是支持这种设计的最强有力的论点。有很多链希望获得一个去中心化的排序器即插即用。如果我们最终可以在其上设计足够的基础设施，以改善跨链用户体验，那就更好了。然而，在想要这样设计的项目中，我想许多项目都不愿意对任何第三方协议「站边」。正如前面提到的，想象一下，如果你是一个具有像 ENS 这样的基本通用基础设施的应用链，你想要一个 Rollup。你不会想选择 Arbitrum 共享排序器，因为这可能将 Optimism 社区排斥在外，反之亦然。

可能这里解决社会协作问题的唯一办法是拥有一个可信中立的共享排序器，以太坊显然是最强的候选者。请注意，这更加强调了我之前关于可信中立的观点——如果这是此类服务的主要增值部分，那么在创建它时，这必须是一个极高优先级的设计目标。如果它看起来像是某个第三方协议的宠物项目，有自己的盈利动机，那就行不通了。它实际上必须是以太坊共享排序器。

值得注意的是，也有合理的批评认为，这里的「中立」是「以太坊」的代号。也就是说，它的主要动机是使以太坊及其原生周边基础设施受益。当然，这样的系统会让这些各方受益。这意味着 ETH 资产的价值获取会更高，以太坊建设者、中继者和搜索者将获得更多的盈利能力。

Fast Based Rollups

Fast Base Layers

我们现在应该明白，你可以在像以太坊这样的缓慢的区块链上拥有区块链，你可以添加可信的 preconfs 以获得更快的用户体验，你甚至可以通过加密经济或加密保证确保跨链时的安全性。

但正如所指出的，如果我们只是从头开始设计这个东西会怎么样。不处理现有链的技术债务和决策。构建这个东西的方法是什么......

之前，我们讨论了对于给定的 BL（例如以太坊），成为具有 preconfs 的 BR 的唯一技术原因是，它的提议者有时可以就与 BL 的同步原子包容性提供可信的承诺。

然而，我们并没有认真讨论过在没有 preconfs 的情况下成为 BR 的能力。我们基本上放弃了这个，因为以太坊很慢，用户没有耐心。

那么为什么我们不对 BR 使用快速 BL 呢？

这解决了我们之前遇到的几乎所有复杂边缘情况和担忧。我们不希望网关出现活动性故障（其结果与此处的安全故障相同），我们不希望它们违背承诺的 preconfs （即安全故障），我们也不想要以太坊重组。这正是共识存在的原因。

DA 层已死，排序层万岁！

关于惰性排序器的大部分讨论都将其视为 rollup 排序器，然后将其数据转储到其他 DA 层。例如，Astria 的前两个 rollup 器（Forma 和 Flame）将使用 Celestia 作为其 DA 层。Astria 的共识将对这些 rollup 器进行排序，然后将数据转发给 Celestia。

这种组合特别好，因为它们显然是互补的——Astria 提供所有的排序基础设施，而 Celestia 通过数据可用性采样（DAS）提供信任最小化的验证。

但是，Astria 也可以用于对以太坊、比特币、Solana 或其他任何你想要的原生 rollup 进行排序。例如，它甚至可以设置为以太坊「具有 preconfs 的 BR」的 preconfs 器（例如，而不是中心化网关，因为惰性排序器基本上只是一个激励和分散的中继器）。

不过要明确的是，每条链都是一个 DA 层。全节点始终可以检查 DA。数据可用是任何链有效性条件的一部分，因此共识始终是签署数据可用。轻节点检查其签署后会得到诚实的多数假设。唯一的区别是，如果链为轻客户端提供了另一种选择，即直接采样 DA，而不是询问共识。

然而，正如我在《Rollups 是否继承了安全性？》中所指出的，像 Astria 这样的快速链在技术上可以为 DAS 添加一条慢速路径（以提高可验证性），而像 Celestia 这样的慢速链可以为排序添加一条快速路径（基于多数信任假设且没有 DAS），即所谓的「快块慢速方块」。

转向垂直整合诸如排序或 DAS 之类的专业层将进一步缩小模块化区块链与集成区块链之间的区别。这同样适用于通过将 ZK 验证者账户添加到 Celestia 的基础层来垂直整合结算层。

然而，将这些服务分开而不是捆绑在一起具有重大意义。这是一种模块化方法，允许 rollup 选择他们想要的现成功能（例如，我想购买具有快速块的去中心化排序，但我不想为 DAS 付费，反之亦然）。研究人员已经表明他们想要 DAS，但到目前为止，用户已经表明他们只想要快速块。

像「快块慢方块」那样捆绑服务会非常固执己见和集成。这必然会增加复杂性和成本。时隙长度对现在在以太坊上普遍存在的计时游戏（以及潜在的去中心化）的影响也是一个考虑因素。

快速 Base Layer vs. 慢速 + preconfs

但您也可以将 Astria 用作 rollup 的 BL。共享排序器可以被视为针对其自己的 BR 进行优化的 BL。

当您的 BL 速度很快时，您的 BR 就不需要 preconfs ，因为它可以直接获得快速确认！然后您的 rollup 实际上会获得 BL 的实时安全性，而 BR + preconfs 则必然会失去这一点。

事实上，没有 preconfs 的 BR 是构建 rollup 的最合理方式。这就是为什么今天的 rollup 都是从这里开始的：

很明显，具有快速区块的 BL 解决了我们在「基于 rollup + preconfs 」中的大多数问题。共享排序器自然是从第一原则方法构建的，「嘿，应用开发人员只想启动一条快速、可靠且分散的链 - 我如何将其提供给他们？」事后尝试将 preconfs 添加到以太坊等较慢的基础层会导致我们上面描述的复杂性。

我们都在建造同样的东西

模块化是不可避免的

因此，我们看到了如何将模块化链重新聚合在一起，提供通用同步可组合性 (USC)。当然，这其中存在着权衡，但它们确实重新引入了有意义的统一度，同时保留了比使用单个状态机更大的灵活性。对我来说，还有一个非常有说服力的案例，即异步可组合性是我们绝大多数用例所需要的。我们需要低延迟、性能和良好的用户体验。互联网是异步的，将所有这些都抽象出来效果非常好。可组合性是加密的巨大增值，但可组合性 ≠ 同步。

抛开灵活性和主权利益不谈，大多数人都会同意我们最终还是需要多条链来实现规模化。这意味着我们最终会拥有许多需要统一的系统，因此模块化方向在这里是不可避免的。

以太坊 + Preconfs → Solana？

现在，让我们比较一下这里的终局。具体来说，我们将比较 Solana 的终局与以太坊的终局，如果以太坊走上这条道路，即通过基于 rollup + preconfs 最大化统一性和用户体验。

在这个愿景中，大量 BR 使用基于以太坊的排序器。网关以低延迟持续向用户传输提议者承诺的（即没有任何共识权重） preconfs ，然后以太坊提议者每隔一段时间将它们提交到完整区块中。这听起来可能很熟悉，因为这几乎就是我们之前为 Solana 描述的碎片流！

那么，这只是一个更复杂的 Solana 吗？这里最大的区别在于时隙时间：

以太坊试图在缓慢的链上添加这一功能，乍一看显然存在问题：

以太坊的共识对于用户来说太慢了，因此获得可靠中立快速用户体验的唯一方法是选择加入提议者承诺的 preconfs 。目前，它的主要瓶颈是由于其巨大的验证器集而导致的签名聚合（MaxEB 和改进的签名聚合可以在这里提供帮助）。
这会导致提议者垄断时间更长，从而提供更高的激励和自由，通过不诚实的行为（例如，隐瞒预先确认）来获取更多的 MEV。
如果网关确实开始延迟或保留 preconfs ，那么对于用户来说，最坏的情况就是依赖以太坊时隙时间。即使 Solana 区块生产者停止在其分配的垄断范围内连续构建和传输区块（出于同样的原因，他们在某种程度上这样做可能是合理的），那么最坏的情况就是依赖快速轮换的共识。然而，今天的四时隙垄断对于网络可靠性是必要的。
实际上，至少在开始时，网关的数量可能会非常少，从而产生比 Solana 更集中的运营商集。
对于提议者的抵押要求可能会非常高（注意设计空间仍在进行中）。
对活跃度问题的担忧在这里会造成极大的损失（因为操作员活跃度问题导致的 preconfs 丢失相当于用户的安全故障，因此必须受到严厉的罚没）。

所有这些都可以通过快速共识来解决。所有这些系统实际上都是我们首先制作 BFT 系统的原因。那么为什么以太坊不应该让它的共识更快呢？拥有超低延迟 base layer 区块时间是否存在一些不太明显的权衡？

幸运的是，我写一篇关于《较短的区块时间是否更好》的文章。较短的区块时间最大的担忧与验证者和操作员的中心化有关。具体来说，人们对较短的区块时间与计时游戏的相互作用感到担忧：

我们看到以太坊上的时间游戏正在不断推进。提议者在自己的时隙中推迟提议区块，以牺牲他人利益为代价赚取更多钱财。中继器还提供「时间游戏即服务」，它们同样在时隙中推迟区块：

资料来源：Data Always

几周前，在颇为臭名昭著的 Justin vs. Toly Bankless 播客中，计时游戏（Timing games）是一个热门话题：

Justin 认为，计时游戏会成为问题，而增量奖励始终是有意义的。Toly 认为，计时游戏不会成为问题，从额外 MEV 提取中获得的增量奖励不足会引起担忧。

我个人认为很难忽视计时游戏的重要性：

如今，我们已经在以太坊上看到了它们的实践。Solana 的论点是，这种情况之所以发生，只是因为 MEV 早些时候在以太坊上被社会规范化了，但这并不能令人信服，因为早期公众对计时游戏的强烈抗议已经转变为接受这一新的现实并围绕这一现实进行设计。
MEV 奖励非常可观——我们这里谈论的 MEV 支付金额已经达到数十亿美元，而不是沙发垫下的几分钱。即使只多赚几个百分点，也是一笔巨款。
即使你不相信质押者对边际收益足够敏感，实际的运营者是正在经营企业，而这直接影响到他们的底线。
Solana 在其生命周期早期更容易依赖利他主义的大型利益相关者（例如基金会和大型投资者），但这是不可持续的，因为任何网络都会进一步去中心化。

我认为 Solana 和以太坊所采取的方向都具有巨大的价值。如果没有别的，我们将在实践中看到这一切。从战略上讲，我也认为以太坊倾向于让自己与众不同是有意义的。最大化去中心化，作为在对抗情况下实现抗审查的一种手段。以太坊做出了很多牺牲来保持一个高度去中心化的协议，因为这是长期博弈的必要条件。它拥有无与伦比的客户端多样性、网络所有权分布、生态系统利益相关者、运营商去中心化等等。如果（很可能是当）Solana 在未来面临严重的审查压力，那么以太坊做出这些决定的原因将变得越来越明显。

上周刚刚在 Zuberlin 进行了 Preconf.wtf，并不令人感到意外，每个人都在谈论 preconfs 和based rollups。这一切都非常酷。但我个人认为，Vitalik 关于《 one-bit-per-attester inclusion lists》演讲和 Barnabé 关于《Overload the Execution Proposer instead (From MEV-Boost to ePBS to APS)》对以太坊的未来最为重要。

来源：Barnabé Monnot，从 MEV-Boost 到 ePBS 再到 APS

关于 preconf 和基于 rollup 的讨论最近开始升温，而我肯定还是比较谨慎的。Vitalik 提出了以下著名的终局：

然而，我们已经深入到「中心化生产」中，却还没有实施更强大的反审查保护措施，比如纳入名单。基本上，以太坊的一半位于下图的最下面一行。（我说一半是因为审查制度实际上并不是黑白分明的，而以太坊只有「弱审查」，即大多数但不是所有区块都受到审查，所以你可能只需要等待一会儿，然后你就会被纳入其中）：

来源：治理证明

从经验上看，以太坊 L1 MEV 供应链目前实时审查的区块比任何具有中心化排序器的 L2 都要多。

L2 无需基础即可获得 L1 的最终 CR（这仍然非常好）。基于 preconfs 的协议无法获得以太坊协议的实时安全性，它们只能获得其周围少数相对集中的基础设施提供商的实时安全性。为了获得更好的实时 CR，最好的选择可能是将排序外包给某种运行简单 BFT 共识的去中心化排序器。这将比将许多链集中到当前相对集中的瓶颈中更加强大。这种情况可能会随着执行拍卖和纳入清单等变化而改善，但这并不指日可待。

考虑到所有这些因素，我不清楚在现阶段，扩大对以太坊 L1 MEV 基础设施的依赖，然后将其巩固为 L2 是否是一个好主意，因为只有少数人构建和中继所有以太坊区块，当今以太坊的大多数无审查区块都依赖于单个构建者（Titan），并且协议中尚未实现任何 CR 工具。这感觉像是在脆弱的地方积极加速。以太坊当然应该努力改善 L2 的用户体验，但不能以牺牲我们最初想要的所有底层属性为代价。