Introduction to the Blockchain Interoperability Challenge
The recent spread of the App-specific chain/rollup thesis has led to a surge in chains and rollups, owing to the increasing popularity of SDKs for chain/rollup development and Rollup as a Service.
This growth has exposed each chain, rollup, and their users to unprecedented fragmentation of state (not just liquidity). Addressing this interoperability issue, various Liquidity Bridges and Messaging protocols have been developed, yet they don't fully resolve the problem.
Futaba: A New Solution to Blockchain Fragmentation
These protocols are primarily optimized for "POSTing" specific assets or data from one chain to another. However, just as communication technology involves not only "POST" but also "GET" functions, blockchain communication requires protocols that access data from other chains without necessitating data bridging. This approach can reduce synchronization costs for data (e.g., NFTs) that don't inherently need bridging.
To achieve seamless omni-chain communication, a protocol called Futaba has been developed, focusing on omni-chain data retrieval.
Core Features of Futaba Protocol
Futaba possesses three key features: Extensibility, Aggregativity, and Modularity.
Extensibility: Futaba requires deploying contracts only on the chain making the data request, unlike existing Messaging or Bridge systems that need contracts on both the requesting and receiving chains. It also allows easy deployment of off-chain components, accommodating the future increase in chains/rollups.
Aggregativity: Beyond simple one-to-one data retrieval from one chain to another, Futaba enables one-to-many data collection from multiple chains simultaneously. This functionality maintains composability, similar to a single state machine, while enhancing scalability.
Modularity*:* Futaba allows the creation of custom validation logic, fitting various ecosystems like L1<>L2 or between L2s, through methods like using zk light clients for Ethereum consensus validation or utilizing state roots stored in a smart contract-based Settlement Layer.
Understanding Futaba's Innovative Architecture
Futaba's architecture includes a Gateway contract and a LightClient contract deployed on the source chain (Src chain), where developers make query requests. Two off-chain components, Relayer and Konoha, retrieve the target data and proofs for verification, returning them to the Gateway contract for validation by the LightClient contract before reaching the user.
Relayer receives events from the Gateway contract, retrieves the target data as storage proof from each chain, and returns it to the Gateway contract. While currently using General Merkle Proof, it plans to adopt ZKP for more cost-effective verification of large data volumes.
Konoha supplies destination chain block headers to the source chain, featuring modularity that allows for various supply mechanisms. Initially using Chainlink, Futaba may later integrate protocols like Lagrange for state proofs or Hashi for block hash aggregation.
Unique Use Cases of Futaba in Blockchain Ecosystems
Futaba presents various use cases, including omni-chain voting and omni-chain contract wallets. It enables aggregation of Governance token quantities across chains for accurate voting power calculation and simplifies contract wallet management by reducing the need to update and synchronize keystore contracts across chains.
Futaba's Development and Future Prospects
Futaba is currently under development on a testnet, with an alpha version and a demo showcasing its features expected to launch soon. Further reports on detailed use cases and best practices for designing and building omni-chain applications using Futaba are also anticipated.
Joining Forces with Futaba: Collaboration and Integration Opportunities
Lastly, Futaba is seeking integration partnerships and collaborations. Those interested in consulting about building omni-chain applications with Futaba can reach out via Twitter DM. For the latest updates on Futaba, following their Twitter account is recommended.
