Nodo completo de Ethereum en VPS: Geth + Lighthouse, archive vs full

Para ejecutar un Ethereum full node en un VPS en 2024-2025, se requiere un servidor con un mínimo de 4 vCPU, 16 GB de RAM (se recomiendan 32 GB) y un disco NVMe rápido con una capacidad desde 2 TB para un Full node o desde 12 TB para un Archive node; el coste de alquiler de un VPS/VDS adecuado con estas características comienza en $60-90 al mes, dependiendo de la ubicación y el tipo de subsistema de disco.

Arquitectura de Ethereum después de The Merge: ¿por qué se necesitan dos clientes?

Ejecutar un ethereum node vps hoy en día es fundamentalmente diferente de cómo funcionaba antes de 2022. Tras la transición de la red al algoritmo Proof-of-Stake (The Merge), el nodo dejó de ser un único archivo binario. Ahora, un nodo completo consta de dos capas independientes que deben trabajar en conjunto: la Execution Layer (EL) y la Consensus Layer (CL).

Execution Layer node: procesamiento de transacciones

El Execution layer node es responsable de la ejecución de smart contracts, el procesamiento de transacciones y el almacenamiento del estado actual de la blockchain (State). Aquí es donde operan clientes como Geth, Nethermind, Erigon o Reth. Esta capa interactúa con los usuarios a través de una JSON-RPC API, permitiendo enviar transacciones y consultar saldos. Sin embargo, sin conexión con la capa de consenso, esta capa no puede saber qué cadena de bloques es la verdadera.

Consensus Layer: Beacon Node y validación

La capa de consenso (Beacon Node) gestiona la lógica de Proof-of-Stake. Se encarga de vigilar qué bloques se reconocen como válidos y coordina el trabajo de los validadores. Para esta tarea se utilizan clientes como Lighthouse, Prysm, Teku o Lodestar. La comunicación entre la EL y la CL se realiza a través de la Engine API utilizando el protocolo de autenticación JWT (JSON Web Token). Si planeas ejecutar un staking node ethereum, también necesitarás un tercer componente: el Validator Client, que firma los bloques con tus llaves privadas.

Elección de características de hardware para ethereum node vps

El principal cuello de botella al operar un nodo de Ethereum es el subsistema de disco. Los HDD convencionales o incluso los SSD SATA económicos no soportarán la carga debido a su bajo índice de IOPS (operaciones de entrada/salida por segundo). Para una sincronización estable y un funcionamiento sin retrasos, es crítico contar con una unidad NVMe. Al elegir un ethereum node vps, oriéntate por los siguientes parámetros:

Es importante tener en cuenta que el volumen de datos en la red Ethereum crece diariamente. Si instalas un eth archive node, la tasa de crecimiento de la base de datos es de unos 150-200 GB al mes. A diferencia de Bitcoin, donde los requisitos de hardware son significativamente menores (puedes leer más sobre esto en el artículo Bitcoin full node en VPS: pruned vs full), Ethereum requiere una disponibilidad constante de memoria RAM libre para el almacenamiento en caché del árbol de estados (Trie).

Full Node vs Archive Node: ¿cuál es la diferencia y qué elegir?

La elección del tipo de nodo afecta directamente a tus costes de infraestructura. Para la mayoría de los desarrolladores y stakers, un Full Node es suficiente, ya que almacena solo el estado actual y los últimos cientos de bloques, permitiendo verificar cualquier transacción nueva.

Características de Full Node y Snap Sync

El Full Node utiliza el modo de sincronización Snap Sync (en Geth). Esto permite descargar el estado actual de la red en pocas horas, sin recalcular toda la historia desde 2015. Actualmente, este nodo ocupa entre 1.2 y 1.4 TB. Si estás desarrollando una dApp o ejecutando un staking node ethereum para uso personal, esta es la opción óptima. El ahorro en espacio de disco permite utilizar NVMe más rápidos en VPS de menor capacidad.

¿Para qué se necesita un eth archive node?

Un eth archive node almacena "instantáneas" (snapshots) del estado en cada bloque. Esto permite realizar consultas del tipo "¿cuál era el saldo de esta dirección en el bloque 5,000,000?". Estos nodos son necesarios para servicios analíticos, exploradores de bloques y protocolos DeFi para análisis histórico. El volumen de datos aquí supera los 14 TB, lo que hace imposible su ejecución en VPS estándar. Aquí se requieren servidores dedicados con grandes matrices de discos. Para optimizar los gastos en tales proyectos, a menudo se considera migrar de AWS a servidores dedicados, ya que los proveedores de la nube cobran un recargo enorme por el volumen de almacenamiento.

Combinación Geth + Lighthouse: instalación y configuración

La combinación geth lighthouse se considera el "estándar de oro" debido a la estabilidad de Geth y el rendimiento de Lighthouse (escrito en Rust). Veamos el proceso de configuración básica en Ubuntu 22.04.

Paso 1: Preparación del entorno y del token JWT

Para una comunicación segura entre la capa de ejecución y la de consenso, es necesario crear una clave secreta:

sudo mkdir -p /var/lib/ethereum/jwt
openssl rand -hex 32 | sudo tee /var/lib/ethereum/jwt/jwt.hex > /dev/null
sudo chmod 644 /var/lib/ethereum/jwt/jwt.hex

Paso 2: Configuración de Geth (Execution Layer)

Ejecución de Geth con soporte para Engine API y limitación de caché para ahorrar RAM:

geth --mainnet \
--authrpc.addr localhost \
--authrpc.port 8551 \
--authrpc.vhosts localhost \
--authrpc.jwtsecret /var/lib/ethereum/jwt/jwt.hex \
--http \
--http.api eth,net,web3 \
--cache 4096 \
--datadir /var/lib/ethereum/geth

Paso 3: Configuración de Lighthouse (Consensus Layer)

Lighthouse se conectará a Geth a través del puerto 8551. Ten en cuenta que el Beacon Node requiere una sincronización que puede llevar tiempo si no se utiliza Checkpoint Sync.

lighthouse bn \
--network mainnet \
--execution-endpoint http://localhost:8551 \
--execution-jwt /var/lib/ethereum/jwt/jwt.hex \
--datadir /var/lib/ethereum/lighthouse \
--http \
--checkpoint-sync-url https://mainnet.checkpoint.sigp.io

El uso del flag --checkpoint-sync-url permite sincronizar la Consensus Layer casi instantáneamente, confiando en un estado verificado de la red.

Clientes alternativos: Erigon y Reth

Aunque Geth domina el mercado (más del 70% de los nodos), la diversificación de clientes es importante para la salud de la red. Además, los clientes alternativos pueden ser más eficientes en ciertos escenarios.

• Erigon: Un fork de Geth reescrito y optimizado para el almacenamiento de datos. Erigon es la mejor opción si necesitas un eth archive node, ya que utiliza una arquitectura de bases de datos planas y ocupa mucho menos espacio para datos de archivo que el Geth estándar.
• Reth: Un nuevo cliente de Paradigm, escrito en Rust. Muestra una velocidad fenomenal de sincronización y procesamiento de consultas. Reth está desplazando activamente a otras soluciones en servicios RPC de alta carga.
• Nethermind: Cliente basado en .NET, frecuentemente elegido por stakers institucionales por su excelente soporte y características Enterprise.

Para analizar el rendimiento de estos sistemas, a menudo se utilizan dashboards personalizados. Si ya utilizas analítica self-hosted para tus proyectos, integrar las métricas del nodo en Grafana será un paso lógico para el monitoreo de la salud del servidor.

Cómo ganar dinero con un nodo de Ethereum: MEV y venta de RPC

Ejecutar un ethereum node vps no es solo un gasto, sino también una oportunidad para obtener ingresos. Existen tres vías principales para monetizar tu propio nodo.

Ejecución de un validador y MEV-Boost

Si tienes 32 ETH, puedes ejecutar un staking node ethereum. Además de la recompensa base por staking (~3-4% anual), puedes conectar MEV-Boost. Este es un software adicional (relé) que permite a tu validador proponer bloques llenos con las transacciones más rentables de los "buscadores" (searchers). Esto puede aumentar la rentabilidad del staking entre un 10% y un 50% en periodos de alta volatilidad del mercado.

Venta de acceso RPC

Muchos desarrolladores no quieren mantener sus propios nodos y están dispuestos a pagar por el acceso a la API. Puedes vender el acceso a tu nodo directamente o a través de protocolos descentralizados como Pocket Network. Tu nodo se convierte en parte de una red global y recibes tokens por cada consulta procesada. Para esto, es crítica una alta disponibilidad (Uptime) y baja latencia (Latency), lo cual se garantiza con un ethereum node vps de calidad.

Arbitraje y frontrunning

Tener un nodo propio otorga una ventaja en la velocidad de recepción de información sobre nuevas transacciones en la mempool. Si programas bots para arbitraje en DEX (Uniswap, Curve), contar con un nodo local reduce la latencia en milisegundos, lo que a menudo es el factor decisivo para una transacción exitosa. En estos casos, se suele elegir un execution layer node basado en Reth para obtener el máximo rendimiento.

Seguridad y administración del nodo

Un nodo de Ethereum es un complejo sistema de software que requiere atención a la seguridad. Dado que el nodo está abierto a la red, puede ser objetivo de ataques DDoS o intentos de explotación de vulnerabilidades en los clientes.

1. Firewall (UFW): Cierra todos los puertos excepto los necesarios. Para la interacción P2P, normalmente se necesitan el 30303 (TCP/UDP) para EL y el 9000 (TCP/UDP) para CL. Los puertos de API (8545, 8551) nunca deben ser accesibles desde el exterior sin una VPN o un túnel SSH.
2. Monitoreo de recursos: Los clientes de Ethereum pueden comenzar a consumir repentinamente más RAM durante las reorganizaciones de la cadena. Configura alertas para el uso de disco y memoria. Si almacenas datos críticos, quizás valga la pena considerar el uso de bases de datos vectoriales para indexar eventos específicos de la blockchain.
3. Actualizaciones: Los clientes se mueven con frecuencia. Omitir una actualización crítica antes de un hardfork puede hacer que tu nodo termine en una rama incorrecta de la blockchain.

Para gestionar las configuraciones y automatizar el despliegue, es conveniente utilizar Docker Compose. Esto permite cambiar rápidamente entre versiones de clientes y escalar la infraestructura con facilidad.

services:
  geth:
    image: ethereum/client-go:latest
    volumes:
      - /path/to/data:/data
    ports:
      - "30303:30303"
    command: --datadir /data --http --http.addr 0.0.0.0

  lighthouse:
    image: sigp/lighthouse:latest
    volumes:
      - /path/to/data-cl:/data
    command: lighthouse bn --network mainnet --execution-endpoint http://geth:8551

Conclusiones

Para ejecutar con éxito un nodo de Ethereum en un VPS en las realidades actuales, es necesario elegir un servidor con disco NVMe de al menos 2 TB y un mínimo de 16 GB de RAM, utilizando la combinación de Geth y Lighthouse para la máxima estabilidad. Si tu objetivo es la analítica profunda, prepárate para alquilar un servidor dedicado para un Archive Node de más de 12 TB, y para ganar con el staking, asegúrate de configurar MEV-boost para maximizar los beneficios.