さまざまなクロスチェーンプロジェクトとそのユースケースの簡単な分析

個々のクロスチェーン プロジェクトの設計について詳しく説明する前に、さまざまな種類のクロスチェーン プロジェクトのアーキテクチャの概要を説明すると役立つと考えました。

誰もが Synapse/IBC を愛し、誰もが Multichain/Hop について聞いたことがあるでしょうが、それらはどう違うのでしょうか。また、それらを理解することがなぜ重要なのでしょうか。

ブロックチェーンは、普遍性、信頼性、スケーラビリティの間の相互運用性の三難問題に直面しています。分散化はユーザーにとって重要ではないとよく言われますが、それは何も悪いことではありません。しかし、異なるブロックチェーン間の通信に関しては、悪意のある者がユーザーの資金を簡単に盗むことができないようにすることが重要です。特に暗号通貨が発展するにつれて、そのようなことが起きないようにすることが長い間開発者の焦点となってきました。

暗号通貨のような新しい分野では、その分野がまだ小さいため、プロトコルとバリデーターは自然に良好な関係を築いているが、時間が経つにつれてその分野が拡大し続けると、悪意のある者が悪事を働く機会もそれに応じて増加するという良い指摘を以前に聞いたことがあります。

前に述べたように、ブロックチェーン間の通信やロールアップも、基盤となるブロックチェーンによってすべて保証されているため、簡単に実現できます。

以前の記事で、クロスチェーン プロジェクトには主に 3 つのタイプがあると述べられていましたが、私もその見解に同意します。

Synapse、Multichain、Thorchain などの最初のタイプのクロスチェーン プロジェクトはすべて MPC (マルチパーティ セキュア コンピューティング) に依存しています。つまり、Synapse にはブロックチェーン間のトランザクションを検証するための独自のバリデーターがあります。もちろん、Thorchain のネイティブ アセットの使用など、これらすべてのクロスチェーン プロジェクト間には微妙な違いがありますが、アーキテクチャはほぼ同じです。このモデルにより、ユーザーはチェーン間のブリッジを素早く簡単に構築できるようになります。ただし、これには大きな信頼が前提となります。従来のブロックチェーンは同じセキュリティ モデルを持っているためトラストレスですが、このタイプのクロスチェーン プロジェクトでは、2 つのブロックチェーンが相互にトランザクションを渡すだけでなく、MPC バリデータ グループ (Thorchain/Synapse) も信頼する必要があります。もちろん、Thorchain では検証者が検証するルーンの量の 2 倍を結合することを要求するなど、セキュリティを向上させる方法はありますが、それでも一定のリスクは残ります。これには、Multichain/Wormhole などのプロトコルのセキュリティ脆弱性で最近確認されたように、スマート コントラクトのリスクが伴います。

最初のタイプのクロスチェーン プロジェクトと同様に、Cosmos と IBC はアーキテクチャ構築において異なるモデルを持っています。異なるブロックチェーン間に仲介者がいるというよりは、ブロックチェーン自体が別のブロックチェーンからのトランザクションを検証すると言った方が正確です。外部バリデータのセキュリティ モデルを信頼するよりも、チェーン自体がバリデーターであることを信頼する方が適切です。

このタイプのクロスチェーン プロジェクトの欠点は、カスタム構成が必要になることです。 IBC と同様に、最終合意に迅速に到達できるチェーンと、この目標を達成するために設定されたカスタム ライト クライアントでのみ機能します。 Tendermint、Snowball、PoW、Nightshade など、さまざまなコンセンサス モデルがあることを考えると、このタイプのクロスチェーン プロジェクトを使用するには、多くの追加作業が必要になることは想像に難くありません。

3 番目のカテゴリもありますが、これについてはよく考えたことはありませんが、基本的には、チェーン上のトランザクションが相手方によって検証されるシステムを構築できます。したがって、その主な前提は、2 つの独立したチェーン上のバリデーターが共謀しない限り、システムは L2 (第 2 層ネットワーク) 間の Hop/Connext のように信頼できないということです。これを実行することの欠点は、これに基づいてクロスチェーン スマート コントラクトを呼び出すことが難しいことです。

これら 3 つのカテゴリ以外にも、さまざまなモデルを試みているクロスチェーン プロジェクトのカテゴリが存在します。

たとえば、L0 (レイヤー 0) はチェーン インフラストラクチャではなくブリッジとなることを目指しているため、プラグ アンド プレイになり、誰もが独自のカスタム アーキテクチャを作成する必要がありません。 L0 の前提は、セキュリティ プロパティを選択することです。これにより、使用する Oracle/リレーヤーを選択でき、アプリケーションとして作成するセキュリティのトレードオフを選択できます。

IBC のようなプロジェクトにとって、これがどれだけ役立つかは想像がつくでしょう。なぜなら、その設計は信頼性がないにもかかわらず、さまざまなチェーンのコンセンサス モデルに基づいてカスタムの軽量クライアントを作成することが最大のハードルであるように思われるからです。

Nomad は、ガス料金が低く、詐欺防止暗号化を使用し、モデルの数時間の遅延のトレードオフも考慮した最適化された設計を模倣することで、クロスチェーン通信を可能にしようとしています。したがって、外部のバリデーターに依存するのではなく、通信を許可しながら必要に応じて不正なトランザクションにフラグを立てるオフチェーン オブザーバーに依存します。

現在、これらのプロジェクトでは、モジュール式の安全機能をどの程度適用すべきか、あるいはそもそも考慮する必要があるのか​​どうかについて、興味深い議論が進行中です。ただし、ZKR の volition/validium と同様に、L0 のようなモジュール アーキテクチャでは、さまざまなアプリケーションがさまざまなセキュリティ トレードオフを選択する可能性があることは想像できます。たとえば、多くの価値を転送する必要がなく、他のチェーン上のコントラクトを呼び出すだけのシンプルなブリッジを使用するアプリケーションを開発する場合は、Synapse のような MPC が適切な選択肢になります。一方、大企業で、チェーン間で大量の価値を移動するためにリソースを投資したい場合は、IBC のようなアーキテクチャが魅力的です。前にも述べたように、IBC/Nomad などの特定のアーキテクチャについてさらに詳しく掘り下げていきたいのですが、この投稿はそれらに対する私の理解の概要を示すのに役立つと思いました。