导读

今日老雅痞共推送 3 篇文章。

AppChain 是我们一直关注的一个赛道。推荐阅读本文，一文给你说清楚，为什么 AppChain 这么热。

当有一项新技术时，人们会带着他们现有的焦虑向它靠拢，但是随着发展，产生偏差，人们会感到梦碎，但这并不是因为梦想是错误的，而是因为我们没有建立足够好的技术。推荐阅读第一条，如果互联网病了，解药在哪里？

时尚与元宇宙的结合不是什么新鲜事儿，2008 年就有品牌开始了这种尝试。经过这么多年，为什么都还停留在花里胡哨的视觉效果这种简单的层面？时尚的本质是创造，元宇宙是创造的土壤吗？推荐阅读第三条，了解我们从过去吸取到的经验和教训。

Dmitriy Berenzon丨编译

medium 丨来源

事实上，“层”（例如 L2、L3 等）在大多数情况下只是具有双向信任最小化桥的信任最小化区块链。

L3 仍处于研发阶段，但通过递归零知识证明在概念上是可能的

• 概述 AppChains 的历史

• 解释 AppChains 的优缺点

• 描述未来 AppChain 市场结构

• 概述 AppChain 设计空间

• 比较当前使用的不同 AppChain 解决方案

AppChain 的前世今生

区块链花了很多年才为开发人员提供 AppChain 基础设施。虽然 Cosmos 和 Polkadot 早在 2016 年就接受并推广了这一概念，但他们直到 2021 年初才完全启动他们的网络（分别具有 IBC 和平行链功能）。与此同时，在可扩展性方面，对以太坊区块空间的需求不断增加，到 2020 年底，交易费用变得高得令人沮丧，此时开发人员迫切需要替代解决方案。与此同时，以太坊可扩展性研究正以乐观和零知识汇总和侧链（统称为“L2s”）的形式缓慢实施。多边形、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），但如果有足够的开发人员需求，它们很可能会推出对专用执行层的支持。

截至 2022 年 10 月 3 日

此外，虽然 AppChains 的启动和互操作在历史上一直很困难，但在过去几年中，开发人员和用户都在加速接受这个想法。Axie 于 2021 年初推出了他们的以太坊侧链 Ronin，DeFi Kingdoms 宣布于 2021 年底从 Harmony 转移到 Avalanche 子网，约 46% 的 Apecoin 社区在 2022 年中期仍投票支持 ApeChain，dYdX 于 2021 年中期宣布 -2022 他们的 V4 将使用 Cosmos SDK 在主权 L1 上构建。今天，有无数的应用程序构建在跨各种平台的 AppChains 上。

不全面；截至 2022 年 10 月 3 日；“以太坊”包括 Polygon、Skale 和其他 L2 和侧链

为什么选择 AppChains ？

开发人员不在共享区块空间上启动智能合约，越来越多地转向构建 AppChains 的主要原因有三个。

性能

• 由于 dApp 在同一网络上相互竞争区块空间，因此一个流行的 dApp 通常会消耗不成比例的资源，这会增加其他 dApp（例如 Polygon 和 Arbitrum ）用户的交易成本和延迟。

• AppChains 为项目提供了保持交易成本和延迟低且可预测的能力，从而为最终用户带来更好的用户体验。

可定制性

• 随着 dApp 越来越受欢迎，开发人员需要继续为最终用户优化他们的应用程序。

• 较大的应用程序将需要做出某些设计选择权衡，例如吞吐量、最终性、安全级别、许可、可组合性和生态系统一致性等。例如，验证器可能具有高性能硬件要求（例如运行 SGX 或 FPGA 以生成零知识证明）。

• 对于传统组织，AppChains 提供了一种无需从一开始就完全无需许可，就能涉足 Web3 的方式；例如，公司可以要求 KYC 的验证者、想要在他们的网络上构建的预筛选开发人员，选择他们想要桥接资产的链。

价值捕获

• 虽然通用可扩展性解决方案降低了交易成本，同时保留了安全性和开发人员体验，但它们为开发人员提供的货币化机会很少。

• 另一方面，AppChains 有一个强大的商业用例，因为应用程序能够分叉现有协议并在其生态系统中将其货币化（例如，来自 AMM 或 NFT 市场的交易费用）。

• 此外，他们的代币从被用作安全模型的额外代币汇中受益（即赌注代币或气体代币），以及该代币的市场重新定价，更接近于 L2 或 L1 代币。

• 应用程序能够通过运行自己的排序器或验证器来捕获 MEV，这可以为新的加密业务模型创造机会；例如，可能是做市商的 dYdX 验证者可以为用户提供低费用或免费费用，但给他们的执行价格略低，类似于 Robinhood 使用的按订单流支付模型。

• 再举一个例子，许多成功的游戏都有大量的模组、扩展、皮肤等，并积极尝试尽可能多的模组化。但大多数时候，改装是由难以赚钱的业余游戏玩家完成的。如果该游戏是 AppChain，那么模组可以在汇总之上扩展该 IP，并通过使用该区块空间获利。

AppChains 的问题

一体两面，AppChains 再好也有问题和局限：

有限的可组合性和原子性

• AppChains 为其他生态系统中的基础设施和用户增加了一定程度的隔离。虽然这不会破坏可组合性（只需要跨相同 VM 的足够好的桥梁），但它确实破坏了原子性（“全有或全无”属性，即单个事务中的所有子操作都被执行，或者一个都不执行。）。

• 也就是说，虽然原子性是所有应用程序都位于同一结算层的特殊属性，但它对许多应用程序来说并不重要（例如，P2E 游戏不依赖闪电贷来维持经济运行）。

重建围墙

• 如果所有 AppChain 都具有读 / 写权限，那么由此产生的市场结构将限制开发人员的无权限和可组合创新以及用户自由交易和选择退出系统的能力，这会导致中心化的风险。而加密的核心是去中性化。

分散的流动性

• 使用 AppChains，来自其他层或链的流动性或资产将需要桥接到该应用程序，反之亦然。虽然通过桥接基础设施可以做到这一点，但它为最终用户增加了额外的摩擦层。

自反安全模型

• 如果使用应用程序令牌作为安全模型，则存在一个边缘情况，即如果令牌的价值下降到 0，应用程序将不再有经济安全性。

资源浪费

• 如果应用程序没有获得足够的使用率，AppChains 可能会浪费资源（物理或经济）。如果 AppChain 有专门的验证器，这些验证器可以在其他地方更有效地部署他们的资源。

需要额外的开发人员

• 因为它不像部署智能合约那么简单，所以在管理额外的基础设施（例如排序器或验证器）时将会有额外的复杂性。

有限的生态系统工具和支持

• 可能没有 "开箱即用 "的资源，如 block explorers, RPC providers, indexers, oracles, fiat on/off ramps，以及生态系统的资金。

新兴的 AppChain 市场结构

由于 AppChains 的特点就是在更孤立的生态系统中构建的，AppChains 最适合具有以下特性的应用程序：

• 到达一定的规模（例如用户数量、协议收入金额、TVL）和产品市场契合度

• 专用区块空间会带来的重大的产品 / 性能优势

• 对安全性和原子性的要求更少（例如 P2E 游戏、NFT 集合、加密社交）

因此，也有理由认为，大多数应用程序将继续在具有共享块空间的 L1 和 L2 上启动。此外，由于 L2 的格局仍然相当分散，我们将看到一些团队，尤其是 DeFi 协议类型的团队，会由于其安全性、流动性和原子性属性而继续选择在 L1 上推出，后者尤其重要，因为闪电贷提供了有效的无限资金资产（负债表风险为零的效率）。此外，如果非 DeFi 应用程序开发了足够大的生态系统和网络效应，它们很可能会在通用 L2 上启动并转移到特定于应用程序的 L3 或特定于应用程序的 L1。我们可以粗略地想象这个操作顺序如下：

这也是有道理的，大多数启动 AppChains 的应用程序将选择模块化执行层（特别是汇总）而不是单片链，因为它们没有引导大型验证器集所需的资金。此外，高质量的验证者不太可能选择将他们的资源用于代币市场价格低且不稳定的 AppChain。

尽管如此，随着加密行业的成熟和普及，更多的应用程序仍将继续推出自己的 AppChain，未来的 AppChain 市场结构将具有多种风格：

• 通过各种桥梁连接的特定于应用程序的整体区块链

• 连接到单片链的特定于应用程序的侧链

• 特定于应用程序的汇总，位于单片链上

• 不使用结算层的主权应用程序特定汇总

说明；不全面

AppChain 怎么设计？

在决定构建哪个 AppChain 基础架构时，需要考虑几个设计权衡：

安全类型：攻击链改变状态有多难？

• Shared：由多个异构验证器保护的状态，可能由不同方运行（例如 Polkadot 平行链、Skale）

• 隔离：应用程序本身提供的安全性；可能使用应用程序拥有的验证器或定序器，并使用应用程序的代币来获取经济利益（例如 Cosmos 链、Axie Ronin）

• 继承：底层结算 / 共识层提供的安全性（例如 zkSync、Optimism）

安全源：安全从何而来，结算又从何而来？

• 以太坊：使用以太坊作为欺诈证明、有效性证明和一般双花保护的结算层（例如 Arbitrum、zkSync）

• 非以太坊 L1：使用非以太坊安全性，并且可能具有完全不同的共识模型（例如 NEAR Aurora、Tezos 汇总）

• 应用代币：应用的代币用作加密经济安全（例如 Avalanche 子网、Cosmos 链）

权限：如何选择节点以及谁可以读取 / 写入状态？

• 无许可：任何人都可以读 / 写合约并验证状态转换（例如 Optimism、StarkNet）

• Permissioned-by-choice：只有列入白名单的验证者 / 开发者才能读 / 写 / 验证链（例如 Polygon Supernets、Avalanche Subnets）

可组合性：流动性和状态在同一生态系统中的其他应用程序之间移动是否容易和安全

• Full : 移动到任何具有最小延迟和最大安全性的应用程序（例如 Polkadot XCMP、Cosmos IBC）

• Limited：在连接性、延迟和 / 或安全性方面存在限制（例如 Avalanche 子网、多边形超网）

最终性：交易何时被视为最终性？（假设概率最终被认为是最终的）

• Instant：通常使用 BFT 共识机制（例如 NEAR Aurora、Evmos）

• 最终：通常使用汇总，一旦块已发布到 L1（并假设数据可用），则可以将交易视为最终交易（例如 Arbitrum、zkSync）

Gas 货币：用户使用哪种代币支付交易费用？

• 应用程序 token：通常应用程序 token 本身运行在特定于应用程序的 L1 或 L2 上（例如 Avalanche Subnets、Osmosis）

• 无：L1 或 L2 验证器或应用程序为用户提供硬件成本补贴。（例如 AltLayer、Skale）

还有其他几个更直接的因素：

• 所需权益：应用程序拥有验证者来保护其链所需的权益数量

• 每秒事务数 (TPS)：吞吐量的主观衡量标准，因为事务的大小可能会有所不同（即，较大的事务将导致较低的 TPS，反之亦然）

• EVM 支持：无需开发人员修改其代码库即可同时支持 Solidity 和 EVM 操作码的能力

我们可以根据这些因素映射现有的 AppChain 解决方案：

截至 2022 年 10 月 3 日；不全面

结论

尽管 AppChains 存在问题，但它们的持续增长表明了开发人员的需求。正如 Apple 所证明的，垂直整合通常会带来更好的用户体验；同样，区块链开发人员将寻求提供 AppChains 支持的完全优化的 Web3 应用程序。也就是说，AppChains 并不适合所有人，开发人员在投入资源启动应用程序之前，应深入考虑其应用程序的需求和权衡。

但是，在未来几年内，我们会观察到 AppChains 对安全模型经济学、货币化策略、平台防御性、整个堆栈的整体价值累积以及对加密市场结构的二阶有许多影响，这些影响是令人兴奋的。

非常感谢 Josh Bowen、Cem Özer、Pseudotheos 和 Dan Elitzer 对本文的贡献。