Skip to main content

Glossary

Definitions for the technical terms used across StereumLabs documentation, dashboards, and blog posts. Where a term has a precise Ethereum-protocol definition, this glossary tries to stay consistent with the official specs and links to them; where a term is StereumLabs-specific (e.g., run, environment profile), the definition is normative for this site.

If you find a term used in our docs that isn't defined here, let us know at contact@stereumlabs.com.

A​

Aggregation window​

The time window over which a panel computes a derived metric. Typical aggregation windows on StereumLabs dashboards: 30s mean for resource panels, 5m rate for counter-derived panels, 24h percentile bands for stability views. Aggregation windows are always documented per panel (see Data Cadence & Retention).

Archive node​

An Ethereum node that retains the entire historical state (every block and the world state at every block), as opposed to a pruned or full node which only keeps recent state. Erigon is best known for compact archive layouts via its MDBX-backed pipelined sync; other ECs offer archive modes with different storage trade-offs. Archive nodes serve debug_traceCall, eth_getProof at historical blocks, and similar deep-history RPC methods.

Attestation​

A signed message by a validator stating its view of the chain head and finality checkpoints in the slot it was assigned to. Successful attestations contribute to a validator's rewards; missed or late attestations reduce them.

B​

Bare-metal​

Physical hardware operated under StereumLabs' direct control, as opposed to virtualized cloud instances. Our bare-metal baseline runs at the NDC2 datacenter in Vienna, Austria, on declared hardware (Epyc 9654P, ECC DDR5, ZFS raidz1, dedicated NICs). See List of VMs.

Beacon chain​

The Proof-of-Stake consensus chain that runs on the consensus layer, coordinating validator duties, finality, and (post-Fusaka) data availability sampling.

Block age​

The wall-clock time from the start of a slot to the moment an execution client first observes the block via gossip. A useful diagnostic for separating network delays from local processing delays.

Blob​

A binary large object attached to an Ethereum transaction, introduced with EIP-4844. Each blob carries roughly 128 KB of data on the consensus layer (not in execution layer state), so it does not permanently bloat the EVM world state. Used primarily by Layer 2 rollups to post transaction data cheaply.

BPO (Blob Parameter Only)​

A scheduled hardfork variant that only changes blob-related parameters (target, max). EIP-7892. Lets blob capacity grow between major hardforks without other protocol changes.

Bucket​

(StereumLabs-specific) An isolated scenario container that pins versions, flags, and environment so multiple runs can be compared. Buckets are how we keep historical comparability when the methodology evolves.

C​

CC (Consensus Client)​

The Ethereum consensus-layer client. Handles fork choice, finality, attestations, and (post-Fusaka) PeerDAS sampling. StereumLabs covers six CCs: Grandine, Lighthouse, Lodestar, Nimbus, Prysm, Teku.

Caplin​

Erigon's built-in consensus-layer implementation, distributed as part of the Erigon binary rather than as a separate CC. A Caplin "standalone" node collapses EL and CL into one binary and one MDBX database. See the Caplin standalone deep-dive.

Checkpoint sync​

A consensus-client startup mode where the node downloads a recent finalized state from a trusted source (instead of replaying the chain from genesis), then backfills history in the background. Used by all major CCs.

Custody group / custody column​

(PeerDAS) A subset of the 128 data columns that a particular node is responsible for storing and serving. Non-validating nodes custody 4 groups; supernodes custody all 128.

D​

Data column sidecar​

A piece of a blob (one of 128 columns generated via erasure coding) attached to a beacon block. Sidecars are the unit of PeerDAS sampling and gossip.

Delayed metrics​

(StereumLabs-specific) The Free plan's Prometheus datasource exposes a small set of pre-recorded metrics with a 7-day delay. Pro and Enterprise plans see the same series in real time via the full Prometheus datasource.

Deployment​

A StereumLabs label identifying the hosting environment. Current values: NDC2 (bare-metal in Vienna, Austria), GCP (Google Cloud Platform, europe-west3-a).

DevP2P​

The execution-layer peer-to-peer protocol stack, including discovery (UDP) and the eth/68 / eth/69 protocols (TCP). Different from the libp2p stack used on the consensus layer. Listens on TCP+UDP port 30303 by default.

Discv5​

The Kademlia-like discovery protocol used by Ethereum consensus clients to find peers. Runs over UDP on port 9000 by default.

E​

EC (Execution Client)​

The Ethereum execution-layer client. Handles the EVM, transactions, mempool, and world state. Talks to the CC over the Engine API. StereumLabs covers six ECs: Besu, Erigon, Ethrex, Geth, Nethermind, Reth.

Engine API​

The JSON-RPC channel (authenticated with a JWT secret) over which a consensus client drives its paired execution client: requests new payloads, updates fork choice, retrieves blobs. Calls include engine_forkchoiceUpdatedV3, engine_newPayloadV4, engine_getPayloadV4, engine_getBlobsV2. Always served over HTTP on port 8551 by default.

Environment profile​

(StereumLabs-specific) The full set of parameters describing where and how a run happens: hardware specs, kernel/OS, network topology, geolocation. Every published run declares its environment profile (often via an environment hash for compact citation).

Epoch​

A grouping of 32 consecutive slots (~6.4 minutes). Many CL accounting metrics roll up per-epoch: finalization checkpoints, validator balance updates, sync committee rotations.

Erasure coding​

Splitting a piece of data into N chunks such that any K of them can recover the original. Used by PeerDAS to split each blob into 128 data columns of which any 64 can reconstruct the blob.

F​

Federation (Prometheus)​

(StereumLabs-specific) An internal Prometheus job that mirrors live metrics from each deployment's local Prometheus into the central full Prometheus tier. Adds a small ingestion delay (a few seconds).

Finality / Finalized​

A consensus-layer guarantee that a block (and its history) will never be reverted, achieved by two consecutive epochs of justified votes from a 2/3 supermajority of stake.

Fork choice​

The algorithm a consensus client uses to decide which chain head to follow when it sees competing forks. Implementations differ in performance characteristics under reorg pressure.

Full Prometheus​

(StereumLabs-specific) The long-retention Prometheus datasource provisioned into each Pro and Enterprise customer's Grafana org. Covers all scraped metrics, with no retention or delay restrictions. See Plans.

Fusaka​

The Ethereum hardfork activated 2025-12-03 at 21:49 UTC (slot 13,164,544). Combines "Fulu" (CL) and "Osaka" (EL). Headline feature: PeerDAS (EIP-7594). See the Fusaka hardware impact post.

G​

Gas limit / Gas used / Mgas/s​

The maximum (limit) and actual (used) computational work in a block, measured in gas units. Mgas/s is the throughput rate (millions of gas per second) – reported by some ECs as a moving average inside the head updated log line.

Gossipsub​

The publish/subscribe protocol used by libp2p (and thus by CCs) to propagate blocks, attestations, blobs, and sidecars across the consensus-layer network.

H​

Hardware-backed measurement​

(StereumLabs-specific) A measurement run on hardware whose specifications are fully declared and stable over the run window. Contrasts with cloud measurements where the underlying hardware may be heterogeneous or shared.

I​

Instant query​

(Prometheus) A query that returns a single value (or vector) at one point in time. Use for current state, snapshot comparisons, or instant percentile estimates.

K​

KZG commitment​

(Kate-Zaverucha-Goldberg) The cryptographic commitment scheme that lets a node verify a small slice of a blob without holding the full data. Central to PeerDAS verification.

L​

Libp2p​

The modular peer-to-peer networking stack used by Ethereum consensus clients (and many other protocols). Runs over QUIC and TCP, traverses NAT/firewall more easily than DevP2P.

Lifecycle (dashboard)​

A status badge on every StereumLabs dashboard. Values: Active (supported, updated), Experimental (under evaluation, may change without notice), Legacy (preserved for continuity, may receive security/compatibility fixes only).

Location​

A StereumLabs label identifying the geographic placement of a host. Current values include Vienna/Austria (NDC2) and europe-west3-a (GCP Frankfurt).

M​

MDBX​

The memory-mapped key-value store used by Erigon and Caplin for chain state. Designed for compact append-only B-trees over very large datasets; supports zero-copy reads via mmap.

MEV-Boost​

A relay-based block-building protocol where validators outsource block construction to external builders who compete on profitability. Most production validators use MEV-Boost; blob-heavy blocks are common because builders optimize for gas revenue.

N​

NDC2​

The datacenter in Vienna, Austria, where StereumLabs operates its bare-metal fleet. Servers and networking are fully managed by RockLogic. Used as our hardware-backed reproducibility anchor.

Near real-time​

(StereumLabs-specific) The data freshness offered by Pro and Enterprise tiers via the full Prometheus datasource. End-to-end latency is typically under 30 seconds (15-second scrape interval plus ingestion overhead).

Node Exporter​

The standard Prometheus exporter for host-level metrics (CPU, memory, disk I/O, network, filesystem). Source: github.com/prometheus/node_exporter. StereumLabs deploys node-exporter on every measured host with a 15-second scrape interval.

P​

Pectra​

The Ethereum hardfork activated in May 2025 (the predecessor of Fusaka). Combined "Prague" (EL) and "Electra" (CL).

Peer (CL / EL)​

  • CL peer: a connection on the consensus-layer libp2p stack. Typical counts: 70–200 per node depending on client.
  • EC peer: a connection on the execution-layer DevP2P stack. Typical counts: 25–130 per node depending on client and its peer-limit configuration.

PeerDAS (Peer Data Availability Sampling)​

EIP-7594. The Fusaka feature that lets nodes verify blob data is available without each node downloading every blob. Each blob is split into 128 erasure-coded data columns; each non-validating node samples 4 custody groups. See the Blob performance analysis.

Prometheus scrape interval​

The cadence at which Prometheus collects metrics from each exporter. StereumLabs uses 15 seconds as the standard scrape interval. End-to-end latency from exporter to queryable datasource is typically 25 to 30 seconds.

Public Prometheus​

(StereumLabs-specific) Our public-facing Prometheus datasource. Exposes a small set of recording rules at a 7-day delay, with 90-day retention. Available on every tier; see Plans.

R​

Range query​

(Prometheus) A query that returns a series of values over a time range, at a specified step resolution. Use for trend lines, longitudinal comparisons.

Reorg (reorganization)​

A short-lived divergence in the chain head where a node briefly accepts one block, then revises to follow a different fork. Frequent reorgs indicate network instability or fork-choice issues.

Role​

A StereumLabs label identifying what a host runs:

  • ec: execution-client host
  • cc: consensus-client host
  • standalone: Caplin standalone (EL + CL in one binary)

Run​

(StereumLabs-specific) A measurement episode with pinned client versions, fixed configuration, declared environment, and validated outputs. Each published run includes a manifest with all parameters needed to reproduce it. See Run anatomy.

S​

Sidecar​

Short for data column sidecar.

Slot​

A 12-second window in which one validator is assigned to propose a block. The atomic time unit of Ethereum's consensus layer.

Snap sync​

An EC sync strategy where the node downloads a recent state snapshot (account ranges, storage ranges, bytecodes) directly from peers instead of replaying every block from genesis. Each EC implements snap (or a variant) with different timing characteristics; see the Execution Client Sync Speed post for a side-by-side comparison.

Supernode​

A consensus-layer node that custodies all 128 data columns instead of the default 4 custody groups. Validating nodes are expected to operate as supernodes so they can serve the data columns of blocks they propose. StereumLabs labels supernodes with the -super suffix on cc_client (e.g., prysm-super).

T​

Time-aligned charts​

Dashboard panels that share an x-axis and time window across multiple series, used for side-by-side comparison. The standard layout for client-vs-client comparators on StereumLabs.

V​

Validator​

An entity (identified by a BLS pubkey) staking 32 ETH and participating in consensus by signing attestations and proposing blocks when assigned. A single CC instance may serve thousands of validator pubkeys.

VM profile​

(StereumLabs-specific) A named hardware/OS/storage configuration used for measurements. Each profile includes provider/region, vCPU/RAM, storage, kernel/OS, availability window, and lifecycle status. See List of VMs.

See also​

  • Purpose & Scope: the canonical statement of methodology and run anatomy.
  • Custom Labels: the StereumLabs label conventions used in dashboards and PromQL.
  • Client metrics: the list of all client-specific metrics StereumLabs scrapes.

Change control for this page: material edits will be logged in the global Changelog with a short rationale and effective date.