This is Part 2 of my node infrastructure series. In Part 1, I set up a Bitcoin + Lightning node on a $220 mini PC. Now I'm adding an Ethereum node — and I ran into a problem that throttled my entire home network.
If you're on T-Mobile Home Internet (or any CGNAT connection), pay attention. Following the default Ethereum node guides will throttle your internet — or worse.
Why Run Your Own Node?
Privacy — Third-party RPCs see every address you query and every transaction you submit. Your node, your queries stay local.
No rate limits — Free tiers throttle you. Your own node doesn't.
Censorship resistance — Providers can refuse transactions or go down at bad times. Infura has had outages during high-volatility periods.
Staking — If you ever want to solo stake 32 ETH, you need a node anyway.
Learning — When you run it yourself, you learn things documentation can't teach you. Like what happens when your ISP's network equipment can't handle Ethereum's traffic patterns.
The Hardware: Repurposed Gaming Rig
I had a gaming PC and some old Monero mining rigs sitting around. Did some shuffling — one became the dedicated ETH node, another became my new gaming setup.
Specs:
- CPU: AMD Ryzen 7
- RAM: 32GB DDR4
- Storage: 2x 1TB NVMe in RAID 0 (1.8TB usable)
- PSU: 450W Corsair
- GPU: Basic card for display output only
- OS: Ubuntu Server
- Hostname:
eth-node - IP:
192.168.0.215
These specs exceed the recommended requirements. The 1.8TB storage is borderline — Nethermind docs say 2TB is "comfortable" — but I have room to add another NVMe if needed.
RAID 0 Setup Note
Combining the two 1TB NVMes into a single 2TB volume required RAID 0 during Ubuntu installation. The partitioning is tricky:
- Create identical partitions on both drives
- Boot partition → mount to
/boot - Main RAID 0 partition → mount to root filesystem
/
The Ubuntu installer menu is unintuitive. I messed up 3-4 times. Budget extra time for this.
Client Selection
After The Merge, Ethereum nodes require two clients that work together:
| Client Type | What It Does | My Choice |
|---|---|---|
| Execution Client | Handles transactions, state, EVM | Nethermind |
| Consensus Client | Handles PoS, block proposals, attestations | Prysm |
Why Nethermind?
- Client diversity matters. Geth is still #1 at ~41%, but the community actively discourages Geth dominance. Nethermind is #2 at ~38%.
- Fastest sync time — under 24 hours according to solo staker reports
- Coinbase moved ~50% of their validators to Nethermind in 2024
Why Prysm?
- Documentation is excellent — easiest to follow for first-time setup
- Helps decentralization (Lighthouse leads with ~43%, Prysm is ~25%)
- Despite a bug in December 2025, still well-maintained
Installation
Folder Structure
~/ethereum/
├── consensus/ # Prysm
├── execution/ # Nethermind
└── jwt.hex # Shared authentication token
JWT Secret
The execution and consensus clients need to authenticate with each other via the Engine API (port 8551). Generate the shared secret:
openssl rand -hex 32 | tr -d "\n" > ~/ethereum/jwt.hex
Prysm (Consensus Client)
cd ~/ethereum/consensus
curl https://raw.githubusercontent.com/prysmaticlabs/prysm/master/prysm.sh --output prysm.sh && chmod +x prysm.sh
Run with checkpoint sync (downloads from a recent finalized state instead of genesis):
./prysm.sh beacon-chain \
--execution-endpoint=http://localhost:8551 \
--mainnet \
--jwt-secret=/home/rodrigo/ethereum/jwt.hex \
--checkpoint-sync-url=https://mainnet.checkpoint.sigp.io \
--genesis-beacon-api-url=https://mainnet.checkpoint.sigp.io \
--p2p-max-peers=15
Checkpoint provider: Sigma Prime
Nethermind (Execution Client)
cd ~/ethereum/execution
wget https://github.com/NethermindEth/nethermind/releases/download/1.35.8/nethermind-1.35.8-c066aee2-linux-x64.zip
unzip nethermind-1.35.8-c066aee2-linux-x64.zip
Run with the T-Mobile-safe flags (see next section for why):
./nethermind \
--config mainnet \
--JsonRpc.Enabled true \
--HealthChecks.Enabled true \
--HealthChecks.UIEnabled true \
--JsonRpc.JwtSecretFile=/home/rodrigo/ethereum/jwt.hex \
--Init.DiscoveryEnabled false \
--Network.MaxActivePeers 10 \
--Network.EnableUPnP false
The CGNAT Problem (And How I Fixed It)
This is where every tutorial failed me.
I followed the official docs exactly. Started Nethermind. Within minutes, something felt off. Claude.ai still worked, but I couldn't load Reddit or Amazon. Other sites were hit or miss. The network was getting flooded.
Killed Nethermind → network recovered instantly.
Started it again → same problem.
What Was Happening
T-Mobile Home Internet uses CGNAT (Carrier-Grade NAT). Unlike normal home internet where you get your own public IP, T-Mobile puts hundreds of customers behind a single shared public IP. Their equipment tracks all the connections for all those customers.
Ethereum nodes use a protocol called discv5 to find peers. It works by sending UDP packets to random IP addresses across the internet, probing for other Ethereum nodes. It does this constantly — hundreds or thousands of probes.
When Nethermind started with discovery enabled, it flooded T-Mobile's CGNAT with UDP packets to random IPs. T-Mobile's equipment either:
- Ran out of capacity to track all those connections, or
- Detected "suspicious" traffic patterns and rate-limited my connection
This throttled my household's internet — not just the node.
The Fix
Discovery was the problem, not peer connections.
T-Mobile's CGNAT can handle a handful of stable TCP connections to peers. It chokes when the discovery protocol blasts UDP packets to hundreds of random IPs.
# Nethermind — disable discovery, low peers, no UPnP
--Init.DiscoveryEnabled false
--Network.MaxActivePeers 10
--Network.EnableUPnP false
# Prysm — low peers
--p2p-max-peers=15
With these flags, my network stays stable. The nodes maintain a few stable connections instead of blasting UDP everywhere.
Gateway reboot clears the "flagged" state if things go bad.
The Tradeoff
With discovery disabled, Nethermind can't find new peers on its own — it relies on peers connecting to it, or on Prysm sharing peers. Sync will be slower, but the network stays stable.
You can add static peers manually later to improve connectivity.
But it works. I'm running an Ethereum node on T-Mobile Home Internet, which most people say is impossible.
Understanding Sync Times
The docs are misleading here. "Checkpoint sync" sounds fast — and it is, but only for the consensus layer.
| Client | What It Syncs | Method | Time |
|---|---|---|---|
| Prysm | Beacon chain (consensus) | Checkpoint sync | ~2 minutes |
| Nethermind | Ethereum state (execution) | Snap sync | Hours to days |
Prysm synced in about 2 minutes. It checkpointed to a recent finalized state and immediately started following the live chain.
Nethermind is different. The execution layer has no equivalent "checkpoint sync." It downloads the entire Ethereum state (~500GB+). That's what "Snap sync" does — and it takes a while.
The Result
I let it run overnight. Went to bed with Nethermind at 4% sync. Woke up to a fully operational node.
Both clients are now synced and following the chain head. Prysm picks up a new block every 12 seconds — exactly as expected. Nethermind processes each block in under 200 milliseconds. Finalization is working. The node is healthy.
Storage landed at 866GB — right at 50% of my 1.8TB RAID. Ethereum state grows around 50-100GB per month depending on network activity, so I've got at least six months of headroom before I need to think about adding another drive. Nethermind supports pruning if it ever becomes a concern.
The CGNAT workaround is holding. With discovery disabled and peers limited, my home network stays stable while the node runs 24/7. I'm maintaining around 14 peers on Prysm and 10 on Nethermind — enough to stay in sync without overwhelming T-Mobile's equipment.
It works. I have a fully synced Ethereum node running on T-Mobile Home Internet — something most guides will tell you is impossible.
Key Takeaways
- CGNAT breaks default Ethereum node configs — If you're on T-Mobile Home Internet (or similar), disable discovery and limit peers
- Two clients, two sync methods — Consensus is fast (checkpoint), execution is slow (snap sync)
- Client diversity matters — Don't just use Geth because it's popular
- Repurpose old hardware — A gaming PC makes an overpowered node
- Budget for friction — Setup takes longer than tutorials suggest
What's Next
Having a synced node is just the beginning.
In Part 3, I'll put this thing to work — connecting MetaMask to my local RPC, querying the chain, and exploring what you can do when you control your own node.
This is Part 2 of my node infrastructure series. See Part 1: Running a Bitcoin Node.
Running nodes on weird network setups? Hit me up on X — I'd love to compare notes.
