アプリケーションチェーン理論: なぜ Cosmos エコシステムは繁栄するのでしょうか?

原文: https://rainandcoffee.substack.com/p/the-application- specific- chain-thesis?utm_source=%2Fprofile%2F14239335-rainandcoffee&utm_medium=reader2

著者: レインアンドコーヒー

過去数週間で、アプリケーションやビルダーが独自のアプリケーション固有のチェーンを構築することを決定したか、そうすることに関心を表明したため、より広範な Cosmos エコシステムが復活しました。これは、より広範な IBC エコシステムにも影響を与えた Terra エコシステムの終焉に続くものです。ただし、スタック全体が技術的に非常に優れたパフォーマンスを発揮していることに留意することが重要であると考えています。トランザクション量が非常に不安定であるにもかかわらず、Tendermint、ABCI、カスタム VM を使用した Cosmos SDK を介した内部チェーン上だけでなく、IBC 経由でチェーン間で内部および外部のメッセージとアセットの転送を処理できることがわかりました。この記事では、アプリケーション固有のブロックチェーンの台頭の背後にある議論と、それがもたらす主権、構成可能性、相互運用性が、次のサイクルで次の「キラー アプリ」とエコシステムを構築するために重要である理由を説明することを目的としています。

このトピックを掘り下げる前に、コンセンサスに達する必要があるため、Cosmos エコシステムのいくつかのユニークなテクノロジーを理解しやすい方法で簡単に紹介します。

ABCI と Cosmos SDK を使用した Tendermint ベースのチェーンの全体的なアーキテクチャは次のとおりです。

コスモスSDK

Cosmos SDK は、ブロックチェーン開発者が VM に依存しない方法でアプリケーション層ロジックを構築できるようにするモジュール式ツールのセットです。 Cosmos SDK は、ABCI 経由で Tendermint と連携するように設計されています。アプリケーション固有のブロックチェーンの作成を可能にするフレームワークであることに加えて、プロトコルに依存しないガバナンス、トランザクションおよびステーキングのメカニズムなどのさまざまなカスタマイズ オプションも可能になります。 SDK は、アプリケーション ロジック層で必要なタスクのほとんどを処理します。つまり、開発者は SDK を完全にゼロから構築する必要はありません。 Tendermint コンセンサス エンジンから受信したトランザクションをルーター経由で処理し、状態の変化とともにメッセージを適切な処理モジュールに送信します。

ABCI

ABCI は、ブロックチェーンのアプリケーション部分と、コンセンサスおよびネットワーク メカニズムを提供する Tendermint 状態レプリケーション エンジンを接続するインターフェイスです。 ABCI はブロックチェーン スタックの分割を実現します。これは、ブロックチェーン アプリケーション部分を仮想マシンから独立させることができるため、スタックのアプリケーション部分に任意の仮想マシンと実行環境を使用できることを意味します。例としては、Junowasm、Cosmwasm、Agoric の Hardened Javascript、さらには Cosmwasm の Secret バージョン (TEE の使用を可能にする) などがあります。 Tendermint 自体は、アプリケーション部分への 3 つの ABCI 接続を作成します。これらは、メモリプールがブロードキャストするときのトランザクションの検証、アプリケーションとコンセンサス エンジン間の接続、およびブロック提案に使用してアプリケーションの状態をクエリする機能を担当します。

テンダーミント

Tendermint Core は、Cosmos エコシステムのチェーンのコンセンサスとネットワーク層を担当します。コンセンサス層は、ネットワーク参加者間のコンセンサス アルゴリズム プロセスを通じてトランザクションの有効性と順序を保証します。ネットワーク層は、システム内のノード間のポイントツーポイント通信を促進し、サードパーティのアプリケーションとノードが対話できるようにする役割を担います。コンセンサス層。

Tendermint は Byzantine Fault Tolerant (BFT) コンセンサス モデルを使用し、即座にファイナリティを達成します。 BFT プロセスは、提案されたブロックの最終コミット フェーズの前に 3 つのフェーズを経ます。 3 つの段階は次のとおりです。

• 提案段階では、ブロックが特定の高さに指定されます。
• 事前投票段階では、検証者の 2/3 が提案されたブロックに対して事前投票します。
• プリコミットステップでは、検証者の 2/3 が提案されたブロックをプリコミットします。

IBC

Inter-Blockchain Communication(IBC) の中核は、同種のブロックチェーンのためのクロスチェーン情報転送プロトコルです。これは、同様の機能を共有するチェーンを接続することを意味します。この場合、Tendermint コンセンサス アルゴリズムによって提供されるインスタント ファイナリティと、軽量クライアント機能を備えたチェーンが接続されます。 IBC の仕組みは、相互に接続することに関心のある 2 つのチェーンがターゲット チェーンのガバナンスを提案することです。これは通常、Cosmos Hub または Osmosis 経由で行われます (現在、Osmosis は 45 に接続し、Cosmos は 40 を接続しています)。これは、プロトコル レベルで合意があることを意味するため、外部ブリッジで信頼できるサードパーティを使用する必要はありません。

次に、2 つのチェーンには、2 つのチェーン間のコンセンサス状態を暗号的に検証するための互いのチェーン上のライト クライアントと、2 つのチェーン上のライト クライアント間で情報を受け渡すためのリピーターが必要です。リレーはアクティビティ、つまりノード間で情報を交換できるようにするため、またノードが正常に合意に達するために必要です。実際の状況を調べてみましょう。

これは、ブロックチェーンを接続する 2 つのバリデーターに信頼の仮定があるため、他のタイプのクロスチェーン ブリッジやメッセージング プロトコルよりも信頼の仮定がはるかに小さいことを意味します。たとえば、Polkadot エコシステムの XCMP では、信頼の前提はリレー チェーン (Polkadot) のみにあります。

Cosmos エコシステムにおける IBC の互換性と普及性、および IBC が接続するチェーンの数を示すために、現在のリアルタイム接続スケールを見てみましょう。

ICS

ICSはInterchain Standardの略で、IBCで発生するチェーン間のトランザクション設定パラメータを使用します。 ICS は基本的に IBC トランザクションのモジュール仕様であり、2 つのチェーンが IBC を使用するには、同じ ICS が必要です。

興味深いユニークな ICS の 1 つは、インターチェーン アカウントとしても知られる ICS-27 です。

ICS-27

インターチェーン アカウントにより、構成可能性、つまり相互運用性が可能になります。これにより、チェーン上の人々はデータを交換できるだけでなく、あるチェーン上の 1 つのスマート コントラクトから別のチェーンに状態を書き込むこともできます。これは、アセットやメッセージが転送されるときにさまざまなインターフェイス間を移動する必要がなく、ユーザーはトランザクションのエンドポイントを指定するだけでソース チェーン上の単一のインターフェイスを利用できることを意味します。 ICS-27 対応チェーンは、他の ICS-27 対応チェーン上にアカウントを作成し、IBC トランザクションを通じてそれらのアカウントを制御できます。インターチェーン アカウントは通常のアカウントのすべての機能を保持しますが、IBC を介して別のチェーンまたはエンドユーザーによって操作されるため、ソース チェーンの所有者は、ターゲット チェーンに登録するクロスチェーン アカウントに対する完全な制御を維持できます。

IBC トランザクション後の手順は、各チェーンが持つ必要のある ICS 仕様に従って実行されます。これは、トランザクションをアプリケーション固有からアプリケーションに依存しないものにすることを意味します。つまり、さまざまなネットワークにわたって真のコンポーザビリティを可能にします。

インターチェーンセキュリティ

チェーン間セキュリティにより、1 つのチェーンまたはハブが他のチェーンのブロックを生成できるようになります。バリデーターは、各チェーンに 1 つずつ、2 つ (またはそれ以上) のノードを実行しますが、メイン チェーンにネイティブ トークンをステークするだけで十分です。これは、IBC レベルのプロトコルであるクロスチェーン検証によって可能になります。サブチェーンは IBC を使用してメインチェーンと通信し、クロスチェーン検証を使用してどのバリデーターがチェーン間セキュリティに参加しているかを追跡します。このようにして、メインチェーンでロックされた値から得られるセキュリティは、子チェーンと共有されます。したがって、コンシューマ/サブチェーンは、独自のバリデータを設定することなく、メインチェーンからセキュリティを獲得します。これにより、資本負担が軽いアプリケーションは、既存のバリデーターの強力なレベルのセキュリティを維持しながら、独自のチェーンを簡単に起動できるようになります。

メインチェーンは一連のサブチェーンのブロックを生成する責任を負い、バリデーターは検証しているチェーンからステーキング報酬を受け取ります。また、スラッシュはバリデーターが悪意のある行為を行うのを防ぐのに役立ちます。

要約する

アプリケーション固有のブロックチェーンにより、いわゆるブロック空間の「リポジトリ」が可能になります。ブロックチェーン スタックをサプライ チェーンとして考える場合、スタックの各部分のブロック スペースは、技術的には、アプリケーションが属するチェーン/レイヤー上のアプリケーションによって「購入」されます。これは、同じブロック スペースに存在するガスの料金を支払う無数の異なるアプリケーションに参加することを意味し、非常に混雑し、競争が激しくなり、料金が上昇します。

何千ものアプリケーションが存在する非常に混雑したモノリシックチェーンによって引き起こされるこの料金の高騰は、ユーザーに押し付けられ、ユーザーは重いコストを負担しなければなりません。その良い例が Osmosis です。Osmosis では、アプリケーション自体が特定のアプリケーション チェーン上でエンド ユーザーが支払う料金をより適切に制御し、料金を一定のレベルに保つことができます。

このようなアプリケーションは倉庫としてチェーン X や Y に依存しないため、店舗の在庫リスクと同様に、アプリケーションの平均手数料が高くなるリスクを負うことになります。これは、アプリケーション自体、ひいてはコミュニティが在庫リスクに参加し、管理できることを意味します。これはリソースの価格設定の効率化につながり、ひいてはアプリケーションの経済性の向上につながります。

アプリケーションは、それが存在するチェーンの所有者であるため、料金体系を自己管理できます。つまり、ユーザーは、存在するチェーンの影響を受けなくなり、チェーン上の各リソースのコストを決定できます。

これに加えて、基盤となるテクノロジー スタックによって実現される柔軟性により、ネイティブのクロスチェーン メッセージング システムにより、より大規模なエコシステム内のチェーン間の構成可能性を維持しながら、アプリケーション層での最適化が可能になります。これにより、構成可能性にはサードパーティの信頼がまったく必要なくなります。 。

Cosmos が普及する前は、アプリケーションとインフラストラクチャ (チェーン) の間に明確なギャップがありましたが、IBC を使用した特定のアプリケーション チェーンはこの障壁を打ち破り、アプリケーションが接続された構成可能なインフラストラクチャになることを可能にします。