As we talk with clients about blockchain implementations at scale, a question we often get is, “What about the high-energy consumption?” This is a common misconception, as only some blockchain implementations are big energy consumers. Here’s why.
Blockchain technology can facilitate trust in distributed systems. How that trust is built affects the amount of energy required. The main challenge is achieving consistency of data across the network so everyone has an identical and unalterable version of the truth.
A key concept in understanding blockchain energy consumption is the consensus algorithm. These algorithms rely heavily on cryptography to ensure there is agreement over the distributed dataset. Every consensus algorithm is a voting principle in which each processing unit represents one vote.
Majority voting principles are used to maintain security, with coded logic that represents how the majority of participants in a blockchain can agree (or vote) on what is a unique and valid transaction history.
Scalability vs. performance
The earliest blockchain networks (e.g., bitcoin and Ethereum) are permissionless, meaning anyone can join in on the consensus algorithm. The key advantage of being public is it’s very safe. Yet, while having more people voting strengthens outcomes, the counting process becomes longer and more complex. So, performance is much lower than with conventional transactive networks.
This signals the most important trade-off in blockchain implementations: scalability versus performance.
Permissioned networks flip the trade-off by performing outstandingly well, but scaling poorly in consensus terms. As a result, permissioned technologies are deployed in consortia where participants are known upfront and can be limited to the enterprises present in a certain system.
There are many approaches to consensus algorithms, each with varying impacts on energy consumption. Following are several examples and use cases (but certainly not an exhaustive list):
1. Proof of work
Proof of work (PoW) is the first consensus algorithm, and still the most common. As the name suggests, it uses the investment of labor to satisfy the majority-vote principle. Often PoW relies on solving a difficult math problem that links a statistical chance of finding the right answer to the amount of processing, or voting power. When someone, often called a miner, finds the right answer, the miner is perceived as adding to the distributed trust and rewarded for the work. This algorithm is most useful in vast networks where value is transacted between individuals who are unknown to one another, such as in many FinTech solutions.
While a miner has no long-term negative effect of increasing processing power, it does increase the short-term chance of finding the right answer to solve the puzzle and claiming a block reward. As any processing power requires a certain amount of energy, consumption increases accordingly. And that’s exactly what’s happened. Currently, the bitcoin blockchain consumes as much energy as a medium-sized European country (Figure 1).
Figure 1: Exponential growth in computational power invested in the bitcoin network, resulting in an estimated energy consumption of 42 TWh/year.
2. Proof of stake
The best-known alternative to PoW is proof of stake (PoS). PoS also rewards miners for maintaining the network. However, the probability of solving the problem is inversely linked to an amount of staked value. As a result, the statistical probability of getting a block reward grows much faster with the amount of staked value than it does with the amount of processing power invested, keeping required power consumption low. PoS is seen as the main competitor to PoW and therefore focuses on the same use cases.
3. Practical Byzantine fault tolerance
Byzantine fault tolerance (BFT), a well-known concept in computer science, often is related to the Byzantine generals’ problem where an array of army generals must agree on a common battle plan, based on information from an unknown number of disloyal petty officers. Practical BFT— for achieving BFT in large embedded networks— offers a cryptographically secure voting principle that works on a two-thirds majority. But this opens the network to Sybil attacks where a single party creates a large number of identities, resulting in a self-constructed majority. So this technology is used solely in consortia, where a number of parties come together and jointly set up rules for the network. It is applicable for sectors such as utilities, logistics and supply chain management and eHealth.
4. Directed acyclic graph (DAG)
One of the newest consensus algorithms is the directed acyclic graph (DAG), or, as proposed by the IOTA network, the Tangle. DAG aims to make each transacting node a consensus node by requiring a reference to one or more parent transactions in each transaction. Referring to parent transactions is put into force by a tiny amount of PoW on each transaction, so that the power consumption is negligibly small compared to traditional PoW consensus platforms. The chain isn’t formed from blocks requiring consensus, but by transactions that include their own consensus. In this sense, DAG isn’t a blockchain, but it does fall within distributed ledger technologies (DLTs).
The major difficulty in DAG is preventing the same transactions from being referenced over and over again. DAG claims to have indefinite scalability and offers transactions without fees. Thus, the technology is often placed within machine-to-machine scenarios such as autonomous vehicles, smart infrastructure and home appliances, and Internet of Things applications.
Matching use cases to platforms
Needless to say, blockchain/DLT offers many choices, and each platform has characteristics that support certain use cases better than others, and that require different levels of energy consumption. There is no one-size-fits-all solution type (yet). Should your use case not fit a particular platform, there very likely are others it will, now or in the near future.
Like the Internet, blockchain was not built in a day. As it matures, novel developments will focus on solving the classic performance-scalability trade-off. Until then, we can focus on stringent use case adoption and appropriate platform selection to maximize results and energy efficiency.