IBC Beyond Light Clients: Solo Machine
The Inter-Blockchain Communication (IBC) protocol offers a secure, general-purpose, and fault-tolerant standard to act as the connective tissue between blockchains. Over time, IBC has arguably established itself as the benchmark for natively verified interoperability systems. The light client-based verification mechanism that IBC uses has been at the core of ensuring its property of trust-minimization.
But IBC is more than its numerous light client implementations (Tendermint/BEEFY/NEAR).
Not only does its scope include blockchains, but also other forms of data systems such as solo machines. Anything from a web application hosted on a server, to a browser, to the mobile in your pocket is a solo machine. And these systems are capable of speaking IBC!
This is made possible using the IBC solo machine client.
What is an IBC solo machine client?
Before defining the solo machine client, it might be helpful to briefly discuss the semantics surrounding light clients in general, as well as IBC light clients (or just ‘client’ for short).
A light client is a lightweight alternative to running a full node. It is resource efficient because, unlike a full node, it does not store all of the block data and execute transactions. Rather they only verify block headers.
An IBC light client (such as the Tendermint light client) is a verification algorithm within a certain blockchain that can, in a resource-efficient manner, keep track of another blockchain’s state updates.
A solo machine is any standalone process that does not have a consensus algorithm. And the solo machine client is another type of verification algorithm capable of authenticating messages sent from a chain or solo machine.
Unlike an IBC light client which uses Merkle proofs to verify the validity of messages sent from a counterparty, a solo machine client keeps track of state by simply checking the authenticity of digital signatures.
Even though solo machines don’t have a provable consensus algorithm, they are still capable of storing a public/private key pair and can also support multi-signature keys.
As an example, when blockchain A communicates with a solo machine over IBC, it registers the solo machine’s public key(s) in its (blockchain A’s) state machine. Verifying the validity of a message sent from the solo machine is as simple as ensuring that the message was signed by its public key (as shown in Figure 1 above).
This is a significantly simpler and more cost-efficient mechanism of state verification compared to the full-fledged light client-based model.
A solo machine with a single key pair can be suitable for a PoA-like/trusted setup — applicable for various enterprise solutions. The client is also capable of updating keys, so a single key pair can be rotated on a regular basis for security. Using a threshold signature or multi-signature design offers the same security guarantees as an externally verified bridging solution, but with the additional capability of interacting and communicating over IBC.
Why use a solo machine client?
There are three key benefits to using an IBC solo machine client:
- Access to the IBC transport layer — and all subsequent chains and ecosystems connected to it (as well as the features + applications built on top).
- Removing the economic and operational overhead that comes with developing an entire blockchain in order to use IBC.
- Suitable to directly interoperate with chains where implementing a regular IBC light client can be complex (for example on Ethereum due to its probabilistic finality).
The transport layer of IBC — responsible for the transport, authentication, and ordering of data packets — is a powerful standard for blockchain interoperability. It offers access to a variety of IBC applications such as token transfers, cross-chain oracle data feeds, cross-chain governance, fee middleware, as well as features like Interchain Accounts, Interchain Queries, and more.
The use of a solo machine not only grants access to this trust-minimized, general-purpose, and ever growing interoperability framework, but one can do so without even having to develop a blockchain.
Crypto.com is the quintessential example of a centralized exchange bringing the IBC solo machine to production by issuing tokens on their public blockchain–Crypto.org. This allows Crypto.com to issue pegged DOT and XLM (Polkadot and Stellar’s native tokens respectively) which are of the ICS-20 (fungible token transfer) level. Hence the tokens can be sent to any chain that’s IBC-enabled and used within DeFi protocols.
As mentioned in Crypto.org’s blog post, without an IBC solo machine, an entity looking to issue tokens would be required to develop a standalone blockchain, connect it to IBC, and maintain/procure the relayer infrastructure required for system liveness. This naturally demands greater resources relative to deploying a solo machine.
Yet another exciting feature of using a solo machine is that it can leverage Interchain Accounts (ICA). In short, ICA allows a (controller) chain/solo machine to control an account on another (host) chain/solo machine. This opens up a plethora of interesting use-cases. For example, a solo machine acting as the controller can delegate funds to be staked on a host chain. The benefit here is that the private keys associated with the controller account (on the solo machine in this example), can be rotated without having to undelegate on the host side, update the private key on the controller, and then redelegate.
The solo machine can also be used to mint/burn tokens, request and receive oracle data (by using BandChain for example), use ICA for cross-chain/machine composability, and more. Hence given that any IBC-level application can be leveraged by a solo machine, the possibilities are virtually endless and up to the imagination of developers making use of this client.
Conclusion
IBC offers a unique and powerful framework for trust-minimized interoperability. And the impressive growth since its genesis is a testament to its security, composability, and extensibility.
While implementing light clients has been the standard design to plug into IBC, the options are not limited to this one method. And it turns out that the solo machine client offers an alternative to implementing IBC light clients. Given its simple proof verification method, the solo machine client is considerably easier to deploy from an engineering standpoint, and an effective solution in deployment scenarios where other potential concerns (eg. security) are mitigated by design.
In conclusion, having access to IBC offers a host of benefits. But it is equally important to facilitate ease of access to IBC as much as possible. And to this latter point, the solo machine client offers one of the best solutions today.
If you’re a chain developer looking to build your custom IBC light client, and have any questions, comments or feedback on the above, feel free to reach out to us here.
About the author: this post was written by Adi Ravi Raj, IBC Protocol Analyst at Interchain GmbH.
