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.
Bitcoin Dominance at 2-Month High: Disaster for Altcoins
August was a bullish month for altcoin traders as they ranked in profits, forcing Bitcoin dominance to drop below 60% for the first time since the start of the year. However, the altcoin euphoria was shortlived as September brought along the bears.
The end of Q3 wasn’t great for Bitcoin traders, but that was expected as September is usually not a profitable month for Bitcoin. In fact, data shows that Bitcoin has lost more in September than in any other month.
As expected, the Bitcoin effect was seen across boards in the market. Altcoins suffered the most, shredding almost all of the profits accumulated in the previous month.
Bitcoin Eyes $12K
Bitcoin is pushing hard towards the $12k mark. It traded as high as $11,942 for the first time since mid-August.
Analysts believe the trend is the start of a new bull cycle for the leading cryptocurrency considering the coin shielded itself and recovered quickly from the recent negative news, including BitMEX’s charges and OKEx’s withdrawal saga.
Although October has been impressive for Bitcoin, and the coin has since recovered from the bearish move in September, altcoins continue to live in the terrible nightmare from the past month.
October: Another Nightmare For Altcoins
Bitcoin dominance started rising in mid-September after it went as low as 55%. At the time of writing, the cryptocurrency maintains a 60.3% dominance of the entire crypto market while the altcoins struggle with 39.7%.
Even Ether (ETH), the second-largest cryptocurrency, was not spared. In August, the coin traded near the $500 mark, reaching $485 for the first time in two years. In the last two months, Ether lost over 20% of its value, and market dominance dropped from above 15% to 11%.
Now, ETH is exchanging hands at $369 with a 2% loss on the daily chart. However, speculation in the market is that the upcoming ETH 2.0 Phase 0 could provide the needed boost for Ether bulls.
Looking at the top 100, a handful of altcoins have shredded at least 15% of their value on today’s trading session. Some of the most significant losers include Uniswap (-17%), Crypto.com (-25%), Balancer (-19%). Meanwhile, Flexacoin saw a big boost with over 258.11% gains in the last 24 hours.
Crypto.com Integrates PayID Offering 5M Users an Easy and Unique Way to Send & Receive Crypto
HONG KONG, October 19, 2020 — Crypto.com today announced PayID, a universal payment identity developed by the Open Payments Coalition, is now available on the Crypto.com App.
Crypto.com’s 5M+ users can register for a PayID from the Crypto.com app, consolidating complex wallet addresses and accounts into a simple ID that works across any payment network and currency. Users who register for their unique PayID will get an exclusive Crypto.com-branded, easy-to-read ID — such as “yourname$payid.crypto.com — that enables users to send/receive crypto payments from other compatible wallets with just a single ID, easing their ability to connect to 100M+ crypto users worldwide.
PayID solves a key pain point in the crypto payments world, which consists of many closed and complex networks. Participants must manage multiple long and random wallet addresses, increasing the likelihood of erroneous transactions. PayID creates a free, open and common protocol that allows for interoperability between any payment network or currency.
Starting today, Crypto.com is offering early access for select customers to register their unique Crypto.com PayID. To be eligible:
- Stake 10,000 CRO or more in Crypto.com Exchange; or
- Stake 10,000 CRO or more in Crypto.com App
On 2 November 2020 all Crypto.com App users can register their own Crypto.com PayID within the Crypto.com App.
Once registered, users can send crypto from other compatible wallets to the Crypto.com App with just their PayID, instead of a full-length crypto address. At launch, supported cryptocurrencies include CRO, ETH, BTC, XRP and many more ERC20 tokens. Users can also send crypto to other compatible wallets using PayID hosted by other members in the Open Payments Coalition.
Crypto.com was founded in 2016 on a simple belief: it’s a basic human right for everyone to control their money, data and identity. Crypto.com serves over 5 million customers today, providing them with a powerful alternative to traditional financial services through the Crypto.com App, the Crypto.com Card, the Crypto.com Exchange and Crypto.com DeFi Wallet. Crypto.com is built on a solid foundation of security, privacy and compliance and is the first cryptocurrency company in the world to have ISO/IEC 27701:2019, CCSS Level 3, ISO27001:2013 and PCI:DSS 3.2.1, Level 1 compliance. Crypto.com is headquartered in Hong Kong with a 600+ strong team. Find out more by visiting https://crypto.com
Crypto More Popular Than Gold Among Russian Investors: Report
A survey among over 2,000 Russian investors has placed cryptocurrency next to gold in terms of popularity. Moreover, younger investors aged below 30 have displayed significant favoritism towards digital assets.
Crypto Ranks Above Gold Among Russian Investors
According to the study published by the World Gold Council, investors from the world’s largest country by landmass have allocated the most funds into generally accepted as safer instruments such as savings accounts, foreign currencies, real estate, and life insurance.
When asked what sorts of investment tools they had invested in the past 12 months, they placed cryptocurrencies as the fifth most popular asset with 17%. Interestingly, gold came next with 16%.
World Gold Council Director of Central Banks and Public Policy, Dr. Tatiana Fic, commented that gold had been a valuable part of Russia’s history. She explained that the development of the gold mining industry began in 1745 with the discovery of gold in the Urals. In the next 100 years, more than half of the global gold production came from Siberia.
However, she noted that the investment market has declined in interest lately. Dr. Fic reasoned that there’s an evident lack of education, resulting in people steering clear from the bullion. She also claimed that investors fear buying fake or counterfeit gold products.
It’s worth noting that Russia seized purchasing gold earlier this year following half of decade of increased accumulation.
Younger Generations Keen To Experiment With Crypto
WGC’s report confirmed previous narratives that younger generations prefer allocating funds into riskier investment instruments such as digital assets.
“18-to-24-year-olds are much more willing to take risks to get exponential growth, rather than take a long-term view. For example, they are the least likely to have invested in a savings account but are the most likely to have invested in collectibles – and around two-thirds are considering investing in cryptocurrencies.” – the report reads.
The paper highlighted that the growing role of mobile apps linked to investment accounts have made it easier for tech-savvy youth to purchase their preferred assets. Cryptocurrencies lead the way “with nearly 80% being bought exclusively online.”
Although physical gold has been bought mostly offline, the report noted that online investments in gold-backed ETFs and vaulted gold have jumped in the past few years as well.
Blockchain1 month ago
Bitcoin price volatility expected as 47% of BTC options expire next Friday
Blockchain1 month ago
Bitcoin Bouncing From Bull Market Support Points To 2021 As The Year Of Crypto
Blockchain2 months ago
Market Wrap: Bitcoin’s Powell-Induced Price Swing; Ethereum Still High on Gas
Blockchain1 month ago
Ethereum: Is the HODLing in yet?
Blockchain1 month ago
Blockchain Bites: Is DeFi an Inside Deal?
Blockchain1 month ago
Hackers Have Been Trying To Crack Bitcoin Wallet Worth $750 Million But Here’s The Catch
Blockchain1 month ago
YFI Founder Puts Himself Forward for Uniswap (UNI) Delegation Duties
Blockchain3 months ago
Wealthfront Lures Millenials With Crypto Memes and Tactics