通往基于应用程序（Based Application）的道路

关于基于(Based) Rollup 的讨论和兴奋很多。这是因为Based Rollup 是基于的。具体来说，它们允许应用程序坚持其底层层（+ 保持同步）——同时获得通常仅限于 Rollup 和应用链的几种超能力（同时衍生安全性）。这些包括定制化、MEV 内部化和专业化。我们之所以过去一般不谈Based Rollup，是因为过去的实现想法通常集中在过载提议者并将一切转变为单链上——这在这些高度去中心化的系统中不是可扩展的。此外，这些设定的用户体验（在缺乏预确认或软保证的情况下）也无法满足应用程序的需求。

在我们看来，目前关于Based Rollup 的教义已经有所改善。然而，重要的假设、潜在问题和中心化担忧依然存在。接下来，我们将简单概述一下过去计划Based Rollup 的工作方式、当前实现的工作方式，以及最终理想的协议外实现将会是什么样子（以及协议内的终局）。

在过去，Based Rollup 通常被认为是一种可能会昂贵、对现有提议者施加重大压力（使用户体验极差）或依赖常见以太坊参与者之外的行为者和中介的实现方式。这是因为关于让 L1 验证者主动对Based Rollup 交易进行排序和执行的讨论很多（基本上把它变成单链，尽管压缩发生在链外）。其他想法集中在选择性加入/退出，但在 MEV-Boost 之外，我们知道 MEV-Boost 负责大部分构建以太坊块——这使得协议外的主动整合变得更加困难。正如你稍后将看到的，我们认为“高效”Based Rollup 的首次实现很可能会发生在 MEV-Boost 的影响范围内，因为这使得整合和遵从性变得更加容易。

在以下的示例和提到的 Rollup 中，请记住压缩发生在链外（且发布到 L1 的数据以压缩形式进行）。我们对现有 L2 的那些处理这项工作的排序器已经相当习惯（而完整节点保持完整状态）。在Based Rollup 中，压缩工作是一个更大问题，因为在下面的 Taiko 示例中，任何人都可以执行此压缩。在 MEV-Boost 示例中，这通常由同时在Based Rollup 上运行完整节点的搜索者和构建者完成。这里需要指出的是，与任何其他区块链类似，运行完整节点的激励需要通过Based Rollup 的重大活动来创建。要么是 Rollup 上的活动量必须足够大，以致于有人愿意承担压缩工作，或者搜索者和构建者在这里变得活跃。或者在启动初期，他们必须获得额外激励。

就目前基于以太坊的Based Rollup 的实时实现而言，最明显的例子是 Taiko，它的运作方式与上面描述的相当不同。它的运作方式也与更多集成化（结束战局前）解决方案可能的外观相差甚远。下面我们概述了 Taiko 的运作方式：

当前Based Rollup 实现

Taiko 采用一个独立的 L2 内存池，搜索者在此参与即时（JIT）拍卖，以构建最有价值的 L2 批次，这类似于 L1 上的提议者-构建者分离（PBS）的运作方式。这些搜索者出价让他们的批次被 L1 块构建者纳入，后者选择最有价值的批次。这个模型可能导致 L2 块构建者竞争提取最大 MEV，反映了 L1 的 PBS。

在这个设置下，为了获得以太坊的同步性和可组合性，你需要领先的提议者和已知的前瞻子委员会参与Based Rollup 计划。目前情况并非如此，块/交易在理论上只是被强行纳入——这与当今 Rollup的中心化排序器非常相似。

最终，适合当前块构建管道的协议外Based Rollup 实现（MEV-Boost 旁车）将可能是实现大多数希望构建Based Rollup 的应用开发者所期望的属性的下一步。这些属性通常包括：

属性：

• 可组合性

• 原子包含；来自一个或多个行为者的保证，确保一组交易将包含在域中，或全部不包含。

• 原子执行 guarantees 确定执行的顺序（例如，通过前置/后置状态承诺）。这是实现应用之间可组合性所必需的。

• 同步可组合性；跨链合约调用。

  • L2 tx 条件于 L1 状态在今天是可能的；在反方向（L1-L2），你要么需要证明在排序时间状态是正确的（实时有效性证明），要么 L1 排序者组需要与 L2 相同（因此集成和抵押化可以实现）。

• 跨 Rollup 可互操作性

• MEV 保留/内部化

• 衍生以太坊安全性

• 定制化/专业化

• 分叉选择 - 公平排序

• 有效性条件（预言机、Gas代币等）

• 快速用户体验（带预确认）

值得一提的 MEV 保留/内部化的方面是，在大多数提议的设置中，以太坊验证者（包含权）仍然拥有相当大的权力，因为他们最终决定哪些内容纳入区块（哪些不纳入）。因此，他们会希望得到一些报酬。你几乎可以把 Rollup 看作当前范式中的搜索者（因此，可以从拍卖中衍生一些价值）。

目前以太坊（以及其他单一链）的状态很清楚的是，有大量应用程序渴望定制、专业化和 MEV 保留，同时获取以太坊的安全性（和同步性）。我们之前在文章中详细讨论了模块化设置的原因这里，以及我们最近在为何应用开发者将构建模块化的两次演讲这里和这里。MEV-Boost 旁车集成最终可能看起来像这样，请注意，这要求构建者与支持的 Rollup 集成（除非我们直接转到 MEV-Boost 中继一般设置，尽管这会失去上述很多能力）。构建者可能最终成为越来越强大的实体，这是我们稍后会讨论的。提议者也需要选择加入（就像他们当前在 MEV-Boost 中所做的那样），尽管如果运行这样的Based Rollup 旁车的提议者利润更高，则其他人也可能参与（因为大多数都是以盈利为目标）。

预确认 + Based Rollup 的 MEV-Boost 旁车集成

请记住，L2 牌照拍卖可能会提前进行（在于哪个 L1 提议者应该包含哪些 L2 块方面）。这是因为Based Rollup 网关协议需要确保提议者已选择加入Based Rollup 计划。网关会知道这一点，因为我们还具备当前/即将上线的验证者子委员会中的未来提议者的前瞻能力（并且可以看到谁已选择加入）。

目前已经有几个提案，涉及这些实现可能以何种方式在以太坊上结束的（无论是在预确认层面上，还是Based Rollup 配合的方式）：

针对Based Rollup：

• Spire

• Taiko/ Gwyneth

• Init4

针对预确认：

• Chainbound

• Primev

• Nethermind

• Commit-Boost

• Luban

然而，目前尚不清楚这将如何在所有 MEV-Boost 验证者和构建者参与中完全实现，但很明显这些事情正在来临，且是首先出现在核心协议外。

以太坊核心社区中也有明确的愿望要更好地支持Based Rollup。在这里，我们特别指的是希望实现单槽最终性（single slot finality）以及更快的块时间——这对Based Rollup 更加有利。这些事情与以太坊的大多数升级一样，发展时间比较长。而预确认/提议者承诺则已经在主网上和测试网上投入生产——虽然它们受到了社区成员的相当大反对（同样是中心化担忧——我们会在后面讨论这些）。

还有一些提供预确认的其他有趣想法，利用在单个 MEV-Boost 拍卖中部分块构建，通过在一个通常时间跨度内运行多个拍卖来实现。 在Linoscope提出的基于预确认的多轮 MEV-Boost中，设想你在 MEV-Boost 拍卖中有固定数量的 更快 轮次，其中构建（并签名）部分区块的有效负载，这个生命周期（来自提议者）的签名作为预确认。完整的区块（带有部分有效负载）将在正常时段结束时被正常传播。以上的XGA也使用类似的想法。然而，与分开一个拍卖的方式相比，他们把区块空间划分为两个车道——优先级和非优先级。这是为了提供一种能力（而不启用过多的 MEV）出售未来不太泄漏的区块空间——意味着验证者将出售对非优先区块空间（用于预确认）的访问。

Based Rollup 在 MEV-Boost 管道中的流程图

请记住，诸如削减、登记和定价等内容为简单起见将被排除在外。

一个如上图所示的预确认协议，可能类似于Spire团队在其预确认网关中所提议的；参见此处。提议者/预确认者（可能已委派排序者角色）通过以太坊提议者前瞻能力提前知晓。在前瞻中没有活动的旁车参与者的情况下，Based Rollup 可能使用备用机制来选择排序者。备用机制的其他用例（谢谢 mteam）还可能是观察到一名预确认旁车参与者被削减（或未提供抵押）。

虽然上述讨论的很大一部分集中在以太坊的复杂性以及其在提供Based Rollup 的平台上的道路，但还有其他网络可以支持它们。下面，我们将涵盖一些可以构建Based Rollup 的地方以及专门为其支持而构建的网络。

在可以支持（并且旨在支持Based Rollup 的）网络方面，有相当多的选择。特别值得注意的是共享排序器，它们本质上是为排序（基于）Rollup 提供排序的网络：

• 共享排序器

  • Astria

  • Espresso

  • Radius

  • Nodekit

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

  • Celestia

  • Avail

• 快速单块链

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

总结来说，Based Rollup 是：

一个离链状态机，通过将其块的排序委托给底层层（及其提议者）。排序者通常是拍卖或领导者选举的赢家（例如以太坊的子委员会及其后续插槽）。在大多数情况下，为了避免过载，排序者可能是成分的提议者（属于底层层的集合），负责纳入；同时，将执行、约束和构建 Rollup 块的工作外包给更复杂的行为者（构建者）——类似于 MEV-Boost。

要求和属性

现在我们已经讲到了Based Rollup 的“什么”，值得花些时间来讨论“如何”。现在启动Based Rollup 并没有什么错，但为了真正以可比拟于非Based Rollup 的方式支持它们，还需要在基础层上或周围进行相当多的变化。

显然，在一条更适合的链（比方说块时间更快的链）上推出Based Rollup 是非常合理的。然而，由于我们显然希望利用以太坊的去中心化、抗审查能力和用户连同其流动性，这里需要进行一些变更。

虽然在 Solana 上开展Based Rollup 很有道理，因为它快速/连续的插槽，但也需要进行一些变更（例如旁车）以处理同步功能，以实现同步可组合性。在这里与 Jito 互动（类似于 MEV-Boost）可能会对拍卖和委托有很大意义。

我们已经提到了一些上面的要求，但让我们尽量涵盖一些我们认为针对以太坊、Solana 和 Celestia 上Based Rollup 时的关键要求。

对于以太坊，要求（以满足良好的用户体验并获得进一步概述的属性）：

• 预确认

  • 纳入保证

  • 执行保证

  • 协议内/外

• 通过旁车将Based Rollup 集成到块构建管道（MEV-Boost）中，配合预确认

  • 自定义块有效性规则

  • 超级构建者

  • 保障的范围（排序/验证）

  • 同步的旁车

• 不对以太坊共识过载（因此以上保障）

• 非构建者+中继完整节点运行者

• 更快的块时间（Vitalik 最近推动 2-4 秒，但是；要实现这一点，我们可能需要对协议规范和共识进行重大变更——更快的块时间也会使预确认变得不那么重要，但方案内的整合确实有助于提升同步性）。

• 请记住，12秒的块时间是最坏的情况，大多数用户在插槽开始时并不会发送交易（考虑到延迟和 MEV-Boost 内交易未接受的时间，中位数纳入时间在 7 秒左右）。

对于 Solana，该链实际上非常适合支持Based Rollup。它具有“快速”（在这种情况下是连续）块时间，从而提供快速确定性共识（在没有预确认的情况下，这是一个理想属性）。但这里仍然存在一些问题，例如：

• 集成到 Jito 不断增长的块构建管道中

• 同步功能和同步性的旁车

• 不对 Solana 验证者过载（已有的重负担要求）

  • 超级构建者？

• 块构建管道的去中心化

顺便提一下，我们已经在 Solana 上看到基于结构（ZK 压缩）推出，伴随着对实现/构建 Rollup 项目的新的兴趣和资金。ZK 压缩在某些方面像基于 ZK-validium。这通常是因为尽管 Solana 显然是一个极其高效的单个状态机，但它正在变得相当臃肿——且应用程序无法控制定制化，也没有 MEV 内部化的控制。

对于 Celestia，许多属性非常适合Based Rollup。它与轻客户端易于验证，有丰富的区块空间及提供共识的“懒惰”基础层。要使它对Based Rollup 更加友好，仍需要进行一些变更：

• 提高块时间以改善用户体验，并且在预确认缺失的情况下

• Based Rollup 互操作性的标准（最好是原子性）

• ZK 账户以提高基础层资产流动性（最好与实时证明结合）

排序或不排序

如上所述，基于排序的实现存在一个相当广泛的范围（协议内或外），以实现同步。在当前（及旧）话语中，这个范围非常相关，因为它很适合“不要过载以太坊共识”的原则以及质押者的优雅。能够可靠执行和排序（来自整个或一个子委员会）的实现将很容易导致以太坊的过载。因此，我们认为深入讨论这个主题是非常重要的：

• 基于排序

  • 排序由底层层的提议者子集（或全部）执行——这意味着他们需要运行执行完整节点并主动构建区块。

  • 会给验证者带来状态膨胀、硬件要求和垂直扩展的负担。

  • 可能会委托给专业化角色——超级构建者的崛起。

• 基于验证

  • 排序由专业化的构建者执行，他们在块构建、约束和定价方面具备专业技术。

  • 纳入保证由最初的提议者提供，提议者可能会在后期验证执行的有效性（这很可能仍会过载当前提议者规范，并且我们可能只会得到如下所述的纳入保证）。

  • 在一个完美的世界里，L1 提议者会足够聪明以处理所有负载（网络/计算），并运行 L2 节点。然而，这不太可能，它会被其可能的不可用性强化，以致于无法自行为预确认/ Based Rollup 块定价。因此，委托。

给我确认

此外，正如我们也观察到的那样，至少在更快的块出现之前，确实需要预确认。关于如何实现这一点仍有很多讨论，但这里显然是值得考虑的。作为提醒，预确认是提议者或有能力在指定时间锁定状态或提供访问的代理角色所做的关于未来纳入或执行的承诺。在Based Rollup 中，这具有重要意义，因为提议者可以提供保证，确保Based Rollup 的区块最终会被执行/纳入。显然，在这种安排中，检查系统会对参与者施加例如债券削减 的重大风险，以确保承诺得到遵守。最好这一过程在协议内进行，因为协议外则会退回到一个小部分人而非整个协议的社会共识方式进行社会削减。

• 纳入保证

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

  • 确保区块/交易将被包括在一个区块中（但不能确保它们会被执行客户端执行）或放到特定顺序中。

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

  • 更易于定价。

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

• 执行保证

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

  • 对提议者施加沉重负担。

  • 准确定价的难度。

  • 如果考虑Based Rollup 可以同时触及以太坊 L1 状态——则应用程序的可组合性需要执行保证。

现在，虽然在该应用中，预确认在应用中使用的范围比较有限，但通常范围非常广泛，可以提供相当灵活的基础层功能以支持提议者承诺。当前的提议者承诺（在预确认/承诺旁车之外）仅限于在区块构建（意味着每 12 秒）时对状态的确认。然而，已经有一些协议外承诺方案（如 Chainbound），可使提议者对其特定区块提出承诺，同时支持纳入预确认这一关键Based Rollup 的属性。正如上述所阐明的是，我们对此充满热情。如果你对协议外的预确认感兴趣，我们强烈建议观看此 Chainbound 团队的演讲。

预确认旁车

除了更快的块时间带来更好的用户体验外，预确认还可以为许多关键点提供额外的支持（超出Based Rollup 的用途）。例如：

• 求解者（Solvers）/链抽象用户体验

• MEV 缓解/捕获

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

提议者承诺的终局相当广泛，而总体思想是它们能够支持更多的用例，例如：

• 部分块构建（多个并行提议者）。

• 状态预确认（同步性/同步功能） + 取消。

• L1 块空间拍卖和索赔。

在协议内的承诺及其区块提议权方面，正在讨论多个提议和实现，如协议强制提议者承诺（PEPC）和执行票（ET）（ + 验证者-提议者分离（APS））。执行票（ET）正受到重点关注，因为它们将允许出现一个协议内市场（彩票），用于购买区块提议权。关于 APS 的构想是将 L1 验证者角色分为两部分——执行和信标（共识）提议者。前者将负责对区块有效载荷进行提议（这可能会外包给构建者，或让构建者发挥此角色），而后者（信标或验证者）负责投票设定区块有效性规则（这在处理Based Rollup 区块时尤其重要，因为会提出更多规则）并通过纳入列表来限制执行权力。这可能特别是在一个超级构建者和关于预确认和Based Rollup 的中心化关注的情况下，提供更高的抗审查能力。如果你对预确认的历史（请查看此处）。

它们正在变得庞大

超级构建者

正如你在这篇文章中可能已经注意到的，有大量的委派和外包给更专业化的角色要么为避免过载，要么为确保更好的市场效率。这意味着，且自从以太坊起，这已经发生了一段时间——将最繁重的工作交到构建者（高效能实体）的手中。这导致产生了“超级构建者”一词。当前在 MEV-Boost 管道中的构建者组也可能在协议（和协议外）中承担重要角色，担任Based Rollup、预确认和承诺的任务。

原因非常明确，我们不想增加以太坊的共识压力。我们无法要求每一个提议者都具备特殊化能力，或能够做到这一点。这是市场力量的一般作用，但会导致中心化，进而带来许多风险。目前这已是现实，今天的以太坊区块中，由三个构建者构建了大多数块，其中两个（Titan 和 Beaverbuild）几乎占据了 80% 的构建份额！今日提议者同样与中继方存在极为信任的关系（希望随着 ePBS 的发展这会有所减轻，但这仍未明朗）。

在Based Rollup 的情况下，构建者将在 Rollup 上运行完整节点以执行排序、保障执行和块构建。同时，他们在预确认层面需要能够对这些区块/捆绑进行精确定价（一些构建者可能将此预确认定价外包给搜索者）。纳入保证的预确认更容易定价，而执行保证则需要显著的专业技术，仍然是一个悬而未决的问题。

在Based Rollup 的背景下，超级构建者一般被认为是不会仅为单一链（以太坊）而构建，而是为多个链（以太坊 + Rollup 生态）服务的专业化行为者。这是必要的，尤其是当我们希望实现区块内同步性和跨领域的 Rollup 可互操作性。某种程度上，你也可以将 Optimism 的超级链排序者/构建者视为 OP-Stack 链的超级构建者，以及 Astria/Espresso 的去中心化排序网络（但在多客户端竞争的情况下，并不单独由一个领导者操控）。委派给构建者的一个有趣方面是，多个 Rollup 的票证持有者可以为这些域提供同步可组合性的纳入保证。

超级构建者及其载荷

“超级构建者”一词还可以被用来描述他们可能接手的“课外”活动（即建筑块之外的其他责任），如承诺和预确认。

在所有这些情况下，尤其是由于日益增加的委托工作，构建者大概率需要大量的债券（抵押）。理想情况下，委托给他们的很多功能也应该能够在链上（协议内）证明，以确保公平、强大和正确的削减。这意味着构建者的横向扩展正在增加（Justin Drake 顺便提到他们对此毫不在意？）。这里当然也存在许多担忧，比如跨块的 MEV，一个构建者可能为远比其他所有构建者更多的 Rollup 构建块（或在提取 MEV 上更具优势），并可能始终在出价上压倒其他所有合作者。这种进一步的复杂化与优化也将进一步导致中心化及新参与者更高的进入门槛（除非他们是 Citadel）。有一点似乎非常明显的是，至少在一个更推动构建者的世界中，纳入列表（IL）显然是大为需要的。

这一切之上，工作量的流向正在越来越多地转向链外/私有的顺序流。与独家供货提供线路的构建者相比，没有这些供给的构建者表现不如，显然，这些资源将能够在任何Based Rollup 的集成中获取最大利益。对于某些应用程序（或 Telegram 机器人）可能具有的 Rollup 并且同时也有独特流向构建者的现象，可能会引发忧虑。Burak Öz，Danning Sui，Thomas Thiery，Florian Matthes 在他们最近的论文 _谁赢得以太坊区块建设拍卖，为什么？_中充分指出了这些问题，特别是关于上面提到的高产业壁垒问题。

有趣的一点是，尽管增大构建者负担的同时，在利益分配方面，他们（至少在链上）所获取的最少。尽管由于三个关键构建者中的两个同时也是交易公司，搜索者的利润自然高度倾向于他们。即便是非交易构建者也可能与搜索者达成收益分享协议，因为他们不会对其流进行交易。当前正如Yuki（Sorella/Fenbushi）所指出的，MEV 的非 MEV 利润分配大致相等，应用程序留下的大量利润往往落入提议者手中。

一件显而易见的事情是，允许/能够捕获（意味着内部化）自身/他人 MEV 的应用程序（或项目）存在巨大的机会。显然，在这个时代，随着链上经济活动的增加，这将意味着他们能够优于无此能力者。这些被遗留下来的边际将为允许应用程序变得更好和更高效的协议提供机会。

应用将如何在Based Rollup 上构建？

如之前提到的那样，你用Based Rollup 构建应用程序的原因有很多，特别是如果你已经在底层层中占据一席之地。让我们举一个例子，看看一个应用程序如何可以在Based Rollup 部署，同时保留它在 L1 上的现有合约。

在 Uniswap 的情况下，你可以让Uniswap 路由器存在于Based Rollup 中，并让应用通过 Rollup 发起调用（这意味着 Uniswap 很可能希望内部化运行中的一部分流量）。例如，一个希望触及 L1 Uniswap 流动性的意图协议，必须通过Based Rollup 的路由器进行调用。

基于 Uni-chain

这同样可能伴随着持续性，产生Based Rollup 行为的函数，该函数可以在 L1 上实施。这很有意义，因为应用程序可以访问 （至少是只读）以太坊，并且未来或许可以实现其智能合约之间的调用。这是 Uniswap 所希望的，因为许多应用程序在每个区块每次都会调用它的路由器/合约（考虑到大多数意图协议及其它许多）。 Aave、Maker 同样如此。

在 Uniswap（以及任何其他希望内部化其 MEV 收入的应用）选择排序者时，它会选择一个愿意支付序列一块区块的排序者——这将意味着返回一些价值给该应用。在有少数这种类型行为者的情况下，达成可回报的总价值精确的概率较低，除非所有参与者都是相对具备信息对称，并且能够全部出价最高限度（不过在这种情况下会预期会发生一些串通行为）。

未来研究与结束思考

• 如整个文章所示，对于这一切最终将转变为怎样，我们如何影响我们今天使用的各类协议，存在显著的假设。时间表也不明确，尤其是与某些内部体系的事情相关。

• 然而，清楚的是，在发达的单链上，存在着庞大的应用生态期望进行定制、内部化和衍生安全性，同时期望实现可组合性。

• 针对特定应用的无序排序（例如参见我们的排序文章）-不仅限于 MEV 内部化，还包括可验证排序规则、频繁批量拍卖、公平排序等。

• 针对 Rollup 特定的分叉选择规则（调价只限于获准的有效块定价更新）。

• 最优块有效性（超出最高费用），可能相当任性（这与最大化价值不同）。

• 块构建者的复杂化与横向扩展需要进一步研究关于危险性（ + 多块 MEV、块投标）；特定操作码/Gas限制/虚拟机/分叉选择规则的特殊化会如何变化。

• 部分块构建 + 多隔离提议者并行构建。

• 通过协议中外的纳入列表限制块构建者。

• 在未集成构建者的定价即有外部代理时若委托（外包给搜索者？）。

• Rollup 支付订单流的形式。

• 持续的块构建（例如在 Solana 上）。

• 时机博弈和影响（+ 验证者错误头投票）。

• • *

如果你是一款目前位于单链上的应用程序，并且希望探索可以如何开始利用模块化的诸元素（正如我们过去一年多次提到的那样），同时保持与底层层的兼容性，请随时与我们联系。

进一步阅读：

• https://research.chainbound.io/examining-the-based-sequencing-spectrum

• https://ethresear.ch/t/based-preconfirmations/17353

• https://mteam.space/eth-sequencing-preconfs-resources/based_rollups.html

• https://github.com/spire-labs/poc-monorepo

• https://ethresear.ch/t/based-rollups-superpowers-from-l1-sequencing/15016

• https://scalability.guide/posts/forced_vs_based/

• https://blog.20squares.xyz/preconfirmations-splitting-the-block/

• https://mirror.xyz/preconf.eth/3SXageNPpcQMz8L2YfW5ipvthNl-InPzaPAfb3LxwqA

• https://vitalik.eth.limo/general/2024/06/30/epochslot.html

感谢 Mathijs van Esch（Maven11）和 mteam（Spire）进行审核。

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