Nodes power Ethereum end‑to‑end. Without nodes, there’d be no decentralized validation, no permanent record of transactions, no EVM to run smart contracts, and no standardized interface for developers to build on.
From developers requiring deep chain history to casual users wanting quick syncs, Ethereum nodes come in three flavors: full, archive, and light. We’ll compare their strengths, typical use cases, and specs.
Learn which type has on hand and a local full copy of history, which needs minimal resources to run, and which is the most practical for dApps.
What is an Ethereum node?
A node is part of Ethereum’s P2P system. Physically, it is a specialized server with enough CPU, RAM, SSD, and an internet connection, running an instance of the Ethereum client software.
In practice, one node is an on‑chain database, rules engine, and network router combined. Namely, it:
- Keeps a live copy of the blockchain, always reflecting the newest state;
- Enforces all of Ethereum’s protocol rules (transaction validation, smart‑contract execution (the EVM), consensus logic, etc);
- Connects to and exchanges data, blocks, and transactions with other nodes, plus handles external RPC requests.
These are the core of Ethereum nodes’ responsibilities.
The role of nodes in the Ethereum network
Nodes are the foundation that makes everything else possible on Ethereum. Their collective work makes the network resilient, trustless, and programmable.
Nodes are also access points and back-end for wallets, front‑ends, bots, oracles, AI agents – all of Web3. They are how decentralized applications (dApps) interface with Ethereum.
What are Ethereum clients?
Client is the software that transforms a computer running it into a node and makes it follow Ethereum’s rules.
To run an Ethereum node, it’s required to run an execution (EL) and consensus (CL) clients together. Users can mix and match existing production-ready software from the list below.
Execution clients:
- Geth: Most widely used, battle‑tested client written in Go;
- Nethermind: .NET/C# stack;
- Besu: Java‑based, focused on permissioning and privacy features;
- Erigon: Known for its performance as an archive node implementation.
Consensus clients:
- Teku: Java/Kotlin client;
- Prysm: Go implementation;
- Lighthouse: Based on Rust;
- Nimbus: Nim implementation.
For a more in-depth description and comparison of clients, consult our best Ethereum clients guide.
Types of nodes in the Ethereum network
Across Ethereum and other EVM‑compatible chains, three node types are considered fundamental:
- Full node
- Archive node
- Light node
They are primarily distinguished by how much blockchain data they keep readily available, the levels of block validation they perform, and the use cases they’re suitable for.
Ethereum full node
A full node gets its name because it holds and validates the entire block history and current state needed for almost every everyday Ethereum use case.
So they are “full” in the sense that they:
- Keep the latest world‑state – state of all accounts and contracts after the most recent block.
- Have the complete, canonical history of what happened on the Ethereum chain – the full history of blocks and receipts.
- Perform the full verification work – check every signature and smart‑contract execution.
These capabilities help it serve virtually all common application and developer needs: balance queries, log filters, contract calls, transaction submission, block lookups, and much more.
Ethereum Full node size
Since full nodes keep only what’s needed for today’s chain and a small recent window, they can run on a consumer‑grade SSD of about 2 TB. It covers average execution and consensus clients' requirements and estimated data growth.
However, the latest storage recommendations have crept up to 4 TB so nodes can keep pace with growth.
Ethereum full node requirements
A full node still consumes a lot of compute, resources, and bandwidth with its scope of responsibilities. Here’s a breakdown of today’s hardware you’ll need to run an Ethereum full node (EL + CL combined):
- Storage: 2-4 TB NVMe SSD (DRAM‑backed with TLC flash or better);
- Memory: 32 GB of RAM;
- CPU: 4 cores / 8 threads;
- Network: ≥ 50 Mbps.
It’s important to note that Ethereum node specs tend to grow in line with the network’s functionality upgrades, validator count, and usage. Core developers are working on counterbalancing that growth; however, the timeline of actual implementation of these measures is yet unclear.
Ethereum archive node
An archive node is, in essence, a full node with pruning disabled, which means it stores all past blocks with complete state available for every block. It can serve data like contract storage at a specific block, event logs filtered by state, or simply “this account had this balance at block N”.
Its ability to provide instant access to past states makes it most practical for block explorers, analytics tools, indexing services, and data APIs.
Full nodes vs archive nodes
The main feature that distinguishes Ethereum archive and full nodes is how much historical data they keep.
Full nodes keep recent past states, but older ones are garbage-collected to save disk space.
After the May 2025 Pectra upgrade, full nodes can reach for up to 8,192 historical blocks, saved in the state. Anything older than that window requires an archive node.
An archive node storing one full state per block quickly balloons to terabytes of data. This means they require orders of magnitude more disk space.
Ethereum archive node size
Different clients make different choices about how they store and index the past states, so the disk footprint of an archive‑mode node may vary from client to client.
As of mid-2025, baseline on‑disk sizes for an archive node by client are:
- Geth: 12 TB
- Nethermind: 14 TB
- Erigon: 3 TB
- Besu: 12 TB
In practice, it’s advised to choose at least 1.5x of current usage to allow for growth, albeit with higher hardware overhead. If you prefer a lighter touch, you can tap into a managed Ethereum archive node API like GetBlock, which delivers full historical data on demand without the multi‑TB storage burden.
Ethereum light nodes
Light nodes, more often referred to as light clients, are the “minimalist” way to participate in Ethereum.
What makes them light is their ability to cryptographically verify data without storing the full database locally. Instead, they download block headers representing the entire data set of individual blocks.
How light nodes work on Ethereum
Let’s imagine a scenario of requesting an account balance from the light client. To serve the valid data that the chain agreed on, the client:
- Asks a full or archive node to supply the requested data (balance) and the Merkle proof (a list of few hashes that show how that value links up to the state root).
- This small proof is enough data for a light client to recompute the root locally and compare the calculated root versus what it already stores in the header.
- If they are identical, the balance is genuine and untampered.
This design keeps light nodes fast, small, and suitable for on‑demand requests.
Light node use cases
The main use case of these types of nodes is in resource-constrained environments. They can be embedded into wallets, web apps, browser extensions, mobile device applications, or IoT devices.
It should be noted, however, that the “light client everywhere” dream remains largely unrealized. Although convenient in theory, most Ethereum client teams prioritize full‑archive node modes, with light client implementations lagging in stability. Dedicated light‐client implementations remain largely in the experimental stage rather than ready for widespread use.
Which Ethereum node to run
Choosing between an Ethereum light, full, and archive node largely depends on the individual use case and available resources. The comparison table below outlines the main distinctions between all three types of nodes.
| Node Type | Data Stored | Data Retrieval | Resource Requirements | Use Cases |
|---|---|---|---|---|
| Full | The current network state and records of all blocks and transactions | Local DB queries | Moderate to high | Developers running dApps who require broad RPC support |
| Archive | Every block, transaction, and every past and present state | Directly from its own local database | Heavy | In‑depth analytics, research, historical state queries (e.g. block explorers) |
| Light | Only block headers | Requests from peer full nodes | Minimal | Mobile & browser wallets; IoT/edge devices |
Tolerance for maintenance is also another point to consider. Running a node means shouldering significant hardware, maintenance, and bandwidth costs. Using services like GetBlock, on the other hand, will spare you the hardware and maintenance.
GetBlock gives you instant access to data from Ethereum full nodes via simple HTTP/WebSocket endpoints. With a few steps of configuration, point your Web3 library to private https://go.getblock.io/<Your-Access-Token> RPC URL and get:
- Instant provisioning: zero sync time, zero maintenance;
- Scalable throughput with global low-latency infrastructure;
- Multi‑chain support: access Ethereum mainnet, testnets, and dozens of other chains from a single dashboard.
Opt for the Dedicated node service for the best possible performance and archive node API access, or start with the Shared service option if your use case tolerates a bit more latency for greater cost efficiency. Sign up for your node today.
