Cliente de ejecución Reth de Ethereum: arquitectura, configuración de nodo y operaciones RPC

Qué es Reth y dónde encaja

Reth (abreviatura de Rust Ethereum) es un cliente de capa de ejecución de Ethereum. Se encarga de la ejecución de transacciones, el almacenamiento del estado, la EVM y la superficie JSON-RPC que consultan las aplicaciones. No es un cliente de consenso: debe combinarse con un cliente de baliza/consenso, como los que implementan la Engine API, que gestiona la elección de bifurcación, las tareas de validador y el gossip de bloques.

El proyecto se desarrolla abiertamente por Paradigm y una amplia base de colaboradores, y se distribuye bajo la licencia Apache/MIT. Sus objetivos de diseño declarados son la modularidad, el rendimiento y la facilidad para contribuir. Como el código se organiza en crates separados, los mismos componentes pueden ensamblarse en un nodo completo estándar de Ethereum, un nodo de archivo o una cadena personalizada compatible con la EVM.

Una advertencia de nomenclatura antes de continuar: el ticker del token "rETH" (Rocket Pool ETH) no tiene relación con el cliente Reth. Si llegaste buscando el precio de un token de staking líquido, este no es ese tema. Todo lo que sigue trata sobre el software del nodo.

• Cliente de ejecución: ejecuta transacciones, mantiene el estado y sirve JSON-RPC.
• Requiere un cliente de consenso conectado a través de la Engine API.
• Admite modos completo y de archivo según la configuración de poda.
• Los crates modulares permiten nodos personalizados y extensiones de ejecución (ExEx).

Supuestos y requisitos previos

Esta guía supone que tienes acceso administrativo a un host Linux, una comprensión básica de la separación ejecución/consenso de Ethereum y un cliente de consenso ya instalado o listo para instalar. También supone que te manejas con systemd, reglas de firewall y la lectura de logs.

Los requisitos de hardware varían según el modo. Un nodo completo necesita bastante más disco que un cliente ligero y se beneficia de almacenamiento NVMe rápido; un nodo de archivo necesita considerablemente más. En lugar de citar cifras fijas que cambian con el crecimiento de la cadena y las versiones de los clientes, consulta los requisitos actuales en la documentación oficial de Reth antes de aprovisionar y luego dimensiona el almacenamiento con margen para el crecimiento. La memoria y la CPU deben dimensionarse para tu carga de trabajo RPC, no solo para la sincronización.

• Un cliente de consenso (nodo de baliza) con soporte de la Engine API.
• Un secreto JWT compartido entre los clientes de ejecución y de consenso.
• Disco local persistente y rápido; evita el almacenamiento conectado por red para la base de datos.
• Acceso a internet saliente para el descubrimiento de pares y la sincronización por snap.

La arquitectura modular en forma de modelo mental

Piensa en Reth como una canalización con etapas reemplazables. La red y la descarga de bloques alimentan una canalización de sincronización por etapas que ejecuta bloques y escribe el estado. Una capa de almacenamiento persiste cabeceras, cuerpos, recibos y estado. Encima se sitúa el servidor RPC, que lee de ese almacenamiento y puede ampliarse.

El diseño de sincronización por etapas es el concepto operativo clave. En lugar de ejecutar cada bloque en estricta secuencia desde el génesis en una sola pasada, Reth procesa la cadena por etapas (cabeceras, cuerpos, remitentes, ejecución, etc.), cada una de las cuales puede reanudarse. Por eso el progreso de la sincronización se informa por etapa y por eso un reinicio generalmente se reanuda en lugar de empezar de cero. Cuando diagnosticas una sincronización lenta o detenida, normalmente estás diagnosticando una etapa.

El mecanismo de extensiones de ejecución (ExEx) te permite suscribirte a bloques confirmados y ejecutar lógica personalizada en el mismo proceso, lo que resulta útil para indexadores y servicios fuera de la cadena. Para la mayoría de los operadores, sin embargo, la superficie práctica es la CLI, el archivo de configuración y la API RPC.

Instalar Reth y preparar el host

Instala mediante tu gestor de paquetes donde exista una fórmula, o compila desde el código fuente si necesitas un commit específico. Los comandos siguientes usan marcadores de posición; sustituye tu propio directorio de datos y la ruta del JWT.

Crea un usuario de servicio dedicado, un directorio de datos y un secreto JWT. El secreto JWT debe ser idéntico para los clientes de ejecución y de consenso, y solo esos servicios deben poder leerlo.

# Example host preparation (adjust paths and user to your environment)
sudo useradd --system --home /var/lib/reth reth
sudo mkdir -p /var/lib/reth/data /var/lib/reth/jwt
sudo openssl rand -hex 32 | sudo tee /var/lib/reth/jwt/jwt.hex > /dev/null
sudo chown -R reth:reth /var/lib/reth
sudo chmod 600 /var/lib/reth/jwt/jwt.hex

# Install via Homebrew on macOS/Linux where available
brew install paradigmxyz/brew/reth

# Or build from source
# git clone https://github.com/paradigmxyz/reth && cd reth
# cargo build --release --locked

Ejecutar un nodo con JSON-RPC habilitado

Inicia Reth con un directorio de datos explícito, la Engine API habilitada para tu cliente de consenso y solo los espacios de nombres RPC que realmente necesites. Exponer eth, net y web3 es lo habitual para backends de aplicaciones; debug y trace son costosos y deben habilitarse de forma deliberada.

Vincula el servidor HTTP a localhost de forma predeterminada y coloca un proxy inverso delante si se requiere acceso remoto. El ejemplo siguiente mantiene el RPC local y apunta la Engine API al puerto autenticado del cliente de consenso.

reth node \
  --datadir /var/lib/reth/data \
  --authrpc.addr 127.0.0.1 \
  --authrpc.port 8551 \
  --authrpc.jwtsecret /var/lib/reth/jwt/jwt.hex \
  --http \
  --http.addr 127.0.0.1 \
  --http.port 8545 \
  --http.api eth,net,web3 \
  --metrics 127.0.0.1:9001

Verificar que el nodo esté saludable

La verificación tiene tres capas: el proceso está en ejecución, el cliente de ejecución sigue la cabeza de la cadena y el RPC responde correctamente. Revisa primero los logs en busca de errores de autenticación de la Engine API, que normalmente significan que el secreto JWT no coincide con la copia del cliente de consenso.

Después consulta el RPC. Un nodo sincronizado devuelve un número de bloque reciente que avanza con el tiempo, y eth_syncing devuelve false. Compara la cabeza informada con un explorador de bloques público para confirmar que no estás retrasado de forma silenciosa.

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

curl -s -X POST http://127.0.0.1:8545 \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":2,"method":"eth_syncing","params":[]}'

curl -s -X POST http://127.0.0.1:8545 \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":3,"method":"web3_clientVersion","params":[]}'

Un procedimiento de medición reproducible para sincronización y RPC

Las afirmaciones de rendimiento publicadas solo tienen sentido en relación con el hardware, los pares y la carga de trabajo. En lugar de confiar en una cifra de una entrada de blog, mide en tu propio host y registra las condiciones. El procedimiento siguiente produce una tabla de resultados que puedes comparar entre configuraciones.

Primero, registra el entorno: modelo de CPU, RAM, tipo de disco, versión del kernel, versión de Reth, versión del cliente de consenso y número de pares. Segundo, mide la sincronización muestreando el número de bloque a intervalos fijos desde una base de datos limpia y calculando bloques por minuto por etapa. Tercero, mide la latencia RPC emitiendo un lote fijo de llamadas de solo lectura (por ejemplo eth_blockNumber, eth_getBlockByNumber y eth_getBalance para una dirección fija) y registrando p50 y p95 sobre al menos unos cientos de muestras. Cuarto, repite tras cualquier cambio de configuración.

Registra los resultados en una tabla como la siguiente. Deja las celdas para rellenarlas con tus valores medidos; no copies cifras de otros sitios.

• | Métrica | Configuración A | Configuración B |
• | Bloques/min de sincronización (etapa de ejecución) | medido | medido |
• | Tiempo hasta la cabeza desde una BD limpia | medido | medido |
• | Latencia p50 de RPC (ms) | medido | medido |
• | Latencia p95 de RPC (ms) | medido | medido |
• | RSS máximo (GB) | medido | medido |
• | Disco usado tras la sincronización (GB) | medido | medido |

Exponer RPC a las aplicaciones de forma segura

Un nodo que sirve a tus propias aplicaciones no debería ser la misma superficie que un endpoint público. Mantén el RPC vinculado a localhost, termina TLS en un proxy inverso, añade autenticación o listas de IP permitidas y limita la tasa por cliente. Deshabilita los espacios de nombres que no necesites; debug y trace pueden agotar la memoria y la CPU.

Si prefieres no operar el nodo tú mismo, un endpoint gestionado elimina la carga de sincronización, actualización y conmutación por error. El servicio de API RPC de OnFinality ofrece endpoints multicadena, y puedes comparar planes en la página de precios de RPC. Para equipos que necesitan capacidad aislada, un nodo dedicado es la opción relevante. Si aún estás eligiendo proveedor, la guía del RPC Assistant sobre la mejor API RPC de Ethereum cubre los criterios de selección.

// Minimal client-side health check against your own RPC_URL
const RPC_URL = process.env.RPC_URL; // e.g. http://127.0.0.1:8545

async function head() {
  const res = await fetch(RPC_URL, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ jsonrpc: '2.0', id: 1, method: 'eth_blockNumber', params: [] }),
  });
  const { result } = await res.json();
  return parseInt(result, 16);
}

const a = await head();
await new Promise((r) => setTimeout(r, 15000));
const b = await head();
console.log({ start: a, end: b, advanced: b - a });

Solución de problemas comunes de Reth

La mayoría de los problemas operativos caen en un pequeño conjunto de categorías. Abórdalos en orden en lugar de cambiar varias variables a la vez.

Fallos de autenticación de la Engine API. Los clientes de ejecución y de consenso deben compartir el mismo archivo de secreto JWT. Confirma que ambos apuntan a la misma ruta y que los permisos permiten a ambos servicios leerlo.

La sincronización parece detenida. Comprueba qué etapa está activa en los logs. Una etapa de ejecución detenida suele indicar saturación del disco o memoria insuficiente; una etapa de descarga detenida apunta a problemas de pares o de red. Reiniciar reanuda desde la última etapa confirmada, así que evita borrar la base de datos como primera respuesta.

Tiempos de espera de RPC bajo carga. Confirma que no has habilitado espacios de nombres pesados, comprueba si el proxy inverso tiene un tiempo de espera más corto que el cliente y mide la latencia p95 antes y después de los cambios. Si el nodo está limitado por la CPU, añadir réplicas detrás de un balanceador de carga suele ser mejor que ajustar una única instancia indefinidamente.

El disco se llena inesperadamente. El modo de archivo y la retención prolongada de recibos y estado crecen de forma constante. Supervisa el uso de disco como una métrica de primer nivel y alerta con margen suficiente antes de llegar a la capacidad.

Limitaciones y compromisos

Reth es un cliente de ejecución completo, no un producto RPC llave en mano. Sigues siendo responsable de las actualizaciones, la supervisión, las copias de seguridad y la respuesta a incidentes. Sus características de rendimiento dependen en gran medida del almacenamiento y la memoria, así que un cliente rápido sobre discos lentos no ofrecerá el rendimiento que esperas.

Ejecutar tu propio nodo te da soberanía sobre los datos, espacios de nombres personalizados y la capacidad de ampliar el comportamiento en el mismo proceso. Los endpoints gestionados intercambian parte de ese control por simplicidad operativa y capacidad elástica. Ninguna opción es universalmente correcta; la decisión depende del volumen de consultas, los requisitos de cumplimiento y cuánto tiempo de ingeniería puedes dedicar a las operaciones del nodo.

Por último, la diversidad de clientes importa para la red en su conjunto. Ejecutar Reth junto con otros clientes de ejecución en entornos distintos reduce el riesgo de fallos correlacionados, y es una razón por la que muchos equipos de infraestructura mezclan clientes deliberadamente en lugar de estandarizarse en uno solo.

Próximos pasos

Una vez que tu nodo esté sincronizado y verificado, el siguiente trabajo es el endurecimiento operativo: una unidad de systemd con política de reinicio, rotación de logs, scraping de Prometheus del endpoint de métricas, alertas sobre el retraso de la cabeza y el uso de disco, y un procedimiento de actualización documentado. Si planeas servir varias aplicaciones, coloca una capa de caché y limitación de tasa delante del RPC.

Para los equipos que se expanden más allá de Ethereum, revisa las redes disponibles y la guía de alojamiento de nodos de blockchain más amplia antes de decidir qué autoalojar. Si quieres una recomendación concreta de endpoint en lugar de una ruta de construcción propia, el RPC Assistant puede preseleccionar proveedores; esta página se detiene deliberadamente en la metodología.