This is a guest post by Michael G. Solomon PhD CISSP PMP CISM
When they hear the term “blockchain,” most people still think of bitcoin. Bitcoin may have started the whole blockchain revolution, but the story doesn’t end there. Many enterprises are exploring blockchain solutions, and many of those are based on private blockchains, a technology that differs in several important ways from the original bitcoin blockchain.
Even though both types of blockchains are based on the same technology, your choice between these deployment options has a large impact on how you write and test your blockchain apps. Let’s explore how public and private blockchains differ, and how each one has its own features and requirements.
Reviewing Blockchain Technology Basics
The original blockchain technology proposal, published in 2009 by an unknown person (or group of people) under the name of Satoshi Nakamoto, was based on a completely new type of public data repository. This new way to store data allowed multiple nodes, or devices connected to a common network, to share copies of a data ledger, even though those nodes don’t trust one another. This “trust in a trustless environment” feature was revolutionary.
The first blockchain implementation was designed to support a new type of currency that exists only as a digital asset. The first blockchain-based digital currency, called cryptocurrency, was bitcoin. Blockchain technology provided the ability for many nodes to share copies of transaction ledgers that each node could trust. That means with the introduction of bitcoin, users could exchange cryptocurrency among themselves and not have to rely on an intermediary, such as a bank, to broker the transactions. Removing the intermediaries allows cryptocurrency transactions to occur faster, and with lower fees. That opened the door to many self-service transactions.
It wasn’t long before people started envisioning how blockchain technology could do far more than just manage cryptocurrency. Almost immediately, implementors started using blockchain technology for other types of transactions. They found that a blockchain was a great way to transfer any object of value from one owner to another without having to involve brokers or other middlemen. The whole concept of disintermediation quickly became recognized as a core benefit of blockchain apps.
While blockchain technology supports the integrity of shared data in a trustless environment, it doesn’t directly govern who can add data to the blockchain. The original bitcoin specification provided some limited scripting abilities, but enterprises of all sizes need more useful and trustworthy rules to govern transactions than bitcoin provides.
In late 2013, Vitalik Buterin proposed a new blockchain implementation called Ethereum, which introduced smart contracts to provide the rules that all nodes on the blockchain network must follow. Smart contracts provide another critical component that makes blockchain technology suitable for the enterprise environment.
But there was one last hurdle to clear before blockchain was really ready for enterprise prime time: handling sensitive data. Bitcoin was designed to be publicly available to anyone. Some blockchain apps work well with this model, but many others don’t. Some enterprises want to use blockchain technology but also need to limit who can access data on their blockchain.
That’s where private blockchains meet enterprise needs.
Introducing Public and Private Blockchains
The original bitcoin blockchain was deployed as a public, or permissionless, blockchain. That means anyone can access the blockchain and can participate in the blockchain network. No central authority checks identities or limits access.
Permissionless blockchains work well when all data is public and its purpose is to provide a transparent list of ledger transactions. In fact, permissionless blockchains can store private data — users can encrypt their data and then store it on the blockchain. Only others with the decryption key can decrypt the data, so there is some assurance that private data is kept private, even on a public blockchain. However, key management issues make storing private data on public blockchains suboptimal solutions in most cases.
On the other hand, enterprises often want to use blockchain technology to share data among multiple business units and partners, remove intermediaries, and build common transaction audit trails. But they often don’t want this data to be globally available. They want a blockchain available to a limited number of nodes and users. This type of blockchain is a permissioned blockchain.
A permissioned blockchain is a regular blockchain, with the addition of a central trusted authority that limits access to the network and blockchain data. The central authority has to grant authorization, or permission, to each node and user before it allows access to the data. This approach makes it possible to store private data on a blockchain, since the trusted authority can limit who can access that data.
Permissioned blockchains can be deployed as private or consortium. A private blockchain is one that is wholly owned and deployed within a single organization. A consortium blockchain still limits access to authorized users, but it allows access by users from multiple organizations, generally partners of one another. An example of a consortium blockchain is a supply chain blockchain that can be accessed by producers, shippers, warehousers and retailers that all participate in getting products from producers to the final consumers.
Comparing Blockchain Models
Each type of blockchain meets the specific needs of its users and has its own idiosyncrasies to address during development and testing. In traditional applications, data repositories can be manipulated to repair data errors. Testing is easy because application databases can be synthetically populated and refreshed at will, and software that contains bugs can be fixed and overwritten. Testers don’t generally have to worry that the data they use or the code they deploy will persist beyond the testing cycle.
Blockchains are different. One of the central features of blockchains is that data on the blockchain, including smart contracts, is said to be immutable. That means once you add data to a blockchain, it’s always there. There is no “delete” operation in blockchain technology, and blockchains never forget data. While immutability provides unparalleled history and audit trail capability for transactions, it also means that any “bad” data or code added to the blockchain stays there forever.
Strictly speaking, blockchains aren’t actually immutable. Any node, or any authorized node in a permissioned blockchain, can change data on the blockchain. However, any change to the blockchain invalidates that copy of the blockchain and is immediately obvious to all. So, to be more precise, blockchains are tamper-resistant and tamper-evident, and effectively immutable.
Effective immutability means that testers must carefully plan all testing activities to properly test blockchain apps and provide assurance that deployed code operates properly and according to specification. And to make matters worse, blockchains require payment to add data to the blockchain. Traditional databases store data for free, but the way blockchains work, special nodes that ensure block integrity get paid for their work. That means even testing blockchain apps in a live environment costs money. Immutability and transaction costs mean that you have to plan your blockchain app testing.
The biggest difference between permissionless and permissioned blockchain from a tester’s perspective is how to approach testing the software.
In a permissionless environment, there is no way to completely get away from the cost of testing in a live environment. Most blockchain testers take an incremental approach to testing their code. The first step is to use a local blockchain to initially test core app functionality. For example, in the Ethereum environment, many developers use a blockchain such as Ganache to carry out initial testing. The next step would be to deploy to a public test blockchain network. Such a network, like Ropsten, Kovan or Rinkeby, allows you to see how your app works on a truly distributed environment with decentralized smart contract functionality.
Test networks provide “free” cryptocurrency you can use to pay transaction fees. These networks are close to live environments but aren’t truly live. To carry out complete software tests, you’ll need to deploy your code to the live blockchain and run your app there. Live blockchain testing on a public blockchain requires transaction fees using live cryptocurrency. For that reason, you probably won’t be able to carry out as many tests as you can for non-blockchain apps.
Testing in a permissioned blockchain environment can be quite different. While you will encounter the same requirement to pay transaction fees, you may not have to commit “real” money. In a permissioned blockchain environment, the governing authority may provide test accounts with sufficient cryptocurrency to carry out test transactions. Sanctioned testing makes it possible to design tests that more closely resemble those of a traditional database app environment.
However, always remember that testing blockchain apps leaves traces that can’t be undone. Since you can’t remove test data from the blockchain, you’ll need to plan for your final test data to live on the blockchain forever. While it is possible to carry out initial testing prior to going “live” and then initializing the blockchain with clean data after testing, any testing on a live blockchain leaves traces.
The key to successful blockchain app testing and use is in first understanding how blockchains differ from databases, and then respecting the public versus private blockchain differences. Good development and testing plans will help you avoid situations that either end up leaving dirty data on the blockchain or even limit the amount of testing. Good planning really does matter.
Article written by Michael Solomon PhD CISSP PMP CISM, Professor of Information Systems Security and Information Technology at University of the Cumberlands.
