Multicoin合伙人：模块化区块链被高估的7个理由

Foresight News ｜2023-08-16 15:28

这篇文章中，我将从第一性原则质疑这个假设，揭示模块化系统的文化神话和隐性成本，并分享我在过去六年思考这场辩论时得出的结论。

作者：Kyle Samani，Multicoin Capital 合伙人

编译：Luffy，Foresight News

过去两年，区块链扩展性争论已经集中到「模块化与集成化之争」这个中心话题上。

请注意，加密货币中的讨论经常将「单一」和「集成」系统混为一谈。关于集成系统与模块化系统的技术辩论，已经跨越了 40 年的漫长历史。加密货币领域的这场对话应该通过与历史相同的镜头来构建，这远非一场新的辩论。

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

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

模块化系统增加了开发复杂性

到目前为止，模块化系统最大的隐性成本是增加了开发过程的复杂性。

模块化系统大大增加了应用程序开发人员必须管理的复杂性，无论是在他们自己的应用程序上下文中（技术复杂性），还是在与其他应用程序交互的上下文中（社会复杂性）。

在加密货币背景下，模块化区块链理论上允许更加专业化，但代价是创造了新的复杂性。这种复杂性（本质上是技术性的和社会性的）正在被传递给应用程序开发人员，最终使得构建应用变得更加困难。

例如，考虑一下 OP Stack。截至目前，它似乎是最受欢迎的模块化框架。OP Stack 迫使开发人员选择采用 Law of Chains（这会带来很多社会复杂性），或者分叉和单独管理。这两种选择都会给构建者带来巨大的下游复杂性。如果你选择分叉，你是否会获得其他生态系统参与者（CEX、法币入口等）的技术支持，而这些参与者必须承担成本才能符合新技术标准？如果你选择遵循 Law of Chains，今天以及明天又会有哪些规则和约束会施加在你身上？

Multicoin合伙人：模块化区块链被高估的7个理由

来源：OSI 模型

现代操作系统 (OS) 是包含数百个子系统的大型复杂系统。现代操作系统处理上图中的第 2-6 层。这是集成模块化组件以管理向应用程序开发人员暴露的堆栈复杂性的典型示例。应用程序开发人员不想处理第 7 层以下的任何内容，这正是操作系统存在的原因：操作系统管理下面各层的复杂性，以便应用程序开发人员专注于第 7 层。因此，模块化本身不应该是目标，而应该是达到目的的手段。

当今世界上的每一个主要软件系统——云后端、操作系统、数据库引擎、游戏引擎等——都是高度集成的，同时由许多模块化子系统组成。软件系统往往会高度集成，以最大限度地提高性能并降低开发复杂性。区块链也是如此。

顺便说一句，以太坊正在降低 2011-2014 年比特币分叉时代出现的复杂性。模块化支持者经常强调开放系统互连（OSI）模型，认为数据可用性（DA）和执行应该分开；然而，这一论点被广泛误解。对当前问题的正确理解会得出相反的结论：OSI 是集成系统而不是模块化系统的论据。

模块化链无法更快执行代码

按照设计，「模块化链」的常见定义是数据可用性（DA）和执行的分离：一组节点负责 DA，而另一组（或多组）节点负责执行。节点集合不必有任何重叠，但它们可以。

在实践中，分离 DA 和执行并不会本质上提高两者的性能；相反，世界上某个地方的某个硬件必须执行 DA，某个地方的某个硬件必须实施执行。分离这些功能并不会提高其中任何一个的性能。虽然分离可以降低计算成本，但只能通过集中执行来降低。

需要重申的是：无论模块化还是集成架构，某处的某些硬件都必须完成工作，而将 DA 和执行分离到单独的硬件上并不会本质上加速或增加总系统容量。

一些人认为，模块化允许多个 EVM 以 Rollup 方式并行运行，从而使执行能够水平扩展。虽然这在理论上是正确的，但这种观点实际上强调了 EVM 作为单线程处理器的限制，而不是在扩展系统总吞吐量的背景下分离 DA 和执行的基本前提。

单独的模块化并不能提高吞吐量。

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

根据定义，每个 L1 和 L2 都是一个具有自己状态的独立的资产账本。这些单独的状态片段可以进行通信，尽管交易延迟更长，而且开发人员和用户面临的情况也更复杂（通过 LayerZero 和 Wormhole 等跨链桥）。

资产账本越多，所有账户的全局状态碎片就越多。这对于链和横跨多个链的用户来说都是可怕的。状态碎片化可能带来一系列后果：

流动性减少，导致交易滑点更高；
更多的总 Gas 消耗（跨链交易需要至少两个资产账本上的至少两笔交易）；
跨资产账本的重复计算增多（从而降低系统总吞吐量）：当 ETH-USDC 的价格在 Binance 或 Coinbase 上变动时，所有资产账本的每个 ETH-USDC 池上都会出现套利机会（你可以很容易想象这样一个世界，每当 ETH-USDC 价格在 Binance 或 Coinbase 上变动时，各种资产账本上就会有 10 笔以上的交易。在碎片化状态下保持价格一致是对区块空间极其低效的利用）。

重要的是要认识到，创建更多的资产账本会明显增加所有这些维度的成本，尤其是与 DeFi 相关的成本。

DeFi 的主要输入是链上状态（即谁拥有哪些资产）。当团队启动应用程序链 /Rollup 时，他们自然会产生状态碎片，这对 DeFi 来说非常不利，无论是管理应用程序复杂性的开发人员（桥、钱包、延迟、跨链 MEV 等），还是用户（滑点、结算延迟）。

DeFi 最为理想的条件是：资产在单一资产账本上发行并且在单一状态机内进行交易。资产账本越多，应用程序开发人员必须管理的复杂性就越多，用户必须承担的成本也越高。

应用程序 Rollup 不会为开发者创造新的盈利机会

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

清算：如果 Compound 或 Aave DAO 想要捕获流向清算机器人的 MEV 的一部分，它们只需更新各自的合约，使当前流向清算人的费用中的一部分支付给自己的 DAO，而不需要新的链 /Rollup。
预言机：预言机代币可以通过提供 back running 服务来捕获 MEV。除了价格更新之外，预言机还可以捆绑任何保证在价格更新后立即运行的任意链上交易。因此，预言机可以通过向搜索者、区块构建者等提供 back running 服务来捕获 MEV。
NFT 铸造：NFT 铸造充斥着倒卖机器人。通过简单编码不断下降的利润重新分配就可以轻松缓解这种情况。例如，如果有人试图在 NFT 铸币后两周内转售其 NFT，则 100% 的收入将重新回归发行方或 DAO。随着时间的推移，该百分比可能会有所变化。

将 MEV 捕获到应用层代币没有通用答案。然而，只要稍加思考，应用程序开发人员就可以轻松地将 MEV 捕获回通用链上自己的代币中。推出一条全新的链根本没有必要，会给开发者带来额外的技术和社会复杂性，并给用户带来更多的钱包和流动性困扰。

应用程序 Rollup 无法解决跨应用程序拥塞问题

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

这是一个历史问题，根本原因是 EVM 的单线程性质，而不是因为 DA 和执行没有分离。所有 L2 都要向 L1 支付费用，并且 L1 费用可以随时增加。今年早些时候的 memecoin 热潮中，Arbitrum 和 Optimism 上的交易费用一度超过了 10 美元。最近，Optimism 的费用在 Worldcoin 推出后也出现了飙升的状况。

解决费用高峰的唯一解决方案是：1）最大化 L1 DA，2）尽可能细化费用市场：

如果 L1 的资源受到限制，各个 L2 中的使用高峰将传递到 L1，这将给所有其他 L2 带来更高的成本。因此，应用链 /Rollup 无法免受 Gas 峰值的影响。

众多 EVM L2 共存只是尝试本地化费用市场的一种粗暴方式。它比将费用市场放在单个 EVM L1 中要好，但并没有解决核心问题。当你认识到解决方案是本地化费用市场，逻辑终点是每个状态的费用市场（而不是每个 L2 的费用市场）。

其他链已经得出了这个结论。Solana 和 Aptos 自然而然地将费用市场本地化。这需要多年来针对各自的执行环境进行大量的工程工作。大多数模块化支持者严重低估了构建本地费用市场工程的重要性和难度。

Multicoin合伙人：模块化区块链被高估的7个理由

本地化费用市场，来源： https://blog.labeleven.dev/why-solana

通过推出多个链，开发人员并不能解锁真正的性能收益。在有应用程序推动交易量增加时，所有 L2 链的成本都会受到影响。

灵活性被高估了

模块化链的支持者认为模块化架构更为灵活。这句话显然是正确的，但它真的重要吗？

六年来，我一直在努力寻找通用 L1 无法为其提供的有意义的灵活性的应用程序开发人员。但到目前为止，除了三个非常具体的用例之外，还没有人能明确说明为什么灵活性很重要，以及它如何直接帮助扩展。我发现灵活性很重要的三个具体用例是：

利用「热」状态的应用程序。热状态是实时协调某些操作集所必需的状态，但只会临时提交到链上，不会永远存在。热状态的几个例子：

DEX 中的限价订单，例如 dYdX 和 Sei（很多限价单最终被取消）。
dFlow 中实时协调和识别订单流（dFlow 是促进做市商和钱包之间去中心化订单流市场的协议）。
预言机如 Pyth，这是一个低延迟的预言机。Pyth 作为独立的 SVM 链运行。Pyth 产生如此多的数据，以至于核心 Pyth 团队决定最好将高频价格更新发送到独立链，然后根据需要使用 Wormhole 将价格桥接到其他链。

修改共识的链。最好的例子是 Osmosis （其中所有交易在发送到验证者之前都经过加密），以及 Thorchain （根据支付的费用对区块内的交易进行优先级排序）。

需要以某种方式利用门限签名方案 (TSS) 的基础设施。这方面的一些例子是 Sommelier、Thorchain、Osmosis、Wormhole 和 Web3Auth。

除了 Pyth 和 Wormhole 之外，上面列出的所有示例都是使用 Cosmos SDK 构建的，并且作为独立链运行。这充分说明了 Cosmos SDK 对于所有三个用例的适用性和可扩展性：热状态、共识修改和门限签名方案 (TSS) 系统。

但是，上述三个用例中的大多数项目都不是应用程序，它们是基础设施。

Pyth 和 dFlow 不是应用程序，它们是基础设施。Sommelier、Wormhole、Sei 和 Web3Auth 不是应用程序，它们是基础设施。它们之中，面向用户的应用程序只有一种特定类型：DEX（dYdX、Osmosis、Thorchain）。

六年来，我一直在向 Cosmos 和 Polkadot 支持者询问它们提供的灵活性所带来的用例。我认为有足够的数据可以做出一些推断：

首先，基础设施示例不应该作为 Rollup 存在，因为它们要么产生太多低价值数据（例如热状态，而热状态的全部意义在于数据不会提交回 L1），或者因为它们执行一些有意与资产账本上的状态更新相关的功能（例如，所有 TSS 用例）。

其次，我见过的唯一一种能够从更改核心系统设计中获益的应用程序是 DEX。因为 DEX 充斥着 MEV，而通用链无法与 CEX 的延迟相匹配。共识是交易执行质量和 MEV 的基础，因此基于共识的改变自然会给 DEX 带来很多创新机会。然而，正如本文前面提到的，现货 DEX 的主要输入是正在交易的资产。DEX 争夺资产，从而争夺资产发行者。在这个框架下，独立的 DEX 链不太可能成功，因为资产发行者在资产发行时考虑的首要问题不是 DEX 相关的 MEV，而是通用智能合约功能以及将该功能纳入到开发人员各自的应用程序。

然而，衍生品 DEX 无需争夺资产发行者，它们主要依赖 USDC 等抵押品和预言机喂价，而且本质上必须锁定用户资产来抵押衍生品头寸。因此，就独立 DEX 链的意义而言，它们最有可能适用于 dYdX 和 Sei 等专注于衍生品的 DEX。

我们考虑一下目前存在的通用集成 L1 应用程序，包括：游戏、DeSoc 系统（例如 Farcaster 和 Lens）、DePIN 协议（例如 Helium、Hivemapper、Render Network、DIMO 和 Daylight）、Sound、NFT 交易所等等。这些都没有特别受益于修改共识带来的灵活性，它们各自的资产账本都有一套相当简单、明显和共同的要求：低费用、低延迟、访问现货 DEX、访问稳定币以及访问到法定渠道，例如 CEX。

我相信我们现在有足够的数据在一定程度上说明，绝大多数面向用户的应用程序都具有与上一段中列举的相同的通用要求。虽然某些应用程序可以通过堆栈中的自定义功能来优化边际上的其他变量，但这些自定义带来的权衡通常是不值得的（更多的桥接，更少的钱包支持，更少的索引 / 查询程序支持，法币渠道减少等）。

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