撰文：Dmitriy Berenzon，1kx 分析师
编译：白泽研究院
虽然区块链的最初应用围绕货币和金融，但在过去几年中，艺术、游戏和音乐等领域的应用激增。与此同时，这些应用程序中的聚合用户数量一直呈线性增长，给底层基础设施带来压力并降低用户体验。此外，随着这些应用程序的扩展，它们越来越需要更多的可定制性和更强大的业务模型。
解决这些问题的一种新兴业务模式是构建特定于应用程序的区块链，称为「AppChains」（应用链）。构建 AppChains 的应用程序可以自定义其堆栈的多个层，例如其安全模型、手续费用和写入权限等。
AppChains 不是一个新概念；比特币可以被认为是用于数字黄金的特定应用区块链，而 Arweave 则可以用于永久存储。也就是说，AppChain 的设计不仅包含单片区块链（例如 Osmosis），还包含处理应用程序状态转换的模块化执行层（例如 rollups、sidechains、plasma），但依赖于单独的结算层或共识层来实现最终性。
事实上，「层」（如 L2，L3 等）在大多数情况下，只是信任最小化的区块链，具有双向最小化信任的跨链桥。
在本文中，我将：
- 概述 AppChains 的历史
- 解释 AppChains 的优缺点
- 描述未来 AppChain 市场结构
- 概述 AppChain 如何设计
- 比较当前已有的不同 AppChain 解决方案
AppChains 的前世今生
AppChain 花了很多年才出现。虽然 Cosmos 和 Polkadot 早在 2016 年就提出并推广了这一概念，但他们直到 2021 年初才完全启动他们的网络（分别具有 IBC 和平行链功能）。与此同时，在可扩展性方面，由于以太坊上用户的需求不断增加，到 2020 年底，ETH 交易费用变得出奇的高，应用程序开发人员迫切需要替代解决方案。与此同时，以太坊链外可扩展性研究正以「L2s」的形式缓慢实施，Polygon、Skale、zkSync (1.0) 、StarkWare (StarkEx)、Optimism 和 Arbitrum 都在 2020 年和 2021 年推出。
其他基础层（「L1」）也意识到支持 EVM（以太坊虚拟机）作为其业务开发工作的一部分的重要性；Avalanche（C-Chain）、NEAR（Aurora）、Polkadot（Moonbeam）和 Cosmos（Evmos）都在 2020 年和 2021 年推出了与 EVM 兼容的链。
在特定于应用程序的设计方面，Celestia 于 2019 年（最初作为 LazyLedger）推出了一种新颖的模块化设计，该设计将传统单片区块链的执行、结算和数据可用性层分开，从而允许特定于应用程序的区块链，无需重建堆栈的其他部分。
如今，有多种平台提供 AppChain 基础设施。虽然其中一些目前仅提供公共区块空间（例如 Optimism、zkSync），但如果有足够的开发人员需求，它们很可能会推出支持专用的执行层。
此外，虽然 AppChains 的启动和互操作问题在历来是困难的，但在过去几年中，开发人员和用户都在加速接受 AppChains。Axie 于 2021 年初推出了他们的以太坊侧链 Ronin，DeFi Kingdoms 宣布于 2021 年底从 Harmony 转移到 Avalanche 子网，Apecoin 社区约 46%的成员仍支持构建 ApeChain，dYdX 宣布他们的 V4 版本协议将建立在使用 Cosmos SDK 打造的 L1 上。今天，有无数的应用程序构建在 AppChains 上。
为什么选择 AppChains？
开发人员越来越多地转向构建 AppChains 而不是在公共区块链上启动智能合约的主要原因有三个。
表现
- 由于 dApp 在同一网络上相互竞争，因此一个流行的 dApp 通常会消耗不成比例的资源，这会增加其他 dApp 用户的交易成本和延迟。
- AppChains 为项目提供了稳定交易成本、延迟低的能力，从而为用户带来更好的用户体验。
可定制性
- 随着 dApp 越来越受欢迎，开发人员需要继续为用户优化他们的 dApp。
- 大型 dApp 需要权衡某些设计选择，例如吞吐量、最终性、安全级别、许可、可组合性和生态系统一致性等。例如，验证器可能具有高性能硬件要求（例如运行 SGX 或 FPGA 以生成零知识证明）。
- 对于传统组织来说，AppChains 提供了一种方法，让他们可以在无需授权的情况下进入 Web3；例如，公司可以要求 KYC 验证者删选想要在他们的网络上构建的开发人员，并选择他们想要将资产通过跨链桥连接到哪些链。
价值捕获
- 虽然通用的可扩展性解决方案的确降低了交易成本，同时保留了安全性和开发人员体验，但它们为开发人员提供的货币化机会很少。
- 另一方面，AppChains 有很强的商业案例，因为 dApp 能够在其生态系统内分叉现有协议并将其货币化（例如，来自 AMM 或 NFT 市场的交易费用）。
- 他们的代币受益于被用作安全模型（即质押代币或 Gas 代币）的额外代币。
- 此外，应用程序能够通过运行自己的排序器或验证器来捕获 MEV，这可以为新的加密业务模型创造机会；例如，dYdX 的验证者（可能是做市商）可以为用户提供低费用或免费费用，但给他们的执行价格略低，类似于 Robinhood 使用的按订单付费的模式。
- 再举一个例子，许多成功的游戏都有大量的模组、皮肤等，并积极尝试尽可能多的调整。但大多数时候，建模是由难以赚钱的业余游戏玩家完成的。如果该游戏构建在 AppChain，那么模组可以在 rollup 之上扩展该 IP，并通过使用该链获利。
AppChains 的问题
然而，任何事都是双刃剑：
有限的可组合性和原子性
- AppChains 在一定程度上隔离了其他生态系统中的基础设施和用户。虽然这不会破坏可组合性（你只需要在相同的 VM 上有足够好的桥接），但它确实破坏了原子性（一种「全有或全无」的属性，即单个事务中的所有子操作要么都被执行，要么一个都不执行）。
- 也就是说，虽然原子性是所有应用程序都位于同一结算层的特殊属性，但它对许多应用程序来说并不重要（例如，P2E 游戏不依赖闪电贷来维持经济运行）。
重建围墙花园
- 作为一个思想实验，如果所有 AppChain 都具有读 / 写权限，由此产生的市场结构将限制开发人员的无需许可和组合创新，以及用户自由交易的能力，这将让 Crypto 重新回到旨在解决的问题上。
流动性分散
- 来自其他层或链的流动性资产将需要跨链桥连接到 AppChains，虽然通过桥接基础设施可以做到这一点，但它为用户增加了额外的「摩擦」。
自反安全模型
- 如果使用应用程序代币作为安全模型，则存在一个边缘情况，即如果代币的价格下降到 0，应用程序将不再具有经济安全性。
资源浪费
- 如果应用程序得不到足够的使用，AppChains 可能会浪费资源（物理或经济）。如果 AppChain 具有专用的验证器，那么这些验证器可以更有效地将其资源部署到其他地方。
额外的复杂性
- 因为它不像部署智能合约那么简单，所以在管理额外的基础设施（例如排序器或验证器）时会增加额外的复杂性。
有限的生态系统工具
- 可能没有「开箱即用」的资源，例如区块浏览器、RPC 提供者、索引器、预言机和生态系统资金。
新兴的 AppChain 市场结构
由于在更孤立的生态系统中构建有许多缺点，AppChains 最适合具有以下特征的应用程序：
- 达到了规模（例如用户数量、协议收入、TVL）和产品市场契合度
- 性能能为产品带来显著的优势
- 对安全性和原子性的要求更少（例如 P2E 游戏、NFT、加密社交）
因此，我们有理由认为大多数应用程序将仍继续在公共 L1 和 L2 上启动。此外，由于 L2 的格局仍然相当分散，我们将看到 DeFi 协议由于其安全性、流动性和原子性属性而继续在 L1 上推出。此外，如果非 DeFi 应用程序有了足够大的生态系统和网络效应，它们可能会在通用 L2 上启动并转移到特定于应用程序的 L3 或特定于应用程序的 L1。我们可以粗略地想象这个操作顺序如下：
还有一个原因是，大多数启动 AppChains 的应用程序将选择模块化执行层（特别是 rollups）而不是单片链，因为它们没有吸引大型验证器群所需的资金。此外，高质量的验证者不太可能选择将他们的资源用于代币价格低且不稳定的 AppChain。
尽管如此，随着加密行业的成熟和普及，更多的应用程序仍将继续推出自己的 AppChain，未来的 AppChain 市场结构将有多种形式：
- 通过各种跨链桥连接的 AppChains
- 连接到 L1 的特定于应用程序的侧链
- 不使用结算层的特定于应用程序的rollups
AppChains 如何设计
在决定构建 AppChain 的基础架构时，需要考虑几个设计权衡：
安全类型：通过攻击来改变状态有多难？
- 共享：由多个异构验证器保护的状态，可能由不同方运行（例如 Polkadot 平行链、Skale）
- 隔离：应用程序本身提供的安全性；可能使用应用程序拥有的验证器或排序器，并使用应用程序的代币来获取经济利益（例如 Cosmos 链、Axie Ronin）
- 继承：底层结算 / 共识层提供的安全性（例如 zkSync、Optimism）
安全来源：安全从何而来，结算又从何而来？
- 以太坊：使用以太坊作为欺诈证明、有效性证明和一般双花保护的结算层（例如 Arbitrum、zkSync）
- 非以太坊 L1：使用非以太坊安全性，并且可能具有完全不同的共识模型（例如 NEAR Aurora、Tezos rollups）
- 应用代币：将应用程序的代币用作加密经济安全（例如 Avalanche 子网、Cosmos 链）
权限：如何选择节点，以及谁可以读取 / 写入状态？
- 无许可：任何人都可以读 / 写合约并验证状态转换（例如 Optimism、StarkNet）
- 选择性许可：只有列入白名单的验证者 / 开发者才能读 / 写 / 验证链（例如 Polygon Supernets、Avalanche 子网）
可组合性：流动性和状态在同一生态系统中的其他应用程序之间移动是否容易和安全？
- 全部 : 移动到任何具有最小延迟和最大安全性的应用程序（例如 Polkadot XCMP、Cosmos IBC）
- 有限：在连接性、延迟或安全性方面存在限制（例如 Avalanche 子网、Polygon Supernets）
最终性：交易何时被视为最终性？
- 即时：通常使用 BFT 共识机制（例如 NEAR Aurora、Evmos）
- 最终：通常使用 rollups，一旦区块被发布到 L1（并假设数据可用），交易就可以被视为最终交易（例如 Arbitrum、zkSync）
Gas 代币：用户使用哪种代币支付交易费用？
- 非应用程序代币：通常是构建应用程序的 L1 或 L2 的基础资产（例如 Ethereum、Evmos）
- 应用程序代币：通常应用程序的代币本身运行在特定于应用程序的 L1 或 L2 上（例如 Avalanche 子网、Osmosis）
- 无代币：L1 或 L2 验证器或应用程序为用户提供成本补贴。（例如 AltLayer、Skale）
还有其他几个更直接的因素：
- 所需权益：应用程序需要验证者来保护其链所需的权益数量
- 每秒事务数 (TPS)：吞吐量的主观衡量标准，因为事务的大小可能会有所不同（即，较大的事务将导致较低的 TPS，反之亦然）
- EVM 支持：无需开发人员修改其代码库即可同时支持 Solidity 和 EVM 操作码的能力
我们可以根据这些因素映射现有的 AppChain 解决方案：
结论
尽管 AppChains 存在问题，但它们的持续增长表明了开发人员的需求。正如苹果公司所证明的那样，垂直整合通常会带来更好的用户体验；同样，区块链开发人员将寻求提供 AppChains 支持的完全优化的 Web3 应用程序。也就是说，AppChains 并不适合所有人，开发人员在投入资源启动应用程序之前，应深入考虑 / 权衡其应用程序的需求。
AppChains 对安全模型经济学、货币化策略、平台防御性、整个堆栈的整体价值累积以及对加密市场结构有许多影响，这些影响将在未来几年内被我们观察到。
