Quantifying Ethereum Energy Consumption via Network Mapping

• “Information Infrastructure” appears repeatedly in the supplied text.Source: A Node-Level Estimate from Crawlable… · p. 1
• A Karlsruhe, Germany location and a partially shown FIZ email address appear in the text.Source: A Node-Level Estimate from Crawlable… · p. 1
• Dennis Trautwein is listed with ProbeLab Analytics OÜ.Source: A Node-Level Estimate from Crawlable… · p. 1

• Network measurement is listed as a concept area.Source: CCS Concepts · p. 1
• Peer-to-peer architectures are listed under computer systems organization.Source: CCS Concepts · p. 1
• Power and energy are listed under hardware.Source: CCS Concepts · p. 1

• Ethereum and proof of stake are listed as keywords.Source: Keywords · p. 1
• Energy estimation and network crawling are listed as keywords.Source: Keywords · p. 1
• Random Forest and MiCAR are listed as keywords.Source: Keywords · p. 1

1 Introduction

• Ethereum’s Merge cut electricity use by about 99.95%, while MiCAR requires energy information and updated figures from service providers.Source: §1 · p. 1
• Existing models use a weighted wattage or aggregated headcounts, rather than peer-advertised metadata such as client, architecture, OS, and validator signals.Source: §1 · p. 2
• The estimate covers peers dialable on mainnet, present in both layer crawls, and assigned a rule label or forest imputation.NAT-only clients, one-layer rows, and churn between crawl sessions are outside this snapshot lower bound.Source: §1 · p. 2
• The pipeline assigns wattage from crawlable peer attributes, uses provider attribution across fourteen providers, separates ARM and x86 profiles, and reads validator activity from subnet and gossip signals.Source: §1 · p. 2

Post-Merge energy models

• Earlier models scale measured wattages by a network-wide headcount or assume how hardware pairs are distributed, rather than reading attributes of named peers.The CCRI merge report supplies idle baselines and client power increments reused by later estimates, carrying forward limitations of its small set of chassis and missing clients.Source: §2 · p. 2

Earlier multi-chain estimates

• Platt et al. [86] assume one machine per validator, while Ibáñez and Rua [55] retain a global hardware mix; both avoid reading attributes from named peers.The one-machine-per-validator assumption raises totals relative to models allowing multiple validators per host [82].Source: §2 · p. 2

Cambridge’s estimate

• The closest running estimate, CBNSI, combines CCRI wattages with beacon-node crawling and hardware-mix counts, but groups ARM with x86 and omits peer-level hosting and validator bitvectors.Those omitted attributes distinguish low-power home systems from high-memory cloud instances.Source: §2 · p. 2

Cloud models

• Pankovska et al. [82] model cloud-versus-home power and data-centre overhead, but cover AWS and use monitoring counts rather than instance-level peer attribution.This pipeline extends cloud attribution to fourteen providers and separates ARM and x86 hosts.Source: §2 · p. 2

Measurement and peer-level data

• Prior work calls for measured hardware and observed machine mixes, while peer-granularity crawls and IP-range attribution already provide information that energy models replace with a mix.Hoffmann and Majuntke [54] benchmark under controlled conditions and evaluate compact models on runtime-observable attributes without production power telemetry.Source: §2 · p. 2

3 Method

• The four-step pipeline crawls both layers, extracts peer attributes, assigns measurement-based wattages when fields are complete, and imputes the remaining rows with a trained forest.The paper reports that code and datasets are public.Source: §3 · p. 3

3.1 Crawl and features

• Nebula crawls collected consensus-layer records on 19 June 2026 and execution-layer records on 22 June 2026, including Identify fields, ENRs, and crawler metadata.The crawls recorded 232,831 consensus-layer visits and 127,911 execution-layer visits.Source: §3.1 · p. 3
• Layer records are inner-joined by address and occurrence index, an assumption because 54% of shared addresses had different consensus- and execution-record counts.The reachable set excludes peers that do not answer, and the method retains rather than drops unmatched rows.Source: §3.1 · p. 3

3.2 Power assignment

• Rule wattages require identifiable clients, architecture, and operating system; incomplete rows go to the forest, while unclassified hosts are treated as physical machines without a hypervisor.That unclassified-host choice overstates the home and bare-metal share when smaller clouds are missing from provider lists.Source: §3.2 · p. 3, §3.2.1 · p. 3

3.2.1 Bare-metal nodes.

• Bare-metal rules use CCRI idle baselines and client power increments, with a 0.91 adjustment for two clients sharing a host and a 0.75/0.25 mix of configurations 5 and 6.The 10 W ARM Linux assignment comes from a Raspberry Pi 5 measurement; other ARM Linux boards are not separate classes.Source: §3.2.1 · p. 3

3.2.2 Cloud nodes.

• Cloud wattage uses provider-specific component models and role-based minimum hardware; validator flags select cloud hardware minima.The AWS calculation uses selected m6i/r6i instances for x86 and Graviton measurements for ARM, while other providers use the CCF component model.Source: §3.2.2 · p. 4

3.3 Random Forest for incomplete peers

• Incomplete peers are imputed with a 500-tree Random Forest using five categorical fields and numeric subnet and gossip-topic counts, with encoder and model fitted only on training data.On hold-out rows, client, architecture, and operating-system fields are hidden to match incomplete-peer information.Source: §3.3 · p. 4

3.4 Empirical power measurement

• The wall-power check records 24-hour traces from two synchronised client pairs and an idle baseline on one Windows 11 x86 gaming desktop.A six-hour Raspberry Pi Zero 2W light-client trace bounds remote-RPC light-client draw but is not intended to validate the 10 W ARM Linux full-node assignment.Source: §3.4 · pp. 4–5

4.1 Crawl coverage

• 3,110 peers receive rule labels and 3,824 receive forest estimates among 6,940 matched peers; six invalid rows are excluded.The coverage table concerns the 19/22 June 2026 crawl.Source: §4.1 · p. 5, Table 7 · p. 5

4.2 Network-level estimate

• 46% of CCAF/CBNSI’s approximately 0.90 MW estimate is covered by the snapshot; similar mean watts imply that most of the gap is coverage.A single-record-per-address join gives 4,898 peers and 297 kW; 54% of shared addresses have different consensus- and execution-record counts.Source: §4.2 · p. 5
• 415 kW (3.63 GWh/year) is the estimated draw of 6,934 valid matched peers, 3.9% below the 431 kW uniform Lighthouse+Nethermind x86 assignment.The comparison uses the same peers; Table 8 compares reachable-peer power with a uniform assignment and the CCAF/CBNSI index.Source: Table 8 · p. 5, §4.2 · p. 5

4.3 Wattage shares

• 15.6% of watts come from AWS peers (12.2% of peers), while validator-flagged peers account for 31.4% of watts (25.7% of peers).Hetzner averages 42.9 W and accounts for 11.9% of watts; labeled wattage clusters mainly between 60 W and 70 W, with a tail to 106.9 W.Source: §4.3 · p. 5
• Hosting provider ranks highest in both forest importance measures; Besu is 18% of the labeled execution-client mix and can draw up to three times the Geth/Nethermind extra watts.The Germany-based crawler may over-represent nearby European hosts.Source: §4.3 · pp. 5–6, Figure 1 · p. 6

4.4 Sensitivity

• 24% is the increase in labeled-set power when the assumed hardware mix changes from 0.75/0.25 to 0.50/0.50.Cloud PUE, AWS utilisation, and the validator-aware mix for unclassified hosts move the labeled total by a few percent; the ARM Linux 10 W point is negligible.Source: §4.4 · p. 6, Table 11 · p. 6

4.5 Imputation

• 4.3 W is the forest MAE on held-out labeled peers when client, architecture, and operating system are hidden.This measures agreement with rule wattages; hiding the hosting provider instead yields MAE 9.3 W and R2 = 0.48.Source: §4.5 · p. 6, Table 12 · p. 6

4.6 Empirical comparison

• 19.0% and 18.5% are the desktop-trace deviations after subtracting the 33 W idle graphics-card draw.The remaining residuals have opposite signs: −14.26 W for Nimbus+Geth and +9.93 W for Prysm+Nethermind.Source: §4.6 · p. 6

5 Discussion

• 415 kW (3.63 GWh/year) is 3.9% below the uniform Lighthouse+Nethermind x86 estimate and about 46% of CCAF’s ∼0.90 MW, mainly because this crawl sees fewer nodes.Mean watts remain near 60 W in both estimates; the total covers peers reachable and matched across both layers.Source: §5 · pp. 6–7
• Flattening the CCRI 0.75/0.25 hardware mix to 0.50/0.50 moves the labeled total by 24%, while AWS and validator-flagged peers account for a larger share of watts than peers.Hetzner and OVH sit in the lower half of the labeled histogram, while AWS accounts for the tail above 100 W; validator-flagged peers average 73.1 W versus 55.2 W for others.Source: §5 · pp. 6–7
• The forest’s masked hold-out MAE is 4.3 W when client, architecture, and operating system are hidden; hosting recovers most of the label, but omitting the provider leaves the imputer weak.The visible-field scores measure agreement with assignment rules, not with a meter.Source: §5 · p. 7
• After subtracting the published 33 W GPU idle, the desktop’s non-GPU idle is about 38.1 W against the pipeline’s 38.3 W x86 idle; remaining client residuals have opposite signs.The 24-hour traces compare measured power with model predictions and an idle baseline.Source: §5 · p. 7, Figure 2 · p. 7, Table 14 · p. 7

5.1 Limitations

• The wattage rules are published-measurement proxies, not per-peer meter readings, and the three-day-separated crawls can mismatch records across layers.A different record count appears on the two layers for 54% of shared addresses.Source: §5.1 · p. 7
• The validation covers one gaming desktop, not cloud or ARM full nodes, and the rules omit extra CPU costs from attestation topics beyond the validator hardware step.The 33 W GPU offset is specific to this chassis; active crawls also miss nodes that never accept inbound connections, with no count available for that hidden population.Source: §5.1 · pp. 7–8, §5 · p. 7

6 Conclusion

• The 500-tree forest trained on 3,110 labels covers 99.9% of matched peers; hidden-field hold-out MAE is 4.3 W against rule wattages.With rule-defining fields visible, hold-out R2 is 0.9909 and five-fold R2 is 0.9890 ± 0.0074; these scores measure agreement with rules, not a watt-meter.Source: §6 · p. 8
• 415 kW (3.63 GWh if held for a year) across 6,934 peers is 3.9% below uniform x86 wattage and about 46% of CCAF’s index.The comparison uses the same Lighthouse and Nethermind x86 wattage for every peer as the uniform baseline.Source: §6 · p. 8
• After subtracting a 33 W GPU idle estimate, 24-hour means remain about 19% from predictions; traces come from one gaming desktop.The paper identifies headless Linux traces, all-attestation-subnet watts, and a same-day passive-listener crawl as remaining needs.Source: §6 · p. 8
• The measured 3.63 GWh/year exceeds MiCAR’s 0.5 GWh/year threshold; the paper says service providers using Ethereum Tokens must disclose sustainability and extend results with grid-mix data.Source: §6 · p. 8
• The estimation model, crawls, tables, and traces are publicly available.Source: §6 · p. 8

A Cloud assignment tables

• Tables 15–16 cover the AWS node-power equation’s variables and the EC2 instances retained for its estimation.Tables 15 and 16 define Equation (2) symbols and list retained instances.Source: Table 15 · p. 11, Table 16 · p. 11, A Cloud assignment tables · p. 11
• Tables 17–20 cover non-AWS equation variables, hyperscaler per-vCPU wattages, SPECpower-derived microarchitecture wattages, and provider-specific CPU microarchitectures.The listed microarchitecture entries include Ice Lake 3.7582, Sapphire Rapids 4.1605, and Skylake 4.1042.Source: Table 17 · p. 11, Table 18 · p. 11, Table 19 · p. 11

B Hold-out scatter

• Figure 3 plots predicted versus rule-based power for 622 held-out nodes with the rule-label fields visible.Source: Figure 3 · p. 12

C Light-client bound

• Helios adds 0.01 W over the Raspberry Pi Zero 2W’s 0.83 W idle mean, an order of magnitude below the 10 W ARM Linux full-node assignment.The 0.84 W Helios mean reflects a remote-RPC light client, not an ARM full node; the Pi could not compile Helios, so its binary was cross-compiled for aarch64.Source: C Light-client bound · p. 12
• Figure 4 shows Raspberry Pi Zero 2W power over six-hour idle and Helios windows.Source: Figure 4 · p. 12, C Light-client bound · p. 12

D Subnet subscription counts

• Tables 21 and 22 list sync-committee and attestation subnet subscriptions, respectively.Source: Table 21 · p. 12, Table 22 · p. 12