應用鏈的興起將帶來哪些風險和機遇？

雖然區塊鏈的最初應用圍繞貨幣和金融，但在過去幾年中，藝術、遊戲和音樂等領域的應用激增。與此同時，這些應用程序中的聚合用戶數量一直呈線性增長，給底層基礎設施帶來壓力並降低用戶體驗。此外，隨著這些應用程序的擴展，它們越來越需要更多的可定製性和更強大的業務模型。

解決這些問題的一種新興業務模式是構建特定於應用程序的區塊鏈，稱為「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 市場的交易費用）。他們的Token受益於被用作安全模型（即質押 Token 或 Gas Token ）的額外 Token 。此外，應用程序能夠通過運行自己的排序器或驗證器來捕獲 MEV，這可以為新的加密業務模型創造機會；例如，dYdX 的驗證者（可能是做市商）可以為用戶提供低費用或免費費用，但給他們的執行價格略低，類似於 Robinhood 使用的按訂單付費的模式。再舉一個例子，許多成功的遊戲都有大量的模組、皮膚等，並積極嘗試儘可能多的調整。但大多數時候，建模是由難以賺錢的業餘遊戲玩家完成的。如果該遊戲構建在 AppChain，那麼模組可以在 rollup 之上擴展該 IP，並通過使用該鏈獲利。

AppChains 的問題

然而，任何事都是雙刃劍：

有限的可組合性和原子性

AppChains 在一定程度上隔離了其他生態系統中的基礎設施和用戶。雖然這不會破壞可組合性（你只需要在相同的 VM 上有足夠好的橋接），但它確實破壞了原子性（一種「全有或全無」的屬性，即單個事務中的所有子操作要麼都被執行，要麼一個都不執行）。

也就是說，雖然原子性是所有應用程序都位於同一結算層的特殊屬性，但它對許多應用程序來說並不重要（例如，P2E 遊戲不依賴閃電貸來維持經濟運行）。

重建圍牆花園

作為一個思想實驗，如果所有 AppChain 都具有讀 / 寫權限，由此產生的市場結構將限制開發人員的無需許可和組合創新，以及用戶自由交易的能力，這將讓 Crypto 重新回到旨在解決的問題上。

流動性分散

來自其他層或鏈的流動性資產將需要跨鏈橋連接到 AppChains，雖然通過橋接基礎設施可以做到這一點，但它為用戶增加了額外的「摩擦」。

自反安全模型

如果使用應用程序 Token 作為安全模型，則存在一個邊緣情況，即如果 Token 的價格下降到 0，應用程序將不再具有經濟安全性。

資源浪費

如果應用程序得不到足夠的使用，AppChains 可能會浪費資源（物理或經濟）。如果 AppChain 具有專用的驗證器，那麼這些驗證器可以更有效地將其資源部署到其他地方。

額外的複雜性

因為它不像部署智能合約那麼簡單，所以在管理額外的基礎設施（例如排序器或驗證器）時會增加額外的複雜性。

有限的生態系統工具

可能沒有「開箱即用」的資源，例如區塊瀏覽器、RPC 提供者、索引器、預言機和生態系統資金。

新興的 AppChain 市場結構

由於在更孤立的生態系統中構建有許多缺點，AppChains 最適合具有以下特徵的應用程序：

達到了規模（例如用戶數量、協議收入、TVL）和產品市場契合度性能能為產品帶來顯著的優勢對安全性和原子性的要求更少（例如 P2E 遊戲、NFT、加密社交）

因此，我們有理由認為大多數應用程序將仍繼續在公共 L1 和 L2 上啟動。此外，由於 L2 的格局仍然相當分散，我們將看到 DeFi 協議由於其安全性、流動性和原子性屬性而繼續在 L1 上推出。此外，如果非 DeFi 應用程序有了足夠大的生態系統和網路效應，它們可能會在通用 L2 上啟動並轉移到特定於應用程序的 L3 或特定於應用程序的 L1。我們可以粗略地想象這個操作順序如下：

還有一個原因是，大多數啟動 AppChains 的應用程序將選擇模塊化執行層（特別是 rollups）而不是單片鏈，因為它們沒有吸引大型驗證器群所需的資金。此外，高質量的驗證者不太可能選擇將他們的資源用於 Token 價格低且不穩定的 AppChain。

儘管如此，隨著加密行業的成熟和普及，更多的應用程序仍將繼續推出自己的 AppChain，未來的 AppChain 市場結構將有多種形式：

- 通過各種跨鏈橋連接的 AppChains 

- 連接到 L1 的特定於應用程序的側鏈

- 不使用結算層的特定於應用程序的 rollups

AppChains 如何設計

在決定構建 AppChain 的基礎架構時，需要考慮幾個設計權衡：

安全類型：通過攻擊來改變狀態有多難？

共享：由多個異構驗證器保護的狀態，可能由不同方運行（例如 Polkadot 平行鏈、Skale）

隔離：應用程序本身提供的安全性；可能使用應用程序擁有的驗證器或排序器，並使用應用程序的 Token 來獲取經濟利益（例如 Cosmos 鏈、Axie Ronin）

繼承：底層結算 / 共識層提供的安全性（例如 zkSync、Optimism）

安全來源：安全從何而來，結算又從何而來？

以太坊：使用以太坊作為欺詐證明、有效性證明和一般雙花保護的結算層（例如 Arbitrum、zkSync）

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

應用 Token ：將應用程序的 Token 用作加密經濟安全（例如 Avalanche 子網、Cosmos 鏈）

權限：如何選擇節點，以及誰可以讀取 / 寫入狀態？

無許可：任何人都可以讀 / 寫合約並驗證狀態轉換（例如 Optimism、StarkNet）

選擇性許可：只有列入白名單的驗證者 / 開發者才能讀 / 寫 / 驗證鏈（例如 Polygon Supernets、Avalanche 子網）

可組合性：流動性和狀態在同一生態系統中的其他應用程序之間行動是否容易和安全？

全部 : 行動到任何具有最小延遲和最大安全性的應用程序（例如 Polkadot XCMP、Cosmos IBC）

有限：在連接性、延遲或安全性方面存在限制（例如 Avalanche 子網、Polygon Supernets）

最終性：交易何時被視為最終性？

即時：通常使用 BFT 共識機制（例如 NEAR Aurora、Evmos）

最終：通常使用 rollups，一旦區塊被發布到 L1（並假設數據可用），交易就可以被視為最終交易（例如 Arbitrum、zkSync）

Gas Token ：用戶使用哪種 Token 支付交易費用？

非應用程序 Token ：通常是構建應用程序的 L1 或 L2 的基礎資產（例如 Ethereum、Evmos）

應用程序 Token ：通常應用程序的 Token 本身運行在特定於應用程序的 L1 或 L2 上（例如 Avalanche 子網、Osmosis）

無 Token ：L1 或 L2 驗證器或應用程序為用戶提供成本補貼。（例如 AltLayer、Skale）

還有其他幾個更直接的因素：

所需權益：應用程序需要驗證者來保護其鏈所需的權益數量

每秒事務數 (TPS)：吞吐量的主觀衡量標準，因為事務的大小可能會有所不同（即，較大的事務將導致較低的 TPS，反之亦然）

EVM 支持：無需開發人員修改其代碼庫即可同時支持 Solidity 和 EVM 操作碼的能力

我們可以根據這些因素映射現有的 AppChain 解決方案：

結論

儘管 AppChains 存在問題，但它們的持續增長表明了開發人員的需求。正如蘋果公司所證明的那樣，垂直整合通常會帶來更好的用戶體驗；同樣，區塊鏈開發人員將尋求提供 AppChains 支持的完全優化的 Web3 應用程序。也就是說，AppChains 並不適合所有人，開發人員在投入資源啟動應用程序之前，應深入考慮 / 權衡其應用程序的需求。

AppChains 對安全模型經濟學、貨幣化策略、平台防禦性、整個堆棧的整體價值累積以及對加密市場結構有許多影響，這些影響將在未來幾年內被我們觀察到。

原文連結