はじめに
ブロックチェーン間で相互にデータを転送するプロトコルであるIBC（現：IBC Classic）は，Cosmos SDKあるいはCometBFTと呼ばれるCosmosエコシステムのフレームワークを前提としていました．
しかし，実際にはCosmos系以外にもさまざまな仕様をもつブロックチェーンが存在しています．
異なるフレームワークで動作しているブロックチェーンに対しても相互運用性を実現するため，2025年3月にIBC v2が公表されました．
概要
IBC v2は，IBC Classicのコアな仕組みを継承しつつ，EthereumやSolanaなど異なるブロックチェーン同士であっても利用できるように改善されたバージョンです．
2025年4月には，CosmosとEthereumのエコシステム同士の相互運用性を実現するプロダクトとして IBC Eureka がローンチされました．EthereumのL2（Arbitrum, Base）やSolanaとの連携も計画されています．
IBC v2の仕組み
IBC v2では概念的に３つのレイヤーを設けています．相互運用の実現に必要な機能をレイヤーごとに再定義し，各レイヤーで扱うべき検証内容を明確にしています．
IBC CLIENT
接続先となるブロックチェーンの状態を確認し，正しく更新されているかを検証します．IBC ClassicではLight Clientと呼ばれていましたが，その辺りの用語の使い方は曖昧です．
IBCではクライアント間でConnection / Channelを介した通信をするため，Relayerと呼ばれる機能がオフチェーンの仲介者であり，IBC v2になってもその構造は変わりません．
セキュリティモデル（コンセンサスや署名の方法など）はカプセル化されており，これによってCosmos系以外のブロックチェーンでもクライアントを作れるようになっています．
Relayerはクライアントの初期化・更新だけでなく，カウンターパーティーとなるブロックチェーン上での不正行為を報告する役割をもちます．もしカウンターパーティー上で不審な動きがみられる場合は，この報告に従ってクライアントが停止され，悪意ある情報の書き換えを防ぐという仕組みです．
多様なブロックチェーンに対応するには，これまでのCosmos系ブロックチェーンが採用してきたセキュリティモデル以外のモデルにも対応する必要があるため，このような仕組みを採用しています．プロトコル上では，不正報告のエンドポイント submitMisbehaviour を設けることのみを定義しており，その実装はクライアントの作成者に委ねられています．
IBC CORE
クライアントを通じてブロックチェーン間の通信内容が記載されたパケットを検証し，完了したらそのパケットを利用するアプリケーションに送信します．
通信の確立方式が抽象化され，IBCの利用にあたってルーターを利用する形に変更されました．アプリケーション用のポートIDを個別のアプリケーションに割り振るルーター，クライアントIDを個別のクライアントに割り振るルーターがあります．
通信の確立方式は，下記のIBC v2における通信の確立で概説しています．
その変更に伴い，パケットの中身も少し変化しています．送信元 / 送信先のブロックチェーンのChannelやPortを指定するのではなく，クライアントIDを指定する形式になりました．
また，パケットに含まれる送信したい内容の記述方法も変更されています．IBC Classicでは，前述のPort指定があったため，パケットには特定のアプリケーション宛のデータ１つしか含められませんでした．しかし，IBC v2では複数のペイロードを格納できる形式に変更され，ペイロード内でPortを指定するようになっています．
この変更により，それぞれ異なるアプリケーション宛の複数のデータを１つのパケットに含めて送信できるようになり，効率性も向上しています．
IBC APP
トークンなどのデータを実際に扱うアプリケーションです．IBCにおいてはモジュールとして導入され，トークンの発行や転送，エスクロー等の機能を実装します．
※エスクローとは，取引する２者の間に入り，（ブロックチェーンであれば）トークン同士を確実に交換するといった仲介機能を指します．
IBC v2における通信の確立
IBC Classicでは，IBCによる通信の確立で以前触れたように，各ブロックチェーン上での Light Client作成（２ステップ），Connectionの確立（４ステップ），Channelの確立（４ステップ）という順で接続していました．
IBCにおけるConnection / Channelの役割は，以下のように位置づけられています．
- Connection：クライアント間の通信の確立
- Channel：アプリケーション単位での通信の確立
このような分担をすることで，同じクライアント同士の通信であっても異なるアプリケーションを跨いで通信内容が混在しないようになっています．
また，アプリケーション間での通信では，相互に参照するためのアプリケーション固有の識別子をパケットに付与しています．
IBC Classicでは，Connection / Channelの確立にハンドシェイクを利用していましたが，その処理負荷や必要なトランザクション手数料の高さという観点から，IBC v2ではハンドシェイクを廃止しました．
ハンドシェイクでは，IBCやアプリケーションのバージョン互換性，アプリケーションが相互に参照するための識別子など，アプリケーション間の通信に必要な情報を提供していたため，IBC v2ではハンドシェイクに代わる情報提供の方法を設ける必要があります．
そのため，各ブロックチェーン上にクライアントを作成した後，カウンターパーティーのクライアントを登録するという形が採用されました．登録時には，カウンターパーティーのクライアントIDとICS-24のPathにおける接頭辞が渡され，この２つの情報を用いて意図したアプリケーションに向けた通信を行います．
ICS-24は，IBCを利用するブロックチェーンを動作させるステートマシンの要件として定められる規格です．Pathはステートマシンが保存するオブジェクトのキーとして利用されます．
まとめ
IBC v2では，さまざまなブロックチェーンに対応するため，コンセンサスアルゴリズムや署名方式によらないクライアントの実装，処理不可の高い複雑なハンドシェイクによる通信路の確立などが仕様に盛り込まれました．
LayerZeroやChainlinkのような信頼性の高い検証用ネットワークを経由する形ではない相互運用技術として，より利用されやすい仕様になったのではないかと思います．
参考
- https://ibcprotocol.dev/blog/ibc-v2-announcement
- https://github.com/cosmos/ibc/tree/main/spec/IBC_V2
- https://docs.cosmos.network/ibc/next/intro#high-level-overview-of-ibc-v2
IBC v2の他にも，個別の相互運用性プロトコルに関して簡単に紹介しています．ご関心があればご一読ください．