Researchers: Miguel Matos & team at INESC-ID
Summary
Lack of trust-minimized interoperability between blockchain ecosystems remains a limiting factor on the utility and growth of DeFi. Our concept of a guest blockchain is a fundamental stepping stone towards straddling the cross-blockchain interoperability chasm. By bringing previously siloed blockchains to the broader IBC, our guest blockchain system dissolves existing communication barriers across blockchains and opens up new opportunities and use for all the involved stakeholders.
This initiative will thus contribute the following:
- A mechanism for making previously incompatible networks IBC-capable
Resulting benefits and use cases include increased liquidity between and within ecosystems, new assets accessible in new ecosystems, cross-chain DeFi opportunities like lending/borrowing and liquid staking, and a streamlined user experience. This furthers the vision of fully decentralized, trustless, and efficient blockchain interoperability. Moreover, this improves the user experience by abstracting the complexity and inaccessibility of cross-chain operations, pushing blockchain towards mass adoption.
Background & Problem Statement
Background
Core background concepts/definitions are as follows:
Trustless Cross-Domain Interoperability & the IBC Protocol:
The Inter-Blockchain Communication (IBC) Protocol represents a great opportunity for advancing cross-chain interoperability. Not only is the IBC protocol cost- and time-efficient compared to many other bridges, but also it is trustless. Most popular bridges like Wormhole are trusted, meaning users must put their faith into a third party to uphold the security of the bridge and facilitate asset transfers. In contrast, IBC is trustless, as it uses cryptographic techniques (instead of a trusted third party) to ensure bridge security and reliability. As a result, users only need to trust in publicly visible code when transferring over IBC.
Yet, connecting to the IBC has a number of requirements. The IBC implementation on each blockchain has the following elements:
- Provable key-value store: this provides a key-value store interface with the addition that it can cryptographically prove to an external verifier the presence or absence of a given key-value pair. It is often realised as a Merkle trie but other cryptographic commitment schemes are also possible.
- Counterparty’s light client: an on-chain component responsible for processing and validating the blockchain headers of the counterparty blockchain. This client is light in the sense that processing only the headers requires a small amount of computational resources.
- IBC module: handles the logic of the IBC Protocol and maintains all the state necessary for the packet exchange. Some blockchains such as those implementing the CosmWasm specification have native IBC support and hence this module is part of the runtime environment. Other blockchains are IBC-agnostic and hence the IBC module is implemented as a regular Smart Contract.
- Smart Contracts: execute in the chain’s runtime environment and are responsible for sending and receiving IBC packets.
Before two blockchains can communicate along the IBC Protocol, an IBC connection must be established that meets the above requirements. This is done through a four-way handshake whose purpose is to negotiate the protocol version and features to use, as well as to verify the identity and status of each chain.
The four phases of the handshake are:
- Init: Chain A initiates the connection, sets the connection’s status to INIT and sends proofs of its view of: i) the status of the connection, and ii) chain B’s head. “Send” here means that an off-chain relayer forwards the message by executing a transaction on the other chain.
- Try: Chain B verifies the proofs, sets the connection’s status to TRYOPEN and sends replies with two analogous proofs.
- Ack: Chain A verifies the proofs, sets the connection’s status to OPEN and sends confirmation to chain B.
- Confirm: Chain B sets the connection’s status to OPEN.
Additional technical requirements imposed by the IBC on chains that it connects are that the ledger needs to:
- Provide a Smart Contract runtime with transactional state changes
- Support light clients and state proofs
- Provide block timestamps
- Support introspection including a view of past block hashes
The Solana Blockchain:
Solana is a blockchain network that has seen significant growth and attention recently. Its core strength is its significant scalability. Thus, Solana is quite a massive ecosystem in terms of usership as well as in terms of value. As of December 7, 2023, the total value locked (TVL) in Solana DeFi protocols is $712 million. This means Solana is the 7th largest blockchain in terms of TVL. The market cap of the network’s native SOL token was approximately $27.3 billion as of the same day. This puts SOL as the 6th largest token in terms of total market capitalization.
If Solana is made cross-chain capable, this allows for the development of new cross-chain use cases between Solana and other ecosystems, and enables users to more seamlessly navigate the cross-chain DeFi space. With the Solana <> IBC connection, users and developers will be able to implement any kind of cross-chain use case imaginable between Solana and the other IBC-enabled chains, including Cosmos/the Interchain, Polkadot, Kusama, and Ethereum. Thus, the speed, cost-effectiveness, and massive liquidity and usership of Solana can be leveraged from other ecosystems as well.
Problem Statement
In its present state, Solana doesn’t meet IBC’s technical criteria, preventing the ecosystem’s integration with the wider IBC network. For example, the IBC ICS-23 specification states that “…to provide a guarantee of a particular state transition having occurred on one chain which can be verified on another chain, IBC requires an efficient cryptographic construction to prove inclusion or non-inclusion of particular values at particular paths in state.” Solana lacks these required state proofs, instead implementing a more simple payment and state verification system. This makes Solana incompatible with the IBC protocol - at least until now.
Thus, the research question is:
- How do we make non-IBC compatible chains interoperable with the IBC?
Plan & Deliverables
Expected outputs/deliverables are as follows:
- Architecting a mechanism for enabling otherwise incompatible blockchains to interoperate with the IBC
- Providing a proof of concept for this mechanism by deploying it on the Solana Network
The plan for achieving this output is outlined below:
Present Experiment: The Guest Blockchain
Alongside our research collaborators at INESC-ID Distributed Systems Group of the University of Lisbon, Composable is pioneering an approach to introduce state proofs via a novel guest blockchain/layer 2 solution.
Our key insight is to create a guest blockchain, running on top of the original host blockchain. This guest chain extends the host capabilities with support for the creation of state proofs and further acts as the protocol light client. This brings two main benefits: first, the approach is generic and can be applied to any blockchain that supports some form of smart contacts, and second, it does not require changes to the underlying host. This last aspect is crucial since extending an existing blockchain with support for state proofs and/or light clients is far from a trivial endeavor. For instance, TRON lacks support for state proofs and it is unclear how these could be added to the system without substantial changes (detailed here). Solana similarly lacks state proofs (as detailed here). NEAR has state proofs but lacks key low-level functionalities to support IBC (as described here).
To make previously incompatible chains IBC-compatible, we introduce the concept of a guest blockchain. The guest blockchain concept acts as a foundational bridge, connecting previously isolated blockchains through the broader IBC. The benefits extend to increased liquidity, cross-chain DeFi opportunities, and a streamlined user experience. As we adapt and deploy this solution on additional blockchains, the vision of trust-minimized cross-chain interoperability becomes a reality, pushing blockchain towards mass adoption.
We initially deploy this guest blockchain for Solana, making this network compatible with the IBC and the other ecosystems it links. In the future, we will deploy this guest blockchain for other IBC-incompatible chains.
Thus, we are able to begin to address the research question above, with a number of areas for future work to expand, as described below.
Future Experiments:
To fully optimize this design, future work is still required. For example, issues may arise if the last validator in the system wishes to quit. Moreover, the IBC protocol security is built on implicit trust of the counterparties. Our solution does not provide any additional security measures on top of IBC protocol’s trust model.
In the future, this guest blockchain design should be adapted for and deployed on additional blockchains that lack state proofs and light clients, such as TRON. In this manner, all blockchains can eventually be connected, facilitating trust-minimized cross-chain interoperability. As a result, compared to using existing bridging options, blockchain users will be able to leverage the IBC to more easily, quickly, and securely navigate between chains, accessing new and existing use cases and financial opportunities.
References
How to Participate
If you’re a researcher who believes that you would be a good fit to contribute to any of the Composable RFPs, please reach out to Composable’s Lead Research Associate, Sydney Sweck, at sydney@composable.finance. In the email, be sure to include:
- The RFP number(s) you’d like to contribute to
- Your relevant background experience
- How you think you could contribute to the research