Deep Dive on the Design of R3 Corda
How is Corda designed? Why is it generally accepted by the financial industry?
Foreword
Corda is a distributed ledger built for enterprises. It is developed and maintained by R3 and officially open sourced in 2016. It is a well-known consortium chain together with Enterprise Ethereum and Hyperledger Fabric. Corda is quite unique. First of all, its design is different from the other two. For example, it uses the “Unspent Transaction Output” (UTXO) model instead of the “Account Model”. Second, Corda has very different goals. In this article, let’s take a deep dive into the design of Corda.
In order to distinguish from the technologies mentioned below, I will temporarily refer to the blockchain technology originated from Bitcoin/Ethereum as “Nakamoto Blockchain”.
*Special thanks to Daniel Huang for his revision and feedback
Origin of Corda
Corda is a technical solution for upgrading and improving the efficiency of collaboration in the financial industry. Compared with the goal of Nakamoto blockchain, which turned out to be radical, Corda appears to be more gentle and stable. R3 believes that the current collaboration model between the financial industry is not only inefficient but also costly, for the reason that each organization all maintains its own ledger. In order to be rigorous, verifying each other’s ledger might be a costly and time-consuming task. Moreover, Each different collaboration scenario needs to repeat the verification process, which also makes collaboration inefficient. In this regard, the solution proposed by R3 is very intuitive: let the organizations jointly maintain a ledger and reduce the cost of verifying and building trust.
Simply put, Corda can allow two or even multiple organizations to share the same ledger and reduce the cost of trust. Reducing costs is almost equivalent to reducing the “human factor” and automating the process. Corda enables the node to automatically execute transactions in accordance with the “contract” and “flow” concluded by both parties in advance.
In the context of collaboration in the financial industry, Corda’s design is not only inspired by the Nakamoto blockchain, but also focuses on the feasibility of regulations, which gives Corda a clear standpoint. Based on the Nakamoto blockchain, Corda has developed a unique structure in the design of “ledgers”, “consensus” and “contracts”. In this article, I will explain the design concepts of these three in more detail.
Before that, let’s take a look at Corda’s basic components and transaction workflow.
Overview of Corda
Corda is a peer-to-peer network. Participants, or Corda nodes for short, are the main members of the Corda network. Nodes can connect to each other to form a business network and can join different business networks simoutaneously according to scenarios.
In addition to the Corda node, there are some necessary service nodes, such as the notary which is responsible for checking double spending of transactions, the identity service which is responsible for identity and permissioning, the network mapping service which is responsible for node lookup and the oracle, which is responsible for introducing real-world information.
Corda Node
A Corda node includes:
- Modules required by the service node, such as notary modules and identity modules.
- Modules related to transaction execution and storage, such as Java virtual machine (JVM), transaction database (Rows) and vault.
- CorDapps, which are distributed applications running on Corda.
The “Vault” in the Corda node is different from the open source project Hashicorp Vault
Introduction to CorDapp
CorDapp is a distributed application running on Corda. All Corda nodes have to run CorDapps to send transactions, form consensus, or update the ledger.
Conceptually, CorDapp is an encapsulation of business logic, which makes it easier to replicate complicated financial services between different institutions. Corda nodes can also have multiple CorDapps run to participate in different collaboration scenarios at the same time.
Specifically, these business logic refer to “flow”, “state” and “contract”:
- Flow: Each CorDapp corresponds to a unique “flow” programmed by developer according to actual needs, usually related to the business. It is a set of steps required from initiating a transaction to confirming a transaction betwwen a “initiator” and “responder”. Particularly, the identity of the “notary” is also specified in the “FLow”.
- State: Every CorDapp has a “state” to express more information than a simple account balance. However, the “state” here only defines the format and does not actually save the value of the state. Only when the transaction is initiated, the actual value is recorded on the transaction according to the “state”.
- Contract: Each CorDapp’s “state” corresponds to a “contract”, which is a set of constraint rules that verify the validity of a transaction — that is, the real-world definition of “contract”. It is worth mentioning that the “contract” of CorDapp and the “smart contract” of the Nakamoto blockchain are two completely different concepts.
Practically speaking, CorDapp is a JAR file, which wraps the Java class and runs on the JVM. The “flow”, “state” and “contract” all have their corresponding Java classes, and R3 officially provides basic templates for developers to program CorDapp based on them.
The Four Major Stages of Corda Transactions
Although CorDapp can design a “flow” to accommodate different business logic, the transaction process can be roughly divided into four major stages:
- Initiating a transaction: The “initiator” first obtains the value of the new state based on the CorDapp “state” and “input” then generates a transaction with the new state and signs it.
- Verifying the transaction: The “responder” verifies the transaction according to the “contract” where the transaction refers to. If the transaction is valid, then the transaction will be signed.
- Notarizing the transaction: the designated “notary” checks if the transaction is double spent. If the transaction is valid, the “notary” will sign on the transaction.
- Updating the ledger: The “initiator” and “responder” check whether the transaction is accompanied by the signature of “notary”, and update the ledger if there is.
Corda transactions are only verified and executed on the related parties of the transaction, and the transaction will not be broadcasted to all nodes. Such a consensus model is more in line with the transaction process that occurs in the real world, which is different from the Nakamoto blockchain “Order- Execute” consensus model.
On the other hand, Corda’s approach to maintaining the ledger consensus is also completely different from that of the Nakamoto blockchain . Corda does not need to maintain a globally unique transaction order, nor determine the proposer in a decentralizing manner. It only needs to maintain the consensus on the “uniqueness” of the transaction, and this work can be done through a “notary” that has a overall view of the transactions. I will elaborate on the details of consensus and “notary” below.
Next, let’s delve into Corda’s design concepts.
Design Concepts of Corda
Corda is inspired by the Nakamoto blockchain. What does it borrow from the Nakamoto blockchain in the design of “ledgers”, “consensus” and “contracts”? What are the innovations of Corda?
1. Ledger: Extend the UTXO Model and Make the Ledger “Localized”
The “Unspent Transaction Output” (UTXO) model is a classic invention used by Bitcoin. Compared with the account model, the state of UTXO is not concentrated in a single huge tree-like data structure, or called the “world state” for short, but is recorded in every transaction scatteredly.
In the UTXO model, each transaction has an “input” and an “output”: “output” is the new state, “input” is the “output” of other transactions. For example, in the above figure, “TRANSACTION Hash=1ba0ce7a71…” on the right has two inputs, corresponding to the second output of “TRANSACTION Hash=95fd065cb0…” on the left and The first output of “TRANSACTION Hash=0dbfcf6665…” on the left.
“Output” has two states: “spent” and “unspent”. If an output has been used as an input by other transactions, the output becomes “spent” and cannot be used as an input for other transactions again. The UTXO model must prevent “double spending” to ensure the safety of the ledger.
The UTXO model can express a clear evolution of the state. This feature is more suitable for the financial industry that focuses on original documents and regulations. Moreover, the transaction order in the UTXO model is naturally established, which contributes to a lighter consensus mechanism.
Corda has also extended on the basis of UTXO, such as introducing the design of “command” and “attachment”, etc. Combined with the “state” of CorDapp, these designs can enrich the expressiveness of the UTXO model to accomplish more complex business logic. It is worth noting that the “attachment” can be a legal prose, which can be used for follow-up actions if there is an unexpected transaction result.
The ledger under the UTXO model is the collection of outputs at the edge of a directed acyclic graph (DAG) composed of all transactions. As mentioned in the overview, Corda’s transactions will only be stored by related parties and will not be broadcasted to the entire network. Therefore, the Corda node maintains a “localized” ledger that is only related to itself, rather than one “global” ledger with all transactions. As shown in the figure above: Alice’s ledger has transactions 2, 6, 5, 4, 1, while Bob’s ledger has only transactions 2, 6. This means that the transaction is no longer verified by every nodes. The node has to obtain and verify the upstream transactions of the input all the way to the source, by itself. In fact, this “lazy validation” paradigm is relatively lightweight for the entire network in the sense of computing power.
2. Consensus: Use a Lighter Consensus Mechanism instead of “Blockchain”
Corda is a decentralized ledger, which means it also needs a consensus to ensure the safety of the ledger. However, it puts the two attributes of consensus: validity and uniqueness, to different mechanisms to maintain respectively.
The validity of the transaction is ensured by the parties involved in the transaction; the uniqueness of the transaction is verified by the “notary”, and neither of them actually needs to use the blockchain. Why? First of all, the “notary” is a relatively centralized design, without the need to determine the proposer by generating blocks. Second, since the transaction order of the UTXO model is naturally established, so there is no need to use blocks to establish the global order.
The “notary” checks whether the transaction has been “double spent” by keeping the information of transactions from different nodes to confirm the “uniqueness” of the transaction. Notaries have real-name identities and are directly designated in the “flow”. As a result, notary with sufficient credibility will have higher probability to be chosen by the initiator.
Compared with traditional notary services, the Corda notary has two additional properties:
- All operations are performed automatically, openly and transparently.
- The notary can be a cluster composed of nodes from different organizations. Each notary node verifies separately and then reaches a consensus through the consensus algorithm, being either Byzantine fault tolerant (BFT) or crash fault tolerant (CFT).
3. Contract: Paired with “Flow” to Realize Programmable Value
Corda contracts are just like the various contracts that we are accustomed to in the real world — — They provide rules for verifying the “state”, and transactions that violate the contract will be invalid.
For example, when renting a house, the “lease agreement” has the list of rules for keeping the state of the house, such as no holes in the walls, and intact furniture. If the contract is violated, the rental will be invalidated.
The mapping relationship between Corda contracts and real-world contracts is closely tied to the design philosophy of Corda. This also makes it very easy to copy various contracts that have been in the financial industry for many years to Corda.
If we compare the concept of “Corda Contract” with “Ethereum Smart Contract”, we will get the following result:
In other words, Corda contract and smart contract are different concepts, they have different purposes and functions:
- Smart Contract: It is an executable code that contains multiple callable functions and has the ability to transfer value. It realizes programmable value and turns the Nakamoto blockchain into a general computation platform.
- Corda Contract: It is a set of ruls mapped from real-world. Although it is a executable code as well, it only has a single, pre-defined interface, and it has no other functions except for verifying transactions.
Although the expressiveness of a corda contract is limited, programmable value is still achievable through the combination of “flow” and “transaction”, such as cascading multiple transactions in a “flow”. Check the official documents for more details.
Born to be Regulated: Observer and Emergency Access
Compared with the other two consortium chains, Corda is arguably born to be regulated from the integration of public key infrastructure (PKI) to the UTXO model that can display the complete state history and transaction context.
Moreover, Corda has some special designs that allow regulation to be involved more actively:
- Observer: Although Corda only allows the parties involved in the transaction to save transaction data, “observers” that do not actually participate in the transaction can obtain the transaction content of their observing parties.
- Emergency Access: This allows certain “specialized nodes” to perform operations such as suspending transactions and correcting wrong transactions, etc. Although it seems a bit contrary to the definition of decentralized ledger itself, it is probably necessary for the financial industry scenario that Corda is dealing with.
Summary
In a nut shell, Corda extends the UTXO model and it does not require a “blockchain” and uses a lighter consensus mechanism. Also, it can realize the programmable value via its unique “flow” design.
Interestingly, the designs seen in Corda can also be found in other distributed ledgers. For example: Holochain also only verifies transactions through the parties involved in the transaction. These technologies outside of the Nakamoto blockchain can actually refer to each other and complement each other, allowing us to have a more complete understanding of distributed ledger technology.
