The Corda platform, developed by the R3 banking consortium, tries to balance traits of permissioned and public blockchains within a network. While some aspects were inspired by public blockchains, Corda was designed from scratch based on the needs of R3’s members and leans far more to the permissioned system. Indeed, although R3 still uses the word “blockchain” extensively to help market their product, Corda has no chain of blocks at all. More than any other “distributed ledger” platform I’m aware of, Corda departs radically from the architecture of conventional blockchains.
This article addresses the differences between Corda and conventional blockchains and their consequent trade-offs. Corda is important because its design decisions bring many of the dilemmas of enterprise blockchains into sharp relief.
Inside conventional blockchains
In order to understand Corda, it’s helpful to understand conventional blockchains; the purpose of which is to enable a database or ledger to be directly and safely shared by non-trusting parties.
In a general sense, the information in any database is separated into records or “rows”, and a transaction can do three different things: delete rows, create rows, and/or modify rows. These can be reduced further to two, since modifying a row is equivalent to deleting that row and creating a new one in its place. For example, if Alice was to pay Bob $10 from her $15 account, her row containing $15 is deleted, and two new rows are created – one containing $10 for Bob and the other with $5 in “change” for Alice.
Following Bitcoin (available on Coinbase)’s and Corda’s terminology, we denote the rows deleted by a transaction as its “inputs”, and those created as its “outputs”. Any row deleted by a transaction must have been created by a previous transaction. Therefore each transaction input consumes (or “spends”) a previous transaction’s output. The up-to-date content of the database is defined by the set of “unspent transaction outputs” or “UTXOs”.
In a blockchain, a transaction is valid if it fulfills the following three conditions:
Correctness. The transaction must represent a legitimate transformation from inputs to outputs. For example, in a financial ledger, the total quantity of funds in the inputs must match the total in the outputs, to prevent money from magically appearing or disappearing. The only exceptions are special “issuance” or “retirement” transactions, in which funds are explicitly added or removed.
Authorization. The transaction must be authorized by the owner of every output consumed by its inputs. In a financial ledger, this prevents participants from spending each other’s money without permission. Transaction authorization is managed using asymmetric (or public–private key) cryptography. Every row has an owner, identified by a public key, whose corresponding private key is kept secret. In order to be authorized, a transaction must be digitally signed by the owner of each of its inputs. (Note that rows can also have more complex “multisignature” owners, for example where any two out of three parties can authorize their use.)
Uniqueness. If a transaction consumes a particular output, then no other transaction can consume that output again. This is how we prevent Alice from making conflicting payments to both Bob and a third party. While the transactions for both of these payments could be correct and authorized, the uniqueness rule ensures that only one will be processed by the database.
In a conventional blockchain, every node checks every transaction in terms of these three rules. Later on, we’ll see how Corda divides up this responsibility differently.
Building blocks
Before discussing some of the challenges of blockchains, I’d like to clarify three additional points. First, while I am using a financial ledger by example throughout this piece, the input–output model of transactions supports a much broader variety of use cases. Each row can contain a rich data object (think JSON) containing many different types of information – indeed, Corda uses the word “state” rather than “row” for this reason. Richer states change nothing fundamental about transaction rules: correctness is still defined in terms of inputs and outputs, authorization is still required for every input, and uniqueness ensures that each output can only be spent once.
Second, there are many blockchain use cases in which rows are only created in the database, and never deleted. These applications relate to general data storage, timestamping and notarization, rather than maintaining some kind of ledger which is in flux. In these data-only applications, transactions add data in their outputs but consume none in their inputs, allowing the rules for correctness, authorization and uniqueness to be simplified. Although data-only use cases are an increasing focus of our own development at MultiChain, I only mention them in passing here, since Corda was clearly not designed with them in mind.
Finally, it’s worth noting that some blockchain platforms do not use an input–output model. Ethereum (available on Coinbase) presents an alternative paradigm, in which the chain controls a virtual computer with a global state that is managed by “contracts”, and transactions do not connect to each other explicitly. A discussion of Ethereum (available on Coinbase)’s model in permissioned blockchains is beyond our scope here, but see this article for a detailed explanation and critique. One key advantage of the input–output paradigm is that most transactions can be processed in parallel and independently of each other. This property is crucial for Corda, as we’ll see later on.
Blockchain’s challenges
Let’s imagine that the world’s banks created a shared ledger to represent the ownership, transfer and exchange of a variety of financial assets. In theory, this could be implemented on a regular blockchain, as described above. Each row would contain three columns: 1) an asset identifier such as GOOG or USD 2) the quantity owned and 3) the owner’s public key. Each transaction would transfer one or more assets from its inputs to its outputs, with special cases for issuance and retirement.
Every bank in the network would run one or more nodes which connect to the others, propagating and verifying transactions. Senior members would act as validators, with the collective responsibility of confirming, ordering and timestamping transactions. Any validator’s misbehavior would be visible to all the nodes in the network, leading to censure, banishment and/or legal proceedings. With all this in place, any financial asset could be moved across the world in seconds, with the rules of correctness, authorization and uniqueness guaranteeing the ledger’s integrity.
What’s wrong with this picture? Actually, there are three problems: 1) scalability, 2) confidentiality and 3) interoperability. The issue of scalability is simple enough. Our proposed interbank blockchain would require every member to verify, process and store every transaction performed by every bank in the world. Even if this would be technically feasible for the largest financial institutions, the cost of computation and storage would create a significant barrier for many. Surely we’d prefer a system in which participants only see those transactions in which they are immediately involved.
A more fundamental issue is confidentiality. While it might sound utopian for every transaction to be visible everywhere, in the real world such radical transparency is a non-starter in terms of competition and regulation. If J.P. Morgan and HSBC exchange a pair of assets, they’re unlikely to want Citi and the Bank of China to see what they did. If the transaction was conducted on behalf of these banks’ customers, it could be illegal for them to expose it in this way.
One proposed solution to the problem of confidentiality is “channels”, as implemented in Hyperledger Fabric. Each channel has certain members, who are a subset of the nodes in the network as a whole. A channel’s transactions are visible only to its members, so that each channel effectively acts as a separate blockchain. While this does help with confidentiality, it also undermines the entire point of the exercise. Assets cannot be moved from one channel to another without the help of a trusted intermediary which is active on both.
Finally, let’s talk about interoperability. In an ideal world, every bank would immediately join our global blockchain on the day it was launched. In reality however, multiple blockchains would be adopted by different groups of banks, based on geography or pre-existing relationships. Over time, a member of one group might wish to start transacting with a member of another, by transferring an asset between chains. Just as with channels, this can only be achieved with the help of a trusted intermediary, defeating the blockchain’s purpose.
Corda aims to solve these interrelated problems of scalability, confidentiality and interoperability via a radical rETHink of how distributed ledgers work.
Corda’s partial view
The fundamental difference in Corda is easy to explain: Each node only sees some, rather than all, of the transactions processed on the network. While a single logical and conceptual ledger is defined by all these transactions, no individual node sees that ledger in its entirety. To draw a comparison, at any point in time, every dollar bill in the world is in a particular place, but nobody knows where they all are.
So which transactions does a Corda node see? First of all, those in which it is directly involved, because it owns one of that transaction’s inputs or outputs. In a financial ledger, this includes every transaction in which a node is sending or receiving funds. Let’s say Alice creates a transaction which consumes her $15 in an input and has two outputs – one with $10 for me, and the other with $5 in “change” for her. After Alice sends me this transaction, I can check it for correctness and authorization, verifying that the inputs and outputs balance and that Alice has signed.
However, this transaction on its own is not enough. I also need to verify that Alice’s $15 input state really exists, and she didn’t just make it up. That means I need to see the transaction which created this state, and check it for correctness and authorization as well. If this previous transaction, which sent Alice $15, has a $10 input belonging to Denzel and another $5 input from Eric, then I must also verify the transactions which created those. And so on it goes, all the way back to the original “issuance” transaction in which the asset was created. The number of transactions I need to verify will depend on how many times the assets have changed hands and the extent of backwards branching.
Since Corda nodes don’t automatically see every transaction, how do they obtain the ones they need? The answer is from the sender of each new transaction. Before Alice creates a transaction consuming her $15, she must already have verified the transaction in which she received it. And since Alice must have applied the recursive technique above, she will have a copy of every transaction needed for this verification. Bob simply requests these transactions from Alice as part of their interaction. If Alice doesn’t respond appropriately, Bob concludes that Alice is trying to trick him, and rejects the incoming payment. In the case where Bob is sent a new transaction whose inputs have multiple owners, he can obtain the necessary proofs from each.
Introducing notaries
So far we’ve explained how Bob can verify the correctness and authorization of an incoming transaction, including recursively retracing its inputs’ origins. But there is one more rule we need to think about: uniqueness. Let’s say Alice is malicious. She can generate one transaction in which she pays $10 to Bob, and another in which she pays the same $10 to Charlie. She can send these transactions to Bob and Charlie respectively, along with a full proof of correctness and authorization of each. While both transactions conflict with each other by consuming the same state, there is no way for Bob and Charlie to know this.
Conventional blockchains solve this problem by every node seeing every transaction, making conflicts easy to detect and reject. So how does Corda, with its partial transaction visibility, address the same problem? The answer is with the help of a “notary”. A notary is a trusted party (or parties working togETHer) which guarantees that a particular state is only consumed once. Each state has a specific notary, which must sign any transaction in which that state is consumed. Once a notary has done this, it must not sign another transaction for the same state. Notaries are the network’s guardians of transaction uniqueness.
Recap: Key differences between Corda and conventional blockchains
In Corda, there is no unified blockchain which contains all of the transactions confirmed. Nodes only see those transactions in which they are directly involved, or upon which they depend historically. Nodes are responsible for checking transaction correctness and authorization but rely on trusted notaries to verify uniqueness.
Of course, there is a lot more to Corda than this: the use of digital certificates to authenticate identity; “network maps” to help nodes find and trust each other; per-state “contracts” which define correctness from each state’s perspective; a deterministic version of the Java Virtual Machine which executes these contracts; “flows” which automate transaction negotiations; “time windows” which restrict transactions by time; “oracles” that attest to external facts and “CorDapps” which bundle many things togETHer for easy distribution. While each of these features is interesting, equivalents for all can be found in other blockchain platforms.
Does Corda solve the scalability, confidentiality and interoperability problems of blockchains?
More scalable, sometimes
Let’s start with scalability. Here, Corda’s advantage appears clear, since nodes only see some of the transactions in a network. In a regular blockchain, the maximum throughput is constrained by the speed of the slowest node in processing transactions. By contrast, a Corda network could process a million transactions per second, while each node sees just a tiny fraction of that. Scalability extends to notaries as well, since the task of signing transactions for uniqueness can be spread between many different notaries, each of which is responsible for a small proportion of the network’s states.
Having said that, there is one situation in which Corda performs far worse than a blockchain. This occurs when a node receives a new transaction which depends on many other transactions it has not seen before. Imagine a highly liquid asset that was issued 10 years ago, and changes hands about every five minutes. The path from any new transaction back to this asset’s issuance will be over a million transactions long. When a node receives this asset for the first time, it must retrieve these million transactions from the sender and verify each one in turn. At a (fairly optimistic) rate of 1000 transactions per second, there would be a 17 minute delay before the recipient could send the asset on – clearly too long for somETHing so liquid.
Why don’t blockchains suffer from this problem? Because nodes see and verify every transaction as it occurs, they are constantly updating the state of the ledger, and know exactly who owns every asset at the present time. Even if a node has never held a particular asset before, it can instantly verify the transaction in which it receives it, and then immediately send it on. To put it another way, blockchain nodes have to verify transactions that might not be relevant to them, but in so doing, they prepay the cost of checking any future transaction that might come in. While Corda nodes are less busy overall, they run the risk of needing to do a huge amount of work at a moment’s notice. There’s nothing scalable about that.
Somewhat more confidential
Let’s move on to confidentiality. In Corda, nodes only see some of a network’s transactions, which undeniably means better privacy than conventional blockchains. NonETHeless, Corda is far from solving the confidentiality problem, because nodes still see some transactions that are none of their business. To take a simple example, if Alice pays Bob $10, then Bob sends that $10 on to Charlie, Charlie’s node has to be shown the transaction between Alice and Bob, even though it doesn’t involve him. At the time that Alice paid Bob, she had no way of knowing who might see this transaction in future, and anyone might be sent it at any time.
To be fair, Corda’s developers are aware of this problem, and discuss it in chapter 15 of their Technical White Paper. The paper suggests simple strategies such as using multiple public keys per entity or reducing traceability by returning assets to issuers for reissuance (similar to cryptocurrency “coin mixers”). It also mentions more advanced future possibilities such as using Tor-like anonymization networks to hide participants’ IP addresses and leveraging zero knowledge proofs or Intel’s secure enclaves to validate transactions without revealing their contents. While all of these suggestions are valid, they can also be applied to regular blockchains using the input–output model, and indeed have been in cryptocurrencies such as Dash, Zcash and Verge. So Corda’s only unique advantage in terms of confidentiality remains its reduced transaction visibility – an incomplete solution at best.
The Corda family tree
To better understand Corda’s scalability and confidentiality advantage, we should note how this depends on the density and overlap of the relationships between transactions. Imagine a “family tree” of the transactions performed in a network, in which each transaction’s parents are the previous ones on which it immediately depends. Specifically, when one transaction’s output is consumed by another’s input, we draw an arrow representing the relationship from parent to child. Transactions can have any number of parents and children, although in most cases we’d expect just a few.
Given this family tree, we define the ancestors of a transaction as its parents, grandparents, great-grandparents, and so on. Our tree’s “ADAm and Eve” are the issuance transactions which created assets and have no parents of their own. As in regular family trees, two transactions cannot be ancestors of each other. In formal computer science terms, this is a directed acyclic graph or DAG, in which ancestry is defined as the transitive closure of the parent relation.
Recall that when a Corda node processes a transaction, it must download and verify all of that transaction’s ancestors, apart from those it has seen before. So if the family tree is deep, new incoming transactions may have a large number of ancestors that need to be verified, triggering Corda’s scalability problem. In addition, if the family tree contains a high degree of interbreeding, a new transaction’s ancestors might include many or most past transactions in the network. In this case, Corda will provide little advantage in terms of privacy.
By contrast, if the family tree of transactions is shallow, and contains many disconnected islands that do not interact with each other, Corda’s advantages come to the fore. Nodes will never need to verify a large number of transactions at once, and can be kept in the dark about the majority of transactions which are unrelated to their own. If used as a financial ledger, we might say that Corda is ideal for highly fragmented markets whose assets rarely change hands.
Interoperability for the win
Here is one area in which Corda truly shines. Imagine two separate Corda networks, with different sets of assets and participants. At some point a participant in one network wants to send an asset to someone in the other. Unlike conventional blockchains, there is no expectation that a node will have verified all past transactions, so the node receiving this new asset will experience nothing unusual. When the transaction comes in, it simply requests and verifies the relevant history, with no awareness that this is from a “separate network”. To stretch a cliché, we might say that there are no strangers in Corda – just friends who have not yet met.
In reality, things aren’t quite that simple. Any Corda node explicitly decides which notaries to trust, since a misbehaving notary can cause financial mayhem. In addition, nodes need a “certificate” granted by a “doorman” to connect to other nodes in a network, since we can’t allow random members of the public to start connecting to nodes and wasting their resources. So before a node on one network can start requesting and verifying transactions from another network, it will need to add to its list of trusted notaries and obtain the appropriate certificate. While this does involve some manual configuration and administration, it is the minimum that can be expected for a system of this nature. Overall, it’s fair to conclude that interoperability is Corda’s big win over conventional blockchains.
Reintermediation
It’s time to talk about disintermediation, the elephant in Corda’s room. In the context of blockchains, disintermediation means that every participant can verify every transaction for themselves, without depending on the good behavior of third parties. In my view, disintermediation is the core advantage of blockchains over centralized databases, in which all participants fully depend on that database’s owner. If the participants in a network have an intermediary they can rely on, and there is no business or regulatory case for disintermediation, then there’s no point in using a blockchain. Centralized databases are faster and more efficient, and avoid the issue of transaction confidentiality.
So do the participants in a Corda network achieve disintermediation? Well, yes, yes and yes but no. For transaction delivery, Corda ticks the box, since the nodes involved in a transaction talk directly to each other. In terms of correctness and authorization, it’s also in good shape, since each node is able to check these properties for itself. However, when it comes to verifying transaction uniqueness, Corda fails the disintermediation test. Nodes cannot confirm uniqueness for themselves, since they do not see every transaction in the network, and the task is outsourced to trusted notaries.
Corda participants are at the mercy of notaries in a number of ways. First, a notary may refuse to sign a transaction, even if its inputs consume outputs that have never been used before. In a financial ledger, this prevents someone from sending or exchanging their assets. Second, a notary could sign two conflicting transactions which consume the same output, leading two parties to believe they received the same thing. As both recipients of the duplicate asset send or exchange it in further transactions, the contagion spreads, and the integrity of the entire ledger could soon be undermined. Finally, a notary may refuse to sign a “notary change” transaction to transfer a state to a competitor, effectively holding the asset owner hostage. For a transaction involving states with different notaries, it’s fair to say that Corda introduces more intermediation than a centralized database, because several third parties are in control.
To put this risk in perspective, it’s worth recalling that Corda notaries need not be controlled by a single organization. They can also consist of a group of nodes running a consensus algorithm that can tolerate bad actors. In this case, a notary will work fine so long as most of its member nodes are following the rules. On the surface, this sounds rather like a blockchain, which depends on a majority of validators behaving well. However in Corda the risks are significantly higher. The worst a cabal of blockchain validators can do is prevent some transactions from being confirmed. A malicious Corda notary can also sign conflicting transactions, sending the ledger into an inconsistent abyss.
Custodian 2.0
But I prefer to adopt a more positive approach. Instead of focusing on the comparison with blockchains, we can view Corda as a major technical upgrade to the financial status quo. Simply replace the word “notary” with “custodian”, and it all falls into place rather neatly. (A custodian is a financial institution that holds assets on others’ behalf.) Yes, notaries are intermediaries, who can both block transactions and allow conflicts to occur, but this is true of today’s custodians as well. A “notary change transaction” can be seen as the transfer of assets from one custodian to another. And Corda transactions are signed by just one notary for the same reason that we like asset exchanges to occur in one place – to prevent either party being out of pocket.
How Corda improves on the traditional custodial model:
It defines a standard computational paradigm and format for expressing financial assets and other contractual commitments.
It provides open source software for interpreting and executing these commitments, guaranteeing that transacting parties and custodians agree on the outcome of every transaction.
Complex multiparty custodians that protect against abuse can be created (using software only!) by leveraging fault tolerant consensus algorithms.
A standard process (“notary change”) is defined for the transfer of assets between custodians, and no custodian is allowed to refuse.
Custodians cannot use an asset under their custody without the owner’s consent, since transactions must also be signed by their inputs’ owners.
Conclusion
Designed to solve the key problems of scalability and confidentiality, Corda’s solutions are incomplete, and greatly depend on the shape of the transaction “family tree”. Yet in order to achieve these partial victories, Corda loses a core property of blockchains – the removal of transaction intermediaries. While Corda undoubtedly excels at interoperability, is that really enough?
If we wanted to be skeptical, we might say that Corda’s team was set an impossible task – to design a flavor of blockchain that would suit the banks funding R3. But the key benefit of blockchains over centralized databases is disintermediation, which comes at the price of reduced confidentiality. How could this trade-off make sense for financial institutions who make money by acting as intermediaries, and are highly sensitive about privacy? Viewed in this light, one might eulogize Corda as a heroic but ultimately unsatisfactory compromise between the desire of R3’s members to do somETHing blockchainy, and the commercial and regulatory constraints under which they exist.
All this takes us back to where we started: Corda isn’t really a competitor for conventional blockchains, MultiChain included. Corda is Corda – an interesting new type of distributed ledger, which has been optimized for the needs of those who are funding it.
– Gideon Greenspan is the CEO of Coin Sciences, the company behind MultiChain, an enterprise blockchain platform