This post will explore how transactions will be validated using distributed ledger technology. It will also provide some use cases around who those transaction validators may be, and what that would look like. First off, transaction validation will be different from the bitcoin blockchain because proof of work will not be used. The features of a private blockchain network are:
- Peer to peer: transfer assets directly between parties who control the assets.
- No bitcoin currency: networks are built for specific markets and can issue and transfer any asset.
- No mining: transactions are ordered by trusted parties that form a ‘federation’, or the nodes on a distributed ledger.
- Fast: confirmation in seconds.
- Scalable: thousands of transactions per second.
Financial institutions don’t want public blockchains
This is no longer a debate. Tim Swanson, director of market research from R3 CEV, wrote a paper called, ‘Watermarked tokens and pseudonymity on public blockchains‘, citing the reasons why this is so. Tim puts it succinctly here:
There are at least three identifiable reasons that financial organizations looking to use some kind of public blockchain should be wary of a watermarked approach:
- the built-in security system inherited from bitcoin and other proof-of-work-based blockchains is not exportable in a regulated financial settlement setting (through a distortion of incentives)
- the lack of legal settlement finality
- the regulatory risks that a watermarked approach introduces.
This paper prefers to use the term watermarked token to encompass two types of system: 1) Colored coins, and 2) Embedded consensus systems, which use their own proprietary metacoin.Note: A metacoin is a coin that’s launched on top of another blockchain as a ‘meta’ layer.
I highly recommend reading this paper for deep insights into this issue. The world of public blockchains was invented so parties who don’t know each other and don’t trust each other could transact. The financial world operates in a very different manner. The parties must know and trust each other and be identified. When parties can trust each other, there’s no need for the inefficiencies associated with public blockchains in the form of mining and solving the ‘double spend’ problem. (This occurs if two transactions attempt to spend the same output, only one of those transactions will be accepted.) Without mining, one can simply validate the transactions and add to the chain by creating hash functions regardless, and forming blocks. A private blockchain for the most part behaves in the same manner as a public blockchain.
One of the main differences comes from the transaction validators, who need to be onboarded and accredited/trusted to join the ledger. Their identity is known to everyone. This actually adds an extra layer of security because if a node performs a malicious act, they can be persecuted and ejected from the network. As opposed to a public blockchain network, the transaction validators in a private blockchain are not incentivized in the form of tokens (money) but rather in having the benefit of being a part of the ledger and being able to read data they consider valuable. This post will explore this issue further, because perhaps there’s a role for disinterested/neutral parties to be involved as the transaction validators so there’s no conflict of interest. For their services, perhaps some form of payment will be necessary. That payment would not be in the form of cryptocurrency token, since with a private blockchain the assets that are being exchanged don’t live on the chain (like bitcoin). It’s more of a promise of exchange.
Getting rid of mining allows for significant performance enhancements for distributed ledgers, as they still have unique properties over a replicated database pattern:
- Any node is able to write to the chain at any time without a centralized node coordinating ‘write’ operations.
- The network could be a coalition of business entities with no one entity owning the network. This creates greater incentives to want to share and use the infrastructure.
- A synchronization technology that allows some nodes on the ledger to have nonidentical copies of the database. (Reason for this explained below.)
Transaction validators provide a service
Transaction validators provide a service for the entire ledger. They determine if transactions meet protocol requirements for the ledger and make a determination that it is ‘valid’. In distributed ledgers, the transaction validators group these transactions into ordered units (blocks) by agreeing on the validity of the transaction and ordering them specifically so as to prevent a ‘double spend’.
I spoke to Simon Taylor, VP of entrepreneurial partnerships at Barclays, about this issue and he gave some good first principles to think about when trying to understand why and how transaction validators should be selected, and what purpose they’re serving.
“Think about why you need validation,” he said. “What are you trying to prove with validation? Am I proving that records match? That business logic executed? Who needs to see this happen? Everyone in the network? Some people in the network? What’s my threat model for why I might want ‘consensus’ or validation?
“So the first goal is to step back and say, who needs to see the data? To do what in a financial transaction? This might be the counterparties. A Central Counterparty (CCP). A smart oracle. A regulator, and perhaps two law firms and a custodian. Why then would I want other network participants to validate the transactions?”
These transaction validators play a critical role in the success of the blockchain as they have the ability to ‘write’ to the ledger and send out confirmations of the transactions. They provide a unique record of truth from which all parties act.
Security concerns without proof of work
Since malicious actors on a distributed ledger are known and can be prosecuted, the main security concerns are the stealing of private keys.
- The actor creating the transaction can store their keys in a secure, offline place. This is known as cold storage. This isn’t very practical, though.
- The actor can store her private key on the local hard drive of their PC. This is a problem because it could get hacked.
- The actor could let a third-party provider manage their private keys in a wallet. This is probably the most convenient for nontechnical people in financial institutions and corporations who have limited knowledge about blockchains.
This is no different than public blockchains, except there’s one major security upgrade: trust. Knowing the counterparties and transaction validators keeps incentives aligned for forming a distributed ledger to begin with.
Examples of how private blockchains are validating transactions
Different companies are using different methods for validating transactions. Most of this information isn’t public knowledge yet. However, a few companies have shared how they’re doing it and I will list a few examples.
Antony Lewis, in his fantastic blog, describes how MultiChain (a private blockchain company headed by Gideon Greenspan) validates via a round-robin process:
Bitcoin’s computation-intensive proof of work solves for a Sybil attack in an anonymous network (ie a small group of entities pretending to be a large group of entities who agree on something in order to spoof the system). With a permissioned blockchain, where block creators are known and have to sign blocks that they create, you don’t have this problem so you don’t need a ‘difficult’ or slow mining puzzle.
MultiChain uses a randomized round-robin system for block-adders and a concept of mining diversity, which is a configurable strictness on how long a block-adder has to sit out for after he has added a block, before the other nodes will accept another block from him.
- At one extreme of the scale (strictness of zero), any block-adder can add any block, meaning it’s very tolerant but also increases the risk that a single block-adder or small group of block-adders can spoof the system.
- At the other extreme of the scale (strictness of 1) once you’ve added a block, you have to let every other block-adder add a block before you can add again. This stops single or groups of block-adders from creating forks, but if a node goes offline then at some point no further blocks will be able to be added while the network waits for the offline node to add the next block.
- Strictness lets you adjust the balance between security and technical malfunction risk.
The block-adders are transaction validators in this model, while the asset owners are the parties performing the transaction.
Tim Swanson, in his latest blog post, talks about Hyperledger, which was acquired by DAH, and how it validated transactions:
The simplest way to describe Hyperledger, the technology platform from Hyper, during its formative year in 2014 was: Ripple without the XRP. Consensus was achieved via PBFT. There were no blocks, transactions were individually validated one by one.
Hyperledger, the technology platform from Hyper, was one of the first platforms that was pitched as, what is now termed a permissioned distributed ledger: validators could be whitelisted and blacklisted. It was designed to be first and foremost a scalable ledger and looked to integrate projects like Codius as a means of enabling contract execution.Note: Practical Byzantine Fault Tolerance (PBFT).
Ripple achieves consensus via the nodes on the network sharing information about transactions. Once a supermajority of the nodes agree, consensus is achieved. This can be an iterative process before the transaction becomes validated.
Other private blockchain companies are doing exactly what public blockchains are doing without using proof of work (as mentioned above). They are grouping transactions into blocks, creating one-way cryptographic hash functions and using multiparty consensus algorithms to name a few things.
The methods companies are employing to validate transactions is one I want to learn more about, as this is a critical piece to the success of the distributed ledger/private blockchain space. For a lot of companies, they’re probably still trying to sort through the best way to do this. The health of the whole ledger depends on the ability of the parts to adapt and withstand stress. In this case, that would be points of failure on how transactions are validated and who those validators are.
Another major assumption that’s now being challenged is around a replicated, shared database in which all of the data is synchronized and all of the nodes on the ledger have identical copies. This is where the third assumption (above) comes into play: a synchronization technology that allows some nodes on the ledger to have nonidentical copies of the database. This opens the doors for an entirely new option as to how transactions will be validated on a ledger.
Let’s suppose we have a distributed ledger that has 20 banks as nodes. Other nodes would include regulators, lawyers, a custodian, a smart oracle (smart contracts) and perhaps disinterested parties to be transaction validators. How is a decision made as to who the transaction validators are within that ecosystem? Are all of the banks going to be all right with only a few of them being the transaction validators? This could present a massive conflict of interest based on what data those validators are privy to, not to mention the fact that most financial institutions enjoy anonymity in how they’re transacting and trading in today’s world, and consider it a distinct advantage. Are they going to have to give this up in order to be a part of the ledger, or will attempts be made to be able to keep this confidential? How can the transactions be distributed as such to ensure anonymity?
Some radical thinking has been done to avoid such issues. Only the nodes involved in a trade will validate the transaction among themselves. Hence, every node on the ledger will have write functionality. This works by not sharing the data and the transactions with any nodes that aren’t directly involved in the trade. What’s shared is the business logic (the instructions around the structure of the transaction) and the workflows (what goes where) via smart contracts. In other words, the business logic is known to all parties, but the transaction itself remains anonymous except between the counterparties. This allows everyone on the ledger to see that something happened the way it was supposed to happen without sacrificing confidentiality. The data stays in each bank’s node, while the ledger itself contains an itemized list of where everything is held.
What comes to mind instantly is, if the two parties are transacting among themselves, what stops them from collusion on trades? Certainly, a transaction validator would need to be someone else aside from the two parties to make sure bad acting doesn’t take place. Regulators or other market infrastructure players could be nodes to oversee the transactions and trades. What’s really compelling about this idea (aside from ensuring anonymity of amounts and types of transactions) is banks having their own data stored in their nodes. This allows each counterparty to control their own data and not the ledger as a whole, which wouldn’t be acceptable to anyone involved. If the whole network were compromised, that would be perilous to the data. Storing the data in this way affords extra protection for individual financial institutions.
Transaction validation in clearing and settlement
Perhaps this opens the door for the incumbents to be a part of the ledger. Parties such as DTCC and the exchanges, who are more disinterested observers than the other participants, and are experts in this, could be nodes on the network. The role of both changes in this new world. No longer do they host the data, as that will remain in the banks nodes, but they could be involved in setting contract templates (smart contracts) and managing upgrade cycles. They could also have a record of all the transactions that are linked to every transaction that has occurred between participants (each and every financial institution) on the ledger. This would be extremely valuable for establishing a chain of custody of each and every transaction as it changes hands (provenance).
There’s also a need for a private key administrator as well. This role will need to be filled. Maybe this falls to some of the rising stars in the cybersecurity world. Regardless of whether this is a real possibility or not, it will be interesting to see how these incumbents position themselves going forward. It will also be interesting to see how other types of company begin to think about transaction validation for their own use cases. In upcoming blog posts, this topic will be explored further.(Special thanks to Simon Taylor, who was instrumental in much of my thinking through conversations we had around this topic. His input was invaluable.)
– This article is reproduced with kind permission. Some minor changes have been made to reflect BankNXT style considerations. Read more here. Image: Ivan Piven, Elegant Design from http://designusfree.com