基于应用程序的道路

avatar
The Weekly Depths
08-02
本文为机器翻译
展示原文

如果你想传播这篇文章，请随意与此主题互动

关于基于 rollups 的讨论和兴奋很多。原因很简单，基于 rollups 就是基于的。具体来说，它们允许应用程序坚持使用其底层（+ 保持同步性）——同时获得通常为 rollups 和应用链保留的几个超能力（同时获得安全性）。这些是定制、MEV 内部化和专业化等。我们过去通常很少谈论基于 rollups 的原因是，过去的实施思想通常集中在使提议者过载并将所有内容变成单一链上——这在这些超去中心化系统中是不可扩展的。此外，这些设置的用户体验（在没有预先确认或软保证的情况下）根本无法满足应用程序的需求。

我们认为，目前围绕基于汇总的教条已经变得更好。然而，重要的假设、假设和中心化问题仍然存在。下面，我们将简单概述过去基于汇总的计划如何工作、当前实现如何工作，以及最终理想的协议外实现将是什么样子（以及协议内的最终结果）。

过去，人们普遍认为基于 rollup 的实现方式要么成本高昂，要么给现有提议者带来巨大压力（并提供糟糕的用户体验），要么依赖于以太坊普通参与者范围之外的参与者和中间人。这是因为有很多讨论专门围绕让 L1 验证者也积极排序和执行基于 rollup 的交易（本质上将其变成一条链，尽管压缩发生在链下）。其他想法集中在选择加入/选择退出，但在 MEV-Boost 之外，众所周知，MEV-Boost 负责大多数构建的以太坊区块 - 这使得协议外的主动集成更加难以管理和获得关注。正如您稍后会看到的那样，我们相信至少“高效”基于 rollup 的首次实现可能会在 MEV-Boost 的影响范围内发生，因为它使集成和一致性变得更加容易。

在下面的任何示例和提及 rollup 时，请记住压缩发生在链下（发布到 L1 的数据以压缩形式进行）。我们已经非常习惯于现有的 L2，它们的序列器处理这项工作（完整节点保持完整状态）。在基于 rollup 的 rollup 中，压缩工作是一个更大的问题，因为在下面的 Taiko 示例中，任何人都可以进行这种压缩。在 MEV-Boost 示例中，这很可能由在基于 rollup 上运行完整节点的搜索者和构建者完成。这里需要注意的一点是，与任何其他区块链类似，运行完整节点的动机必须由基于 rollup 上的显著牵引力来创造。rollup 上的活动量必须足够大，以便有人进行压缩工作，或者搜索者和构建者在那里活跃起来。或者在初始引导阶段，他们必须得到额外的激励。

就迄今为止以太坊上基于 rollup 的实时实现而言，最明显的例子是 Taiko，其功能与上面描述的有很大不同。它的运作方式也与更集成的（终局前）解决方案完全不同。我们在下面概述了 Taiko 的运作方式：

Taiko 采用单独的 L2 内存池，搜索者参与即时 (JIT) 拍卖以构建最有价值的 L2 批次，类似于 L1 上的提议者-构建者分离 (PBS) 操作方式。这些搜索者竞标让他们的批次被 L1 区块构建者收录，后者选择最有价值的批次。此模型可导致 L2 区块构建者竞相提取最大 MEV，与 L1 PBS 类似。

在此设置中，要获得以太坊的同步性和可组合性，您需要领先的提议者和已知的前瞻性子委员会成为基于汇总方案的参与者。目前情况并非如此，理论上，区块/交易只是被强行加入 - 这与当今汇总的中心化排序器非常相似。

最终实现基于 Rollup 的协议外实现，使其适合当前的区块构建管道 (MEV-Boost sidecar)，并实现全面参与，这可能是实现大多数希望构建基于 Rollup 的应用程序开发人员所寻求的属性的下一步。这些属性通常是：

特性：

关于 MEV 保留/内部化方面，值得一提的是，在大多数提议的设置中，以太坊验证者（纳入权力）仍然拥有相当大的权力，因为他们最终决定什么可以进入区块（什么不能）。因此，他们会希望得到一定数额的报酬。你几乎可以将 rollup 想象成当前范式中的搜索者（因此，可以从拍卖中获得一些价值）。

从以太坊（和其他单片链）的现状可以清楚地看出，有大量应用程序渴望定制、专业化和 MEV 保留，同时实现以太坊安全性（和同步性）。我们之前已经在这里和 这里 的文章中深入介绍了模块化设置的原因，以及我们最近在这里和这里做的关于应用程序开发人员为什么要构建模块化的两场演讲。

 MEV-Boost 侧边车集成最终可能会看起来像这样，请记住，这要求构建者与受支持的汇总集成（除非我们直接采用 MEV-Boost 中继式设置，尽管这会失去上述许多权力）。构建者最终可能会成为越来越强大的实体，我们稍后会讨论这一点。提议者也必须选择加入（就像他们目前对 MEV-Boost 所做的那样），尽管如果运行这种基于汇总的侧边车的提议者的利润更高，那么其他人也可能会参与（因为大多数追求利润）。

请记住，L2 票证拍卖可能会提前完成（就哪个 L1 提议者应该包含哪个 L2 区块而言）。这是因为基于汇总的网关协议需要确保提议者已选择加入基于汇总的方案。网关会知道这一点，因为我们还可以预测当前/即将到来的验证者小组委员会中的未来提议者（并且可以看到谁选择了加入）

目前已经出现了一些关于如何在以太坊上实现这一实现的提案（既包括预先确认层面，也包括基于汇总的适用方式）：

对于基于汇总：

对于预先确认：

然而，目前还没有明确的观点表明这将如何全面实施（如所有 MEV-Boost 验证者和构建者都参与其中），但很明显这些事情即将到来，而且它们将首先出现在核心协议之外。

以太坊核心社区内部也明显希望更好地支持基于汇总。这里我们特别指的是希望单槽最终性，但同时也希望更快的出块时间——这更适合基于汇总。与以太坊上的大多数升级一样，这些事情还很遥远。另一方面，预确认/提议者承诺已经在主网和测试网上投入生产——尽管他们受到了社区成员的强烈反对（再次强调，集中化问题——我们将在后面进一步讨论这些问题）。

还有一些其他有趣的想法（提供预确认），它们利用在单个 MEV-Boost 拍卖中构建部分区块，方法是在通常的拍卖时间范围内运行多个拍卖。在Linoscope （Nethermind）的基于多轮 MEV-Boost 的预确认中，其想法是，在 MEV-Boost 拍卖中，您有固定数量的更快轮次，您可以在其中构建（并签署）部分有效载荷（区块），此签名（来自提议者）充当预确认。然后，完整区块（带有部分有效载荷）在正常时段结束时正常传播。上面的XGA也使用了类似的想法。但是，他们没有将一个拍卖分成多个拍卖，而是将区块空间分成两个通道 - 优先和非优先。这样做是为了提供出售未来泄漏较少的区块空间的能力（而无需启用太多 MEV） - 这意味着验证者将出售对非优先区块空间的访问权限（用于预确认）。

请记住，为了简单起见，削减、注册和定价等内容被排除在外

如上图所示，预确认协议可能类似于Spire团队在其预确认网关中提出的协议； 请参阅此处。通过以太坊提议者前瞻，可以提前知道提议者/预协商者（可能已委托排序者角色）。如果前瞻中没有活跃的 Sidecar 参与者，则基于 Rollup 可能会使用回退机制来选举排序者。回退机制的其他用例（ h/t mteam ）也可能是如果预协商 Sidecar 中的参与者已被削减（或没有抵押品）

虽然以上大部分内容都集中在以太坊的复杂性及其为 based rollup 提供平台的道路上，但也有其他网络可以支持它们。下面，我们将介绍一些可以构建 based rollup 的地方以及专门为支持它们而构建的网络。

就能够支持（并且是为了支持基于 rollups 而构建的）网络而言，有相当多的网络。这里特别值得注意的是共享排序器，它本质上是用于对（基于）rollups 进行排序的网络：

  • 共享序列器

    • 阿斯特里亚

    • 浓咖啡

    • 半径

    • 节点套件

  • 数据可用性层（带共识）

    • 塞拉斯蒂亚

    • 可用性

  • 快速整体式

    • Solana（大型生态系统 + 允许高效汇总的属性）

总而言之，基于汇总的内容包括：

一种链下状态机，将其区块的排序委托给底层（及其提议者）。排序者通常是拍卖或领导者选举的获胜者（例如以太坊的子委员会及其后续席位）。在大多数情况下（为了避免过载），该排序者可能是负责纳入的提议者（这是底层集合的一部分）；同时它将 rollup 区块的执行、约束和构建委托/外包给更复杂的参与者（构建者）——ala MEV-Boost。

要求和属性

既然我们已经介绍了基于汇总的内容，那么值得花些时间介绍一下如何操作。现在推出基于汇总显然没有错，但必须对基础层进行相当多的更改，才能真正支持它们，使它们与非基于汇总相媲美。

显然，将 rollup 建立在更适合自己的链上（例如出块时间更快的链）是非常有意义的。但是，由于我们显然有兴趣利用以太坊的去中心化、审查阻力和用户以及流动性，因此这里需要进行相当多的改变。

虽然基于 rollups 在 Solana 上也非常有意义，因为有更快/连续的 slot，但需要对同步函数进行更改（即 sidecar），以处理同步可组合性。这里与 Jito 的一些交互（例如 MEV-Boost）对于拍卖和委托来说可能也很有意义。

我们已经提到了上面的一些要求，但让我们（尽我们所能）涵盖所有我们认为基于以太坊、Solana 和 Celestia 的汇总的关键要求。

对于以太坊来说，要求（为了获得适当的用户体验和获得上面概述的属性）：

对于 Solana 来说，该链实际上非常适合基于支持的汇总。它具有“快速”（在这种情况下是连续的）出块时间，这提供了快速的确定性共识（在没有预先确认的情况下，基于汇总的汇总所需的属性）。但是，这里仍然存在一些问题，例如：

顺便提一下，我们已经看到类似基础结构（ZK Compression）在 Solana 上上市，同时人们对在 Solana 上启用/构建汇总的项目重新产生了兴趣并获得了资金支持。ZK Compression 在某些方面与基于 ZK-validium 的工作原理非常相似。这通常是因为，尽管 Solana 显然是一种极其高效的单一状态机，但它变得相当臃肿——而且应用程序没有自定义控制，也没有 mev 内部化。

对于 Celestia 来说，实际上有很多属性非常适合基于汇总。轻客户端的可验证性、充足的区块空间和提供共识的“惰性”基础层。有一些变化会使其更适合基于汇总：

按顺序还是不按顺序

如上所述，有相当多的方法可以实现基于排序的本地（或协议外）同步。这个范围在当前（和更早）的讨论中非常相关，因为它非常符合“不要使以太坊共识超载”和 homestaker 的优雅。许多允许执行和排序保证（来自整个或小组委员会）的验证者的实现将极大地超载以太坊共识。因此，我们发现有必要更多地讨论这个主题：

答应我，我只是需要确认

此外，正如我们所见，至少在加速区块之前，需要进行预先确认。关于如何实施这一点仍存在很多争论，但这肯定值得考虑。作为回顾，预先确认是由提议者或委托参与者提供的关于未来纳入或执行的承诺，他们有能力在指定时间锁定或提供对状态的访问。在基于 rollup 的网络中，这很重要，因为提议者可以保证 rollup 区块最终会被执行/纳入。显然，在这种方案中，可能会对参与者施加大量削减保证金，以确保承诺得到履行。这是协议内的理想世界，因为协议外会恢复为由一小部分人而不是整个协议的社会共识进行的社会削减。

  • 包容性保障

    • 委托执行、区块构建和排序

    • 保证区块/交易将被包含在一个区块中（但不保证它们将被执行客户端执行）或按特定的顺序排列

    • 无法确保应用程序之间的可组合性

    • 更容易定价

    • 外包排序器（构建者）和提议者的合作（中继可能发挥通常的作用，尽管这里的压力也可能很大）

  • 执行保证

    • 实时有效性证明或抵押。

    • 给提议者带来沉重压力

    • 定价更难

    • 重要的是，我们认为基于 rollups 可能会同步触及以太坊 L1 状态 - 其中应用程序的可组合性需要执行保证

虽然目前预确认的使用非常有限，但其应用范围非常广泛，可以为提议者承诺提供相当灵活的基础层。提议者承诺的当前属性（预确认/承诺边车之外）仅限于区块构建时的状态确认（即每 12 秒一次）。但是，已经有一些协议外的承诺方案（例如 Chainbound），可以使提议者向其他人发出有关其特定区块的承诺，同时支持包含预确认中的基于密钥的汇总属性。如上所述，这是我们非常渴望拥有的。如果您对协议外的预确认感兴趣，我们强烈推荐Chainbound 团队的这次演讲。

除了更快的区块速度以实现更好的用户体验之外，预确认还能带来其他关键点（除了用于基于汇总之外）。例如：

提议者承诺、票证和证明者

提议者承诺的最终目标非常广泛，总体思路是他们将能够支持更多的用例，例如：

在协议内承诺和区块提案权方面，有几项提案和实施方案正在讨论中，例如协议强制提案人承诺 (PEPC)和执行票证 (ET) (+证明者-提案人分离 (APS) )。ET 受到广泛关注，因为它们将允许在协议内市场 (抽签) 购买区块提案权。APS 的想法是将 L1 验证者角色分为两个独立的角色 - 执行者和信标 (共识) 提案者。前者的任务是提议区块有效载荷 (这方面的构建很可能外包给建设者，或者我们让建设者来扮演这个角色)。后者 (信标或证明者) 的任务是投票确定区块有效性规则 (对于基于汇总的区块尤其重要，因为可能会概述更多规则) 并通过包含列表限制执行权。这很可能（尤其是在超级建造者和围绕预确认和基于汇总的集中化问题的世界中）提供更高的审查抵抗力。如果您对预确认历史感兴趣（请查看此处）。

它们越来越大

超级建筑师

您可能已经注意到，为了避免超负荷或确保更好的市场效率，很多工作被委托和外包给更专业的参与者。这意味着，以太坊上已经发生了一段时间了，而它导致的结果就是，将大部分繁重的工作交给建设者（高度复杂的实体）。这导致了所谓的“超级建设者”的出现。MEV-Boost 管道中的当前建设者群体可能也将在协议内部（和外部）发挥关键作用，以进行基于汇总、预确认和承诺。

原因很明显，我们不想让以太坊的共识超载。我们无法要求每个提议者都如此专业，他们也没有能力做到。这是普遍的市场力量，但它确实会导致集中化，并带来许多风险。这在今天已经生效，目前有 3 个构建者构建了绝大多数以太坊区块（其中两个，Titan 和 Beaverbuild，构建了近 80%！）。今天的提议者也与中继者有着极其信任的关系（希望随着 ePBS 的进步，这种关系会有所减弱，尽管目前还不清楚）

出于排序、执行保证和区块构建的原因，构建者（在基于汇总的情况下）可能会在汇总上运行完整节点。同时，他们需要能够（在预协商的情况下）正确定价这些区块/捆绑包（一些构建者可能会将这种预协商定价外包给搜索者）。纳入保证预确认的定价要容易得多，而执行保证则需要相当复杂的技术，这仍然是一个悬而未决的问题。

关于基于 rollups 的话题，超级建造者通常可以被认为是一个专门的参与者，他不是为单个链（以太坊）建造，而是为一组链（以太坊+Rollups）建造。这是必要的，特别是如果我们想要块内同步性和跨域 rollup 互操作性。在某种程度上，你也可以将 Optimism 的超级链排序器/建造者视为 OP-Stack 链的超级建造者。以及 Astria/Espresso 的去中心化排序器网络（但如果没有单一领导者，则更多是多并发）。委托给建造者的一个有趣方面是，多个 rollups 的票证持有者可以为这些域之间的同步可组合性提供包含保证。

超级建设者这个术语还可用于指他们在原有职责（构建模块！）之外可能从事的课外活动，例如承诺和预先确认。

在所有这些情况下，我们可能需要为建造者提供大量债券（权益），尤其是委托给他们的工作越来越多的情况下。最好是，外包给他们的许多功能也应该在链上（协议内）可证明，以确保公平、稳健和正确的削减。这标志着建造者方面的横向扩展增加（Justin Drake 随口说他们对此没意见？）。这里有很多令人担忧的地方，比如多块 MEV，建造者建造的汇总数量远远超过其他所有人（或更擅长提取 MEV），以及可能持续出价高于所有其他建造者。与所有事情一样，这种进一步的复杂化和优化也将导致进一步的中心化和新参与者的更高进入门槛（除非他们是 Citadel）。有一件事似乎很清楚，那就是在建造者拥有更多权力的世界中，至少迫切需要包含列表 (IL)。

除此之外，流量正越来越多地转移到链下/私人订单流。拥有独家供应商（以及集成供应商）的构建者比没有的构建者做得好得多，而这少数人也有可能从任何基于汇总的集成中获利最多。在某些应用程序（或 Telegram 机器人）可能拥有汇总并且还拥有流向构建者的独家流量的情况下，这也可能令人担忧。Burak Öz 、 Danning Sui 、 Thomas Thiery 、 Florian Matthes在他们最近的论文《谁赢得了以太坊区块构建拍卖以及原因？》中很好地强调了这些问题，尤其是围绕上面提出的高进入门槛问题。

有趣的是，对于这种给建造者增加的工作量，在利润分配方面，他们（至少在链上）获得的利润最少。尽管由于三个主要建造者中的两个也是道具店，搜索者的利润显然也大部分属于他们。即使是非交易建造者也可能与搜索者达成收入分成协议，因为他们不在搜索者的流量上进行交易。目前，正如Yuki （Sorella/Fenbushi）所指出的那样，MEV 与非 MEV 的利润大致平均分配，有大量利润留给了应用程序，而这些应用程序往往最终落入提议者的手中。

它确实非常清楚地表明了一件事，那就是允许/能够捕获（即内部化）自己/他人的 MEV 的应用程序（或项目）拥有巨大的机会。显然，在当今时代，随着链上经济活动的数量增加，这很可能意味着他们可以胜过那些无法做到这一点的人。这些剩余的利润空间是协议的机会，这些协议可以让应用程序变得更好、更高效。

应用程序如何在基于汇总的基础上构建其应用程序？

如前所述，将应用程序构建为基于 Rollup 的原因有很多，特别是如果您已经在底层扎根并部署。让我们举一个例子，说明应用程序如何作为基于 Rollup 启动，同时保留其在 L1 上的现有合约。

对于 Uniswap 来说，你可以让Uniswap Router运行在基于 rollup 中，并让应用程序通过 rollup 进行调用（这意味着 Uniswap 有望通过拍卖将部分流经它们的流量内部化）。例如，想要接触 L1 Uniswap 流动性的意图协议必须通过基于 rollup 上的路由器进行调用。

这可能还会与同步性一起发挥作用，以便基于 rollup 操作创建可在 L1 上执行的函数。这将很有趣，因为应用程序可以访问（至少读取）以太坊，并且将来可能调用其智能合约。这是 Uniswap 尤其想要的，因为许多应用程序在每个区块都会调用其路由器/合约（想想大多数意图协议和许多其他协议）。Aave、Maker 等也是如此。

在 Uniswap（以及所有其他希望内部化其 MEV 收入的应用程序）如何选择排序器的情况下，它很可能是愿意为排序区块付费的排序器——这意味着向应用程序返回一些价值。在只有少数此类参与者的世界中，它达到可能返回价值的确切总额的可能性非常低，除非所有参与者之间具有完全的信息对称性，并且能够全部出价到上限（尽管此时你会预计会开始发生一些勾结）。

未来研究和总结

如果您的应用程序目前运行在单片单链上，并且您有兴趣探索如何开始利用模块化的各个方面（正如我们在过去一年中多次提到过的那样），同时保持可组合性并与底层保持一致，请随时与我们联系。

进一步阅读：

感谢 Mathijs van Esch (Maven11) 和 mteam (Spire) 的审阅。

相关赛道:
元宇宙
Play To Earn
Layer 1
来源
免责声明：以上内容仅为作者观点，不代表Followin的任何立场，不构成与Followin相关的任何投资建议。
喜欢
1
收藏
1
评论
相关推荐