最近では、Cosmos SDK、Avalaunch Subnetのようなブロックチェーンを簡単に構築するためのSDKやCalderaのようなRollup as a Serviceによってチェーンやロールアップの数が増加している。このような状況おいて、トークンのBridgeなどのCross-chainの通信の重要性とそれに対する人々の注目度も高まっていると感じる。
一方で、多くの記事、カンファレンス等でInteroperability、Bridge、MessagingなどのCross-chainの通信に関わる用語がたびたび登場しているが、それらの用語は曖昧に使用されており、様々な人と話す際に誤解を生んでいると感じていた。
また、これらのCross-chainの通信に起きている問題を正確に把握している人やその複雑性を理解している人は少ないと感じており(それ故にLayerZeroで良くないですか？IBCでよくないですか？という意見もよく散見される)、私自身もまだ把握しきれていない問題もあるだろう。
そのため、この記事では
Cross-chainの通信の文脈で使用されている用語の整理
Cross-chainの通信におけるトリレンマ
Cross-chainの複雑化
複雑性の原因を踏まえた上でのCross-chainの将来
について私なりに書いてみようと思う。
すでに冒頭でCross-chainという用語を使用しているが、今回は異なるブロックチェーンあるいはロールアップのことを指す (ロールアップの定義についてはJonに聞いてください…)。そしてこれ以降は、Cross-chainの通信において送信元のチェーンをSrc chain、送信先のチェーンをDestination chainと呼ぶ。
まずInteroperabilityはCross-chainの通信をする能力のことを指し、下記の図のように階層化することができ、それぞれの階層について説明する。
Messaging LayerはいわゆるMessagingやArbitrary Messaging Bridges (AMB)呼ばれるもので、任意のデータ (しばしばMessageやPacketと表現される) を送信することを指す。その中でもチェーン間で安全な接続を確立するレイヤーであるTransport Layerと実際にCross-chainの通信を検証するレイヤーであるVerification Layerに分けることができる。IBCの場合はこのMessaging Layer自体をTransport Layerと表現しているように見えるが、この記事では詳しいことは後述するがあえてTransport LayerとVerification Layerを分けて定義する。
Application Layerは実際にCross-chainの通信において行うアクションについて扱うレイヤーであり、具体的にはFTをチェーンを跨いで送信するToken BridgeとNFTをチェーンを跨いで送信するNFT Bridgeや、Destination chainで特定の関数を実行するInterchain Accountなどに分けられる。IBCにおいてはToken BridgeをICS-20、NFT BridgeをICS-721、Interchain AccountをICS-27として規格化されており、LayerZeroもToken BridgeをOmni-chain FT (OFT)として規格化されている。
そして特にToken Bridgeに関してはもう1つ別の要素があることに注意する必要がある。それはLiquidity Networkである。基本的にToken Bridgeに関してはLiquidityを提供しないでCross-chainでのトークンの送信を実行する手法のことを指し、しばしばLiquidity-lessと呼ばれる。資産をSrc chainのスマートコントラクトに預けてDestination chainで新しくmintするLock-mint方式と、資産をSrc chainでburnしてDestination chainで新しくmintするBurn-mint方式の2つがあり、前者はArbitrum<>Ethereumの$ETHのToken BridgeのようなL1とL2間のNative Tokenの送信に使用されることが多い。後者はまだ数は少なく、Circleが提供するUSDCをBurn-mintでToken Bridgeを行うCCTP (Cross-Chain Transfer Protocol)が代表的なものである。
しかし、Liquidity NetworkはSrc chainとDestination chainに同じ資産 (厳密には異なる資産でも問題ない) を流動性を持ち、それを利用してCross-chainのトークンの送信を行う手法であり、多くの人はこれをBridgeを呼んでいるだろう。
例えばユーザーがSrc chainにUSDCを送信すると、Messagingを介してSrc chainにUSDCが送られたことをDestination chainに伝達して、それを受け取ったDestination chain側はその情報をもとにユーザーにUSDCを送信する。
これはLayerZeroがMessaging Layerであり、StargateがApplication LayerのLiquidity Networkであるということができる。
ここでは基本的なCross-chainの通信の流れを確認する。大まかな流れは以下の通り。
Src chainのEndpoint contractにCross-chainの通信のリクエストを送る
ユーザーがBridgeするための資産を送る
コントラクト上からMessageを送る
Endpoint contractがMessageを含んだイベントを発行し、Off-chainのアクターがそのイベントを受け取り、Destination chainにMessageを送信する ここでいうOff-chainのアクターはMessageを運搬するRelayerと呼ばれるものやMessageの検証をする独自のネットワークなど様々であるが、Relayerはほぼ必須のアクターである
Destination chainでMessageや独自のネットワークの署名の検証を行う
検証に成功した場合、そのMessageあるいはTokenをユーザーに渡す
RelayerはCross-chainの通信を実現するための重要なアクターで、Src chainから受け取ったMessageをDestination chainに送信する役割を持つ。
この中で2のみはOff-chainで行われ、2と3にデザインスペースがある。これはSrc chainから送信されたMessageが正しいかどうかを確かめる必要があるためである。
Cross-chainの複雑性の原因を探るために重要な材料としてInteroperabilityのトリレンマがあり、Genaralization、Trustless、Extensibilityで構成されている。
これは任意のデータを取り扱うことができるかを指し、IBCやLayerZeroのようなMessaging Layerを持つプロトコルの場合は基本的に満たされおり、Token Bridgeのみを行っているプロトコルはこの条件を満たしていない。今回の記事ではToken Bridgeについては詳細に記述しないので、そこまで気にする必要がない。
追加の信頼の前提 (Additional Trust Assumption) が最小化されているかどうかを指す (そのためTrust-minimizedと呼ぶこともある)。
基本的にInteroperabilityを実現するには信頼できる第三者が必要であり、これを追加の信頼の前提 (Additional Trust Assumption)と呼ばれることが多い。信頼できる第三者 (Trusted third-party) の場合、CEXのような中央集権的な機関などを想起しやすいが、この記事ではCEXのような信頼というよりChainlinkのような独自ネットワークなどを信頼としたいので、Trusted third-partyではなく、Additional Trust Assumptionという用語を使用する。
これを踏まえた上でTrustlessの理想的な状態は、通信しているチェーン以外のセキュリティに依存しないことを指す。上記のCross-chainの通信のライフサイクルで述べたRelayerは単にMessageを送信しているのみであるためAdditional Trust Assumptionには該当しない。基本的にMessageを検証するためのアクターがAdditional Trust Assumptionに該当することが多い。
また、Trustlessを考える上で重要な概念がある。それはClusterとClient diversityである。
Clusterとは、セキュリティを共有し、信頼最小化された方法で互いに通信できるドメインの集合である。特定のエコシステム内 (Intra-cluster) ではTrustlessなInteroperabilityを提供できるが、エコシステム間のInteroperabilityを実現する際にはAdditional Trust Assumptionを必要とする。
例えばTendermintを利用している場合のIBCや、PolkadotのXCM、Avalanche Subnet間の通信のためのAvalanche Warp Messaging (AWM) などである。
これは、コンセンサスアルゴリズムやstate commitmentの仕組みの数だけチェーンやロールアップの多様性があることを指す。その中でTrustlessを目指すにはその多様性に合わせたInteroperabilityを提供することが必要となる。[1]
これはあらゆるチェーンやロールアップに対応することができるのかを指す。この定義では**「あらゆる」**と定義しているので、Intra-cluster内ではIBCやXCMは非常に対応しやすいが、エコシステムを超えると難しくなる。
特にMessaging LayerにおいてはTrustlessとExtensibilityがトレードオフになっており、Trustlessを維持しつつ、Extensibilityを実現することがInteroperabilityの1つのゴールだと言える。
ここまでCross-chainに関する用語の解説とInteroperabilityのトリレンマについて説明しました。ここでは過去のInteroperabilityに触れつつ、今日のInteroperabilityがより複雑化している原因について考える。
今回は2021年以前を指すことにする。それは2022・2023年あたりに大きな変化があったと感じたこと、そして私自身が2022年からブロックチェーンを勉強し始めて、2021年以前の解像度が高くない可能性があるためである。
以前はエコシステム内のInteroperabilityはCosmosやPolkadot、あるいはEthereumとL2の間等に限られており、ほとんどがエコシステムを跨ぐL1とL1のInteroperabilityになっていた。そのため、Additional Trust Assumptionを必要とする中間ネットワークによってInteroperabilityを実現していたケースが多いと感じている。そしてこれらの中間チェーンは独自のApplication LayerとMessaging Layerを持ったMonolithicなネットワークであった。
L1とL1の通信においてもブロックヘッダへの署名を検証できればIBCのようなLight Clientの検証を行うことができたが、実際にはオンチェーンの検証に非常に大きなコストがかかるため高頻度で通信することができなかった (ex. Near<>Ethereum)。そのため、TrustlessというよりExtensibilityに重きが置かれていたイメージがある。
そして今日、特に2022年から2023年にかけてInteroperabilityの問題が複雑になっていったのは大きく3つの要因があったと推測される。
Off-chain computationの発展
InteroperabilityのModular化
RollupとChainが増加とModular化
ブロックチェーンの領域でZKPやTEEのようなOff-chain computation (Verifiable computation) が使用されるようになり、ブロックヘッダの署名などの検証コストを下げることができようになった。これによってLight Client検証の実用性を高めることができ、Extensibilityを維持したままTrustlessを目指す取り組みが進んだ。つまり、Verification LayerがMultisigやPoSのような独自のネットワークからより暗号学的なアプローチが採用され実装の複雑性が増加した。
ex. Composable FinanceやElectron LabのzkIBC、DatachainのLCP (TEEの使用)
特に2023年においてはModular Blockchainの煽りを受けてInteroperability自体もModular的なアプローチが言及されることが増加した。先ほどの用語の整理でも言及したが、大きく分けるとApplication Layer、Transport Layer、Verification Layerで階層化され、それぞれのLayerのアプローチが多様化していった。
Application Layer
特にToken Bridgeでは、Burn-mint、Lock-mint、Liquidity Networkというように手法が多様化している。Liquidity NetworkではInteroperabilityのトリレンマとは異なるトリレンマ [2]を持っているためさらに問題が複雑になっている。そして既存のTokenをより様々なチェーンで利用するために、xERC20やOFTにする取り組みが行われているが、それぞれが独自の規格を持っている状態であり、規格の競争が行われている。[3]
Transport Layer
IBCやLayerZeroなど、プロトコルごとにチェーンの接続方法やMessageの形式が異なるので、統一されていない。そのため、それぞれでDestination chainの指定方法、Messageの送信方法、acknowledgementの有無などの仕様が異なり、開発者にとっては非常に混乱する事態になっている。
PolymerはIBC (特にTransport Layer) をL2に拡張するプロジェクトを行なっており、Transport Layerの統一に大きく資する可能性がある。
Verification Layer
エコシステムごと (Intra-cluster) Trustlessな検証方法は異なるにも関わらず、現在のModular Blockchainはチェーンやロールアップごとに使用しているモジュールが異なるため、複雑にClusterが絡み合っている。具体的にどのように複雑になっているかは次のセクションで説明する。
このようにそれぞれのLayerで問題は山積みの状態であり、それらをまとめて1つのネットワークなどで解決するのは非常に困難な状況になっているため、それぞれのLayerで個別に解決する必要がある。しかし、それによってより問題が複雑になっている。
上記でも少し触れたが、現在ではModular BlockchainとApp-specific chain/rollupの流れが加速している。これによってRollupとChainが増加を引き起こすだけでなく、特にRollupにおいては、Execution、Settlement、Data Availabilityを個々のRollupが自由に決めることができるので、より複雑なClusterを形成している。
この複雑なClusterの形成はIBCにおけるTendermintのような汎用的なTrustlessな通信方法を提供することが難しくなる。
例えば、以下の3つのRollupがあるとする。
Rollup A: SettlementとDAがEthereum
Rollup B: SettlementがEthereumでDAがCelestia (Celestiaのblob streamを使用)
Rollup C: SettlementはRollupに帰属し、DAがCelestia (Sovereign Rollup)
AとBは同じSettlementを共有しているので、Settlementにポストされたstate rootなどを活用すればTrustlessな通信を行うことができる。また、BとCはDAがどちらもCelestiaであるためCelestiaのLight Nodeを利用すればTrustlessな通信を行うことができる。 (Settlement LayerにProofを提出する前でRollupのFinalityしか確保していないので、厳密にはRollupのFinalityをTrustlessに確保できるという方が正しい)
しかし、AとCの場合は共有している部分が存在しないので、Third-partyを利用する必要がある。
ここでは深く言及しないが、AとCにおいてShared SequencerでSequencing Layerを共有していれば、Shared Sequencerのネットワーク自体のTrustはあるものの、Trustを小さくした形で通信することができる。
このように現在では各Rollupが同じエコシステムに存在しているわけではなく、それぞれのレイヤーで部分的に被っている場合や全く被っていない場合もあるので、最適な検証方法の提供が非常に難しくなっており、複雑性が増している。
ZKPやTEEなどの高度なOff-chain computationの登場、Interoperability自体のModular (階層化)、そしてRollupとChainの増加とそれらのModular化によってInteroperabilityの各レイヤー、特にVerification Layerの最適化が非常に難しくなり、複雑となっている。
ここまでInteroperabilityのトリレンマやInteroperabilityの複雑化のような問題的な部分について書いてきたが、ここではそのような状況を踏まえてInteroperabilityがどのような未来に進んでいくのかについて自分なりの考えを述べる。
FTにおいてはLiquidity BridgeからLiquidity-lessへ向かうだろう。既にCosmosのエコシステムではICS-20のおかげでLiquidity-lessになっているが、EVM系ではまだLiquidity Bridgeが主流になっているので、今後はLiquidity-lessの勢いが増すだろう。
その理由は2つあり、1つはCCTPの登場によってburn-mintのUSDC Bridgeが少しずつ普及していること、もう1つはxERC20やLayerZeroのOFTのようなburn-mint型でBridgeできるERC-20を拡張した規格の採用が少しづつ見られることである。これらの規格それ自体が増えていき、規格の統一ができていないことは別途問題であるが、少なくとも今後複数のチェーンで展開したトークンに関しては上記の規格を使用するものが増えていくだろう。
Transport Layerは他のMessagingのプロトコルが出てくる限り多様化してしまうので、しばらくは統一化されるとは思わない。個人的にはIBCのTransport Layerは洗練されているとは思うが、EVMのチェーンやRollupに同じような形で採用さえもされていないのは、2つ理由があると考えられる。
1つはIBCがEVMのチェーンやRollupにほとんど適用されておらず実際にCosmosエコシステムの場合と同じように動くかどうか分らないこと、もう1つは今のCross-chainはほとんどがToken BridgeであまりTransportの強みが生かされないことである。
前者についてはLCPやPolymerが実現しようとしているはずなので、今後に期待したい。後者に関しては、App-specific chain/rollupが加速し、それらが相互作用をするレベルまで進まなければ実際にPacket forward middlewareのようなTransport Layerの強みが発揮されないのではないかと考えている。
Verification Layerではそれぞれのエコシステムごとに適切な検証方法を提供するModular interoperabilityがより盛んになりだろう。既にHyperlaneやLayerZero、Axelar VMはこのようなコンセプトを持っているが、今年はこの傾向がより加速すると考えている。これによって、Messageを送信するエンドポイントは同じままで、検証方法を自由に選択することができ、それぞれのRollupの間の通信を最適化させることができる。
そして、検証方法についてはAxiomやLagrange、HerodotusなどのZK Coprocessorがより注目されるだろう。これらは高価な計算をオフロードするプロトコルであるが、これらをModular interoperabilityの検証に使用する (実際にはConsensusの検証やSTFの検証など様々である) ことによってよりセキュアな通信を実現することができる。
一方でProofの生成時間が長いことや検証のコストがまだ少し大きいことを踏まえてZK Coprocessorをメインの検証方法として採用するのではなく、サブとして採用するケースも増えてきている。例えばBrevisのcoChainはPoSで一度計算結果を返却した後、一定期間のChallenge windowを設けて、その間にPoSに対するFraud ProofをZKPとして提出することができる。このような手法はLayer Nなどでも用いられており、しばらくはこの手法を採用するプロジェクトが多いと推測する。
そして、ここではあまり触れていないが、RollupにおいてはShared SequencerやShared ProverなどのアクターもCross-chainに関わっており、非常に多くのCross-chainのソリューションが登場している。これらの手法も踏まえつつTrustlessな通信を実現する必要がある。
Application Layerの上にIntent Layerが登場し、ユーザーがトランザクションを実行することなくToken Bridgeを実行することを可能にする。これによってユーザーのガス代の負担を軽減され、さらに署名によってToken Bridgeを実現するのでチェーンを意識しなくなる (Chain Abstraction [4])。
このレイヤーにはAnomaやSUAVEが該当し、1つのチェーンに縛られないShared mempoolとして機能するだろう。
HyperlaneではPermissionless deploymentという機能が実装されており、Hyperlaneではなく、アプリケーションやチェーン側でMessagingやその上にあるToken Bridgeを実装することができる。EVM系ではこのような仕組みはなかったので新規のRollupなどには非常に役立つだろう。
しかし、Hyperlaneの場合、デフォルトのセキュリティがそれぞれのネットワークで孤立したPoSであるため、Additional Trust Assumptionが大きいことが問題である。
今回はInteroperability、BridgeやMessagingなどのCross-chainに関わる用語の解説からInteroperabilityのトリレンマやそれを解決することの複雑性が増している原因について探究し、それを踏まえた上でどのような未来が来るかついて述べた。
特にModular BlockchainとApp-specific chain/rollupの影響によってChainやRollupが増加して、エコシステムが複雑に絡み合った結果、Trustlessな検証方法自体も多様化してしまったことが複雑性の大きな要因だと考えられる。それため、1つのプロトコルで横断的に解決することは難しい。
その中で私が最も重要だと思うのはPolygon CDKやOP Stack、Arbitrum Orbitのようなエコシステム内のRollup通信ではなく、Polygon CDKのRollupとOP StackのRollupの間の通信であると考える。これらの通信には設計の余地がかなり残されている印象があり、私自身も何か提案できたらなと思う。
最後ではありますが、現在私はFutabaというCross-chainのデータ取得のためのインフラを開発しています。こちらにドキュメントとコンタクトを掲載しておくので、興味がある人はご連絡ください。
また、現在Futabaを利用したToken Bridgeを構想しているので、そちらに興味がある人もご連絡をいただけると嬉しいです。
Introduction | Futaba
Futaba is a modular omnichain interface enabling communication between contracts, rollups and blockchain networks by querying and pulling data from a single source chain.
[1] https://www.youtube.com/watch?v=o3BYfEMbUzM
[2] https://www.dropbox.com/s/gf3606jedromp61/Delta-Solving.The.Bridging-Trilemma.pdf?dl=0
[3] wstETHを他のチェーンに展開する上で各Messagingプロトコルで争いになったhttps://research.lido.fi/t/wormhole-x-axelar-lido-bridge-implementation-for-wsteth-on-bnb-chain/6012/1
[4] https://medium.com/connext/introducing-chain-abstraction-9b8f6e4dc31a
