Blockchain is everybody’s latest buzzword–right up there with AI and IoT–but what does it mean, and how is it relevant to the enterprise?
The answer to those questions is likely “a lot,” but before we get to that, let’s define what a blockchain is–and isn’t.
So What is a Blockchain, Really?
A blockchain is a distributed database spread among users who don’t (necessarily) trust each other. To maintain its integrity, it uses cryptography and distributed systems mechanisms known as consensus protocols to ensure the whole network agrees on updates and the state of the data, which provide very strong proofs of integrity and time-stamping. This is why it is sometimes referred to as a “single source of truth.” But while techniques already existed to reconcile disagreements on data correctness, up until now most mechanisms involved trusting a third-party, who typically has full control of the data. Blockchains now make it possible to have the same level of trust without a third-party that can control, manipulate or simply lose the data.
The first use of a blockchain was in 2009 in the popular cryptocurrency Bitcoin, as the underlying distributed ledger that keeps track of all users’ transactions in order to prevent them from double-spending their coins. Over time, the community realized that the transactions recorded on a blockchain didn’t have to be financial and could be anything, for instance updates to DNS entries (Namecoin, 2011) or the state of a worldwide, distributed computer (Ethereum, 2013).
The first blockchain-based systems, being cryptocurrencies, were all public and non-permissioned: that is, anyone and everyone could join (and were even invited to), but this meant also inviting potentially malicious actors to the party. To manage this hard distributed computing problem of a group trying to agree when some members might be deceitful (called Byzantine Fault Tolerance), a special consensus mechanism was devised by Bitcoin’s elusive creator Satoshi Nakamoto: force every user who wants to participate in the network to solve a cryptographic puzzle, using real-world resources, to weed out opportunistic manipulators. This system is called proof-of-work and typically trades off performance and scalability for distributed, cryptographic security.
In such a system, the trust is shifted to the underlying code, designed to enforce common rules using a well-defined protocol (both for the exchange of messages between peers and the consensus mechanism) and public key cryptography (to identify users and authenticate their transactions). These elements themselves are open source, and often build on previous open source implementations.
Separating the Chain from the Coin
As people started separating the blockchain from the cryptocurrencies, some realized it could be useful to share a blockchain among a specific group of people–say a group of companies working together–without letting just anybody join. This different set of constraints led to the emergence of private, permissioned blockchains such as Hyperledger Fabric or EEA’s Quorum. Existing relationships between members of group (say, contractual ones) can make it possible to operate not in a “trust no one, verify everything” mindset but in a less computationally-intensive “assume trust, keep logs to audit” mindset.
This change in trust relationships allows these types of blockchains to replace proof-of-work with alternative consensus algorithms such as proof-of-stake; proof-of-elapsed-time; RAFT or Paxos; or even a simple leader election. An added benefit is that it also makes it possible to run the blockchain much faster, achieving much higher throughputs (often measured in transactions per seconds, TPS)–an important requirement for some use cases.
These types of blockchains have become known as “Distributed Ledger Technologies” (DLTs) and are held by some purists not to be “real” blockchains at all, though they are of great interest to those interested in particular use cases to which “classic” blockchains may not be well suited. Industries such as financial services, healthcare, supply chain, and logistics, as well as governments, are all looking at how using a common information rail, a “single source of truth,” could benefit them, simplifying business dealings, account reconciliation, auditable transfer-of-custody of goods or publishing official documents with robust proofs of integrity and time stamping.
To enhance this effort, several consortia are working on creating enterprise-ready blockchain solutions and tools, such as the Linux Foundation-backed Hyperledger, the Enterprise Ethereum Alliance, the Blockchain Insurance Industry Initiative, or R3.
Working as part of communities, these consortia recognize the value of sharing and open approaches: open source software is the default in the blockchain world.
When Do You Really Need a Blockchain?
Hype is everything with new technologies, and some skeptics argue that blockchain is a solution looking for a problem. And in many cases, they are right. While blockchains can prove extremely useful in certain cases, in others they are simply not the right tool for the job.
After all, distributed databases already exist and are good at what they do.
To figure out if a blockchain might be a good solution to a problem, it can help to think about the situation at hand with these three questions:
Does the problem require a centralized controller or authority?
If it does, or it functions perfectly well that way, then you don’t need a blockchain. To put it differently, if the task required in the process execution isn’t distributed between different entities, then using a blockchain (a database designed to work with multiple entities that don’t trust each other) is meaningless.
Could it work fine with a standard database?
Blockchains provide an interesting function: making sure every participant holds a copy of the data (and that that data is the same). If you don’t need this (even more so, if you don’t want this), then a standard database is going to work better (and, at this point in time, much, much faster).
These two questions are somewhat connected, as they bring us back to the question of centralized authority, the third party we mentioned earlier. A third-party is (or should be) a choice in terms of trust model. If this third-party is a single point of failure or doesn’t provide adequate transparency, then it can often be argued that a system based on it is not functioning correctly and could be enhanced.
Lastly, is adoption going to be costly or annoying to some stakeholders?
If you do have a process whose execution requires multiple parties and for which a centralized database is ill-suited, you’re off to a good start, but if moving to a blockchain-based solution offers great advantages to you but not to the other stakeholders, then forcing a blockchain on them will not bring you the reduction in friction for which you might be hoping.
Where Red Hat Comes In
Red Hat is interested in blockchain technology for two main reasons. The first is because many of our customers are. We know that they are interested in how to deploy blockchain alongside–and integrated with–their existing infrastructure, and how to move forward with new products and opportunities which involve blockchain–typically private and permissioned blockchain. They want to know that Red Hat products will be a good fit for them, whether it’s in the toolchain, platform, management, or middleware layers. Companies are moving beyond a proof-of-concept “we’ll just try this, and see if it works, but we won’t try connecting it” mentality to a “if this is going to a core part of our business, we need to integrate it with our other business-critical applications” mindset. Making this possible for them is a key part of Red Hat’s planning around blockchain.
The second opportunity is for use within Red Hat products and internal processes. There are bound to be opportunities to improve what we do with blockchain technologies. We’re beginning to see ideas emerge about what we could do here, and this is another area that we’re monitoring closely.
Another point, of course is that most blockchain projects are open source communities, and we want to help our customers and partners engage with these communities in the most appropriate and beneficial way for them, us and the wider community.
Looking Towards the Future
Beyond public and private blockchains, what’s coming in the near future to blockchains?
The first and oft-mentioned enhancement to blockchains is the addition of “smart contracts,” the capacity to program code that runs directly on a blockchain. While they are still experimental in nature, they hold interesting promises for automating processes and creating conditional transactions of many types. A variety of capabilities can be be made possible by programming the blockchain directly, including: automating payment if conditions are met; releasing certain information given the presence of the right data; creating derivative contracts; automatically charging an electrical car at a charging station.
Other improvements that are worth noting are next generation blockchains that are self-governing and interconnected. Existing blockchain systems have required the community running the blockchain to agree on the rules in some way or another, in some cases requiring users to run specific forks of the software to signal a preference. But what if there was a way for a community of diverse members to reach consensus on the actually functioning of the blockchain itself, programmatically? Using a blockchain to maintain the rules of a blockchain is the idea behind self-governing blockchains, where the members can vote directly “on chain” to update the rules governing who may join the blockchain, under what conditions, what quorum is necessary to change the rules, and potentially even what consensus mechanism to use, if several are available.
Another interesting area of improvement is connecting various blockchains. One of the promises of blockchains is to end data silos, replacing them with systems where every actor has a copy of the data and can update it. But when you start having several parallel blockchains, you end up with horizontal silos, defeating the original purpose.
Recognizing that different blockchains will be used for different jobs and will coexist, people are turning their attention to how to interconnect different chains to make it possible to exchange information and value between them. Projects such as Cosmos, Polkadot, the Interledger Protocol, and others are working on ways to connect blockchains using sidechains, pegged chains and other mechanisms, which will prove particularly useful if, as we expect, blockchains become an important technological building block of future IT stacks.
Conclusion
As we have seen, while there is a lot of hype surrounding blockchains, there are also genuine reasons to be interested and maybe even excited.
The technology is a good example of what open source innovation can look like, with multiple actors working on others’ advances to create something other than the sum of its parts, that brings something really new and can solve previously unsolvable problems.
At Red Hat, we are excited about these workloads, their requirements on computing, storage and network and infrastructure, and the impact they can have–and are already having–on our customers and partners. We look forward to helping our customers and communities use the technology in smart and relevant ways.