Diving into Energy Use on Stellar: Blockchain Payment Efficiency Examined

Stellar is a decentralized, open-membership network optimized for payments and built on blockchain technology, with the goal of enabling money to flow between banks, businesses and people across the global financial infrastructure, while minimizing latency and transaction fees. At the core of the network is a federated-voting consensus algorithm, the Stellar Consensus Protocol (SCP). Put simply, the goal of the consensus algorithm is to ensure that all nodes on the network agree on the contents of the blockchain (the ledger) without the network risking a split into two disagreeing networks or getting stuck.

SCP is a partially synchronous, federated Byzantine agreement protocol defining the consensus mechanism. It is based on voting in quorum systems, a fairly common approach among distributed systems and consensus protocols. SCP introduces an open-membership system — a Federated Byzantine Agreement System — where nodes accept different and evolving quorums. This means that nodes can join and leave the network without the need for a centralized membership coordination. To better understand the internal mechanisms of the protocol, I sincerely recommend reading Marta Lokhava’s excellent post on Intuitive Stellar Consensus Protocol, or watching her talk with the same title. That said, there are two main aspects worth emphasizing for the sake of understanding this study.

1. The essence of consensus in SCP lies in the intention of nodes to stay in agreement (“trusting”) with other nodes, a property that transitively connects the entire network. Unlike proof-of-work algorithms, computational work is not required to guarantee safety. Optimizations can be made to the performance of the protocol without being cancelled out by side effects such as increasing difficulty.
2. With message passing being an integral part of the protocol and the consensus round time being as short as 3–5 seconds, a large number of messages will need to be transmitted, received, and possibly acted upon in a small window of time.

The goal of the study was to arrive at a generalized Wh-per-transaction estimate for the core of the Stellar network, and through the process formulate and assess a method for doing so.

The study is limited to estimating the running electricity consumption of the Stellar network (stellar-core), and does not include estimates associated with the larger life cycle of hardware, the construction of data centres or ICT infrastructure, nor with possible implicit impacts from e.g. replacing other financial infrastructure. Neither does it include the electricity consumption of running Horizon, Stellar's API layer, nor investigate electricity consumption of re-ingestion of history or other fault-handling mechanisms.

At the core of the study lies the assumption that we can approximate the energy consumption of a single validator node as the sum of the electricity consumption of computation (CPU), memory usage (RAM), storage (HDD/SSD), and the network traffic.

Once an estimate of the electricity consumption of a single node was constructed, it was used to construct a bottom-up estimate of the entire network. Simply put, the estimated average electricity use of a single node was multiplied with the number of nodes on the network. This linear extrapolation was in part justified within the limits of this study by a community survey.

To construct an estimate of the electricity consumption of a typical basic validator node, a dedicated server was rented at Hetzner, and measurements were made during a period of roughly six weeks. Most of the scripts used can be found at the GitHub repository wanecek/eitl01-scripts.

The electricity usage of CPU and RAM were estimated using software-based measurements using the Intel RAPL interface, with the electricity usage sampled for 1-second intervals every 0-5 seconds at random. The random delays were added to distribute sampling across different phases of a consensus round.

The electricity usage of storage was estimated through assuming a constant power consumption of a hard-drive of 6.5 W, regardless of disk capacity or read-write frequency, as shown appropriate by the US Data Centre Energy Usage Report.

To account for indirect energy usage in data centers such as cooling, the consumption of CPU, RAM, and storage were multiplied by a global average data center power usage efficiency (PUE) of 1.67.*

Lastly, to account for the electricity used when transmitting messages on the global ICT infrastructure, network power consumption was estimated using a general kWh/GB conversion factor. I used a coefficient of 0.06 kWh/GB.

Additionally, through sending out a community survey, we received a general overview of what hardware a typical validator node runs on, how much network data is transmitted/received, as well as the level of system resource usage.

Measurements from a single node suggest that with the selected coefficients, network traffic is by far the largest source of power consumption – on average responsible for 94% of power consumption.

This figure was then extrapolated across the (at the time of the study) 132 active nodes on the network. Since the survey suggested that network traffic is about the same for all nodes, regardless of whether they are a basic or full validator, we dare to approximate the complete network traffic (and hence electricity consumption) by multiplying our estimates with the number of validator nodes.

It was especially interesting to note that similar volumes of traffic were recorded for our outlier node (which no other validator node on the network had added to their quorum set) as some of the Tier 1 nodes (which many other validator nodes on the network have added to their respective quorum sets). It is worth emphasizing that these assumptions are tied to a discrete point in time and may not hold true as the network grows.

Finally, with the above results in mind, we arrived at a total mean electricity consumption per transaction of 0.222 Wh per successful transaction, or a mean total power consumption of 186.5 W per node, or 24.6 kW for the entire network.

With understanding of the consensus algorithm’s design, relying on message passing rather than computational work, it becomes clear that arbitrary, complex computational work is not going to contribute to power consumption like it does in proof-of-work algorithms. Moreover, the absence of built-in rebound effects such as a self-regulating difficulty allows for further optimizations.

The results indicate that message-passing most significantly contributes to the electricity consumption of the network. That said, it is important to first discuss the validity of said results, as well as what conclusions can rightfully be drawn from the results.

With some uncertainty regarding the network Gb-to-kWh coefficient, we cannot with high confidence determine exactly how large a part of the electricity consumption is attributable to network traffic. If the real value is 2x, 5x, or 10x smaller, network traffic would instead be accountable for 89 %, 76 % or 62 % respectively. Still, the results seem to clearly indicate that network traffic is a significant factor of Stellar’s electricity consumption, despite the extent being uncertain. The fact that other node runners reported similar ranges of traffic volume (roughly 100 GB per day) strengthened the hypothesis that the network traffic can roughly be approximated linearly across the network.

Similar uncertainty exists when it comes to the power-measurements of CPU and RAM. Intuitively, the figures reported were quite low, together contributing an average of just less than 4 W. However, just like reported by other validator nodes, the average measured CPU load was less than 10 %, with high spikes followed by short near-idling periods. It is possible that at such low system loads, other components of the server hardware become just as significant as the CPU and RAM, which is why readings from a physical power meter would be interesting, as well as measurements done on a greater variety of hardware (one node runner even reported running stellar-core on a Raspberry Pi). Again, while the exact precision of the number is questionable, the results indicate that neither the CPU nor RAM usage significantly contribute to the electricity consumption of the network at this point.

To improve the accuracy, precision, and relevance of the results, I would recommend future studies to take the following measures:

• Verify the software-based power-measurements of a server with physical readings using a watt-meter. There is some uncertainty regarding the precision of the readings from the Intel RAPL interface, and how well it represents the entire server. Although previous studies have shown that Intel RAPL is a good indicator of total machine power consumption, they’ve done so at higher workloads. A variety of hardware and physical readings would bring greater confidence to the estimate.
• Record additional variables, such as type of operation and number of balloting rounds, to better understand what network activity requires more electricity consumption. This may reveal additional areas of optimization.
• Model or simulate how the electricity consumption is affected by the network growth. Simulation and theoretical models on the impact of network growth (more nodes, higher bandwidth, and a longer ledger history) on the Stellar network’s total electricity consumption would better account for Stellar’s capacity to support a larger portion of the global financial infrastructure, and highlight where efforts to decrease the electricity consumption should be focused.
• Apply a more up-to-date coefficient for the electricity of network traffic.
• Allow validators to publish data that aids in understanding the network. Better insight into how much data traffic is sent/received by each node, what hardware they’re running, system resource usage, and similar data points could help understand variations in the network and how to with better precision extrapolate the electricity consumption across the network, without having to measure the electricity of each node.
• Include Horizon and ledger-storage of data from full validators. This would expand the scope of the estimate to better include the entire network.

On a large scale, we can see that overall electricity consumption of the Stellar network remains low, with resource usage being comparable to that of a regular web-server. It seems that Stellar has successfully decoupled decentralization from extreme power consumption and, as such, it is a protocol that other blockchain implementations — in or outside of fintech — could draw from.

To put the numbers for electricity usage per transaction into a context, one can compare them to similar services. When doing so it is important to note that this is, in some ways, comparing apples to pears. For example, when comparing to VISA, one should arguably include Horizon – Stellar’s API layer – for a fairer comparison. However, it does provide an intuition regarding the magnitude of Stellar’s electricity consumption.

Despite a few sources of uncertainty in the study, the results clearly indicate that Stellar has successfully decoupled extreme electricity usage from decentralization in its consensus algorithm. There are still several areas where improvements can be made to further reduce the electricity consumption of the entire network, perhaps by reducing duplicate traffic in the overlay network. It is my hope that the SDF and the Stellar ecosystem can continue this work to better understand and to further expand the Stellar network, while ensuring it remains a sustainable technology.‍

The Stellar Development Foundation would like to thank Wilhelm for all the hard work and research he put into composing his thesis and putting this blog post together. With his findings, Wilhelm has opened the door to understanding how energy is used by the Stellar network, and we wholeheartedly agree that if Stellar is to be an integral part of an increasingly digitized financial system, we must measure and continually improve on environmental sustainability. We are supporting additional research and academic analysis to paint a more complete picture of energy usage – and by extension, sustainability – of the Stellar network.

–––

* Reference: R. Bashroush and A. Lawrence, "Beyond PUE: tackling it's wasted terawatts.," Tech. rep., Uptime Institute, 2020.

**Different scientific studies arrive at significantly different values for this coefficient depending on e.g. the methods used, the age of the study, and the scope included in measurements. For the sake of this study, I used a coefficient of 0.06 kWh/GB. This was chosen based on a comprehensive review study authored by Joshua Aslan et al. There is reason to be fairly confident that this real value has decreased since then, as the global volume of traffic has increased significantly while the total power consumption is believed to have remained fairly flat. As such, it is recommended to be viewed as an overestimate, although at this point, I cannot specify by how much.