Methodology

Overview 

Summary

Following the development of the Cambridge Bitcoin Electricity Consumption Index (CBECI), we sought to explore the environmental externalities of blockchain networks beyond Bitcoin. The discourse surrounding electricity consumption and sustainability has intensified, prompting an expansion of our research scope. While Bitcoin undoubtedly accounts for a significant portion of electricity consumption, examining additional blockchain networks and providing the requisite data for an informed discussion is crucial. By introducing the Cambridge Blockchain Network Sustainability Index (CBNSI), we aim to contribute to the ongoing debate and offer a tool for assessing Ethereum's electricity consumption.

Before delving further into our research, it is vital to address Ethereum's history since, unlike Bitcoin, Ethereum transitioned from a proof-of-work (PoW) to a proof-of-stake (PoS) consensus mechanism in an event known as The Merge. The methodology outlined in this section pertains to the current iteration of Ethereum (i.e., Ethereum post-Merge).

Ethereum is a public-permissionless blockchain network initially based on the PoW consensus mechanism. The possibility of shifting to PoS was discussed as early as 2014.¹ Still, only many years later, on 15 September 2022, did Ethereum successfully undergo this transition that fundamentally altered the network's architecture. Before The Merge, the Beacon Chain (consensus layer) and the execution layer (previously Ethereum Mainnet) were two separate blockchains that only communicated inflows of ether to the staking smart contracts (from Mainnet to the Beacon Chain) to replicate funds on the Beacon Chain. The two blockchains ran in parallel, each with its own way of reaching consensus. Post-Merge, the execution layer is still responsible for executing transactions and smart contracts. This responsibility is carried out through the Ethereum Virtual Machine (EVM), a sandboxed environment that executes code in a decentralised manner across the network. Conversely, the consensus layer is now responsible for validators agreeing on which blocks are appended to the blockchain (fork choice rule) and distributing rewards for network services rendered (such as proposing or attesting blocks).

To prevent malicious behaviour, in PoW, network participants who propose blocks needed to demonstrate unforgeable proof (a valid block hash) that they have spent computational resources. Conversely, PoS does not require such proof but instead requires participants to put financial resources at stake. Ethereum requires those who participate in proposing new blocks and providing attestations (so-called validators) to pledge 32 ETH as collateral. If a validator behaves negligently or maliciously, knowingly or unknowingly, they will not be compensated for network services rendered. In more severe cases, the network will impose a financial penalty (known as 'slashing') that reduces the validator's stake (pledged collateral) accordingly. 

In this way, PoS diverges from the energy-intensive nature of PoW in achieving distributed consensus. This distinction has significant ramifications for electricity consumption and its estimation. Our research on PoW consensus-based blockchain networks follows the bottom-up techno-economic model we applied to calculate Bitcoin’s electricity consumption. However, this approach cannot be applied to PoS, as the mechanism does not involve the use of substantial computational resources to solve hash puzzles. Consequently, estimating the quantity and efficiency of hardware based on electricity costs becomes irrelevant, as these factors do not affect an operator's revenue. As a result, it was necessary to devise an alternative method for approximating the number of hardware units in use and their technical specifications.

Analogous to the CBECI, this study incorporates a sensitivity analysis, which demonstrates how power demand varies depending on diverse hardware and software combinations. As the precise power demand cannot be ascertained, we employed a hypothetical range comprising three scenarios, of which two establish the upper and lower bounds. Enclosed within these limits is the best-guess estimate, representing a more pragmatic perspective on Ethereum's actual power demand. We elucidate in greater detail the various assumptions made when calculating the theoretical upper- and lower-bound power demand and the best-guess estimate in the relevant sections.

Representation

The dashboard on the index page displays the Ethereum network's estimated power demand and electricity consumption for all scenarios (lower bound, upper bound and the best guess), and it is updated once a day.

The first number refers to the Ethereum network's total power demand . This measure corresponds to the electrical power the Ethereum network needs or uses at any given moment and is expressed in kilowatts (kW). The second figure refers to the network’s total electricity consumption, a metric that corresponds to the total amount of electricity used over a given period. In this case, it is an annualised value expressed in gigawatt-hours (GWh) based on the assumption that the estimated power demand remains constant over an entire year.

Further, we applied a seven-day moving average to the resulting estimates to smooth potential short-term fluctuations in key variables (such as Beacon Node count), thereby rendering them more suitable for comparison with other electricity usage alternatives.

Model parameters

The CBNSI model considers the parameters in Table 1. The following sections specify how we calculated each estimate and what assumptions were made.

Table 1: Ethereum model parameters

Estimating node count

A key component to estimating Ethereum's power consumption is the number of hardware devices used. However, as explained earlier, we could not use the approach we followed with Bitcoin because that model relies on the assumption that miners are rational economic agents that only use hardware that is profitable to operate. This assumption, however, fails to capture the nature of PoS-based blockchain networks. As the Ethereum network no longer uses the computationally intensive process of mining to reach distributed consensus, the number of devices in use and their computational power have virtually no bearing on an operator's revenue. Consequently, an alternative method for estimating the quantity and specifications of hardware devices in use had to be devised.

Our revised method relies on the network monitoring tool Armiarma crawler, developed by Miga Labs, to identify and analyse Beacon Nodes. Hereafter, we use the term Beacon Node synonymously with a node that runs an execution client and a consensus client and has an arbitrary number of validator clients connected to it. Although it is technically possible to run a node with only a validator client, this situation is outside the scope of our study. However, we expect this to have minimal impact on electricity use, as only running a validator client would require the operator to connect to a third-party Beacon Node, which poses risks that are difficult to control. We can expect that those able to meet the threshold of 'solo' staking 32 ETH are willing and able to invest in the appropriate hardware that satisfies system requirements for running an execution client, consensus client and validator client.

The Armiarma crawler relies on the node discovery protocol discv5 to identify other nodes to communicate and exchange metadata between peers. Peer-to-peer (P2P) communication is a fundamental part of permissionless blockchain networks, as it allows nodes to exchange information and participate in the network. In the Ethereum network, each node maintains a copy of the blockchain and processes transactions and smart contracts. These nodes communicate with each other through a P2P protocol, allowing them to share information and reach consensus on the state of the blockchain. The Ethereum P2P protocol uses a network layer responsible for discovering and connecting to other nodes on the network. Once two nodes are connected, they can exchange messages, including transactions, blocks and other data types, using a custom P2P messaging protocol. The protocol also includes mechanisms for ensuring the integrity and confidentiality of the exchanged information.

From these communications, the Armiarma crawler extracts and stores information about peers participating in Ethereum's peer discovery network and then analyses individual peers and the network at large. However, to avoid being penalised for requesting information from other nodes but not offering the same services in return, the crawler is set up at genesis state and advertises itself accordingly. Table 2 shows a non-exhaustive selection of peer information collected.

Table 2: Peer data

Source: Cortes-Goicoechea & Bautista-Gomez (2020)


It is worth noting that the Armiarma crawler’s original purpose was not just to determine the number of Beacon Nodes (Figure 1) in the network, but also to analyse the network's health in general. However, a more detailed analysis of this function is beyond the scope of this study.

Figure 1: Beacon Node count

in collaboration with

Although the metadata describing the nodes to which the crawler is connected contains much information, it lacks precise hardware specifications. Consequently, an alternative approach was required to estimate the hardware specifications of the discovered nodes, which we explicate further in the following section.

Selecting hardware

As mentioned in the summary, the methods used to estimate the hardware employed in PoW and PoS consensus-based blockchain networks are fundamentally different. In PoW, we can expect that the hardware used to secure the network will only be run if it is profitable, given certain assumptions. To that end, we created a set of profitable hardware based on a list of bitcoin mining hardware and compared the profitability of each device to its operating cost based on an electricity cost parameter. However, this approach does not apply to PoS since the energy-intensive process of finding a valid block hash is no longer necessary.

To address this issue, a different method must be used that accounts for the fact that an entity's revenue does not depend on the number and computational power of its hardware devices. In this environment, rational economic actors would try to find the hardware with the lowest power consumption that still fulfils all software requirements and performs well under stress. However, the actual composition of the hardware remains unknown and must therefore be approximated based on reasonable assumptions.

Our assumptions regarding hardware configurations and their electrical power are based on a Crypto Carbon Ratings Institute (CCRI) report,² which presents the findings of real-world experiments with client software and various hardware configurations. It is essential to note that the chosen hardware configurations were based on consumer-grade hardware, not configurations typically used in professional data centres.

Six different categories of hardware configurations were created and ranked according to performance from lowest to highest. A more detailed description of the hardware configurations can be found in Appendix 1.

The configurations of each tier were then compared with the (minimum) software requirements of the consensus clients (Prysm, Lighthouse, Teku, Nimbus and Lodestar) and the execution clients (Geth, Erigon and Besu). This comparison led to the exclusion of configurations 1–3 from further analysis, as they did not meet these requirements.

Having determined the universe of hardware configurations allows now for testing the electrical power usage of each consensus- and execution client during operation. However, before doing so, the idle power use of each hardware configuration (Appendix 2) had to be isolated to avoid distorting the results. The resulting marginal power use of all observed consensus and execution client software for hardware configurations 4–6 can be found in Appendices 3 and 4.

The next step involved defining the frequency of specific execution and consensus client combinations, which is essential as the required electrical power varies between these combinations. Here, we must state that while the tested clients do not cover all available execution and consensus clients, they cover the vast majority.³ Figure 2 illustrates the current distribution of consensus clients, and Table 3 displays the distribution of execution clients.

Figure 2: Consensus client distribution

in collaboration with

Table 3: Execution client distribution

Source: Ethernodes, as of 10/03/2023

Notably, while we consider daily changes in the consensus client distribution, we do not for execution clients, as this data is not yet available. Therefore, we assume that the distribution shown in Table 3 is a fair approximation of the execution client distribution over time.

As previously mentioned, we did not consider all available Ethereum clients in this study, which may result in some of the Beacon Nodes discovered by the network crawler running clients that are not included in Table 4. This could create a gap between the total number of Beacon Nodes discovered by the network crawler and the sum of those using any of the mentioned consensus and execution clients in sets C and E.

Table 4: Ethereum clients

 To account for this gap, we created the adjusted share (S) where each consensus and execution client combination listed in Table 5 is divided by the sum of their shares, as shown in Equation 1. This step is necessary since if all the shares of consensus and execution client combinations considered were added together (Table 5), the result would be less than 100% due to the omission of other combinations not listed in the table.

Table 5: Ethereum client combinations

To calculate the share of each combination, the proportion of each consensus client (s_c,d) is multiplied by the proportion of each execution client (s_e), as shown in Equation 2.

While we incorporated a power usage effectiveness (PUE) factor in our pre-Merge Ethereum power demand and electricity consumption estimates, we did not include one in this study due to the previously mentioned assumption that the hardware is self-hosted. Thus, we can assume that the premises where the equipment is hosted does not contain any special cooling or air circulation systems.

The following sections present three different estimates, two of which are theoretical upper and lower bounds representing hypothetical best- and worst-case scenarios. These scenarios mark the range within which the most credible estimate lies.

Constructing the lower-bound estimate

The lower-bound estimate represents a hypothetical best-case scenario based on the assumption that all discovered nodes only use the most efficient hardware configuration that still fulfils the software requirements. It is worth noting that this is also the configuration that would minimise operational costs while ensuring that hardware requirements are met.

We then differentiated the lower-bound estimate into an annualised consumption estimate (Equation 3) and a power demand estimate (Equation 4). The power demand estimate indicates the maximum electricity consumption at a given time. The annualised consumption estimate adds a time component to show the electricity consumption if it remained constant for 365.25 days.⁴ This allows for a more convenient comparison with other industries, countries, or activities and facilitates a better understanding of the results.

The power demand (D) of the Ethereum network for the lower bound on a given day is calculated using Equation 4. This estimate assumes that the hardware configuration of all discovered nodes is consistent with configuration 4 (shown in Appendix 1).

As previously mentioned, the lower bound represents a theoretical minimum. It indicates the minimum power demand required if only the most efficient hardware configuration is used. However, it is important to note that this is a purely hypothetical figure that may not represent the actual situation. There is evidence⁵ that various actors host nodes in the network, including individuals and professional data centres, who may have different hardware configurations. Consequently, it is reasonable to assume that the actual power demand of the network differs from the lower-bound estimate.

Constructing the upper-bound estimate

Like the lower-bound estimate, the upper-bound estimate presents a hypothetical worst-case scenario premised on the assumption that all discovered nodes utilise the least efficient hardware configuration, one that significantly exceeds software requirements. While it would be more economically prudent to employ the most efficient hardware configuration that satisfies the software requirements, individuals who self-host may have interests beyond finding the most cost-effective solution for running an Ethereum node, such as using their hardware for alternative purposes.

 In a manner similar to the lower-bound estimate, the upper-bound estimate is differentiated into an annualised consumption estimate (Equation 5) and a power demand estimate (Equation 6). While the power demand estimate shows the maximum electrical power usage at any given time, a time component (annual) was added to demonstrate the daily estimated power demand if it stayed constant for 365.25 days.⁶ This makes the results easier to understand and more convenient to compare.


The Ethereum network's power demand (D) for the upper bound on a given day is calculated using Equation 6. This estimate assumes that all discovered nodes have a hardware configuration equal to configuration 6 (shown in Appendix 1).

As mentioned above, the upper bound reflects a theoretical ceiling and should give an idea about the maximum power demand required if only the least efficient hardware configuration is used. This is a purely hypothetical figure that is likely not representative. Evidence⁷ shows that various actors host nodes, from self-hosting to professional data centres. It is reasonable to assume that these actors use different hardware.

Constructing the best-guess estimate 

Our best-guess estimate is the most realistic option, as it takes into consideration the use of various hardware configurations with differing efficiencies. This approach acknowledges the likelihood of a diverse range of hardware being employed in practice, unlike the other two scenarios, which are solely based on single hardware configurations. However, since the actual hardware distribution is unknown, we based our calculations on the hardware distribution shown in Table 6.

Table 6: Hardware distribution based on the CCRI report

Source: CCRI (2022)

Like the upper- and lower-bound estimates, we differentiated the best-guess estimate into an annualised consumption estimate and a power demand estimate. While the power demand estimate shows the maximum electrical power use at any given time, a time component (annual) has been added to demonstrate the daily estimated power demand if it stayed constant for 365.25 days.⁸ This makes the results easier to understand and more convenient to compare.

The Ethereum network's power demand (D) for our best-guess scenario on a given day is calculated using Equation 8. This estimate assumes that all discovered nodes use hardware configurations 4, 5 or 6. Table 6 shows the assumed share of each configuration (H). (Appendix 1 provides the technical specifications of each configuration.)

As mentioned, the best guess reflects the estimated power demand required for a diverse hardware mix and is considered the most realistic option. The estimate assumes that the hardware configuration distribution in Table 6 accurately represents all discovered nodes. While this assumption may be reasonable, it is still an approximation as the specific hardware each node uses is unknown. However, there is evidence⁹ that various actors host nodes, ranging from individuals self-hosting on laptops or consumer-grade hardware to professional data centres using high-performance servers. This supports the notion that a diverse hardware mix is used in reality.

Discussion

Limitations of the model

Theoretical models are generally imperfect representations of reality, as they are based on certain, and perhaps unrealistic, assumptions and are thus subject to limitations. The following non-exhaustive list highlights the primary limitations of our the current Ethereum estimates:

• Presently, it is not possible to precisely determine each Beacon Node's hardware configuration, necessitating a reliance on a set of assumptions. These assumptions are informed by research conducted by CCRI (2022), which tested specific hardware configurations. Although the best-guess estimate already takes into account the employment of various user hardware configurations, further research is required to ascertain the extent to which different hardware configurations are utilised.

• In measuring the average marginal electrical power of consensus and execution clients, the values were obtained separately and subsequently combined. The implicit assumption is that the result would be equivalent if both clients operated in parallel. CCRI (2022) observed that when running the most common client combination (Prysm and Geth) simultaneously, electricity consumption was 9% lower than when tested individually. However, they also noted that during the course of parallel testing, 12% fewer transactions were processed, which may explain the reduced electricity consumption.

• The tests for estimating the average marginal electrical power were conducted with specific software client version. Over time, however, client versions are upgraded, which may result in the software stressing the hardware to a greater or lesser extent, potentially changing the power demand.

• While we use the available daily data on consensus client distribution, we assume that the execution client distribution in Table 3 remains constant until more information is available.

• In this study, the term 'nodes' refers to Beacon Nodes, which operate at least one consensus client and one execution client. Nevertheless, it is possible to run a validator client independently, despite the significant drawbacks associated with doing so. This factor may contribute to an underestimation of the total node count.
  
  

We are committed to publishing studies that present a picture as close to reality as possible. Nevertheless, we acknowledge that, especially in this emerging area of research, we often have to rely on numerous assumptions. While we are confident that the proposed estimates represent a fair range of Ethereum's electricity use, this methodology will be refined and adjusted over time as new and more granular data becomes available. That being said, we will record any alterations in the change log.

For suggestions on improving the index, please contact us through our website.

How do our estimates compare to others?

There have been a few attempts to estimate Ethereum's post-Merge electricity consumption (Table 7). Some of these estimates are updated daily, while others represent a snapshot at a specific time. Since The Merge is a recent event, there is limited research on post-Merge electricity consumption, and different approaches often lead to varying results. Therefore, it is essential to consider the publication date and methodology when comparing estimates from other studies.

All comparisons are based on estimated annualised electricity consumption to make comparing estimates more convenient.

Table 7: Overview of previous studies

Appendix 1

Source: CCRI (2022)

Appendix 2

Source: CCRI (2022)

Appendix 3

Source: CCRI (2022)

Appendix 4

Source: CCRI (2022)

Appendix 5

Source: CCRI (2022)

¹ Average idle consumption

² Average marginal consumption of consensus client

³ Average marginal consumption of execution client

⁴ Total average consumption of consensus and execution client combination (AIC + AMC_c + AMC_e

Appendix 6

Source: CCRI (2022)

¹ Average idle consumption

² Average marginal consumption of consensus client

³ Average marginal consumption of execution client

⁴ Total average consumption of consensus and execution client combination (AIC + AMC_c + AMC_e)

Appendix 7

Source: CCRI (2022)

¹ Average idle consumption

² Average marginal consumption of consensus client

³ Average marginal consumption of execution client

⁴ Total average consumption of consensus and execution client combination (AIC + AMC_c + AMC_e)