AppChain發展詳解，未來還有哪些機會值得關注？

過去，區塊鏈應用主要圍繞貨幣與金融領域展開。然而近幾年，相較於其它品類，藝術、遊戲與音樂等領域的區塊鏈應用數量激增。同時，用戶數量呈超線性增長，為底層基礎設施帶來不小的壓力，降低了終端用戶體驗。因此，應用需要更加寬泛的自定義空間以及更強大的業務模型來滿足自身的發展需要。

為解決這些問題，基於特定應用的區塊鏈（亦稱 AppChain）逐漸進入視野。簡單來說，AppChain 是指將區塊空間專門用於特定應用的區塊鏈。構建在 AppChain 上的應用程序可以自定義其堆棧的不同層，如安全模型、費用Token以及寫入權限等。

其實，AppChain 並非一個新概念。比特幣網路即可被視為「數字黃金」的專用區塊鏈；同理，Arweave 也可以被看作是用作永久儲存的應用鏈。也就是說，AppChain 的設計不僅包含單片區塊鏈（如 Osmosis），還包括處理應用狀態轉換的模塊化執行層（如 Rollups，Sidechains，Plasma），最終依賴於單獨結算或共識層來完成。

事實上「Layer」（如 L2、L3 等）在大多數情況下是指信任成本最低的區塊鏈，同時這種區塊鏈兼具最低雙向信任成本的銜接橋屬性。

AppChain 的歷史

經過多年演變，區塊鏈才發展出可供開發人員使用的 AppChain 底層基礎設施。即便 Cosmos 和 Polkadot 早在 2016 年就開始推廣這一概念，但到了 2021 年初才付諸實踐（即 IBC 與平行鏈）。在可擴展性方面，鏈上應用對以太坊的區塊空間需求不斷增加。2020 年底，以太坊的超高交易費用使開發人員意識到尋找替代解決方案已經迫在眉睫。彼時，可擴展性研究聚焦在 Optimistic、ZK-rollups 以及側鏈（統稱為「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（原名 LazyLedger）於 2019 年提出了模塊化設計的新概念，該設計將傳統單片區塊鏈的執行、結算與數據可用層分開，使基於特定應用的區塊鏈落地成為現實，並且堆棧的其它部分也不需要重新構建。

如今已有多個平台提供 AppChain 的底層基礎設施。雖然其中一些僅支持共享區塊空間層（如 Optimism、zkSync），但如果開發人手充足的話，很可能會對專用執行層提供支持。

雖然 AppChain 的上線與交互一直非常困難，但在過去幾年中，開發人員與用戶都在逐步接受這種方式。Axie 在 2021 年初推出了其以太坊側鏈 Ronin；DeFi Kingdoms 在 2021 年底宣布從 Harmony 遷移至 Avalanche 子網；有約 46% 的 Apecoin 社區成員希望在 2022 年中旬推出 ApeChain；dYdX 在 2022 中旬宣布產品的 V4 版本將使用 Cosmos SDK 技術構建獨立的 L1。目前，已經有無數的應用構建在跨各種平台的 AppChain 當中。

選擇 AppChain 的原因

越來越多的開發人員不再在共享的區塊空間上部署智能合約，反而選擇 AppChain，主要原因有三點：

性能

· 由於 DApp 在同一網路中互相競爭區塊空間，因此某個當下流行的 DApp 常常會消耗大量資源，導致其它 DApp（如 Polygon、Arbitrum）交易成本上升，網路出現延遲。

· AppChain 使交易成本與低網路延遲保持在項目方可預測的範圍之內，從而為終端用戶帶來更好的使用體驗。

可定製性

· 隨著 DApp 的受眾逐漸增加，開發人員需要為用戶不斷優化產品。

· 規模較大的應用需要在設計中做出權衡，如吞吐量、最終性、安全級別、許可、可組合性、生態系統一致性等。例如作為 validator 對硬體可能有較高的性能要求（如運行 SGX 或 FPGAs 來生成零知識證明）。

· 對於傳統機構來說，AppChain 提供了一種進入 Web3 的方式，無需從開始就接受完全無需許可的方式；如公司可以要求 validator 進行 KYC；預篩出想要在其網路上做開發的工程師；選擇跨鏈的起點與終點。

價值捕獲

· 雖然通用型擴展方案降低了交易成本，保留了安全性與開發體驗，但這些方案為幾乎沒有為開發人員提供獲得其它收益的機會。

· 另一方面，現有產品對於 AppChain 來說有著極強的商業示範效應，開發者可以在其它生態中 fork 出現有協議並獲得收益（如 AMM 機制或 NFT 交易的手續費）。

· AppChain 的 Token 可以從其它安全模型（如質押 Token 或 gas Token ）類 Token 的價格下跌以及該 Token 在市場中重新回歸到 L2 或 L1 Token 應有價值的過程中獲得收益。

· 此外，應用可通過運行自己的 sequencer 或 validator 來避免 MEV，這樣便有機會產生新的加密商業模型，如 dYdX 的 validator 可以成為做市商，為用戶降低或者免除手續費，但沒有提供最優執行價，類似 Robinhood 的「賣訂單流」（PFOF,Payment for Order Flow）模型。

· 再舉一個例子，許多成功的遊戲中都有大量的模組、擴展組件、皮膚等元素，而且遊戲在發展的過程中開發商會儘可能地使模組便於修改。只不過大多數時候，這些修改都是由沒有獲得經濟利益的業餘遊戲玩家來完成的。如果這些遊戲在 AppChain 上的話，模組就可以將這個 IP 擴展到 Rollup 上通過共用區塊空間獲得經濟收益。

AppChain 存在的問題

有限的可組合性與不可分割性

· AppChain 一定程度上將自身與底層基礎設施以及其它生態隔離開來。雖然沒有打破可組合性（使用同種 VM 的跨鏈橋實現跨鏈），但卻打破了不可分割性（一種「全完成」或者「全部不完成」的屬性，即要麼單筆交易中的子操作全部執行，要麼全都不執行）。

· 也就是說，雖然不可分割性是所有在同一結算層的應用的獨特屬性，但它對許多應用來說並不是最重要的（比如，P2E 遊戲不是依靠閃貸來維持其經濟運行的）。

權限限制

· 假設所有的 AppChain 都具有讀寫權限，那麼由此產生的市場結構將會限制開發人員在無需許可與可組合方面的創新。用戶進行自由交易與選擇退出的權力也會受到限制，反而使本應加密行業解決的問題，再次出現了。

流動性割裂

· 在 AppChain 的使用中，其它底層的流動性與資產需要使用跨鏈橋過渡到生態系統當中，反之亦然。雖然使用跨鏈橋無可厚非，但站在用戶角度確實增加了交互中的不便。

自反安全性模型

· 如果將應用的 Token 作為安全模型，可能會出現邊緣案例，即如果 Token 的價值歸零，那麼應用中的經濟系統便再無安全性可言。

資源浪費

· 如果鏈上應用使用率過低，那麼 AppChain 本身造成了資源浪費。如果 AppChain 有專用的 validator，這些 validator 可以將資源部署到其它生態。

額外的開發成本

· 與部署智能合約不同，AppChain 開發過程較為繁瑣，所以在管理周邊基礎設施（如 validator 或 sequencer）時增加了技術難度。

生態系統工具與技術支持受限

· 沒有可供使用的「現成」資源，如區塊瀏覽器、RPC 供應商、索引器、預言機、法幣通道以及生態基金。

AppChain 的新興市場

由於在建立獨立生態系統時可能會遇到如上所述的缺陷，AppChain 比較適合具有如下特徵的應用：

· 在某方面達到一定規模，如用戶量、協議收入、TVL、產品市場契合度等

· 在專用區塊空間有顯著的產品或性能優勢

· 對安全性與不可分割性要求較低，如 P2E 遊戲、NFT、加密社交等

因此，有理由推斷大多數應用還會繼續在共享區塊空間的 L1 與 L2 上推出。此外，由於 L2 的現有格局仍然非常分散，出於安全性、流動性以及不可分割性的考量特別是 DeFi 協議還是會選擇在 L1 上推出。需要強調的是，不可分割性在這裡尤為重要，因為即使在資產負債表為零的情況下，利用閃電貸仍然可以獲得有效且無限使用的資金。

此外，如果非 DeFi 應用的發展達到了一定規模，形成足夠大的生態與網路效應，它們很可能會選擇在通用的 L2 上推出產品，然後轉移到以應用程序為主的 L3 或者直接在基於這款應用的 L1 上推出，發展過程大致如下：

多數應用在決定開發 AppChain 的時候會選擇模塊化執行層（特別是 Roll-ups）而非單片區塊鏈，因為他們沒有啟動大型 validator set 所需的資金。此外，高質量的 validator 不會選擇 Token 價格較低或者不穩定的 AppChain 進行部署。

即便如此，隨著加密行業的發展與普及，大多數應用還是會繼續推出自己的 AppChain。未來的 AppChain 市場結構也十分多樣化：

· 通過不同跨鏈橋來連接的基於特定應用的單片區塊鏈

· 連接單片區塊鏈且基於特定應用的側鏈

· 在單片區塊鏈中基於特定應用的 Roll-ups

· 無需使用結算層且獨立的特定應用 Roll-ups

AppChain 的設計空間

在選擇在哪種 AppChain 上進行開發時，需要參考以下幾點做出權衡：

安全類型：攻擊該鏈並更改其狀態的難度有多大？

· Shared：由多個異構 validator 保護，大機率由不同的對象負責運行

（如 Polkadot 的平行鏈、Skale）

· Isolated：安全性由應用本身提供保障；很可能使用的是應用自帶的 validator 或 sequencer；將應用的 Token 用於質押，獲得經濟收益

（如 Cosmos、Axie Ronin）

· Inherited：應用底層結算或共識層來保障安全性

（如 zkSync、Optimism）

安全來源：安全性的保障的從何而來？結算髮生在哪裡？

· Ethereum：將以太坊作為欺詐證明、有效性證明以及常見雙花攻擊的結算層，保證網路安全

（如 Arbitrum、zkSync）

· Non-Ethereum L1：利用非以太 L1 的安全性，大機率有著完全不同的共識模型

（如 NEAR Aurora、Tezos rollups）

· 應用 Token ：將應用 Token 作為生態的安全性保障

（如 Avalanche 的 Subnets、Cosmos 生態中的子鏈）

許可：節點是如何被選出的？誰可以讀取或寫入狀態？

· 無許可：任何人都可以讀寫合約，驗證狀態轉換

（如 Optimism、StarkNet）

· 選擇性許可：只有被列入白名單的 validator 或開發者才可以讀寫或驗證鏈的狀態（如 Polygon 的 Supernets、Avalanche 的 Subnets）

可組合性：在同一生態中，流動性與狀態流轉至不同應用的難易程度與安全性是怎樣的？

· 無限制: 可以轉移到任意應用，延遲小，安全性高

（如 Polkadot 的 XCMP 協議、Cosmos 的 IBC 協議）

· 有限制：在連接性、延遲或安全性方面存在限制

（如 Avalanche 的 Subnets、Polygon 的 Supernets） 

最終性：交易在何時被認為是處於完成的狀態？

（假設「最終性」即是真實的完成狀態）

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

· 有條件要求：通常使用 rollups 方案，一旦區塊被發送至 L1（假設數據可用），交易即可被視為最終完成（如 Arbitrum、zkSync）

Gas Token ：用戶使用哪種 Token 作為 gas 進行支付？

· 非應用 Token ：通常是應用所在 L1 或 L2 的底層資產

（如 Ethereum、Evmos）

· 應用 Token ：應用 Token 本身運行在基於特定應用的 L1 或 L2 上

（如 Avalanche 的 Subnets、Osmosis）

· 無 gas：L1 或 L2 的 validator 或應用本身為用戶提供硬體成本補貼

（如 AltLayer、Skale）

其它重要參考因素：

·質押要求：應用需要質押多少 Token ，可使 validator 保證網路的正常運行

· TPS：吞吐量的主觀衡量標準會隨著交易規模的大小產生變化

（即較大規模的交易會使吞吐量降低，反之亦然）

·支持 EVM：無需開發人員修改其代碼庫即可同時支持 Solidity 以及 EVM 操作碼

根據以上幾點，可以將現有的 AppChain 解決方案總結為：

總結

儘管 AppChain 目前存在各種問題，但開發人員的需求表明 AppChain 持續發展。正如當年的 Apple，垂直領域的整合通常會帶來更好的用戶體驗；同樣，區塊鏈開發人員會在 AppChain 的賦能下，交付出更加優質的 Web3 應用。但 AppChain 並不適合所有場景，工程師應該在投入精力做開發前，深入思考應用的需求，權衡利弊。此外，有諸多因素會對安全模型經濟學、貨幣化策略、平台防禦性、堆棧整體價值的自然增長以及加密市場結構的次級效應產生影響，AppChain 在接下來幾年的發展值得期待。

原文連結