How R3 Corda works
A short ouevre on Corda distributed ledger platform.
“ An assemblage is precisely this increase in the dimensions of a multiplicity that necessarily changes in nature as it expands its connections. There are no points or positions in a rhizome, such as those found in a structure, tree, or root. There are only lines.”
Gilles Deleuze, Felix Guattari. (1980) A Thousand Plateaus.
This time I suppose the article will be more theoretical than last several times and I hope I won’t come down to a silly joking I used to. From the very beginning of this blog, my intention was to somehow utilize a humanitarian vision of emerging technologies, especially blockchain and decentralization. It really lacks rigor, but I hope it could be a nice introduction to a very technical thing for those curious though not deeply technical people.
So let’s start. There are two main documents I am using in the article: a non-technical whitepaper and technical whitepaper.
There are three main concepts you need to know to master your knowledge in Corda. Here they are:
- State — or, state object. It’s a building block of Corda and it represents a specific agreement or contract, like a real-world contract. This is the one thing the consensus should be achieved about — the exact state object, not a state of the entire ledger. It’s important and will be described in details later.
- Flow — a small multi-party sub-protocols that are used to share transaction data (state objects) with relevant involved parties. It’s opposite to what we can observe in public blockchains like Bitcoin and Ethereum where transaction data is globally broadcasted.
- Notary— a mystic thing indeed (yeap I lied you when said I won’t joking). An entity that provides transaction ordering and timestamping services. The thing is, Corda doesn’t organize transactions into blocks, so, it’s not a blockchain.
Being said that, let’s see how it does work.
Unlike Bitcoin and Ethereum, Corda is a permission-based network where you have to be granted access. It’s specified in flow API — yes, the flow I introduced earlier. It also can be considered as a tribe or something that imposes certain requirements on your identity and you cannot join the specific flow unless you satisfy it. The consensus is achieved on a transaction level (instead of leger level as in Bitcoin or Ethereum), thus there’s no need for all network nodes to verify and approve the transaction.
Indeed, the important thing about Corda is it’s agility to using different consensus algorithms. As it has no exact one, the notaries can actually use different ones — BFT, Raft, maybe some others. Running ahead it can be said that Corda develops a metanetwork for all these sub-networks or flows. Imagine that there are auditing companies, banks, cleaning companies that serve these banks. All of them have their internal cuisine of bookkeeping, subcontractors, various other financial and non-financial relations. In a way Corda aims to develop a system for all their interactions, both within a single company and with others, using the same protocol.
It’s worth mentioning that the developers of Corda from the very beginning claims that they are creating an architecture that will model and automate real-world transactions in a legally enforceable manner. This is a common pitfall of many blockchains that the transactions they store do not have a legal value. Instead, smart contracts in Corda has not only transaction information, but also legal prose.
For a better understanding of this architecture, let’s see how it works compared with another well-known permission-based network — Hyperledger Fabric.
Fabric’s understanding of consensus covers the whole transaction flow, starting from proposing a transaction to the network community. The nodes assume different roles and tasks in the process of consensus. There’re three different types of nodes in Hyperledger Fabric:
- Endorser peer, that validates the transaction and executes a chaincode (a smart contract). It doesn’t make any update in the ledger.
- Anchor peer, that establishes a connection between other peers. For instance, there’re two companies — manufacturer and supplier. They have their own DLTs built on HL Fabric, and so with anchor peers, they can exchange the information about the states of their ledgers. It broadcasts the updates that are happening in the ledger.
- Orderer peer, that updates the ledger by making new blocks of transactions. So it’s responsible for keeping ledger updated.
Both HL and Corda have a consensus on a transaction level, not on a whole ledger (like Proof-of-Work or Proof-of-Stake). The subject of the consensus is transaction validity and uniqueness (avoidance of double spend). Unlike Hyperledger Fabric, where the ledger is shared across every organization in a Fabric channel, in Corda, the transaction is shared only within the sub-network or flow. In that sense, there’s a direct communication instead of a global broadcast, and privacy is preserved.
Besides, Corda doesn’t put transactions into blocks (that’s why there’s no blockchain, all these Merkle trees, etc.). As it takes time to broadcast a block with transactions across the entire network, it may affect the system because lots of new transactions are happening at this time. This means that blocks need to be created slowly enough that each has already been distributed across the network before the next one is created.
Instead, in Corda individual transactions are sent directly to the involved parties, a very quick process. And so that’s why
No entity has an entire history of all the transactions in the network.
But there’re notaries that know the current states of this particular piece of the network. They serve as validators of the transactions. And the typical transaction looks as follows:
- A new transaction A turns (“spend” in Corda terminology) a state X to create a state Y.
- You send transaction A to the notary that knows about state X.
- The notary checks that state X is still valid and signs transaction A. State X is now invalid, with state Y taking its place.
If state X above were not valid when the transaction was proposed, the notary would respond that state X had already been spent.
Thus, Corda has transmitted the responsibilities of knowing the world state and seeing all transactions from the entire network onto a special notary service. Members of the network don’t need to trust everyone, just the organizations that run the notary. There can also be multiple notaries, each trusted for a different purpose.
Notaries can compete on their availability and performance.
Although this architecture raises many questions, it was interesting to study it and compare it with the blockchain and DLTs (I finally understood the difference). Perhaps next time we will try to evaluate financial applications of Corda using the example of securities.
The opinion of the author may not coincide with his point of view.
For personal inquiries, please text in Telegram.
