A detailed look at the non-blockchain blockchain
As time goes on, the blockchain world has been separating into two distinct parts. On one hand, public blockchains with their associated cryptocurrencies have enjoyed a remarkable recent comeback, minting many a multi-millionaire. On the other hand, use of permissioned or enterprise blockchains has been growing quietly but steadily, seeing their first live deployments across multiple industries during 2017.
One interesting question to consider is the appropriate level of similarity between these two types of chain. Both implement a shared database using peer-to-peer networking, public–private key cryptography, transaction rules and consensus mechanisms that can survive malicious actors. That’s a great deal of common ground. Nonetheless, public and private blockchains have different requirements in terms of confidentiality, scalability and governance. Perhaps these differences point to the need for radically divergent designs.
The Corda platform, developed by the R3 banking consortium, adopts a clear stance on this question. While some aspects were inspired by public blockchains, Corda was designed from scratch based on the needs of R3’s members. 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.
My goal in this piece is to explain these differences and discuss their implications, for good and bad. Actually, good and bad is the wrong way to put it, because the more interesting question is “Good and bad for what?” This article is far from short. But by the end of it, I hope that readers will gain some understanding of the differences in Corda and their consequent trade-offs. Corda is important because its design decisions bring many of the dilemmas of enterprise blockchains into sharp relief.
One last thing before we dive in. As the CEO of the company behind MultiChain, a popular enterprise blockchain platform, why am I writing in such depth about a supposedly competing product? The standard reason would be to argue for MultiChain’s superiority, but that’s not my motivation here. In fact, I do not see Corda and MultiChain as competitors, because they are fundamentally different in terms of design, architecture and audience. Corda and MultiChain compete in the same way as cruise liners and jet skis – while both transport people by sea, there are almost no real-world situations in which both could be used.
On a more personal note, I’ve learned a great deal from Corda’s technical leadership over the past few years, whether through meetings, correspondence or their public writings, much of which occurred before they joined R3. Some of my interest in Corda stems from the respect I have for this team, and for this reason alone, Corda is worth studying for anyone seeking an understanding of the distributed ledger field.
In order to understand Corda, it’s helpful to start with conventional blockchains. The purpose of a blockchain is to enable a database or ledger to be directly and safely shared by non-trusting parties. This contrasts with centralized databases, which are stored and controlled by a single organization. A blockchain has multiple “nodes”, each of which stores a copy of the database and can belong to a different organization. Nodes connect to each other in a dense peer-to-peer fashion, using a “gossip protocol” in which each node is constantly telling its peers everything it learns. As a result, any node can rapidly broadcast a message to the entire network via many alternative paths.
A database, whether centralized or blockchain-powered, begins in an empty state, and is updated via “transactions”. A transaction is defined as a set of database changes which are “atomic”, meaning that they succeed or fail as a whole. Imagine a database representing a financial ledger, with one row per account. A transaction in which Alice pays $10 to Bob has three steps: (1) verify that Alice’s account contains at least $10, (2) subtract $10 from Alice’s account, and (3) add $10 to Bob’s account. As a basic requirement, any database platform must ensure that no transaction interferes with another. This “isolation” is achieved by locking the rows for both Alice and Bob while the payment is under way. Any other transaction involving these rows must wait until this one is finished.
In a blockchain, every node independently processes every transaction on its own copy of the database. Transactions are created anywhere on the network and automatically propagated to all other nodes. Since the organizations running nodes may have different (or even conflicting) interests, they cannot trust each other to transact fairly. Blockchains therefore need rules which define whether or not a particular transaction is valid. In a shared financial ledger, these rules prevent users from spending each other’s money, or conjuring funds from thin air.
Along with the rules that determine transaction validity, blockchains must also define how transactions will be ordered, since in many cases this ordering is critical. If Alice has $15 and tries to send $10 to both Bob and Charlie in two separate transactions, only one of these payments can succeed. While we might like to say that the first transaction takes precedence, a peer-to-peer network has no objective definition of “first”, since messages can arrive at different nodes in different orders.
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. To go back to Alice’s payment to Bob, 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’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 Charlie. 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.
A blockchain is literally a chain of blocks, in which every block links to the previous one via a “hash” that uniquely identifies its contents. Each block contains an ordered set of transactions which must not conflict with each other or with those in previous blocks, as well as a timestamp and some other information. Just like transactions, blocks propagate rapidly across the network and are independently verified by every node. Once a transaction appears in a block, it is “confirmed”, leading nodes to reject any conflicting transaction.
Who is responsible for creating these blocks, and how can we be sure that all nodes will agree on the authoritative chain? This question of “consensus algorithms” is a huge subject in itself, filled with wondrous acronyms such as PoW (Proof of Work), PBFT (Practical Byzantine Fault Tolerance) and DPoS (Delegated Proof of Stake). We won’t be getting into all that here. Suffice to say that permissioned blockchains for enterprises use some kind of voting scheme, where votes are granted to “validator nodes” who are collectively responsible. The scheme ensures that, so long as a good majority of validator nodes are functioning correctly and honestly, transactions will enter the chain in a (close to) fair order, timestamps will be (approximately) correct, and confirmed transactions cannot be subsequently reversed.
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 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’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.
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 – an asset identifier such as GOOG or USD, the quantity owned, and 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: scalability, confidentiality and 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.
But let’s put scalability aside, since it can ultimately be solved using expensive computers and clever engineering. 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. The difficulty of this approach was recently highlighted by SWIFT’s reconciliation proof-of-concept, which estimated that over 100,000 channels would be needed in production. That’s 100,000 islands between which assets cannot be directly moved.
In data-only use cases, where transactions do not consume data in inputs, the confidentiality problem can be sidestepped by encrypting or hashing the data in outputs, and delivering the decryption key or unhashed data outside of the chain. But for a transaction whose inputs consume other transactions’ outputs, every node has to see those inputs and outputs in order to validate the transaction. While advanced cryptographic techniques such as confidential assets and zero knowledge proofs have been developed to partially or completely solve this problem for financial ledgers, these impose a significant performance burden and/or cannot be generalized to any correctness rule.
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.
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.
While every state can have a different notary, all of the states consumed by a particular transaction must be assigned to the same one. This avoids issues relating to deadlocks and synchronization, which should be familiar for those with distributed database experience. Let’s say Alice and Bob agree to exchange Alice’s $10 for Bob’s £7. The transaction for this exchange must be signed by the notaries of both states, but which one goes first? If Alice’s notary signs but Bob’s fails for some reason, then Alice will be left with an incomplete transaction and can never use her $10 again. If Bob’s signs first then he is similarly exposed. While we might like notaries to simply work together, in practice this requires mutual trust and the use of a consensus protocol, complications which Corda’s designers chose to avoid.
If states with different notaries are required as inputs to a single transaction, their owners first execute special “notary change” transactions, which move a state from one notary to another, changing nothing else. So when parties are building a transaction with multiple inputs, they must first agree on the notary to be used, and then perform the notary changes necessary. While the developer in me felt a small twinge of pain when reading about this workaround, there’s no reason why it won’t work so long as notaries play along.
It should also be clarified that, while each notary is a single logical actor in terms of signing transactions, it need not be under the control of a single party. A group of organizations could run a notary collectively, using an appropriate consensus protocol in which a majority of the participants are needed to generate a valid signature. This would prevent any single malicious party from undermining uniqueness by signing transactions that conflict. In theory, we could even allow every node in the network to participant in this kind of shared notarization, although in that case we’d be more-or-less back to a conventional blockchain.
Let’s recap the 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. My goal in this article is to focus on that which makes Corda unique.
So does Corda live up to its promise? Does it solve the scalability, confidentiality and interoperability problems of blockchains? And in making its particular choices, how much of a price does Corda pay?
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.
All in the breeding
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.
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 far 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.
A strange animal
Putting scalability, confidentiality, interoperability and disintermediation together, it’s hard to reach a simple verdict on the Corda alternative. Overall, from the perspective of this blockchain platform developer, it seems, well… compelling but strange. 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.
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.
Looking at Corda in this way, we can see how it 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.
I’m far from being a banker, but to me this all sounds rather promising. And perhaps Corda could equally well be applied to other industries with complex custodial structures, such as insurance or shipping. While Corda’s design may not provide the full disintermediation of a blockchain, it proposes a powerful transformation for industries in which intermediaries play an essential role.
Once we go down this line of thinking, a question inevitably arises: If we’re already trusting notaries with the life-and-death job of verifying uniqueness, why not rely on them for correctness and authorization as well? Corda already has the notion of a “validating notary”, which fully verifies transactions before adding its signature. Instead of regular Corda nodes downloading and checking their transactions’ ancestors, why not just ask a notary instead? This could help with scalability and confidentiality, since most nodes would see no transactions other than their own. We might even suggest that a network’s notaries fully trust each other, so there’s no need to worry about ancestors. Each state’s notary could vouch for its validity, verifying only the transaction that created it with other notaries’ help.
Let Corda be Corda
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. I have no idea whether Corda will ultimately succeed or fail, because I don’t know its real-world costs and benefits compared to the current way of doing things. But no matter what happens in the future, it is certainly worth studying in terms of philosophy and design.
As for MultiChain, we’re taking a different approach. To steal a line from The West Wing, we’re determined to “let blockchain be blockchain”. Blockchains are what they are, and we have no plans to turn them into something different. As the data infrastructure for a shared application, a blockchain represents a specific trade-off when compared to a centralized database – a gain in disintermediation at the cost of reduced confidentiality. And we’re working hard on making MultiChain 2.0 the best possible blockchain platform for application developers to use.
Please post any comments on LinkedIn.