Corda is a decentralized ledger. Corda is about states, vault, point-to-point messaging, on and off-ledger, contracts, notary services. Corda is a financial service consortium. It was launched as a decentralized ledger, where attention is paid to the way data is processed. Millions of dollars are spent every year to reconcile data. Corda introduces a shared processing logic, to meet organisations’ financial synchronisation and reconciliation.
- Corda Explained
- Key features and how it works
- Comparison with a regular Blockchain
Key features and how it works
Corda Ledger – Network
A peer-to-peer network can be compared with a digitalized group of individuals sharing messages.
In a globalized ledger, messages are sent as gossips, with the aim to get the message distributed to all nodes. Corda is a different solution:
Messages are distributed on a need to know basis between using point-to-point messaging. Each node needs to specify the recipient of the message, which can be found in a Network Map, a kind of phonebook with all relevant data of the peers.
Corda Ledger – Data
Considered as data known by more than 1 party/node. Everything that is being shared makes the whole ledger. No two peers see the same data, as each node can share sub sets of data with other peers.
Facts or data known by only 1 node may be kept off-ledger or on-ledger, however, when kept on-ledger it’s a non-shared data set.
Corda Ledger – Object
Ownership is usually documented based on describing transfer of ownership and maintaining the history of transfers. Corda introduces a ‘State’ to embed the agreement between parties, in a digitalized fashion.
Contain the shared information. Similar as in a blockchain, where transactions and the data structure are immutable, states cannot be changed. To take into account the evolving characteristic an agreement may have, states can only be ‘updated’ by copying the latest version and making updates. The newest version becomes the ‘current’ one while the previous version becomes ‘historic’. A state can hold any type of asset: IOU-cash transaction, swaps, invoices, etc. Once the type has been created, it cannot be changed to any other type.
State sequences are depicting the life cycle of an agreement. Any change to the state from issuing to settlement must result in the creation of a new version of the state, while making the previous one ‘historic’. The chain of states from creation to the end is the ‘state sequence’. The historic states may be kept on or off-ledger. The most current state is called the head of the sequence, which represents the latest information of the shared data.
Corda Ledger – The Vault
A wallet is a virtual container where cryptocurrencies are stored. Corda uses a Vault to track the current state of the ledger. A vault can be queried by type (per asset), by consumed or unconsumed state. Historic states are considered as consumed states. Heads as unconsumed states.
Each head, as they represent shared facts, has an identical head ‘type’ in another node’s Vault.
In case a head is maintained for own purpose (non-shared data), it will not have a representative head in any other vault.
Corda Ledger – Transactions
In a regular blockchain, transactions are part of a Merkle tree. Next to this, a new block header is created which consists of the hash reference of the preceding block and the root of the Merkle tree that contains the new transactions. A new hash reference pointing to this latest created header will become the head of the blockchain.
Transactions in Corda work differently. Transactions are not grouped in a block with unrelated transactions. In Corda there is no ‘global’ update of the ledger, only a point-to-point communication, where bringing various transactions together in a block, wouldn’t make sense at all.
Transactions are a proposal to change the ledger.
There are 3 types of transactions:
- Issuances: create/issue states on the ledger
- Updates: the state
- Exits: ends the state, without creating a new output version
Those transactions can contain different state types. However, a transaction is atomic meaning that all changes proposed by the transaction must be accepted.
Corda Ledger – Acceptance Process
A node on the ledger will make a proposal to update the ledger. The involved peers will verify the proposal and sign in case they accept the proposal and agree about the validity. From that moment, the transaction is committed, meaning the input state reference becomes historic and a new output state is created.
Prior to this ‘digital’ signature validation, the contractual validation takes place. A contract is a part of the state, besides the properties and the participants. This contract is a function that verifies whether the proposed changes meet the rules. The execution of the contract should always deliver the same result and in this way the contractual validation can be performed by each peer independently.
On top of the peer’s consensus about the validity of the transaction, the uniqueness of the input state is another prerequisite to bring the transaction to finality.
This uniqueness validation is done by the notaries, who keep a map reference to the input states. In case the input state wasn’t ‘mapped’ yet, the notary will sign the transaction. At the same time, the input state will be ‘mapped’ and becomes invalid for any future transaction.
This validation is also called the non-verifying transaction, as the notary doesn’t need any access to the content of the states.
The validation of the peers should include the verification of the transaction’s dependencies and ensures that all depending transactions in the chain are signed by all involved peers and are accepted by the contract. Peers should be able to deliver the entire chain on a request basis, if they ask to accept a transaction.
Transactions should contain a sub-flow to automatically deliver the necessary dependencies in order to find the historic transactions.
Corda Ledger – Identities
A distinction is made between legal organisational identities and service identities.
Legal identities are directly involved in the transactions. Service identities provide a particular service during the execution of the transaction.
A first service identity is the notary who ensures the uniqueness of the input states. Another service identity is the ‘Oracle’. The Oracle is consulted in case external information is needed to evaluate the transaction’s validity. In that case next to the involved peers and the notary, the signature of the Oracle is a prerequisite to finalize the transaction.
Comparison with a regular Blockchain
Some of the characteristics of blockchain are present in the Corda model, however R3 gives them their own characteristics. An overview of features and the way they’re handled in Corda:
The way privacy is handled, (e.g. partial data visibility), the consensus and limited shared ledger approach may conclude that Corda lends itself to support very specific agreements and contract types.
We all understand now Corda isn’t a blockchain. But, whether Corda is considered as a distributed ledger, a business to business ledger or a shared ledger, the current design as presented, shows the initial aim to meet the requirements of financial services and other derivative products.