Bitcoin has received a lot of negative press because of its energy consumption[1]. I wanted to understand why Bitcoin, i.e., blockchains, use so much energy and what cryptocurrencies are doing about it. Here’s a summary of what I found.
A blockchain is a database that is very difficult to tamper with. Each database entry is called a block. The block contains transaction data, a timestamp and a cryptographic hash related to the block preceding it. This cryptographic hash is like a block’s fingerprint in the form of a large number derived from the block data. The hash codes link the blocks because each block contains the hash of the preceding block. Hence the name blockchain. If any block data were to change, its hash would change. The hash included in the subsequent block would no longer match the data and thus signal an alteration. This makes the blockchain quite robust to modification.
To further limit the risk of modification, the blockchain is not stored in one centralized location, where hackers might gain access and change it. Instead, copies of the blockchain are distributed to every node in the network and updated with every new block. So, to change a block would require not only to change all the subsequent blocks but also the majority of all the copies of the blockchain distributed throughout the network. It is effectively impossible to change all of this in the time before the next block is added. With Bitcoin, a block is generated every 10 minutes and contains a maximum of 3000 transactions[2]. That is few and shows that Bitcoin does not scale to everyday transactions. In 2019, in the USA alone, over 750’000 credit card transactions were recorded every 10 minutes on average[3].
But now, who may add a new block to the blockchain and when, since the blockchain is decentralized and there are countless copies throughout the network? The nodes in the network need a method to agree on who can add a block. This is called a consensus mechanism and ensures a unique and verifiable blockchain. One way to decide is for every node to wait a random time and the computer whose random timer expires first can attach the new block and update the blockchain.
The problem is, how do you stop the dishonest participant from claiming that its timer has expired and from taking control of the blockchain? For Bitcoin, it is the hash that makes it impossible to cheat with the timer, in something called “proof-of-work.”
Remember, the hash is like the fingerprint of a block of data. A large block of data is input into a mathematical formula that generates a fixed-length hash output. For example, for Bitcoin, any input data goes into the Secure Hash Algorithm SHA-256, which computes a hash of 256 bits. The particularity of this algorithm is that it is easy to calculate the hash from the block, but impossible to compute the block from the hash. A second characteristic of the hash algorithm is that even the smallest change in the input data creates a completely different hash code.
For example, Steve Martin’s quote “I was not naturally talented. I didn’t sing, dance or act, though working around that minor detail made me inventive” generates the following hexadecimal SHA-256 hash: 4a07 d6bc ada3 cbe7 b8a9 5c7a ac1f 00a7 714e d858 24ac dcfa cf2a 50ad 8e7c 48e7.
Capitalizing “Minor” and leaving the rest of the sentence unchanged leads to a completely different hash: 0f05 a1e7 53e0 96b0 3be9 6b01 d5f5 51d6 a54d a044 3460 3b12 c579 b5cd 2fae c560. So even with just one letter changed, the hash looks very different.
To create a timer that nobody can cheat, Bitcoin asks that the next generated hash has a certain number of zeros in the first positions, i.e., the hash needs to be of the form 0000 XYZ…., for an example with four leading zeros. Recall that the data block cannot be found from the hash. The only way to find a correct hash is add some extra data called a “nonce” to the data. But since the nonce cannot be reverse-engineered from the hash, the only way to get the correct output hash is to guess a nonce and compute the hash from the nonce and the other data. This is repeated with random nonces in the hope to be the first one that finds a correct nonce. The nonce for Bitcoins is a 32-bit number, that means there are about 4.3 billion possibilities. The computer that finds a suitable nonce to generate a hash in the required form can then add the block to the blockchain and receives a block reward. This is called “Bitcoin mining,” because the block rewards are the only way that new Bitcoins are issued.
All the “miners” compete and massive computing power is used to win the next block reward by guessing a suitable nonce. Because the miners invest a lot of computing power, this method is called “proof-of-work.” To find the right nonce is a question of luck and therefore probabilistically linked to the amount of computing power used. To hijack the system, one would have to control over 50% of the mining computing power.
So, it is maintaining randomness and prevent malicious interference that uses all this power in Bitcoin mining. The power consumption is the price for making the system more.
How much power? Well, it is estimated that blockchain uses between 60 and 125 TWh per year, that is about the electricity consumption of Austria (75 TWh) or Norway (125 TWh). Given the maximum number of 3000 Bitcoin transactions per block, this is quite astronomical. So, what other consensus mechanisms are there? What are alternatives to “proof-of-work”?
The best-known alternative to “proof-of-work” is “proof-of-stake.” Here, participants that want to encode or validate a block “stake” their money on the transaction: If they are not honest and try to cheat when encoding or validating blocks, they will lose the money they have put up in order to take part. The stake works like a security deposit. To manipulate the blockchain would need control of a majority of participants, and so control of a large sum of staked money.
Once the participants have staked, block encoders and validators are chosen at random.
But, of course, the entire point of proof-of-work was to choose randomly, so how is randomness ensured for proof-of-stake?
Each user picks a random number. All the user’s random numbers are then exclusive-OR’d together. This is in principle quite good because as each user commits its number, this is an easy method to compute a pseudo-random number all users can verify easily. In practice, it is a bit more complicated, but this is the gist of the so-called RANDAO process.
The problem here is that not all the users are revealing their numbers at the same time. So, as each user reveals its number, a dishonest user could follow along. It turns out that a dishonest user can influence the entropy/randomness of the output by revealing or not revealing its number, and bias the end-result in its favor. If 34% of the users collude, they could hijack the scheme[4].
To avoid this problem, Verifiable Delay Functions (VDFs) are used. These are functions that are known to take a certain number of sequential computing operations, and thus time. We cannot speed them up beyond a certain point even by using special-purpose computing. The output of the RANDAO is input to a VDF and the computation of the VDF output takes much longer than the time window during which the participants can commit their random number. For example, if the window to commit the user numbers is 10 seconds, the VDF may take 10 minutes to compute. That way, all the users need to commit their number before a malicious user can compute the final output of the VDF. Without the knowledge about the final output, the user cannot bias the result in his favor. Obviously, the choice of VDF is very important and among its characteristics must be that the final output is not predictable based on any earlier output, we can quickly verify it without having to redo the entire computation, and it must have a unique valid output[5].
This sounds a bit like proof-of-work: A lot of computation up front, followed by an easy-to-verify hash when given the correct block data and nonce. But that’s not quite true because proof-of-work is probabilistic. The more computing power you have, the more likely you are to find the correct nonce. To guess a suitable nonce and then compute the hash is, by design, suitable for parallel computing, i.e., all the miners searching at the same time for a suitable nonce. This leads to the arms race in computing power observable for Bitcoin. In Contrast, VDFs are deterministic functions that cannot be solved faster through parallel computing and, given an input, lead to a unique output. Simply having more parallel computing power does not help in getting a faster output. Only faster hardware can improve the sequential computation time of the VDF. If even with the fastest special-purpose hardware, the computation takes much longer than the time window during which the users can commit their random numbers, there is no incentive to cheat, because there is no hope of beating the clock. Correspondingly, it suffices to compute the VDF once and then have the participants verify the results. Ethereum, the second largest cryptocurrency by market capitalization, aims to change to a proof-of-stake system in 2022[6]. It is estimated to use less than 1% of the power of bitcoin[7]. Besides addressing the problem of energy consumption, Ethereum also works on its scalability, including the number of transactions, through “sharding”[8]. If the cryptocurrencies develop to handle many thousands of transactions per second using reasonable amounts of energy, they may become much more useful in the future. It’ll be interesting to see where the journey goes.
[1]. https://www.ft.com/content/1aecb2db-8f61-427c-a413-3b929291c8ac
[2]. https://towardsdatascience.com/the-blockchain-scalability-problem-the-race-for-visa-like
[3]. https://www.cardrates.com/advice/number-of-credit-card-transactions-per-day-year/
[4]. https://ethresear.ch/t/avalanche-randao-a-construction-to-minimize-randao-biasability-in-the-face-of-large-coalitions-of-validators/4248
[5]. https://eprint.iacr.org/2018/712.pdf ; https://reading.supply/@whyrusleeping/a-vdf-explainer-5S6Ect
[6].https://en.wikipedia.org/wiki/Ethereum#Continued_development_and_milestones_(2017%E2%80%93present) ; https://ethereum.org/en/upgrades/merge/
[7]. https://www.bloomberg.com/news/articles/2021-05-23/ethereum-closes-in-on-long-sought-fix-to-cut-energy-use-over-99