"What Is IBC?"「IBC とは?」(和訳)
プッシュ通知

この記事は、Intechain Foundationによる記事、ELI5: Whats IBC?の和訳記事です。

ビットコインの誕生により、それ以降様々な設計やユースケースを持つブロックチェーンが爆発的に増えました。これらのブロックチェーンは異なる目的で使用され、通常、相互作用、インターオペラビリティが制限されている存在でした(現在もある程度そうです)。

インターネットは、世界のあらゆる場所にあるコンピュータどうしが相互通信することを容易にしました。これと同様に、ブロックチェーン間を結合する同様の技術が必要です。IBC(Inter-Blockchain Communication)プロトコルは、これを果たすことを目的としています。

IBCは、2つの異なるブロックチェーンが互いに通信することを可能にするインターオペラビリティプロトコルです。IBCは、信頼性が高く、秩序があり、認証された通信を保証します。

IBCの最も重要な特性の1つは、トラストの最小化です。ブロックチェーンでは、トラストの最小化は本質的にセキュリティと結びついています。完全に「トラストレス」な分散システムは存在しません。したがって、セキュリティの問題は、誰を、あるいは何を信頼するのか、そしてその信頼はどのように破られうるのか、すなわち信頼されたエンティティが破損するには何が必要なのか、ということに帰結します。

この意味で、ほとんどのブリッジング・ソリューションと異なり、IBC は信頼できるサードパーティを使用しません。つまり、2つの特定のチェーンが提供する機能(およびデフォルトでそのコンセンサスメカニズム)を使用する場合、IBCを使用してそのチェーン間でやり取りする際には追加のトラストが必要ないということです。

IBC はまた、トークン転送のための単なるブリッジではありません。IBC は汎用メッセージングプロトコルなのです。つまり、あらゆる形式のデータをIBC上で通信することができます。

IBCはどのように機能するのか?

IBCの仕組みを理解するためには、IBCの以下の2つの異なる層に分けることが重要です。それぞれを解説していきます。

  • トランスポート層
  • アプリケーション層
2つのブロックチェーン間のIBCパケットフローのイメージ

トランスポート層

IBC上で通信されるメッセージは、データパケットに入って転送されます。そして、トランスポート層は、これらのデータパケットの輸送、認証、順序付けを行います。

トランスポート層は、パケット内のデータがどうあるべきか、受信側のチェーンでどう解釈されるべきかについては何も指定しません。トランスポート層から見れば、データパケット内の情報は単なるランダムなbyteです。

トランスポート層の主要な構成要素は、ライトクライアント、リレイヤー、コネクション、チャンネルである。

ライトクライアントは、ブロックチェーンを軽量に表現したものです。フルノードとは異なり、ライトクライアントはブロックチェーンに含まれるすべてのメッセージの全履歴は保存しません。また、トランザクションを実行することもありません。ライトクライアントはフルノードに接続し、ブロックヘッダー(ブロック内に含まれるデータの要約)を検証するように設計されています。このため、ライトクライアントはストレージと計算の面で効率的です。

IBC上でやりとりする2つの独立したブロックチェーンAとBは、相手のチェーンのライトクライアントを持ちます。これは、Aが自分のブロックチェーン上にライトクライアントを持ち、それがBのブロックチェーンの軽量版として機能することを意味します。AはBとあるメッセージ「X」をやり取りしたい場合、そのメッセージが存在するブロックのヘッダーを、そのメッセージのコミットメント証明とともにBに送ります。コミットメント証明は、A上の特定のメッセージの有無を検証するために使われます。ブロックヘッダーと証明を使用して、BはAが確かにXを送ったことを暗号的に検証します。IBCにおけるこのライトクライアント利用により、ブロックチェーンは信頼できる第三者を必要とせずにメッセージを交換することができます。

しかし、AとBは、これらのメッセージ/データパケットを互いに直接送信するわけではありません。その代わり、AはBにメッセージを送りたいとき、そのメッセージを含むデータパケットのハッシュステートマシンというものに保存します。オフチェーンプロセスであるこの中継器は、こういったメッセージを常に監視しています。リレーヤーは、A が B 宛のメッセージをステートマシンに保存したことを確認すると、そのメッセージを拾って B に渡します。

コネクションは、2つの異なるチェーン上のライトクライアントを接続する役割を担っています。そしてチャンネルは、異なるチェーン上のモジュール間でパケットを転送するためのパイプの役割を担います。したがって、コネクションがチェーン固有であるのに対して、チャンネルはモジュール固有です。各チャンネルのエンドは、2つのモジュール間でパケットを正確にルーティングするために使用される固有のチャンネルID(およびポートID)を持っています。

アプリケーション層

アプリケーション層は、エンドユーザーと対話するためのものです。トランスポート層を利用して上に構築する様々なアプリケーションで構成されています。トランスポート層は、データパケットがどうであるかを指定しませんが、これはアプリケーション層が果たします。

IBCは、FT/NFT転送、クロスチェーンOracleフィード、インターチェーンアカウント、インターチェーンクエリー、手数料ミドルウェア(中継者にインセンティブを与える)など、さまざまなアプリケーションに対応しています。

例えば、トークン転送のためのIBCレベルのアプリケーション、インターチェーンスタンダード20(ICS20)規格では、データパケットがどのように構成されるべきか、そして受信チェーンによってどのように解釈されるべきかを規定しています。カジノ・トークンの場合、データパケットには送信者、受信者、金額、デノミネーション(IBC denom)に関する情報が含まれます。デノムフィールドは、特定のトークンがあるチェーンに到達するまでの経路をトレースします。パケットがどのように処理されるかに関する理論も、ICS20によって規定されています。

わかりやすく例えると

IBCを理解するのに役立つ簡単な例えに、郵便配達システムのものがあります。あなたが誰かに手紙を送るとき、郵便サービスを通して送ります。郵便サービスは、あなたから手紙の入った封筒を回収して、受取人の郵便受けに投函します。そして、受取人はその封筒を開けて、あなたの手紙を読みます。IBC のトランスポート層は、郵便サービスだと考えることができます。郵便サービスは、手紙の中身がどうあるべきか、あるいは受取人があなたのメッセージをどう解釈すべきかを教えてはくれません。

また、封筒の中身が何であるかも知りません。封筒そのものは、あるチェーンから別のチェーンに送られるIBCパケットと考えることができます。そして、この封筒には、受取人のアドレスを指定することになります。これは、IBCパケットに、そのパケットを誰が送ったか(Chnannel IDで指定)、誰に宛てたものか(counterparty channel IDで指定)という情報が含まれているのと同様です。結局、封筒(データパケット)を開けて手紙の内容を解釈するのは、受信者(アプリケーション)なのです。

IBCは何に使うのか?

互換性のあるトークン転送の他に、IBCレベルのアプリケーションにはインターチェーンアカウントとインターチェーンセキュリティがあります。

インターチェーンアカウントは、単一のインターフェイスに留まりつつチェーン間の相互作用を促進します。これは、B(「ホストチェーン」と呼ばれる)で実行できる送金、ステーキング、ガバナンス提案に対する投票などのアクションが、A(「コントローラーチェーン」と呼ばれる)から実行できることを意味します。インターチェーンアカウントは、UXを向上させることにより、インターチェーン内のコンポーザビリティを大幅に向上させます。

インターチェーンセキュリティは、Cosmos Ecosystemの共有セキュリティのバージョンです。ブロックチェーンは、完全にオプトイン方式で他のチェーンからセキュリティをリースすることができます。これは、Cosmos Hubのような既に確立されたネットワークによって提供されるセキュリティを利用することを選択できる新しいチェーンにとって特に有用です。インターチェーンセキュリティは、チェーンが独自のバリデータセットを起動する必要性を取り除きます。

つまりこれは、あるチェーン(セキュリティ・プロバイダ)のバリデータが、別のチェーン(セキュリティ・コンシューマ)のバリデータを検証できるようになるということです。

IBCをコアプリミティブとして使用できるアプリケーションは一貫して拡大しています。クロスチェーンNFT転送とインターチェーンクエリー(あるチェーンが別のチェーンから状態を読み取ること)は現在開発中で、間もなく製品化される予定です。

IBCはどのような問題を解決するのか?

IBCは、ブロックチェーンがサイロのように存在し、相互作用が限定的であるという問題を解決するものです。ブロックチェーン間のインターオペラビリティは、最大限の価値を生み出すために必要です。

各ブロックチェーンは、何らかのユースケースに対応しています。これらのユースケースを複数のブロックチェーンで活用できない場合、その有用性は著しく損なわれます。インターネットがもたらしたブレークスルーは、情報が世界のさまざまな場所を簡単に行き来できるようになったことです。同様に、さまざまなブロックチェーンの実用性は、複数のプラットフォームで自由にアクセスできる必要があります。

例えば、ユーザーはあるブロックチェーンのステーブルコインを使い、別のブロックチェーン上に存在する分散型取引所(DEX)の流動性プール(LP)を通じて利回りを上げたいと思うかもしれません。あるいは、別のブロックチェーンが提供するプライバシー保護の特性を活用したいと思うかもしれません。このようなユースケースを実現するためには、チェーン間のインターオペラビリティが必要です。

IBCは、インターオペラビリティの問題を解決するだけでなく、トラストを最小限に抑え、安全で拡張性の高い、汎用的な方法でこれを実現します。

アプリケーション開発者は、IBCをどのように利用すればよいのでしょうか?

Cosmos SDKはモジュール式であるため、開発者はライトクライアント、コネクション、証明の検証などの抽象化されたレイヤーを気にする必要がありません。開発者にとって、最も関連性の高い要件と機能は、チャネルポートです。IBCに関するより詳細な情報については、当社の開発者向けポータルを参照してください。

Cosmos SDKを使用してブロックチェーンを構築する場合、SDKモジュールのIBCを有効にするために必要な手順については、こちらで詳しく説明しています。また、ICFのイニシアチブであるInterchain Builders Programに応募して、Cosmosでの構築をサポートしてもらうことも可能です。

著者について:この元投稿は、Interchain GmbHのIBCプロトコルアナリストであるAditya Ravi Rajによって書かれました。

運営者情報

Stir lab運営元のSTIR (スター)は、ETHERSECURITY PACIFIC HOLDINGS PTE. LTD.(本社:シンガポール、代表取締役:加門昭平)及びその100%子会社である株式会社イーサセキュリティ(本社:東京都渋谷区、代表取締役:加門昭平、紫竹佑騎)が運営するWeb3 Consulting & Development Teamです。

 

X (Twitter)@Stir_Network_JP

LinkedInhttps://www.linkedin.com/company/14613801

運営元https://stir.network/

Twitterでフォローしよう

おすすめの記事