Energy Benchmarks for the IOTA Network (Chrysalis Edition)

TL;DR

In our tests, a Raspberry Pi 4 node uses just over a millionth of a kWh per IOTA message/transaction, including proof-of-work costs. For comparison, making one mug of coffee in a single-serve machine uses about .024 kWh (nearly 22,000 times as much energy).

Executive Summary

There is increasing, and appropriate, scrutiny of the energy footprint of cryptocurrency networks. At the IOTA Foundation, we place an emphasis on low energy requirements and green use cases.

• Digitizing measurement, reporting and verification of sustainability performance (Digital MRV) in Chile, funded by the Canadian government.
• Tracing the path of energy from production in solar panels to consumption in electric vehicles in Trondheim, Norway, with Jaguar Land Rover, Engie Lab Crigen, and Entra ASA.
• Improving efficiency in the supply chain and allow goods to travel more freely across borders with Zebra Technologies.
• Reducing supply chain friction from Kenya to the Netherlands, speeding up goods transfer, and reducing waste of fresh produce with Trademark East Africa.

External research has previously demonstrated the low power consumption of the pre-Chrysalis IOTA network. The recent Chrysalis upgrade removes many inefficient aspects of the protocol and should further improve energy efficiency. However the IOTA Foundation has traditionally refrained from posting any energy efficiency figures publicly, as measurement is complex and nuanced. The figures can vary considerably depending on the network toplogy and the load.

Given the recent interest in this topic and in response to community requests, we have decided to publish our internal metrics, gathered during Chrysalis development. These metrics demonstrate a significant reduction in energy consumption as a result of the upgrade.

IOTA is designed to be lightweight and a Hornet node can run on low-power devices like Raspberry Pis.

• Running a Hornet node on a Raspberry Pi 3 or 4 with no transactions being issued uses a negligible amount of energy.
• If a Raspberry Pi 4 node is not performing remote proof-of-work, the energy requirement is as low as 1.18 milliJoules per transaction/message at 100 messages per second (MPS). This equates to \(3.28 x 10^{^{-10}}\) kWh or in easier terms, less than a billionth of a kWh.
• If a Raspberry Pi 4 is performing remote proof-of-work, the energy requirement is as low as 4.026 Joules per transaction/message. This equates to \(1.1 x 10^{^{-6}}\) kWh or in easier terms, just over a millionth of a kWh.
• The reduction in energy consumption due to the Chrysalis upgrade (in different testing scenarios) is between 33% and 95%.

Note: These figures should be seen only as a ballpark and a comparison with the pre-Chrysalis network. They are a starting point for a conversation, and by no means exhaustive. The main limitations are that:

• We used Raspberry Pis for the nodes (for ease of measurement) in a simple configuration, while most nodes are run on cheap VPSs and with a more complex network topology.
• The energy usage is unlikely to scale linearly with network load.

Introduction

The second phase of the Chrysalis upgrade introduced many changes to the IOTA protocol. These changes aim to simplify the transition to Coordicide, improve the developer experience, and accelerate industry adoption. But one very important feature is the substantial performance improvements. Upgrades such as the transition to binary logic (as opposed to ternary), as well as the usage of Ed25519 signatures instead of W-OTS, reduce much of the computational load that HORNET nodes need to carry in order to keep the network alive.

This benchmark analysis aims to compare the impact of these on the energy consumption of HORNET nodes running on Raspberry Pis.

Methodology

1) Laptop HORNET Coordinator

The IOTA network used in this benchmark can be seen as a Private Tangle. It must not be confused with the mainnet, devnet, Chrysalis network, or Pollen network.

A Hornet Coordinator node was deployed on a personal laptop computer (x86-64 Intel Core I9, 40GB RAM). Since the Coordinator will be removed on Coordicide, it was not included in the energy benchmark.

2) Raspberry Pi HORNET nodes

The benchmark was performed with one Raspberry Pi 3B+ (4 Cores ARM Cortex-A53 1.4 GHz) and one Raspberry Pi 4 (4 Cores ARM Cortex-A72 1.5 GHz), in order to achieve a degree of variability in regards to the collected data. They were connected together into the same Local Network Area (LAN - 33.42Mbs Down, 3Mbs Up, combination of cat5e and cat6 cabling), where they could also communicate with the laptop (ie the Coordinator).

All measurements were repeated with the Hornet nodes set up as pre-Chrysalis (v0.5.6) and post-Chrysalis (v0.6.0) nodes.

The pre-Chrysalis Hornet nodes had the following fixed parameters:

• Merkle Tree Depth = 13
• Security Level = 2
• Interval = 10s

The post-Chrysalis Hornet nodes had the following fixed parameters:

• Interval = 10s
  (Merkle Tree Depth and Security Level are no longer parameters on Chrysalis Pt.2)

In order to avoid low performance and reliability issues of regular SD cards, RasPiKey eMMC Modules (16Gb) were used as storage devices for the Raspberry Pis.

The operating system was a minimalistic custom Linux Distribution based on OpenEmbedded, which allowed efficient allocation of CPU power as a result of the absence of unnecessary software components. The utilised kernel was linux-raspberrypi v5.4.72 with no customizations applied to the build system. The rootfs was based on the honeycomb-image-minimal.bb BitBake recipe, which inherits from Poky’s core-image-minimal.bb recipe.

3) Power Consumption Measurements

In order to perform accurate measurements of the power consumption of each HORNET node, a custom breadboard circuit was set up. The power consumption of each Raspberry Pi was measured with a Texas Instruments INA219, leveraged with a breakout board by Adafruit.

A BeagleBone Black was used to collect the measurements from the INA219 sensors via i2c bus.

An XL4016 module was used to step down a 12V,10A switching power supply to 5V while keeping a high output load current (max 8A).

The INA219 sensors work by measuring the voltage drop of a 0.1 Ohm Shunt Resistor inserted between the Raspberry Pi’s Vcc and the XL4016’s Vcc.

A reference measurement of the power consumption of both Raspberry Pis was collected, without running any Hornet nodes. All measurements were collected over a period of 10 minutes.

Figures 1 and 2 outline the experimental setup.

4) Proof of Work and Spam Rate

Proof-of-work (PoW) is defined as the repeated computation of hashes in order to find the nonce that validates a candidate transaction/message (here, transactions are used in the pre-Chrysalis context, while messages are used in the post-Chrysalis context). As a protocol, IOTA (both pre- and post-Chrysalis) allows the PoW calculation to be performed either by the node or the client.

When PoW is performed by the node, the intense computational load is expected to impose a significant increase in energy consumption on the Raspberry Pis. When PoW is performed by the client, the node is only responsible for propagating the transactions/messages.

On pre-Chrysalis IOTA, the Minimum Weight Magnitude (MWM) determines the computational load required for PoW calculation. For every Transaction, an average of 3^MWM hashes need to be calculated to find a valid nonce. Currently, the pre-Chrysalis mainnet uses MWM=14 (ie 3^14 = over four million hashes).

On post-Chrysalis IOTA, we now have variable length messages and the PoW is adapted to the length of the message. A new parameter, called PoWScore, replaces MWM. A PoWScore of X means that for every byte of the message, on average X hashes need to be calculated until a valid nonce is found. The current Alphanet uses a PoWScore equal to 4000 (ie 4000 hashes/byte).

One of the main functions of PoW is to reduce the ability of bad actors to spam the network with meaningless transactions/messages, since a significant amount of computational load will have to be allocated for a relatively long period of time. Therefore, reproducing the mainnet/alphanet values of MWM/PoWScore is useful for measuring the impact of PoW on the energy consumption on the Raspberry Pis.

In order to measure the power consumption of the Hornet nodes while they perform PoW, two simple Spammer Clients were written:

• Pre-Chrysalis: iota_pyspammer
• Post-Chrysalis: iota_rspammer

Both clients were executed from the same laptop running the Coordinator (note: the spam was directed at the nodes, with no direct connection between the clients and Coordinator).

Reproducing mainnet/alphanet PoW parameters (MWM/PoWScore) is significantly prohibitive to the spam rate (transactions/messages per second), regardless of whether PoW is calculated by the node or client. On the other hand, it is also desirable to evaluate the impact that the propagation of new transactions/messages has on the energy consumption of the Hornet nodes, without necessarily taking PoW into consideration.

Therefore, a second scenario was also evaluated, whereby the Coordinator’s spammer plugin was enabled at a spam Rrate of 50 and 100 transactions/messages per second, and the spammer clients were not used at all. We call this scenario “Easy PoW”, and the Coordinator was responsible for all the PoW. The nodes were set with the following PoW parameters:

• Pre-Chrysalis: MWM = 10
• Post-Chrysalis: PoWScore = 50

Results

1) Reference

Table 1 below displays the reference measurements collected when the Raspberry Pis were turned on without any Hornet nodes running, with power consumption in milliWatts.

Table 1: Reference - No HORNET Node

2) Pre-Chrysalis

Figure 3 displays two graphs showing the power consumption over time of each Raspberry Pi in four different scenarios, all in the pre-Chrysalis mode:

• Reference, where no Hornet node was running.
• Resting, where the Hornet nodes were running, however with no incoming transactions
• 50 transactions per second, with Easy PoW (MWM = 10) being performed by the Coordinator.
• 100 transactions per second, with Easy PoW (MWM = 10) being performed by the Coordinator.
• Mainnet PoW (MWM = 14) being performed by the Raspberry Pis.

Tables 2, 3, 4 and 5 tabulate the data from Figure 3.
Table 2 contains the Average Power of the Raspberry Pis while no Transactions were being issued to the HORNET nodes.

Table 2: Pre-Chrysalis – No Transactions

Table 3 refers to the Easy PoW scenario, with the Coordinator performing all the PoW and the Raspberry Pis only responsible for propagating 50 TPS.

Table 3: Pre-Chrysalis – Easy PoW by Coo (50 TPS)

Table 4 refers to the Easy PoW scenario, with the Coordinator performing all the PoW and the Raspberry Pis only responsible for propagating 100 TPS.

Table 4: Pre-Chrysalis – Easy PoW by Coo (100 TPS)

Table 5 represents the average power required by the Raspberry Pis while performing the mainnet PoW. It also displays the average TPS rate that each Raspberry Pi was able to achieve under these conditions.

Table 5: Pre-Chrysalis – Mainnet PoW performed by Raspberry Pi

3) Post-Chrysalis

Figure 4 displays two graphs with the power consumption over time of each Raspberry Pi in four different scenarios, all in the post-Chrysalis mode:

• Reference, where no Hornet node was running.
• Resting, where the Hornet nodes were running, however with no incoming messages
• 50 messages per second, with Easy PoW (PoWScore = 50) being performed by the Coordinator.
• 100 messages per second, with Easy PoW (PoWScore = 50) being performed by the Coordinator.
• Mainnet PoW (PoWScore = 4000) being performed by the Raspberry Pis.

Tables 6, 7, 8, and 9 tabulate the data from Figure 4.
Table 6 contains the average power of the Raspberry Pis while no messages were being issued to the Hornet nodes.

Table 6: Post-Chrysalis – No Transactions

Table 7 refers to the Easy PoW scenario, with the Coordinator performing all the PoW and the Raspberry Pis only responsible for propagating 50 MPS.

Table 7: Post-Chrysalis – Easy PoW by Coo (50 MPS)

Table 8 refers to the Easy PoW scenario, with the Coordinator performing all the PoW and the Raspberry Pis only responsible for propagating 100 MPS.

Table 8: Post-Chrysalis – Easy PoW by Coo (100 MPS)

Table 9 represents the average power required by the Raspberry Pis while performing the Chrysalis alphanet PoW. It also displays the average MPS rate that each Raspberry Pi was able to achieve under these conditions.

Table 9: Post-Chrysalis – Alphanet PoW by Raspberry Pi

Discussion

1) Data Normalization

In order to evaluate the relative difference of energy consumption during each scenario, we subtract the reference average power consumption from each measurement.

Table 10: Pre-Chrysalis – Normalized from Reference

Table 11: Post-Chrysalis – Normalized from Reference

Here we notice that regardless of the IOTA Protocol (pre- or post-Chrysalis), the Raspberry Pi 4 tends to consume less power than the 3 (with the exception of 0 TPS/MPS). That is likely due to optimizations on the different CPU architectures, where the RPi4 has ARM Cortex-A72 cores and the RPi3 has Cortex-A53.

2) Energy per Transaction / Message

If we consider that (1):

\[ Power [W] = Energy [J] / Time [S] \]                  

We can estimate the actual energy consumed by each transaction/Mmessage. First, we normalize each measurement again by subtracting them from the Resting Hornet consumption (0 TPS/MPS).

Table 12: Pre-Chrysalis Normalized from 0 TPS

Table 13: Post-Chrysalis Normalized from 0 MPS

We already know the spam rate on the Easy PoW scenarios (100 TPS/MPS), so we can assume that one transaction takes 1/100 second in duration. The same logic applies for 50 TPS/MPS. We can look at Tables 5 and 9 to find out the average TPS for the mainnet/alphanet scenarios and apply the formula (1).

Tables 14 and 15 display the estimated energy consumption per transaction in the pre-Chrysalis and post-Chrysalis contexts.

Table 14: Pre-Chrysalis Energy per Transaction

Table 15: Post-Chrysalis Energy per Message

3) Relative Analysis

We can finally compare the measurements in a relative fashion, in order to quantify the reductions of power and energy consumption in terms of percentages. For example, let’s call some pre-Chrysalis measurement A and call the corresponding post-Chrysalis measurement B. The relative difference C is given as:

\[ C = 100 * \frac{A - B}{A} \%\]

Table 16: Relative Difference of Power consumption at 0 TPS/MPS

Table 17 shows the relative difference of the power consumption of the three spamming scenarios, all normalized from 0 TPS/MPS.

Table 17: Relative difference of power consumption of the three spamming scenarios, all normalized from 0 TPS/MPS.

Table 18: Relative difference of energy consumption of the three spamming scenarios.

Conclusion

No significant differences were noticed in regards to the power consumption of resting Hornet nodes (0 TPS/MPS).

Significant differences were noticed in regards to both power and energy consumption on the three different spamming scenarios. The post-Chrysalis Hornet nodes performed more efficiently, reducing power and energy consumption by more than 50% in most scenarios.

Differences in performance were also noticed in relation to hardware, where the Raspberry Pi 4 performed slightly better than the Raspberry Pi 3.

The most significant optimization happened when the mainnet/alphanet PoW parameters were reproduced. That happened not only because of the reduction in power consumption. But also because post-Chrysalis messages were issued much faster than pre-Chrysalis transactions. Since energy is equal to power x time, less time issuing messages incur in less energy spent.

One very important remark is that we should resist the urge for any assumptions regarding linearity of these measurements. It is not necessarily true that 10 TPS/MPS will result in 10 times the energy consumption of 1 TPS/MPS, for example. That is very explicitly illustrated by the relationship between the energy consumption of the 50 TPS/MPS and 100 TPS/MPS measurements.

Overall, we conclude that Chrysalis results in very significant optimizations to the IOTA protocol, both in terms of power and energy consumption.

IOTA: Discord | Twitter | LinkedIn | Instagram | YouTube