Ejecutar un nodo Ethereum en 2026 es una decisión disfrazada de muchas: comprar el disco correcto. Todo lo demás — elección de clientes, RAM, CPU — tiene márgenes cómodos, pero el estado de Ethereum es un monstruo de lecturas aleatorias, y la diferencia entre un NVMe de verdad y cualquier cosa más lenta es la diferencia entre sincronizar en un día y no alcanzar la cadena jamás. Aquí está la hoja de hardware honesta para un full node y qué cambia si validas.
La spec de referencia
| Componente | Mínimo que funciona | Cómodo |
|---|---|---|
| Disco | 2 TB NVMe (TLC) | 2×2 TB NVMe (espejo o desborde) |
| RAM | 16 GB | 32 GB |
| CPU | 4 núcleos modernos | 6–8 núcleos (sync más rápido, RPC más ágil) |
| Red | 100 Mbps, 1.5–3 TB/mes | 1 Gbps sin medición |
Realidad actual de mainnet: un full node (ejecución + consenso, pruning por defecto) ocupa aproximadamente 1.3–1.8 TB según el par de clientes, y crece — 2 TB es el suelo de compra sensato, 4 TB compra años de no pensar en ello. Los nodos archive son otro deporte (15 TB+) y casi nadie necesita uno.
Por qué el disco lo decide todo
El acceso al estado de Ethereum son millones de pequeñas lecturas aleatorias; la velocidad de sync y la latencia de procesado de bloques siguen los IOPS del disco casi linealmente. Clasificación práctica:
- NVMe TLC de datacenter/consumo: sync inicial en horas-a-un-día, luego sigue el ritmo sin esfuerzo. Este es el requisito.
- NVMe QLC / SSD SATA: puede completar el sync, luego sufre en periodos pesados de estado; la efectividad de atestación se resiente si validas.
- HDD en cualquier configuración: nace muerto — el nodo se atrasa más rápido de lo que sincroniza. Ningún RAID arregla la física.
En hardware alquilado, comprueba el modelo exacto del disco cuando figure, y prefiere líneas NVMe enterprise — las máquinas con 2×512 GB NVMe se quedan pequeñas; el punto dulce de nuestro stock son máquinas con 2×1.92 TB NVMe de datacenter.
Clientes: elige un par minoritario, no el default
Un nodo son dos programas: ejecución (Geth, Nethermind, Besu, Reth) y consenso (Lighthouse, Prysm, Teku, Nimbus, Lodestar). Todos los pares mainstream funcionan con la spec de arriba — Reth y Nethermind son notablemente eficientes, Nimbus es el avaro de RAM. El argumento de salud de red también es interés propio: los clientes supermayoritarios cargan riesgo de bug correlacionado, y los validadores en clientes minoritarios están más seguros exactamente en los escenarios que más duelen. Sincroniza con checkpoint sync (minutos para consenso; ejecución rellena después) — ya nadie sincroniza desde génesis.
¿Buscas un servidor que simplemente funcione?
Valebyte VPS — NVMe, soporte 24/7, despliegue en 60 segundos.
Notas de validador: paranoia de uptime bien apuntada
Validar añade casi nada de hardware (el cliente validador es pluma) pero cambia la psicología. Apunta bien la paranoia:
- La caída es barata. Las penalizaciones offline reflejan más o menos lo que habrías ganado: un día caído es un día de recompensas perdidas, no una catástrofe. No construyas HA exótica para eso.
- El slashing viene de la mala configuración, casi siempre las mismas claves en dos sitios (un «failover» mal hecho). Nunca ejecutes validadores duplicados; habilita la protección doppelganger; trata las claves como lo sagrado.
- Monitoriza como adulto: métricas de clientes a Grafana, un check externo de uptime, alertas de disco lleno y atestaciones perdidas.
Dónde ejecutarlo
Los nodos caseros son legítimos pero viven con uplinks residenciales y sustos de energía. Un dedicado alquilado lo cambia por uptime aburrido: el perfil que encaja es 6–8 núcleos, 32–64 GB, 2×1.92 TB NVMe y tráfico generoso o sin medir — en nuestro stock es la banda de ~$59–117 (líneas Xeon-E/Ryzen), y la ubicación de Lituania con cuotas de 30–100 TB digiere los 2–3 TB/mes de charla P2P sin pensarlo. Los VPS valen para testnets; los validadores de mainnet merecen discos no compartidos. Hechos verificados el 8 de julio de 2026 — los tamaños de disco derivan hacia arriba; la ley de los IOPS es permanente.
