Corda-IBC: A Framework to Achieve Interoperability Between Corda and Heterogeneous Blockchains via IBC
Hyperledger Lab YUI is a blockchain interoperability project that enables multiple heterogeneous blockchains to connect to each other with IBC protocol. YUI has supported Hyperledger Fabric and Hyperledger Besu, and now, we have officially launched the IBC Module for Corda, or Corda-IBC. To put it simply, YUI finally supports Corda.
As many of you might already know, Corda is one of the largest enterprise blockchain platforms in the world. It is used for various projects such as digital currencies, financial systems, supply chain management, etc.
In this article, I will go through the overview of Corda-IBC and how we realize interoperability between Corda and other blockchains via IBC.
For an article on IBC, please see here.
Corda-IBC Overview
Corda-IBC implements IBC/TAO and ICS-20 in the form of Corda contracts/flows and also provides gRPC API services for clients to execute IBC operations and to access IBC states. In the Corda world, there are no global states; in other words, Corda is not a blockchain platform. However, there is still a way to implement IBC in such an environment.
In the UTXO model of Corda, state classes that are updated repeatedly and live through multiple transactions can be implemented. Such output states are called “linear states” in Corda. Each linear state forms a sequence of linear state transitions, which is similar to that a blockchain forms a sequence of linear state transitions.
Corda-IBC defines a special linear state class named “Host” and handles a Host as one end of an IBC connection. In reality, several IBC-related states like ClientState, Connection and Channel are created separately from Host to improve the performance.
Anyway, the fundamental idea of Corda-IBC is to regard a group of linear states that consists of one Host state and multiple IBC-related states created under the Host state as a blockchain to connect to another blockchain via IBC. Each output state in Corda can be proved to exist and to satisfy expected conditions, by showing a SignedTransaction that includes the said state as output and that is signed by proper parties (e.g., Notary).
Contract States
All contract states defined in Corda-IBC are created under any one Host state. The following figure shows how Corda-IBC states are created.
A Host state and all states created under it share the same “host ID”. Every state that belongs to the same Host state has a unique “state ID” that is unique in the scope of the Host. On the other hand, it is assured by a simple trick that every Host state that is notarized by the same Notary has a host ID that is unique in the scope of the Notary. Thus, a combination of host ID and state ID becomes an ID specifying a single state that is unique in the scope of the Notary.
Operations (Flows)
The IBC standard defines operations to update IBC states such as updateClient, connOpenInit, chanOpenInit, recvPacket, acknowledgePacket, etc. Each of the IBC operations is implemented as a flow in Corda-IBC. The following figure shows how a Corda-IBC-related transaction is set up and verified to be valid. Each of the operations complies with syntax and semantics defined by IBC (ICS).
The figure below shows how to create a transaction with Corda-IBC.
The figure below illustrates how to verify a transaction with Corda-IBC.
Light client for Corda-IBC
In the context of IBC, external light clients must be able to verify that specified states do indeed exist on a target ledger by only inspecting the states themselves and succinct proof of the states. For example, in terms of blockchain that embeds merklized state roots in block headers (e.g., Ethereum), we can prove and verify the existence of states by generating and validating Merkle proofs of the states. Blocks themselves can be validated by checking if they satisfy the “consensus rules” of the blockchain.
In the case of Corda, we can verify the existence and contents of states much more straightforward than typical blockchains. Given a Notary’s public key and a target Host’s base ID, a light client for Corda-IBC can verify states created under the target Host by checking if a presented “SignedTransaction” satisfies the following conditions.
- It is signed by an expected Notary.
- It includes a target state as output that:
✓Has an expected base ID.
✓Has expected contents.
Final Thoughts
Supporting major enterprise blockchain platforms is crucial for IBC to adapt to the enterprise area. Datachain is actively contributing to this effort through the YUI project, and Corda-IBC is also being developed for this goal. Corda-IBC supports only ICS-20 as IBC/APP for now, but in the next step, it is planned to evolve it into an SDK for building various IBC/APP implementations. Stay tuned for Corda-IBC and the YUI project.
