As we talk to businesses far and wide on the topic of blockchain, the question of security is almost always top of mind. Specifically, business are asking questions about how a blockchain can be used to enable participating companies to comply with data protection regulations. The article that follows makes a case for Permissioned Blockchains as THE means to achieve the level of data protection and consistency required by today’s businesses (large and small). Special thanks to Kostas Christidis, along with Chet Murthy, Sharon Coco, Chris Ferris and Gari Singh, for their outstanding collaboration on the following article:
A Case for Permissioned Blockchains
When it comes to blockchain for the enterprise world, our research has shown that permissioned blockchains are the only way to go. In contrast to their permissionless counterparts, permissioned blockchains are the only systems that can enforce policies that can constrain both access to data, and participation in the network, based on identity. This design enables participating companies to comply with data protection regulations. Permissioned blockchains are also more effective at controlling the consistency of the data that gets appended to the blockchain, allowing for more granular decision processes to be built on top of them.
Recall that in a typical blockchain, we identify three functions: read, write, and validate. Reading is, unsurprisingly, the ability to read the data that resides on the blockchain. Writing means being able to append data to the blockchain. Every write operation starts out as a proposed transaction that is posted on the network. These proposed transactions would not always be valid: they may be malformed (syntax errors), or they may constitute an attempt to perform a task for which the submitter is not authorized. When we talk about validation, we refer to filtering out these invalid transactions and then deciding on the exact order for the remaining, valid transactions. This is a process that we call consensus. These ordered transactions are packaged into blocks, which are in turn appended to the blockchain.
In a permissionless blockchain, everyone can read, write, and validate. Depending on the application, we may wish to restrict some or all of these functions to a select set of participants; this gives us permissioned blockchains. Several configurations are possible in this space (restricted read/write/validate, restricted write/validate and unrestricted read, etc.) but, we focus primarily on the one configuration where the set of validating nodes is known and controlled. Recall that the validators process the incoming transactions, decide on their order, and effectively maintain the network’s authoritative transaction log. Thus, deciding who gets to be a validator is a crucial choice.
We argue that for most business purposes, permissioned blockchains are the only choice that can enable compliance with data protection regulations, and satisfy the need for controlled data consistency. We expand on both of these points below.
Let’s start with regulatory compliance, and the data protection principles that have been put in place by a number of acts and directives. As examples, consider the Gramm-Leach-Bliley Act in the U.S. financial sector, the Health Insurance Portability and Accountability Act (HIPAA) for the U.S. healthcare industry, and the European Unionâ€™s Data Protection Directive. What each of these examples illustrates is that companies are often required by governmental or regulatory authorities to know who processes their data, and to constrain where this processing takes place.
In a permissionless blockchain, where a pseudonymous node from across the world can join and participate in the validation process, satisfying these regulatory requirements is not possible. These companies will instead have to operate in a blockchain where the validators are vetted and known, creating an audit trail that allows for regulatory compliance. In addition, this blockchain must have an agreement protocol for admitting new validators and removing existing ones. (This gives the participants the assurance that any validators added to the system in the future will be vetted properly and required to comply with the agreed-upon policy.) These characteristics can only exist within a permissioned blockchain.
Controlled data consistency is the second requirement that drives the use of permissioned blockchains. In permissionless blockchain, you may get temporary forks, either because two validators created the next block at around the same time, or because there was a network partition and a group of validators got cut off from the rest. (These forks are deviations from what the network considers to be the “correct” blockchain.) At the root of this situation is the fact that any node can join this network and attempt to validate the next block of transactions; or put differently, the number of validating nodes on the network is not known.
This exposes permissionless blockchain participants to a couple of problems. First, they might not have a concrete way of knowing that a fork is in progress. Second, when the fork does eventually get resolved and the participants converge to a single “truth,” those that had chosen the “wrong” view in the meantime were exposed to operating on incorrect data.
An often-used workaround to deal with this is to always ignore the last X number of blocks on the blockchain, which can be calculated as a function of the probability of observing a deviation. (This is where the infamous “wait for six blocks to confirm the transaction” Bitcoin rule-of-thumb comes from.) While this workaround is effective for the avoidance of forks (the longest known Bitcoin fork to date is four blocks), it overlooks the fact that applications almost always operate in a connected, consistent world; business applications should not have to incur a nontrivial delay by default, on every operation. Most importantly though, such workarounds overlook the fact that companies are no longer able to build a business policy where they decide what is allowed to be inconsistent, and by how much, under certain network faults; permissionless blockchains provide no such mechanism.
Data inconsistencies are not inherently “bad,” and are in fact acceptable to a number of businesses, but they should be made permissible in a manner that the companies can control.
With permissioned blockchains, we avoid this data consistency problem by running on protocols that prevent the creation of forks and deliver strong consistency; the data that you see now, will also be here an hour from now, so the business process can build safely upon it.
In conclusion, it is these two requirements, which lead us to permissioned blockchains: control over who processes the data, and control of data consistency. Both of these capabilities are important for most businesses that want to use blockchain technology, and we are convinced that the only way to provide them is to use permissioned blockchains.