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

sholanaのshohyo

Introduction

皆さんこんにちは。Skyland VenturesのShoです。

今回は、前回非常に好評だった、UnUniFiのファウンダー、木村優さんとのInteroperabilityに関する議論の続きを文字起こししたものになります。

全議論はビデオポッドキャストとしてYoutubeでも公開しておりますので、そちらも合わせてご活用ください。

Youtube : URL

前回の議論 (Vol1) では、Cosmos IBC、そしてInteroperabilityの基礎的な部分を以下のような順序で議論しました。
① Cosmos とは何か
② Interoperabilityとは何か
③Interoperability Protocolの解説 (Polkadot / Alexar / LayerZero / CosmosIBC) 

Vol.1は以下のURLから確認できますので、もし宜しければ御覧ください。Youtube : URL
Note : URL
Scrapbox (要点のみ) : URL

前回記事はTwitterでも何人か取り上げてくださった方がいらっしゃり、
現在Skylandで行っているハッカソンに「木村さんの動画を見てInteroperabilityやりたくなりました！」という学生さんが参加されたり、かなり嬉しい反響がありました。引き続きヒヤリングの公共財化は進めていきたいですね。

今回の議論 (Vol2) では、前回の解説を踏まえて、
① Interoperabilityの未来像
② Interoperabilityによってできること / IBCの優位性
③ Interoperabilityの達成に向けて足りないこと
をテーマにして解説をいただきました。

前回動画
前回note (7/15時点) 

記事作成の経緯などはVol.1で解説しているので割愛します。

記事の使い方

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

  • ① Summaryだけを読む

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

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

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

  • ② 全文を読む

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

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

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

TL;DR/Summary

Summaryをscrapbox上に作ってます。

ALL CONVERSATION

1. Introduction

松本 : よろしくお願いします。  今回は前回に引き続き、Cosmos系のLayer1 Blockchainの"UnUniFi"のファウンダーをされている 木村優さんに来ていただきました。 本日はよろしくお願いします。

木村 : はい、よろしくお願いします

松本 : 木村さんの自己紹介などは前回のpodcastの方でもnoteの方でも公開しておりますので、そちらをご覧いただければなというふうに思います。 今回はですね。 前Interoperability の説明だったりとか、それを実現するためのプロトコル、そしてそれぞれの説明と差分みたいなところを解説していただいたんですけれども。

松本 : 今回はそれらのプロトコルを全部ひっくるめて、 じゃあ彼らはどうブロックチェーンのエコシステムを変えていくんだっけ？ っていうところについて、話したいなっていう風に思っております。 

木村 : はい、一旦 大丈夫だと思います。

2. The future and problem of Interoperability 

松本 :  ありがとうございます。 では、木村さんは最終的に全てのブロックチェーンがインターオペラビリティを実装して、相互に通信ができる状態になると思いますか？

木村 : そうですね。 まあ全てのブロックチェーンでInterOperabilityの規格は実装できます。 で、それのうち最初は当然ながら そのAxelarみたいなTSS型だったりとか、あるいはLayerZeroみたいなオラクル依存型で低コストで始めるというところから、まずはすでにそれは実装が始まっていますし、使われてもいるんですけども最終的にはですね。IBCのように完全にトラストレスな形のインターオペラビリティに移行して、障害点が最も少ないような形でチェーン自体が繋がっていくんじゃないかなっていうふうに思ってます。

松本 : なるほど、ありがとうございます。 まあ、すでにこういうEVM系でレイヤー Zeroだったりが実装されているっていうお話が前回もあったと思うんです。 けれどもこうCosmos IBCが抱えてる課題だったりとかって、具体的にどういうところがあるのか教えていただいても大丈夫ですか？

木村 : そうですね。 もう、それは前回話した内容とほぼ一緒でガス代です。 IBC をそのまま EVM系で実装しようとすると前回お話した通り、ガス代が非常に高くなるので。 そのガス代を抑えるために、例えばTEE (Trasted Execution Environment) を使ったりとか、ゼロ知識証明を使ってそのガス代を抑えていく。そういうアプローチを取って、EVM上でのIBCを実現するって プロジェクトが出てきてますね。

松本 : それが前回言ってた LCPだったりとかPolymerだったりっていうところはい。

木村 : そうです。 はい。

松本 : なるほど。 ありがとうございます。 僕らはVCなので、じゃあそれが何年後に来るかみたいなところをやっぱりこう考えるんですけど、木村さん的にはこうどういう風に予測されてますか？

木村 : そうですね。これに関しては自分たちがそのプロジェクトやってるわけではないんですけども。 テストネットレベルであれば、まあ年内には絶対に動くぐらいの技術の成熟はしているはずで、メインネット、本番環境でしたら、まあ 来年とか来年後半とかぐらいには実用化されていくんじゃないかな っていう。 個人的な予測はしてます。

松本 : なるほど、ありがとうございます。CosmosIBCの一番の強みっていうところが、トラストレスであること。完全にお互いのチェーンだけで完結していくことですよね。

木村 : ですね。

松本 : 例えばなんですけど、ChainlinkとかBand Protocolよりも分散性のないブロックチェーンって。 どちらかといえば、IBCよりもLayerZeroを使う インセンティブの方が強かったりするのかな？ って思ったんですけど、どうですかね？

木村 : 基本的にはセキュリティの強度は結局変わらないです。 なぜなら通信主体であるチェーン自体が改ざんされれば、結局オラクル部分が 改ざんされなく、結局一緒なので、通信自体のセキュリティのチェーンAとチェーンBとオラクル部分のうち、最も弱い部分に引きずられるという風に考えていただければokです 。

松本 : なるほど。結局自身の分散性がボトルネックになってしまうんですね。

木村 : そうですね。 はい。 なので別にオラクルに頼ったから出て強くなるわけでもなく、結局それは弱いままですね。

松本 : そういうことですね。 ありがとうございました。 結局、その バリゲーターの分散 みたいなところはどのチェーンでも当然必要になってくると。

木村 : そうですね。 

3. What would come true w/ interoperability? 

松本 : 前回、Polkadotの話をしていたときに、パラチェーン同士で関数の参照ができるような話があったりしました。そんなような文脈でInterOperabilityの実現によって、できるようになることを教えていただいてもよろしいですか？

木村 : はい、そうですね。 まずはUnUnifiの機能のうちの一つを説明しようかなと思います。UnUniFiは、NFTFiの領域に特化したチェーンで、機能としては NFT担保のレンディングとかいろいろあるんですけども、そのうちの一つとしてインターチェーンのYield Aggregatorっていう機能があります。 例えばいろんなDEXがあって、そのDEXに流動性供給して利回りを得るとか。 例えば、普通のレンディングに貸し出して利回りを得る とか、いろんな利回りを得る方法がDeFiの中にもあるじゃないですか？ それらを組み合わせたりとかして自動で配分して自動で運用するという機能がYield Aggregatorです。Yield Aggregatorの機能をIBCを使って全チェーンに対応した、というのがインターチェーンのYield Aggregatorなんですね。

CoinTelegraphより引用

松本 : はい。

木村 : 今までのYield Aggregatorだったら、例えばEthereum上にあるAggregatorだったらイーサリアム上の利回りを得るところに配分するとかいうのを今までしてたんですけども、このインターチェーンのYield Aggregatorを使えば、UnUniFi Chainに当然とどまらず、IBCだったり、もしくはAxelarとかを使って接続できる全てのチェーンの利回りというのを、それぞれ自動で配分できるという。  なのでIBCを使えばこんな感じで、チェーンを横断的に、最適な形で運用を自動化することができます。これはもうIBCがないとできないことですね。

松本 : それは圧倒的な資本効率の実現みたいな文脈ですか？

木村 : そうですね。 まあ資本効率っていう意味ではユーザーが手間かけて、それぞれ 手動でやっても資本効率とそんな変わらないんですけど、ユーザーが手間っていう意味ではむちゃくちゃ変わりますね。

松本 : そうなると、実はInteroperabilityというのはUXの部分に深く関わってるっていう認識で大丈夫ですか？ 

木村 : そうですね。Interoperability はUXの改善に影響を与える可能性があります。例えば、Cross ChainのYield Aggregatorであれば、今までは一つ一つのチェーンでそれぞれ行っていた作業を一気にまとめて行えるようになります。

松本 : なるほど、ありがとうございます。最近、CosmosやLayerZeroのようなInteroperabilityのためのプロトコルを使わずに、外から複数のブロックチェーンの流動性プールにアクセスすることができるプロトコルも出てきてるかな って思うんですけど、それらとIBCの決定的な違いってどこになると思いますか？

木村 : そうですね。 ユーザー体験としてはほとんど違いはないですが、やはりIBC自体が最も究極にトラストレスな形で動いてるのはまず一つ。そして、IBCは最も一般化できるというか、IBCは仕様的にうまいことレイヤーが区切られているんですね。IBCはアプリケーションレイヤーとトランスポートレイヤーに区切られていて、さらにポリマーの立場だと、そこステートレイヤーも分けられるっていう。 そういう立場を取っています。

どういうことかって言うとIBCを使って通信して実現されるアプリケーションこそがまさにさっきのインターチェーンのYield Aggregatorだったりして。 別の通信プロトコルを使って実現できるアプリだとFuji Financeとかっていうのがあるわけじゃないですか。

松本 : はい。

木村 : そこで、このトランスポートレイヤーというのは何かを説明します。シンプルにIBCの通信のデータの規格部分だったり、どうやってデータが転送されるかみたいなところを規定してるんですけども、ここをさらにPolymerの立場に立ってステートレイヤーという部分に分割すると何がいいかっていうと、そのIBCの部分のライトクライアントをZk IBCに置き換えたりだとか。 LCPみたいなTrasted Environmentに置き換えたりだとか。 もしくはレイヤー 2に置き換えてOptimisticなIBCっていうのを。仮想的に想定したりとかっていうのができてですね。IBCのこのアプリケーションレイヤーの部分はともかくとして概念としてですね。IBCの設計では、最もその広い対象に当てはめられるように論理的に区切られてるんですよね。そのため、結局最終的にこうInteroperabilityの理解が広がってくると。 やってることってIBCのうちの1個の特殊な形として通信をしてるだけじゃないかっていう風に他のInteroperabilityのプロトコルだと。 なので、User Experienceとしてはほぼ変わらないんですけども。 裏側の技術として最も一般化された形になっているのはどれかっていう。 を考えるとIBCっていうのはかなり一般化されている設計にはなっています。

松本 : なるほど。 一般化されているっていうのはどう言い換えればいいんですかね？

木村 :  言い換えるのはちょっと難しいですね。ライトクライアントをチェーン同士で実装すればトラストレスになります。 これが最も一般的な形の最も標準的な形の IBCですね。 そこを若干トラストフルな形に概念的に置き換えることもできるんですよ。 例えばオラクルを使いましょう。っていう形でオラクルを使った形のステートレイヤーで、IBCのトランスファーレイヤーを使うということもやりようによってはできるわけで。IBCは個人的にアプリケーションレイヤーとトランスポートレイヤーとレイヤーの立場に立って、この3つに区切ると それぞれのパーツを組み替えることによって、実は他のInteroperability Protocolと同じことしてました。 っていう そういう できるっていう事なんですね。

松本 : だから ほとんどのインターオペラ ビリリティはある種、IBCを使って実現できるよっていうところですね。

木村 : そういうことですね。 Layer2同士のInteroperabilityですら、ステートレイヤーの部分にOptimisticなLight Clientを用意すれば、それが実現できるということですね。

松本 : なるほど。

4. What is lacking for Interoperability

松本 : まとめ方が難しいですね笑 では例えば木村さんが、まだこれ足りてないんじゃないかって思う。Interoperabilityのパーツとかあったりしますか？ 結構起業家の方とかも見ると思うんで。

木村 : そうですね。 足りてない部分。実現されていないという意味では、その IBC みたいな汎用的なトランスポートレイヤーに接続できる Layer 2同士で動くようなステートレイヤーとかが足りてないっていうことになりますね。 それを まさに ポリマーはそのZKIBCだけじゃなくて Layer 2同士、モジュラーブロックチェーン同士のIBCとかも実現しようとしていて、まさにそのステートレイヤーの中の一種の形態としてZkIBCってのがあるし、また一種の形態としてOptimisticなIBCがあるっていう。そのOptimisticなIBCとかでもまだまだこれから実現しなければいけないっていう状況で、これ 全然このLayer 2同士のIBCみたいなものは全然実現から程遠いという状況かなと思っております。

松本 : Layer2同士のIBCとLayer1同士のIBCっていうのはどういう点で違うのか、ちょっとお聞きしても大丈夫ですか？

木村 : ます。 そうですね、Layer1の場合はValidatorがブロックに対して署名することによって、そのブロックが確定するというか、確率的なものについては置いていて確定するじゃないですか？ なので、ライト クライアントを実装する際には、ブロックに対するバリデイターの多数決 もしくは2/3以上の署名があるって事を確認すれば済むんですけども、

木村 : 例えばLayer2でロールアップの場合はSequensorがトランザクション を取り込んだという概念的なブロックがありますと。 で、そのブロックが定期的にLayer1ブロックチェーンに対して 都度経過報告みたいな形でこのロールアップされていく中で、結局その経過報告に不正があればペナルティを課す、という形でインセンティブ的にロールアップは安全性が保たれているのですが、結局そこで不正があるとIBCみたいな。 そのライトクライアント みたいな形でブロック自体の正しさがどこにあるのかっていう保証することはできないんですよね。なので、Layer1同士のライトクライアントであれば、ブロックの署名を検証すればよかったものを、Layer2同士のIBCを組み替えて実現しようとすると、不正があった場合のペナルティとかそういうところまで一緒に考えないといけない 。

松本 : なるほど。Layer2自身がバリデータを持たなくて、比較的中央集権的なシーケンサーっていうところに頼んでるからこそ、ちょっと難しさがあるというか、一言で言えば不正に対しての分岐が多いんですかね？

木村 : そうなんですよ。 なので、Layer2同士でIBCを実装しようとなるとその理論上できるんですけども、結構考えないといけないことが多い。

松本 : ありがとうございます。 一応ポリマーはそこに取り組んではいるんですね。

木村 : はい。PolymerはZK IBCだけではなくて、L2同士のInteroperabilityみたいなところにも取り組んでいます。

なるほど、ありがとうございます。

松本 : ちなみにInteroperabilityを持つLayer2といえば、Celestiaを利用したIBCを搭載したLayer2はどうなんですかね。これはCelestiaの上に乗ったLayer2 ブロックチェーンということで良いんでしょうか。

木村 : そうですね。Celestiaをデータアベイラビリティレイヤーとした、Celestiaの上に作られたLayer2ブロックチェーンになります。Layer2ブロックチェーンは、今後そのポリマー的な考え方を使えばLayer2なんだけどIBCが使えるというモジュラーブロックチェーンになりますね。

松本 : なるほど、ありがとうございます。 すごい、ちょっと複雑なのでなんか図にしてなんかやってもいいかもしれないです。

木村 : ね、そうですね。 今回は まとめるのが難しいかもしれないです。

松本 : 今回は、Interoperabilityがこれからどうなっていくかというところ、そして現在足りないパーツの話を行っていきました。結構興味深い話というか、引きが強い話を何個かできたかなと思っております。結構今回の二回のPodcastを通じて、いろんな人に見ていただき、Skyland Venturesとしてもとても勉強になりました。本当にありがとうございました！


いいなと思ったら応援しよう！