# [JP] Why is Cross-chain so complicated? By [Futaba](https://paragraph.com/@futaba) · 2024-02-07 --- Motivation ========== 最近では、Cosmos SDK、Avalaunch Subnetのようなブロックチェーンを簡単に構築するためのSDKやCalderaのようなRollup as a Serviceによってチェーンやロールアップの数が増加している。このような状況おいて、トークンのBridgeなどのCross-chainの通信の重要性とそれに対する人々の注目度も高まっていると感じる。 一方で、多くの記事、カンファレンス等で**Interoperability**、**Bridge**、**Messaging**などのCross-chainの通信に関わる用語がたびたび登場しているが、それらの用語は曖昧に使用されており、様々な人と話す際に誤解を生んでいると感じていた。 また、これらのCross-chainの通信に起きている問題を正確に把握している人やその複雑性を理解している人は少ないと感じており(それ故にLayerZeroで良くないですか？IBCでよくないですか？という意見もよく散見される)、私自身もまだ把握しきれていない問題もあるだろう。 [![User Avatar](https://storage.googleapis.com/papyrus_images/b7f4bbfcc5ad22c7d33cf797286eefc7ae69a9dc01ce45591ef511244ce35bc1.jpg)](https://twitter.com/grandchildrice) [gohan 🍚⛩️](https://twitter.com/grandchildrice) [@grandchildrice](https://twitter.com/grandchildrice) [![Twitter Logo](https://paragraph.com/editor/twitter/logo.png)](https://twitter.com/grandchildrice/status/1753718735574376871) BridgeやOracleは、なぜそんなに複雑なのかよく分からないので、複雑化していく歴史背景を説明する図とかあったらいいなー[@adachi\_tomoki3](https://twitter.com/adachi_tomoki3) [![Like Icon](https://paragraph.com/editor/twitter/heart.png) 8](https://twitter.com/grandchildrice/status/1753718735574376871)[ 3:55 AM • Feb 3, 2024 ](https://twitter.com/grandchildrice/status/1753718735574376871) そのため、この記事では 1. Cross-chainの通信の文脈で使用されている用語の整理 2. Cross-chainの通信におけるトリレンマ 3. Cross-chainの複雑化 4. 複雑性の原因を踏まえた上でのCross-chainの将来 について私なりに書いてみようと思う。 用語の整理 ===== すでに冒頭で**Cross-chain**という用語を使用しているが、今回は異なるブロックチェーンあるいはロールアップのことを指す (ロールアップの定義については[Jon](https://twitter.com/jon_charb)に聞いてください…)。そしてこれ以降は、Cross-chainの通信において送信元のチェーンを**Src chain**、送信先のチェーンを**Destination chain**と呼ぶ。 まずInteroperabilityは**Cross-chainの通信をする能力**のことを指し、下記の図のように階層化することができ、それぞれの階層について説明する。 ![Hierarchy of Interoperability](https://storage.googleapis.com/papyrus_images/74111d64c94913426331f8bd35f0c9cf46fbba5569d284b636b9507558d26798.png) Hierarchy of Interoperability ### Messaging Layer **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 **Application Layer**は実際にCross-chainの通信において行うアクションについて扱うレイヤーであり、具体的にはFTをチェーンを跨いで送信する**Token Bridge**とNFTをチェーンを跨いで送信する**NFT Bridge**や、Destination chainで特定の関数を実行する**Interchain Account**などに分けられる。IBCにおいてはToken Bridgeを[ICS-20](https://github.com/cosmos/ibc/blob/main/spec/app/ics-020-fungible-token-transfer/README.md)、NFT Bridgeを[ICS-721](https://github.com/cosmos/ibc/tree/main/spec/app/ics-721-nft-transfer)、Interchain Accountを[ICS-27](https://github.com/cosmos/ibc/tree/main/spec/app/ics-027-interchain-accounts)として規格化されており、LayerZeroもToken Bridgeを[Omni-chain FT (OFT)](https://docs.layerzero.network/contracts/sending-tokens)として規格化されている。 そして特に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)](https://developers.circle.com/stablecoin/docs)が代表的なものである。 ![Burn-mint bridge](https://storage.googleapis.com/papyrus_images/689bb5637c9197acf95ce0125fd6812b601f5328ff930a0abb5c51e5a568323c.png) Burn-mint bridge しかし、Liquidity NetworkはSrc chainとDestination chainに同じ資産 (厳密には異なる資産でも問題ない) を流動性を持ち、それを利用してCross-chainのトークンの送信を行う手法であり、多くの人はこれをBridgeを呼んでいるだろう。 ![Liquidity network bridge](https://storage.googleapis.com/papyrus_images/00e564e11f0802722f33c6fc6afacf81e44586a62f08e32916222c928caaf25e.png) Liquidity network bridge 例えばユーザーがSrc chainにUSDCを送信すると、Messagingを介してSrc chainにUSDCが送られたことをDestination chainに伝達して、それを受け取ったDestination chain側はその情報をもとにユーザーにUSDCを送信する。 これはLayerZeroがMessaging Layerであり、StargateがApplication LayerのLiquidity Networkであるということができる。 Cross-chainの通信のライフサイクル ====================== ここでは基本的なCross-chainの通信の流れを確認する。大まかな流れは以下の通り。 1. Src chainのEndpoint contractにCross-chainの通信のリクエストを送る 1. ユーザーがBridgeするための資産を送る 2. コントラクト上からMessageを送る 2. Endpoint contractがMessageを含んだイベントを発行し、Off-chainのアクターがそのイベントを受け取り、Destination chainにMessageを送信する ここでいうOff-chainのアクターはMessageを運搬するRelayerと呼ばれるものやMessageの検証をする独自のネットワークなど様々であるが、Relayerはほぼ必須のアクターである 3. Destination chainでMessageや独自のネットワークの署名の検証を行う 4. 検証に成功した場合、そのMessageあるいはTokenをユーザーに渡す RelayerはCross-chainの通信を実現するための重要なアクターで、Src chainから受け取ったMessageをDestination chainに送信する役割を持つ。 この中で2のみはOff-chainで行われ、2と3にデザインスペースがある。これはSrc chainから送信されたMessageが正しいかどうかを確かめる必要があるためである。 ![Lifecycle of cross-chain communication](https://storage.googleapis.com/papyrus_images/7303cc1c1677c845c834d6772bee54312eb0a1f483a6c753428d3ca5ac0a9119.png) Lifecycle of cross-chain communication Interoperabilityのトリレンマ ====================== Cross-chainの複雑性の原因を探るために重要な材料としてInteroperabilityのトリレンマがあり、**Genaralization**、**Trustless**、**Extensibility**で構成されている。 ![https://medium.com/connext/the-interoperability-trilemma-657c2cf69f17](https://storage.googleapis.com/papyrus_images/5b05a9247e51ad7e8a4683f7a96999509553652c2f0aa022305bad9c8537cbcf.png) https://medium.com/connext/the-interoperability-trilemma-657c2cf69f17 ### **Generalization** これは任意のデータを取り扱うことができるかを指し、IBCやLayerZeroのようなMessaging Layerを持つプロトコルの場合は基本的に満たされおり、Token Bridgeのみを行っているプロトコルはこの条件を満たしていない。今回の記事ではToken Bridgeについては詳細に記述しないので、そこまで気にする必要がない。 ### **Trustless** 追加の信頼の前提 (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** ![https://blog.celestia.org/clusters/](https://storage.googleapis.com/papyrus_images/b704190cc845ce93100fce38f74001f575de8ced592b83245a5a81b2cc88f230.png) https://blog.celestia.org/clusters/ Clusterとは、セキュリティを共有し、信頼最小化された方法で互いに通信できるドメインの集合である。特定のエコシステム内 (Intra-cluster) ではTrustlessなInteroperabilityを提供できるが、エコシステム間のInteroperabilityを実現する際にはAdditional Trust Assumptionを必要とする。 例えばTendermintを利用している場合のIBCや、[PolkadotのXCM](https://wiki.polkadot.network/docs/learn-xcm)、Avalanche Subnet間の通信のための[Avalanche Warp Messaging (AWM)](https://docs.avax.network/build/cross-chain/awm/overview) などである。 #### **Client diversity** ![https://www.youtube.com/watch?v=o3BYfEMbUzM](https://storage.googleapis.com/papyrus_images/fded82b786a93ebf56e36010aebe3165f726bd02cc95a223ddf5a08796251c88.png) https://www.youtube.com/watch?v=o3BYfEMbUzM これは、コンセンサスアルゴリズムやstate commitmentの仕組みの数だけチェーンやロールアップの多様性があることを指す。その中でTrustlessを目指すにはその多様性に合わせたInteroperabilityを提供することが必要となる。\[1\] ### Extensibility これはあらゆるチェーンやロールアップに対応することができるのかを指す。この定義では\*\*「あらゆる」\*\*と定義しているので、Intra-cluster内ではIBCやXCMは非常に対応しやすいが、エコシステムを超えると難しくなる。 特にMessaging LayerにおいてはTrustlessとExtensibilityがトレードオフになっており、**Trustlessを維持しつつ、Extensibilityを実現すること**がInteroperabilityの1つのゴールだと言える。 Interoperabilityの複雑化 ==================== ここまでCross-chainに関する用語の解説とInteroperabilityのトリレンマについて説明しました。ここでは過去の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に重きが置かれていたイメージがある。 ### 今日のInteroperability そして今日、特に2022年から2023年にかけてInteroperabilityの問題が複雑になっていったのは大きく3つの要因があったと推測される。 1. Off-chain computationの発展 2. InteroperabilityのModular化 3. RollupとChainが増加とModular化 #### Off-chain computationの発展 ブロックチェーンの領域でZKPやTEEのようなOff-chain computation (Verifiable computation) が使用されるようになり、ブロックヘッダの署名などの検証コストを下げることができようになった。これによってLight Client検証の実用性を高めることができ、Extensibilityを維持したままTrustlessを目指す取り組みが進んだ。つまり、Verification LayerがMultisigやPoSのような独自のネットワークからより暗号学的なアプローチが採用され実装の複雑性が増加した。 ex. [Composable Finance](https://app.trustless.zone/ethereum/?from=CENTAURI&to=ETHEREUM)や[Electron Lab](https://mainnet.electronlabs.org/bridge)の[zkIBC](https://ethresear.ch/t/bringing-ibc-to-ethereum-using-zk-snarks/13634)、Datachainの[LCP](https://medium.com/lcp-network/lcp-a-proxy-for-light-client-verification-to-realize-trust-minimized-and-gas-efficient-f7d5868e4b0) (TEEの使用) #### InteroperabilityのModular化 特に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\]](https://www.notion.so/Why-is-Cross-chain-so-complicated-40815f1004914d1da5b2022a6be20b37?pvs=21)を持っているためさらに問題が複雑になっている。そして既存のTokenをより様々なチェーンで利用するために、xERC20やOFTにする取り組みが行われているが、それぞれが独自の規格を持っている状態であり、規格の競争が行われている。\[3\] **Transport Layer** IBCやLayerZeroなど、プロトコルごとにチェーンの接続方法やMessageの形式が異なるので、統一されていない。そのため、それぞれでDestination chainの指定方法、Messageの送信方法、acknowledgementの有無などの仕様が異なり、開発者にとっては非常に混乱する事態になっている。 [Polymer](https://docs.polymerlabs.org/)はIBC (特にTransport Layer) をL2に拡張するプロジェクトを行なっており、Transport Layerの統一に大きく資する可能性がある。 **Verification Layer** エコシステムごと (Intra-cluster) Trustlessな検証方法は異なるにも関わらず、現在のModular Blockchainはチェーンやロールアップごとに使用しているモジュールが異なるため、複雑にClusterが絡み合っている。具体的にどのように複雑になっているかは次のセクションで説明する。 このようにそれぞれのLayerで問題は山積みの状態であり、それらをまとめて1つのネットワークなどで解決するのは非常に困難な状況になっているため、それぞれのLayerで個別に解決する必要がある。しかし、それによってより問題が複雑になっている。 ### RollupとChainが増加とModular化 上記でも少し触れたが、現在ではModular BlockchainとApp-specific chain/rollupの流れが加速している。これによってRollupとChainが増加を引き起こすだけでなく、特にRollupにおいては、Execution、Settlement、Data Availabilityを個々のRollupが自由に決めることができるので、より複雑なClusterを形成している。 ![](https://storage.googleapis.com/papyrus_images/3feed1732475e24ed9141adf2b5c2308e8889c62a3b1f415d17117c3dc791eab.png) この複雑なClusterの形成はIBCにおけるTendermintのような汎用的なTrustlessな通信方法を提供することが難しくなる。 例えば、以下の3つのRollupがあるとする。 Rollup A: SettlementとDAがEthereum Rollup B: SettlementがEthereumでDAがCelestia ([Celestia](https://celestia.org/)の[blob stream](https://blog.celestia.org/introducing-blobstream/)を使用) Rollup C: SettlementはRollupに帰属し、DAがCelestia ([Sovereign Rollup](https://celestia.org/learn/sovereign-rollups/an-introduction/)) 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](https://maven11.substack.com/p/the-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の複雑化のような問題的な部分について書いてきたが、ここではそのような状況を踏まえてInteroperabilityがどのような未来に進んでいくのかについて自分なりの考えを述べる。 ### Application Layer FTにおいてはLiquidity BridgeからLiquidity-lessへ向かうだろう。既にCosmosのエコシステムではICS-20のおかげでLiquidity-lessになっているが、EVM系ではまだLiquidity Bridgeが主流になっているので、今後はLiquidity-lessの勢いが増すだろう。 その理由は2つあり、1つはCCTPの登場によってburn-mintのUSDC Bridgeが少しずつ普及していること、もう1つは[xERC20](https://www.xerc20.com/)やLayerZeroのOFTのようなburn-mint型でBridgeできるERC-20を拡張した規格の採用が少しづつ見られることである。これらの規格それ自体が増えていき、規格の統一ができていないことは別途問題であるが、少なくとも今後複数のチェーンで展開したトークンに関しては上記の規格を使用するものが増えていくだろう。 ### Transport Layer 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](https://github.com/cosmos/ibc-apps/tree/main/middleware/packet-forward-middleware)のようなTransport Layerの強みが発揮されないのではないかと考えている。 ### Verification Layer Verification Layerではそれぞれのエコシステムごとに適切な検証方法を提供するModular interoperabilityがより盛んになりだろう。既に[Hyperlane](https://www.hyperlane.xyz/)やLayerZero、[Axelar VM](https://axelar.network/blog/axelar-virtual-machine-future-of-interoperability)はこのようなコンセプトを持っているが、今年はこの傾向がより加速すると考えている。これによって、Messageを送信するエンドポイントは同じままで、検証方法を自由に選択することができ、それぞれのRollupの間の通信を最適化させることができる。 そして、検証方法については[Axiom](https://docs.axiom.xyz/docs/introduction/why-axiom)や[Lagrange](https://lagrange-labs.gitbook.io/lagrange-labs/overview/what-is-the-lagrange-protocol)、[Herodotus](https://docs.herodotus.dev/herodotus-docs/)などの**ZK Coprocessor**がより注目されるだろう。これらは高価な計算をオフロードするプロトコルであるが、これらをModular interoperabilityの検証に使用する (実際にはConsensusの検証やSTFの検証など様々である) ことによってよりセキュアな通信を実現することができる。 一方でProofの生成時間が長いことや検証のコストがまだ少し大きいことを踏まえてZK Coprocessorをメインの検証方法として採用するのではなく、サブとして採用するケースも増えてきている。例えば[BrevisのcoChain](https://blog.brevis.network/2024/01/18/introducing-brevis-cochain-the-fusion-of-crypto-economics-and-zk-proof-in-a-zk-coprocessor/)はPoSで一度計算結果を返却した後、一定期間のChallenge windowを設けて、その間にPoSに対するFraud ProofをZKPとして提出することができる。このような手法は[Layer N](https://docs.layern.com/security/fraudProof)などでも用いられており、しばらくはこの手法を採用するプロジェクトが多いと推測する。 そして、ここではあまり触れていないが、RollupにおいてはShared Sequencerや[Shared Prover](https://starkware.co/resource/joining-forces-sharp/)などのアクターもCross-chainに関わっており、非常に多くのCross-chainのソリューションが登場している。これらの手法も踏まえつつTrustlessな通信を実現する必要がある。 ![](https://storage.googleapis.com/papyrus_images/e185edc03e1162b05cb88d117a4b0bbb5d62613152036caba185dad6ac09fa17.png) ### その他 #### Intent Layer Application Layerの上にIntent Layerが登場し、ユーザーがトランザクションを実行することなくToken Bridgeを実行することを可能にする。これによってユーザーのガス代の負担を軽減され、さらに署名によってToken Bridgeを実現するのでチェーンを意識しなくなる (Chain Abstraction \[4\])。 このレイヤーには[Anoma](https://anoma.net/blog/chimera-chains)や[SUAVE](https://writings.flashbots.net/the-future-of-mev-is-suave)が該当し、1つのチェーンに縛られないShared mempoolとして機能するだろう。 #### Permissionless deployment Hyperlaneでは[Permissionless deployment](https://medium.com/hyperlane/permissionless-interoperability-3ae02fc162de)という機能が実装されており、Hyperlaneではなく、アプリケーションやチェーン側でMessagingやその上にあるToken Bridgeを実装することができる。EVM系ではこのような仕組みはなかったので新規のRollupなどには非常に役立つだろう。 しかし、Hyperlaneの場合、デフォルトのセキュリティがそれぞれのネットワークで孤立したPoSであるため、Additional Trust Assumptionが大きいことが問題である。 Conclusion ========== 今回は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. https://futaba.gitbook.io ![](https://storage.googleapis.com/papyrus_images/1fc8d6b498042e0571e286850442d06fb5f80abc3b18e6dc6efd85cb54531280.avif) ](https://futaba.gitbook.io/docs/introduction/futaba-introduction) [ Futaba Early Builders --------------------- Turn data collection into an experience with Typeform. Create beautiful online forms, surveys, quizzes, and so much more. Try it for FREE. https://typeform.com ![](https://storage.googleapis.com/papyrus_images/448388aee6997944270a8238398c0569d50e4dfb2757473a34ce6e955a9f3916.png) ](https://b6xxe4i0amr.typeform.com/to/w4wGLvbs) References ========== \[1\] [https://www.youtube.com/watch?v=o3BYfEMbUzM](https://www.youtube.com/watch?v=o3BYfEMbUzM) \[2\] [https://www.dropbox.com/s/gf3606jedromp61/Delta-Solving.The.Bridging-Trilemma.pdf?dl=0](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](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](https://medium.com/connext/introducing-chain-abstraction-9b8f6e4dc31a) --- *Originally published on [Futaba](https://paragraph.com/@futaba/jp-why-is-cross-chain-so-complicated)*