How the Guest Blockchain for Solana IBC Differs from a Solo Machine Solution

By 0xbrainjar, Sydney Sweck, & Michał Nazarewicz


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:

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

(Image source)

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:

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.

1 Like