Connect with us


R3 Corda: Deep dive and technical review



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.

Introducing blockchains

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.

Transaction rules

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:

  1. 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.
  2. 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.)
  3. 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.

Building blocks

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.

Blockchain 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 – 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.

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.

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.

Taking score

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.

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.

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.




Hackers Have Been Trying To Crack Bitcoin Wallet Worth $750 Million But Here’s The Catch



A bitcoin wallet containing a little over 69,000 BTC is doing the rounds in hacking communities all over the internet. The reason? It’s obvious.

Everyone (read seasoned hackers and self-professed bitcoin wallet crackers) wants to break it open and take it all. Or at least, a slice of the almost $750 million pie. For the last two years, however, no one has been able to ‘strike it lucky.’

Hackers Tried Cracking The 7th Largest Bitcoin Wallet In The World

According to cybersecurity expert Alon Gal, who goes by the handle ‘UnderTheBreach on Twitter, hackers have been trying to break open a bitcoin wallet holding around $720 million worth of BTC (considering today’s rates). However, Gal reported that no one has posted any success regarding the same.

As it so happens, the bitcoin wallet in the discussion has the 7th largest BTC stash in the world.

It Is Now Available Online For Everyone To Try

While some folks have tried breaking in themselves, most of them admitting failure has advertised the wallet on online hacking forums for somebody else to do the job.

You Might Also Like:

Alon revealed this to Vice in a one-on-one chat regarding the matter:

Stealing Bitcoin wallets from victims worldwide is a common goal among cybercriminals. Wallets tend to be protected by strong passwords and in the event that a cybercriminal manages to obtain a wallet and cannot crack the password he might sell it to opportunistic hash crackers who are individuals with a large amount of GPU power

Gal noticed one such advertisement on a popular hacking forum RaidForums. And not just hacking portals, the wallet showed up on BitcoinTalk on June 29 last year. After that, on All Private Keys and then Wallet-dat(dot)net.

But Does It Contain The 69,370 BTC Though?

The bitcoin wallet seems like a tough nut to crack. But the important question to ask is – Does it contain the BTC? Although it has an alphanumeric address, it is quite possible that the ‘wallet.dat’ file is ‘doctored.’ There is a public key available but not the private key.

The founder of Wallet Recovery Services, Dave Bitcoin, said that:

It’s possible to doctor a Bitcoin wallet.dat file to make it seem like it contains a high balance. The wallet file contains pairs of public key & encrypted private key of the addresses it controls. So one could modify the file in a binary editor and change the public key of one of the address pairs to that of a high value BTC address.

It may be a bait to beguile folks into making bitcoin payments for a shot at cracking a wallet that doesn’t actually have any BTC.

Breaking In Could Be Impossible

According to another assumption, cracking open this bitcoin wallet may be outright impossible. But why?

Quite possibly, the wallet is protected by a long, unique, and difficult to crack the password. Apart from this, the wallet.dat file may be encrypted using a combination of AES-256-CBC and SHA-512 algorithms. These are super slow to process, making it all the more difficult to ‘brute force’ them open.

Binance Futures 50 USDT FREE Voucher: Use this link to register & get 10% off fees and 50 USDT when trading 500 USDT (limited – first 200 sign-ups & exclusive to CryptoPotato).

Click here to start trading on BitMEX and receive 10% discount on fees for 6 months.


Continue Reading


Huobi Buysback $24 Million HT

Huobi token price, Sep 2020One of the biggest crypto exchange handling some $2 billion in daily trading volumes has burned 4.872 million Huobi tokens (HT), worth about $24 million. “The month on month burnt…



One of the biggest crypto exchange handling some $2 billion in daily trading volumes has burned 4.872 million Huobi tokens (HT), worth about $24 million.

“The month on month burnt HT has increased by 97%,” they say while the “circulation deflation rate for the month is about 1.63%.”

So the supply is decreasing by 1.63% a month, with Huobi stating their trading volumes have doubled recently.

Some of their profits are meant to go towards this token that has a total supply of 500 million HTs.

A cool 219 million has been burned, with some 100,000 of it destroyed in just the past two months:

Burned Huobi tokens, Sep 2020
Burned Huobi tokens, Sep 2020

The zero address is the ethereum network address. It’s ‘owned’ by the eth nodes, as in the protocol itself, with it not having a private key.

So this 219 million has gone now with it unable to exchange hands any further as the tokens have effectively been destroyed and are now kind of a museum piece.

This burning of tokens is meant to act as a dividend distribution of sorts with that reduced supply leading to a price appreciation in theory provided all else is equal.

There hasn’t been any notable change in the price of Huobi, however, perhaps because it faces much competition from many new tokens that provide governance rights and ownership over dapps.

Uniswap is the latest example, with this being a decentralized exchange that is now to go through token holders votes to set numerous parameters, including how the daily fee revenue of about $1.5 million is to be distributed.

There are two main methods currently. YFI requires staking with only those that lock the token and vote on governance getting the fees.

Somewhat indirectly this locking would benefit those that are not staking as well due to it temporarily reducing supply, but the main reward goes to those that do a bit of work like voting.

The other method was kicked off by Binance with it being more like the traditional stocks buyback where you use the profits to buy the token and take it out of circulation.

That’s done wonders for Binance’s BNB price which has increased by nearly 10x since it launched to a market cap of $4 billion.

With a decentralized dapp, it’s not clear how this buyback can be done in a code based way as in the case of sushi for example, the token holders voted for the buyback, but an individual with custody over the eth carried out the operation.

Theoretically, there’s no reason why the code can’t do the buyback itself with Andre Cronje probably able to write it up within a week.

The code currently gives the fee of 0.3% to Liquidity Providers (LPs), so to set it to ‘buy uni on the uni/eth pool and burn’ shouldn’t be hard.

That would then make this a deflationary token, with it being a proper share ownership of a code based automated business.

Continue Reading


Illicit crypto transactions are getting more attention from the government



The COVID-19 pandemic has forced governments worldwide to focus on bringing blockchain technology to their financial services, along with the needed regulatory upgrades to keep the burgeoning fintech industry clean.

Related: Not like before: Digital currencies debut amid COVID-19

For example, on Sep. 10, Switzerland — a global center for the wealth management industry, housing around $2 trillion or 27% of global offshore wealth — passed a reformed Blockchain Act that includes a new set of laws and regulations to support the growth of blockchain and decentralized finance companies in the country.

Related: Why Switzerland is becoming a “crypto nation” with a flourishing ICO market: Expert take

Furthermore, in a major milestone for the crypto industry, leading travel rule solutions nonprofit Travel Rule Information Sharing Alliance, or TRISA, from Ciphertrace and developer of the world’s first tracing tool for Monero, together with Sygna Bridge from CoolBitX announced their interoperability proof-of-concept, allowing crypto service providers from both platforms to meet the requirements as outlined by the travel rule. It is available to the public on GitHub.

The travel rule was introduced by the Financial Action Task Force in June 2019 and requires financial institutions participating in cryptocurrency transactions to exchange relevant beneficiary and originator Know Your Customer, or KYC, information. As a result, Virtual Asset Service Providers, or VASPs, between the two solutions can communicate compliance data with minimal disruption.

As Michael Ou, CEO of CoolBitX and creator of Sygna Bridge, explained: “In the last few years, several innovative solutions have appeared to help crypto and virtual asset businesses comply with anti-money laundering regulations that are beginning to develop around the world — each addressing the needs of different audiences. At the end of the day, money-laundering and terrorist financing are global issues that require the collaboration between different entities. This all begins with ensuring that the solutions are able to communicate effectively between each other. By adapting industry standards such as the IVMS101 and building tools to ensure correct translation and connectivity, Sygna Bridge and TRISA are working together to ensure that the cryptocurrency industry is growing and maturing in a positive direction.”

John Jefferies, chairman of TRISA, added:

“Achieving global interoperability for Travel Rule compliance across jurisdictions is vital for a successful sunrise phase. We are pleased to enable message interoperability and extend mutual VASP authentication in this Travel Rule proof of concept.”

According to statistics released by the United States Office on Drugs and Crime, up to $2 trillion is laundered on the global market annually, which bypasses the latest cryptocurrency KYC measures. Financial institutions could be missing up to 90% of cryptocurrency-related transactions, as they overlook lesser-known digital asset exchanges, according to the latest report by CipherTrace.

Until they are eventually caught by United States law enforcement, criminals prefer using cryptocurrency tumblers or cryptocurrency mixing services when paying for illicit goods and services that are transmitted with no oversight by governments or central banks, thereby obscuring the trail back to the fund’s original source.

Related: Illicit uses of cryptocurrency gaining attention around the world: Expert take

Nearly a month after announcing the largest-ever seizure of cryptocurrency assets used by terrorist organizations in a multi-agency investigation conducted alongside the Federal Bureau of Investigations, Department of Homeland Security Investigations and Internal Revenue Service Criminal Investigation, the U.S. Department of Justice showcased the results of a five-year operation targeting Mexican drug cartels on Sept. 3.

Robert Murphy, the Drug Enforcement Administration’s special agent in charge at Atlanta division, said:

“We have a Mexican drug cartel who initially came to our attention through U.S. Fish and Wildlife when they smuggled over 900 kilos of cocaine with frozen sharks.”

The indictment charged 12 defendants and two businesses with mail and wire fraud conspiracy, conspiracy to possess with intent to distribute controlled substances, and money laundering conspiracy. The charges carry potential penalties of up to life in federal prison with no parole.

A week later, on Sept. 10, the DEA announced the results of a six-month operation, “Crystal Shield,” again targeting Mexican drug cartels operating major methamphetamine transportation hubs in the United States. The operation led to “nearly 1,840 arrests and the seizure of more than 28,560 pounds of methamphetamine, $43.3 million in drug proceeds, and 284 firearms.” The U.S. Attorney General William Barr said more than 60 Mexican cartel figures have been extradited this year, and more are expected. Barr added:

“Unfortunately Covid has intervened and has tempered a lot of the progress we had been making, reduced our momentum.”

These U.S. Federal agencies have bolstered their cryptocurrency oversight and enforcement efforts for 2021 — which begins in October of 2020 — with millions of dollars in new funding to shore up national and international cryptocurrency investigations.

Related: The US plan to monitor illegal crypto activities more sufficiently

The IRS is already spending some of that funding on a bounty of up to $625,000 to anyone who can crack untraceable privacy coins.

The IRS’s federal whistleblower program

It should be noted that the IRS has a federal whistleblower law program for informants (including foreigners) who provide information that leads to the collection of taxes, whether from undisclosed fiat or cryptocurrency, and offering up to 30% of the resulting tax and penalty revenue.

At the direction of Senator Charles Grassley, Dean Zerbe, a partner at law firm ZMFF&J, was responsible for the modern IRS whistleblower law, which was signed into law in 2006. He also established the IRS Whistleblower Office and created an award program for tax whistleblowers while he was senior counsel and tax counsel for the chairman of the Senate Finance Committee, from 2001 to 2008.

This legislation led to the famous UBS tax evasion case that reverberated around the world. UBS, Switzerland’s largest bank, admitted to helping Americans dodge taxes, and it agreed to pay the U.S. government $780 million. In a departure from its own legal standards, the Swiss government also divulged banking client secrets. Alarmed by the affair, many U.S. depositors pulled their money out of UBS, and thousands of tax-dodging Americans came clean with the IRS. The IRS awarded $104 million to the banker-turned-whistleblower who helped the government uncover the massive scheme, which was the largest bounty ever granted to a single whistleblower in the U.S. at the time.

As Dean Zerbe explained:

“The IRS released its 2019 annual report on the whistleblower program — showing over $616 million dollars brought into the Treasury thanks to the work of tax whistleblowers speaking out about tax evasion. […] The trend is clear that the IRS has embraced the modern mandatory tax whistleblower program created by my old boss Chairman Charles Grassley (R-IA) — and it is honest taxpayers who have most benefited.”

The report makes note that whistleblowers can be paid for FBAR violations (undeclared foreign bank accounts) as well as criminal fines.

However, “the top reason — 51%! — whistleblower submission is rejected is because the submission is not specific. […] The IRS does not want submissions that are speculative. The IRS wants and welcomes submissions that are grounded — particularly those coming from credible whistleblowers — containing known facts, dealing with specific taxpayers and ideally, with documents in hand and involving recent/current tax evasion,” pointed out Dean Zerbe.

The views, thoughts and opinions expressed here are the author’s alone and do not necessarily reflect or represent the views and opinions of Cointelegraph.

Selva Ozelli, Esq., CPA is an international tax attorney and certified public accountant who frequently writes about tax, legal and accounting issues for Tax Notes, Bloomberg BNA, other publications and the OECD.


Continue Reading