Cosmos のインターオペラビリティ — 現状と進展

2019年9月20日 2019年9月20日

Cosmos のインターオペラビリティ — 現状と進展

https://twitter.com/TheInterchain/status/1163217199487565824 — A visualization of an IBC packet traveling between two blockchains

Cosmos は「A Network of Distributed Ledgers」(White Paper から引用)を掲げ、Scalability, Usability, Interoperability という 3 つの側面から既存のブロックチェーンにおける問題を解決しよう(公式サイトから引用)というプロジェクトです。2019年3月に待望の mainnet 稼働を迎え、コンセンサス部分を担う Tendermint と、それを含んでアプリケーション固有のブロックチェーンを作成するフレームワークとして提供されている Cosmos SDK は、すでに Scalability と Usability について(彼らの主張している範囲では)一定の成果を示していると言えるかもしれません。

一方で、むしろそれらよりも世間から取り上げられることの多かった Interoperability とその仕様として当初より存在が示されていた IBC(Inter-Blockchain Communication) については、2019年9月時点で動作するソフトウェアとして実現はされていません。実は IBC の仕様は https://github.com/cosmos/ics として公開されており、近頃になって RC(release candidate) と銘打ったバージョンがリリースされるなど最終的な仕上げ段階に移っていることが見てとれます。しかし、(私の感覚では)まだ詳しい内容どころかその仕様が公開されているという事実さえもあまり認知されておらず、関係者の会話においても根拠が不確かな言説が多いというのが現状のように思います。

HashHub では Sanka Network として Cosmos のバリデータを運用していることもあり、Cosmos が目指す理想の根幹をなすであろう ICS について積極的にキャッチアップしていこう！と輪読会を始めました。ICS として finalized されるには実装例を示す必要があるとされていますが現時点でそこまではまだ進んでいないため、抽象的な定義から全容を把握していくことになります。当然ながらそれなりに難しく開催数回ですでに苦労しているところです。と同時に、分からないことが分からないというような状態から少しずつメンバー間の会話が具体的になりつつあり手応えも感じています。

ICS 内の実装例ではなく実際に使えるものとしてのソフトウェア実装については、実装中あるいは実装予定のパーティが https://github.com/cosmos/ics/blob/master/ECOSYSTEM.md として公開されていますのでそちらもチェックしてみてください。ただし、唯一ステータスが “Alpha” とされている Cosmos SDK への PR もコメントアウトや TODO だらけで、かつ、一部の ICS を実装しただけに見えるような状態です。また、これは実装スケジュールそのものについての言及ではないですが、2019年11月に行われるとアナウンスされたハッカソンでは参加者がプロトタイプの IBC を利用できるようになっているはずとの言及もあるので、(本当なのか？と思わなくもないですが…)案外近いうちにひょっこり公開されるのかもしれません。

さて、残りのスペースではどんな ICS が定義されようとしているのかその概要を spec.pdf の順序通りにご紹介して終わりたいと思います。まだ全くと言っていいほど読み込めておらず、各 ICS の定義の synopsis として記述されている部分を斜め読みした結果をかいつまんで列挙する形ですので正確ではない情報も多いかと思いますが、気になった方はぜひ一緒に ICS (と、ゆくゆくはその実装！)を読みましょう。この記事をきっかけに ICS に少しでも興味を持ってもらえたのであれば幸いです。

ICS 001 — ICS Standard

ICS のプロセス自体について。ECMAScript の TC 39 を参考にしている
最終ステージである Finalised と認められるには、参照実装が複数存在すること、エコシステムにおけるステークホルダー全員と仕様策定のコアチームが賛同していること、受入テストが記述されていることなどが条件とされている
ICS に必要とされる文書構造や言語・擬似コードの指定

ICS 023 — Vector Commitments

複数の要素からなるリストに、ある要素が入っている(or いない)ことを効率よく証明する仕組みについて、それが持つべき関数とプロパティ
一方のブロックチェーンで発生したステートの遷移を別のブロックチェーンで検証できるようにするため、特定のインデックスにある要素が入っている(or いない)ことを暗号学的に証明できなければならない
具体的な実装を隠蔽した記述になっているので掴みづらいが、RSA Accumelator のようなものが想定されている？(よく分かってません…)

ICS 024 — Host Requirements

IBC 実装をホストするブロックチェーンに求められるインターフェースやプロパティについて
具体的には、ステートを格納する KVS、ステートの検証を外部から行うために必要になる情報を公開する関数、Solidity の revert/require/assert のように例外を取り扱う仕組みなど

ICS 002 — Client Semantics

IBC 実装をホストするブロックチェーンが満たさなければならないコンセンサスアルゴリズムのプロパティについて
ライトクライアントという単語が色々な使われ方をしていて今のところ一番よく分からない…

ICS 003 — Connection Semantics

ブロックチェーン間の接続の抽象化 = Connection について
二つの異なるチェーンそれぞれにステートフルなオブジェクトが存在しそれぞれ相手のチェーンのライトクライアントと関連づけられており、チェーン間のステートの検証とパケットの(チャンネルを介した)関連づけを担当する

ICS 005 — Port Allocation

ポートはチャネルの両端であり、どのモジュールと対応させるかについてポートを割り当てたり変更・解放することで表すことができる
TCP/IP のように数字に対応するものではない
(私の現時点の理解では) Hoge チェーンのポート Foo (Bank モジュールにバインド済み)と、チェーン Fuga のポート Bar (Bank モジュールにバインド済み)がチャネル Ch-Aを構成し、同様の二つのチェーン間のチャネル Ch-B, Ch-C をまとめるようにコネクション Conn が存在する

ICS 004 — Channel & Packet Semantics

メッセージ伝送についての順序、重複制御(同じものは一度だけ伝送する)、モジュール許可(対応するモジュールにのみ伝送)を持たせた抽象概念をチャネルと呼ぶ
コネクションは1つ以上のチャネルを持つことができる
送受信するモジュールがどうやって送信するパケットを構築するか、受け取ったパケットを処理するかなどをコントロールしなければならない
チャネルはペイロード(チャネル上でやりとりされるデータ)には関知しないので、送受信するモジュールが送信するパケットをどのように構築するか、受け取ったパケットの処理方法などをコントロールしなければならない

ICS 025 — Handler Interface

IBC ハンドラーが同一ブロックチェーン内の他モジュールへ公開するインターフェースについて

ICS 026 — Relayer Module

外部からのデータグラムを受け取りIBCハンドラーを呼び出してハンドシェイクとパケットリレーをを処理するモジュール。ややこしいがこのリレイヤーモジュールと後述の ICS 018 で出てくるリレイヤープロセスは明確に異なるものを指しており、後者はオフチェーンで実行される独立したソフトウェアで2つのブロックチェーンを接続するものとされている
モジュールの検索テーブルを持っており、これを利用してパケットを受信した時に対応するモジュールを呼び出す。外部のリレイヤープロセスはリレイヤーモジュールにパケットをリレーするだけで済む

ICS 018 — Relayer Algorithms

ブロックチェーン間の現実の接続について
オフチェーンで実行される具体的な行動でデータをリレーする。例えば両チェーンのステートをフェッチして、適切なデータグラムを構築し他方のチェーンでトランザクションを介して更新を実行するなど

ICS 020 — Fungible Token Transfer

fungible token を転送するためのパケットデータ構造・ステートマシンの処理ロジック・エンコーディング詳細
既存の asset tracking module とリレイヤーモジュールとの間で動作する
アプリケーション層の標準なのでこれだけ IBC/APP 扱い

Appendix A: Use-case Descriptions

ユースケース集

Appendix B: Design Patterns

特徴的なデザインのその由来
リレイヤーモジュールとIBCハンドラーの関係が Call receiver の章に書いてある

この記事を最後まで目を通してしまった稀有な人はさっそく https://github.com/cosmos/ics で続きを読んでみてください！

お知らせ

■ステーキング事業の提供を始めました！
7月からHashHubでは、Cosmos,Tezos,IOSTの3つのトークンをステーキング出来るサービス「Sanka Network」を提供し始めました。本サービスのご利用をご検討の方は、下記のWEBサイトからお問い合わせください。

Sanke Network：https://www.sanka.network/

■fressetsは積極的に採用を行っています！詳細は下記のリンクからご確認下さい。
Link: https://fressets.com/careers/careers-416/
Link: https://fressets.com/careers/careers-0/

■HashHubでは下記のポジションを積極採用中です！
・コミュニティマネージャー
・ブロックチェーン技術者・開発者
・ビジネスディベロップメント
詳細は下記Wantedlyのページをご覧ください。

Wantedly：https://www.wantedly.com/companies/hashhub/projects

■HashHubでは入居者募集中です！
HashHubは、ブロックチェーン業界で働いている人のためのコワーキングスペースを運営しています。ご利用をご検討の方は、下記のWEBサイトからお問い合わせください。また、最新情報はTwitterで発信中です。

HashHub：https://hashhub.tokyo/
Twitter：https://twitter.com/HashHub_Tokyo

Cosmos のインターオペラビリティ — 現状と進展 was originally published in Blockchain Engineer Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.