This is the first in a series of articles where we will see how it is possible to materialize a use case / PoC with Blockchain. Starting with the “theory”, which are the decision algorithms that we use to see if it is worthwhile and of substantial value to apply said technology, and then going to analyze the practical case of that PoC.
Blockchain is being praised as a technological innovation which allows to revolutionize how society trades and interacts. This reputation is in particular attributable to its properties of allowing mutually mistrusting entities to exchange financial value and interact without relying on a trusted third party.
A blockchain moreover provides integrity protected data storage and allows to provide process transparency.
Since blockchain technology is still new, a lot of organizations are looking at ways to incorporate it into their businesses. The fear of missing out on this technology is quite high, and most organizations approach the problem as “we want to use blockchain somewhere, so where can we do that?” which leads to frustrations with the technology as it cannot be applied universally. A better approach would be to first understand blockchain technology, where it fits, and then identify systems (new and old) that may fit the blockchain paradigm.
In this paper we differentiate between permissionless (e.g., Bitcoin/Ethereum) and permissioned (e.g. Hyperledger/Corda) blockchains and contrast their properties to those of a centrally managed database. Also we provide a structured methodology to determine the appropriate technical solution to solve a particular application problem.
In future articles we will analyze in depth three use cases — Supply Chain Management, Interbank and International Payments, and Decentralized Autonomous Organizations — and we will provide an outlook for further opportunities.
Public vs. private, open vs. permissioned
In order to grasp the issues faced by blockchains that will not affect traditional databases, it is important to be aware of the different kinds of blockchains that have been proposed over the last few years. The terms that need to be understood are: public vs. private, and open vs. permissioned.
- The first blockchain system was Bitcoin, and as the system was designed to allow anyone with a computer to submit transactions or join in with maintaining the network, it is both public (Bitcoin runs on the internet), and open (anyone can create a bitcoin address, or download or design software to run nodes that perpetuate the Bitcoin network).
- At the other extreme, we see private and permissioned blockchains. For these systems, the blockchain is run on a private network, for example a VPN or intranet, and an administrator has to grant permission to any individual wanting to submit transactions or maintain a blockchain node. Such a blockchain might, for example, be used by an HR department within a large corporation, where there is a need to provide an auditable record of HR data, but the company does not want just any employee to view or add to the blockchain data, and it certainly doesn’t want the public to see the blockchain data content
- Completing the basic possible combinations, we have open and permissioned blockchains (anyone can see the blockchain, but only specific agents can add data; a use case could be a distributed social media system or a digital rights management system), and private yet permissionless blockchains (for example, a corporate whistleblowing blockchain, in which any employee can submit an complaint or notification, but people outside of the company can’t see the data recorded on the blockchain, and company officers cannot identify the reporting person).
- Finally, there may also be hybrid systems, for example an open blockchain in which anyone can submit a transaction, but only specific permissioned computers are allowed to generate blocks and maintain the blockchain system.
There exist an inherent tradeoff between transparency and privacy. A fully transparent system allows anyone to see any piece of information, i.e. no privacy is provided. Likewise, a fully private system provides no transparency. However, a system can still provide significant privacy-guarantees while making the process of state transitions transparent, e.g. a distributed ledger can provide public verifiability of its overall state without leaking information about the state of each individual participant. Privacy in a public system can be achieved using cryptographic techniques but typically comes at the cost of lower efficiency.
WHEN DOES A BLOCKCHAIN MAKE SENSE?
In general, using an (open or permissioned) blockchain only makes sense when multiple mutually mistrusting entities want to interact and change the state of a system, and are not willing to agree on an online trusted third party.
To ease the decision making process, we provide a basic flow chart in Figure 1. We consider one or multiple parties that write the system state, i.e. a writer corresponds to an entity with write access in a typical database system or to consensus participant in a blockchain system.
Figure 1: A flow chart to determine whether a blockchain is the appropriate technical solution to solve a problem
1. If no data needs to be stored, no database is required at all, i.e. a blockchain, as a form of database, is of no use.
2. Similarly, if only one writer exists, a blockchain does not provide additional guarantees and a regular database is better suited, because it provides better performance in terms of throughput and latency.
3. If a trusted third party (TTP) is available, there are two options:
- First, if the TTP is always online, write operations can be delegated to it and it can function as verifier for state transitions.
- Second, if the TTP is usually offline, it can function as a certificate authority in the setting of a permissioned blockchain, i.e. where all writers of the system are known.
If the writers all mutually trust each other, i.e. they assume that no participant is malicious, a database with shared write access is likely the best solution. If they do not trust each other, using a permissioned blockchain makes sense. Depending on whether public verifiability is required, anyone can be allowed to read the state (public permissioned blockchain) or the set of readers may also be restricted (private permissioned blockchain).
4 If the set of writers is not fixed and known to the participants, as is the case for many cryptocurrencies such as Bitcoin, a permissionless blockchain is a suitable solution.
By other hand, the United States Department of Homeland Security (DHS) Science & Technology Directorate has created a more detailed flowchart to help one determine whether a blockchain may be needed for a development initiative. The flowchart is reproduced here, with permission:
Finally, in next table we contrast some properties of permissionless and permissioned blockchains, and a central database. In a centralized systems, the performance in terms of latency and throughput is generally much better than in blockchain systems, as blockchains add additional complexity through their.
In the next posts we will analyze in depth with those methodologies three use cases:
- Supply Chain Management,
- Interbank and International Payments, and
- Decentralized Autonomous Organizations
Do you have a business? Would you like to validate the potential of blockchain to make it more profitable and efficient?
AtiCommunity, we know that the key is not to invest to invest in revolutionary systems, but to study in depth the needs of companies, assess the possibilities and evaluate the return that each innovation will have.
Our solutions provide real benefits, which can boost your company by making it more profitable and competitive.
Tell us about your project and we will advise you without obligation.
Yes! I want to transform my company.
