共享排序器

想象一个世界，在这个世界中，rollups 可以轻松实现高水平的审查抗性、易于部署、互操作性、快速 确认、活跃性和 MEV 民主化。虽然这个目标看起来遥不可及，但随着共享排序器的出现，这样的世界可能触手可及。然而，并非所有 rollups 都是平等的，这引出了有关在共享排序器网络上，如何分配奖励和 MEV 的问题。本文将探讨使共享排序器网络实现的特性及可以实现的属性。

共享排序器网络主要由 Alex Beckett 进行报道，后由 Celestia 的 Evan Forbes 和 Espresso Systems 团队（以及 Radius）进行了更深入的探讨，同时还有 Jon Charbonneau 的新出色 作品。Josh、Jordan 及其在 Astria 的团队正在构建第一个投入生产的共享排序器网络。Astria 的共享排序器网络是一个模块化区块链，用于聚合和排序 transactions，而不执行这些 transactions。

在 Astria 的设置中，排序器将已排序的区块发送到 DA 层，也发送到 rollup 节点。Rollups 从排序器那里获得软确认保证，而从 DA 层获得硬确认保证（在区块确认后），之后他们将执行对他们有效的交易。

共享排序器网络本质上是一个与 rollup 无关的排序器集合，正如名字所暗示的，可以为不同的 rollups 服务。这有各种权衡和属性，我们稍后将详细讨论。首先，我们必须描述排序器（或排序器集合）应该维持的最重要属性。在一个 rollup 中，排序器或排序器集合的主要要求是审查抗性或活跃性（其中一部分来自基础层，以及安全性）。这意味着提交给排序器的有效交易必须在有限的时间内包含在链中（超时参数）。共享排序器集合只需确保交易包含在区块中（即 crLists）。

要实现审查抗性和活跃性都是相当困难的，如我们在 Modular MEV 第二部分中所述。在 Tendermint 等共识算法中，可以确保在攻击后恢复。然而，一旦发生攻击，活跃性则会丧失。基本上，要求所有其他排序器对区块进行签名，而不是选择一个定制的领导者，可能不是最佳选择。虽然这增加了审查抵抗性，但以“中心化”的代价和将 MEV 提取至单一领导者的代价而来。可以使用的另一种排序机制，是类似 Duality 的 Multiplicity。他们的设备可以让非领导节点（或排序器）将额外的交易包括在一个区块中。总体而言，在大多数共识协议中，实现攻击后的审查抗性和活跃性是很困难的。

另一种可能使用的共识算法，可能是类似于 HotStuff 2，它在攻击期间确保活跃性。

它允许避免等待最大网络延迟（超时）而选择新的领导者，以防审查或不签名。它可能是一个有趣的去中心化排序器集合的共识算法，因为它在不增加额外阶段的情况下解决了共识中的活跃性问题。如果领导者知道最高锁定（同意特定输出的最高表决者数量）并能够说服诚实的参与者，那么问题就解决了。如果没有，诚实的领导者在特定时刻后可以迅速推动进展，帮助下一个领导者。例如，Hotstuff 节点无需在通知新领导者之前确认切换消息，相反可以直接切换到新视图并通知新领导者。

与 Tendermint 的不同之处在于，尽管它们都是两个阶段（Hotstuff I 有三个，II 有两个），Tendermint 有线性通信，但不是响应性的，而 Hotshot2 是响应性的。如果存在一系列诚实的领导者，该协议是乐观响应的，因为所有步骤（除了第一个领导者的提案）都依赖于获得前一步的消息法定数。在共享排序器环境中，这使该协议可以在不退回到底层的情况下实现更好的活跃性，同时又保持这样做的可能性。

共享排序器集的构建模块

一组排序器被允许将交易提交到结算层（rollups 所在的层）。只要满足特定要求，并且所需提案者的数量未满，你就可以加入该集。此举可用于优化延迟、吞吐量等，例如 Tendermint 保持相对较低。这些要求将类似于如何成为特定区块链的验证者。例如，你必须满足特定的硬件要求，以及启动抵押金或担保——如果你想提供经济上的软确认，这一点尤为重要。

共享排序器集（或任何去中心化排序器集）由多个组件组成，这些组件共同确保交易被处理。这些组件包括：

1. 为每个 rollup 提供 JSON-RPC 的交易提交（对于非完整节点运行者）到作为 mempool 的节点，这些节点在构建和排序之前功能。mempool 中需要某种机制来决定队列，以及确保有效区块构建的交易选择过程。

2. 一个区块/批处理构建算法，用于处理队列中的交易并将它们转化为一个区块或批次。这一步骤可能还包括可选压缩，以减小生成的区块大小（calldata 压缩）。如前所述，这应该与提案者分开——本质上是 PBS。压缩数据可以以多种形式出现，例如：

   1. 没有 RLP 编码——然而，这对去中心化的排序器集可能是必要的，以帮助标准化在空间高效格式中节点间的数据传输。https://learnblockchain.cn/article/12600

   2. 省略 nonce（验证特定区块中数据的唯一编号）——在执行时，可以根据先前的链状态重新计算。

   3. Gas价格简化——根据固定的价格范围设置 gas。

   4. Gas简化——不仅仅是Gas价格，还有Gas编号系统。

   5. 用索引取代地址——rollups 可以存储映射地址索引，而不是存储完整地址，这些地址存储在其他地方。

   6. 以科学记数法表示值——以 wei 为单位的以太坊交易中的值字段是一个大数字。你不能省略值字段或将其减少到固定值集。然而，你可以选择以科学记数法书写，而不是 wei 以节省数据。

   

   1. 省略数据字段——对于简单转账不需要，但在更复杂的交易中是必要的。

   2. 用 BLS 聚合签名替换单个签名——签名是以太坊交易中最大的组成部分。你可以存储一个针对特定数量交易的 BLS 聚合签名，而不是存储每个签名。可以检查 BLS 聚合签名，以确保它与整个消息和发送者的集合一致。

   3. 作为索引的 from 字段——如同 To 字段，你可以将 from 字段添加为映射的索引。

   4. 一个有趣的设计理念是“模块化”，你可以在此基础上进行调整和权衡，以适应你特定的 rollup 案例。

3. 一个点对点（p2p）层，允许排序器接收来自其他排序器的交易，并在构建后传播区块。此步骤对于确保共享排序器能够有效跨多个 rollups 工作至关重要。

4. 共享排序器集的领导者轮换算法（在单一领导者选举的情况下无需达成共识）。你可以选择仅实施领导者轮换算法。另一个方向是走 多并发区块生产者 的路线，这正是 Duality 提出的。

5. 共识算法，例如前面讨论的 Tendermint 或 Hotstuff2，以确保 rollup 节点与 proposed 账本的排序一致。

6. 向底层 DA+共识层提交区块/批次的 RPC 客户端，确保区块/批次安全地添加到 DA 层，确保“最终”确认，并且所有交易数据在链上可用。

7. 区块构建者和提案者角色分离，以确保公平性和一致性，并避免 MEV 被窃取。同时将执行与排序分开，这是优化效率、降低 PGA 和提高 CR 重要的一点。

Rollup 节点从排序器接收已排序的区块以进行软提交，并从 DA 层块接收已排序的区块以进行硬提交。

交易数据（calldata）首先发布到基础网络，在那里进行共识，以保证用户和 rollups 的交易。然后，rollup 节点执行交易（并提交到添加到典型 rollup 链的状态转换函数）。共享排序器网络为 rollups 提供了其活跃性和审查抗性。Rollups 维持其主权，因为所有交易数据存储在基础层上，允许它们随时远离共享排序器进行分叉。来自 rollup 端的状态转换函数（STF）的状态根是从发自共享排序器的交易根（inputs）计算得出。在 Celestia 上，随着数据添加到链上并达成共识，这被生成。因为你已经拥有 tx 根（和所有可用数据），Celestia 可以为轻客户端提供小的包含证明（rollup 节点在 Celestia 上运行）。

为了为用户提供他们所期望的用户体验，rollup 节点接收已排序的区块（也发送到 DA 层）。这可以为 rollup 提供软确认保证——即一个承诺，即区块最终会如预期在 DA 层上排序，此时 rollup 节点会执行交易并提供新的状态根。

区块创建与时隙

要确定区块创建的时机，排序器需要建立一个时隙概念。排序器应在固定时间间隔内提交批次，通常每 X 秒，其中 X 是时隙时间。这确保交易可及时高效地处理，否则特定时隙的领导者将超时，并失去其签名奖励（和执行奖励）。例如，Celestia 的区块时间（根据 GitHub 规范）大约为 15 秒。由于这是已知的，我们可以假设我们可以将多少个“时隙/区块”从共享序列集向 DA 层和 rollup 节点的最终区块适配。考虑优化的 Tendermint，或类似 Hotstuff2 的设计。

在一个时隙内可以提交多个批次，前提是设计允许 rollup 完整节点有效地将它们处理成一个区块（在时隙的时间和超时参数内）。这可以进一步优化区块创建，并确保交易迅速处理。此外，时隙还可用于促进排序器领导者选举。例如，你可以从抵押池中随机选取一个时隙领导者，基于抵押权重。以保密的方式实现这一点是最有意义的，利用类似于秘密领导者选举 的方式可能是最理想的，以减少审查。甚至可以采用分布式验证者技术（DVT）类型的设置（如 Obol/SSV 风格的解决方案）。延迟和时隙时间对区块提交和构建如何影响协议有重大影响。因此，合理检视这如何影响系统。Bloxroute 尤其对其在以太坊上如何表现进行了极好的研究和数据点。在 MEV-Boost 中，参与提案者（验证者，或在 rollup 情况下，排序器）向中继请求 GetHeader。这为他们提供了区块竞标，即特定区块的值。这通常是每次接收到的最高值区块。对于每个时隙，验证者通常会在时隙开始后约 400 毫秒请求 GetHeader——由于显然存在大量验证者，增援通常必须处理无数请求。这在一个大型共享排序器集中也是如此。这意味着你需要适当的基础设施来支持这一点。

中继还在促进构建者和提案者分离的同时，验证构建者构建的区块是否正确。他们还会检查费用是否支付正确，并充当 DoS 保护。此外，他们本质上还充当区块的托管者，并处理验证者注册。这在一个无限的排序器世界中尤为重要，你需要对参与者进行适当的核算，谁在参与，谁不参与（例如，前面讨论的同步层）。

关于区块何时准备好（即由构建者提交），它们通常是提前或者在插槽开始后大约 200 毫秒提交的。然而，与 GetHeader 一样，存在相当大的波动，但主要在插槽开始前/后 200 毫秒提交。如果构建者发送到多个中继，实际存在相当大的延迟。Bloxroute 还研究了将区块发送到多个中继时发生的情况。正如你所预期的那样，区块传播到的中继越多，延迟就越大。平均而言，第二个中继将需要 99 毫秒才能使区块可用，第三个需要 122 毫秒，第四个需要 342 毫秒。来源：

近几个月来，RPC 对区块链而言是极其重要的。没有适当的基础设施，负担是巨大的，而拥有适当的 RPC 选择也至关重要。在这方面，RPC 的包含对将交易发送到 RPC（以及公共 mempool）的零售用户至关重要。Bloxroute 对 20 笔交易进行的小测试，这些交易被发送到不同的 RPC，然后测量每笔交易被包含在区块中的时间。

来源: Bloxroute Labs

有趣的是，有些 RPC 需要几个区块才能包含交易，因为这取决于哪个构建者赢得了相应的下一个区块。从 RPC 发送给构建者的交易越多，快速纳入的可能性就越高。尽管交易发起者可能利用他们独特位置的订单流来针对特定构建者，甚至构建自己的区块。

在中继性能的统计方面，观察它们在以太坊的性能表现也很有趣。这帮助我们更深入地理解 PBS 在多验证者/构建者/中继世界中的工作方式，Hopefully we’re heading to a place in relation to rollups in general. Metrika 有关于此的一些极好的统计数据，因这些数据值得致以感激而保存。

在这里需要注意的是，错过的竞标只是中继被期望中继的竞标，但没有发生。竞标期望来自注册到特定中继的验证者，适用于任何给定时隙。这对于中继本身来说并不是一个故障，也不会在协议层面上受到这样的对待。

来源: app.metrika.co

如果发生竞标故障（例如中继提供无效区块），而它是有责任的，那么它将被视为竞标故障。这些事实上不是很频繁，而且在大多数情况下是注册偏好故障（当Gas限制或费用没有符合特定验证者的注册偏好）。共识层故障相对较少，这种故障发生在竞标不符合以太坊的共识层规则时，例如时间戳错误或父哈希未与之前的区块对齐等等。

在延迟方面（例如，验证者接收来自构建者构建的区块头响应所需的时间），数据相当一致。尽管存在一些异常值，例如请求的中继与所选验证者位于不同地理位置时。

来源: app.metrika.co

在 builders 的统计上，在 MEV-boost 的总构建者数量约为 84，其中前 3 名构建者占大约 65%~ 的构建区块。这个数据有些误导，因为这些也是运行时间最长的构建者。然而，它确实显示出构建角色仍然有些集中，因为如果你缩小时间范围，我们会得到类似的结果。在过去 30 天中，实际上活跃的构建者数量要少得多，只有 35 个，而在过去一周中只有 24 个。竞争激烈，最大和最强的通常会胜出。这一现象显然增加了独占的订单流。我们预期构建者的分布将在模块化堆栈中保持相对集中（因为这是在拥有最佳订单流和硬件优化这一游戏的结果），仅限于少数参与方，除非设置发生重大变化。虽然这不是根本性问题，但这种状况在堆栈中持续存在了一种中心化的力量，我们希望了解挑战现状的想法。如果你对这个（严重的）主题感兴趣，我们高度推荐阅读 Quintus 的关于 订单流、拍卖和中心化 的文章。

关于我们期望构建者角色在模块化堆栈中前进的方向，我们相当确定（至少在 Cosmos SDK 设置中）会看到通过 Builder Modules 的 Skip/Mekatek 类型设置。另一个解决方案是 SUAVE 类型设置——例如，一个特定的 全球 构建者链，它为任意数量的链提供区块构建和竞标偏好服务，以确保 PBS。我们将稍后对此解决方案进行更深入的报告，并提出些尚未解决问题的部分答案。

关于中继，我们强烈推荐由 Ankit Chiplunkar 和 Mike Neuder 撰写的 Frontier Research 文章，标题为 乐观中继及寻找乐观中继的信息。这篇文章详细讲述了 MEV-boost 中继的工作方式，以及当前的权衡与运营成本，探讨可能在提升效率方面进行的改变。有趣的是，根据 Flashbot 的估算，目前在 MEV-Boost 中运行中继的成本大约为每年 ~$100k。

最终性

作为我们看待模块化区块链的最终性的一种前提回顾，这里是段落的搭建我们之前的 Modular MEV 作品中，值得注意的是，这不是一个“官方”的或全面的最终性视图，但我们认为它最准确地代表了易懂的理解的 rollup 最终性。

Pending_On_L2: Rollup 的排序器所做出的对用户交易的软提交承诺，这些交易最终会在基础层确认和确定。

Finality_On_L2: 排序器已提交 rollup 的状态转移函数，且区块已添加到 rollup 的典型链中

Pending_On_L1: 交易输入或输出/状态转移函数已提交到 L1，但有效性证明尚未提交，或争议期尚未结束——这也要求 Ethereum 的两个连续效期过去。大多数乐观性的 rollups 认为在这一时刻最终性已达到，即便根据典型桥，仍在这一时刻存在一个任意的 7 天挑战期。

Finality_On_L1: 当乐观性 rollups 结束争议期，或有效性证明已提交并通过，亦经由超大多数在两个连续效期中确认。

现在在主权共享排序 rollups 中，这看起来稍有不同，试图用一幅图表来说明：

在这种情况下，我们在理论上在 L1 上获得最终性，等等？是的，L2 毕竟是主权的。这是假设没有欺诈证明和挑战期，或者你正在使用有效性证明。

那么我们如何实际实现这些最终性级别？区块最终性的实现是在一个区块添加到规范链上，且无法被撤回。然而，这里有一些细微差别，取决于完整或轻节点的视角。在有序区块的情况下，一旦被包括在 DA 层块中，它就是最终的。由 rollup 完整节点/验证者执行的执行区块（带状态根）由这些被有序区块的基础层所赋予的有效状态根。如果超出完整节点（例如，面向轻客户端或桥接）的最终性，要使人们信服状态根的有效性，你可以利用以下方法之一。此外，另一种方法是使验证者对状态根的正确证明负责（乐观路径），通过担保和随后的欺诈证明。你也可以提供有效性（ZK）证明。

实现区块最终性的方式有多种：

1. 通过工作量证明（PoW）、LMD+Ghost、Goldfish、Ouroboros（PoS）等概率实现。

2. 通过足够委员成员的签名来实际证明（例如，Tendermint 的 2/3、Hotshot2 或其他 PBFT 类型）

3. 依靠 DA 层上交易/区块的排序，以决定什么是规范链，什么是分叉选择规则（例如，Based）。

通过不同机制获得的不同类型的最终性。例如，“软最终性”（例如，待处理）通过单一领导者选举实现的类型。如果实施时每个插槽只有一个或零区块（提交或不提交），同步层可以安全地假设这些区块中交易的顺序。

Proven最终性提供比软最终性更强的保证（本质上是最终的）。要实现可证明的最终性，必须由大多数排序器对一个区块进行签名，从而一致认为该块是规范的。虽然这一方法很好，但如果已经实施了单一领导者选举，这可能并不是必须的，因为它基本上保证了区块的顺序。显然，这取决于有效的领导者选举算法。例如，它是 51% 的实施、66%还是单一领导者（最好是随机的（VRF）和秘密的）。如果你想深入了解以太坊中特定的最终性，我们强烈推荐这篇文章 这篇，同时我们稍后对无限集合的有效性问题也会进行推荐和讨论。

许可、半许可或无许可

为防止潜在的 DoS 攻击，必须设定经济障碍才能加入排序器集并向排序器层提交交易。在绑定（有限数量的排序器）和无限（无限制）集合中，都必须设置经济障碍才能将批次提交到 DA 层，以防同步层（在排序器之间传递区块）被减速或遭到 DDoS 攻击。然而，DA 层本身提供了一定的保护，因为提交数据到其所需的费用相当（da_fee）。加入无限集合所需的担保应涵盖保护免受同步层被垃圾邮件攻击所必需的额外费用。另一方面，加入绑定集合所需的担保将取决于需求（从成本/收益角度的平衡）。

在无限的排序器集上，无法实现在排序器层的可证明最终性（因为我们无法确知有多少个活跃投票者/签名者）。另一方面，在绑定排序器集上，可以通过超大多数排序器对一个区块的签署实现可证明的最终性。这确实要求同步层知道排序器层及其在任何给定时刻的活动排序器，这也带来了额外的负担。在绑定排序器集（例如，最大 100）中，你也有能力优化 “性能” 的排序器数量，尽管以牺牲去中心化和审查抗性为代价。绑定集的重要性以及经济担保在于提供“快速”的可证明最终性，这也是确定性的。

我们在传统区块链中也能看到无界和有界排序器类型，例如以太坊中的 PoS（Casper + LMD-GHOST）是无界的；而 Cosmos SDK/Tendermint 基于链的 PoS，则利用绑定集合。有趣的是，我们是否期望来自社区的类似经济学和选项 围绕共享排序器的内容流行；正如我们在权益证明中所看到的？在这种情况下，我们看到向一些实体的中心化（因此无界实际上并不重要，如果你在拥有几个大型 staking 提供者/池）。不过，它们确实“掩盖”了这种中心化，毕竟，你仍可以进行家庭质押，如果需要的话。从意识形态的角度来看，选择几乎应该总是无界的——但要记住，经济学使它们很相似。无论参与者是谁，你所支付的经济学费用应该始终是相同的，即，DA 和硬件费用（尽管这可能会根据分配给你的质押的数量和经验，以及有效运行基础设施的能力而降低）。即使在有界 PoS 的世界中，我们已经看到一组基础设施提供者成为几乎所有链中最大和最常见的验证者。大多数 Cosmos 链中的验证者之间的关联性非常高，这无疑是对所述链的去中心化和审查抗性的一种威胁不同的是，任何零售用户都可以将任意数量的质押给他们选择的验证者。不幸的是，这通常位于列表的顶部，并继续该途径。但我们再次问：我们是否期望模块化世界中会发生类似的经济活动？希望不会，但随着我们的专业化，你通常希望找到最适合的人选——这通常是专业的质押提供者。我们也将在稍后的单独章节中讨论这些经济学。

然而，在所有这些中，总要记住的重要一点是，最终用户的验证最为重要——这在轻客户端和 DAS 中对任何人、任何地方（即使在吉萨金字塔）都是可用的；

来源: @JosephALChami

关于无界和有界在排序器方面的权衡与利弊，可以总结为：

无界排序器集：

• 任何拥有足够担保/质押的人都可以成为排序器 = 高水平的去中心化。

• 由于该集可能是无限的，无法实现单一领导者选举。

• 通过 VRF 非单一领导者选举是可能的，但很难在不确切知道会有多少排序器的情况下设置 VRF 参数。这也应该尽可能是秘密领导者选举的实现，以避免 DoS 攻击。

• 如果没有领导者选举 = 浪费资源问题：区块构建实际上是一个自由的竞争，成功提交第一个有效的区块/批次的所有其他人都会失败。

• 在排序器层上没有可证明的最终性，只有在概率玩法中——例如，LMD Ghost + Casper。

• 最终性只能在批次写入 DA 层之后达到（受到基础层区块时间的限制，Celestia 的情况是 15 秒以内）。

• “更好的”审查抗性超出边界集合。

有界排序器集：

例如，这是以太坊中的单插槽最终性解决方案之一，还有超级“多数”委员会。请参阅 此处 。

• 允许的排序器数量在某一特定时间有限。

• 与无界集合相比，有界集合可能更复杂。

• 可以实现单一领导者选举，从而在排序器层上提供强有力的最终性保证。

• 同步层需要了解排序器集，以判断哪些区块是有效的。

• 将排序器集（或设置的变化）写入结算层的区块（例如，选叉规则），并写入 DA 层，可以让同步层独立地确定排序器集。例如，这就是 Sovereign Labs 的 rollups 的功能，集合变化被写入发布到 DA 层的有效性证明。

• 如果 DA 层的速度足够高，则可能不需要排序器层上强大的最终性保证（但是，当前没有优化的结算层配置的最少区块时间通常大于 10 秒）。

关于如何监控这些排序器集以及如何添加或删除新参与者的问题，还存在相当大的设计空间，以实现这一步。例如，是否会通过代币持有者治理来实现（以及如何考虑使用集合的多种不同代币和 rollups）？这意味着可能会通过“社会共识”方式进行离线信号，以指示区块链上的变化（即以太坊的方式）。然而，请记住，共识中的相关损失也显然是关于共识规则的劈分。

共享排序器的经济学

共享排序器网络的经济学提供了一些有趣的选择。我们之前讨论过，共享排序器网络中的验证者与你的典型 L1 验证者并没有太大不同。它参与的网络只是更优化以执行一项任务，即接收意图（pre-PBS），因此提案和排序交易。就像一个“常规”验证者一样，它有收入和成本组件。在方程式的两侧，验证者参与的网络具有很大的灵活性，类似于常规的 L1。

收入来源于用户，或它们最终目标交互的 rollups，为使用共享排序器支付一定费用。该费用可能是提取的 MEV 的百分比（输入数字可能难以进行近似），跨链传输的价值、类似于 gas 的构造或每次交互的固定费用。最优雅的收入解决方案可能是设置共享排序器的支付金额低于通过跨 rollup 共享排序器获取的额外价值，以获得共享安全性和流动性的利益。但不利之处在于，度量共享堆栈中某一部分去中心化的真实利益非常困难。然而，随着共享排序器网络逐渐成长为自己的生态系统，其提取费用的能力将可能增加。这主要是因为它们固有地易于聚合，具有一定的规模经济效应。随着越来越多的 rollups 和随之而来的应用加入网络，跨领域可提取的 MEV 也会增多。在成本方面，共享排序器网络也有竞争的选择。他们可以轻松通过承担向 DA 层发布数据的费用来补贴网络的使用，甚至通过与自身的 rollup 应用程序进行交互来补贴这部分费用。这与 Web2.0 公司使用的策略类似，即在用户（或 rollup）获取上承担初始损失，希望他们长期的收入能超出这些费用。另一种更为新颖，或者说更加去中心化的方式是允许 rollups 用它们的原生代币支付 DA 费用。在这种情况下，共享排序器层承担着在发布数据至 DA 层所需的代币与 rollup 的原生代币之间的定价风险。实质上，这仍然是共享排序器承担成本；然而，它通过获得“供应者”（rollup）的代币而创造了生态系统的对齐。这在某种程度上类似于我们在 Appchain 论文 中提出的仓储构造。还有其他可能降低成本的部分是通过利用不同形式的 DA。不同的 DA 层因使用情况的不同，会提供不同的定价，用户可以通过轻客户端轻松验证或直接做出不同的区块大小选择来实现。最后，共享排序器在发布到 DA 层之前也可以对交易进行批处理。在 ZKR 的案例中，这可以因某种交易平衡而降低交易成本；在 ORU 方面，你可以进行我们目前在各个 rollups 上看到的各种批量交易费用优化。这将减少需要发布到 DA 层的数据量，从而降低共享排序器网络的成本，提高整个网络的盈利能力。这确实是以限制互操作性和改变最终性时间为代价（在之前讨论的 L1 最终性意义上）。

总体来看，共享排序器网络的经济学使得一些有趣的实验和启动策略成为可能。我们估计，关键的差异化点在于生态系统的规模，因此跨域 MEV 的数量，而不太关注成本方面的问题。我们还强烈建议查看 Espresso 团队非常深入的 关于共享序列的博客文章，他们在文章中也讨论了这些类型网络的一些经济学权衡（和积极面）。为了展示为什么 rollups 有动力利用共享序列（超出其经济学），可以考虑聚合。

聚合理论与共享排序器

描述共享排序器所能实现的特性的一种方式是通过聚合理论的视角。聚合理论（AT）是一个平台或聚合者如何通过系统化集成其他平台及其用户而获得显著用户吸引力的概念。你会本质上将游戏从稀缺资源（例如：区块空间）的分配改变为控制丰裕资源的需求（在这种情况下，区块空间非常合理）。AT 本质上是将供应者和产品（即 rollups 和区块空间）聚合成一个为聚合用户基础提供的优越用户体验。随着这些聚合器的网络效应的增长，这种关系变得越来越独占——没有理由偏离。随着这种变化，用户体验成为类似设置之间的重要差异化因素。如果新的用户有强烈的激励（例如：良好的用户体验和轻松的互操作性），那么 rollup 转向自身网络或不同网络的可能性就不大——因为网络效应推动了新的供应商和新用户的涌入。这造成了一种自我强化的循环效应，从供应商和用户的角度来看，同时也从聚合的抗审查视角出发。

来源: Aggregation Theory 2015, Ben Thompson

在共享排序器的情况下，通过几乎“组合”和联盟使用相似堆栈垂直部分的 rollups，可以看到 AT——加强自己和他人，同时使用户在任何地方都能拥有相同的体验。

供应者（例如：rollups）在理论上并不在共享排序器集合中排他，但在现实中；共享排序器集合中，rollups 和用户受益于网络效应的循环，提高了上述 rollups 的使用。这些好处使得 rollups 和用户更容易与共享堆栈集成，因为他们如果不参与，会损失更多。当仅有两个 rollup 共享排序器集合时，这些好处可能难以察觉，但随着 rollup 和用户数量的增加，这一点变得非常明显。共享排序器集合与用户之间的关系是直接的，因为它们为交易排序，即使用户自己根本不知道他们正在与这些排序器互动——因为从他们的角度看，他们只是在使用一个有理由与之互动的 rollup（这意味着排序/排序器变得独特）。与这些排序器相关的唯一成本基本上是它们运行所需的硬件成本，只要区块空间和保证其价值的代币对最终用户是有价值的。交易费用是数字的，并从用户的钱包中支付，未来甚至可能通过账户抽象中的付费者等先进技术来抽象化（但是，还是会有某人承担 DA、序列和执行的成本）。

考虑到 Josh 和 Jordan 的工作背景，之前在 Google 工作。Google 的产品自成立以来就受到 AT 思想的深刻启发，这种影响在 Google 搜索中尤为明显，Google Search 是通过模块化（哈哈）单个页面和文章构建，使其能够通过全球搜索窗口直接访问。

在共享排序器集合中，客户（rollup 的用户）拥有越来越低的获取成本，因为当供应商（rollups）的数量增加时，他们可能会被吸引到此集合。这意味着，在大多数情况下，聚合器（或多聚合器）具有赢家通吃的效应，因为随着供应商的增加（当然仅在用户体验良好的情况下），这个聚合器的价值也随之增加。相反，在单一序列网络中，客户获取则仅限于单一网络及其应用程序。如果用户想要在不同的 rollup 上使用 rollup 应用程序，他们不得不完全脱离该网络（考虑到当前的限制）。这意味着用户的粘性和价值不是很高，并且还意味着在任何时候，如果不同的 rollup 生态系统变得受到高度重视（或拥有更多激励），资金可能会迅速流出。

属性与权衡的总结

属性

共享排序器集是一个卷曲网络，为多个 rollup 聚合和排序交易。这些 rollup 都共享相同的排序器。资源的池化意味着 rollup 获得更强的经济安全和抗审查能力，这使得快速软最终性保证和条件跨 rollup 交易成为可能。

现在，对于共享排序器之间原子性的讨论在 Twitter 上引起了相当多的噪音。这主要围绕它是否默认是原子的展开——答案是否定的。但是，如果这些 rollups 实现了彼此的状态转移函数（STF），作为与条件交易相关的依赖关系——它们确实可以在它们之间实现原子性——前提是它们的插槽/区块时间对齐（这应该在共享排序器集的情况下时常有效）。在这种情形下，得到原子互操作性，你实际上只需在链 A 上运行一个轻节点，而在链 B 上也是如此（类似于 IBC 的工作方式）。为了进一步增强这方面的互操作性（超出仅信任单个全节点作为轻节点），你可以实现 ZKP（状态证明本质上）来解决确保状态确实正确的“预言机问题”。这将更清晰地表明条件交易或类似的事务是否已经通过它们之间的标准桥接。欺诈证明也是一个可能的选项，但显然会让我们面临一个挑战期（这意味着第三方会出现，收取费用来承担风险）。此外，在轻客户端（而不是相互之间的全节点情况下），由于等待已签名的头部 + 欺诈证明窗口（如有），它将至少滞后一个区块。

我们相信“桥接”最有可能与轻客户端和 ZK 结合解决。这方面的挑战（而非智能合约）是，rollup 节点方面的硬分叉（升级等）需要彼此共同进行，以保持它们的桥接运作（就像 IBC 需要同样的状态模块启用）。如果你想更多地了解这个特定话题（以及如何解决它）——我们强烈推荐这份 演示文稿。

使得共享排序器具有超强可扩展性的原因在于，它们并不执行和存储任何状态（就像当前的中心化排序器那样）。针对 rollup 节点本身也是如此（它们无需扩展到数百个节点，除非他们希望保证它们之间的原子性——例如：轻客户端/状态证明）。这些节点只是执行对它们的 rollup 有效的交易，以及任何对它们也有效的条件跨域交易。如果 rollup 节点必须为多个 rollup 执行和存储状态，便会限制可扩展性并降低去中心化（进而降低抗审查能力）。它还强化了提议者-构建者分离（PBS）的概念。虽然我们仍需完全分离构建者与提议者。在当前的设定中，排序器基本上是构建者和提议者（尽管它们不执行交易）。理想的设定可能是排序器仅存在于对来自高度优化构建者设置形成的有效块盲目签字，并确保区块正确实施（同时为这种证明提供高程度的经济最终性和抗审查能力）。通过这样，排序器可以向rollup节点提供高程度的安全性和承诺，以保证soft finality。

对于跨 rollup 的条件交易，它们还存在于帮助 rollup 节点（执行者）提供中间状态根，从而实现 rollup 之间的原子性。如果你想深入了解这可能是什么样的，可以参考这份 简短演示。

权衡

如前所述的超时参数在 MEV 和交易纳入的方面具有一些有趣的影响，这取决于排序器集合的排序和领导者/共识机制。例如，如果超时参数，如我们的 应用特定链论文 中描述的，比较短，那么在去中心化排序器层面，提议者需要尽快发布数据。在这样的一个世界中，你可能会看到来自去中心化排序器集合的“验证者”竞争成为领导者，互相提高出价填满 DA 层的区块空间，直到达到经济上不再可取的点。

正如 Evan 在 Celestia 论坛的原始懒惰排序器帖子 中强调的那样，等待交易在发布到基础层（在这种情况下是 Celestia）后再执行是相当浪费的。由于你现在限于基础层的区块时间——从用户体验的角度，看这是一段很长的等待最终性的时间。为了获得更好的用户体验，共享排序器为 rollups 提供了一种软最终性承诺（如前文讨论），这给我们带来了用户在现有中心化 rollups 中所习惯的用户体验（同时保持去中心化和高抗审查能力）。软承诺本质上只是对交易最终顺序的承诺，但其由一项重大的经济担保和来自基本层的快速最终性支持。实际的硬最终性发生在所有交易数据已经发布到基础层（意味着 L1 实际上达成更快最终性时）。这取决于这些 rollups 是否使用欺诈证明，还是对于它们的主权证明验证采用零知识证明——这在 rollup 侧发生。之所以需要这种分离，是为了将状态转换的巨大计算需求从排序器身上移走（这是一种巨大瓶颈）。相反，rollup 节点仅处理对它们有效的那些（这确实意味着我们必须为妥善互操作性添加条件交易、状态证明或轻节点验证）。硬最终性仍然依赖于基础层（但这在 Celestia 之上可能在 15 秒左右，而且具有确定性与 Tendermint ）。这能为 rollup 侧提供高度相对快速的硬最终性保证。

在网络中，还可以利用 ZK 证明来优化验证和交易大小（例如：只发布状态差异——这增加了在提交 ZKP 前更高的信任程度）。这些状态证明，可以如前所述，用于简化连接链/rillups 之间的互操作性（无需等待挑战窗口）。

早前讨论过的这些条件交易的一个缺点是，它们在验证和发布方面的成本可能相对较高（例如：Tendermint 区块头验证成本高，并且在 Cosmos 链上是会受到补贴的）——而且可能会增加系统的延迟（不过仍然比孤立的 rollups 更快）。由于垂直共享整合所带来的原子性确实弥补了很多这一点。

在新的 rollup 启动阶段，选择共享排序器集是非常合理的——而作为供应商所获得的好处可能在很大程度上超过你可能在堡垒层面被“迫使”做出的权衡。然而，对于已经成熟的拥有大量交易和经济活动的 rollups，放弃部分堡垒可能没有多大意义。

这就引出了一个问题：我们是否需要类似基于经济/交易（每个 rollup）权重重分配提取的 MEV 以吸引已经成熟的 rollups 加入共享集合——甚至保持极其成熟的 rollups，以避免他们单独创建网络。这一切都是相当理论上的，但它确实提供了一个有趣的思考框架，讨论在许多具有不同活动水平的 rollup 共同作战的共享垂直世界中， MEV 的未来会是什么样。比如说，如果一个单一的 rollup 通过排序器集合驱动了很大部分价值，而它和其他可能并未带来太多“价值”的 rollups 共享部分利润，则它们显然有更多理由去转向他们自己的孤立系统。EigenLayr 的 Sreeram 也对此有一些 想法，我们建议仔细阅读。

当你考虑到搜索者在新的链上工作的技术成本时，这也会变得越来越重要，因此标准化这一点，并向链提供产权证书以满足“他们的” MEV 是一个很好的起点。本质上，在 MEV 中，主导界面（或软件）可能会获胜——然而实际上货币化这些软件是极其困难的，除非你运行主要的基础设施部分（导致中心化）。在市场层面，共享排序器提供的本质上是一个多个供应商的公共内存池，以及一个可能引导更健康竞争的中心化拍卖。

这里的一个担忧是，如果两个 rollups 都在共享集合中进行序列化，那么一个“经济”价值较少的 rollup（A）担任排序器，可能会被选为提议拥有高 MEV + 费用的区块，这些费用源自 rollup（B）。从 rollup B 的角度来看，它本质上可能会错失一些价值，而在孤立模式中，他们是可以独享这些价值的。

解决互操作性权衡

关于前面讨论的关于互操作性的提议权衡，解决这些问题的另一种办法如下总结：

共享排序器网络的目的在于它为多个链提供了一种典范保证，这在这种情况下显然是一项巨大优势。这可以与一种保证在 rollup 之间进行有效状态转移的机制相结合。这可以是基于委员会的方法（例如 PoS），一种绑定的背书（乐观方法），或我们更倾向于的——一种由委员会签名支持的 ZKP。由于共享排序器是“懒惰的”，它们仅创建针对多个 rollups 的超级块，以将交易进行排序，而这些交易的执行则留给具体的 rollup。状态证明（即：Lagrange、Axiom 或 Herodotus 等）都是能够在主权 rollup 之间潜在获取最终性评估的可行方案。你甚至可以通过像质押池、EigenLayr 等东西添加经济保证最终性背书。基本概念是，共享排序器提供了顺序的经济性典范保证，基于此顺序生成有效性证明则具决定性。基本思想是，rollups 能够在彼此之间同步执行交易。例如，两个 rollup 节点网络能够通过 ZKP 确定地确认两个 rollup 历史的合法性，并且可通过发布到有效 DA 层的数据进行验证。然后，这些 rollup 节点可以通过在链上发布一个从网络 A 和 B 接收到的单一 rollup 区块前缀来同时结算这两个 rollup。有一点需要说的是，我们之前略微提到过——跨 rollup 的原子（或同步）交易价格很可能高于单独内部 rollup 交易。这是因为条件跨 rollup 交易需要从两个独立系统中通过共享执行来消耗资源。

Succinct 也对在 Optimism superchain 生态系统中与共享排序器（和共享欺诈证明）之间进行的跨链“原子”交易进行了书面讨论，你可以查看 此处。此外，正如 Polymer 的 Bo Du 所言；“跨链原子交易就像为写操作在数据库碎片之间获悉锁”。

垂直未来

Jon Charbonneau 和其他人已经深入探讨了 SUAVE 类链的内部运作，因此我们不会过于详细。你可以查看他的一些作品，如果你想要更详细的描述。尽管我们认为，垂直整合确实值得拥有自己单独的一部分，以突显我们可以做到的极高的模块化程度（以及为何如此），以及关于垂直整合的一些开放问题和担忧。

尽管来自 Astria、Espresso 和 Radius 的当前共享序列提案极具模块化，排序器仍然充当构建者和提议者（尽管在 Astria 的案例中，它们不执行交易）。Astria 还积极在其架构内构建 PBS。

实现 PBS 有多种方法，即便尚未构建到协议中（但去中心化程度各异）。像 SUAVE 这类，使用像 MEV-Boost 的链下模型，或实施构建者模块（如由 Mekatek 和 Skip 开发的 Cosmos SDK 模块）。

需要注意的是，这些都不是排他性的。你可以灵活地利用多种不同的方法，并让任何人表达他们的偏好。其中执行者们竞相满足这些偏好。在选项中添加更多灵活性始终是好的（并符合我们对模块化的信仰）。然而，各種实现的权衡会有所不同。对于像 SUAVE 之类的东西，你确实要添加隐私性（借助 SGX或密码学），同时为了真实保障提供密码经济安全，而不是依赖完全受信任的中心化 PBS 构建器。（感谢 Jon Charbonneau 的反馈）。

垂直集成到构建者链中需要以某种方式进行，以确保公平，并不走捷径而增加延迟和降低性能。因此，一条构建者链需要具备极其优化的条件，并且可能需要昂贵而高性能的硬件（导致中心化）。这意味着，为了实现终端用户的验证，我们可能需要实现某些轻节点的设置（尽管它们必须信任全节点），或利用一种状态证明类型的设置，以确保链与用户均有满偏好的证明，且确保区块正确构建。

这样的链可能会超大状态（我们希望避免这种情况）。尽管这些状态重交易将通过智能合约进行偏好竞标。在偏好竞标的情况下，它要么被填满，要么不被填满（在短时间内），因为竞标通常只在短时间内有效，具体取决于偏好。这意味着，我们可能能够对竞标实现非常高效（且及时）的状态过期——这将允许我们修剪数据并保持链“干净”。这个过期时间需要长 enough，以仍然允许偏好竞标被填满，不过过期设置过短则实质上不可能实现对未来区块空间的有效完整翻倍。由于它们并不需永存（与应用不同），恢复和检索过期的竞标合约不太可能被需要-这可以通过在填满竞标后提供状态/存储证明，或通过 DAS 存储解决方案来实现，例如 Joachim Neu 提出的 方案。

如我们早前讨论所见，验证 SUAVE 的“真相”可能限制在该平台的“鲨鱼”（即有强大用户）之间，因为大多数用户和 SUAVE 策略的客户从中获利颇丰。这可能诱使我们让人们运行全节点以验证——尽管这很大程度上排除了广大人民（你可以认为他们并不需要验证）。我认为这是与加密相悖的；我们更倾向于看到通过状态证明或进行友好兼容的轻客户端实现的 SUAVE 的验证。

需要这个的原因是，你会希望验证你的偏好是否被恰当地填满，以及在支付时区块是否装有正确的信息（防止奇怪的重打包及其他攻击手段）。这基本上是一个预言机问题——这确实可以在所有 SUAVE 将要实现的链上对于 Stateproof 解决。将这些状态证明跨链带来另一个问题；我们如何跨链传递这个信息，以便无损或不扣留措施？可能通过强大的经济最终性背书（比如由 Lagrange 提出的方案，在这种情况下，你可以使用 EigenLayr 的重新质押验证器来确认链的最终性和真实性，并具有极强的经济担保）。但这将引发另一个问题（例如，竞标合约指明“预言机”——在此例中为再质押者）提出持有质押的代币并提供经济担保，然而我们该如何在共识之外进行清算？虽然你可以编码进清算机制，但这并不在共识中，这意味着会利用社交清算（然而很少“公正”，并可能导致问题）通过智能合约实现。这是当前 EigenLayr 清算时遇到的一个更严重的问题。

如此一来，我们将处于什么情况呢？直到我们妥善实现链上“无信任”的清算并不依赖共识；SUAVE 类链可能需要自身的共识算法和密码经济安全，以确认竞标偏好的最终性和构建的区块——然而，这意味增加其他密码经济攻击途径，尤其是当其构建的 rollup 的价值远远高于其自身的密码经济安全度。

此外，对于 SUAVE 类链和跨领域 MEV 的总体设计空间还有相当大的想象空间。以下仅是一些可能的研究途径：

• 意图匹配与基于意图的系统

• 多资产交易中的凸优化

• DSLs

• MEV 重分配

• 延迟战争

• 为多个 rollup 的状态机器构建单一行动者所需的扩展性问题

• 偏好表达

在偏好表达方面，为了与 EVM 中的智能合约交互，合约调用（消息）会被发送到带有执行指令的已部署代码的特定功能地址。虽然用户提供输入，但由于潜在状态的关系，他们未必对输出控制。

相比之下，偏好表达设计系统（如 SUAVE 和 Anoma）仅要求用户用 bond 签名偏好，在满足搜索者的偏好的情况下，该 bond 将支付给构建者和提议者。不同类型和虚拟机的执行可能因复杂的组合逻辑（如 MEV 搜索者和构建者的交易订单）而各有不同。这是最近引起众多关注的新设计空间——尤其是在 Anoma 结构上。我们建议查看 Anoma 体系架构。同时强烈推荐 这一短文，这是来自 Haun 的 Breck 发表的前菜。

本文的大部分内容能够出现，离不开在此领域所做出的伟大研究。非常感谢：

• Evan Forbes（Celestia）

• Alex Beckett（Celestia）

• Astria 团队

• Espresso 团队

• Flashbots

• Jon Charbonneau 和 Michael Jordan 来自 dba（小写研究 + 和大量其他来源）

• Bloxroute Labs

同时，我们想感谢所有人、项目与公司，在这篇文章中所引用的内容。

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