インターオペラビリティとCosmos IBCのいろは Vol.1 【UnUniFi 木村優さん】

sholanaのshohyo

Introduction

皆さんこんにちは、Skyland Venturesの松本 頌平です。私はSkyland Venturesにてキャピタリストとして1年ほど勤務し、web3系の投資・リサーチ等を担当しております。

今回は、Skylandが巻き起こしているモーレツなPodcastラッシュに感化され、自分が担当する領域の一つでありながら中々追えていなかった【Interoperability】の領域についてPodcastを撮ることにしました。そこでお話を聞いたのはCosmos系のL1チェーンである " UnUniFi" を構築されている木村優さんです。

木村さんに、初見の人向けにこれまでの経歴をまとめたサイトなどありますか？と聞いところ、これ読めば大体わかるよと仰られたので共有します。

https://twitter.com/kimurayu45z/status/1499334130416291842?s=46&t=Rkp3txb3SE2aFfLKXocNtQ

ヤバ記事でした。

Concept of this article

記事作成の経緯

元々YoutubeとSpotifyのみで公開しようと思っていたのですが、「インターオペラビリティ」という今後数年において非常に重要なテーマについて、かなり多くの知見・気づきを得られるPodcastになったので、是非文章にも残そうということで書いています。木村さんがめちゃくちゃ優しく、正直あまりこの分野に詳しくない自分でもしっかりと理解できる喋り方にしてくれたので、その恩はより多くの方に読んでいただけるよう頑張ることで返そうかなと。後は僕の相槌がちょっと邪魔だったので文章にしました。

聞いてもらいたい / 読んでもらいたい人

  • 以下の中にまだ十分な解像度がないと当てはまる言葉が一つでもある人

インターオペラビリティ / Cosmos / Layerzero / Polkadot / Axelar

  • 次の質問に対する答えを知りたい人

Q1. インターオペラビリティを実現する以下のプロトコルにはどのような違いがあるか。(Cosmos / Layerzero / Polkadot / Axelar)
Q2. Cosmos IBCはEVMのブロックチェーンに対応することができるか。
Q3. 複数チェーンにDappsを開発する際、App-Specific chainを構築する場合とマルチチェーン展開をする場合にはそれぞれどのようなメリット・デメリットがあるか。 (Hint : MEV)
Q4. Cosmos上のプロジェクト「Celestia」は、CosmosIBCのどのような課題を解決するために生まれたか。

記事の使い方

この記事は、同じ内容を二種類の方法で読めるようになっています。

  • ① Summaryだけを読む

    • ## TL;DR/Summaryより、Scrap Boxのリンクに飛んでください。

    • ある程度ブロックチェーンの仕組みなどに詳しい人はこれだけでわかると思います。

    • Summary片手にPodcast or Youtube聞くのとか結構有りだと思います。大事なところを先読みしながらだとわかりやすいです。

  • ② 全文を読む

    • ## ALL CONVERSATION より、直接読んでください。

    • たまに用語解説など乗っています。

    • 音声・動画の視聴が面倒な方はおすすめです。

TL;DR/Summary

Summaryをscrapbox上に作ってます。

ALL CONVERSATION

続いて、議論の全体を読みたい方のために文字起こしを作成しました。一部　簡潔な表現にするために、文章の編集やカットなどを行っております。では、開始。

1. Interoduction

松本 : 今日はCosmos上で、L1ブロックチェーンである"UnUniFi"を開発されている木村さんに来ていただきました。宜しくお願いします。

木村 : お願いします。

松本 : Skylandは今インターオペラビリティ、Crosschainという領域への投資を増やしていきたいなと思っていて、その中でもやはりCosmosのエコシステムってのは強力だなと感じており。最近はCelestiaのような超大型のプロジェクトも出てきて、追うべきなのはわかっているのですが知識不足で。そこでCosmosの最前線で戦う木村さんにお話を聞こうと思い、今回の場をセッティングしました。木村さん、まずは是非自己紹介をお願いします。

木村 : はい、まずCosmos「系」ですね、Cosmos「上」ではなくて。Cosmos系でレイヤー1のブロックチェーンを作っているんですけども、UnUniFiというブロックチェーンを作っています。木村優と言います。

木村 : ブロックチェーンの立ち位置としては、いわゆる "App-Specific"というか、"Sector-Specific"と呼ばれるような、目的に最適化したようなブロックチェーンでして、領域はNFTFiと呼ばれるNFTとDeFiをラップしたような、そういう領域のものなんですけども。Cosmos系のチェーンということで、CosmosIBCと呼ばれるブロックチェーンを相互運用するための通信規格に対応したブロックチェーンになっています。今回のPodcastは、IBCとかインターオペラビリティを中心にお話しているというふうに言ってましたので、そこを覚えていただければと思っています。

松本 : その通りですね。それでは最初のテーマに行きたいんですけども。最初はCosmosってなんだっけというところですね。そしてInteroperabilityを実現する方法として、Cosmosの他にもBridgeやPolkadotなど、いろんな方法がありますけど、なぜCosmosを使うのかというところを聞きたいですね。

インターオペラビリティ / Interoperability とは :
日本語では、主に「相互運用性」という訳が当てられる。独立に存在するコンポーネント間で相互に組み合わせて運用可能であること。
ブロックチェーンの文脈では、異なるブロックチェーン同士が任意の情報を送受信できることを差す。

コトバンク

2. Cosmos を構成する3つの要素

木村 : はい、まずはCosmosって単語を整理する必要があります。よくある誤解として「Cosmosが単一のブロックチェーンの名前である」というのがあるんですけど。正確にはそうではないので。

木村 : Cosmosには3つの意味があります。それは「Cosmos Hub」「Cosmos SDK」そして「Cosmos IBC」ですね。この内ブロックチェーンを意味するのは「Cosmos Hub」だけです。これはAtomをガバナンストークンとして動いているブロックチェーンの名前です。

木村 : そしてCosmos SDKって何なのかっていうと、僕らが作っている "UnUniFi" のようなパブリックブロックチェーンを開発するためのソフトウェアライブラリです。Cosmos HubっていうブロックチェーンもこのCosmos SDKを使って作られています。他有名なところでは、Osmosis、Injectiveなどがあります。

ソフトウェアライブラリとは :
プログラミング言語において、よく利用すると思われる関数や機能、データなどをまとめたファイルのこと。ソフトウェアの開発メーカーなどから提供されることが多い。ライブラリには、実行ファイルに直接組み込まれるスタティックリンクライブラリと必要なときだけライブラリの機能を呼び出すDLLがある。

コトバンク

木村 : そしてCosmos IBC。これは異なるブロックチェーン間を相互運用、連携するための通信規格の名前です。ここまでの情報をまとめると、UnUniFiだったり、Cosmos Hubだったり、Osmosisだったり、色々なCosmos SDKを使って作られたブロックチェーンがあります。で、それらのブロックチェーンはCosmos IBCという通信規格を使って通信ができます。ということですね。

木村 : Cosmos上ではないよ、とはじめにいったのは、UnUniFiはCosmos Hubの上に立ってるわけはないよとってところでですね。Cosmos上、と言ってしまうとどうしてもLayer2ブロックチェーンや、サイドチェーンのように聞こえてしまいますから。Cosmos HubとUnUniFiの関係は、あくまで対等なものです。

松本 : なるほど。

木村 : Cosmos IBCを使うと、一切の親子関係、従属関係なしにブロックチェーン同士が相互運用できるんですけども、Cosmos SDKには標準でこのモジュールが実装されています。なのでCosmos SDKを使って作ったブロックチェーンは、Cosmos IBCを搭載することが非常に簡単にできるようになっています。

3. Cosmos IBCに関する誤解

木村 : ただし一つ重要な点があって、Cosmos IBCっていう通信規格は、 Cosmos SDKによって作られたブロックチェーンだけで使えるわけではないんですね。

木村 : なのでやろうと思えば、Polkadotでも、Nearでも、理論上はEVMでもCosmos IBCを実装して、インターオペラビリティを実現することが可能です。 Polkadot上のプロジェクトではComposable FinanceっていうところがIBCを実装していたり、最近ではデータチェーンさんという会社がTOKIというプロジェクトを発表しましたけど、それはLCPっていうプロジェクトを使ってEVMのブロックチェーンでIBCを実現しようしていますね。他にも、Polymerっていうプロジェクトが海外にあるんですけども、こういったプロジェクトはゼロ知識証明、ZKPを使ってIBCをEVM上に実装しようとしています。

木村 : 大事なことなので何回でも言いますけど、要するにCosmos IBCってのはCosmos SDKで作られたブロックチェーンには限らない、どのブロックチェーンにも理論上搭載することができる通信規格になります。

4. EVMとCosmos IBCの相性

松本 : なるほど。ちょっと気になったんですけど、ということは、これまでは Cosmos IBCをEVMに搭載するには技術的なハードルがあって、そこを解決するためのプロトコルが最近生まれてきた、みたいな認識で会ってますか？

木村 : 全く仰る通りですね。単純にCosmos SDKを使わずに実装するのに工数がかかるってのもあるんですけど。もう一つ実装上の問題として、ガス代が非常に高くなるってのもあるんですね。例えば、あるプログラミング言語でIBCを実装して、EVM系のチェーンに実装してみましたと。IBCは"Lights Client"という機構を使って作られた規格なんですけども。このLights Clientと呼ばれるパーツが非常にガスを消費するんですね。さらに正確に言うとデジタル署名の検証が必要なんですけど、これがガス代を高くする。だから現実的なガス代ではIBCを動かせないという課題があったんです。

木村 : それをLCPプロジェクトだったら、Trusted Execution Environmentを使って、オフチェーンでこの証明の検証を行って、オンチェーンの検証コストを安くする。そしてPolymerの場合はゼロ知識証明の技術を使ってデジタル証明の検証にかかるガス代を圧縮するというところで、実用的なレベルでIBCをEVM上に実装するというアプローチが取られていますね。

松本 : ありがとうございます。そんな中で、例えば今説明していただいたCosmos IBCという通信規格と、他のInteroperability Protocolとの違い、そしてCosmosの優位性はどこかなというのを教えていただきたいです。

5. インターオペラビリティの定義

木村 : そうですね。まずはインターオペラビリティの定義として、狭義と広義の２つを説明します。ただのブリッジの機能であってもインターオペラビリティに含めてしまうという考え方は、非常に広義なものです。これの定義にしてしまうとかなり話が広くなってしまうので置いておいて、ブロックチェーン間で任意のデータを送受信できるという狭義の意味をインターオペラビリティの定義とします。

木村 : これができるプロトコルは今回4つ紹介します。まずは「Cosmos」。そして「Polkadot」、「Axelar」、「Layerzero」。他にはAvalancheのサブネットなども一応ありますが、今回は説明の役には立たないので置いておきます。基本的にはPolkadotと同じだと考えておいてください。

6. Protocol ①Polkadotについて

木村 : Polkadotは、Polkadotの「リレーチェーン」という、DOT Tokenによって動いているHUBのブロックチェーンがありまして、このHUB Blockchainに対してパラチェーンと呼ばれるブロックチェーンが複数接続しています。代表例がAstar Networkですね。

木村 : このパラチェーンは何なのかっていうと、リレーチェーンに面倒を見てもらっているブロックチェーンのことですね。彼らはセキュリティをリレーチェーンに依存しています。その代わりに、トークンの時価総額が低いパラチェーンだったとしても、リレーチェーンを動かしているDOTトークンが買収されない限り、トークンの買い占めで乗っ取られることはありません。

松本 : Cosmosとは全然違う仕組みですね。

木村 : そうですそうです。これを個人的にはMerge Validationと呼んでるんですけど。PolkadotはXCMと呼ばれるデータフォーマットに基づいたデータをパラチェーン間でやり取りすることができますが、これは「一旦は」このMerge  Validationを前提のものとして実装がされてます。

木村 : 一説によれば、どうやらこのXCMというのは所詮データフォーマットなので、Merge ValidationがMUSTではないと言われてはいるのですが、現状ポルカドットのMerge ValidationがなされていないところでXCMが使われている例はないので、一旦このPolkadotのインターオペラビリティであるXCMは、Merge Validationを前提としていると説明しておきます。

木村 : これはつまり、Polkadotのリレーチェーンに接続していないブロックチェーンっていうのは、XCMを利用してPolkadotのパラチェーンと通信するってことが現状できない状況になっていますね。さっきもちょっと話したAstar Network と Composable Financeというチェーン同士はどちらもPolkadotのパラチェーンなので、XCMを使って通信ができます。ちなみにTokenを送受信するだけではなく、例えばAstar上のこの機能を呼び出したいなど、そういうのもできます。これがトークンブリッジに限らない広いユースケースですね。

7. Protocol ②Axelarについて

木村 : 次に面倒くさくないのがAxelarなので、Axelarについて解説していきましょう。AxelarはTSS (threshold-signiture-scheme) と呼ばれる仕組みを使ってメッセージングを実現しているブロックチェーンなんですけども。機構的には非常にシンプルで、Axelarというブロックチェーンがそもそも存在するんですよ。そしてValidatorがいて、署名をするんですよね。そしてその署名で多数決を得られたようなデータであれば、送信してOKだという。非常にのろくさい、シンプルな、古典的なブリッジとよく似た手法でAxelarは実現されています。

木村 : Axelarとブリッジの異なる点といえば、Axelarの場合はただトークンを送るというだけではなくて、データの送信もできるというふうになっています。そして、基本的にはEVM系のチェーンで対応がなされていますね。これがAxelarの General Message Passing という仕組みです。

木村 : ただし、ここで非常に重要なのは、この仕組みがAxelarというブロックチェーン自体に依存してしまっているというところですね。これから紹介するLayerzeroとCosmosは、この依存先、つまり単一障害点になるような部分をできるだけなくそうという思想で作られています。

松本 : なるほど。

8. Protocol③ Layerzeroについて

木村 : LayerzeroとCosmosは非常に似ているので、どっちから話してもいいんですが、先にLayerzeroの仕組みから説明しましょう。Layerzeroを使用したMessagingを考えるときに、ブロックチェーンAとブロックチェーンBがある場合、AとBはAxelarのようなブロックチェーンに依存しているわけでもありませんし、Layer0というブロックチェーンが存在するわけでもありません。ではどのようにメッセージを送るかを解説します。まず、Layerzeroの Lights Clientというパーツ、IBCにもあったものですね。これを使って、ブロックチェーン Aとブロックチェーン Bのヘッダー部分をとある場所に保管します。

ヘッダー部分とは :
ブロックにおけるハッシュ値 (データが暗号化されたもの) や、全トランザクションを圧縮したものを取り込んでいる部分。あるトランザクションが正しいかどうかを数学的に証明するために必要な情報。

松本が書いたので間違ってるかも

木村 : そのとある場所というのが、Layerzeroの場合はChainlinkやBand ProtocolのようなOracleなんですね。で、チェーンAからチェーンBにメッセージを送りたい場合は、relayerと呼ばれる機構がこのメッセージを伝達してくれるんですけど、当然そのメッセージが悪意のあるものかどうかを検証する必要がある。そこでオラクルに保存した通信相手 (チェーンB) のヘッダー情報を参照する。これによってメッセージの正当性を検証しているんです。

松本 : なるほど、面白いですね。

木村 : なぜここでChainlinkやBand Protocolのようなオラクルが出てきているかということなんですけども、ここがIBCとの最大の違いで、ここを説明するために一旦IBCの説明に移ります。

9. Protocol④ Cosmos IBCについて

木村 : Cosmos IBCの場合、ブロックチェーンAとブロックチェーンBがあったとして、例えばCosmos Hubだったり、Axelarだったりといったブロックチェーンや、Chainlinkのようなオラクルに依存する必要が一切ありません。チェーンAとチェーンBだけがあれば、それだけでIBCは動きます。何回も話しますけど、一切依存関係はありません。

木村 : チェーンAからチェーンBに対して任意のメッセージを送る際には、ここもやはりrelayerと呼ばれるLayerzeroと同じパーツがあるんですけども、彼らがメッセージの伝達を行います。ここでやはりrelayerに悪意がないことを確認する必要があります。その際IBCでは、通信相手のブロックチェーンのヘッダー部分を、自分のブロックチェーンに直接取り組むんですね。つまり、オラクルにブロックのヘッダーを取り込むLayerzeroの方式ではなく、当事者であるチェーン同士で完結できるような形になっているんです。メッセージが送られるとき、自分のブロックチェーン内にある情報だけで、relayerが嘘の情報を伝達していないかどうかを検証できるのがCosmos IBCです。

木村 : なので、LayerzeroとIBCの最大の違いはなにか、というと、通信相手のブロックチェーンのブロックのヘッダ検証をどこでやっているかということなんです。IBCはチェーン自身でやっているし、Layerzeroはオラクルに投げているんですよ。ただ逆に言えば、IBCはブロックヘッダーを自分で持つことにコストがかかるという部分がトレードオフなんですけどね。

木村 : Layerzeroはオラクルに依存するかわりに、コストが抑えられますので、現状EVMだったりで動くようなブロックチェーンで既に動いている状態で使われています。一方でIBCは先程言ったように、EVM上で実現しようとするとガス代が非常に高くなるんですが、このガス代が高くなる原因っていうのがまさにここなんですね。ブロックヘッダーを取り込んで署名を確認するっていうところがまさにガス代が高くなる原因で、Layerzeroはそこをオラクルに任せてしまっているので、ガス代が高くなる心配がありません。

松本 : めちゃくちゃ面白いですね。つまり、インターオペラビリティのプロトコルは、relayerの悪意を防ぐためにトラストレスである必要があるけど、その仕組みにもトラストとガス代 (コスト) のトレードオフがあって、それをどのように評価するかによってプロジェクトが変わってくるということなんですね。

木村 : まさに仰る通りですね。オラクルもまあ確かに分散的に動いているというか、Chainlinkは確かに分散化されたネットワークなので、「分散化されたネットワークをトラストすることはトラストではない」という見方もできますし、「巨大な分散化されたネットワークをトラストすることはトラストフルだ」という立場をとるならば、IBCはトラストレスだけどLayerzeroはオラクルをトラストしているという見方もできることになります。ここは現実的に実用的なコストとトラストレスのトレードオフを考える必要がありますね。IBCはある種理想主義者的なスタンスだとも言えます。

10. マルチチェーン展開とApp Specific Chainの差分

松本 : ありがとうございます。今、4つのインターオペラビリティプロトコルとその仕組み、メリットやデメリットみたいなところを教えていただきましたが、木村さんがUnUniFiを開発するときにCosmosを選んだ理由など教えていただけますでしょうか。

木村 : そうですね 当時は別にLayerzeroが普及してたとかCosmos IBCとLayerzeroの比較が十分にできたみたいな時代でもなかったので、別に今さら結果論的に言うつもりは無いんですけども (笑) これはLayerzeroにも言えることですが、Cosmos IBCに対応したブロックチェーンとして作っておけば、IBCで後からでも別のチェーンにいくらでも繋がれるからですね。

木村 : インターオペラビリティがないブロックチェーンにアプリケーションを開発した場合、マルチチェーン展開というのがありますけど。例えば、Ethereumで作ったDappsをBSCやPolygonにコピーしたりというものですね。しかし、これの大きな問題点は流動性が分散してしまうというところなんです。

木村 : 例えばDEXのDappsを作る事業者を例に挙げましょう。Uniswapみたいなものですね。これをEthereumにデプロイしました、Polygonにも、Avalancheにも、BNBにもデプロイしました。するとそれぞれ流動性プールができるんですけども、この流動性プールを共有することはできないですよね。この分散をフラグメンテーションが起きるともいうんですけども、そういった問題が発生します。一方でクロスチェーンのインターオペラビリティの機能があると、そういった流動性の部分を共有するっていう機構が作れたりします。

木村 : その典型がLayerzeroの Stargateであったりとか、LCPのTOKIだったり、PolymerのCatalystというプロジェクトもあるんですけれども。そういった感じで流動性を共有するっていうところまでインターオペラビリティを使えばできるんですよね。

11. App-Specific chainのハードル

松本 : ありがとうございます。こう聞くと、Dapps、例えばUniswapなんかがどうしてAppchainを作らないかみたいなのが結構気になってくるんですけど、そこを深掘りしても大丈夫ですか。

木村 : そうですね、Uniswapなんかはもう既にEthereum上でポジションを撮ってしまっているので移動するインセンティブもないのかなと思いますけど (笑) 新規に参入するところでいえば、EVMの上でマルチチェーン展開を選ぶか、インターオペラビリティのあるApp-Specific Chainを選ぶのかという決定における基準はいくつかあります。まず、チェーンを作る場合はValidatorが当然必要になるので、それを集める労力が無駄だと感じる開発者もいます。UnUniFiはちゃんとValidatorを集めているので、分散化された形でネットワークは動いてるんですけども。そういった業務を発生させずに、あくまで開発に集中したいというチームであれば非常に理解できますね。

木村 : ちなみにこれを解決するソリューションは既にありまして、例えばCelestiaとかDimensionって呼ばれるプロジェクト。これもCosmos系のプロジェクトなんですけども、彼らはモジュラーブロックチェーンといってLayer2のブロックチェーンを簡単につくれるようなプロジェクトなんですね。これまではCosmos SDKを使ってLayer1ブロックチェーンを作っていましたが、彼らを使えばCosmos SDKでEthereumのセキュリティに依存したLayer2のブロックチェーンを作れる。Layer2であれば別に自分たちでValidatorを集める必要は無いじゃないですか。あくまでSequencerがいればLayer1の上に乗っかるだけなので。まあいかんせんちょっとまだ新しい領域なので、これが浸透するにはまだまだ時間がかかってくるという現状もあるかとおもいます。

12. インターオペラビリティとMEV

木村 : 実は個人的ににApp-Specific Chainを選んだメリットは他にもあり、それがアプリ層だけではなくて、コンセンサスレイヤーを含めたカスタマイズだったりチューニングができるというところもありまして。これは最近確信を得ただけの結果論でもあるんですけども、最近MEVっていう単語を聞いたことはありませんか。

松本 : もちろんあります。

木村 : このMEV問題に対応する手段として、このCosmos SDKでLayer1でもLayer2でもいいんですけども、コンセンサスの部分からMEVの対策を仕込んでやるというチューニングをすることが可能なんですね。一方で、EVM上のブロックチェーンでDappsを作るだけだったら、コンセンサスの部分には介入できないじゃないですか。当然、Flashbotとか色々出てきてますけども。

松本 : そうですね。

木村 : Cosmos系でもMEVに関する研究を専門にしているところがあって、Skip Protocolなどかなり研究も進んでいます。そういったところのコンセンサスレイヤーも含めたチューニングだったりとかっていうのは、やっぱり目的に特化したブロックチェーンを作るっていうところの最大のメリットかなっていうふうに考えています。

松本 : いやそこはものすごく興味深いですね、最近はMEVってどこでも話を聞くところで、例えば今はL2-L1間のMEVも良く話を聞きますが、縦だけじゃなくて横のMEVもあるよなあと思っていたところでした。

松本 : 大変申し訳無いのですが、使っている会議室の時間の関係でここまでとさせてください。ちょっとまだ議論したりないところが多いと思うので第二回とかやっても大丈夫ですか？

木村 : いいですよ。

松本 : ありがとうございました。今日はインターオペラビリティが今後重要になっていくという仮説が確信に変わるとても良い機会だったと思います！本日は本当にありがとうございました。

木村 : ありがとうございました。

終わりに

木村さんの説明めっっちゃくちゃ丁寧かつわかりやすくて感動しました。時間の関係でMEVの話など深ぼれなくて残念でしたが、ちょっと情報量が圧倒的過ぎたので、このくらいで良かったかもしれません (これ以上はパンクする) 。第二回も是非やらせていただきたいと思っているので、次回は下記の辺りを更に具体的に聞いていこうかなと思います。

- MEVを防ぐための具体的なコンセンサスレイヤーのチューニング方法
- Interoperabilityが必要なユースケース・そうでないユースケース
- Interoperability protocolが広がっていくために必要なこと
- 木村さんが想像する Interoperabilityの未来
- あと時間あればZetachainに関しても

あと文字起こし全部やるのは、AIを使ってるとはいえ正気の沙汰じゃないのでもうやらないかもしれないです笑。Videoとサマリーで魅力が伝えられるように、次からは相槌も抑えめで、しっかりとゲストの方の話を遮らないようにしたいですね。





この記事が気に入ったらサポートをしてみませんか？