共享排序器:共享排序、聚合的 SoK...

  • maven11
  • 发布于 2023-05-06 20:40
  • 阅读 26

本文深入探讨了共享排序器网络(Shared Sequencer Networks)的概念,它旨在通过聚合多个 Rollup 的交易排序来提升审查抵抗性、互操作性和最终确定速度。

共享排序器;关于共享排序、聚合理论和垂直整合的SoK

想象一下,在一个开箱即用的 Rollup 可以实现高水平的抗审查性、易于部署、互操作性、快速最终性、活性和 MEV 民主化的世界。这可能看起来是一个崇高的目标,但随着共享排序器的到来,这样的世界可能触手可及。然而,并非所有的 Rollup 都是一样的,这导致我们思考如何在共享排序器网络上分配奖励和 MEV。在本文中,我们将探讨使共享排序器网络可实现的属性以及可以实现的属性。

共享排序器网络主要由 Alex Beckett 介绍,后来由来自 Celestia 的 Evan ForbesEspresso Systems 团队(以及 Radius)进行了更深入的介绍,同时还有 Jon Charbonneau 的最新 文章。Josh、Jordan 和他们在 Astria 的团队正在构建第一个生产中的共享排序器网络。Astria 的共享排序器网络是一个模块化区块链,它聚合和排序 Rollup 的交易,而不执行这些交易。

在 Astria 的设置中,排序器将排序后的区块发送到 DA 层,也发送到 Rollup 节点。Rollup 从排序器获得软最终性保证,从 DA 层获得硬最终性保证(在区块最终确定后),然后它们将执行对其有效的交易。

共享排序器网络本质上是一组与 Rollup 无关的排序器,顾名思义,它可以为一组不同的 Rollup 提供服务。这有各种权衡和属性,我们稍后会讨论。首先,我们必须描述对于排序器(或一组排序器)来说最重要的属性。在 Rollup 中,排序器或排序器集的主要要求是抗审查性或活性(其中一些是从基础层继承的,以及安全性)。这意味着提交给排序器的有效交易必须在有限的时间内(超时参数)包含在链中。共享排序器集只需要确保交易包含在一个区块中(即 crLists)。

正如我们在 Modular MEV 第 2 部分中概述的那样,实现抗审查性和活性都非常困难。在像 Tendermint 这样的共识算法中,你可以确保在攻击后恢复。但是,在发生攻击时,你会失去活性。本质上,要求所有其他排序器签署一个区块,而不是选择一个定制的领导者,可能不是最好的选择。虽然这增加了抗审查性,但代价是“中心化”和 MEV 提取到一个单一的领导者。另一种可以使用的排序机制,可能类似于 Duality 的 Multiplicity。这是他们的工具,用于非领导者节点(或排序器)将额外的交易包含到一个区块中。总的来说,在大多数共识协议中,攻击后的抗审查性和活性很难实现。

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

它允许避免在因审查或未签名的情况下选择新的领导者之前,必须等待最大的网络延迟(超时)。它可能成为去中心化排序器集的一种有趣的共识算法的原因是,它解决了共识中活性问题,而无需添加额外的阶段。如果一个领导者知道最高的锁(对特定输出达成一致的最多行为者),并且可以说服诚实的参与者,那么问题就解决了。如果不是,则在特定点之后的诚实领导者可以负责任地推动进展,从而帮助下一个领导者。例如,Hotstuff 节点不需要在通知新领导者之前确认切换消息,而是可以直接切换到新视图并通知新领导者。

它与 Tendermint 的不同之处在于,尽管两者都是两个阶段(Hotstuff I 有三个,II 有两个),但 Tendermint 具有线性通信,但没有响应性,而 Hotshot2 有。如果存在一系列诚实的领导者,则该协议是乐观响应式的,因为所有步骤(除了第一个领导者的提议)都依赖于从上一步获得足够数量的消息。在共享排序器设置中,这使得协议有可能在不需要回退到底层的情况下实现更好的活性,而又不消除这样做的可能性。

共享排序器集的构建块

允许一组排序器向结算层(Rollup 所在的层)提交交易。你可以加入该集合,前提是它们满足某些要求,并且没有达到所需的提议者数量。这可能是为了优化延迟、吞吐量等等——例如,Tendermint 保持相对较低)。这些要求将类似于你如何在某个区块链上成为验证者。例如,你必须满足某些硬件要求,以及起始权益或保证金——如果你想提供经济的软最终性,这一点尤其重要。

共享排序器集(或者说任何去中心化的排序器集)由几个组件组成,这些组件协同工作以确保交易得到处理。这些组件包括:

  • 每个 Rollup 的 JSON-RPC,用于向节点提交交易(对于非完整节点运行者),这些节点在构建和排序之前充当 mempool。在 mempool 中,需要某种机制来决定队列,以及交易选择过程,以确保有效的区块构建。

  • 区块/批次构建算法,它处理队列中的交易并将它们转换为区块或批次。此步骤还可能包括可选的压缩以减少结果区块的大小(calldata 压缩)。如前所述,这应该与提议者分开——本质上是 PBS。数据压缩可以采用多种形式,例如:

    1. 没有 RLP 编码——但是,这可能需要用于去中心化的排序器集,以帮助标准化节点之间以节省空间格式传输数据。
  1. 省略 nonce(验证特定区块中数据的唯一编号)——当需要执行时,可以通过查看链的先前状态来重新计算它。

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

  3. Gas 简化——除了 gas 价格之外,还有 gas 编号系统

  4. 用索引替换地址——Rollup 可以存储地址索引,而不是存储完整地址,该映射存储在其他地方。

  5. 科学计数法 表示值——以 wei 为单位定价以太坊交易中的 value 字段,使其成为一个大数字。你不能省略 value 字段或将其减少到一组固定值。但是,你可以改用科学计数法来编写它,以节省数据。

  6. 省略数据字段——对于简单的转移不需要,但是对于更复杂的交易则需要。

  7. 用 BLS 聚合签名替换个人签名——签名是以太坊交易中最大的组成部分。你可以存储一定数量交易的 BLS 聚合签名,而不是存储每个签名。可以针对整套消息和发送者检查 BLS 聚合签名,以确保有效性。

  8. 将 From 字段作为索引——与地址字段一样,你可以将 from 字段作为索引添加到映射中。

  9. 一种有趣的“模块化”设计概念是,你也可以随意使用它并进行权衡,使其适合你特定的 Rollup 情况。

    • 对等网络 (p2p) 层,允许排序器从其他排序器接收交易并在构建后传播区块。此步骤对于确保共享排序器可以有效地跨多个 Rollup 工作至关重要。

对等网络 (p2p) 层

对等网络 (p2p) 层

  • 共享排序器集的领导者轮换算法(在单领导者选举的情况下,他们不需要达成共识)。你可以选择只设置一个领导者轮换算法。另一种方法是采用 Duality 提出的 多并发区块生产者 途径。

  • 一种共识算法,例如前面讨论的 Tendermint 或 Hotstuff2,以确保 Rollup 节点与账本的提议排序达成一致。

  • 一个 RPC 客户端,用于将区块/批次提交到底层 DA+共识层,这确保了区块/批次安全地添加到 DA 层,从而确保“最终”的最终性并且所有交易数据都可在链上获得。

  • 分离构建者和提议者的角色,以确保公平性和一致性,并避免 MEV 窃取。除了从排序中删除执行之外,优化效率、降低 PGA 和提高 CR 非常重要。

Rollup 节点接收来自排序器的已排序区块以进行软提交,并接收来自 DA 层的已排序区块以进行硬提交

Rollup 节点接收来自排序器的已排序区块以进行软提交,并接收来自 DA 层的已排序区块以进行硬提交

交易数据 (calldata) 首先发布到基础网络上,在该网络上执行共识以保证用户和 Rollup 的交易。然后,Rollup 节点执行交易(并提交到添加到规范 Rollup 链的状态转换函数)。共享排序器网络为 Rollup 提供活性和抗审查性。Rollup 保持其主权,因为所有交易数据都存储在基础层中,允许它们随时从共享排序器中分叉出来。Rollup 端的 State Transition Function (STF) 中的状态根是从共享排序器发送到 DA 层的交易根(输入)计算得出的。在 Celestia 上,这是在将数据添加到链并达成共识时生成的。由于你已经有了 tx 根(和所有可用数据),Celestia 可以为轻客户端(Rollup 节点在 Celestia 上运行)提供一个小型的包含证明。

为了向用户提供他们期望的 UX,Rollup 节点会收到已排序的区块(也已发送到 DA 层)。这可以为 Rollup 提供软最终性保证——承诺该区块最终将在 DA 层上按原样排序,届时 Rollup 节点将执行交易并提供新的状态根。

区块创建和槽

为了确定区块创建的时间,排序器需要建立槽的概念。排序器应以规则的时间间隔(通常每 X 秒)提交批次,其中 X 是槽时间。这确保了交易能够及时有效地处理,因为否则特定槽的领导者将被超时,并失去其签名奖励(和执行奖励)。例如,Celestia 的区块时间(根据 GitHub 规范)可能约为 15 秒。由于这是已知的,因此我们可以对我们可能在从共享排序集到 DA 层和 Rollup 节点的最终区块中容纳多少个“槽/区块”做出一些假设。考虑到优化的 Tendermint 或类似 Hotstuff2 的东西。

假设设计允许 Rollup 完整节点有效地将它们处理成单个区块(在槽的时间和超时参数内),则可以在单个槽中提交多个批次。这有助于进一步优化区块创建并确保快速处理交易。此外,槽还可以用于促进排序器领导者选举。例如,你可以根据权益权重从权益池中随机选择一个槽领导者。以保持秘密的方式执行此操作最有意义,并且可能首选利用类似 秘密领导者选举 的东西,以最大程度地减少审查。甚至分布式验证器技术 (DVT) 类型的设置(例如 Obol/SSV 风格的解决方案)。延迟和槽时间对区块提交和构建如何影响协议有相当大的影响。因此,有必要了解这如何影响系统。Bloxroute 特别是对他们的继电器如何在以太坊上执行有一些 出色的研究和数据点。在 MEV-Boost 中,参与的提议者(验证者,或在 Rollup 的情况下为排序器)从继电器请求 GetHeader。这为他们提供了区块 bid,即特定区块的价值。这很可能每次都是收到的最高价值区块。对于每个槽,验证者通常在槽时间开始后约 400 毫秒请求 GetHeader – 并且由于显然有大量验证者 – 中继必须经常为无数的请求提供服务。对于大型共享排序器集来说也是如此。这意味着你需要适当的基础设施来促进这一点。

中继还在促进构建者和提议者分离的同时,还努力验证构建者构建的区块是否正确。他们还会检查是否正确支付了费用并充当 DoS 保护。此外,它们本质上充当区块的托管人,并且还处理验证器注册。这在无界排序器的世界中尤其重要,在这种世界中,你需要对谁在参与以及谁没有参与进行适当的核算(例如,前面讨论的同步层)。

就区块何时准备就绪而言(即由构建者提交),通常在槽开始之前或之后大约 200 毫秒呈现。虽然,与 GetHeader 一样,存在相当大的差异,但主要是在槽时间开始之前/之后 200 毫秒左右提供服务。在构建者发送到多个中继的情况下,实际上存在相当多的延迟。Bloxroute 还研究了将区块发送到多个中继时会发生什么。正如你可能期望的那样,区块传播到的中继越多,延迟就越多。平均而言,第二个中继需要 99 毫秒才能使区块可用,第三个中继需要另外 122 毫秒,而第四个中继需要另外 342 毫秒。来源:

正如在过去几个月中可能已经清楚的那样,RPC 对区块链而言极其重要。没有适当的基础设施是一项巨大的负担,并且拥有适当的 RPC 选择也至关重要。从这个意义上讲,因此对于将其交易发送到 RPC(和公共 mempool)的零售用户而言,包含 RPC 至关重要。Bloxroute 对 20 个交易进行了一个小测试,这些交易被发送到各种 RPC,然后测量了每个交易包含在一个区块中的时间。

来源: Bloxroute Labs

来源:Bloxroute Labs

有趣的是,由于这取决于哪个构建者赢得了相应的下一个区块,因此某些 RPC 需要多个区块才能包含该交易。交易从 RPC 发送到得构建者越多,快速包含的可能性就越高。尽管交易发起者有可能利用他们独特的位置优势来针对特定的构建者,甚至构建他们自己的区块。

关于以太坊中继性能的统计数据,了解它们的性能也很有趣。这有助于我们更深入地了解 PBS 在多验证者/构建者/中继世界中的运作方式,我们希望这通常是我们正在走向的 Rollup 的方向。Metrika 对此有一些很棒的统计数据,所有功劳都归功于他们。

这里应该注意的是,错过的 bid 只是指预期中继 relay bid 但没有 relay 的情况。对 bid 的期望来自已注册到任何给定槽的特定中继的验证者。这本身不是中继的错误,在协议级别上也不会这样对待。

来源: app.metrika.co

来源:app.metrika.co

如果发生了 bid 故障(例如,中继提供无效区块),并且它负有责任,则它将被视为 bid 故障。这些通常不是很频繁,并且大多数是注册偏好故障(即 gas 限制或费用不符合特定验证者的注册偏好)。更罕见的是共识层故障,即 bid 与以太坊的共识层规则不符,例如时间戳错误或父哈希与先前的区块不对齐等。

就延迟而言(例如,验证者收到构建者构建的区块标头响应的时间),数据非常一致。虽然有一些异常值,例如,如果被请求的中继与例如所选的验证者位于不同的地理位置。

来源: app.metrika.co

来源:app.metrika.co

构建者 而言,MEV-boost 上的构建者总数约为 84 个,其中前 3 大构建者约占已构建区块的 65%。这有些误导,因为这些也是运行时间最长的构建者。虽然它确实展示了一个有点中心化的构建者角色,但如果你降低时间尺度,我们会得到类似的结果。就实际的活跃构建者而言,过去 30 天的数量要低得多,为 35 个,过去一周为 24 个。竞争非常激烈,通常是最大和最坏的获胜。某些独有的 order flow 可能会并且已经只会增加这一点。我们预计构建者的分布将保持一定程度的中心化(由于它是具有最佳 order flow 和硬件优化的一场游戏)在几个参与者周围,除非我们对设置进行重大更改。虽然这不是一个根本性的问题,但它仍然是堆栈中的一种中心化力量,我们渴望了解有关挑战当前现状的想法。如果你有兴趣更深入地研究这个(严重)主题,我们强烈建议阅读 Quintus 关于 order flow、拍卖和中心化 的文章。

就我们期望构建者角色在模块化堆栈中向前发展的位置而言,我们非常确定(至少在 Cosmos SDK 设置中)将通过 构建者模块 看到 Skip/Mekatek 类型的设置。另一种解决方案是 SUAVE 类型的设置——例如,一个特定的全局构建者链,为任意数量的链提供区块构建和 bid 偏好服务,以确保 PBS。我们稍后将更深入地介绍此解决方案,并提供一些关于此的一些未决问题的答案。

关于中继,我们强烈推荐 Frontier Research 的 Ankit Chiplunkar 和以太坊基金会的 Mike Neuder 的一篇文章。名称为 乐观中继和在哪里可以找到它们。该文章详细介绍了 MEV-boost 中中继的运作方式、它们当前的权衡以及运行成本,以及可以进行的为了提高效率的可能更改。一个有趣的注意事项是,根据 Flashbot 的估计,目前在 MEV-Boost 中运行中继的成本约为 10 万美元/年。

最终性

作为我们如何看待与模块化区块链相关的最终性(因为它们现在看起来的样子)的先决条件,以下是我们之前 Modular MEV 文章中的回顾。请注意,这不是一个“官方”也不是对最终性的全面看法;但是,我们认为它最准确地代表了易于理解的心理模型中 Rollup 最终性的细微差别。

Pending_On_L2: Rollup 的排序器提供的软承诺,用户的交易最终将在底层上提交和最终确定,该底层从中获得安全性。

Finality_On_L2: 排序器已提交到 Rollup 的状态转换函数,并且区块已添加到 Rollup 的规范链中

Pending_On_L1: 交易输入或输出/状态转换函数已发布到 L1,但有效性证明尚未发布,或者争议期尚未结束 – 这也需要以太坊连续通过两个 epoch。这是大多数 Optimistic Rollup 表示已达到最终性的点,但是根据规范的桥 – 此时仍然存在任意的 7 天挑战期。

Finality_On_L1: Optimistic Rollup 的争议期已结束,或者有效性证明已发布并经过验证,并且已在连续两个 epoch 中以超多数确认。

现在,在主权共享排序 Rollup 上,这看起来略有不同,让我们尝试用图表解释一下:

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

那么,我们实际上如何实现这些级别的最终性?当一个区块被添加到规范链并且无法还原时,就实现了区块最终性。但是,这里存在一些细微差别,具体取决于完整节点或轻节点的视图。在已排序区块的情况下,一旦它被包含在 DA 层区块中,它就完成了。已执行的区块(带有状态根)由 Rollup 完整节点/验证者执行,这为他们提供了从基础层上的已排序区块派生的有效状态根的保证。超越完整节点的最终性(例如,对于轻客户端或桥接)必须相信所述状态根的有效性。在这里,你可以利用以下描述的方法之一。此外,另一种方法是由验证者负责正确证明状态根(乐观路线),通过保证金和随后的欺诈证明。你也可以提供有效性 (ZK) 证明。

有不同的方法来实现区块最终性:

  • 通过工作量证明 (PoW)、LMD+Ghost、Goldfish、Ouroboros (PoS) 等进行概率性地实现。

  • 当区块由足够的委员会成员签名时,可证明地实现。(例如,Tendermint 2/3,Hotshot2 或其他 PBFT 类型)

  • 依赖于 DA 层上交易/区块的排序,以便它决定什么是规范链和 fork 选择规则(例如,基于)。

可以通过不同的机制实现不同类型的最终性。

一种类型的最终性是“软最终性”(例如,pending),如果实现了单领导者选举,则可以实现。在这种情况下,每个槽将只有一个或零个区块(提交或不提交),并且同步层可以安全地假定这些区块中交易的排序。

另一种类型的最终性是提供比软最终性更强保证的“可证明最终性”(本质上是最终的)。为了实现可证明的最终性,大多数排序器必须签署一个区块,从而同意该区块是规范的。虽然这种方法很好,但如果已经实现了单领导者选举,则可能没有必要,因为它从根本上保证了区块排序。显然,这取决于生效的特定领导者选举算法。例如,它是 51% 的实施方案、66% 的实施方案还是单领导者(最好是随机 (VRF) 且秘密的)。如果你想进一步阅读有关以太坊中最终性的具体内容,我们强烈建议阅读 这篇文章,以及我们稍后将推荐的一篇关于无界集的文章。

许可型、半许可型或无需许可型

为了防止潜在的 DoS 攻击,必须设置经济障碍,既可以加入排序器集,也可以向排序器层提交交易。在有界(有限数量的排序器)和无界(无限)集中,必须存在向 DA 层提交批次的经济障碍,以防止同步层(在排序器之间传播区块)被减慢或 DDoSed。但是,DA 层本身提供了一些保护,因为向其提交数据需要付出一定的成本 (da_fee)。加入无界集所需的保证金应涵盖防止同步层被垃圾邮件攻击所需的任何额外成本。另一方面,加入有界集所需的保证金将取决于需求(从成本/收入角度来看的均衡点)。

使用无界排序器集,无法在排序器层上实现可证明的最终性(因为我们永远无法确切地知道有多少活跃的投票者/签名者)。另一方面,使用有界排序器集,可以通过大多数排序器签署一个区块来实现可证明的最终性。这确实需要同步层了解排序器层以及哪些排序器在任何给定时间处于活动状态,这会增加一些开销。在有界排序器集(例如,最多 100 个)中,你还可以优化排序器的数量以提高“性能”,尽管这会以去中心化和抗审查性为代价。有界集的重要性以及经济保证金是提供“快速”可证明的最终性的能力,这也是确定性的。

我们还在传统区块链中看到了无界和有界排序器类型,例如以太坊中的 PoS(Casper+LMD-GHOST),它是无界的;基于 Cosmos SDK/Tendermint 的链中的 PoS 使用有界集。一个有趣的思考是,我们是否期望社区围绕共享排序器做出类似于我们在权益证明中看到的类似的经济性和选择?在这里,我们看到了向一些实体的中心化(因此,如果你无论如何都只有几个大型质押提供商/池,那么无界实际上并不重要)。虽然,它们确实“掩盖”了中心化,但毕竟,如果你愿意,你仍然可以进行家庭质押。从意识形态的角度来看,选择几乎总是应该是无界的——但请记住,经济学使它们无论如何都非常相似。无论参与者是谁,你为之付费的经济学都应该是平等的,例如 DA 的成本和硬件成本(尽管这可能会因分配给你的权益数量和经验以及有效运行基础设施而降低)。即使在有界 PoS 世界中,我们也看到一群基础设施提供商从根本上成为几乎所有链中最大且最常看到的验证者。大多数 Cosmos 链上的验证者之间已经存在巨大的相关性,这肯定也对所述链的去中心化和抗审查性构成危险。虽然,一个非常不同的是,任何零售用户都可以将任何金额质押给他们选择的任何验证者。可悲的是,这通常都会分配给列表的顶部,生活还在继续。我们再次问;我们期望在模块化词中发生类似的经济学吗?人们希望不是,但随着我们的专业化,你通常希望找到最适合这项工作的人——而大多数时候,这是专业质押提供商。我们稍后也会在单独的部分中介绍这些经济学。

但是,要记住的最重要的一点是,归根结底,最重要的是最终用户验证——对于轻客户端和 DAS 来说,这对于任何地方的任何人都是可用的(即使在吉萨金字塔);

来源: @JosephALChami - Celestia 轻节点

来源:@JosephALChami - Celestia 轻节点

在排序器类型方面,无界和有界的权衡和优点可以概括为:

无界排序器集:

  • 任何具有足够保证金/权益的人都可以成为排序器 = 高水平的去中心化

  • 无法进行单领导者选举,因为该集可能是无限的。

  • 可以通过 VRF 进行非单领导者选举,但是如果不了解将有多少个排序器,则很难确定 VRF 参数。如果可能的话,这还应该是秘密领导者选举实施方案,以避免 DoS 攻击。

  • 如果没有领导者选举 = 浪费资源问题:区块构建本质上是自由的,并且谁提交的第一个有效区块/批次获胜,而其他人都将失败。

  • 排序器层上没有可证明的最终性,只有概率性——例如 LMD Ghost+Casper

  • 只有在批次写入 DA 层后才能达到最终性(限于底层区块时间,Celestia 的情况下为 15 秒)。

  • 比有界集“更好”的抗审查性。

有界排序器集:

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

  • 允许的排序器数量在任何特定时间都是有限的。

  • 与无界集相比,有界集可能更难实施。

  • 可以实施单领导者选举,从而在排序器层上提供强大的最终性保证。

  • 同步层需要了解排序器集才能知道哪些区块有效。

  • 将排序器集(或集更改)写入结算层区块(例如,fork 选择规则),这些区块写入 DA 层,可以允许同步层独立确定排序器集。例如,这就是 Sovereign Labs 的 Rollup 的运作方式,集更改写入发布到 DA 层的有效性证明中。

  • 如果 DA 层的速度足够快,则可能没有必要在排序器层上提供强大的最终性保证(但是,大多数当前未优化的结算层设置的区块时间至少为 10 秒以上)。

关于如何监视这些排序器集,以及如何添加或删除新参与者,对于应如何实施,仍然存在相当大的设计空间。例如,是否会通过代币持有者治理来实现这一点(以及如何考虑使用该集的许多不同代币和 Rollup)?这意味着很可能将通过脱链社会共识来完成,该共识表示链上变更(例如,以太坊的方式)。但是,请记住,关于违反共识规则的削减,实际的链上共识显然已经到位。

共享排序器的经济学

共享排序器网络的经济学允许一些有趣的选择。正如我们之前讨论的那样,共享排序器网络中的验证者与典型的 L1 验证者没有太大的不同。它参与的网络只是更优化于完成一项任务,即接收意图(预 PBS),然后提出和排序交易。像“常规”验证者一样,存在收入和成本组成部分。在等式的两边,验证者参与的网络都具有很大的灵活性,类似于常规 L1。

收入来自用户,或者说最终目的是要与之交互的 Rollup,他们为使用共享排序器支付一定的费用。该费用可以是 MEV 提取的百分比(输入数量可能很难在此处近似),跨链价值转移、gas 构造或每次交互的固定费用。最优雅的收入解决方案可能是一种设置,其中支付给共享排序器的价值小于通过在 Rollup 之间共享排序器并获得共享安全性和流动性带来的额外价值。不利之处在于,堆栈另一部分的去中心化优势很难量化。但是,随着共享排序器网络发展成为自己的生态系统,其提取费用的能力可能会增加。这在很大程度上是由于其固有能力可以轻松聚合,并且在某种程度上具有规模经济效应。随着越来越多的 Rollup 以及随之而来的应用程序加入网络;可提取的跨域 MEV 越多。

在成本方面,共享排序器网络也具有竞争的可选性。他们可以轻松地通过预先支付发布到 DA 层的成本,甚至用于与 Rollup 本身上的应用程序交互来补贴其网络的使用。这类似于 web2.0 公司使用的策略,即你会在用户(或 Rollup)获取上遭受初步损失,并希望他们的长期收入能够超过支出。另一种更新颖或加密原生的方法是允许 Rollup 以其原生代币支付 DA 费用。在这里,共享排序器层承担了在 DA 层上发布数据所需的代币价格与 Rollup 的原生代币之间的定价风险。从本质上讲,它仍然是一个共享排序器预先支付成本;但是,它通过获取“供应商”(Rollup)的代币来创建生态系统对齐。这与我们在 应用程序链论文 中提出的仓储结构有些相似。可能降低成本的另一个部分是通过利用不同形式的 DA。由于利用率高,不同的 DA 层将提供不同的定价,用户可以通过轻客户端轻松进行验证或完全做出不同的区块大小选择的能力。最后,共享排序器还可以在发布到 DA 层之前批量处理交易。在 ZKR 的情况下,这可以降低 tx 成本,因为交易达到了某种均衡,在 ORU 方面,你可以进行我们在各种 Rollup 上实时看到的各种批处理 gas 优化。这将减少需要在 DA 层上发布的数据量,从而降低共享排序器网络的成本,从而提高整个网络的盈利能力。但它的代价是限制了互操作性并更改了最终完成的时间(在前面讨论的 L1 上的最终完成感的意义上)。 总的来说,共享排序器网络的经济学原理允许一些有趣的实验和引导策略。我们估计,关键的区别将是生态系统的大小,以及因此产生的跨领域 MEV 的数量,而不是成本方面。我们还强烈建议查看 Espresso 团队关于共享排序的非常深入的 博客文章,他们也涵盖了这些类型网络的经济权衡(和积极因素)。为了展示 rollups 为什么有动机利用共享排序的另一种方式(除了经济因素之外),看看聚合是有意义的。

聚合理论与共享排序器

另一种描述共享排序器所具备的属性的方式是通过聚合理论的视角。聚合理论(AT)是指平台或聚合器如何通过系统地整合其他平台及其用户来获得显著的用户吸引力。你本质上是将游戏从稀缺资源(例如,区块空间)的分配转变为控制对丰富资源的需求(同样,在这个例子中区块空间是有意义的)。AT 本质上是将供应商和产品(即 rollups 和区块空间)聚合到单一的、卓越的用户体验中,以供聚合的用户群使用。随着这些聚合器的网络效应增长,这种关系变得越来越具有排他性——没有理由离开。随着这种情况的发生,用户体验就成为了相似设置之间至关重要的区分因素。如果新用户的激励措施到位(例如,良好的 UX 和简单的互操作性),那么 rollup 转移到自己的网络或不同的集合的可能性不大——因为网络效应会驱动新的供应商和新用户。这从供应商和用户的角度,以及从聚合的抗审查性的角度来看,都产生了一种飞轮效应。

来源:Aggregation Theory 2015, Ben Thompson

来源:Aggregation Theory 2015, Ben Thompson

在共享排序器的领域中,AT 可以被视为 rollups 几乎是“组合”和联盟,它们都利用了相似的垂直堆栈部分——加强了自己和他人,同时使用户能够在任何地方都拥有相同的体验。

供应商(例如 rollups)在理论上在共享排序器集合中不是排他性的,但在现实中;共享排序器集合,它的 rollups 和用户受益于网络效应的循环,从而导致了这些 rollups 的使用量增加。这些好处使得 rollups 和用户更容易与共享堆栈集成,因为如果不参与,他们会损失更多。当只有两个 rollup 共享一个排序器集合时,这些好处可能很难看到,但当你在等式中添加越来越多的 rollups 和用户时,情况就会变得更加清晰。共享排序器集合与用户有直接关系,因为它们会对用户的交易进行排序,即使用户自己也不知道他们正在与它们互动——因为从他们的角度来看,他们只是在使用一个他们有理由与之互动的 rollup (这意味着排序/排序器变得具有排他性)。与这些排序器相关的唯一成本本质上是运行它们的硬件成本,只要保护它的区块空间和 Token 对最终用户有价值。交易费用是数字化的,并从用户的钱包中支付,也许在未来,甚至可以通过账户抽象中的 paymasters 等进步来抽象掉(但是,有人必须承担 DA、排序和执行的成本)。

当你考虑到 Astria 的 Josh 和 Jordan 以前在哪里工作时——Google,这种情况就更有意义了。自成立以来,Google 的产品就深受 AT 思想的启发,这在 Google 搜索中尤其明显,Google 搜索是通过模块化(lol)各个页面和文章而创建的,从而可以通过全局搜索窗口直接访问它们。

在这种共享排序器集合的案例中,客户(rollups 的用户)的获取成本越来越低,因为随着供应商(rollups)数量的增加,他们很可能会被该集合所吸引。这确实意味着,在大多数情况下,聚合器(或多重聚合器)可能会产生赢家通吃的效应,因为该聚合器的价值随着供应商的增加而增加(当然,前提是用户体验良好)。相反,在单一排序网络上,客户获取仅限于单个网络及其应用程序。如果用户想要使用位于不同 rollup 上的 rollup 应用程序,他们将(在当前限制内)必须完全离开该网络。这意味着用户和价值的粘性不高,也意味着在任何时候,如果不同的 rollup 生态系统受到高度重视(或有更多的激励), capital 可能会迅速撤离。

属性和权衡的总结

属性

一个共享排序器集合是一个 rollup 网络,它为多个 rollups 聚合和排序交易。这些 rollups 都共享相同的排序器。这种资源池意味着 rollups 获得更强的经济安全和抗审查性,从而允许 快速的 软最终性保证和有条件的跨 rollup 交易。

现在,Twitter 上出现了大量关于共享同一排序器集合的 rollups 之间的原子性的讨论。这主要是围绕着它是否默认是原子性的,或者不是——它不是。但是,如果所讨论的 rollups 已经实现了彼此的状态转换函数(STF)作为它们之间关于条件交易的依赖关系——它们确实可以具有原子性——只要它们的 slot/区块时间对齐(它们应该使用共享的排序器集合)。在这种情况下,为了获得原子互操作性,你本质上只需要在链 B 上运行链 A 的轻节点,反之亦然(类似于 IBC 的工作方式)。为了进一步提高这种互操作性的安全性(除了信任单个完整节点作为轻节点之外),你可以实施 ZKP(本质上是状态证明)来解决确保状态确实正确的“预言机问题”。这将更清楚地表明条件交易或类似交易是否已接触它们之间的规范桥。欺诈证明也是一种可能性,但显然会给我们留下一个挑战期(这意味着第三方会出现并为此风险收取费用)。此外,在轻客户端(而不是彼此的完整节点)的情况下,由于等待签名的标头 + 欺诈证明窗口(如果有的话),它将至少落后一个区块。

我们认为,“桥接”最有可能通过轻客户端和 ZK 结合来解决。在这种情况下,使用轻客户端(而不是智能合约)的挑战在于,需要rollup 节点端的硬分叉(升级等)彼此结合进行,以保持其桥梁运行(就像 IBC 需要启用相同的状态模块一样)。如果你想阅读更多关于这个特定主题(以及如何解决它)的信息——我们强烈推荐这个演示文稿

是什么让共享排序器具有令人难以置信的可扩展性,那就是它们不执行和存储任何状态(就像现在的中心化排序器所做的那样)。rollup 节点本身也是如此(除非它们想要彼此之间的原子性——例如轻客户端/状态证明,否则它们不必扩展到 100 多个节点)。这些节点只执行对其 rollup 有效的交易,以及对它们也有效的任何有条件的跨域交易。如果 rollup 节点必须为许多 rollup 执行和存储状态,那将阻碍可扩展性并降低去中心化(反过来会降低抗审查性)。它还加强了 Proposer-Builder-Seperation (PBS) 的概念。虽然我们仍然需要完全分离构建者和提议者。在当前的设置中,排序器本质上是一个构建者和提议者(尽管它们不执行交易)。理想的设置很可能是排序器只是盲目地签署来自高度优化的构建者设置的已构建区块,并确保区块得到正确实施(同时为该证明提供高度的经济最终性和抗审查性)。通过这种方式,它们可以提供高度的安全性和承诺,以保证 rollup 节点的软最终性。

对于跨 rollup 的条件交易,它们还用于帮助启用 rollup 节点(执行者)以提供中间状态根,从而实现 rollup 之间的原子性。如果你想深入了解这可能是什么样子,那么这个简短的演示文稿非常适合你。

权衡

正如我们在特定于应用程序的链论文中所述,前面提到的超时参数对 MEV 和交易包含有一些有趣的影响,具体取决于排序器集合的排序和领导者/共识机制。例如,如果超时参数相对较短,则对于去中心化排序器级别的提议者来说,尽快发布数据至关重要。在这样一个世界中,你可能会获得去中心化排序器集合的“验证者”之间的竞争,他们竞相充当领导者,并在 DA 层上相互竞标区块空间,直到不再具有经济上的吸引力为止。

正如 Evan 在 Celestia 论坛上最初的 lazy sequencers 帖子中所述,在将交易发布到基础层(在本例中为 Celestia)之前等待执行交易是非常浪费的。因为你现在受限于基础层的区块时间 - 从 UX 的角度来看,等待最终性需要很长时间。为了获得更好的 UX,共享排序器为 rollups 提供软最终性承诺(如前所述),这为我们提供了用户在现有中心化 rollups 中习惯的 UX(同时保持去中心化和高度的抗审查性)。软承诺本质上只是对交易最终顺序的承诺,但得到了沉重的经济约束和来自基础层的 快速最终性(发布后)的支持。欺诈证明也涵盖了这一点(如引言中所述)。实际的硬最终性发生在所有交易数据都已发布到基础层时(这意味着 L1 实际上更快地实现了最终性)。这取决于 rollups 是否使用欺诈证明或零知识证明来验证其主权证明——这发生在 rollup 端。想要这种分离的原因是从排序器中消除状态转换的繁重计算(这是一个巨大的瓶颈)。相反,rollup 节点只处理对它们有效的那些交易(这确实意味着我们必须添加有条件的交易、状态证明或轻节点验证以实现适当的互操作性)。硬最终性仍然取决于基础层(但这可能在 Celestia 上大约为 15 秒,并且也与 Tendermint 确定),这确实为我们在 rollup 端提供了高度的相对快速的硬最终性保证。

也可以在网络中使用 ZK 证明来优化验证、交易大小(例如,只发布状态差异——但这确实增加了更高的信任度,直到发布 ZKP)。正如前面所介绍的,这些状态证明可以用于允许连接的链/rollups 具有更简单和更快的互操作性(不必等待挑战窗口)。

前面介绍的这些有条件交易的一个缺点是,验证和发布它们可能会更昂贵(例如,Tendermint 区块头验证成本很高,并且在 Cosmos 链上得到补贴)——并且会增加一些系统延迟(但仍然比孤立的 rollups 快得多)。由于垂直共享集成而可以实现的原子性弥补了其中的很多。

在新的 rollup 的引导阶段,使用共享排序器集合非常有意义——并且你作为供应商所获得的积极因素很可能会超过你可能“被迫”在护城河级别上做出的一些权衡。但是,对于已经成熟且具有大量交易和经济活动的 rollups 来说——放弃部分护城河可能意义不大。

这引出了一个问题,我们是否需要类似经济/交易(每个 rollup)加权的 MEV 提取重新分配,以吸引已经成熟的 rollups 加入共享集合——甚至保留非常成熟的 rollups 并避免它们拆分自己的网络。这都非常理论化,但这肯定是一个有趣的想法,围绕着 MEV 在具有不同程度活动的许多 rollups 之间的共享垂直世界中会是什么样子。例如,如果一个通过排序器集合驱动大部分价值的单个 rollup 与其他人(可能没有带来那么多“价值”)分享这些利润的一部分,那么它们肯定有更多的理由迁移到自己的孤立系统。EigenLayer 的 Sreeram 在这里也有一些想法,我们也建议阅读。

当你考虑到搜索者在新链上工作需要相当大的技术成本时,这一点也变得越来越重要,因此标准化这一点并为链提供一些关于“他们的”MEV 的主权可能是一个好的起点。从本质上讲,在 MEV 中,占主导地位的接口(或软件)可能会胜出——但是,除非你运行关键的基础架构部分(导致中心化),否则实际上将此软件货币化非常困难。在市场层面上,共享排序器提供的是本质上是许多供应商的公共 mempool,中心化拍卖很可能会导致更健康的竞争。

这里的担忧是,如果两个 rollups 都在共享集合中运行一个排序器。运行排序器的具有“较少经济”价值的 rollup (A) 可能会被选为提出区块,其中包含来自 rollup (B) 的大量 MEV + 费用。从 rollup B 的角度来看,它们本质上会错过一些价值,而如果采用孤立的方法,它们会将这些价值保留给自己。

解决互操作性权衡

关于提议的关于互操作性的权衡的另一个说明,解决其中一些问题的另一种方法总结如下:

共享排序器网络的重点是它为多个链提供了规范性的保证,这肯定是一个很大的优势。这可以与一种机制相结合,以保证 rollups 之间有效的状态转换。这可能是一种基于委员会的方法(例如 PoS)、一种绑定的证明(乐观方法),或者我们更喜欢的一种方法——由委员会签名支持的 ZKP。由于共享排序器是“lazy”的,它们只创建对多个 rollups 的交易进行排序的巨型区块,并且所述交易的执行留给特定的 rollups。状态证明(即 Lagrange、Axiom 或 Herodotus 等)都是可能获得对跨主权 rollups 的最终性的证明的解决方案。你甚至可以通过诸如 staking 池、EigenLayer 等添加经济绑定最终性证明。这个想法是共享排序器提供了订单规范性的经济保证,并且从此订单生成有效性证明是确定性的。基本思想是 rollups 可以同步地执行彼此之间的交易。例如,两个 rollup 节点网络可以通过 ZKP 并通过可用性条件感知到 rollup 历史的有效性(数据已发布到高效的 DA 层)。然后,rollup 节点可以通过在链上发布从网络 A 和 B 收到的单个 rollup 区块前缀来同时结算两个 rollups。需要说的一点是,我们之前稍微介绍了这一点 - 跨 rollup 原子(或同步)交易可能比单个内部 rollup 交易更昂贵。这是因为有条件地跨 rollup 的交易通过共享执行消耗来自两个独立的系统。

Succinct 还撰写了一篇关于 Optimism 超链生态系统中具有共享排序器(和共享欺诈证明器)的 rollups 之间的跨链“原子”交易的文章,可以在此处查看。Bo Du 从 Polymer 的观点来看,“跨链原子交易就像获取跨数据库分片的锁以进行写入”。

垂直的未来

Jon Charbonneau 和其他人已经非常深入地研究了类似 SUAVE 的链的内部运作方式,因此我们不会过多地详细介绍。如果你想要更详细的描述,可以查看他的文章。虽然,我们确实认为垂直整合应该有自己的部分,既要突出我们真正可以实现怎样令人难以置信的模块化(以及为什么),又突出围绕垂直整合的一些未解决的问题和担忧。

虽然来自 Astria、Espresso 和 Radius 的当前共享排序提案非常模块化,但排序器仍然充当构建者和提议者(尽管在 Astria 的案例中,它们不执行交易)。Astria 还在从一开始就积极地将 PBS 构建到他们的架构中。

如果 PBS 尚未内置于协议中,则有几种方法可以实现 PBS(尽管去中心化的程度不同)。类似于 SUAVE,使用链下模型(如 MEV-Boost),或实现构建器模块(如 Mekatek 和 Skip 构建的 Cosmos SDK 模块)。

重要的是要注意,这些都不是排他性的。你可以灵活地使用几种不同的方法,并让任何人表达他们的偏好。从而让执行者竞争以满足这些偏好。添加更多的选择总是好的(并且符合我们对模块化的信念)。虽然,各种实现将会有不同的权衡。对于像 SUAVE 这样的东西,你可以(通过 SGX 或密码学)在密码经济安全性之外,向真理添加隐私,而不是依赖于完全受信任的中心化 PBS 构建者。(感谢 Jon Charbonneau 在此处的反馈)

垂直集成到构建者链需要以一种确保公平、不偷工减料并增加延迟和降低性能的方式完成。因此,构建者链需要进行令人难以置信的优化,并且可能需要昂贵且性能良好的硬件(导致中心化)。这意味着要获得最终用户的验证,我们可能需要一些轻节点实现(尽管他们必须信任完整节点),或者使用状态证明类型的设置来确保链和用户能够证明投标偏好已得到满足,并且区块已正确构建。

这样的链可能会具有令人难以置信的状态(我们希望避免这种情况)。尽管这些状态繁重的交易将是通过智能合约进行的偏好投标。在偏好投标的情况下,要么满足偏好,要么不满足(在很短的时间内),因为投标通常只有在很短的时间内有效,具体取决于偏好。这意味着我们可能能够为投标实施非常有效(且早期)的状态到期——这将允许我们修剪数据并保持链“干净”。此到期日期需要足够长,以仍然允许满足投标偏好,尽管将其降低太多实际上使得实现遥远的区块空间期货是不可能的。恢复和检索过期的投标合约的需求不太可能需要,因为它们不需要永远存在(与应用程序不同)——可以通过在投标得到满足时提供状态/存储证明,或者通过 DAS 存储解决方案——如 Joachim Neu 提出的解决方案,从而使此操作更加“安全”和无需信任。。

正如我们早期所介绍的,验证 SUAVE 的“真相”的需求很可能仅限于该平台的“鲨鱼”(高级用户),因为 SUAVE 实现的大多数用户和客户都可以从中获得显着的经济利益。这可能会诱使我们只需让人们运行一个完整节点(如果他们想要进行验证)——尽管这排除了绝大多数人(你可以争辩说他们没有验证的必要)。(我们认为)这与加密技术背道而驰,我们更希望看到通过状态证明或通过轻客户端友好的实现“无需信任地”实现 SUAVE 的验证。

需要这样做的原因是,你想要验证你的投标偏好是否得到了正确满足,并且区块是否在支付时填充了正确的信息(以避免奇怪的重新捆绑和其他漏洞)。这本质上是一个预言机问题——这确实可以通过状态证明解决链上状态(SUAVE 的所有状态)。但是,使这些状态证明跨链会带来另一个问题,我们如何以确保没有任何东西被篡改或隐瞒的方式跨链中继此信息?这很可能通过强大的经济最终性证明(例如 Lagrange 提出的证明,在其中你可以使用 EigenLayer 的重新 staking 验证器来证明链的最终性和真相,并具有非常强大的经济纽带)。然后,这将带来一个不同的问题(例如,投标合同指定“预言机”——在本例中为 restakers ——指定了被 staked 并提供经济约束的 Token ——但是我们如何在共识之外削减此 Token 呢?虽然你可以在代码中编写削减标准,但这不在共识中,这意味着将通过智能合约使用社会削减(这几乎从未“公平”,并且可能导致问题)。这是 EigenLayer 当前削减的更大问题之一。

那么,这把我们带到哪里了?很可能在这样一种情况下,在我们获得链上“无需信任的”共识之外的削减之前,类似 SUAVE 的链可能需要其自己的共识算法和密码经济安全性,以证明投标偏好和构建区块的最终性——但是,这意味着添加更多的密码经济攻击向量,特别是如果它是为价值更高的 rollup 构建区块,远高于其自身的密码经济安全性。

除此之外,对于类似 SUAVE 的链和跨域 MEV 通常应该是什么样子,还有一个超级大的设计空间。以下只是一些可能的研究途径:

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

  • 多资产交易中的凸优化

  • DSL

  • MEV 重新分配

  • 延迟竞赛

  • 需要单组参与者为多个 rollup 的状态机构建而引发的缩放问题。

  • 偏好表达

在偏好表达方面,要与 EVM 中的智能合约交互,需要将合约调用(消息)发送到具有包含执行指令的已部署代码的地址上的特定函数。虽然用户提供输入,但由于潜在的有状态,他们可能无法控制输出。

相反,偏好表达设计系统(例如 SUAVE 和 Anoma)仅要求用户用绑定来签署偏好,如果满足搜索者的偏好,则会将该绑定支付给构建者和提议者。对于复杂的组合逻辑(例如 MEV 搜索者和构建者的交易排序),不同语言和虚拟机(Virtual Machines)的实现可能会有所不同。这是一种新的设计空间,最近受到了很多关注——尤其是在 Anoma 结构周围。我们建议查看 Anoma 架构here。并且强烈建议 这篇短文 ,作为 Haun 的 Breck 的开胃菜。


如果没有在这个特定垂直领域所做的出色研究,那么本文的大部分内容是不可能完成的。非常感谢:

此外,我们要感谢我们在整篇文章中引用的所有人员、项目和公司对该领域的贡献。

  • 原文链接: maven11.mirror.xyz/I12E6...
  • 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
点赞 0
收藏 0
分享
本文参与登链社区写作激励计划 ,好文好收益,欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
maven11
maven11
江湖只有他的大名,没有他的介绍。