How public blockchain is destroying the Earth – and why Gospel is not

July 20, 2018
Posted in: Blog

Public blockchains such as those used to manage cryptocurrencies consume an enormous amount of computing energy and have been accused of being wasteful and even immoral.  Reuben Thompson explains the controversy and why private blockchains should not be tarnished with the same brush.

 

One of the most common (and often fair) criticisms of cryptocurrencies and similar, public blockchain networks relates to how the Proof of Work algorithms used for consensus consume enormous amounts of energy and the negative effect on the environment this has. In this post, I’ll be looking at why these algorithms are used, the attempts of public systems to work around the issue and why private, permissioned systems like Gospel are fundamentally different and unaffected by this problem.

 

So, what is Proof of Work?

A public blockchain, can, by definition be accessed by anyone. This means that, in theory, a block can be cut by anyone. It’s necessary, therefore, to have a mechanism by which the rate at which blocks are cut can be regulated and the right to do so can be distributed. This prevents the network being swamped with transactions and ensures that no single network participant can control who gets to submit transactions. Bitcoin (and other cryptocurrencies) do so using a combination of posing a hard mathematical problem (1) that can be solved in approximately the desired block time by the current amount of computing power available (mining) and rewarding the first participant who does so with some coins (a block reward) and the right to decide which transactions are in that block (usually those with the highest transaction fees attached).


This is not far off the amount of energy consumed by the whole of Ireland


As the value of the cryptocurrencies has risen, so has the value of the reward, increasing the amount of compute power miners are willing to dedicate to it. This has led to rampant electricity consumption, with Bitcoin alone being estimated to consume 2.55GW of energy late last year, which could be annualised to 22.3TWh. This is not far off the amount of energy consumed by the whole of Ireland. When you add in the mining for Litecoin, Ethereum and so on, it’s a truly shocking amount of energy consumption.

 

Didn’t Satoshi see this coming?

Well, to some extent, yes. With the expectation of the rising value of coins, the block reward reduces periodically and will eventually be eliminated, leaving only the transaction fees as reward. What he didn’t foresee was the rate of growth in value or the extent to which miners have been willing to build custom hardware to game the SHA algorithm used in the mining process.

 

What has been done?

There is, unfortunately, a fundamental conflict between the aims of the miners (acquiring as much cryptocurrency as possible using the hardware they’ve bought) and other users of the network. Bitcoin’s system for voting on change proposals is done by writing votes into the blocks, so only miners get a say. This means that even relatively uncontroversial proposals such as increasing block size to keep transaction fees and wait times manageable have been extremely difficult to pass. This means that most improvements to the system have been in the form of hard forks (effectively splitting the currency in two – eg Litecoin and Bitcoin Cash) or starting entirely new networks.

Early attempts to solve this issue mainly consisted of changing the mining algorithm to one that was harder to manipulate with custom hardware (for example Litecoin’s use of the high-memory consumption scrypt algorithm). Since then, more and more esoteric systems of hashing and mining have emerged such as Monero’s use of Cryptonight which uses a large amount of memory and many iterations of hashing in an attempt to reduce the incremental value of owning many machines or custom hardware. Fundamentally, though, it’s still brute force and it still eats energy in prodigious and unsustainable volumes.


Early attempts to solve this issue mainly consisted of changing the mining algorithm to one that was harder to manipulate with custom hardware


More recent attempts have centred around Proof of Authority (2) systems which dictate who has the right to cut the next block based on a shared algorithm. In many systems this is a Proof of Stake (at the most basic level “if you hold n% of the coins you can cut n% of the blocks”) which, although complex and rarely successfully implemented, preserves the decentralised nature of the blockchain. Ethereum, for instance, have been committed to implementing such a system for a good while, but have yet to get it to work consistently at scale. Others implement a two-tier network with “super nodes” that use consensus to determine the right to cut the next block. Whilst sound, in theory, these have serious drawbacks in practice as finding a suitable group of trusted parties to host them in a public network can be very challenging and there is a significant risk of a single party seizing more than half of them compared to that of a traditional public network. EOS, NEM, Zencash and Graft all use variants of this system and Stellar uses a hybrid.
How is Gospel different?

Unlike all these systems, Gospel is a private, permissioned blockchain. That means that nodes can only join with the agreement of the others, preventing the possibility of a 51% attack and removing the need for a brute force algorithm. As the number of active nodes is known and finite, allocating the right to cut a block can be relatively easily achieved and a single view of the queue of transactions to be cut can be maintained, ensuring they can be cut in the most advantageous order.

Many private systems use a single node to cut the blocks (eg Hyperledger Fabric in single orderer mode). This has the downside of a single party controlling the process and a single point of failure, but provides simplicity and speed. The single party downside may be acceptable if that party can be trusted not to ignore transactions from others and endorsement (pBFT consensus) is enforced earlier in the process as in Gospel and Fabric. Fabric also has a multi-party, single queue system utilising Kafka, providing failover, but theoretically allowing the party with the fastest server to cut as many blocks as they wish. Gospel can support both these methods if customers wish as, for most purposes, one or both of these offer a good balance of efficiency and safety in a semi-trusted environment, especially when combined with pre-endorsed transactions.

Other systems use pBFT at block time to cut blocks but with the downside that all nodes must calculate each block increasing compute power and, substantially reducing speed and reliability. This does, however, prevent a single participant from cutting all the blocks or brute-forcing out the transactions of another party. This can be thought of as running the ordering in lock step across all the nodes.

Uniquely to Gospel, we’re also working on a new consensus algorithm designed specifically for our clients’ needs. It brings BFT to the determination of authority to cut a block without relying on the entire network running in lockstep. Initial signs are that it delivers the speed of simpler algorithms with none of the reliability or compute power downsides. It’s worth remembering, though, that the best option for a particular client will depend on their exact needs – that’s why it’s important that like almost everything in Gospel, consensus is pluggable.

 

So, how much energy does it take to cut a transaction?

With Bitcoin this is actually pretty easy to calculate as the blocks are typically 1MB in size. Transactions are typically around 400 bytes (including a proportionate share of the block overhead) meaning each transaction accounts for around 1/2600 of a block. As a block is cut (approximately) every 600 seconds and we know that consumption is around 2.55GW, we can say a block takes about 425MWh to cut and 1/2600 of that is 163kWh or about the amount of energy a typical UK flat uses in a month. The enormous values of the block reward (even with recent declines, $100k for a Bitcoin block) means that spending nearly $30,000 on electricity to mine one doesn’t seem as crazy as it really is to the miners.


Uniquely to Gospel, we’re also working on a new consensus algorithm designed specifically for our clients’ needs


With Ethereum, the question is a little more complex as the blocks vary greatly in size (and number of transactions), are cut at a much higher rate and are occasionally empty. This means that attributing energy usage to a single transaction is much harder as the amount used varies depending on whether the network is busy or not. I’ve seen a few ambitious (and rather specious) commentators suggest this means the marginal energy cost of an Ethereum transaction is, therefore, zero. It is, however, reasonable to assume that if nobody made any transactions, nobody would bother mining Ether as it would have no value, so one can reasonably attribute a proportion of the total consumption to a transaction. Digiconomist estimate that, on average, each transaction consumes around 92kWh (3).

With Gospel, on the other hand, there are no marginal energy costs to cutting a transaction to a block as there is no proof of work. Our smaller test net of five nodes consumes around 1.4kW and will quite happily cut ten blocks a second (and probably a lot more), each with 20 transactions, meaning the energy cost per transaction is infinitesimally small.

 

In conclusion

The open nature of public blockchain requires a rigid form of control to ensure the will of the overall network cannot be subverted by a single participant. Although significant strides have been made, no solution has yet provided as comprehensive a solution as Proof of Work, meaning its appalling environmental consequences cannot be avoided at present. Private blockchain, however, has none of the environmental downsides of public blockchain and, for many applications provides a safer, more scalable solution as well as an environmentally sound one.

 

Reuben

 

context-based access

Reuben Thompson is Gospel’s VP of Technology.

 

Footnotes
1. We hear people talk a lot about “a hard mathematical problem” but it’s rare to get anyone to actually explain it in layman’s terms, so I’m going to have a go…

 

First off, we need to know what a hash algorithm is. It’s a mathematical function that will produce a long number from any input, but where the original input cannot be derived from the output. Typical examples (with various degrees of security) include MD5, SHA, SHA2 and scrypt. Blockchain uses hashing extensively to ensure the security of the chain using a construct called a Merkle Tree.

 

As you’ll probably know, each block includes the hash of the previous block to form the chain. Proof of work typically means that in order to gain the right to cut a valid block, a miner must have found a number that when hashed together with that block hash produces a value beginning with a given number of zeroes. As the probability of receiving any given hash value is roughly equal, the probability of receiving a number beginning with more zeroes for any given input is lower by an order of magnitude for each additional zero. This number is called the nonce (yes, really) and must be included in the block for it to be valid. This has the upside that verifying the result is easy, but finding it is very hard. The difficulty (ie number of leading zeroes) is reviewed regularly by the network to ensure that blocks are cut at a near constant rate.

 

2. I use the term Proof of Authority more generally than the Ethereum team do with their Clique engine. I mean that a predetermined algorithm determines authority to cut the next block in general terms rather than their particular mechanism based on identity and reputation.

 

3. I don’t think it’s unreasonable to extrapolate that if the Ethereum network was totally congested because of, say, a game involving cats or some equally important business use, the environmental cost per transaction would reduce. If we think of this in cat terms, the 50kWh of that reduced cost is about 180MJ. Your average 4kg cat needs about 238 calories a day which is 995kJ. That means that your cryptokitties transaction needs as much energy as 180 actual cats. And that’s at peak usage; today, that’s about 310 cats!  Meeeow…

 

For a 90 second summary of Gospel click here.

For an in-depth overview of the Gospel solution click here.

Ask the team – many of your questions answered.