Blockchain Nodes: Ethereum, Bitcoin and Server Requirements

In 2024 a crypto exchange decided to run their own Ethereum full node instead of using external API providers like Infura. Reason — dependency on third party and cost $500-1000 per month for high-load tier. Got dedicated server for €120 per month, started sync. After 4 days process stopped at 87% — ran out of disk space. Turned out full Ethereum node needs not 2 TB as planned but minimum 3 TB accounting for growth. Added another disk, resynced in 5 days. Result: own node handles 2000 requests per second, latency 15-30 milliseconds vs 150-300 milliseconds through Infura, full data control, saving €380 per month.

Running own blockchain node is compromise between control, performance and costs. For development public RPC providers sufficient. For production app with high load or privacy requirements need own node.

Node Types: Full, Light, Archive

Full node stores entire blockchain from genesis block and verifies every transaction by network consensus rules. For Bitcoin this means all blocks from 2009, for Ethereum all blocks from 2015. Full node can independently verify any transaction and block without trusting third parties.

Important clarification: Bitcoin full node stores complete transaction history but may not store full UTXO (unspent transaction outputs) state for all addresses all time — this optional through txindex. Ethereum full node after proof-of-stake transition and snap/fast sync implementation stores only recent state and not necessarily all historical states.

Archive node stores not only all blocks but all historical network states for each block. For Ethereum this critical if you need queries like "what was address balance at block 5,000,000 three years ago". Ethereum archive node size exceeds 12 TB and grows 50-70 GB per week. Archive nodes needed for blockchain explorers, analytics platforms, tax reporting services.

Light node doesn't store full blockchain, only block headers and requests necessary data from full nodes on demand. Light node can work even on smartphone but depends on full nodes and trusts them to certain degree. For server infrastructure light nodes almost never used — if running node, run full.

Pruned node is full node that deletes old blocks after processing them, keeping only recent (e.g. last 550 blocks for Bitcoin). This saves disk space — pruned Bitcoin node takes ~10 GB instead of ~600 GB. But such node can't serve historical data queries and doesn't help new nodes synchronize.

Bitcoin Node: Requirements and Characteristics

Bitcoin Core — official Bitcoin full node implementation. Written in C++ and works on Linux, macOS, Windows. For production server node use Linux.

CPU requirements. Bitcoin node doesn't require powerful CPU. Transaction validation uses cryptography (SHA-256, ECDSA) which though CPU-intensive, modern processors handle easily. Minimum sufficient 2 cores at 2+ GHz. For comfortable work recommended 4 cores. During initial sync (IBD — initial block download) node maximally loads CPU verifying all blocks from 2009. On processor level Intel i5 latest generation this takes 6-12 hours pure CPU time.

RAM. Bitcoin Core works efficiently with 2 GB RAM minimum, recommended 4-8 GB. Node keeps in memory mempool (unconfirmed transaction pool), UTXO set (unspent outputs set), block cache. With dbcache=4096 (4 GB allocated cache) sync goes noticeably faster thanks to fewer disk accesses.

Disk space. Full unpruned Bitcoin node takes about 600 GB as of early 2026. Blockchain grows roughly 60-80 GB per year depending on network activity. For node operation disk speed critically important. On HDD initial sync can take week or more due to huge amount of random reads for validation. On SATA SSD sync takes 1-3 days. On NVMe SSD can fit in 12-24 hours.

Storage format — LevelDB database for chainstate (current UTXO state) and blocks as separate files ~128 MB each. Random reads from chainstate very frequent during validation, so slow disk kills performance.

Network requirements. Bitcoin node actively exchanges data with other nodes in P2P network. Initial sync downloads ~600 GB data. After sync traffic is roughly 20-50 GB per month incoming and 20-50 GB outgoing at standard settings. If allow other nodes to download blocks from your node (serve as seed-node for network), traffic can grow to 500 GB+ per month outgoing.

Important is stable internet with low latency. Node receives new blocks and transactions from peers, and faster the better. Delay in receiving new block means you learn about transaction confirmations later. For most applications not critical, but for mining or high-frequency trading latency matters.

Ports and firewall. Bitcoin Core uses port 8333 for P2P communication with other nodes. This port must be open for incoming connections if you want your node accessible to rest of network. Port 8332 used for RPC API (JSON-RPC interface for programmatic node interaction). RPC port must be closed externally and accessible only locally or through VPN.

Sync time. Initial Bitcoin full node sync (initial block download) takes 12 hours to several days depending on hardware and connection. On fast server with NVMe SSD, 8 GB RAM, good connection can fit in 12-18 hours. On slow VPS with HDD and poor connection can stretch to week.

Process goes in several stages: downloading blocks from peers (limited by connection), validating blocks (limited by CPU and disk), building chainstate (limited by disk). Bottleneck usually disk at validation stage for old blocks where thousands small random reads.

Real config example. Hetzner server AX41-NVMe: AMD Ryzen 5 3600 (6 cores, 12 threads, 3.6 GHz), 64 GB RAM, 2x 512 GB NVMe in RAID 1, 1 Gbps network, cost €49 per month. On such server Bitcoin full node syncs in 14-16 hours, runs stable, can serve several thousand RPC requests per minute.

Ethereum Node: Substantially Higher Requirements

Ethereum after proof-of-stake transition (The Merge in September 2022) and subsequent updates became less resource-demanding than was, but still heavier than Bitcoin.

Ethereum clients. Several Ethereum node implementations in different languages: Geth (Go), Erigon (Go), Nethermind (C#), Besu (Java). Most popular — Geth, used on approximately 60% nodes. Erigon more efficient on disk space thanks to advanced storage architecture.

After proof-of-stake transition need run two components: execution client (Geth/Erigon/etc) processes transactions and stores state, consensus client (Prysm/Lighthouse/Teku/Nimbus) participates in consensus and block finalization. Both clients work together and communicate via Engine API.

CPU requirements. Ethereum node noticeably loads CPU. During sync processor works at limit verifying transactions and updating state. Minimum need 4 cores, recommended 6-8 cores at 3+ GHz. Weaker processor will lead to node falling behind head of chain — network generates blocks faster than node can process them.

RAM. This bottleneck for Ethereum. Geth requires minimum 16 GB RAM for operation, comfortable 32 GB. During sync memory consumption reaches 12-16 GB for execution client plus 2-4 GB for consensus client. If memory low, process will swap to disk which kills performance completely.

Reason for high memory consumption is Ethereum state (all smart contract and account states) very large and node keeps hot parts in memory for fast access. MPT (Merkle Patricia Trie) data structure for state requires lots memory for efficient operation.

Disk space. Here Ethereum especially hungry. Geth full node with snap sync (fast sync without all historical states) takes 1.2-1.5 TB as of early 2026. Archive node takes 12-14 TB. Growth roughly 50-70 GB per week for full node, more for archive.

Erigon client more efficient — full node takes ~800 GB, archive 4-6 TB thanks to advanced compression and storing only state changes between blocks. But Erigon less stable and has less support than Geth.

Critically important fast NVMe SSD. On SATA SSD node will sync slowly and may fall behind head of chain. On HDD running full Ethereum node in 2026 practically impossible — too many random read/write operations to state database.

Network requirements. Initial sync downloads 1.2-1.5 TB data. After sync traffic is 50-100 GB per month incoming and similarly outgoing at moderate load. If your node popular and many peers connect, traffic can grow to 1-2 TB per month.

Latency also important. Ethereum blocks generate every 12 seconds, and node must manage to receive, process and transmit block further in this time. Poor connection will lead to missing blocks and need to request them later.

Ports. Execution client (Geth) uses 30303 TCP/UDP for P2P, 8545 for HTTP RPC API, 8546 for WebSocket RPC. Consensus client uses 9000 TCP/UDP for P2P, 5052 for Beacon API. P2P ports must be open, API ports closed externally.

Sync time. Geth with snap sync synchronizes 12-36 hours on good hardware. Erigon can sync 6-12 hours thanks to more efficient architecture. Old full sync that verified every transaction from genesis took weeks and now not used.

Consensus client syncs separately, takes 2-6 hours. It downloads beacon chain (consensus chain) which much lighter than execution layer.

Practical example. Hetzner AX102: AMD Ryzen 9 5950X (16 cores, 32 threads, 3.4 GHz), 128 GB RAM, 2x 3.84 TB NVMe in RAID 1, 1 Gbps network, cost €169 per month. On such server Geth + Lighthouse sync in 18-24 hours, run stable, can serve tens thousands RPC requests per minute. This enough for medium DeFi platform or NFT marketplace.

Bitcoin vs Ethereum Requirements Comparison

Direct comparison of minimum and recommended configurations:

Bitcoin full node minimum: 2 cores CPU, 4 GB RAM, 700 GB SSD (better NVMe), 100 Mbps network. Sync 1-3 days. Monthly traffic ~100 GB. Server cost €30-50/month.

Bitcoin full node recommended: 4 cores CPU @ 3 GHz, 8 GB RAM, 1 TB NVMe SSD, 1 Gbps network. Sync 12-24 hours. Cost €50-70/month.

Ethereum full node minimum: 4 cores CPU, 16 GB RAM, 1.5 TB NVMe SSD, 100 Mbps network. Sync 1-3 days. Monthly traffic ~200 GB. Cost €80-120/month.

Ethereum full node recommended: 8 cores CPU @ 3+ GHz, 32 GB RAM, 2 TB NVMe SSD, 1 Gbps network. Sync 12-24 hours. Cost €120-170/month.

Ethereum archive node: 8+ cores CPU, 64 GB RAM, 14+ TB fast storage (NVMe RAID), 1 Gbps network. Sync week+. Cost €250-400/month depending on disk space.

Ethereum requires 2-3x more resources than Bitcoin due to EVM (virtual machine for smart contract execution) complexity, large and fast-growing network state, more frequent blocks (12 seconds vs 10 minutes).

Performance Optimization and Tuning

Bitcoin Core optimization. Parameter dbcache in bitcoin.conf controls database cache size in memory. Default 450 MB, but with free RAM can increase to 4096-8192 (4-8 GB). This dramatically speeds block validation during sync. After IBD completion can return to smaller value.

Parameter maxconnections limits simultaneous connections to other nodes. Default 125, normal for home node. For server node with good connection can raise to 200-300. More connections helps faster propagate blocks and transactions, but eats traffic and slightly CPU.

If don't need full transaction history for every address, don't enable txindex=1. This saves sync time and disk operations. txindex needed only if you do getrawtransaction for arbitrary transactions by their ID.

Geth optimization. Parameter --cache sets cache size in megabytes. Default 4096 (4 GB), recommended set around 50-70% free RAM. On server with 32 GB RAM can set --cache=16384 (16 GB). More cache — fewer disk operations, faster sync and operation.

Parameter --maxpeers limits peer count. Default 50, adequate. Increasing to 100 gives small sync speed gain but eats more traffic and CPU. For production node usually leave 50-70.

Use --syncmode=snap for fast sync instead of --syncmode=full. Snap downloads only current network state without all historical states, saving weeks of time. Full sync needed only if you want independently verify every transaction from genesis, which for most applications excessive.

Erigon instead of Geth. If disk space critical, Erigon takes 1.5-2x less space thanks to smart data storage. But Erigon less stable, more frequent bugs, updates can break compatibility. For production if reliability more important than space — Geth safer choice.

Node monitoring. Critically important monitor node is synced and not falling behind. For Bitcoin can check getblockchaininfo RPC call — blocks field should match headers, and verificationprogress should be 0.9999+ (almost 1.0). Lag of dozens blocks normal during activity peaks, hundreds blocks — problem.

For Ethereum check eth_syncing — should return false if synced. Also eth_blockNumber compare with public explorers like Etherscan. If lag more than 10-20 blocks constantly — node can't handle load, need more resources.

Monitor disk usage — if free less than 15-20%, will run out soon. Ethereum grows roughly 3-4 GB per day, means at 100 GB free in month problems. Need plan expansion ahead.

Providers and Alternatives to Own Node

Managed blockchain node providers. If don't want manage own node, there are services providing node access for fee:

Infura — most popular for Ethereum. Free tier gives 100,000 requests per day, paid tiers from $50 to $1000+ per month depending on load. Latency usually 150-300 milliseconds from Europe, higher from other regions. Risk in centralization — if Infura falls, multiple DApps stop.

Alchemy — Infura competitor with similar pricing and capabilities. Offers additional APIs for event notifications, advanced analytics. Free tier 300 million compute units per month, paid from $49/month.

QuickNode — another provider with focus on performance. Claim latency 50-100 milliseconds, but cost more — from $49/month for basic tier, $299+ for high loads.

GetBlock — European provider, cheaper than American. From €29/month for shared node, from €99 for dedicated. Supports Bitcoin, Ethereum, dozens other blockchains.

Cost comparison: provider vs own node. If your app makes 10-20 million requests per month to Ethereum node, this costs $200-500/month on Infura/Alchemy. Own node on dedicated server for €120-170/month handles billions requests with proper architecture.

But there are hidden own node costs: setup time (10-20 hours initially), monitoring and maintenance (5-10 hours per month for updates and problem solving), downtime risk if node crashes and nobody to quickly fix. For small project or MVP managed provider cheaper and easier. For production with high load or privacy requirements — own node more profitable.

Hybrid approach. Many projects use own node for main load and managed provider as fallback. If own node unavailable or lagging — requests go to Infura. This gives reliability while keeping control and savings on most requests.

Node Security and Privacy

RPC API protection. By default Bitcoin Core and Geth RPC API listen only on localhost (127.0.0.1). If need allow external access (e.g. from another server in your infrastructure), critically important configure authentication and encryption.

Bitcoin Core supports HTTP Basic Auth through rpcuser and rpcpassword in config. But HTTP connection not encrypted, so need either SSH tunnel, or VPN, or reverse proxy with TLS (nginx with SSL certificate).

Geth can run with --http.api to limit available methods. For example --http.api=eth,net,web3 allows only data reading, without personal (account management) and admin (node management). For production never expose full API set externally.

Firewall rules. Open only necessary ports. For Bitcoin: 8333 TCP/UDP (P2P) must be open to world, 8332 (RPC) closed completely or accessible only from specific IPs via whitelist. For Ethereum: 30303 (execution P2P), 9000 (consensus P2P) open to world, 8545/8546 (RPC/WebSocket) closed or through VPN.

Use iptables or ufw on Linux for strict control. Example for Bitcoin: allow 8333 to all, allow 8332 only from 10.0.0.5 (your app server), deny everything else on these ports.

Privacy and IP address. Running node exposes your IP address to entire P2P network. All your transactions visible as originating from this IP. If this critical, can use Tor. Bitcoin Core supports working through Tor out of box — all connections go through Tor network, your real IP hidden.

Geth also can configure to work through Tor but this more complex and may slow sync. For most applications this excessive — node IP usually not critical information. But for paranoid or in countries with strict regulation Tor option exists.

Regular updates. Blockchain clients regularly update with security patches and new features. Critically important keep node on current version. Vulnerability in old version can lead to attack that crashes node or worse — allows stealing funds if node stores private keys (not recommended for production).

Bitcoin Core and Geth release versions every few months. Major updates require stopping node and restart which can take several minutes. Plan updates in low-load periods.

Real Use Cases

Ethereum DeFi platform. Decentralized exchange DEX uses own Geth node for reading smart contract states and sending transactions. Node handles 50-100 requests per second (token balances, pool prices, swap simulation). Running on Hetzner AX102 for €169/month. Latency 10-20 milliseconds vs 200-400 through Infura. Saving about €800/month compared to Infura Enterprise plan.

Additionally keep backup node on different provider (OVH) and Infura as third fallback. On main node crash traffic automatically switches to backup in 5-10 seconds via health check in load balancer.

NFT marketplace. Platform indexes all NFT transfers and metadata from Ethereum blockchain. Use Erigon archive node for historical smart contract event access. Node takes 5.2 TB on OVH server with 8 TB RAID array for €250/month.

Each new block parsed for Transfer events of ERC-721/ERC-1155 contracts. Processes 10-50 events per second during activity periods (NFT mints, major sales). Archive node allows historical queries like "who owned NFT #5234 six months ago" for analytics and tax reporting.

Cryptocurrency payment processor. Service accepts Bitcoin payments for e-commerce sites. Running Bitcoin Core full node on Hetzner AX41 for €49/month. Node monitors mempool for incoming transactions to client addresses, detects block confirmations.

Works paired with Bitcoin Core wallet generating unique addresses for each payment. Processes 200-500 payments per day, peak load 50 transactions per hour. Own node gives full control and privacy — no client addresses leak to third-party providers. Transaction detection latency 1-5 seconds after broadcast to network.

Blockchain analytics. Company analyzes Bitcoin transactions for compliance and AML (anti-money laundering). Use several Bitcoin Core nodes with txindex=1 for full transaction index. Nodes replicated in different datacenters for fault tolerance.

Each node processes 100-200 requests per second from analytics system building transaction graphs, tracking suspicious patterns, checking addresses against blacklist. Full txindex takes additional ~200 GB on disk but allows instantly getting any transaction by ID without slow scanning all blocks.

Conclusions and Recommendations

Running own blockchain node makes sense when need full data control, low latency, high throughput or privacy. For small projects and MVP managed providers like Infura more convenient and cheaper. For production with tens millions requests per month — own node more economically viable.

Bitcoin node can run on modest hardware — 4 cores CPU, 8 GB RAM, 1 TB SSD for €50-70/month handles most applications. Ethereum substantially heavier — need minimum 8 cores, 32 GB RAM, 2 TB NVMe for €120-170/month. Ethereum archive node for full history costs €250-400/month due to huge disk space.

Critical success factors: fast NVMe SSD (without it sync takes week and node may lag), enough RAM (otherwise swap kills performance), stable internet with low latency, regular client updates, sync and resource monitoring.

For fault tolerance recommended keep minimum two nodes in different datacenters plus managed provider as final fallback. This protects from downtime at one node or datacenter problems. Load balancer with health checks automatically switches traffic to healthy node.

Security critical — close RPC API from external access, use authentication and TLS, keep client on current version, don't store private keys on same machine as node. Firewall must allow only necessary ports.

Start implementation with test node on testnet (Sepolia for Ethereum, testnet for Bitcoin) to master setup and monitoring without risk. After successful test can launch mainnet node for production. Sync takes day-two, after which node ready to serve application.