模块化系统的隐性成本

编者注：本篇文章是技术扩展创造社会扩展的精神继承者。 单击 [此处]（https://multicoin.capital/2021/05/25/technical-scalability-creates-social-scalability/"Technical Scalability Creates Social Scalability"）即可阅读。

在过去两年里，扩展之争已经缩小，并集中在模块化与集成的核心问题上。

（请注意，加密对话通常将“单片”和“集成”系统混为一谈。 在过去 40 年里，就堆栈每一层的集成系统和模块化系统在科技领域的[争论历史悠久]（https://www.google.com/search?q=stratechery+modular+integrated "Monolithic vs. Integrated History of Debate"）。 这种对话的加密化身应该通过相同的镜头来构建；这远不是一场新的辩论）。

在思考模块化和集成时，区块链可以做出的最重要的设计决策是向应用程序开发人员暴露堆栈的复杂程度。 区块链的客户是应用程序开发人员，因此最终应该考虑他们的设计决策。

今天，模块化在很大程度上被誉为区块链扩展的主要方式。 在本篇文章中，我将质疑从第一原则中获得的归纳，揭示模块化系统的文化神话和隐形成本，并分享我在过去六年中考虑这一辩论得出的结论。

模块化系统增加开发人员复杂度

到目前为止，模块化系统的最大隐形成本是开发人员复杂度。

模块化系统大大增加应用程序开发人员必须管理的复杂度，无论是在他们自己的应用程序（技术复杂度）还是在与其他应用程序和状态片段（社会复杂度）的接口上。

在加密系统的背景下，我们今天看到的模块化区块链允许理论上更专业化，但代价是创造新的复杂度。 这种技术和社会问题的复杂性通过堆栈传递给应用程序开发人员，最终使其更难构建。

例如，考虑一下 OP 堆栈，似乎是 2023 年 8 月领先的模块化框架。 OP 堆栈迫使开发人员选择[区块链法律]（https://optimism.mirror.xyz/JfVOJ1Ng2l5H6JbIAtfOcYBKa4i9DyRTUJUuOqDpjIs?emailCampaignId=new_entry_email "Law of Chains"）（按照名称的建议，具有很复杂的社会关系)，或者分叉并单独管理 OP 堆栈。 这两种选择都为建筑商带来了大量的下游复杂度。 如果您选择走自己的路线，您是否会从其他生态系统参与者（CEX，Fiat On-Ramp 等）获得技术支持，这些参与者必须承担成本才能符合新的技术标准？ 如果您选择遵循区块链法律，那么今天您给自己施加什么规则和约束，更重要的是，明天呢？

来源 [OSI 模式]（https://www.cloudflare.com/learning/ddos/glossary/open-systems-interconnection-model-osi/ "OSI Model "）

现代操作系统（OS）庞大而复杂，包括数百个子系统。 现代操作系统处理上图中的第 2-6 层。 这是集成模块化组件以管理通过堆栈向应用程序开发人员公开的复杂性的典型示例。 应用程序开发人员不想处理第 7 层以下的任何内容，这正是操作系统存在的原因：操作系统管理下列复杂层，这样应用程序开发人员就不必这样做。 因此，模块化本身不应成为目标，而应成为实现目的的手段。

当今世界每个主要的软件系统——云后端、操作系统、数据库引擎、游戏引擎等——都是高度集成的，同时由许多模块化子系统组成。 软件系统倾向于长期集成，以最大限度地提高绩效并减小开发人员的复杂度。 区块链也不会有什么不同。

（另外，以太坊的[主要突破]（https://youtu.be/l9dpjN3Mwps "Vitalik Buterin reveals Ethereum at Bitcoin Miami 2014"）正在降低 2011-2014 年比特币分叉时代出现的复杂度。 模块化支持者经常强调开放系统互连（OSI）模型，认为数据可用（DA）和执行应该分开；然而，此论点被广泛误解。 对当前问题的正确重要理解导致相反结论：使用 OSI 作为模拟，是集成系统而不是模块化的系统的论据。

模块化区块链执行代码的速度不会更快

通过设计，“模块化区块链”的常见定义是数据可用性（DA）和计算的分离：一组节点进行 DA，而另一组（或一组）进行执行。 节点集根本不必有任何重叠，但它们可以。

实际上，将 DA 和计算分开并不会提高两者之间的性能；在一天结束时，世界上某个地方的某个硬件必须执行 DA，某个地方的某个硬件必须进行执行。 分离这些职能不会提高两者的性能。 但是，分离可以降低计算成本，但只能通过集中执行来降低。

然而，这一点值得重申：无论模块化和集成架构如何，某个硬件必须完成工作，并且将 DA 和执行推送到单独的硬件上，本质上不会加速或增加系统总容量。

一些人认为，模块化允许许多 EVM 的扩散以并行运行，这使得执行可以水平扩展。 虽然这在理论上正确无误，但此注释实际上强调作为单线程处理器的 EVM 限制，而不是解决在扩展系统总吞吐量的背景下分离 DA 和执行的基本前提。

模块化本身不会增加吞吐量。

模块化增加用户的交易成本

根据定义，每个 L1 和 L2 都是具有自身状态的不同资产账。 这些独立的状态片段可以通信，尽管延迟时间更多，开发人员和用户更复杂（例如，通过桥梁，例如[LayerZero]（https://layerzero.network/"LayerZero"）和 [Wormhole]（https://wormhole.com/"Wormhole"））。

资产账越多，所有账户片段的全局状态就越多。 这对跨多个领域的区块链和用户来说都是单方面地可怕。 片段状态导致

1. 流动资金减少，因此对投资者来说价差更高
2. 气体消耗总量增加（因为跨链交易按定义需要至少两个资产账上的至少两个交易）。
3. 跨资产账的更多重复计算（从而减少系统总吞吐量）：当以太坊-美元市值的价格在币安网或比特币基地上变动时，所有跨资产账的每个以太坊-美元市值池上都有套利机会。 （您可以轻松想象这样一个世界，当以太坊-美元市值在币安网或比特币基地上变动时，各种跨资产账中有 10 多个交易。 由于片段状态而保持价格一致是非常低效的块空间的使用。

重要的是要认识到，创建更多的资产账会明确地增加所有这些维度的成本，特别是因为它涉及 DeFi。

对 DeFi 的主要输入是链上状态（即拥有资产的人士）。 当团队启动应用程序链/汇总时，他们会自然地分散状态，这对 DeFi 来说非常糟糕，无论是在管理应用程序开发人员（桥接、钱包、延迟、跨链 MEV 等）和用户（更广泛的传播，更长的结算时间）方面。

当资产在单个资产账上发布并且交易在单个状态机内发生时，DeFi 效果最好。资产账越多，应用程序开发人员必须管理越复杂，用户必须承担的成本就越高。

应用程序汇总不会为开发人员创造新的货币化机会

应用程序链/汇总的支持者认为，激励措施将导致应用程序开发人员构建汇总，而不是在 L1 或 L2 上，以便他们可以将 MEV 捕获回自己的代币。 然而，这种想法有缺陷，因为运行应用程序汇总并不是将 MEV 捕获回应用程序层代币的唯一方法，而且在大多数情况下，也不是最佳方法。 应用层代币可以通过在通用链上对智能合约中的逻辑编码来捕获 MEV 回自己的代币。 让我们列举几个例子：

1. 清算 —如果化合物或 Aave DAO 想要捕获用于清算机器人的部分 MEV，他们可以更新各自的合同，以支付当前将流向清算人以路由到 DAO 的费用的百分比。 无需要新区块链/汇总。
2. 数据库_ — 数据库代币可以通过提供回运行即服务来捕获 MEV。 除了价格更新之外，数据库还可以捆绑任何保证在价格更新之后立即运行的链上交易。 因此，数据库可以通过向搜索器、块构建器等提供回运行即服务来捕获 MEV。
3. _NFT 铸造 — NFT 铸造充斥着剥头机器人。 这可以通过简单编码利润再分成下降来轻松缓解。 例如，如果有人试图在 NFT 铸造发行两周内转售他们的 NFT，则可以将 100% 的收入重新获取回铸造创建器或 DAO。 这个比例会随时间变化。

捕获 MEV 到应用程序层代币没有通用答案。 然而，稍微思考一下，应用程序开发人员可轻松将 MEV 捕获回通用链上自己的代币。 推出全新区块链根本没有必要，会给开发人员带来额外的技术和社会复杂度，并为用户带来更多的钱包和流动资金挑战。

应用程序汇总不解决跨应用程序拥塞问题

许多人认为，应用程序链/汇总可以确保给定的应用程序不会受到其他区块链上活动（例如流行的 NFT 铸造）引起的气体峰值的影响。 这种观点部分正确，但大多是错误的。

这一直是个问题，主要是原因 EVM 的单线程本质，而不是因为 DA 和执行缺乏分离。 所有 L2 的支付费用到 L1，L1 的费用可以随时增加。 在今年年初的模因币狂热中，Arbitrum 和 Optimism 的交易费用超过 10 美元。 最近，世界币推出后，Optimism 的费用[飙升]（https://twitter.com/optimismFND/status/1683522341148532738?s=20 "Fee Spike"）。

费用飙升的唯一解决方案是兼备：1) 最大化 L1 DA，2) 使费用市场尽可能细化：

如果 L1 的资源受到限制，各种 L2 的使用高峰将逐步下降到 L1，这将对所有其他 L2 产生更高的成本。 因此，应用程序链/汇总不能免受气体飙升的影响。

许多 EVM L2 的共存只是尝试本地化费用市场的粗略方式。 它比将所有内容都放在单个 EVM L1 中要好，但不能从第一原则中解决核心问题。 当您认识到解决方案是[本地化费用市场]（https://twitter.com/KyleSamani/status/1684005760504844290?s=20 "Localize Fee Markets"），逻辑终点是每个州的费用市场（而不是每个 L2 的费用市场）。

其他区块链已得出这一结论。 Solana 和 和 Apt os都自然地本地化费用市场。 这需要为各自的执行环境进行多年的工程工作。 大多数模块化支持者严重低估解决使超本地费用市场成为可能的硬工程问题的重要意义和难度。

![本地化费用市场]（//images.ctfassets.net/qtbqvna1l0yq/5a8EU6NdlMEPZ9nxOQdnP8/c41c557b0d6d6b6ccae99988751bfa53/LocalizedFee_Markets.avif） 来源： [https://blog.labeleven.dev/why-solana]（https://blog.labeleven.dev/why-solana "https://blog.labeleven.dev/why-solana"）

通过启动许多资产账，开发人员自然增加技术和社会复杂度，而不会释放实际绩效收益，即使在其他应用程序推动增大容量时也是如此。

灵活度被高估

模块化链的支持者认为模块化架构更灵活。 这一说法显然正确无误。 但尚不清楚它是否重要。

六年来，我一直在寻找应用程序开发人员，他们需要通用的 L1 无法提供有意义的灵活度。 但到目前为止，除了三个非常具体的用例之外，还没有明确说明为什么灵活很重要，也没有说明它如何直接帮助扩展。 我确定的三个具体使用案例中灵活度十分重要：

• 应用程序利用“热”状态。 热状态是某些动作集的实时协调所必需的状态，但最终不会在链上永久呈现。 列举热状态的几个示例：
  • 在 DEX 中限制命令，例如 [dYdX]（https://dydx.exchange/ "DyDx"）和 [Sei]（https://www.sei.io/ "Sei"）（许多限制命令最终会被取消）。
  • 实时协调和识别[dFlow]（https://dflow.net/ "dflow"）中的命令流（dFlow 是一种协议，旨在促进做市商和钱包之间的分散命令流市场）。
  • 数据库，例如 [Pyth]（https://pyth.network/ "Pyth"），这是一个低延迟的数据库。 Pyth 作为独立的 SVM 链运行。 Pyth 产生如此多的数据，以至于核心团队决定最好将高频价格更新发送到独立链，然后使用 Wormhole 根据需要将价格转换到其他链。
• 区块链可以修改共识。 最好的例子是 [Osmosis]（https://app.osmosis.zone/ "Osmosis"）（其中所有交易在发送到验证器之前都经过加密）和 [Thorchain]（https://thorchain.org/ "Thorchain"）（根据支付的费用对区块内的交易进行优先排序)。
• 基础结构需要以某种方式利用门限签名方案（TSS）。 例如，[Sommelier]（https://www.sommelier.finance/ "Sommelier"），[Thorchain]（https://thorchain.org/ "Thorchain"），[Osmosis]（https://app.osmosis.zone/ "Osmosis"），[Wormhole]（https://wormhole.com/ "Wormhole"），和 [Web3Auth]（https://web3auth.io/ "Web3Auth"）。

除了 Pyth 和 Wormhole 之外，上面列出的所有示例均使用 Cosmos SDK 构建，并且作为独立链运行。 这充分说明 Cosmos SDK 在所有三种用例中的质量和扩展能力：热状态、共识修改和门限签名方案 (TSS) 系统。

但是，上述三部分中标识的大多数项目不是应用程序。 它们是基础结构。

Pyth 和 dFlow 不是应用程序；它们是基础结构。 Sommelier（区块链，而不是收益优化器前端）、Wormhole、Sei 和 Web3Auth 不是应用程序；它们是基础结构。 在面向用户的应用程序中，它们都是一种特定类型：DEX（dYdX，Osmosis，Thorchain）。

六年来，我已经向 Cosmos 和 Polkadot 的支持者询问使用案例，这些使用案例从它们提供的灵活度中解锁。 我认为有足够的数据来推断几件事：

首先，基础结构示例不应作为汇总形式存在，因为它们要么产生太多低值数据（例如，热状态，并且热状态的整点是数据未提交回 L1），要么因为它们执行某些功能，故意与资产账上的状态更新正交（例如，所有的 TSS 用例）。

其次，我见过唯一类型的应用程序有意义地改变核心系统设计是 DEX。 这很容易理解，因为 DEX 充斥着 MEV ，并且因为通用链按照定义不能匹配 CEX 的延迟。 共识是交易执行质量和 MEV 的基础，因此，基于共识的更改，自然 DEX 中有很多创新机会。 然而，正如本文前面所述，现汇 DEX 的主要输入是交易的资产。 DEX 竞争资产，因此也竞争资产发行者。在此框架中，独立的 DEX 链不太可能成功，因为资产发行者在发行时考虑的主要变量不是 DEX 相关的 MEV，而是通用智能合约功能，以及将该功能集成到应用程序开发人员各自的应用程序中。

然而，这种与资产发行人竞争的 DEX 框架对于衍生品 DEX 大多无关，后者主要依赖于美国美元市值的抵押品和数据库价格，并且本质上必须锁定用户资产以抵押衍生品头寸。 因此，在独立的 DEX 链有意义的情况下，它们最有可能适用于以衍生品为重点的 DEX ，例如 dYdX 和 Sei。

（注意：如果您正在构建新类型的基础结构，但上述类别无法捕获，或者面向消费者的应用程序，该应用程序确实需要比通用集成 L1 支持更灵活，请联系我！ 我花了六年时间才提炼出上述内容，我敢肯定这份清单并不完整。）

相反，让我们考虑一下今天存在于通用、集成的 L1 中的应用程序。 一些示例：游戏；[Audius]（http://audius.co "Audius"）；DeSoc 系统，例如 [Farcaster]（https://www.farcaster.xyz/ "Farcaster"）和[Lens]（https://www.lens.xyz/ "Lens"）； DePIN 协议，如 [Helium]（http://helium.com "Helium"），[Hivemapper]（http://hivemapper.com "Hivemapper"），[Render Network]（https://renderfoundation.com/ "Render Network"），[DIMO]（https://dimo.zone/ "Dimo"），和 [Daylight]（https://godaylight.com "Daylight"）; [Sound]（https://www.sound.xyz/ "Sound"），NFT 交易所等。 所有这些都没有特别受益于修改共识带来的灵活度。 它们都有相当简单、明显和常见的要求，从各自的资产账中：低费用，低延迟，访问现汇 DEX，访问稳定币，以及访问 Fiat on-ramp，如 CEX。

我相信我们现在有足够的数据可以肯定地说，绝大多数面向用户的应用程序具有与前一段所列举的相同的共同要求。 虽然某些应用程序可通过堆栈的自定义来优化边缘上的其他变量，但这些自定义的权衡通常不值得（更多的桥接，更少的钱包支持，更少的索引/查询提供商支持，减少直接的法币到加密货币入口等）。

推出新的资产账是实现灵活度的一种方法，但它很少增加价值，而且几乎总是以最小的最终收益为应用程序开发人员带来技术和社会复杂度。

重构无需扩展 DA

您还将听到模块化支持者谈论在扩展背景下重新构建。 这是模块链支持者提出的最推测的论点，但值得解决。

它大致说明，由于重构（例如，通过像 EigenLayer 这样的系统），加密生态系统作为一个整体可以重构以太坊无限次，以便为无限数量的 DA 层（例如，EigenDA）和执行层提供动力。 因此，在所有方面都解决了扩展问题，同时确保价值应计为以太坊。

尽管现状和理论未来之间存在大量不确定因素，但让我们理所当然地认为，所有分层推定都如宣传的那样有效。

今天的以太坊 DA 约为 83 KB/s。 今年末，使用 EIP 4844，这大约增加一倍，达到约 166 KB/s。 虽然使用不同的安全假定集（并非所有以太坊都将重新归入到 EigenDA）， 但 EigenDA 会额外增加 10 MB/s。

相比之下，Solana 今天提供的 DA 大约为 125 MB/s（每个区块 32,000 个片段，每个片段 1,280 个字节，每秒 2.5 个区块）。 Solana 比以太坊和 EigenDA 效率更高，因为其[涡轮块传播协议]（https://docs.solana.com/cluster/turbine-block-propagation “Turbine”），已生产 3 年。 此外，Solana 的 DA 会随着时间推移而扩展，使用 [尼尔森定律]（https://www.google.com/search?q=nielsen%27s+law+bandwidth+doubling&spell=1&sa=X&ved=2ahUKEwikkrrhz7H_AhUVnWoFHUG5DcMQBSgAegQILRAB&biw=2560&bih=1340&dpr=2 "Nielsen’s Law"），该定律继续有增无减（不像摩尔定律， 用于实际目的[在单线程计算中消失]（https://www.quora.com/does-Moores-Law-no-longer-hold-for-single-core-processing-speeds-what-is-the-significance-of-that-for-Moores-Law-and-computing-power-generally “Moore's law dead”））。

有很多方法可以通过重构和模块化扩展 DA，但这些机制如今根本不需要，并且会引入显著的技术和社会复杂度。

为应用程序开发人员构建

在考虑了多年之后，我得出结论，模块化本身不应该是一个目标。

区块链必须为他们的客户（即应用程序开发人员）提供服务，因此，区块链应该抽象化基础结构级别的复杂度，以便企业家可以专注于构建世界级应用程序。

模块化构建区块十分成功。 但是构建获胜技术的关键是找出堆栈中的哪些部分要集成，以及哪些部分要留给其他人。 就目前而言，集成 DA 和执行的区块链本质上提供了更简单的最终用户和开发人员体验，并最终为最佳应用程序提供更好的基层。

感谢 [Alana Levin]（https://twitter.com/AlanaDLevin "Alana D Levin"），[Tarun Chitra]（https://twitter.com/tarunchitra "Tarun Chitra"），[Karthik Senthil]（https://twitter.com/karsenthil "Karthik Senthil "），[Mert Mumtaz]（https://twitter.com/0xMert_ "Mert Mumtaz"），[Ceteris]（https:////twitter.com/ceterispar1bus "Ceteris"），[Jon Charbonneau]（https://twitter.com/jon_charb "Jon Charbonneau "），[John Robert Reed]（https://twitter.com/johnrobertreed "John Robert Reed"），和 [Ani Pai]（https://twitter.com/ani_pai "Ani Pai"），对本篇文章的反馈。