Corda's Data Model

Corda’s data model for electronic money

The following illustration shows a simple example of the Corda’s data model for electronic money:

In the above illustration, each state represents an amount of money issued by a specific bank and owned by a specific party at some point in time. We can see that Alice combines two cash states to perform payment and transfer 10 GBP to Bob. After that, Bob decides to redeem this money to get some cash from the bank.

As shown in the above illustration, there are two different commands for each case. We can also guess some of the rules of the associated contract for this Cash state.

For a Spend command, the contract will verify that the sum of all input states equals the sum of all output states so that no money is lost or created out of thin air. It will most likely check that the Spend command contains all the owners of the input states as signers, which need to attest to this transfer of money.

Double-spend problem

In the above example, we can notice that nothing would prevent someone from spending a specific cash state to two different parties who would not be able to detect that. This is known as double-spend.

Preventing double-spend

Double-spend is prevented in Corda via the concept of notaries.

A notary is a Corda service responsible for attesting that a specific state is not spent more than once.

Transaction finalization

In practice, every state is associated with a specific notary and every transaction that wants to spend this state needs to acquire a signature from this notary that proves that the state was not spent already by another transaction. This process is known as transaction finalization in Corda.

Fault tolerance and availability with a Notary cluster

The notarisation services are not necessarily provided by a single node; it can also be a notary cluster of multiple nodes in order to provide better fault tolerance and availability. In that case, these nodes will form a consensus group.

Corda allows the consensus algorithm used by the notary service to be pluggable depending on the requirements in terms of privacy, scalability, performance, etc. For instance:

• A notary cluster might choose to use a crash fault tolerant (CFT) consensus algorithm (e.g., Raft) that provides high performance but also requires high trust between the nodes of the cluster.

• Alternatively, a notary cluster might choose to use a byzantine fault tolerant (BFT) algorithm that provides lower performance but also requires less trust between the nodes of the cluster.

Implications of permissions on Corda nodes and notaries

Permissioning has different implications on regular Corda nodes and notaries.

• In the first case, it forms the foundation for authentication of communication between nodes.
• In the second case, it makes it easier to detect when a notary service deviates from a protocol (e.g., violating finality), identify the associated real-world entity, and take the necessary actions.

This means that finalized transactions are not reversible in Corda unless someone violates the protocol.

Note: Corda is in contrast to some other distributed ledger systems where nodes are anonymous and can thus collude in order to revert historic transactions, such as Bitcoin.

As mentioned previously, in some cases, even a limited amount of protocol violation can be tolerated, i.e., when using a byzantine consensus protocol.