应用链的兴起将带来哪些风险和机遇？|区块链

　　原文标਩题：《应¡用链的兴起将带来哪些风险和机遇ધ？未来将会如何发展？ 》

　　原文作者：Dm"itriy Berenzon੘，1kx° 

　　分析师原文编译æ：白泽研究院❄

　　虽然ⓦ区块链的最初应用围绕货币和金融，但在过去几年中，艺术、游戏和音乐等领域的应用激增。与此同时，这些应用程序中的聚合用户数量一直呈线性增长，给底层基础设施带来压力并降低િ用户体验。ⓐ此外，随着这些应用程序的扩展，它们越来越需要更多的可定制性和更强大的业务模型。

　　解决这些问题的一种新兴业务模式是构建特定于应用程序的区块链，称为‘௄AppChains’（应用链）。构建ર AppChains 的应用程序可以自定义其堆栈的多个层，例如其ੑ安全模型、手续费用和写入权限等。

　　AppChains 不是一个新概念；比特币可以被▩认为是用于数字黄金的特定应用区块链，而 Arweave 则可以用于永久存储。也就是说，AppChain 的设计不仅包含单片区块链（例如 OsmoÅsis√），还包含处理应用程序状态转换的模块化执行层（例如 rollups、sidechains、plasma），但依赖于单独的结算层或共识层来实现最终性。

　　事实上，‘层’（如 L2，L3 等）在大⊂多数情况下，只是信઱任最小化的区块链，具有双向最小化信任的跨઼链桥。

▤　　在本­文¹中，我将：

　　概述િ AppChains 的历史解释 AppChains 的优缺点描述未来 AppChain 市场结构概述 AppChain 如何设计比较当前已有੐的不同 AppChain 解决方案Β

　　AppChain 花了很多年才出现。虽然 Cosmos 和 Polkadot 早在 2016 年就提出并推广了这一概念，但他们š直到 2021 年初才Ð完全启动他们的网络（分别具有 IBC 和平行链功能）。与此同时，在可扩展性方面，由于以太坊上用户的需求不断增加，到 2020 年底，ETH 交易费用变得出奇的高，应用程序开发人员迫切需要替代解决方案。与此同时，以太坊链外可扩展性研究正以‘L2s’的形👿式缓慢实施，Polygon、Skale、zkSync （1.0） 、StarkWare （StarkEx）、Optimism 和 Arbitrum 都在 2020 年和 2021 年推出。

　　其他基础层（‘L1’）也意识到支持 EVM（以太坊虚拟机）作≥为其业务开发工作的一ν部分的重要性；Avala࠹nche（C-Chain）、NEAR（Aurora）、Polkadot（Moonbeam）和 Cosmos（Evmos）都在 2020 年和 2021 年推出了与 EVM 兼容的链。

　　在特定于应用程序的设计方面，CeÝlestia 于 2Ψ019 年（最初作为 LazyLedger）推出了一种新颖的模块化设计，该设计<将传统单片区块链的执行、结算和数据可用性层分开，从而允许特定于应用程序的区块链，无需重建堆栈的其他部分。

　　如今，有多种平台提੭供 AppChain 基础设施。虽然其中一些目前仅提供公共区块空间（例如 Optimism、zkSync），但如果有足够的જ开发人员需求，它们很可能会推出†支持专用的执行层。

　　此外，虽然 AppChains ஻的启动和互操作问题在历来是困难的，但在过去几年中，开发人员和用户都在加速接受 AppChains。Axie 于 2021 年初推出了他们的以太坊侧链 Ronin，DeFi Kingdoms 宣布于 2021 年底从 Harmony &#266b;转移到 Avalanche 子网，Apecoin 社区约 46% 的成员仍支持构建 ApeChain，dYdX 宣布他们的 V4 版本协议将建立在使用 Cosmoõs SDK 打造的 L1 上。今天，有无数的应用程序构建在 AppChains 上。

　　开发≡人员越来越多地转向构建 AppCha∋ins 而不是在公共区块链上启动智能合约的主要原因有&#263d;三个。

　　由于 dApp 在同一网络上相互竞争，因此一个流行的 dApp 通常会消耗不成比例的资源，这会增加其他 dApp 用户的交易成本和延迟。AppChains 为项′目提供了稳定交易成本、延迟低的能力，从而为੐用户带来更好>的用户体验。

　　随着 dApp 越来越受欢迎，开发ੑ人员需要继续为用户优化他们的 dApp。大型 dApp 需要权衡某些设计选择，例如吞吐量、®最终性、安全级别、许可、可组合性和生态系统一致性等。例如，验证器可能具有高性能硬件要求（例如运行 SGX 或 FPGA 以生成零知识证明）。对于传统组织来说，AppChains 提§供了一种方法，让他们可以在无需授权的情况下进入 Web3；例如，公司可以要求 KYC 验证者删选想要在他们的网络上构建的开发人员，并选择他们想要将资产通过跨链桥连接到哪些链。

　　虽然通用的可扩展性解决方案的确降低了交易成本，同时保留了安全性和开发人员体验，但它们为开发人员提供的货币化机会很少。另一方面，AppChains 有很强的商业案例，因为 dApp 能够在其生态系统内分叉现有协议并将其货币化（િ例如，来自 AMM 或 NFT 市场的交易费用）。他们的Token受益于被用作安全模型（即质押 Token 或 Gas Token ）的额外 Token 。此外，应用程序能够通过运行自己的排序器或验证器来捕获 MEV，这可以为新的加密业务模型创造机会；例如，dYdX 的验证者ⓨ（可能是做市商）可以为用户提供低费用或免费费用，但给他们的执行价格略低，类似于 Robinhood 使用的按订单付费的模式。再举一ੈ个例子，许多成功的游戏都有大量的模组、皮肤等，并积极尝试尽可能多的调整。但大多数时候，建模是由难以赚钱的业余游戏玩家完成的。如果该游戏构建在 AppChain，那么模组可以在 rollup 之上扩展该 IP，并通过使用该链获利。

　Õ　然而，☞任何事都是双刃ε剑：

　　AppChains 在一定程度上隔离了其他生态系统中的基础设施和用户。虽然这不会破坏可组合性（你只需要在相同的 V੧M 上有足够好的桥接），但它确实破સ坏了原子性（一种‘全有或全无’的属性，即单个事务中的所有子操作要么都被执行，要♨么一个都不执行）。

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

　　ા作为一个思想实验，如果所有 AppChain 都具有读 /ਗ਼ 写权限，由此产生的市场结构将限制开发人员的无需许可和组合创新，以及用户自由交易的能¦力，这将让 Crypto 重新回到旨在解决的问题上。

　　来自其他层或链的流&#263a;动性资产将需要跨链桥连接到 Ap↑pChains，虽然通过桥ઽ接基础设施可以做到这一点，但它为用户增加了额外的‘摩擦’。

　　如果使用应用程序 Tokeૉn 作为安全模型，⁄则∝存在一个边缘情况，即如果 Token 的价格下降到 0，应用程序将不再具有经济安全性。

　　如果应用程序得不到足够的使用，AppChains 可能会浪费资¤源（物理或经济）。如果 AppChaiðn 具有专用的验证器，那么这些验证器可以更有效地将其资源部署♧到其他地方。

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

　　可能没有‘开箱即用’的资源»≤，例如ઢ区块浏览器、RPC 提供者、索引器、预言机和生态系统资金。

　　由于在更孤立的生态系统中构建有许多缺点，ØAŠppChains 最适合具੥有以下特征的应用程序：

　　达到了规模（例如用户数量、协议收入、TVL）和产品市场契合度性能能为产品带来显著的优势对安全性和原子性的要求更少（例如 P2E 游૥戏、N੟δFT、加密社交）

　　因此，我们有理由认为大多数应用程序将仍继续在公共 L1 ੨和 L2 上启动。此外，由于 L2 的格局仍然相当分散，我们将看到 DeFi 协议由于其安全性、੏流动性和原子性属性而继续在 L1 上推出。此外，如果非 DeFi 应用程序有了足够大的生态系统和网络效应，它们可能会在通用 L2 上启动并转移到特定于应用程序的 L3 或特定于ý应用程序的 L1。我们可以粗略地想象这个操作顺序如下：

　　还有一个原因是，大多数启动 AppChains 的应用程∩序将选择模块化执行层（特别是 rollups）而不是单片链，因为它们没有吸引大型验证器群所需的资金。此外，高质量的验证者不太可能选择将他们的资源用于 Token 价格低且不稳定的 AppChaiઢnહ。

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

Ó　　- 通过各种跨链桥连接的 AppöChains&nઠbsp;

ત　　- ઩连接到 L1 的特定于应用程☼序的侧链

　　- 不使用结算层的特定于λ应ਬ用ⓙ程序的 rollups

　　在决定构建 …AppૄChain 的基础架构时，需要考虑几个è设计权衡：

　　共享Æ：由多个异构验证器保护的状态，可能由不同方运行（例如 Polkadot▩ 平行链、Skal⇐e）

　　隔离：应用程序本身提供的安全性；可能使用γ应用程序拥有的验证器或排序器，并使用应用程序的 Token 来获取经济利益（例如 Cosથmos 链、Axie Ro੐nin）

æ

　　继承：底层结算 / 共识层提供的安全性（例如☺ zkSⓚync、Optimism）

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

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

ર　　应用 Token ：将应用程序的 Token 用作加密经济安全（例如 Avalanche¬ 子网、Cosmos∉ 链）

　　无许可：▒任何人都可以读 / 写合约并验证状态转换（ਬ例如 Optimism、StarkશNet）

　　选择性&#263b;许可：只有列入白名单的验证者 / 开发者才能读 / 写 / 验૟υ证链（例如 Polygon Supernets、Avalanche 子网）

　　全部 ： 移动到任何具有最小延迟和最大安全性的ä应用程序（例如 Polkadot XCMP、Cosmoηs IψBC）

　　有限：在连അ接性、延迟或安全性ਯ方面存®在限制（例如 Avalanche 子网、Polygon Supernets）

　　即时ο：通¢常使用 BFT 共—识机制（例如 NEAR Aurora、Evmos）

　　最终：通常使用 rollups，一旦区块被发布到 L1（并假设数据可用），交易就可૊以&#25d3;被视为最终交易（例如 Arbitruૣm、zkSync）

　　非应用程序 TokeÌn ：通常是构Ô建应用程序的 L1 或 L2 的基础资产（例如 ઺Ethereum、Evmos）

　　应用程序 Token◈ ：通常应用程序的 Token 本身运行在特定于应用程序的 L1 或 L2 上（例如 Avalanche&#266a; 子网、Osmos&#25d0;is）

ⓖ　　无 Token ：L1 或 Lπ2 验证器或应用程序为用户提供成本补贴。（例如 AltLayer、S⇔kale）

　　所需权益：应用程序需要验™证者来ⓑ保护其链所&#260e;需的权益数量

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

৻

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

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

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

&#25bc;24Û小时滚动播报最新的财经资讯和视频，更多粉丝福利扫描二维码关注（sinaf”inance）

新浪财经意见¥反઴馈留言板&#25d3;

&#263c;

All Rights Res♨erveગd 新浪公司 版权所有