Configuración de un Nodo Val

Qué configuramos y por qué

Ethereum ha pasado al mecanismo de consenso Proof-of-Stake (PoS) como parte de la actualización The Merge, lo que ha cambiado radicalmente la forma de confirmar transacciones y crear nuevos bloques. Ahora, en lugar de mineros que utilizan la potencia computacional (Proof-of-Work), la red es mantenida por validadores que "hacen staking" de 32 ETH como garantía. Los validadores son responsables de verificar transacciones, crear nuevos bloques y votar por la corrección del estado de la blockchain.

Configurar su propio validador de Ethereum en un VPS o servidor dedicado le permite participar activamente en la descentralización de la red, obtener recompensas por su trabajo y tener control total sobre sus fondos. Ejecutar un validador no es solo una forma de obtener ingresos pasivos, sino también una contribución importante a la seguridad y sostenibilidad de Ethereum. Usted será parte de una red global que garantiza el funcionamiento de miles de aplicaciones descentralizadas (dApps), protocolos DeFi y mercados NFT.

Al final, el lector obtendrá un validador de Ethereum completamente funcional, capaz de sincronizarse con la red, atestiguar bloques y proponer nuevos, obteniendo así recompensas. Este proceso incluye la instalación de dos tipos principales de clientes: un cliente de ejecución (Execution Client), que procesa transacciones y gestiona el estado de la Máquina Virtual de Ethereum (EVM), y un cliente de consenso (Consensus Client), que es responsable de la lógica de Proof-of-Stake, incluyendo atestaciones y propuestas de bloques.

Existen alternativas al alojamiento propio del validador (self-hosted):

• Staking-as-a-Service (SaaS): Servicios que gestionan el validador por usted, requiriendo solo el depósito de 32 ETH. Conveniente, pero usted confía las claves del validador a un tercero y paga una comisión.
• Exchanges centralizados: Muchos exchanges ofrecen servicios de staking, permitiendo hacer staking con menos de 32 ETH. Esta es la opción más centralizada, donde usted confía completamente sus activos al exchange y pierde el control de las claves.
• Staking en pool: Protocolos descentralizados, como Lido o Rocket Pool, permiten hacer staking con cualquier cantidad de ETH, recibiendo a cambio tokens de staking líquidos. Usted no ejecuta su propio validador, pero participa en su soporte a través de un pool.

¿Por qué el self-hosted en un VPS es preferible para nuestra audiencia objetivo? El alojamiento propio en un VPS o servidor dedicado proporciona el máximo control, seguridad y privacidad. Usted posee completamente sus claves de validador, no paga comisiones a terceros (aparte del costo del VPS) y contribuye directamente a la descentralización de la red. Es la elección ideal para aquellos que valoran la soberanía sobre sus activos y desean comprender profundamente la infraestructura de Ethereum.

Qué configuración de VPS se necesita para esta tarea

La elección de la configuración correcta del servidor es crucial para el funcionamiento estable y eficiente de un validador de Ethereum. El nodo requiere recursos significativos, especialmente espacio en disco y velocidad de entrada/salida (I/O).

Requisitos mínimos (válido para 2026):

• CPU: Mínimo 4 núcleos (vCPU) con una frecuencia de reloj de 2.5 GHz o superior. Los validadores utilizan activamente el procesador durante la sincronización y el procesamiento de bloques.
• RAM: Mínimo 16 GB de RAM. 32 GB son altamente recomendables para garantizar la estabilidad y evitar ralentizaciones, especialmente al usar múltiples clientes o monitorización.
• Disco:
  • Tipo: Solo NVMe SSD. La velocidad de lectura/escritura es críticamente importante para la sincronización de la blockchain y las atestaciones. Un SATA SSD puede ser demasiado lento.
  • Volumen: Mínimo 2 TB. La blockchain de Ethereum está en constante crecimiento. Para un nodo completo (Geth) en 2026, puede requerir más de 1.5 TB, más espacio para el crecimiento y el sistema operativo. 3 TB son óptimos para una perspectiva a largo plazo.
  • I/O: Alta velocidad de I/O (mínimo 2000 IOPS para lectura/escritura).
• Red:
  • Velocidad: Puerto de 1 Gbit/s.
  • Tráfico: Ilimitado o con un gran margen (mínimo 2-3 TB/mes). La sincronización y el funcionamiento constante del nodo generan un tráfico de red significativo.

Plan de VPS específico para la tarea:

Para ejecutar un validador de Ethereum, se recomienda elegir un plan de VPS con las siguientes características:

• CPU: 6-8 vCPU, 3.0+ GHz
• RAM: 32 GB
• Disco: 2-3 TB NVMe SSD
• Red: Puerto de 1 Gbit/s, tráfico ilimitado

Un VPS con las características mencionadas garantizará la estabilidad y el rendimiento de su validador durante muchos años. Si planea ejecutar varios validadores u otros servicios que consumen muchos recursos, considere configuraciones más potentes.

Cuándo se necesita un dedicado y no un VPS:

Un servidor dedicado (dedicated server) puede ser preferible en los siguientes casos:

• Múltiples validadores: Si gestiona decenas o cientos de validadores.
• Máximo rendimiento y control: Los servidores dedicados ofrecen un rendimiento predecible sin "vecindad" con otros usuarios, y control total sobre el hardware.
• Requisitos de hardware específicos: Por ejemplo, el uso de módulos de seguridad de hardware (HSM) para las claves del validador, lo que rara vez está disponible en un VPS.
• Servicios adicionales: Si planea alojar en el mismo servidor otros servicios de blockchain que consumen muchos recursos, nodos de otras redes o grandes bases de datos.

En la mayoría de los casos, un VPS bien configurado es suficiente para uno o dos validadores, pero al escalar o si se necesita la máxima fiabilidad y rendimiento, un dedicado adecuado puede ser la mejor opción.

Ubicación: qué factores influye

La elección de la ubicación geográfica del servidor influye en varios factores:

• Legislación: La jurisdicción en la que se encuentra el servidor puede afectar los aspectos legales de la propiedad y gestión de activos de criptomonedas.
• Latencia: Una baja latencia a otros nodos de la red Ethereum es importante para el envío oportuno de atestaciones y propuestas de bloques. Elija una ubicación con buena interconexión con las principales troncales de Internet y grandes centros de datos.
• Precio: El costo del VPS puede variar según la región.
• Disponibilidad: Algunas regiones pueden tener mejor disponibilidad y fiabilidad de infraestructura.

Generalmente se recomienda elegir una ubicación en un gran centro de datos europeo o norteamericano para una interacción de red óptima con el resto de la red Ethereum.

Preparación del servidor

Antes de instalar los clientes de Ethereum, es necesario realizar una configuración básica y reforzar la seguridad de su servidor. Utilizaremos Ubuntu Server 24.04 LTS (válido hasta 2026) como sistema operativo.

1. Actualización del sistema

En primer lugar, actualice todos los paquetes a sus versiones más recientes.

sudo apt update && sudo apt upgrade -y

Este comando actualiza la lista de paquetes e instala todas las actualizaciones disponibles sin solicitar confirmación.

2. Creación de un nuevo usuario con permisos sudo

No se recomienda trabajar directamente con la cuenta de root. Cree un nuevo usuario y agréguelo al grupo sudo.

sudo adduser validator_user

Siga las instrucciones para crear una contraseña e introducir la información del usuario. Luego, añada el usuario al grupo sudo:

sudo usermod -aG sudo validator_user

Ahora puede iniciar sesión como validator_user y ejecutar comandos con sudo.

3. Configuración de la autenticación por claves SSH

Esto es significativamente más seguro que usar contraseñas. Genere una clave SSH en su máquina local (si aún no tiene una):

ssh-keygen -t ed25519 -C "[email protected]"

Luego, copie la clave pública al servidor para validator_user. Reemplace your_public_key_file con la ruta a su clave pública (normalmente ~/.ssh/id_ed25519.pub) y your_server_ip con la IP de su servidor:

ssh-copy-id -i ~/.ssh/id_ed25519.pub validator_user@your_server_ip

Si ssh-copy-id no está disponible, puede hacerlo manualmente:

# Inicie sesión en el servidor como validator_user
ssh validator_user@your_server_ip

# Cree el directorio .ssh y el archivo authorized_keys, si no existen
mkdir -p ~/.ssh
chmod 700 ~/.ssh
touch ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

# Pegue su clave SSH pública (que copió de su máquina local) en el archivo authorized_keys
# Puede usar nano o vim:
nano ~/.ssh/authorized_keys
# Pegue la clave y guarde (Ctrl+X, Y, Enter para nano)

# Salga del servidor
exit

Ahora intente iniciar sesión en el servidor como validator_user sin contraseña.

4. Desactivación de la autenticación por contraseña para SSH (opcional, pero recomendado)

Una vez que se haya asegurado de que el inicio de sesión con claves SSH funciona, desactive la autenticación por contraseña en la configuración de SSH.

sudo nano /etc/ssh/sshd_config

Busque las siguientes líneas y asegúrese de que estén configuradas de esta manera:

PasswordAuthentication no
PermitRootLogin no

Guarde los cambios y reinicie el servicio SSH:

sudo systemctl restart sshd

Importante: Asegúrese de poder iniciar sesión con una clave SSH antes de deshabilitar la autenticación por contraseña, de lo contrario, podría perder el acceso al servidor.

5. Configuración del firewall (UFW)

UFW (Uncomplicated Firewall) es una interfaz conveniente para gestionar iptables. Configúrelo para permitir solo el tráfico necesario.

sudo apt install ufw -y              # Instalación de UFW
sudo ufw default deny incoming       # Denegar todo el tráfico entrante por defecto
sudo ufw default allow outgoing      # Permitir todo el tráfico saliente por defecto

sudo ufw allow ssh                   # Permitir tráfico SSH entrante (puerto 22)

Para los clientes de Ethereum, necesitaremos los siguientes puertos:

• Cliente de Ejecución (Geth): TCP/UDP 30303 (P2P), TCP 8545 (RPC), TCP 8546 (WebSocket).
• Cliente de Consenso (Prysm Beacon): TCP/UDP 12000 (P2P), TCP 3500 (gRPC).
• Cliente de Consenso (Prysm Validator): No requiere puertos abiertos desde el exterior, se comunica con el Cliente Beacon localmente.

Añada reglas para estos puertos:

# Geth
sudo ufw allow 30303/tcp             # P2P TCP
sudo ufw allow 30303/udp             # P2P UDP
sudo ufw allow 8545/tcp              # RPC (solo si se necesita conexión externa, de lo contrario, solo localhost)
sudo ufw allow 8546/tcp              # WebSocket (solo si se necesita conexión externa)

# Prysm Beacon Chain
sudo ufw allow 12000/tcp             # P2P TCP
sudo ufw allow 12000/udp             # P2P UDP
sudo ufw allow 3500/tcp              # gRPC (solo si se necesita conexión externa)

Active UFW:

sudo ufw enable

Verifique el estado de UFW:

sudo ufw status verbose

6. Instalación de Fail2ban

Fail2ban protege el servidor contra ataques de fuerza bruta, bloqueando las direcciones IP desde las cuales se originan múltiples intentos fallidos de inicio de sesión.

sudo apt install fail2ban -y         # Instalación de Fail2ban
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local # Creación de una copia local del archivo de configuración
sudo nano /etc/fail2ban/jail.local   # Edición del archivo de configuración

En el archivo jail.local, busque la sección [sshd] y asegúrese de que esté habilitada (enabled = true). Puede configurar bantime (tiempo de bloqueo) y findtime (período en el que se cuentan los intentos fallidos).

[sshd]
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s

Guarde los cambios y reinicie Fail2ban:

sudo systemctl restart fail2ban
sudo systemctl enable fail2ban       # Habilitar el inicio automático al arrancar

Su servidor ya está listo para la instalación de los clientes de Ethereum.

Instalación de software — paso a paso

Instalaremos dos componentes clave: el cliente de ejecución (Execution Client) y el cliente de consenso (Consensus Client), así como el cliente validador. Como clientes, elegiremos Geth (Go-Ethereum) y Prysm, por ser de los más populares y estables.

1. Preparación del entorno para los clientes

Crearemos usuarios de sistema separados para cada cliente para una mejor aislación y seguridad. También crearemos directorios para los datos.

# Creación de usuario y directorios para Geth (Execution Client)
sudo adduser --system --no-create-home --group execution
sudo mkdir -p /var/lib/ethereum/execution
sudo chown -R execution:execution /var/lib/ethereum/execution

# Creación de usuario y directorios para Prysm (Consensus Client)
sudo adduser --system --no-create-home --group consensus
sudo mkdir -p /var/lib/ethereum/consensus
sudo chown -R consensus:consensus /var/lib/ethereum/consensus

2. Instalación de Execution Client (Geth)

Geth es uno de los clientes de ejecución más comunes. Para el año 2026, utilizaremos una versión estable, por ejemplo, v1.14.x.

2.1. Descarga de Geth

Descargaremos la última versión estable de Geth desde el repositorio oficial de GitHub. Verifique la versión actual en la página de lanzamientos de Geth.

# Vaya al directorio temporal
cd /tmp

# Descargue el archivo con los binarios de Geth (reemplace la versión con la actual para 2026, por ejemplo, 1.14.1)
# Ejemplo: wget https://github.com/ethereum/go-ethereum/releases/download/v1.14.1/geth-linux-amd64-1.14.1-e737c04a.tar.gz
wget https://geth.ethereum.org/downloads/geth-linux-amd64-latest.tar.gz -O geth.tar.gz

# Descomprima el archivo
tar -xvf geth.tar.gz

# Mueva el archivo ejecutable a /usr/local/bin
sudo mv geth-linux-amd64-*/geth /usr/local/bin/geth

# Verifique la versión de Geth
geth version

2.2. Creación de la clave JWT

Para una interacción segura entre el cliente de ejecución y el cliente de consenso, se utiliza un token JWT. Lo generaremos.

sudo mkdir -p /var/lib/ethereum/jwt
sudo openssl rand -hex 32 | sudo tee /var/lib/ethereum/jwt/jwtsecret.txt
sudo chmod 600 /var/lib/ethereum/jwt/jwtsecret.txt
sudo chown -R execution:execution /var/lib/ethereum/jwt
sudo chown -R consensus:consensus /var/lib/ethereum/jwt

Este comando crea un archivo jwtsecret.txt con una clave hexadecimal de 64 caracteres y establece los permisos y propietarios correctos.

2.3. Creación del servicio Systemd para Geth

Crearemos un archivo de unidad Systemd para el inicio automático y la gestión de Geth.

sudo nano /etc/systemd/system/geth.service

Pegue el siguiente contenido:

[Unit]
Description=Geth Ethereum Execution Client
After=network.target

[Service]
User=execution
Group=execution
Type=simple
Restart=always
RestartSec=5
ExecStart=/usr/local/bin/geth \
  --mainnet \
  --datadir /var/lib/ethereum/execution \
  --authrpc.addr 127.0.0.1 \
  --authrpc.port 8551 \
  --authrpc.jwtsecret /var/lib/ethereum/jwt/jwtsecret.txt \
  --http \
  --http.addr 127.0.0.1 \
  --http.port 8545 \
  --http.api eth,net,web3,admin,debug,txpool \
  --ws \
  --ws.addr 127.0.0.1 \
  --ws.port 8546 \
  --syncmode "snap" \
  --cache 16000 \
  --maxpeers 50 \
  --nat extip:$(curl -s ifconfig.me)

[Install]
WantedBy=multi-user.target

Explicación de los parámetros de Geth:

• --mainnet: Se conecta a la red principal de Ethereum.
• --datadir: Especifica la ruta al directorio donde se almacenarán los datos de la blockchain.
• --authrpc.addr 127.0.0.1 --authrpc.port 8551 --authrpc.jwtsecret /var/lib/ethereum/jwt/jwtsecret.txt: Configura una interfaz RPC segura para la interacción con el cliente de consenso. Solo accesible localmente.
• --http --http.addr 127.0.0.1 --http.port 8545 --http.api eth,net,web3: Habilita la interfaz HTTP RPC, solo accesible localmente.
• --ws --ws.addr 127.0.0.1 --ws.port 8546: Habilita la interfaz WebSocket RPC, solo accesible localmente.
• --syncmode "snap": Utiliza el modo "snap sync" para una sincronización rápida.
• --cache 16000: Asigna 16 GB de RAM para la caché de Geth (se recomiendan 16 GB para 32 GB de RAM).
• --maxpeers 50: Establece el número máximo de pares.
• --nat extip:$(curl -s ifconfig.me): Detecta automáticamente la dirección IP externa para NAT.

Guarde el archivo y recargue Systemd, luego inicie Geth:

sudo systemctl daemon-reload           # Recargar la configuración de Systemd
sudo systemctl enable geth             # Habilitar el inicio automático de Geth
sudo systemctl start geth              # Iniciar Geth

Verifique el estado de Geth:

sudo systemctl status geth

También puede monitorear los registros de Geth:

sudo journalctl -f -u geth --no-hostname

Geth comenzará a sincronizar la blockchain, lo que puede tardar desde varias horas hasta varios días, dependiendo de la velocidad del disco y la red.

3. Instalación de Consensus Client (Prysm)

Prysm es un cliente de consenso que implementa la lógica de Proof-of-Stake e interactúa con Geth.

3.1. Descarga de Prysm

Descargaremos la última versión estable de Prysm desde el repositorio oficial de GitHub. Para el año 2026, esta podría ser la versión v5.x.x.

# Vaya al directorio temporal
cd /tmp

# Descargue el script de instalación de Prysm
curl https://raw.githubusercontent.com/prysmaticlabs/prysm/master/prysm.sh --output prysm.sh
chmod +x prysm.sh

# Ejecute el script para descargar los binarios (beacon-chain y validator)
./prysm.sh beacon-chain generate-config
./prysm.sh validator generate-config

# Mueva los binarios a /usr/local/bin
sudo mv beacon-chain /usr/local/bin/beacon-chain
sudo mv validator /usr/local/bin/validator

# Verifique las versiones
beacon-chain --version
validator --version

3.2. Creación del servicio Systemd para Prysm Beacon Chain

Crearemos un archivo de unidad Systemd para Prysm Beacon Chain.

sudo nano /etc/systemd/system/prysm-beacon.service

Pegue el siguiente contenido:

[Unit]
Description=Prysm Beacon Chain Consensus Client
After=network.target geth.service
Requires=geth.service

[Service]
User=consensus
Group=consensus
Type=simple
Restart=always
RestartSec=5
ExecStart=/usr/local/bin/beacon-chain \
  --datadir /var/lib/ethereum/consensus \
  --mainnet \
  --execution-endpoint http://127.0.0.1:8551 \
  --jwt-secret /var/lib/ethereum/jwt/jwtsecret.txt \
  --suggested-fee-recipient YOUR_ETH_ADDRESS \
  --p2p-host-ip $(curl -s ifconfig.me) \
  --monitoring-host 127.0.0.1 \
  --monitoring-port 8080 \
  --grpc-gateway-host 127.0.0.1 \
  --grpc-gateway-port 3500 \
  --checkpoint-sync-url https://sync.prylabs.network

[Install]
WantedBy=multi-user.target

Asegúrese de reemplazar YOUR_ETH_ADDRESS con su propia dirección de Ethereum, donde se enviarán las comisiones por los bloques (MEV y tarifas de transacción).

Explicación de los parámetros de Prysm Beacon Chain:

• --datadir: Ruta al directorio para los datos del cliente de consenso.
• --mainnet: Se conecta a la red principal de Ethereum.
• --execution-endpoint http://127.0.0.1:8551 --jwt-secret /var/lib/ethereum/jwt/jwtsecret.txt: Especifica cómo conectarse a Geth a través de RPC seguro.
• --suggested-fee-recipient YOUR_ETH_ADDRESS: Dirección para recibir las comisiones por los bloques.
• --p2p-host-ip $(curl -s ifconfig.me): Detecta automáticamente la IP externa para P2P.
• --monitoring-host 127.0.0.1 --monitoring-port 8080: Habilita métricas para Prometheus (accesibles localmente).
• --grpc-gateway-host 127.0.0.1 --grpc-gateway-port 3500: Habilita gRPC Gateway (accesible localmente).
• --checkpoint-sync-url https://sync.prylabs.network: Utiliza la sincronización de punto de control (checkpoint sync) para un inicio rápido (recomendado para nuevos nodos).

Guarde el archivo y recargue Systemd, luego inicie Prysm Beacon Chain:

sudo systemctl daemon-reload
sudo systemctl enable prysm-beacon
sudo systemctl start prysm-beacon

Verifique el estado y los registros de Prysm Beacon Chain:

sudo systemctl status prysm-beacon
sudo journalctl -f -u prysm-beacon --no-hostname

Prysm Beacon Chain comenzará la sincronización, utilizando los datos de Geth y, si está configurado, la sincronización de punto de control (checkpoint sync). Este proceso también puede llevar un tiempo considerable.

4. Instalación de Validator Client (Prysm)

El cliente validador es responsable de firmar atestaciones y propuestas de bloques utilizando sus claves de validador. Las claves del validador deben generarse y depositarse a través del Ethereum Launchpad oficial. Nunca genere claves en el servidor si no está completamente aislado y protegido.

4.1. Importación de claves de validador

Una vez que haya generado las claves de validador en su computadora local (usando Ethereum Launchpad o herramientas como ethdo) y haya completado el proceso de depósito de 32 ETH, tendrá un archivo validator_keys (generalmente en formato ZIP o JSON). Debe transferirlo al servidor.

# Cree un directorio para las claves del validador
sudo mkdir -p /var/lib/ethereum/validator/keys
sudo chown -R consensus:consensus /var/lib/ethereum/validator

# Copie el archivo validator_keys.zip de su máquina local al servidor (reemplace con sus datos)
# scp /path/to/your/validator_keys.zip validator_user@your_server_ip:/tmp/validator_keys.zip

# En el servidor, inicie sesión como validator_user, luego cambie al usuario consensus para descomprimir
sudo -u consensus bash
cd /tmp
unzip validator_keys.zip -d /var/lib/ethereum/validator/keys/
exit # Volver a validator_user

# Establezca los permisos de acceso correctos
sudo chown -R consensus:consensus /var/lib/ethereum/validator/keys
sudo chmod -R 700 /var/lib/ethereum/validator/keys

También deberá introducir las contraseñas para cada clave de validador. Prysm proporciona una importación interactiva.

sudo -u consensus /usr/local/bin/validator accounts import --wallet-dir=/var/lib/ethereum/validator/wallet --keys-dir=/var/lib/ethereum/validator/keys

Siga las instrucciones para introducir las contraseñas de cada archivo de clave.

4.2. Creación del servicio Systemd para Prysm Validator

Crearemos un archivo de unidad Systemd para Prysm Validator.

sudo nano /etc/systemd/system/prysm-validator.service

Pegue el siguiente contenido:

[Unit]
Description=Prysm Validator Client
After=network.target prysm-beacon.service
Requires=prysm-beacon.service

[Service]
User=consensus
Group=consensus
Type=simple
Restart=always
RestartSec=5
ExecStart=/usr/local/bin/validator \
  --datadir /var/lib/ethereum/validator \
  --beacon-rpc-provider 127.0.0.1:4000 \
  --wallet-dir=/var/lib/ethereum/validator/wallet \
  --wallet-password-file=/var/lib/ethereum/validator/wallet-password.txt \
  --monitoring-host 127.0.0.1 \
  --monitoring-port 8081

[Install]
WantedBy=multi-user.target

Importante: Debe crear un archivo /var/lib/ethereum/validator/wallet-password.txt que contenga la contraseña de su monedero Prysm. Este archivo debe estar protegido.

sudo nano /var/lib/ethereum/validator/wallet-password.txt
# Inserte la contraseña del monedero Prysm que estableció al importar las claves
# Guarde y cierre
sudo chmod 600 /var/lib/ethereum/validator/wallet-password.txt
sudo chown consensus:consensus /var/lib/ethereum/validator/wallet-password.txt

Explicación de los parámetros de Prysm Validator:

• --datadir: Ruta al directorio para los datos del cliente validador.
• --beacon-rpc-provider 127.0.0.1:4000: Especifica cómo conectarse a la Prysm Beacon Chain local.
• --wallet-dir: Ruta al directorio donde se almacenan los datos del monedero Prysm.
• --wallet-password-file: Ruta al archivo con la contraseña del monedero.
• --monitoring-host 127.0.0.1 --monitoring-port 8081: Habilita métricas para Prometheus (accesibles localmente).

Guarde el archivo y recargue Systemd, luego inicie Prysm Validator:

sudo systemctl daemon-reload
sudo systemctl enable prysm-validator
sudo systemctl start prysm-validator

Verifique el estado y los registros de Prysm Validator:

sudo systemctl status prysm-validator
sudo journalctl -f -u prysm-validator --no-hostname

Después de iniciar con éxito los tres componentes (Geth, Prysm Beacon, Prysm Validator), su validador comenzará la sincronización y, una vez activo en la red de Ethereum, empezará a realizar sus funciones y a ganar recompensas.

Configuración

En la sección anterior, ya configuramos los parámetros básicos de los clientes a través de los servicios Systemd. Aquí profundizaremos en algunos aspectos importantes de la configuración, seguridad y verificación.

1. Gestión del secreto JWT

El secreto JWT (jwtsecret.txt) es crucial para una interacción segura entre Geth y Prysm. Permite que el cliente de consenso se autorice para realizar solicitudes al cliente de ejecución. Ya lo creamos en /var/lib/ethereum/jwt/jwtsecret.txt con los permisos correctos (chmod 600) y propietarios (execution:execution y consensus:consensus).

Nunca compartas este archivo ni lo expongas a acceso externo.

2. Configuración de los servicios Systemd

Utilizamos Systemd para gestionar los clientes. Aquí están los parámetros principales que puedes modificar o verificar:

• User y Group: Definen el usuario y el grupo bajo los cuales se ejecuta el servicio. Esto es importante para la seguridad.
• Restart=always: Garantiza que el servicio se reiniciará automáticamente en caso de fallo.
• RestartSec=5: Un retraso de 5 segundos antes de reiniciar.
• ExecStart: El comando principal para iniciar el cliente con sus parámetros.
• After y Requires: Indican dependencias. Por ejemplo, prysm-beacon.service se inicia después de geth.service y requiere su funcionamiento.

Para modificar los parámetros de un servicio Systemd, siempre usa sudo systemctl daemon-reload después de editar el archivo .service, y luego sudo systemctl restart .

3. TLS/HTTPS para acceso externo (opcional)

Los clientes validadores de Ethereum generalmente no necesitan acceso externo directo a través de HTTP/HTTPS, ya que se comunican con la red mediante protocolos P2P y con el cliente de ejecución localmente. Sin embargo, si decides configurar el acceso externo a la API de Geth (por ejemplo, para monitoreo remoto o interacción con tu billetera), se recomienda encarecidamente utilizar un proxy inverso con TLS/HTTPS.

No lo configuraremos en detalle aquí, pero aquí tienes una idea general con Caddy:

# Установка Caddy (актуально для 2026 года)
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy

# Пример Caddyfile для проксирования Geth RPC (если бы он был доступен извне)
# sudo nano /etc/caddy/Caddyfile
#
# your.domain.com {
#   reverse_proxy 127.0.0.1:8545
#   tls [email protected]
# }
#
# sudo systemctl restart caddy

Atención: Abrir los puertos RPC de Geth o Prysm para acceso externo sin la autenticación y TLS/HTTPS adecuadas es una grave amenaza de seguridad. Siempre usa 127.0.0.1 para las direcciones RPC/API, a menos que se requiera acceso externo a través de un proxy seguro.

4. Verificación del funcionamiento

Después de iniciar todos los servicios, asegúrate de que funcionan correctamente.

4.1. Verificación de Geth

Verifica el estado del servicio:

sudo systemctl status geth

Verifica los registros:

sudo journalctl -f -u geth --no-hostname

Asegúrate de que Geth se está sincronizando. Los registros deben mostrar mensajes como "Imported new chain segment". También puedes verificar el bloque actual:

curl -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' http://127.0.0.1:8545

Este comando debería devolver el número de bloque actual en formato hexadecimal.

4.2. Verificación de Prysm Beacon Chain

Verifica el estado del servicio:

sudo systemctl status prysm-beacon

Verifica los registros:

sudo journalctl -f -u prysm-beacon --no-hostname

En los registros, deberías ver mensajes sobre la sincronización con la red, la búsqueda de pares y la conexión a Geth. Asegúrate de que Prysm se conecta correctamente a Geth ("Connected to execution client").

4.3. Verificación de Prysm Validator

Verifica el estado del servicio:

sudo systemctl status prysm-validator

Verifica los registros:

sudo journalctl -f -u prysm-validator --no-hostname

Después de la sincronización completa de la Beacon Chain y la activación de tu validador en la red, verás mensajes sobre la realización de atestaciones ("Attested block") y, posiblemente, propuestas de bloques ("Proposed block"). También asegúrate de que el validador se conecta correctamente a la Beacon Chain.

Para una verificación completa del estado del validador, puedes usar el comando Prysm:

sudo -u consensus /usr/local/bin/validator accounts list --wallet-dir=/var/lib/ethereum/validator/wallet

Este comando mostrará una lista de tus validadores y su estado.

Copias de seguridad y mantenimiento

Una estrategia de copia de seguridad adecuada y un mantenimiento regular son clave para la estabilidad y seguridad a largo plazo de tu validador de Ethereum. Es importante entender qué se debe respaldar y qué no.

1. Qué respaldar

• Claves del validador (Validator Keys): Esto es lo más crítico. Tus claves de validador son tu acceso a los 32 ETH apostados. Deben generarse en un entorno seguro sin conexión (por ejemplo, en un ordenador separado sin acceso a internet) y almacenarse en varios lugares seguros. Nunca guardes una única copia de las claves en el servidor. Los archivos que importaste al cliente Prysm (/var/lib/ethereum/validator/keys y /var/lib/ethereum/validator/wallet) son tu copia de trabajo. Las claves originales que generaste deben guardarse por separado.
• Archivos de configuración de los clientes: Son los archivos geth.service, prysm-beacon.service, prysm-validator.service de /etc/systemd/system/. Contienen los parámetros de inicio de tus clientes.
• Secreto JWT: El archivo /var/lib/ethereum/jwt/jwtsecret.txt. Es necesario para la interacción entre clientes.
• Archivo de contraseña de la billetera Prysm: /var/lib/ethereum/validator/wallet-password.txt.

Qué NO respaldar:

• Datos de la cadena de bloques (Geth y Prysm): Los directorios /var/lib/ethereum/execution y /var/lib/ethereum/consensus. Estos datos ocupan terabytes y pueden resincronizarse desde cero si es necesario. Respaldarlos no es práctico ni eficiente.

2. Script simple de copia de seguridad automática

Crearemos un script simple para respaldar los archivos de configuración y el secreto JWT. Las claves del validador deben respaldarse manualmente y almacenarse en el lugar más seguro posible, no en el mismo VPS.

sudo mkdir -p /opt/backup_scripts
sudo nano /opt/backup_scripts/backup_configs.sh

Inserta el siguiente contenido:

#!/bin/bash
BACKUP_DIR="/tmp/validator_config_backup_$(date +%Y%m%d%H%M%S)"
CONFIG_FILES=(
    "/etc/systemd/system/geth.service"
    "/etc/systemd/system/prysm-beacon.service"
    "/etc/systemd/system/prysm-validator.service"
    "/var/lib/ethereum/jwt/jwtsecret.txt"
    "/var/lib/ethereum/validator/wallet-password.txt"
)

mkdir -p "$BACKUP_DIR"

for file in "${CONFIG_FILES[@]}"; do
    if [ -f "$file" ]; then
        cp "$file" "$BACKUP_DIR/"
        echo "Backed up: $file"
    else
        echo "Warning: File not found: $file"
    fi
done

# Архивируем и сжимаем
tar -czvf "$BACKUP_DIR.tar.gz" -C "$(dirname "$BACKUP_DIR")" "$(basename "$BACKUP_DIR")"
echo "Backup created: "$BACKUP_DIR.tar.gz""

# Очистка временной директории
rm -rf "$BACKUP_DIR"

# Теперь вы можете скопировать "$BACKUP_DIR.tar.gz" на внешнее хранилище
# Например, scp "$BACKUP_DIR.tar.gz" user@remote_host:/path/to/backups/

Haz el script ejecutable:

sudo chmod +x /opt/backup_scripts/backup_configs.sh

3. Dónde almacenar las copias de seguridad

Las copias de seguridad no deben almacenarse en el mismo servidor que los datos originales. Lugares de almacenamiento recomendados:

• Almacenamiento externo compatible con S3: Almacenamientos en la nube como Amazon S3, DigitalOcean Spaces, Backblaze B2. Puedes usar utilidades como s3cmd o rclone para la carga automática.
• VPS separado: Un VPS económico en otra ubicación, donde puedes copiar las copias de seguridad por SSH (usando scp o rsync).
• Ordenador local/NAS: Si tienes un almacenamiento local fiable con redundancia.

Añade el comando para copiar el archivo a un almacenamiento externo al final del script backup_configs.sh. Por ejemplo, para SSH:

# Внутри скрипта backup_configs.sh, после строки rm -rf "$BACKUP_DIR"
# scp "$BACKUP_DIR.tar.gz" user@remote_host:/path/to/backups/
# rm "$BACKUP_DIR.tar.gz" # Удалить локальную копию после успешной загрузки

4. Automatización de copias de seguridad con Cron

Configura Cron para ejecutar el script de copia de seguridad diaria o semanalmente.

sudo crontab -e

Añade la siguiente línea para una copia de seguridad diaria a las 03:00 de la mañana:

0 3 * * * /opt/backup_scripts/backup_configs.sh >> /var/log/validator_backup.log 2>&1

Este comando ejecutará el script cada día a las 03:00 y redirigirá la salida a un archivo de registro.

5. Actualizaciones: rolling vs maintenance window

Las actualizaciones regulares de los clientes de Ethereum y del sistema operativo son cruciales para la seguridad y el rendimiento. Siempre estate atento a los anuncios de los desarrolladores de los clientes (Geth, Prysm) sobre nuevas versiones.

• Actualización de clientes Ethereum:
  • Importancia: Actualiza lo antes posible después del lanzamiento de actualizaciones críticas (seguridad, corrección de errores, cambios importantes de protocolo).
  • Proceso: Generalmente implica descargar la nueva versión del archivo binario, reemplazar el antiguo y reiniciar el servicio Systemd.

    
    sudo systemctl stop geth prysm-beacon prysm-validator
    # Загрузите новые бинарники Geth, beacon-chain, validator в /tmp
    # sudo mv /tmp/new_geth /usr/local/bin/geth
    # sudo mv /tmp/new_beacon-chain /usr/local/bin/beacon-chain
    # sudo mv /tmp/new_validator /usr/local/bin/validator
    sudo systemctl start geth prysm-beacon prysm-validator
    

  • "Maintenance Window": Para actualizaciones importantes, es posible que se requiera una pequeña "ventana de mantenimiento" (unos minutos de inactividad) para evitar problemas. Sigue las recomendaciones de los desarrolladores.
  • "Rolling Updates": Algunas actualizaciones pueden ser "rolling", es decir, puedes actualizar los clientes de forma secuencial, minimizando el tiempo de inactividad.
• Actualización del sistema operativo:
  • Ejecuta regularmente sudo apt update && sudo apt upgrade -y.
  • Para actualizaciones del kernel o componentes importantes del sistema, puede ser necesario reiniciar el servidor (sudo reboot). Planifica esto para el momento de menor actividad.

Importante: Siempre lee las notas de la versión antes de actualizar y verifica la compatibilidad de las versiones del cliente de ejecución y del cliente de consenso. Asegúrate de tener una copia de seguridad de la configuración antes de realizar cambios significativos.