Jump Crypto：5つのマルチチェーンアーキテクチャの特徴、メリット、デメリットを詳しく解説
原題：「Flavors of Standalone Multichain Architecture》
原文編纂：Guo Qianwen、Chain Catcher
原文編纂：Guo Qianwen、Chain Catcher
概要
概要
スケーラビリティは、この分野で長年にわたって広く議論されてきたトピックです。モノリシック ブロックチェーンとモジュラー ブロックチェーン、水平スケーリングと垂直スケーリングに関する議論は、長い間コミュニティの会話の焦点となってきました。
このため、特定のアプリケーションやユースケースに特化した実行環境、またはファイナリティ（ブロックチェーン上のトランザクションがトランザクションステータス確認の状態に達した状態を指すファイナリティ）ツールを確立するという一般的な見解が浮上しました。 。このアイデアは特に、各製品と各アプリケーションのセキュリティと速度の要件に基づいたコンセンサスとコンピューティングの分離と最適化を指します。これにより、理論的には、基礎となる単一のブロックチェーンの負荷が軽減され、パフォーマンスが向上します。しかし、このアプローチは、そのようなアーキテクチャの下で相互運用性を確保するために必要なインフラストラクチャの非常に複雑なために長い間妨げられてきました。
過去数年間にわたり、私たちはさまざまな方法でこれらの課題に対処することで大きな進歩を遂げてきました。さらに重要なのは、過去数か月の間に、いくつかの独立したマルチチェーン環境の通信層が立ち上げられており、これらの通信層がこの「パズル」の最も重要なピースであると言えます。一方、過去数週間で、さらに多くの L1/L2 ブロックチェーンがアーキテクチャの調整を発表し、アプリケーション固有のブロックチェーンにすぐに使えるインフラストラクチャを提供し、議論が再び火を噴いています。
この記事では、このビジョンを追求して開発されたさまざまな形式のアーキテクチャを詳細に検討し、共通のコンセンサス、容量、相互運用性の観点からそれらのトレードオフを比較します。具体的には、Polkadot、Cosmos、Avalanche、Polygon Supernets、Binance BAS の 5 つの独立したマルチチェーン アーキテクチャを研究します。
注: この記事では、アプリケーション固有のブロックチェーンがバリデータ グループまたはコンセンサス アルゴリズムを共有する、スタンドアロンのマルチチェーン インフラストラクチャに焦点を当てています。
比較基準
独立したマルチチェーン エコシステムの接続の程度は、共有開発者ツールキットのような低いものから、共有のバリデータ セット、ファイナリティ ツール、状態といった高いものまでさまざまです。客観的に言えば、各アプローチには独自の利点がありますが、共有セキュリティの維持と速度/容量に関しては、いずれもある程度の最適化が行われています。
この記事では、これらのエコシステムを 5 つの主要なパラメーターによって比較します。
1. コンセンサス
すべてのエコシステムは、Sybil 攻撃の防御とファイナリティ実現時間の基本要件を満たしているため、本質的に最適なコンセンサス メカニズムは存在しません。ただし、1) 特定の種類のコンセンサス モデル、2) 各チェーンの共有または独立したコンセンサス メカニズム、3) 共有または独立したトークン インセンティブを比較する価値はあります。チェーンは同じコンセンサス メカニズム (Tendermint BFT など) を使用する場合がありますが、エコシステムのパラメータに応じて、各チェーンのバリデーターは独自の独立したトークンによってインセンティブを与えられたり、その逆も同様です。共有コンセンサス メカニズムとトークン インセンティブは、ベース レイヤがより優れたセキュリティを提供できることを意味する一方、独立性を選択することは設計の柔軟性が向上することを意味します。
2. ファイナリティ/ステータス
これらのエコシステムでは、一部のチェーンは何らかの形で独立性を維持しており、一部のチェーンは全体レベルで最終化されています。これにより、1) セキュリティが強化され、2) より包括的な相互運用性が実現します。ただし、これには容量の制約というトレードオフもあり、モジュラーブロックチェーンの数が一定数を超えると、ファイナリティに達するプロセスが大幅に遅くなります。
3. 共有バリデーターグループ/ノードの自律性
コンセンサスメカニズムを共有することに加えて、個々のブロックチェーンはバリデーターグループを共有することもできます。以下の例では、バリデータの共有は、すべてのチェーン上の単一のバリデータ セットから、各バリデータ セットが基礎となるブロックチェーンのすべてではなく一部にコンセンサスを提供する複数のバリデータ セット、基礎となるブロックチェーンごとに相互に排他的なバリデータ セットにまで及びます。共有バリデータ セットは、新しいブロックチェーンごとに限界リスクが軽減されるため、一元的なセキュリティを提供しますが、ノードに対する大規模な侵害は、バリデータ セットによって保護されているすべてのチェーンに悪影響を与える可能性があります。このパラメーターの理想的な状態は、多数のチェーンに共有セキュリティを提供するために十分に分散された単一のバリデーター セットです。一方、最も危険な状態は、少数の集中ノードを持つ単一のバリデーター グループです。
4. 相互運用性アーキテクチャ
この記事で取り上げているプロジェクトのほとんどは、「burn burn + mint」または「lock + mint」ブリッジ アーキテクチャを採用しています。これらのシステムは次の点で異なります: 1) ルーティング、つまりメッセージとトークンが何らかのグローバル状態監視状態を持つ単一セットのバリデーターを通過するかどうか、または各ルートが独立しているかどうか、2) これらが取得するバリデーターのセットがリンクしているかどうかエコシステムによって共有されるか、サードパーティ組織に委託されます。エコシステムがサードパーティ検証者の独立したルーティングとアウトソーシングの状態に近づくほど、新しいチェーン リリースにこの基盤となるエコシステムを選択することはお勧めできません。独立リリースの場合は、汎用のサードパーティ ブリッジに直接接続することをお勧めします。 。
5.速度と容量
速度と容量は主に上記の設計上の選択を示しており、ターミナル状態に到達するまでの時間とエコシステムがサポートできるチェーンの最大数によって測定できます。たとえば、ファイナリティが共有され、単一のグローバル状態を持つ構造では、特定の数のチェーンしか対応できないため、ファイナリティまでの時間が大幅に遅くなり、セキュリティの向上とのトレードオフになります。
I. ポルカドットパラチェーン
概要
概要
Polkadot はこの分野の初期に存在し、単一のグローバル状態を共有するアプリケーション固有のブロックチェーンをサポートするために構築されました。 Polkadot アーキテクチャでは、アプリケーション固有のブロックチェーン (パラレル チェーン) が、基礎となるブロックチェーン (リレー チェーンと呼ばれる) とコンピューティング リソースとコンセンサス リソースを共有し、その主な機能は統一されたグローバル状態を維持することです。
コンセンサス、ファイナリティ、バリデーターグループ
Polkadot は、提案されたプルーフ オブ ステーク コンセンサスをリレー チェーン レイヤーで実行します。このアーキテクチャには 3 種類のノードがあります。
推薦者は信頼できる検証者を選択し、DOT の一部を彼らに賭けます。彼らはバリデーターの報酬を共有しますが、悪意のある活動に関与した場合、バリデーターも削減されます。
バリデータ:
バリデータ:
リレー チェーン上のバリデータは、ブロックの生成とコンセンサスに参加します。独立したモノリシックなブロックチェーンとは異なり、リレー チェーンのバリデーターは、複数のチェーンと個々のトランザクションの状態について合意に達する必要があります。
校正者:
コレーターは特定のパラチェーン上のトランザクションを収集し、候補トランザクションのブロックと状態遷移の証明をリレー チェーン バリデーターに提案します。各コレーターは、リレー チェーンとそれが動作するパラチェーン上のノードを維持します。彼らは独自のパラチェーン上にトランザクションを蓄積し、封印されていないブロックを作成し、それを状態遷移証明とともに 1 つ以上のリレー チェーン バリデーターに提供します。リレーチェーンバリデーターが合意に達するまで、ブロックは最終的なものとみなされません。
パラチェーンはグローバル状態を共有しますが、実行する特定のコンセンサス アルゴリズム (GRANDPA/Tendermint/従来の pBFT など) を自由に選択して、リレー チェーン (Polkadot/Kukama) での決済の前にパラチェーン レベルの検証を可能にします。
Polkadot コンセンサスのユニークな特徴は、ブロックの生成とブロックのファイナリティを分離し、ハイブリッド コンセンサスのフレームワークの下で動作することです。
ブロック生成機構：BABE（Blind Assignment for Block Extension）ブロック拡張ランダム割り当て方式
バリデーターは、賭け金の価値とポルカドットのランダムサイクルに基づいて、注文を出し、6 秒スロットのブロックを生成するために選択されます。このランダムな選択では、各スロットのブロック生成候補が 1 つ、多数、またはゼロになる可能性があります。複数のバリデーターが同じスロットに選出されると、ブロックの生産は競争に変わります。バリデーターが選択されない場合は、2 回目の選択が行われます。ブロックが生成されると、メッセージは他のバリデーターに送信されます。
ファイナリティ ツール: GRANDPA (GHOST ベースの再帰的 ANcestor 導出プレフィックス アグリーメント) GOSHT ベースの再帰的 ANcestor 導出プレフィックス アグリーメント
最終的に、Polkadot はパラチェーンにある程度の柔軟性を提供しながら、最高のセキュリティのコンセンサス方式を採用しました。各パラチェーンはチェーンレベルの「コンセンサス」に基づいてデザインを作成し、リレーチェーンにブロックを提案できますが、ファイナリティはPolkadotリレーチェーン上でのみ実現され、DOTトークンの参加を誓約する必要がある検証者のグループによって保証されます。 Polkadot には約 100 人のアクティブなバリデーター (最大 1000) があり、各バリデーターには最大 256 人のノミネーターがあります。その共有バリデータセットは、パラチェーンプロジェクトのより高いセキュリティ保証を確保するために、設計の柔軟性をある程度犠牲にしています。リレー チェーン レベルでの集中型コンセンサスは、より高い共有セキュリティを提供できますが、一部のパフォーマンスも犠牲になります。パラチェーンの数は固定されており、この数を超えると、ファイナリティまでの時間が大幅に遅くなります。
相互運用性
相互運用性
このアーキテクチャでは、これらのコンポーネント、特にリレー チェーンは、Polkadot 独自の通信標準 XCM を通じて相互に通信します。
マクロレベルでは、Polkadot クロスチェーン情報配信システム内のすべてのメッセージはリレー チェーンを通じて送信され、それによってセキュリティが維持されます。渡すことができるメッセージには次の 2 種類があります。
上向きに渡されたメッセージ (UMP): パラチェーンからリレー チェーンへのメッセージ
Downwardly Delivered Message (DMP): リレー チェーンからパラチェーンの 1 つへのメッセージ。
パラチェーンに入る情報はイングレスと呼ばれ、出力される情報はエグレスと呼ばれます。
以下は、パラチェーン A からパラチェーン B にメッセージを渡すプロセスです。
パラチェーン A は UMP を発行し、これは終了バッチの一部としてリレー チェーン上のすべてのバリデーター ノードに送信されます。
パラチェーン B 上のコレーター ノードは、新しいブロック候補をリレー チェーンに送信するたびに、新しいエントリ メッセージを検索します。
エントリ情報はパラチェーン B の処理キューに追加され、次のブロック提案でバリデーター ノードに渡されます。
資産移転の過程で、基礎となる資産は A ブロックチェーン上で破棄され、B ブロックチェーン上で再発行されます。
すべてのメッセージがグローバル状態を監視する単一のバリデーター (Polkadot リレー チェーンと共有) を通過し、すべてのチェーンが同じ標準に基づいて構築されていることを考慮すると、burn+mint モデルは効率的になります。 Polkadot の相互運用性レイヤーは、この分野で最も効率的で安全なレイヤーの 1 つです。したがって、XCM を使用して既存のパラチェーンにシームレスに接続し、スタートアップにこれらのネットワーク効果を借用できるため、そのエコシステム内でプロジェクトを構築することを選択することをお勧めします。
共有セキュリティを高める代償として、パラチェーンの数が一定の値に達すると、ファイナリティに至るまでの時間が大幅に遅くなります。 Polkadot では、レンタルに使用される並列チェーンが約 100 あると推定されており、その目的は、この制限による影響を軽減することです。コミュニティの支援により、プロジェクトは DOT 誓約を通じてパラチェーンの使用に入札できますが、クォータが期限切れになると、クォータを維持するために他の参加者と再入札する必要があります。これは、最も多くの活動とコミュニティのサポートがあるプロジェクトのデフォルトのガバナンス メカニズムであり、キャパシティの制約を部分的に回避しますが、エコシステムに参加するための新しいプロジェクトの参入障壁が比較的高いことも意味します。
II. Cosmos
概要
概要
Cosmos SDK は、すぐに使えるコンセンサスと実行を備えたツール セットで、誰でも独自の PoA/PoS ブロックチェーンを作成できます。この記事で説明する他のエコシステムとは異なり、Cosmos は、スマート コントラクト ベースの仮想マシンの柔軟性、主権、パフォーマンスが限られているという前提に基づいて構築されています。したがって、Cosmos では、複数のアプリケーションを実行できる単一の仮想マシンを構築するのではなく、ユースケースごとに個別のブロックチェーンの作成を奨励し、促進しています。この構造により、アプリケーション開発者は構築時に特定のアーキテクチャ、言語などを中心に柔軟に運用でき、Cosmos のマルチチェーン通信層 IBC を通じて相互運用性を実現できます。個々のブロックチェーンはゾーンと呼ばれ、接続されたモジュールはハブと呼ばれます。
コンセンサス、ファイナリティ、バリデータセット
Cosmos エコシステムでは、Polkadot とは異なり、各アプリケーション固有のブロックチェーンが独自の独立した状態を維持し、各ブロックで独立したファイナリティを実現します。 Cosmos SDK を使用すると、開発者はステート マシン (つまり、アプリケーション) を定義するだけで済み、Cosmos の Tendermint コア (共有ソフトウェア層) を利用してコンセンサスとネットワーク接続を推進できます。 Tendermint は、BFT ベースのコンセンサス アルゴリズムを実行しており、各独立ゾーンのバリデータは、状態遷移を促進し、独立した状態を維持するために活用できます。各ブロックチェーン/ゾーンでは、各エポックが次のブロックを提案するバリデーターをランダムに選択します。バリデーターの 2/3 以上がその有効性を証明した場合、そのブロックは有効であると見なされます。バリデータセットと特定のインセンティブ設計は、ステートマシン/アプリケーションレベルで定義できます。
Tendermint は、各ブロックチェーン/ゾーンが ABCI (Application Blockchain Interface) と呼ばれる専用インターフェースを介して接続する必要がある共有ソフトウェア層です。各ゾーンからのトランザクションは、ABCI を介してトランザクション バイトとして Tendermint コアに渡され、検証者はこれらのバイトを最終的にソートし、ABCI を介してコードをステート マシンに送り返し、これらのトランザクションの正当性を証明します。
一般に、Cosmos は Polkadot とはわずかに異なるトレードオフを選択しました。つまり、チェーンはコンセンサス メカニズムを共有しますが、それぞれが独立したままであり、同じバリデータ セットとインセンティブ メカニズムが保証される必要はありません。共有されたコンセンサスにより一定レベルのセキュリティが提供される一方、インセンティブを個別に定義し、独立した状態を維持することで、各プロジェクトの設計に柔軟性がもたらされます。標準化されたコンセンサスはバリデーターの重複の増加にもつながり、バリデーター自体の大規模な分散と組み合わせることで、Polkadot ほどではありませんが、共有セキュリティも強化されます。コスモスは、2021年末に向けて共有/チェーン間セキュリティの導入に向けた準備を開始しています。この提案されたフレームワークの下では、シングルチェーンは Cosmos Central からセキュリティ保証を借用/共有できるようになります。バリデーターは、ハブ上とゾーン上の 2 つのノードを実行し、両方のノードのコンセンサスへの参加から料金と報酬を受け取ることができます。センターに抵当に入れられたトークンは、2 つの場所の整合性合意のための共有担保として機能し、どちらかの当事者による悪意のある行為により、両当事者は「スラッシュ」(スラッシュ: 一般的に誓約の解除を指します) を引き起こします。新しいチェーンの可用性が向上し、セキュリティが共有されます。
相互運用性
相互運用性
各地区が主権を持ち、独立した地位を維持していることを考えると、地区間のコミュニケーションがますます重要になります。 Cosmost は、ハブ (ゾーンを接続するルートとして機能します) を介して、ハブに接続されているゾーンの状態を監視します。コスモス ハブは、コスモス エコシステムの最初のハブであり、初期の高価値地区のほとんどが接続されています。 Cosmos Hub を通じて、接続された地区は相互に通信できます。情報交換のための特定のアーキテクチャは、Inter-Blockchain Communication (略して IBC) と呼ばれます。 IBC クライアントは、各チェーンのコンセンサス状態と、クライアントのコンセンサス状態に対して証明を正しく検証するために必要な証明を追跡する軽量クライアントです。
IBC アーキテクチャでは、トークン転送の開始から、各チェーンは相手からヘッダー情報を受け取り、相手のバリデーター セットを追跡します。次に、ソースチェーン上の送信アドレスがコインパケットを送信し、センターによって記録されます。中央バリデーターはトランザクションの有効性に同意し、それらのトークンをソースチェーン上のコントラクトにロックする必要があります。次に、センターは宛先チェーン上でこれらのロックされた資産のラップされたトークンを鋳造することを提案する証明書を宛先で発行します。次に、宛先チェーン上のバリデータは、証明書をソース チェーン ヘッダーと照合し、その後、次のブロックでこの関数を承認して、宛先チェーン上でラップされたアセットをミントします。上記のアクションが実行されない場合、ソース チェーン上のロックされたアセットは送信者のアドレスに返されます。ラップされたアセット代表は、センターを介して宛先チェーン上で破棄されるため、ソース チェーン上の基本アセットのロックを解除できます。
Cosmos では、ルーティングは、すべてのブロックチェーンの状態を監視する単一の十分に分散されたバリデーターのセットによって管理され、これらのバリデーターのほとんどはブロックチェーンと共有されるため、ゾーン メッセージングが適切なセキュリティ保証を提供できます。これは、障害点が集中化され、十分に分散化されているため、Cosmos エコシステム内に構築する十分な理由にもなります。
ファイナリティは単一のチェーンに集中していないため、理論的には Cosmos には無限の数のゾーンとハブを含めることができます。そのため、Polkadot とは異なり、新しいプロジェクトで新しいチェーンを構築することに問題はありません。ここでのトレードオフは、より大きな設計の柔軟性と、より多くの個別のブロックチェーンに対応するためのより高い容量を得る代わりに、セキュリティの一部をゾーンにオフロードすることです (ゾーンに独自のインセンティブを設計させ、バリデーターを引きつける)。
III. Avalanche subnets
概要
概要
Avalanche は、サブネットワークと呼ばれるノードのグループによって検証されたブロックチェーン エコシステムです。サブネットワークは、ランダムなサブサンプリングの繰り返しに基づく Avalanche の新しいコンセンサス バリアントなど、独自のコンセンサス メカニズムを自由に選択できます。サブネット内の各ブロックチェーンはコンピューティング リソースとコンセンサス リソースを共有しますが、最終的には独自の状態を維持し、グローバルに共有される状態は存在しません。
コンセンサス、ファイナリティ、バリデータセット
そのアーキテクチャをより深く理解するには、次の 3 つの重要な部分を理解する必要があります。
雪崩式のコンセンサス
繰り返されるランダムなサブサンプリングを指します。 Avalanche コンセンサスは、ランダムなサブサンプリングを繰り返してコンセンサスを達成する Snowball アルゴリズムに基づいて構築されています。このシステムでは、各ノードが k 個の隣接ノードにランダムに質問して、トランザクションが正しいかどうかを判断します。このプロセスは、事前に設定された特定のクォーラム x に達し、ノードが高い信頼度 (少なくともビットコインのハッシュ衝突確率) 内に収まるまで繰り返され、最終的にネットワークがトランザクションの正当性について同意します。
Avalanche エコシステムにおける 2 つの主要な PoS ベースのコンセンサス モデルである Snowman と Avalanche は、ランダムなサブサンプリングを繰り返し使用します。 2 つの違いは、Avalanche は DAG (有向非巡回グラフ) アーキテクチャを使用するのに対し、Snowman は線形ブロックチェーン用に構築されていることです。 DAG ベースのシステムと線形ブロックチェーンの主な違いは、線形ブロックチェーンのファイナリティは順序付けられているのに対し、DAG ベースのシステムではその状態が無秩序なファイナリティを持つトランザクション ネットワークに近いことです。 Avalanche エコシステム内のブロックチェーンは、2 つのコンセンサス モデルのいずれかを使用するか、独自のモデルを採用するかを選択できます。
サブネット (サブネット)
サブネットは、Avalanche フレームワーク内の一部のブロックチェーンでコンセンサスを提供できるバリデーターのコレクションです。各ブロックチェーンにはサブネットがありますが、各サブネットは複数のブロックチェーンを検証できます。各ブロックチェーンは独立して検証可能であるため、グローバル状態はブロックチェーン間で非線形となり、ブロックチェーン間で共有されるセキュリティは存在しません。
仮想マシン (VM)
仮想マシンは、ブロックチェーンのアプリケーション レベルのロジックを決定します。 Avalancheは、オペレーションコードを1セットだけ提供するのではなく、各ブロックチェーンに一連のオペレーションコードを提供して、その中から選択し、状態を処理、変換できるようにしたいと考えている。現在のオプションには、Subnet EVM (サブネット用に構築された EthereumVM)、AvalancheVM (DAG チェーン)、SpacesVM (1 つのキー:値ストレージ仮想マシン)、および BlobVM (バイナリ データ ストレージ仮想マシン) が含まれます。さらに、プロジェクトは独自のカスタム仮想マシンを自由に実装できます。
Avalanche アーキテクチャの前提は、これら 3 つのコンポーネントが、サブネット/バリデーターの成長に合わせて超線形に拡張するモジュール式フレームワークに適合することです。
Avalanche の現在の形態では、参加しているすべての Avalanche バリデーターによって保証されたメイン ネットワークがあり、その下に 3 つのブロックチェーンがあります。
P チェーン: Yeti コンセンサスに基づく線形ブロックチェーン。バリデーターの作成、委任者の追加、サブネットおよびその他のタスクの作成に使用されます。
X-Chain: 資産交換のための Avalanche コンセンサスに基づく DAG タイプのブロックチェーン。
C チェーン: 一般的なスマート コントラクト用の、EVM を実行する、Yeti コンセンサスに基づく線形ブロックチェーン。
これらのバリデーターのさまざまな組み合わせによりサブネットワークを形成し、段階的に参加するブロックチェーンを検証できます。
上記は、現在約 1450 のバリデータを含むデフォルトのサブネットに当てはまりますが、新しいサブネットへの移行はまだわかりません。つまり、Avalanche が行うトレードオフは、柔軟性を高める代わりに、各サブネットにさらに高度なセキュリティをロードすることです。
相互運用性
相互運用性
アーキテクチャのモジュール性と、エコシステム内のさまざまなチェーンに (単一のグローバル状態ではなく) 複数の同時状態があるという事実を考慮すると、クロスチェーンおよびクロスサブネット通信が懸念事項になります。
単一サブネット内のクロスチェーン転送: 各サブネットには、そのサブネット内のすべてのブロックチェーンに対するバリデーターのセットがあるため、この問題は比較的簡単に解決できます。メイン/デフォルトのサブネットの X、C、P チェーン間でアセットを転送するような例を挙げることができます。このアーキテクチャには少なくとも 3 つの同時状態があるため、アセット Z は、受信チェーンの遷移の一部となる前に、送信チェーンの現在の状態のどのアカウントにも存在してはなりません。したがって、ユーザーが Z をチェーン X からチェーン C に転送するように要求した場合、サブネットワークバリデーターはまず Z をチェーン X に書き込み、続いて Z をチェーン C にミントすることに同意する必要があります。このプロセスは、同じバリデーターのセットがサブネット内のすべてのチェーンでのコンセンサスを担当するため、比較的簡単になります。
異なるサブネット間のクロスチェーン転送: バリデーターのセットが同じではなくなったため、異なるサブネット間のクロスチェーン転送を比較することは困難です。この場合、サードパーティ製リピータとの外部ブリッジングが重要になります。現在の Avalanche アーキテクチャには、複数のサブネット間にブリッジを展開するモジュールがあります。各インスタンスは、1) 書き込みとミント、または 2) ロックとミントにカスタマイズできます。単一サブネット転送とは異なり、これはサードパーティのリレーラーに依存して送信チェーンのバーンまたはロックを監視し、このメッセージを受信チェーンに転送してミントを開始します。 WAGMI と Fuji サブネットをブリッジする実装例の概要を次に示します。
現在の設定では、サブネットの各ペアに独立したブリッジが必要で、リピーターのしきい値は 1 まで低く設定でき、リピーターの実行は Chainsafe にアウトソーシングされます。これは短期的には許容できる解決策ですが、長期的には、リピーターの分散ネットワークを備えた単一のブリッジの方が安全である可能性があります。
Avalanche のサブネット内メッセージングは Cosmos や Polkadot などに似ており、単一セットのバリデーターが各チェーンの状態を監視し、転送を容易にします。バリデータ セットが十分に分散されている限り、合理的な共有セキュリティ保証を提供できるため、このアーキテクチャも推奨されます。ただし、サブネット間の情報伝送にはまだ改善の必要があり、現在はサードパーティのリピータに依存しているため、サードパーティのブリッジが独自のセキュリティ保証を持っている限り、結果は比較的妥当なものになるでしょう。したがって、新しいサブネットを直接展開するよりも、既存のサブネット内に展開する方が適切です。
Cosmos と同様に、Avalanche は分散状態を採用して、複数の独立したブロックチェーンをサポートします。コンセンサス メカニズムとバリデータ セットの柔軟性により、Avalanche エコシステムの一部のブロックチェーンでは、各サブネットの参加者の数に基づいてブロック時間を短縮することもできます。たとえば、C チェーンのファイナリティまでの時間は 2 秒です。現在、それ以外のすべてのチェーンのファイナリティタイムは 1 秒未満です。
IV. Polygon Supernets
概要
概要
Polygon は、スーパーネットと呼ばれるこの一連のエコシステムにおいて、すぐに使用できるアプリケーション固有のブロックチェーンとして最新に発表されました。 Cosmos SDK と同様に、Polygon には、独立したネットワークの作成を容易にする Edge と呼ばれるモジュール式フレームワークがあります。ユーザーはこのフレームワークを活用して、共有セキュリティまたはソブリン ブロックチェーンを展開できます。どちらのチェーン タイプも個別の状態を維持しますが、共有セキュリティ チェーンは共有のバリデーター セットを利用するのに対し、ソブリン ブロックチェーンは独自のバリデーターを展開します。
コンセンサス、ファイナリティ、バリデーターグループ
スーパーネットで使用できるコンセンサスには 2 つのタイプがあります。
IBFT PoA (イスタンブール BFT 証明機関): Polygon Edge のデフォルトのコンセンサス。はバリデータの固定セットであり、バリデータは過半数 (51%) の投票によってバリデータを追加および/または削除できます。超過半数 (2/3) の投票によって合意に達します。バリデーターは交代で新しいブロックを提案します。スーパーネットフレームワークの下でのソブリンブロックチェーンにより適しています。
スーパー ネットワーク アーキテクチャは MATIC トークンによって動機付けられており、約 200 の検証者が共有セキュリティ PoS モジュールに参加し、強力な共有セキュリティ保証を提供します。その代わりに、プロジェクトは独自のインセンティブを設計し、コンセンサスに結びついたネイティブ トークンを使用する柔軟性を犠牲にしなければなりません。高性能アプリケーションの構築に重点を置いたプロジェクトの場合、独自のアプリケーションの構築と、他のアプリケーションで使用できる独自のコンピューティング層の構築との間でトレードオフを行う必要があります。
相互運用性
相互運用性
Polygon Edge フレームワークは、ChainBridge と呼ばれるブリッジング ソリューションを利用して、トークン転送などのスーパーネット間の通信を容易にします。この投稿の前半で見たソリューションと同様に、トークン転送プロセスは次のとおりです。
トークンはソースチェーン上でロックまたは焼き付けられます
リピーターはソースチェーン上のこのアクションを監視し、その情報を宛先チェーンに伝達します。
ソース チェーン トークンは、宛先チェーンで作成されたトークンを表します。
ソース チェーン トークンがロック (または破棄) されている場合、ユーザーはラップされたトークンを宛先チェーンに返して、ソース チェーン上の基礎となる資産のロックを解除できます。
Edge と ChainBridge の場合、このペーパーで前述したいくつかのソリューションとは異なり、スーパーネットとブリッジのバリデーターは必ずしも同じではありません。
これは、チェーンレベルおよび通信レベルのコンセンサスのために設定された共有バリデータにより障害点が少なくなるという、独立したマルチチェーン アーキテクチャにおける有力な議論とは対照的です。とはいえ、Polygon が提供する他の共有セキュリティ機能を考慮すると、ブリッジ バリデータ セットが十分に分散され、適切にインセンティブが与えられていれば、これは重要な要素ではない可能性があります。
Polygon は、スピードとセキュリティに関連した興味深いデザインを作成しました。 Polygon は、バリデータ セットとコンセンサス メカニズムを共有することで、十分な共有セキュリティを提供します。同時に、各スーパーネットが独自の状態を維持できるようにすることで、Polkadot などのオーバーヘッドが回避され、理論的には無制限の数のスーパーネットを構築できるようになります。
V. Binance BAS
概要
概要
Binance Application Sidechains (BAS) は、アプリケーション固有のブロックチェーン用の BSC のモジュール式フレームワークです。 BAS の初期バージョンは、各チェーンに必要なセキュリティのレベルに応じて、3 ～ 7 個のバリデータを備えた一連の PoS サイドチェーンになると推定されています。 BAS チェーンは、この記事で取り上げる唯一のアプリケーション固有のブロックチェーンであり、コンセンサスも状態も共有する必要がなく、各 BAS には独自の独立したバリデーターのセットがあります。 BSC と関連付けたい場合は、サイドチェーンと BAS チェーンと BSC を接続する外部ブリッジを構築するための開発者用の共有ツールキットのみを使用できます。
BAS に加えて、Binance は、BNB チェーン パーティション チェーン (BPC) と呼ばれる、イーサリアム L2 に似た共通の実行環境も構築しています。これは、BNB ビーコン チェーンの一部の計算をホストするために使用されます。これは興味深いものですが、この記事ではアプリケーション固有のサイドチェーンの議論に焦点を当てます。
コンセンサス、ファイナリティ、バリデータセット
Binance が提供するアーキテクチャは、おそらくこの分野で最も弱いものの 1 つです。各チェーンには独立したバリデーターの小さなセットがあり、独自の状態を維持しているため、共有セキュリティの保証は非常に限られており、Binance が開発者に提供するツールは独自のブロックチェーンを構築するためのツールキットのみであることを意味します。バリデータセットを大きくできる場合、またはすべてのサイドチェーンにわたって高い信頼共有ができる場合は、Binance でプロジェクトを構築することを検討する価値があります。ただし、BAS は、低いコンセンサス共有のみを必要とするプロジェクト構築に適しています。
相互運用性
相互運用性
一連のソブリン ブロックチェーンと同様に、BAS チェーンは相互に通信するためにサードパーティのブリッジを必要とします。この場合、BSC は Celer のサードパーティ ブリッジを使用して「ロック + キャスト」を通じて各 BAS に接続し、各 BAS もこのメカニズムを通じて接続されます。
Binance は独立したバリデーターを備えたサードパーティのブリッジを採用しており、そのエコシステム内でプロジェクトを構築することは、スタンドアロンのブロックチェーンを構築するほど魅力的ではない可能性があります。理論的には、どのスタンドアロンのブロックチェーンもこれらのブリッジを介して接続できるためです。注意すべき点は、客観的にはこれは悪い設計ではありませんが、開発者にとって、このエコシステム内でプロジェクトを構築することを選択する強い理由はないため、独立したアーキテクチャを直接構築することを選択する方が良いということです。
BAS アーキテクチャ下のサイドチェーンは検証者、コンセンサス、または状態を共有せず、各チェーンの検証者セットが小さいため、ファイナリティまでの時間が短くなり、収容できるチェーンの数が多くなります。
結論は
結論は
アプリケーション固有のブロックチェーンは、しばらくの間、スケーラビリティに関する議論の重要な部分を占めてきましたが、その実装は、誕生したばかりの相互運用性インフラストラクチャによって妨げられてきました。過去数か月間、このインフラストラクチャはさまざまな独立したマルチチェーン エコシステムでオンライン化され続けているため、よりユースケースに特化したインフラストラクチャの作成や開発など、この分野での活動がさらに活発になることを期待しています。サブアプリケーション層 (Polkadot 上の Acala など) とアプリケーション固有の実行環境。
