As is often the case amid the emergence of a new technology, there is currently a lot of (sometimes irrational) exuberance around blockchain. Inevitably, this will lead to some examples of disillusionment when reality kicks in. No, blockchain will not do miracles on its own, and it isn't a 'get out of jail free' card. However, it has some real potential, as well. The trick will be to identify when blockchain is the right tool for the job, especially when compared with more traditional database products and services. Innovation and 'bug fixing' in this space will continue, and blockchain-powered applications will continue to evolve, but what are the current requirements that mean blockchain is the answer?

The 451 Take

If you want immutable records chronologically linked together in 'blocks' and you're part of a trustless 'chain,' you're going to love blockchain. If not, the chances are that a more traditional distributed database or some combination of a distributed database and blockchain-like features is likely to fit your needs. Additionally, note that the effort required to run a blockchain application or join an existing blockchain network is considerably less than if you're intending to develop one yourself. Do not succumb to the hype; be practical instead. Do a careful analysis of your requirements and how those are met by different database technologies, including distributed ledgers and blockchain.

Trustless chains

Blockchains are good for use cases that involve multiple parties – individuals, organizations or machines – that do not necessarily know or trust each other, where the technology provides the trust and integrity across these networks so the participants/peers can share data and transfer assets without the involvement of a central authority or a trusted third-party. Blockchain is best applied where there's dissonance (people-, process- or paperwork-related) across multiple parties. It can take the friction out of supply chain processes and transactions.

Blockchain has an advantage over traditional centralized databases for the use cases described above. However, not all traditional databases are centralized. Some distributed databases might be suitable, architecturally, for a distributed network of participants – particularly compared with permissioned blockchain networks, and especially those where the participants are members of a single entity, where established trust is a prerequisite. In effect, the more permissioned and trusted the environment, the more likely it is that a 'regular' distributed database system can do the job.

To delete or not to delete...

Blockchains are good for use cases that need an audit trail, a continuous list of immutable records (transactional data – e.g., user activities and interactions) that cannot be deleted. Blockchains can provide a chain of custody and a single source of truth for the transfer of any 'digitized' asset, be it money, diamond, contract, land, intellectual property, identity or other. When a record is accessed or altered, the activity is logged into and verified by the blockchain.

While blockchain can be used to create and read immutable records, if you need to update or delete data, then blockchain is not suitable for storing the data itself. In other words, blockchain only addresses the first two of the CRUD (create, read, update and delete) functions of persistent storage.

As a result, in relation to the EU's new General Data Protection Regulation (GDPR), it is not clear whether and how anyone can store personal data on a blockchain and comply with the literal or absolute interpretation of the 'erasure' right/obligation stipulated by the GDPR. It further complicates the issue that the GDPR defines 'personal data' and 'identifiability of a natural person' very broadly. For example, is a natural person whose encrypted/hashed identity data is recorded on a blockchain identifiable? One potential workaround is to store all personal data off-chain and only record transactional data (e.g., user activities and interactions) on-chain. However, there are digital identity offerings with the promise to store encrypted identity data across multiple nodes on the blockchain, where only the private key holder can decrypt the data. At the very least, businesses need to be aware of the risk in operating blockchains that include personal data of EU-based individuals.

On a more general level, for regulatory and compliance reasons, if you want to use blockchain, you will have to conduct thorough research, possibly do some adjustments and work with your regulator.

Intermediaries...too many?

Blockchains are good for use cases and markets where intermediaries add little value and the number of them needs to be reduced for efficiency reasons at the very least. If you don't want to get rid of intermediaries or trusted third parties, why bother using blockchain technology? The goal of disintermediating third parties may certainly be a good one for a few specific use cases, but probably not for all scenarios, especially in an enterprise context. Not all intermediaries are bad or inefficient.

In terms of potential cost savings, if you use a running blockchain application or join a blockchain network, you can rely on other organizations when it comes to support and maintenance. However, if you are developing a blockchain-based application yourself and need to provide support and maintenance for it, it has to be assessed whether that's less costly than, for example, having in-house administrators keeping a distributed database running.

Performance...penalty?

If your application requires high performance and that's all that you care about, a relational database may be a better choice than blockchain.

In a permissionless blockchain, every node needs to process and validate every transaction. For the network to get faster, more compute would need to be added to every (public) node, which is something that is hard, if not impossible, to control. The type of consensus protocol used affects the performance of the network. Proof of work (PoW), in particular, unfavorably affects transaction-processing speed. There are a few approaches, such as the Lightning Network and the Raiden Network, that are attempting to improve the performance issues of public blockchains such as Bitcoin and Ethereum. For example, the Lightning Network is an upgrade proposal that allows peers to quickly and inexpensively transact among themselves on private channels, with the final outcomes broadcast to the Bitcoin blockchain. Startups and consortia are tweaking existing protocols, as well as developing and experimenting with new algorithms, to tackle the flaws of the PoW and proof-of-stake (PoS) consensus protocols. Delegated PoS is an emerging, reportedly highly performant, algorithm used by BitShares, the Steem blockchain and the EOS.IO (Block.one) software.

In a permissioned blockchain, you can make sure that every node is a high-quality computer with high bandwidth, and add more compute to every node for the network to get faster. Additionally, the consensus protocols promoted by permissioned blockchain frameworks such as Hyperledger Fabric are not 'CPU burners,' and only parties that take part in a certain transaction have to reach consensus. But then again, the more permissioned and trusted the environment, the more the resemblance to modern but 'regular' distributed databases.

Akamai and Mitsubishi UFJ Financial Group recently announced their plans to launch a new blockchain-based online payment network designed to execute more than one million transactions per second (with latencies of less than two seconds per transaction). Akamai claims that the underlying permissioned blockchain architecture is extensible to 10 million transactions per second. Also, the recently launched Hedera Hashgraph is a public implementation (with a permissioned governance model) of Hashgraph, a byzantine fault-tolerant protocol that can support hundreds of thousands of transactions per second with three seconds of consensus latency, according to the Hedera team.

Set data free, but not for free?

If data monetization is what you're looking for, that is a key use case for blockchain technology, with the potential to unlock the value of data for individuals or businesses – 'set it free, but not for free.' For example, monetizing the wide array of data that enterprises capture at the edge is an exciting opportunity that lies at the intersection of Internet of Things (IoT) and blockchain: e-commerce of things.

The idea behind decentralized data marketplaces/exchanges – an emerging concept that leverages blockchain technology for buying and selling personal and business data – is to equalize the access to data and unlock its value for individuals, as well as researchers and businesses (again, set it free, but not for free). As mentioned above, however, beware of limitations in terms of a provider's ability to update and delete data. The intention is that data owners/originators – whether individuals or organizations – are able to easily and securely share and monetize their data on their own terms, which is a concept that we believe will be welcomed by many, but what will actually work in the real world is still unclear at this point.

Hello, fault tolerance!

If fault tolerance is important to you, we believe that blockchains have a decisive advantage over more traditional distributed databases. Decentralized systems like blockchains are less likely to fail accidentally and more expensive to attack, and it is a lot harder for participants to collude to act badly (benefit themselves at the expense of others). Getting the same level of robustness in a 'regular' distributed database – especially for use cases that involve multiple parties – would be extremely difficult or unreasonably expensive, if at all possible.

How big are your data files?

Blockchains are generally not well-suited to store large data files, at least not today. Blockchains typically store state of data, transactions and permissions – that's what they are primarily for. For example, e-Estonia's X-road data exchange platform digitally links databases of different government agencies – data is stored where created and is never duplicated. Guardtime's KSI blockchain has been integrated into this platform to make sure only authorized parties access the data and ensure the integrity of the logs containing records of all on-platform activity.

451 Research Blockchain Taxonomy

Understanding the taxonomy of blockchain and related technologies is the first step in making informed decisions. Below is our initial taxonomy, which will be updated as the market evolves.

Source: 451 Research
Csilla Zsigri
Senior Analyst, Cloud Transformation & Blockchain

Csilla Zsigri is a Senior Analyst for 451 Research’s Cloud Transformation channel. Csilla also covers blockchain and works on custom research, providing strategic guidance, as well as market and competitive intelligence, to technology vendors, service providers and enterprises.

MATT ASLETT
Research Director

Matt Aslett is a Research Director for the Data Platforms and Analytics Channel at 451 Research. Matt has overall responsibility for the data platforms and analytics research coverage, which includes operational and analytic databases, Hadoop, grid/cache, stream processing, search-based data platforms, data integration, data quality, data management, analytics, machine learning and advanced analytics.

Keith Dawson
Principal Analyst

Keith Dawson is a principal analyst in 451 Research's Customer Experience & Commerce practice, primarily covering marketing technology. Keith has been covering the intersection of communications and enterprise software for 25 years, mainly looking at how to influence and optimize the customer experience.

Want to read more? Request a trial now.