by Miguel Matos, 0xbrainjar
The emergence of multiple blockchain ecosystems with disparate technical, security, and economic characteristics has been a blessing (giving users freedom to choose the ecosystem that best fits their needs) and a curse (as these ecosystems typically do not mesh well).
Among the different approaches to bridge these ecosystems, the Inter-Blockchain Communication (IBC) Protocol is notable as it enables heterogeneous chains to trustlessly communicate. Composable expanded this protocol outside Cosmos to other chains, including Polkadot, Kusama, and Ethereum, via their IBC bridge. However, many blockchains such as TRON, Solana, and NEAR lack the requirements to interoperate with the IBC - until now.
Composable and our research team at INESC-ID Distributed Systems Group have developed a solution: a guest blockchain, which enables light client verification of state for blockchains without state proofs or IBC-specific host functions. Currently, we are building proofs-of-concept for the Solana and NEAR blockchains with support for other ecosystems coming. As a result, previously IBC-incompatible chains successfully interoperate with the IBC.
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).
The figure below illustrates the sequence of steps to send a message between blockchains in our approach. Anyone can run a relayer to pass messages between the host blockchain and the counterparty blockchain:
Individual features of the guest blockchain are detailed below.
To be able to provide proof to the counterparty blockchain, a guest blockchain with provable storage is necessary. The guest blockchain thus implements a provable key-value storage which addresses the requirement of having state proofs and other features that allow it to comply with IBC prerequisites.
As exemplified in the code snippet below, the commitment of the storage is included in the block in the form of a hash of a root node of a Merkle trie. The guest blockchain uses this Merkle trie to keep its state. An important consideration is the amount of information that needs to be kept. As an IBC connection continues to be used, more data is generated. This problem is especially crucial for the guest contract because it runs on the host blockchain where storage costs are higher compared to a“bare metal” machine or “the cloud”.
To address this, the trie used by the guest blockchain implements sealing or pruning of subtries. Any node can be sealed and removed from the on-chain storage. This operates recursively up the trie such that if all children of an inner node are sealed, the node itself can be sealed as well. This enables creation of membership and non-membership proofs for keys on the trie:
Blocks are grouped in epochs which have minimal length. An epoch specifies the set of validators that sign the blocks. Once a simple majority of stake signers is reached, the block is accepted and finalized. New epochs are introduced through the next_epoch field in the block. The hash of the block when epoch was introduced serves as epoch’s identifier (i.e. epoch_id).
If someone receives a block belonging to an epoch they do not know about, they can request a block by hash to get the epoch’s definition. If needed, this can be repeated until a block belonging to a known epoch is encountered. This makes it possible to sync to the latest state of the blockchain without having to fetch all blocks.
The guest blockchain has validators that are responsible for producing guest blocks with the state proofs that are then sent to the counterparty chain by a trustless relayer, similarly to what is done in existing IBC-enabled blockchains. From the perspective of the host blockchain, the guest blockchain is just yet another smart contract which hence inherits the security model and guarantees of the host blockchain.
If one wants to become a validator for the guest blockchain, they need to stake assets with the guest contract. Once they do so, they are added to the set of candidate validators. The validation requires minimal resources from the validator as the bulk machinery is provided by the underlying host blockchain. This makes the validator role quite lightweight and hence appealing.
If enough blocks have passed since the beginning of current epoch (see section “Epoch Change” above), the contract looks at the candidates with most stake, picks them as the validators set of the next epoch, and proposes it in the next_epoch entry of the next block. If a validator wishes to stop validating, they again send that information to the guest contract which removes them from the set of possible validators. However, the validator must continue validating blocks until the validator set change occurs. In other words, validators must commit to validate blocks for the duration of at least one epoch. Otherwise, staked tokens are not released, making this an incentive to follow the protocol.
Furthermore, once a validator is removed from an active set, they need to wait before their staked tokens are released to them. This is to allow other parties who may have detected malicious behavior performed by the validator to submit their proofs.
Any actor can provide a proof of slashable behavior by submitting it to the guest contract as either i) a pair of signatures for blocks with the same height but different hashes or ii) a signature for a block whose hash does not correspond to known hash at that block’s height. Submitted blocks must belong to the same chain the contract is operating (i.e. have the same genesis hash).
Because the guest contract stores a limited number of past hash values, the second form of misbehavior proof is not always possible to verify by the contract. This means that if a malicious validator signs an invalid block only, that behavior may remain unpunished if it is not caught in time. However, signing multiple blocks can always be reported successfully.
Since a host blockchain may have forks, validators must wait for a host block to finalize before they sign a virtual block generated in a given host block. This guarantees that they will only ever sign a single virtual block for given height and thus will not face slashing punishment.
Once misbehavior is successfully reported, the validator is slashed (i.e. their stake and unpaid rewards are taken away) and they are removed from the validators set for the next block. This may lead to a validators set change outside of the regular epoch change schedule. To avoid validators performing fraudulent actions and immediately resigning with all their stake and rewards intact, the virtual blockchain holds onto the validator’s stake and reward for a period sufficient for other actors to have time to find and report any potential slashable behavior.
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 conclusion, 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. 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.
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.