Researcher: TBD
Summary
Lack of trust-minimized interoperability between blockchain ecosystems remains a limiting factor on the utility and growth of DeFi. Bitcoin is one blockchain that has achieved some degree of mass adoption, but it is largely siloed and there are few opportunities for Bitcoin DeFi. By bringing the Bitcoin blockchain to the IBC, we aim to dissolve existing communication barriers across blockchains and open up new opportunities and uses for all the involved stakeholders.
This initiative will thus contribute the following:
- A mechanism for making Bitcoin IBC-capable, possibly using BitVM
Resulting benefits and use cases include increased liquidity between and within ecosystems, new assets accessible in new ecosystems, cross-chain Bitcoin 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
Bitcoin:
Bitcoin is the original cryptocurrency, with both the Bitcoin chain and its token being established in 2009. Bitcoin continues to be at the top of crypto rankings; at the time of writing, it has the largest Market Cap, which is over $890 billion (as per CoinMarketCap). Bitcoin is also the crypto that is arguably the closest to mass adoption, exemplified when Bitcoin ETFs were recently approved by the US Securities and Exchange commission. However, DeFi practices with Bitcoin are limited compared to other blockchains like Ethereum, partially due to its inefficiencies such as significant financial/energy costs to operate and slow transaction speeds.
Bitcoin is currently very isolated from other chains. One contributing factor is that it is structured very differently from most newer blockchains (such as being the only significant proof-of-work blockchain, with other chains operating along proof-of-stake security models). Relevant to this research initiative, Bitcoin lacks many of the requirements of the IBC, making it incompatible with the IBC in its current state.
Yet, if Bitcoin is made cross-chain capable, this allows for the development of new cross-chain use cases between Bitcoin and other ecosystems, and enables users to more seamlessly navigate the cross-chain DeFi space. With the Bitcoin <> IBC connection, users and developers will be able to implement any kind of cross-chain use case imaginable between Bitcoin and the other IBC-enabled chains, including Cosmos/the Interchain, Polkadot, Kusama, Ethereum, and soon, Solana. Thus, the massive liquidity, usership, and reputation of Bitcoin can be leveraged from other ecosystems as well. This also brings a new opportunity for Bitcoin DeFi to flourish, in particular cross-chain DeFi with Bitcoin tokens on other ecosystems that are better positioned to support DeFi practices at scale.
BitVM:
BitVM is a novel, work-in-progress computing paradigm enabling Turing-complete smart contracts on Bitcoin via Taproot trees and fraud proofs. This provides an opportunity for light client proofs (such as those from IBC-enabled chains) to be natively verified by Bitcoin.
Problem Statement
The problem here is that Bitcoin is largely siloed from other blockchain ecosystems, leaving Bitcoin DeFi opportunities incredibly limited. The IBC provides a potential means for connecting Bitcoin to other ecosystems, but first Bitcoin must be made IBC-compatible.
Thus, the question that this research aims to address is as follows:
- How can we connect Bitcoin to the IBC to make it cross-chain interoperable?
Plan & Deliverables
Expected outputs/deliverables are as follows:
- Architecting a mechanism for enabling Bitcoin to interoperate with the IBC
The plan for achieving this output is outlined below:
Experiment: Mechanism for Bitcoin IBC Compatibility
This is a largely coding-based initiative. First, we will work to identify and isolate specific components of Bitcoin that make it IBC incompatible. Then, we will develop and test solutions to each of these limitations, ultimately compiling a cohesive design for allowing Bitcoin to send messages back and forth with the IBC (and thus with the blockchains that IBC connects). It is likely that we can use BitVM to accomplish this, similar to Citrea. The Citrea trust-minimized bridge program consists of an operator and verifier software with zk circuits of the bridge, built on top ofBitVM. The final model will be simulated/tested to prove its effectiveness at enabling Bitcoin IBC connectivity.
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