【保存版】Cosmos IBCの仕様の網羅的説明

こんにちは。

前回記事

ではIBCはトークン送信の機能だといいましたが、これは簡略化のための嘘です。

実はもっとすごいです。

IBCの仕様を、公式のICS (Inter-Chain Standard。標準規格仕様書みたいなもの)に正確に基づいて、すべて説明していきます。

保存版です(永久とは言ってない)。

ICS-1 ICS Specification Standard

ICS-1は種別が”Meta”とあるとおり、「ICSとはどのようなものか」を定めたICSです。

ICSの必須項目は、

• 番号
• タイトル
• ステージ
• カテゴリ
• 著者
• 作成日時
• 編集日時

から成ります。

任意項目として、

• このICSが依存する別のICS
• このICSが依存されている別のICS
• このICSが置き換える別のICS
• このICSが置き換えられる別のICS

があります。

内容が簡単であることと、以後ICSを読むのに必要であることから、全員知っておくべきICSと言えます。

著作権

また、ICSはApache 2.0ライセンスによる著作権表示が必要です。

疑似コード

ICS内にて疑似プログラムコードによる説明が行われる場合、TypeScriptの文法に従います。

ICS-2 Client Semantics

このICSでは、IBCプロトコルを実装するにあたって要求される、ブロックチェーンのコンセンサスアルゴリズムの性質について説明しています。

要求される性質さえ満たしていれば、コンセンサスアルゴリズムの内部実装は不問となっています。

このICSがあることで規格が統一され、IBC相手のステートの更新内容を検証することができます。

このICSは、IBCを独自に実装したりしたい人など以外は、内容を詳細に把握する必要はありません。

ICS-3 Connection Semantics

このICSでは、IBCにおける”Connection”の概念を説明しています。

IBCにおいては、コネクションの開設にあたって、二往復の発信を行います。

知っている人は、TCPの3ウェイハンドシェイクを思い返せばすぐにわかると思います。あんな感じです。

1. ConnOpenInit A→B
2. ConnOpenTry A←B
3. ConnOpenAck A→B
4. ConnOpenConfirm A←B

このような二往復の発信を経て、”Connection”が確立されます。

このICSは、アプリケーション開発するにあたっては大雑把でよいので知っておいたほうが良いです。

ICS-4 Channel & Packet Semantics

このICSでは、IBCにおける”Channel”と”Packet”の概念を説明しています。

IBCにおいて、Channelは一つのConnectionと紐づいています。一つのConnectionは、複数のChannelと紐づくことができます。いわばConnectionとChannelが1:Nの関係になっています。

Channelも、Connectionと同様に二往復の発信を経て確立されます。

1. ChanOpenInit A→B
2. ChanOpenTry A←B
3. ChanOpenAck A→B
4. ChanOpenConfirm A←B

このような過程を経て確立されたChannelの中で、Packetが送受信されます。パケットの意味はTCPと同じで、決まりに従って送受信されるデータのことです。

このICSは、アプリケーション開発するにあたっては大雑把でよいので知っておいたほうが良いです。

ICS-5 Port Allocation

このICSでは、IBCにおける”Port”の概念を説明しています。

TCPなんかではポートは番号で表されます。よく使うものでは、sshに22、httpに80、httpsに443、などです。

一方、IBCではポートは文字列で表されます。”bank”や”staking”などです。

これはCosmos SDKでよく使われるモジュール名からきています。つまり、IBCでは一般的にモジュールの名前をポート文字列として使うことになります。

ポートを指定することで、IBCによってやりとりしたい相手チェーンの機能を指定することができます。

このICSは、アプリケーション開発するにあたっては大雑把でよいので知っておいたほうが良いです。

ICS-6 Solo Machine Client

このICSでは、IBCにおける”Client”のうちの一つ、”Solo Machine Client”について説明しています。

IBCにおいて、”Client”というのは「検証アルゴリズム」のことを指します。

Solo Machineは、もはやなんでもありです。スマホでもタブレットでもラップトップでも。そのようなSolo MachineからIBCの真正性を検証するために策定されています。

ICS-7 Tendermint Client

このICSでは、IBCにおける”Client”のうちの一つ、”Tendermint Client”について説明しています。

Tendermintによるステートマシン(状態遷移機械。ブロックチェーンのことを仕組みから見て言ってる呼び方)が、IBCを通じてTendermint以外でできたステートマシンやSolo Machineと繋がるときのために用意されています。

ICS-9 Loopback Client

このICSでは、IBCにおける”Client”のうちの一つ、”Loopback Client”について説明しています。

Loopbackは、TCPでいうところのlocalhostです。ようは自分自身に戻ってきます。

同じブロックチェーンの別のモジュールにIBCでつながる、といったことができるようになりますが、これに関しては対象のモジュールが存在していることがわかっている場合、Cosmos SDKでモジュール同士連携させたほうがはやいので実用的なユースケースにはなりません。

つまり連携対象のモジュールが存在しているかどうか何も知ることのできない状態で連携しようとしたいときや、IBCのインターフェースに統一させたいときに使うことになります。

ICS-10 GRANDPA Client

このICSでは、IBCにおける”Client”のうちの一つ、”GRANDPA Client”について説明しています。

GRANDPAはGHOST-based Recursive Ancestor Deriving Prefix Agreementの略であり、Cosmos SDKと対をなすもう一つのブロックチェーン開発キット”Substrate”にも搭載されているコンセンサスアルゴリズムです。

Cosmos SDKのTendermintに相当する部分がSubstrateのGRANDPAだと思ってください、だいたいあってます。

このICSによりどうなるかというとようするにSubstrateで作られたブロックチェーンにIBCが搭載できるということです。Substrate製チェーンがPolkadotリレーチェーンに接続しながらCosmosネットワークに入ることも夢ではなくなるわけです。

ICS-18 Relayer Algorithms

このICSでは、”Relayer”のアルゴリズムを策定します。

Relayerとはなにかというと、オフチェーンで動作するプロセス(ようするにブロックチェーンの仕組みとは別で、ブロックチェーンの外部のアプリケーションとして動作しているもの)です。

このRelayerに相当する部分がなければ、つまりオンチェーンのプロセスだけではIBCは使おうと思ってもうまく使えないので、必須の仕組みとなります。

ブロックチェーンのステートを取得したり、トランザクションを生成して提出したりする機能を持ちます。

IBCを使ったアプリケーションを開発したい方は、Relayerの考え方だけでも把握しておく必要があります。

ICS-20 Fungible Token Transfer

みなさんの中には、ここまで読んで、「IBCって、トークンをブロックチェーン間で送信しあう機能じゃなかったの？こんな大がかりだったの？」と思っていた人がいるのではないでしょうか。

実はその疑問は正しくて、IBCはトークンを送り合うだけの機能ではありません。パケットを通じていかなるデータも送信でき、任意のモジュールでそのデータを任意にデシリアライズ(解釈)することができます。

異なるチェーン間でのトークン送信なんてのは、そのパケットのなかに、トークン情報を入れることでなされるIBCの一つのユースケースにすぎないのです。

IBCは異なるチェーン間でトークンを送信する機能だという説明をよくすることがありますが、簡略化、わかりやすさのためであり、全く正確ではありません。

このICSでは、IBCを使って、トークンを送信する規格を定めています。

IBCを使ったデータ送受信によってなされるユースケースのうち、最も基本的な動作の一つであると思われるので、アプリケーション開発するにあたっては大雑把でよいので把握すると良いでしょう。

ICS-23 Vector Commitments

このICSでは、”Vector Commitments“と呼ばれる構造で、”Commitment”を管理することを規定しています。

“Commitment”とは、簡単に言えばブロックチェーンのステート(ブロックの状態)を暗号学的に検証しやすい状態(暗号学的ハッシュ関数にかけた状態などを想像してください)にしたもので、これをVector Commitmentsの形式で管理することで、IBCにおいて別チェーンがもう一方のチェーンのCommitmentの検証を行いやすくするという目的があります。

ある特定のブロックからブロックへの状態遷移のうち、ステート内の特定の部分だけ検証したいというときを想定して考えられています。

テクニカルな表現ををすると、Level DBのようなKey Value Storeにおいて管理されるステートのうち、特定のパス以下だけを検証したいとき、です。

このICSは、IBCの内部実装の話なので、IBCを独自に実装したい人以外は把握は必須ではありません。

ICS-24 Host Requirements

このICSでは、IBC機能を持つブロックチェーンが備えるべき要件を示しています。

タイムスタンプの取得機能や、エラーハンドリング機能、イベントログシステム、アップグレード機能などが挙げられます。

このICSは、IBCを独自に実装したい人以外は把握は必須ではありません。

ICS-25 Handler Interface

このICSは、IBC機能を利用するモジュール等が備えるべきハンドラーを規定しています。

このICSは、IBC機能を利用したCosmos SDKモジュールを開発したい人は把握しておく必要があると考えられます。ただし、後述のICS-26が、この規定の煩雑さを緩和してくれます。

ICS-26 Routing Module

このICSでは、Routing Moduleを規定します。

このモジュールはICS-25で規定されているハンドラー群を実装するにあたって煩雑な作業を簡略化してくれます。

例えば、Handler Interfaceを直接実装しようとなると、IBCにかかわるすべてのモジュールのステートを管理しないといけなかったりと、難しい点が多いです。

このICSは、IBC機能を利用したCosmos SDKモジュールを開発したい人は把握しておく必要があると考えられます。

ICS-27 Interchain Account

このICSを説明する前に、EthereumのAccountとContract accountの違い、またはCosmos SDKにおけるAccountとModule accountの違いを、説明しておく必要があります。

通常のAccountは、秘密鍵から生成される公開鍵から生成されるアドレスで表されます。ようするに秘密鍵と紐づいています。

一方でContract accountは、スマートコントラクトが管理するもの、Module accountはモジュールが管理するものであり、特定の秘密鍵とは結び付いていません。

そのように、プログラムがプログラムのために利用するアカウントというのを、IBCのためにも用意しておこう、という発想で、Interchain Accountが用意されます。

Interchain accountは、IBCを通じて、他のチェーンによって管理されます。

チェーンをまたいだトークン送信にとどまらず、より深い構成となったIBCアプリケーションを開発したい方は、把握しておくべきICSでしょう。

おわりに補足

zennで販売している「Cosmos SDKの教科書」も今後、Launchpadの説明になっている現状から、Stargateの内容を書き記してアップデートする予定です。すでに購入いただいている方は、そのまま読むことができます。