アプリケーションチェーンの風が吹いている。その前世、現在、未来はどのようなものなのか？

撰文：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と平行チェーン機能を持っています）。同時に、スケーラビリティの観点から、Ethereum上のユーザーの需要が増加し、2020年末にはETHの取引手数料が異常に高くなり、アプリケーション開発者は代替ソリューションを切実に求めていました。その間、Ethereumのオフチェーンスケーラビリティ研究は「L2s」という形で徐々に実施され、Polygon、Skale、zkSync (1.0)、StarkWare (StarkEx)、Optimism、Arbitrumが2020年と2021年に登場しました。

他の基盤層（「L1」）も、EVM（Ethereum Virtual Machine）をサポートすることの重要性に気づきました。Avalanche（C-Chain）、NEAR（Aurora）、Polkadot（Moonbeam）、Cosmos（Evmos）は、2020年と2021年にEVM互換のチェーンを立ち上げました。

アプリケーション特化型の設計に関しては、Celestiaは2019年に（最初はLazyLedgerとして）新しいモジュール式設計を発表しました。この設計は、従来の単一ブロックチェーンの実行、決済、データ可用性レイヤーを分離し、アプリケーション特化型のブロックチェーンを可能にします。

現在、さまざまなプラットフォームがAppChainインフラストラクチャを提供しています。これらの中には、現在は公共のブロックスペースのみを提供しているものもあります（例えばOptimism、zkSync）が、十分な開発者の需要があれば、専用の実行レイヤーをサポートする可能性が高いです。

さらに、AppChainsの立ち上げと相互運用性の問題は常に困難でしたが、過去数年で開発者とユーザーはAppChainsの受け入れを加速させています。Axieは2021年初頭にEthereumサイドチェーンRoninを立ち上げ、DeFi Kingdomsは2021年末にHarmonyからAvalancheサブネットに移行することを発表し、Apecoinコミュニティの約46%のメンバーは依然としてApeChainの構築を支持しています。dYdXは彼らのV4バージョンのプロトコルがCosmos SDKを使用して構築されたL1上に構築されることを発表しました。今日、無数のアプリケーションがAppChains上に構築されています。

なぜAppChainsを選ぶのか？

開発者が公共のブロックチェーン上でスマートコントラクトを立ち上げるのではなく、AppChainsを構築することにますます移行している主な理由は3つあります。

パフォーマンス

• 同じネットワーク上でdAppが競争するため、人気のあるdAppは通常、不釣り合いなリソースを消費し、他のdAppユーザーの取引コストと遅延を増加させます。
• AppChainsはプロジェクトに安定した取引コストと低遅延の能力を提供し、ユーザーにより良い体験をもたらします。

カスタマイズ性

• dAppがますます人気になるにつれて、開発者はユーザーのためにdAppを最適化し続ける必要があります。
• 大規模なdAppは、スループット、最終性、安全レベル、許可、相互運用性、エコシステムの一貫性など、特定の設計選択を天秤にかける必要があります。例えば、バリデーターは高性能なハードウェア要件を持つ場合があります（例えば、SGXやFPGAを実行してゼロ知識証明を生成するなど）。
• 伝統的な組織にとって、AppChainsはWeb3に許可なしで入る方法を提供します。例えば、企業はKYC検証者に、彼らのネットワーク上で構築したい開発者を選別させ、資産をどのチェーンにクロスチェーンブリッジで接続するかを選ぶことができます。

価値の捕獲

• 汎用のスケーラビリティソリューションは、取引コストを削減しながら安全性と開発者体験を保持しますが、開発者に提供するマネタイズの機会はほとんどありません。
• 一方、AppChainsは強力なビジネスケースを持ち、dAppはそのエコシステム内で既存のプロトコルをフォークし、マネタイズすることができます（例えば、AMMやNFTマーケットからの取引手数料）。
• 彼らのトークンは、セキュリティモデル（すなわち、ステーキングトークンやガストークン）として使用される追加のトークンから利益を得ます。
• さらに、アプリケーションは独自のソーターやバリデーターを運営することで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）

セキュリティの出所：セキュリティはどこから来て、決済はどこから来るのか？

• Ethereum：Ethereumを使用して詐欺証明、有効性証明、一般的な二重支払い保護の決済レイヤーとして使用します（例えばArbitrum、zkSync）
• 非Ethereum L1：非Ethereumのセキュリティを使用し、完全に異なるコンセンサスモデルを持つ可能性があります（例えば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）

ガストークン：ユーザーはどのトークンを使用して取引手数料を支払うか？

• 非アプリケーショントークン：通常、アプリケーションが構築されるL1またはL2の基盤資産（例えばEthereum、Evmos）
• アプリケーショントークン：通常、アプリケーションのトークン自体がアプリケーション特化型のL1またはL2上で運営されます（例えばAvalancheサブネット、Osmosis）
• 無トークン：L1またはL2のバリデーターまたはアプリケーションがユーザーにコスト補助を提供します（例えばAltLayer、Skale）

他にもいくつかのより直接的な要因があります：

• 必要なステーク：アプリケーションがそのチェーンを保護するために必要なバリデーターの数
• 毎秒取引数 (TPS)：スループットの主観的な測定基準であり、取引のサイズによって異なる可能性があります（つまり、大きな取引は低いTPSをもたらし、逆もまた然り）
• EVMサポート：開発者がコードベースを変更せずにSolidityとEVMオペコードの両方を同時にサポートする能力

これらの要因に基づいて、既存のAppChainソリューションをマッピングできます：

結論

AppChainsには問題があるものの、その持続的な成長は開発者の需要を示しています。Appleが証明したように、垂直統合は通常、より良いユーザー体験をもたらします。同様に、ブロックチェーン開発者はAppChainsをサポートする完全に最適化されたWeb3アプリケーションを提供しようとするでしょう。つまり、AppChainsはすべての人に適しているわけではなく、開発者はアプリケーションを立ち上げるためにリソースを投入する前に、そのアプリケーションのニーズを深く考慮し、トレードオフを行うべきです。

AppChainsはセキュリティモデルの経済学、マネタイズ戦略、プラットフォームの防御性、全体のスタックの価値の蓄積、暗号市場構造に多くの影響を与え、これらの影響は今後数年で私たちが観察することになるでしょう。