By 0xbrainjar, Sydney Sweck, & Michał Nazarewicz
Summary
The Inter-Blockchain Communication (IBC) Protocol provides a cost- and time-efficient and trust-minimized mechanism for cross-blockchain communication. This protocol was developed originally to connect blockchains within the Interchain, which includes the Cosmos Hub and Cosmos SDK chains. However, there are other mechanisms that have been emerging more recently that allow systems other than Cosmos-based blockchains to communicate with IBC and its connected chains. This includes IBC’s own solo machine client as well as Composable’s guest blockchain design.
In the following article, we explain how the guest blockchain is not a solo machine or solo machine client. We further break down the similarities and differences between these two mechanisms of tapping into the IBC. Most notably, the solo machine client allows non-blockchain solo machines to connect to IBC, while the guest blockchain allows non-IBC compatible blockchains to connect to IBC.
Guest Blockchain Overview
The Solana guest blockchain is a system developed by Composable and our collaborators on the research team at INESC-ID Distributed Systems Group, associated with the University of Lisbon. This guest blockchain design enables communication between IBC and previously IBC-incompatible blockchains such as Solana.
The guest blockchain architecture, detailed in Figure 1 below, involves the creation of a new “guest blockchain” that functions atop the “host blockchain” that is being connected to the IBC. The guest blockchain has provable storage in addition to all of the features needed for IBC compatibility, such as state proofs (which is the feature Solana is missing that makes it IBC incompatible). This guest blockchain functions similarly to a layer 2 (L2) blockchain in that it continually reads the underlying blockchain and sends transactions there for final settlement, while maintaining its own validator set to generate its own blocks. A relayer is also a critical component in IBC-guest blockchain connection, as it facilitates messages between the IBC and guest blockchain.
Figure 1: Guest Blockchain Architecture
The benefit of this approach is that it is generic and can be applied to any blockchain that is IBC-incompatible, though this requires some customization. Moreover, this approach does not alter the host blockchain, but still allows it to participate fully in the IBC, allowing it to leverage all benefits on all IBC-enabled chains. Through the guest blockchain, the host chain and other IBC-enabled chains are able to interoperate fully and seamlessly, to the same extent that IBC-native chains do.
Further information on the guest blockchain can be found in the following links:
- Crossing the Cross-Blockchain Interoperability Chasm
- Solana IBC | Picasso Documentation
- The first Solana IBC connection will soon be realized through Picasso | by Picasso | Medium
IBC Solo Machine Client Overview
To understand IBC’s solo machine client, it is important to first understand what a solo machine is. A solo machine is a standalone machine that is able to interact with blockchains through IBC, though it is not a blockchain itself. Examples of solo machines are web applications, browsers, laptops, and mobile devices. Notably, solo machines do not have provable consensus engines, though they can store public/private key pairs as well as multisignature keys.
With this definition in mind, IBC’s solo machine client is a verification algorithm that authenticates messages from a solo machine. This allows solo machines to access the IBC’s transport layer and IBC-connected blockchains and their features.
IBC’s solo machine client works through the implementation of a light client (also called light nodes). There is a light client on the solo machine, representing the blockchain that the solo machine is connecting to. The solo machine is thus able to send messages from a remote counterparty chain to be verified by an on-chain light client (called the solo machine client) on IBC-enabled chains.
When a blockchain and a solo machine are communicating via the solo machine client, the blockchain registers the machine’s public keys in its state machine via this solo machine client. The validity of a message from the solo machine is verified by ensuring that the message was signed by its private key. A diagram of how this works is shown in Figure 2:
Figure 2: Communication Between Blockchain A and a Solo Machine Over IBC
The benefit of the solo machine client is that it provides access to the IBC transport layer without the need to create an entire blockchain. Specifically, this transport layer facilitates transport, authentication, and ordering of data packets for IBC, further allowing access to many IBC applications. The solo machine client also allows use of interchain accounts (ICA), which allow a (controller) chain/solo machine to control an account on another (host) chain/solo machine.
Further information on the IBC solo machine client can be found in the following links:
- IBC Solo Machine | Developer Portal
- ibc/spec/client/ics-006-solo-machine-client at main · cosmos/ibc · GitHub
Comparison Analysis
The following table summarizes how the above-described features of the solo machine client and the guest blockchain compare and contrast:
Table 1: IBC Solo Machine vs. Composable Guest Blockchain
| Solo Machine Client | Guest Blockchain | |
|---|---|---|
| What can be connected to IBC: | A solo machine | A blockchain & its applications (currently, Solana) |
| Which IBC-enabled chains it connects to: | Cosmos SDK chains | Cosmos SDK chains, Polkadot and Kusama parachains, and Ethereum |
| How it connects: | Light clients, IBC | Light clients, IBC, guest/layer 2-like blockchain, relayer |
| How verification occurs: | Checking authenticity of digital signatures | Using Merkle proofs to verify validity of messages |
Key Takeaways
The largest difference between the presently discussed technologies is that the solo machine client connects solo machines to IBC, while the guest blockchain connects otherwise IBC-incompatible blockchains to IBC. Moreover, the solo machine client currently only has an implementation for Cosmos SDK chains and thus solo machines can only interact with these chains, while the guest blockchain can interact with all IBC-enabled chains (which now further includes Polkadot, Kusama, and Ethereum).
While the guest blockchain is not a solo machine solution, it does have some architectural similarities with the solo machine client given that both must interconnect with the IBC. Specifically, both use light clients, which helps these solutions uphold the efficiency, security, and trust-minimization that the IBC provides. Overall, though, the architecture of the solo machine client is much simpler than that of both the guest blockchain and also the standard IBC connections between Cosmos-based chains. This is because connecting an entire blockchain to IBC is much more complicated than connecting an individual machine to IBC.
To summarize, though they serve to connect different types of systems, both the solo machine client and the guest blockchain function to help bring IBC everywhere as the gold standard for cross-chain communication.