An all-too-familiar criticism of blockchain technology is the fact it consumes too much energy. Once people hear that one Bitcoin transaction consumes as much energy as it takes to power 18 homes in the USA for a full 24 hours, or that annually the Ethereum network’s energy consumption has surpassed that of the entire country of Bolivia, they get turned off. Rightfully so.
For those that decide to start asking questions, there are those around that will be quick to offer a simple correction: the wasteful proof of work consensus mechanisms used by market leaders Bitcoin and Ethereum are not an inherent property of blockchain technologies. In fact, there have been secure green consensus mechanisms working on public blockchains since 2013, such as proof of stake.
Then the conversation on energy waste ends.
However, Ethereum, and just about every other mainstream public blockchain that uses smart contracts, faces another energy-related ticking time bomb: smart contracts are huge energy hogs.
How huge? Well, 10 million people placing one hypothetical order of fries on Ethereum requires enough energy to power 5.67 million US homes for 1 day.
It doesn’t need to be this way, but in order to have any chance of addressing this issue, the conversation around smart contract frameworks needs more nuance.
At a high level, the problem is with how smart contracts are executed. The market standard at the moment was set by Ethereum in 2015 and it is something I refer to as “stateful contract execution.”
Stateful execution means each and every node, or computer, on the network individually executes each contract, or program, and compares their results to the others. Assuming more than 50% of the network reaches the same result, that change is written on the blockchain.
This purist design made sense for early blockchain projects. The easiest way to trust a distributed ledger is to know that the calculations of every smart contract that impacts the underlying data written to the blockchain gets executed and verified by everyone else. Tough to cheat if we all did the same work.
While this maximizes trust that the program will function as expected, it means the network is only as fast as its slowest node because every node needs to do its own work before agreeing on changes. Aside from speed, this translates directly into energy consumption. Instead of just processing simple transactions, each node must execute full smart contract programs.
In other words, instead of simply validating a transaction by declaring “accept” or “reject,” nodes must run through a flow chart of “if this, then that” logic in order to get to the decision on whether to “accept” or “reject” a change.
One normal transaction on the Ethereum network requires 22 KWh of electricity, according to estimates from Digiconomist. For reference, data from the US Energy Information Administration shows that in a 30 day month, the average US household consumed 28.9 KWh of electricity per day in 2017.
After seeking public input and receiving feedback directly from Digiconomist, it was decided that the most accurate way of converting Gas to energy consumption would involve looking at the total energy consumed by the network over the previous day and comparing it with the total Gas consumed over that same period. Combining data from Digiconomist’s Ethereum Energy Consumption Index and etherchain.org, we can come up with an estimate that:
1 Gas = 0.0004 KWh electricity
It should be noted that this calculation is a rough approximation as it only accounts for the energy consumption of mining validators. Due to lack of data, this does not account for the energy consumption of non-mining, full validating nodes. Further data collection and research is recommended to holistically assess the energy consumption of smart contract execution.
We also know that each standard operation on the Ethereum network, for example adding or multiplying numbers, is metered in Gas at the following rates:
- 3 Gas for each computation that requires adding or subtracting integers
- 5 Gas for each computation that requires multiplying or dividing integers
- 20,000 Gas for each computation requiring one 256-bit word (normal text) to be committed to storage
The equation for calculating your Gas to run a specific contract is:
21000 Gas for validating your transaction + the amount necessary to cover the computations in your contract.
Imagine a network like Ethereum’s with its existing 8000 nodes and 1 killer app that suddenly brings in 10 million users.
Let’s say each person makes 1 request that involves writing one 256-bit word, doing 1 computation adding some integers together, and performing 1 computation multiplying some numbers together.
Just to make it comparable to real life, think of writing the word “Fries” on a receipt, adding up the column of this one cost ($0 + the cost of fries), and then multiplying that subtotal by the relevant sales tax. This isn’t necessarily a smart contract that you would write, but let’s just use it for an easy visualization.
The result of this simple request is that each person needs 41,008 Gas, which equates to 16.4 KWh of electricity per person.
16.4 KWh x 10,000,000 interactions = 164,000,000 KWh
Recall the numbers above and we can assess that 10 million orders of fries in this app equate to enough energy to power 5.67 MILLION US homes for 1 day at the 2017 standard rate of 28.9 KWh per day.
Until recently, I believed the stateful contract execution framework was the only way to do things. It turns out, in early 2019, an alternative “green” approach that I would refer to as stateless contract execution entered the scene.
The basic idea is that smart contracts get stored on the blockchain, however, contracts are only executed by one node. The basic workflow is that someone sends a trigger transaction with some input information that points to the node that is running the contract, this “contract runner” node does some calculations, then it sends an output transaction for consensus. No complex computations across the full network, just a normal transaction to validate.
This does mean you need to trust the node that is running a particular program or contract, which means this approach involves sacrificing a degree of trust compared to stateful contract execution. That said, mitigation measures can be built into the system.
For example, Ardor platform includes the ability to run a contract runner node under a multi-signature approval scheme. If the contract code is made open source, then multiple additional verification nodes can also run in parallel and check the contract runner node’s work, flagging foul play.
[Full disclosure: I hold small investments in Bitcoin, Ethereum, and Ardor as well as several other cryptocurrencies and have done work with Jelurida.]
A lawyer at the recent SCIT 2019 conference in NYC was saying many regulators are clamping down on blackbox technologies that result in harm to consumers, and that there has been a marked shift toward open sourcing code. The immutability of the blockchain almost demands open sourcing technology as a liability protection measure.
If that trend holds true, the stateless contract execution model is positioned to benefit substantially from this shift since it appears to provide a transparent, scalable, and sustainable means of ensuring data integrity. This also significantly enhances the ability of enterprises to perform real contract life cycle management since all it takes to update a contract is to deploy the new code to one node and update the references in future trigger transactions, then shut down the other node with the old contract.
The key question at the end of the day is whether all nodes on a given network, such as Ethereum with 8000 nodes, really need to execute the full computation of every smart contract, or whether one node that is under multi-signature control could provide the same level of data integrity by completing the computation itself and sending the final transaction for consensus. Stateless contract execution is still relatively new in the blockchain space but given the clear energy waste of the current industry standard, this is absolutely an area in need of further exploration and discussion.
I base all my analysis on technology in its current form. To that point, I welcome any feedback on how to improve the accuracy of the calculations above; however, anyone that makes a statement around Ethereum 2.0 “fixing” these problems should recognize that in fact, none of Ethereum’s solutions would change the stateful or stateless issue. Even if you develop an application on an Ethereum shard, all nodes on that shard must execute the contract. Furthermore, Ethereum has had bits of code for a proof of stake consensus mechanism on GitHub since 2015 and it has yet to reach mainnet despite multiple announcements that the launch was just a few months away. If you have comments or corrections, please keep the discussion focused on technology that actually functions on a public mainnet.
Skylar Hurwitz is founder at blockchain consultancy Demetrius Consulting and has been reviewing and analyzing public blockchains since 2017.
Create your free account to unlock your custom reading experience.