This article is in Japanese. Click here for the English version.

最近では、App-specific chain/rollup thesisが広まったことにより、chain/rollup開発のためのSDKやRollup as a Serviceが普及してチェーンやRollupが増加しています。そのため、それぞれのチェーンやRollup、そしてユーザーはこれまで以上のStateの断片化 (not only liquidity) に晒されてれています。これが一般的な相互運用性の問題であり、この問題に取り組むために多くのLiquidity BridgeやMessagingプロトコルが開発されています。

しかし、このようなLiquidity BridgeやMessagingプロトコルが相互運用性の問題を完全に解決しているわけではありません。基本的にこれらのプロトコルは特定のアセットやデータをあるチェーンから他のチェーンに”POST”することに最適化されています。

しかし、実際の通信技術には”POST”だけではなく”GET”の機能が存在し、ブロックチェーンの通信においてもあるチェーンから他のチェーンのデータにアクセスするプロトコルが必要だと考えています。これによって本来Bridgeさせる必要のないデータ (ex. NFT) をBridgeすることによって発生する同期コストを削減することができます。

そこで私たちはよりシームレスなブロックチェーン間の通信を実現させるために、Omni-chainのデータ取得に特化したプロトコルであるFutabaを開発しています。

FutabaにはExtensibility、Aggregativity、Modularityという3つの特徴があります。

Futabaはデータ取得のリクエストをするチェーンにのみコントラクトをデプロイすれば利用可能になるので、既存のMessagingやBridgeのようにリクエストを行うチェーンとそれを受け取るチェーンでそれぞれコントラクトをデプロイする必要はありません。

また、オフチェーンのコンポーネントも簡単にデプロイすることができるため、将来的なchain/rollupの増加にも対応することができます。

Futabaは、1つのチェーンから別のチェーンへといった単純な1対1のデータ取得だけでなく、one-to-manyで複数のチェーンから同時にデータを収集することができます。

これはApp-specific chain/rollupの増加によって、それぞれのchain/rollupで管理しているstateに同時にアクセスすることができるようになるので、本来のsingle state machineで可能になっていたコンポーザビリティを維持したまま、スケーラビリティの向上を図ることができます。

また、YearnのようなAggregatorはSingle chainで稼働していますが、Futabaによって複数のチェーンからデータを収集できるので、より強力なAggregatorを構築することを可能にします。

Futabaでは、独自の検証ロジックを構築することができます。これによってL1<>L2やL2同士など、それぞれのエコシステムに適したデータ取得の検証方法を実装することが可能です。

具体的には、Ethereumのデータを他のチェーンで利用するために、Ethereumのコンセンサスを検証するzkライトクライアントを利用した検証や、EthereumのL2間でデータの取得をする際にはsmart contarctとして実装されているSettlement Layerに保存されたステートルートを活用した検証などを可能にします。

セキュリティ面では、Dappsやエコシステムごとに独自のコントラクトやオフチェーンエージェントを持つことができるため、万が一ハッキングなどのインシデントが発生しても、ネットワーク全体が影響を受けることはなく、被害を最小限に抑えることができます。 また、将来的にzkpや優れた暗号が登場した際に、迅速な検証方法として統合することができ、今後急速に変化する暗号学のトレンドにも対応できるようになります。

FutabaにはSrc chainにエンドポイントであるGateway contractと検証を行うLightClient contractがデプロイされており、開発者はそこからqueryのリクエストをします。

そしてFutabaにはRelayerとKonohaという2つのオフチェーンコンポーネントがあり、これらが対象のデータ・検証のためのProofを取得し、Gateway contractに返却しLightClient contractで検証をしたのち、ユーザーに返却します。

RelayerはGateway contractからのイベントを受け取って、それをもとに各チェーンから対象のデータをstorage proofとして取得し、それを再度Gateway contractに返却します。

現在storage proofはGeneral Merkle Proofとして取得していますが、大量のデータをより安価に検証するためにZKPを採用します。

KonohaはDestination chainのブロックヘッダーをSrc chainに供給するためのコンポーネントで、ブロックヘッダを供給する仕組みを持っていれば任意の仕組みに変更できるModularityを備えています。

初期段階ではChainlinkを使用しますが、将来的にはLagrangeのようなstate proofを提供するプロトコルやブロックハッシュアグリゲーターであるHashiの利用も可能になります。

Futabaのユースケースとして考えられるものをいくつか紹介します。

現在のオンチェーンの投票はGovernance tokenがMultichain化している一方で、投票数の計上がSingle chainとなっています。また、投票を行うチェーンがEthereumの場合は投票コストが高いことも問題になっています。

そこで、Futabaを利用したOmni-chain votingが非常に有効です。Futabaを使用して投票者が持っている各チェーンのGovernance tokenの量をaggregateしてきて真の投票力を計上して投票することができます。また、Ethereumの投票力を計上したままL2などのガス代の低いチェーンで投票することもできます。

Safeなどのcontract walletはownerのデータを持つkeystore contractをそれぞれのチェーンに展開する必要があり、それぞれのkeystore contractを更新・同期するコストが非常に高いです。

そこで、Futabaを利用したOmni-chain contract walletを構築することができます。Futabaを利用してkeystore contractの情報を取得することができるので、keystore contract同期させるコストを減らすことができます。

現在Futabaはテストネットでの開発を進めており、まもなくアルファ版としてFutabaの複数の機能を使用できるDemoがローンチされる予定です。また、それに伴ってFutabaが具体的にどのように動いているのか、実際の使い方についての情報も公開していきます。乞うご期待ください。

そして上記で挙げたユースケースなどをより深掘りしたFutabaのユースケースのレポートも今後公開されます。Omni-chainのアプリケーションの設計や構築はまだ黎明期なのでベストプラクティスを探していきましょう。

最後に、Futabaは初期段階での統合・パートナーシップを募集しています。Futabaを利用したOmni-chainのアプリケーションの構築の相談をしたい場合はTwitterのDMから連絡してください。

Futabaに関する最新の情報を得るためにはTwitterをfollowしてください。🌱

This article is in Japanese. Click here for the English version.

最近では、App-specific chain/rollup thesisが広まったことにより、chain/rollup開発のためのSDKやRollup as a Serviceが普及してチェーンやRollupが増加しています。そのため、それぞれのチェーンやRollup、そしてユーザーはこれまで以上のStateの断片化 (not only liquidity) に晒されてれています。これが一般的な相互運用性の問題であり、この問題に取り組むために多くのLiquidity BridgeやMessagingプロトコルが開発されています。

しかし、このようなLiquidity BridgeやMessagingプロトコルが相互運用性の問題を完全に解決しているわけではありません。基本的にこれらのプロトコルは特定のアセットやデータをあるチェーンから他のチェーンに”POST”することに最適化されています。

しかし、実際の通信技術には”POST”だけではなく”GET”の機能が存在し、ブロックチェーンの通信においてもあるチェーンから他のチェーンのデータにアクセスするプロトコルが必要だと考えています。これによって本来Bridgeさせる必要のないデータ (ex. NFT) をBridgeすることによって発生する同期コストを削減することができます。

そこで私たちはよりシームレスなブロックチェーン間の通信を実現させるために、Omni-chainのデータ取得に特化したプロトコルであるFutabaを開発しています。

FutabaにはExtensibility、Aggregativity、Modularityという3つの特徴があります。

Futabaはデータ取得のリクエストをするチェーンにのみコントラクトをデプロイすれば利用可能になるので、既存のMessagingやBridgeのようにリクエストを行うチェーンとそれを受け取るチェーンでそれぞれコントラクトをデプロイする必要はありません。

また、オフチェーンのコンポーネントも簡単にデプロイすることができるため、将来的なchain/rollupの増加にも対応することができます。

Futabaは、1つのチェーンから別のチェーンへといった単純な1対1のデータ取得だけでなく、one-to-manyで複数のチェーンから同時にデータを収集することができます。

これはApp-specific chain/rollupの増加によって、それぞれのchain/rollupで管理しているstateに同時にアクセスすることができるようになるので、本来のsingle state machineで可能になっていたコンポーザビリティを維持したまま、スケーラビリティの向上を図ることができます。

また、YearnのようなAggregatorはSingle chainで稼働していますが、Futabaによって複数のチェーンからデータを収集できるので、より強力なAggregatorを構築することを可能にします。

Futabaでは、独自の検証ロジックを構築することができます。これによってL1<>L2やL2同士など、それぞれのエコシステムに適したデータ取得の検証方法を実装することが可能です。

具体的には、Ethereumのデータを他のチェーンで利用するために、Ethereumのコンセンサスを検証するzkライトクライアントを利用した検証や、EthereumのL2間でデータの取得をする際にはsmart contarctとして実装されているSettlement Layerに保存されたステートルートを活用した検証などを可能にします。

セキュリティ面では、Dappsやエコシステムごとに独自のコントラクトやオフチェーンエージェントを持つことができるため、万が一ハッキングなどのインシデントが発生しても、ネットワーク全体が影響を受けることはなく、被害を最小限に抑えることができます。 また、将来的にzkpや優れた暗号が登場した際に、迅速な検証方法として統合することができ、今後急速に変化する暗号学のトレンドにも対応できるようになります。

FutabaにはSrc chainにエンドポイントであるGateway contractと検証を行うLightClient contractがデプロイされており、開発者はそこからqueryのリクエストをします。

そしてFutabaにはRelayerとKonohaという2つのオフチェーンコンポーネントがあり、これらが対象のデータ・検証のためのProofを取得し、Gateway contractに返却しLightClient contractで検証をしたのち、ユーザーに返却します。

RelayerはGateway contractからのイベントを受け取って、それをもとに各チェーンから対象のデータをstorage proofとして取得し、それを再度Gateway contractに返却します。

現在storage proofはGeneral Merkle Proofとして取得していますが、大量のデータをより安価に検証するためにZKPを採用します。

KonohaはDestination chainのブロックヘッダーをSrc chainに供給するためのコンポーネントで、ブロックヘッダを供給する仕組みを持っていれば任意の仕組みに変更できるModularityを備えています。

初期段階ではChainlinkを使用しますが、将来的にはLagrangeのようなstate proofを提供するプロトコルやブロックハッシュアグリゲーターであるHashiの利用も可能になります。

Futabaのユースケースとして考えられるものをいくつか紹介します。

現在のオンチェーンの投票はGovernance tokenがMultichain化している一方で、投票数の計上がSingle chainとなっています。また、投票を行うチェーンがEthereumの場合は投票コストが高いことも問題になっています。

そこで、Futabaを利用したOmni-chain votingが非常に有効です。Futabaを使用して投票者が持っている各チェーンのGovernance tokenの量をaggregateしてきて真の投票力を計上して投票することができます。また、Ethereumの投票力を計上したままL2などのガス代の低いチェーンで投票することもできます。

Safeなどのcontract walletはownerのデータを持つkeystore contractをそれぞれのチェーンに展開する必要があり、それぞれのkeystore contractを更新・同期するコストが非常に高いです。

そこで、Futabaを利用したOmni-chain contract walletを構築することができます。Futabaを利用してkeystore contractの情報を取得することができるので、keystore contract同期させるコストを減らすことができます。

現在Futabaはテストネットでの開発を進めており、まもなくアルファ版としてFutabaの複数の機能を使用できるDemoがローンチされる予定です。また、それに伴ってFutabaが具体的にどのように動いているのか、実際の使い方についての情報も公開していきます。乞うご期待ください。

そして上記で挙げたユースケースなどをより深掘りしたFutabaのユースケースのレポートも今後公開されます。Omni-chainのアプリケーションの設計や構築はまだ黎明期なのでベストプラクティスを探していきましょう。

最後に、Futabaは初期段階での統合・パートナーシップを募集しています。Futabaを利用したOmni-chainのアプリケーションの構築の相談をしたい場合はTwitterのDMから連絡してください。

Futabaに関する最新の情報を得るためにはTwitterをfollowしてください。🌱