On this page 8 sections
An Ethereum full node in 2026 needs a 4-core CPU, 32 GB of RAM, a 4 TB NVMe SSD and a 50/15 Mbps connection, according to EIP-7870, the hardware recommendation the client teams maintain. A validator should have 8 cores, 64 GB of RAM and a CPU with a single-thread PassMark score around 3,500. An archive node fits in about 2 to 2.5 TB with Reth, Erigon or Geth’s path-based archive mode, or needs more than 12 TB in the legacy hash-based mode.
The short version
| Role | CPU | Single-thread (PassMark) | RAM | Storage | Bandwidth (down / up) |
|---|---|---|---|---|---|
| Bare minimum (ethereum.org) | 2+ cores | — | 16 GB, 32 GB recommended | 2 TB NVMe, likely exceeded by 2027 | 25+ Mbps |
| Full node (EIP-7870) | 4 cores / 8 threads | about 1,000 | 32 GB | 4 TB NVMe | 50 / 15 Mbps |
| Validator (EIP-7870 “attester”) | 8 cores / 16 threads | about 3,500 | 64 GB | 4 TB NVMe | 50 / 25 Mbps |
| Local block builder (EIP-7870) | 8 cores / 16 threads | about 3,500 | 64 GB | 4 TB NVMe | 100 / 50 Mbps |
EIP-7870 is an informational, “living” document created in January 2025 and kept current by client developers; ethereum.org’s run-a-node guide, last updated in August 2026, repeats its figures. They describe a node that keeps up comfortably, not the smallest machine that technically syncs.
Disk space: how much each client needs
A node runs two programs: an execution client, which holds the state and history, and a consensus client, which follows the beacon chain. The execution client accounts for almost all of the disk. Ethereum.org lists these sizes for mainnet:
| Execution client | Snap-synced full node | Full archive |
|---|---|---|
| Besu | 800 GB+ | 12 TB+ |
| Erigon | no snap sync; about 2 TB fully pruned | 2.5 TB+ |
| Geth | 500 GB+ | 12 TB+ hash-based; about 2 TB path-based |
| Nethermind | 500 GB+ | 12 TB+ |
| Reth | no snap sync; about 1.2 TB fully pruned | 2.2 TB+ |
Add about 200 GB for the consensus client’s beacon data. Then plan for growth: Geth’s documentation notes that a snap-synced node grows by about 14 GB a week with the default cache until it is pruned. That is why EIP-7870 asks for 4 TB even though a fresh full node uses well under 2 TB.
History expiry saves 300 to 500 GB. Since July 2025, every major client can drop the block bodies and receipts from before the Merge, which no longer matter for consensus. In Geth (v1.16.0 and later), start a new node with --history.chain postmerge, or stop an existing one and run geth prune-history; Nethermind applies it by default to new nodes from v1.32.2, and Besu, Erigon and Reth have their own flags, listed in the Ethereum Foundation’s announcement.
The type of SSD matters as much as its size. Ethereum.org discourages DRAM-less and QLC drives: a node performs a constant stream of small random reads and writes, and cheap consumer SSDs that slow down under sustained load can leave a node permanently behind the chain. Use a TLC NVMe drive with DRAM, and never a hard disk for the live database.
Archive nodes: 2 TB or 20 TB
An archive node keeps every historical state, so it can answer questions such as “what was this balance at block 15,000,000”. Block explorers, indexers, analytics and some RPC services need one; wallets and validators do not.
- Geth path-based archive (v1.16.0 and later): about 2 TB for a full-history mainnet archive, or about 6.5 TB if full flat states are stored as well, and about two weeks to sync. Enable it with
--syncmode full --gcmode archive --history.state=0. Historical Merkle proofs througheth_getProofneed v1.17 and the--history.trienodeoption. - Erigon and Reth were designed around compact archives: 2.5 TB+ and 2.2 TB+ respectively, according to ethereum.org.
- Hash-based archives (Geth’s legacy mode, Besu, Nethermind): more than 12 TB, and Geth’s documentation warns its hash-based database can exceed 20 TB and take months to sync from genesis.
Archive nodes reward large, fast NVMe arrays and plenty of memory for caches. Geth also lets you move the state history to a cheaper, slower device with --datadir.ancient.
CPU: single-thread speed matters
Block processing is largely sequential, so a fast core counts for more than many slow ones. EIP-7870 expresses this as a single-thread PassMark target: about 1,000 for a full node and about 3,500 for a validator or a local block builder, which must process each block quickly enough to attest or propose on time. Here is where common server processors sit, using PassMark’s single-thread ratings as of October 2026:
| Processor | Cores / threads | Single-thread rating | Validator target (~3,500) |
|---|---|---|---|
| AMD Ryzen 9 9950X3D | 16 / 32 | 4,737 | Above |
| AMD Ryzen 9 9950X | 16 / 32 | 4,726 | Above |
| AMD Ryzen 9 9900X | 12 / 24 | 4,670 | Above |
| AMD EPYC 4585PX | 16 / 32 | 4,540 | Above |
| Intel Xeon E-2488 | 8 / 16 | 4,300 | Above |
| AMD Ryzen 7 7700 | 8 / 16 | 4,050 | Above |
| AMD EPYC 9355P | 32 / 64 | 3,747 | Above |
| AMD EPYC 9454P | 48 / 96 | 2,988 | Below; fine for full and archive nodes |
High-core-count server CPUs trade clock speed for throughput. That makes them excellent for archive nodes, indexers and several chains on one machine, and less suited to a latency-sensitive validator.
Memory and bandwidth
Memory. 32 GB runs an execution and a consensus client side by side; 64 GB gives a validator headroom for larger caches, a validator client, MEV-Boost and monitoring, and avoids the swapping that makes a node miss attestations. Memory beyond that is useful for archive nodes and for several nodes on one server.
Bandwidth. EIP-7870 asks for 50 Mbps down and 15 Mbps up for a full node, 25 Mbps up for a validator and 50 Mbps up for a local block builder. Those are floors: the initial sync downloads hundreds of gigabytes, and a well-connected node serves blocks to its peers around the clock. On a metered connection that upload is the line to watch; on an unmetered port it does not matter. Geth’s documentation explicitly advises against capped data plans.
Which server for which node
Matching the requirements above to PowerDedi configurations, all with a 10 Gbps unmetered port:
| Use | Configuration | Why | Price |
|---|---|---|---|
| Full node or RPC for your own apps | Ryzen 9 9950X, 128 GB, 2 × 1.92 TB NVMe | Single-thread 4,726; 3.84 TB of NVMe in total (1.92 TB if mirrored) | $159/mo |
| Validator | Ryzen 9 9950X3D, 192 GB, 2 × 3.84 TB NVMe | Above EIP-7870’s CPU and memory targets for validators, with 3.84 TB of mirrored NVMe | $219/mo |
| Validator with ECC memory | EPYC 4585PX, 128 GB ECC, 2 × 1.92 TB NVMe | Same Zen 5 clocks with error-correcting memory | $179/mo |
| Archive node, indexer or several chains | EPYC 9454P, 256 GB ECC, 2 × 3.84 TB NVMe | 48 cores and twelve memory channels for parallel work | $489/mo |
| Large archive or multi-client RPC | EPYC 9555P, 768 GB ECC, 4 × 3.84 TB Gen5 | Four fast drives and memory for big caches | $949/mo |
Two honest caveats. The Ryzen 7 7700 at $79 a month passes the CPU and memory targets, but its 2 × 1 TB of NVMe is too small for a mainnet full node with room to grow; we recommend it for Bitcoin nodes instead. And the EPYC 9454P’s single-thread rating sits below EIP-7870’s validator target: choose it for archives and indexing, not for a solo validator.
Setup tips that save a resync
- Use checkpoint sync for the consensus client: it starts from a recent finalized state instead of replaying the beacon chain from genesis.
- Prune pre-Merge history on new nodes from the start; it is 300 to 500 GB you never download.
- Keep the database on its own NVMe volume and monitor free space: an execution client that runs out of disk can corrupt its database.
- Open the P2P ports of your clients (for example 30303 TCP and UDP for Geth’s peer-to-peer traffic), and keep RPC ports bound to localhost or behind a firewall. Our first-hour hardening checklist covers the rest.
- Never run the same validator keys on two machines. Running a backup validator with the same keys is the classic way to get slashed; use slashing protection and fail over manually.
This guide covers hardware only and is not staking or financial advice. For other chains, see our Solana validator and RPC sizing guide and blockchain node hosting.
Sources
- EIP-7870: Hardware and Bandwidth Recommendations — Ethereum Improvement Proposals
- Spin up your own Ethereum node — ethereum.org (updated August 17, 2026)
- Hardware requirements — Geth documentation
- Archive node — Geth documentation (edited February 24, 2026)
- History pruning — Geth documentation
- Partial history expiry announcement — Ethereum Foundation Blog, July 8, 2025
- CPU single-thread performance — PassMark Software
- AMD EPYC 9355P vs EPYC 9354 and AMD EPYC 9454P vs EPYC 9454 — PassMark Software
