Problem with applications deployed in a single network

The size of the ledger of all Corda applications deployed in a single network can become large. The various nodes of the network communicate in a peer-to-peer fashion only with the nodes they need to transact. Still the notary service seems to be something that needs to be used by all the nodes and could potentially become a scalability and performance bottleneck.

Solution by Corda

To deal with the above-discussed problem, Corda supports both vertical and horizontal partitioning.

Each network can contain multiple notary clusters so that different applications can use different clusters (vertical partitioning). Even the same application can distribute its states between multiple notary clusters for better performance and scalability (vertical partitioning).

Note: The only requirement for all input states of a transaction is to belong to the same notary. This is so that the operation of checking whether a state is spent and marking it as spent can be done atomically in a simple and efficient way without the use of distributed transaction protocols.

Notary-change transaction

It is a particular transaction type provided by Corda, which allows one to change the notary associated with a state by essentially spending the state and creating a new one associated with the new notary.

In some use cases, the notary-change transaction partitions the datasets to require a minimum number of such transactions, because most transactions are expected to access states from the same partition.

For example, the partitioning of states according to geographic regions if we know in advance that most of the transactions will be accessing data from the same region. This architecture also makes it possible to use states from different applications very easily without the use of distributed transaction protocols.

Note: This above described process is known as atomic swap and, a real use case in the financial world is delivery-versus-payment (DvP).

Corda applications

Corda applications are called CorDapps and contain several components, of which the most important ones are the states, their contracts, and the flows.

The flows define the workflows between nodes used to update the ledger or simply exchange some messages.

Defining nodes interaction

Corda provides a framework that allows the application to define the interaction between nodes as a set of blocking calls that send and receive messages. The framework is responsible for transforming this into an asynchronous, event-driven execution.

Providing message serialization

Corda also provides a custom serialization framework that determines how application messages are serialized when sent across the wire and how they are deserialized when received.

Messaging between nodes

Messaging between nodes is performed with the use of message queues, using the Apache ActiveMQ Artemis message broker. Specifically, each node maintains an inbound queue for messages received by other nodes and outbound queues for messages sent to other nodes. A bridge process is responsible for forwarding messages from the node’s outbound queues to the corresponding inbound queues of the other nodes.

Even though all of these moving parts can crash and restart in the middle of some operation, the platform guarantees that every node will process each message exactly-once.

Achieving exactly-once guarantee

The guarantee of every node to process each message exactly once is achieved by resending messages until they are acknowledged and having nodes keeping track of messages processed already and discarding duplicates.

Performing operations in an atomic way

Nodes also need to acknowledge a message, store its identifier and perform any related side-effects in an atomic way. It is achieved by doing all of this in a single database transaction. All the states from the ledger that are relevant to a node are stored in its database. This part of the database is called the vault.

A node provides some more APIs that are used for various purposes, such as:

  • Starting flows
  • Querying the node’s vault

These APIs are accessed remotely via a client, which provides a remote procedure call (RPC) interface implemented on top of the existing messaging infrastructure and using the serialization protocol described before.

The following illustration contains a high-level overview of Corda’s architecture:

Get hands-on with 1400+ tech skills courses.