異なるブロックチェーンは、ユーザーが複数のブロックチェーン上のデータや資産とやり取りできるようにするために、インターブロックチェーン通信（IBC）プロトコルがブロックチェーン間のトランスポート層として機能するように確立されました。 Cosmosエコシステムが最初にIBCを採用しましたが、一般化可能なプロトコルであるため、IBCは他の多くのエコシステムにも導入されています。

ICS-02は、ライトクライアントの構築に関する要件を概説し、IBCがライトクライアントデータを管理する方法も含まれています。IBCが機能するためにはクライアントが必要であり、これらは任意の検証アルゴリズムであり、通常はIBC形式でエンコードされた情報をチェーン上で証明するためのものです。これにより、情報が一つの場所から別の場所に移動します。

From the perspective of IBC, each chain is normally identified by its light client. The most common verification occurs between two communicating state machines; using a light client, a source chain is able to verify updates from a destination chain without downloading its entire data. Because light clients are a versatile tool, they can use multiple methods to do state verification.

コンセンサス証明検証

コンセンサスアルゴリズムに関する注意事項

ブロックチェーンの合意は、ネットワークに参加するすべてのノードが同期していることを確認します。合意検証を使用すると、ライトクライアントは、十分な数のバリデータがヘッダに署名したことを証明します。この種の検証は、IBCの最も一般的な用途です。

コンセンサスアルゴリズムは、通常、ルールセットと優先順位が異なります。ただし、2つの異なるコンセンサスアルゴリズムの不均一性により、チェーンがIBCを介して通信することが困難になる可能性があります。例えば、Cosmosチェーンは、シングルスロットファイナリティ(高速ファイナリティとも呼ばれる)を持つTendermintコンセンサスアルゴリズムを使用しています。一方、イーサリアムのコンセンサスはシングルスロットのファイナリティを持たないため、セキュリティよりも活性を重視するため、ファイナリティが遅くなりますが、IBCはセキュリティを重視するコンセンサスアルゴリズムと最も互換性があります。ブロックが「最終」と見なされるタイミングがこのように異なるため、2つのチェーンが互いにブロックを送信して検証する方法が困難になります。

そのような場合、最終性に到達する前の特定のブロック高さのライトクライアントを持つことができる仮想ライトクライアントが実装されることができます。最初はIBCは、Tendermintベースのチェーン内での採用に焦点を当てており、クライアント仕様と実装がどのように定義されたかが明確でした。この初期段階の後、クライアントリファクタリング他の合意アルゴリズムや機能を持つチェーンの軽量クライアントの開発における柔軟性と容易さが向上しました。

軽量クライアント：ステートマシン

「ステートマシン」は、ブロックチェーン全体（複製された台帳）またはラップトップや携帯電話などのプライベートキーで操作に署名する単一のプロセス（最小限の合意）となることがあります。

一般的に、状態機械は分散型台帳を持つブロックチェーンとして考えられますので、ブロックチェーン間でIBCを確立する際、宛先チェーンのライトクライアントはソースチェーンによってホストされます。ソースチェーンはまた、2つのチェーン間の接続ハンドシェイクによって確立される宛先チェーンの信頼された状態を維持します。IBCプロトコルは、宛先チェーンの状態更新が有効であるかどうかをチェックするアルゴリズムである有効性述語を使用します。ライトクライアントが機能するためには、ソースチェーンに対する有効性述語と信頼された状態が必要です。

クライアント「タイプ」vs. クライアント「インスタンス」

ライトクライアントは、多くのチェーンの多くのクライアントインスタンスをサポートするためにできるだけ効率的に設計されています。 これを実現するために、ライトクライアントアルゴリズムはすべての状態遷移をリプレイしないため、それによってフルノードにすることがあります。

ライトクライアント：ソロマシン

ソロマシンは、ラップトップ、Webインターフェース、携帯電話、またはオフチェーンプロセスなどのデバイスです。ソロマシン 通信を確立できますブロックチェーンがIBCを使用する場合、複製された台帳を使用します。

例えば、IBCは可能にすることができます 保管転送プロトコル新しいチェーンの統合コストを低減します。これは重要です。なぜなら、中央集権的な管理者は、新しいネットワークを統合する際に、統合される各チェーンに対してフルノードとRPCインフラストラクチャを実行する必要があるため、手間暇かかります。代わりに、管理者はクロスチェーンの転送、鋳造/焼却を容易にする単独のマシンクライアントを運用できます。検証は、管理者が運営する接続されたマシンのクライアントによって行われます。

ソロマシンクライアントは、IBCがブロックチェーンだけでなく、その外の接続性を開く方法を示しています。上記の例では、IBCを使用することで、機関が簡単にパブリックブロックチェーンとやり取りすることが可能になります。これは、ブロックチェーンに触れるビジネスラインの一例に過ぎず、それには完全なチェーンを立ち上げたり、重いハードウェアを維持したりする必要がありません。

合意証明を超えた検証

クライアントの実装と更新を容易にするために作業が行われていますが、有効性または不正の証明を行うオプションもあります。

楽観的IBC：クライアントは、いくつかの仮想マシンでプログラムを実行するオフチェーンリレーサを介して受信ヘッダーを楽観的に受け入れることができます。このシナリオでは、詐欺証明が提出される可能性のあるチャレンジウィンドウが存在します。楽観的IBCの利点は、システム全体のコストを削減できることです。欠点には、長い詐欺チャレンジ期間が含まれ、ネットワークに依存して資産の移動に高い基本コストがかかる可能性があります。イーサリアムの場合、これは21,000ガスユニットです。

ZK-IBC:クライアントの計算はオフチェーンで行われ、ZKPを介してオンチェーンで検証されます。最小レイテンシーはなく、コストはナイーブ検証よりも低くなります。しかし、ZK検証はオンチェーンでコストがかかる可能性があり、最大レイテンシーがないため、ユーザーは確認を得るのにしばらく待つことになります。また、署名スキームが SNARK に対応していない場合は、非互換性の問題が発生する可能性があります。

上記の別々のシステムにはいくつかの避けられない欠点があるため、Optimistic ZKは両方から利益を借りることが提案されています。両方を使用する利点は、接続メンテナンスのコストを下げ、リレーアのインセンティブにより最大遅延バウンドを導入することです。

オプティミスティック ZK: ソースチェーンはヘッダーを楽観的にオンチェーンで受け入れます（セキュリティのためにステーキングメカニズムが可能性として用意されています）。その後、ZKP は不正行為の場合の詐欺証明や有効性証明として使用され、接続の遅延を動的に短縮します。

セキュリティと不正行為

IBCは、外部で検証された相互運用性プロトコルが取り組むような第三者信頼の仮定を必要としません。それは単なる輸送プロトコルであり、そのセキュリティ特性は、チェーンそのものではなく、基になるクライアントや接続の種類に依存します。また、詐欺の証明、正直な過半数の仮定、共通データの利用を通じた共有セキュリティなど、接続の利用にも依存します。IBCプロトコルは、接続の両側のチェーンのアイデンティティを知る必要はありません。IBCクライアントが有効な更新と同期されている限りです。

もしも、例えば、ソースチェーン上のクライアントが宛先チェーンによって設定されたコンセンサスルールを破った場合、ソースチェーンでその違反の証拠が検証されると、ホストチェーン上のクライアントは凍結されます。このような状況を目撃した当事者（リレーア）は、この違反の証拠とともにメッセージを送信することができます。違反述語は、このような状況で呼び出されるアルゴリズムであり、違反が証明された場合、クライアントは凍結され、行動を取るためのガバナンスシステムがあることを願っています。違反の結果は参加チェーンによって決定されます。

軽量クライアントを使用して構築する

IBCは、基礎となるチェーンのコンセンサスと内部の技術としての熟練を必要とする場合がありますが、すべての細部がIBCを使用してビルドするために重要であるわけではありません。これらの記事シリーズでのもう一つの目標は、IBCを使用して構築するためにはすべての細部が重要であるわけではないことです。ここからの持ち帰りは、クライアントが取り組むことができるさまざまな検証実装を考慮に入れるというIBCが強力なツールであるということです。

IBCエコシステムは、IBCを採用するための簡単なソリューションにするために積極的に取り組んでいます。議論されているイニシアチブには、クライアントのリファクタリングと仮想クライアントが含まれています。たとえば、あるチェーンがコンセンサスをアップグレードしたい場合、接続されているすべてのチェーンとその軽量クライアントをアップグレードする必要があり、これはコストのかかるオンチェーンガバナンスプロセスです。WASMクライアントは、スマートコントラクトとして展開されたクライアントインスタンスを介して軽量クライアントの開発とアップグレードを簡単にするために開発されています。これにより、チェーンを停止せずに軽量クライアントをアップグレードすることが容易になり、Rustなどの言語でクライアントを作成することが可能となります。

別れのテイクアウトは、IBCクライアントは、誰でも、どんな機械でも使用でき、任意のブロックチェーンを横断して状態を検証できるため、これらは暗号通貨における新しいビジネスやサービスのための強力な触媒となります。

この記事は、IBCをサポートするためにPolymerがスポンサードしており、真に分散型の相互運用性に関するコミュニティ教育を支援しています。

Polymer Labs, composed of skilled distributed systems and infrastructure engineers, crypto pioneers, and accomplished business operators, is at the forefront of advancing Ethereum interoperability with IBC. With technical values based on TCP/IP, Polymer’s mission is to establish the next generation of the internet by ensuring that the interoperability layer of the decentralized web is neutral, open, permissionless, and uniform across ecosystems. As the creators of the Ethereum Interoperability Hub, the first Layer 2 focused on enabling IBC interoperability, Polymer sets a new standard in blockchain technology.

免責事項：

1. この記事は[から転載されましたeshitanandini]. 全ての著作権は元の作者に帰属します[ESHITA]. If there are objections to this reprint, please contact the Gate Learnチームはすぐに対処します。
2. 責任の免責事項：この記事に表現されている意見は、著者個人のものであり、投資アドバイスを構成するものではありません。
3. 他の言語への記事の翻訳は、Gate Learnチームによって行われます。特記されていない限り、翻訳された記事のコピー、配布、あるいは盗作は禁止されています。