Nodos de Solana: validadores, nodos RPC y self-hosting

Una wallet que lee un balance, un explorador que recupera una transacción de hace dos años y un sistema de trading que consume actualizaciones de cuentas pueden parecer que usan el mismo servicio de Solana. Por debajo, dependen de infraestructura distinta.

Para los equipos de aplicaciones, la pregunta útil no es simplemente "¿deberíamos correr un nodo de Solana?". Es: ¿qué cargas de trabajo necesita nuestra aplicación, y qué partes del stack deberíamos operar nosotros mismos?

¿Cuáles son las tres capas de infraestructura de Solana?

Al construir sobre Solana, hay 3 tipos de infraestructura que parten todos de los nodos de Solana. Entonces, ¿qué es un nodo de Solana? En pocas palabras, un nodo de Solana es un servidor que corre el software cliente de validador.

Los validadores que votan aseguran y producen la cadena, mientras que los nodos remote procedure call (RPC) que no votan exponen el estado en vivo y las APIs de transacciones. Sistemas separados de archivo, indexación, caché y streaming atienden cargas de trabajo que un nodo estándar no puede retener o responder de forma eficiente por sí solo.

Los validadores que votan aseguran la cadena

Los validadores que votan participan en el consenso y ayudan a la red a acordar la cadena canónica. También producen bloques cuando son seleccionados como líder. Su responsabilidad principal es mantenerse sincronizados, votar correctamente y cumplir de forma confiable con las funciones de líder.

Las aplicaciones dependen de este consenso, pero la mayoría de las solicitudes de las aplicaciones no se envían directamente a los validadores que votan.

Los nodos RPC atienden el tráfico en vivo de las aplicaciones

Un nodo RPC generalmente corre el mismo software cliente de validador sin votar. Sigue al cluster, reproduce bloques y mantiene el estado actual de las cuentas, pero no vota ni entra en el calendario de líderes.

En cambio, expone la interfaz RPC de Solana. Wallets, exchanges, exploradores, bots y otras aplicaciones usan esa interfaz para consultar datos de la cadena, simular transacciones y enviar transacciones.

Un validador que vota técnicamente también puede exponer RPC. En producción, los operadores normalmente mantienen esa interfaz privada o restringida para que el tráfico impredecible de las aplicaciones no compita con el consenso y la producción de bloques.

Sistemas secundarios atienden cargas de trabajo de datos especializadas

Los nodos RPC exponen la API de Solana, pero los proveedores no tienen que responder cada solicitud directamente desde un nodo en vivo. Pueden usar sistemas construidos para:

• historial de transacciones y bloques a largo plazo
• indexación de cuentas y consultas filtradas costosas
• caché de datos solicitados con frecuencia
• streams en tiempo real con filtrado, buffering, replay y recuperación

Para los métodos RPC estándar atendidos por estos sistemas, las aplicaciones pueden seguir usando los mismos métodos, parámetros, filtros y formatos de respuesta de la API con los que ya están familiarizadas. Solo cambia el sistema que responde la solicitud. El historial antiguo proviene de almacenamiento separado porque el nodo en vivo ya no lo tiene, mientras que las consultas costosas del estado actual pueden atenderse de forma más eficiente desde índices o cachés dedicados.

¿Qué capa de infraestructura maneja cada carga de trabajo de Solana?

Consideremos algunas solicitudes comunes de aplicaciones:

• Una wallet verifica un balance o simula una transacción. Un nodo RPC en vivo puede responder directamente desde el estado actual.
• Un explorador carga una transacción de hace dos años. La aplicación sigue llamando a un método RPC estándar, pero el proveedor responde desde almacenamiento de archivo porque el nodo en vivo ya no tiene los datos.
• Una app de portafolio consulta todas las cuentas propiedad de un programa grande. El mismo método RPC y los mismos filtros pueden atenderse desde un índice o caché de cuentas en lugar de hacer que un nodo escanee su estado repetidamente.
• Un sistema de trading necesita cada actualización de cuenta o transacción a medida que ocurre. Usa infraestructura de streaming para entrega continua, a menudo junto con RPC para consultas puntuales.
• Un operador de red quiere votar y producir bloques. Eso requiere un validador que vote, no un servicio de RPC para aplicaciones.

Un proveedor puede exponer varias de estas capacidades como un solo servicio. La aplicación ve interfaces familiares mientras distintos sistemas hacen el trabajo detrás de ellas.

¿Cómo sirven los nodos de Solana los datos históricos?

Métodos como getTransaction, getBlock y getSignaturesForAddress pueden consultar actividad antigua. Un nodo RPC estándar, sin embargo, retiene localmente solo una ventana limitada del ledger. Una vez que los datos antiguos se han eliminado (pruned), agregar más CPU no hace que la consulta funcione. Los datos ya no están en ese nodo.

Los datos de archivo profundos de Solana requieren una ruta separada que:

1. Ingiere bloques y transacciones desde fuentes en vivo e históricas
2. Detecta y repara datos faltantes
3. Almacena los datos para retención prolongada y alto volumen de consultas
4. Sirve solicitudes RPC históricas desde esa capa de almacenamiento

Por eso "archive RPC" no es simplemente un nodo normal con un disco más grande. A escala de producción, los proveedores típicamente sirven archive RPC desde sistemas separados de almacenamiento y consulta, presentados a través de una interfaz RPC familiar.

En Alchemy, aprendimos esta limitación directamente. Al principio usamos Google Bigtable para el historial de Solana, y luego reconstruimos el stack de archivo sobre HBase autogestionado. Hoy, cada registro se escribe dos veces, se valida programáticamente y se escanea en busca de completitud. Cuando el sistema encuentra un vacío, reingiere la entrada faltante. Métodos históricos como getTransaction y getSignaturesForAddress ahora leen desde esta capa de datos optimizada en lugar de depender de la retención local de la flota RPC en vivo, para brindar la velocidad y confiabilidad que nuestros clientes esperan.

¿Por qué getProgramAccounts es costoso?

getProgramAccounts ilustra una limitación distinta. Los datos de la cuenta existen en el estado actual, pero responder la solicitud puede requerir buscar en un conjunto grande de cuentas y aplicar filtros en el momento de la consulta.

Un nodo almacena cuentas principalmente para poder reproducir bloques y mantener el estado actual de la cadena. No es una base de datos analítica de propósito general. Los escaneos directos ocasionales pueden ser aceptables, pero escanear repetidamente millones de cuentas se vuelve lento e intensivo en recursos bajo tráfico de producción.

Para cargas de trabajo sostenidas, los operadores pueden consumir actualizaciones de cuentas de forma continua y mantener índices o vistas cacheadas orientadas a consultas. Las solicitudes entonces leen resultados preparados en lugar de repetir un escaneo completo cada vez.

Las solicitudes repetidas de getProgramAccounts son un problema de indexación, no una solicitud de un nodo más grande. Dicho de otra forma, la distinción no es "nodo pequeño versus nodo grande". Es servir datos desde un nodo en vivo versus servir datos indexados.

¿Cómo funcionan el streaming de Geyser y gRPC?

Los sistemas de trading, los indexadores y otras aplicaciones en tiempo real a menudo necesitan procesar actualizaciones de cuentas, transacciones, slots o bloques a medida que ocurren.

Las suscripciones por WebSocket forman parte de la interfaz estándar de Solana y funcionan bien para eventos en vivo seleccionados. Para cargas de trabajo que necesitan menor latencia, mayor throughput o filtrado más rico, Yellowstone gRPC ofrece una interfaz de streaming más performante construida sobre gRPC sobre HTTP/2.

El cliente validador Agave, incluso cuando corre como nodo RPC sin votar, también puede correr plugins de Geyser. Geyser emite actualizaciones de cuentas, transacciones, slots y bloques a medida que el nodo procesa la cadena. Los proveedores pueden exponer esos datos a través de Solana gRPC compatible con Yellowstone, agregando filtrado, buffering, replay, confiabilidad y entrega multi-nodo.

El streaming no reemplaza al RPC. El RPC responde una pregunta sobre el estado. El streaming le indica a la aplicación que el estado cambió. Muchos sistemas de producción usan ambos.

¿Cuándo deberías autoalojar infraestructura de Solana?

La mayoría de los equipos de aplicaciones deberían empezar con un proveedor. Un solo nodo RPC autoalojado no cubre automáticamente todos los casos de uso que necesitas (proveer historial duradero, consultas indexadas, APIs replicadas globalmente o streams de datos), y hacerlo de forma confiable implica mucho trabajo.

Autoalojar tiene sentido cuando el control sobre tu infraestructura mejora el producto o cuando los requisitos de política descartan un servicio administrado. Ejemplos incluyen:

• un operador de validador que participa en el consenso
• un sistema de trading sensible a la latencia que necesita ubicación específica del nodo o control del ruteo de transacciones
• un servicio que requiere plugins de Geyser personalizados, índices o políticas de retención
• una organización con requisitos estrictos de cumplimiento o control de infraestructura
• una plataforma grande cuyo tráfico sostenido justifica un equipo dedicado de infraestructura

La prueba es si ser dueño de la infraestructura genera una ventaja medible que compensa el trabajo de hardware, ingeniería y guardias.

¿Qué se necesita para operar infraestructura de Solana?

La guía de hardware actual de Agave establece un punto de partida alto antes de considerar el tráfico de producción, la redundancia y los sistemas de datos adyacentes.

El hardware es solo el piso. Bajo el sistema de consenso actual de Solana, los validadores que votan también pueden gastar hasta aproximadamente 1.1 SOL por día en transacciones de voto. Los servicios RPC de producción necesitan nodos redundantes para evitar un único punto de falla. Los equipos que se autoalojan y requieren historial profundo, índices o streams confiables también deben operar esos sistemas.

¿Cómo se corre un nodo de Solana?

La configuración empieza con el rol, no con la línea de comandos.

1. Elige la carga de trabajo. Decide si el despliegue va a votar, servir RPC o alimentar un pipeline de datos especializado.
2. Aprovisiona el host. Ajusta los requisitos actuales de CPU, memoria, almacenamiento, ancho de banda, sistema operativo e IP pública al cliente y al rol.
3. Configura el rol. Un operador de RPC corre sin votar y selecciona el historial, los índices de cuentas y la configuración de retención requeridos. Un operador de validador configura su identidad y su cuenta de voto.
4. Protege claves y endpoints. Mantén las claves sensibles fuera del host del validador. Coloca los endpoints públicos de RPC y WebSocket detrás de autenticación, límites de tasa y balanceo de carga.
5. Opera el servicio completo. Monitorea la sincronización, el disco, la CPU, la red, la salud de los procesos y los errores a nivel de aplicación. Planifica actualizaciones, recuperación, failover y abuso.

Usa las guías mantenidas de Agave para los comandos y flags actuales del validador o la configuración de nodos RPC.

¿Cómo deberías evaluar a un proveedor de infraestructura de Solana?

Empieza por las cargas de trabajo que tu aplicación necesita, y luego pregunta cómo el proveedor atiende cada una.

Haz benchmark de los métodos, suscripciones y regiones que tu aplicación va a usar. La guía de proveedores de RPC de Solana compara las opciones actuales según esos criterios.

La conclusión

Una aplicación de Solana no necesita "un nodo" en abstracto. Necesita capacidades específicas: estado en vivo, APIs de transacciones, historial, consultas indexadas, streams o, en un conjunto mucho más pequeño de casos, participación en el consenso.

Identifica primero esas cargas de trabajo. Luego decide qué partes del stack ofrecen una ventaja real cuando se operan internamente y cuáles conviene obtener de un servicio administrado.

Construye en Solana con Alchemy

La mayoría de los equipos de aplicaciones no necesitan operar su propia flota de RPC, bases de datos de archivo, índices e infraestructura de streaming. Proveemos RPC de Solana en vivo para estado y transacciones, historial de bloques y transacciones desde el génesis mediante métodos estándar, y gRPC compatible con Yellowstone para streams en tiempo real.

Empieza a construir en Solana, sigue la guía rápida de la API de Solana, o habla con nuestro equipo sobre capacidad dedicada y cargas de trabajo personalizadas.

Preguntas frecuentes

¿Qué es un nodo de Solana?

Un nodo de Solana es un servidor que corre el software cliente de validador. Sigue al cluster, reproduce bloques, mantiene el estado actual de la cadena y se comunica con otros pares. Los validadores que votan participan en el consenso y la producción de bloques. Los nodos RPC que no votan exponen las APIs para aplicaciones.

¿Cuál es la diferencia entre un validador y un nodo RPC?

Ambos siguen y reproducen la cadena. Un validador que vota participa en el consenso y puede producir bloques cuando es seleccionado como líder. Un nodo RPC no vota ni entra en el calendario de líderes. Se enfoca en servir estado en vivo y APIs de transacciones a las aplicaciones.

¿Es un archive node un tipo separado de nodo de Solana?

No usualmente. El historial profundo de transacciones y bloques generalmente lo sirve un sistema de datos de archivo separado detrás de una interfaz compatible con RPC, no un nodo estándar con un disco más grande.

¿Las aplicaciones necesitan correr un validador?

Usualmente no. Las aplicaciones dependen de los validadores para establecer la cadena, pero sus propias solicitudes normalmente van a nodos RPC y servicios de datos especializados. Correr un validador es necesario para la participación en el consenso, no para el acceso ordinario de las aplicaciones.

¿Cuáles son los requisitos de hardware para un validador o nodo RPC de Solana?

La guía actual de Agave empieza en 12 cores, 24 threads y 256 GB de RAM para un validador que vota. Un nodo RPC que no vota empieza en 16 cores y 32 threads, con 512 GB de RAM recomendados al correr todos los índices de cuentas. Ambos requieren almacenamiento NVMe rápido y redes confiables.

¿Necesito SOL para correr un nodo de Solana?

Un nodo RPC que no vota no requiere SOL para votar. Un validador que vota necesita cuentas de identidad y de voto fondeadas, y paga los costos de las transacciones de voto bajo el sistema de consenso actual.

¿Es rentable correr un validador de Solana?

Depende del stake delegado, el desempeño de voto, la comisión, los ingresos por comisiones de transacción cuando es seleccionado como líder, los ingresos por maximum extractable value y los costos operativos. Los validadores con poco stake delegado a menudo tienen dificultades para cubrir gastos. Trata la operación de un validador como su propio negocio de infraestructura, no como una forma de dar acceso RPC a una aplicación.

¿Cómo se corre un nodo de Solana?

Elige primero el rol, aprovisiona según los requisitos actuales del cliente, configura el comportamiento de voto o RPC, protege las claves y los endpoints, y agrega monitoreo y failover. Usa la documentación actual de Agave para los comandos y flags porque los releases soportados y las recomendaciones cambian.

¿Debería autoalojar un nodo RPC o usar un proveedor?

Usa un proveedor cuando necesites capacidad administrada, datos históricos, métodos indexados, streaming o failover sin operar esos sistemas tú mismo. Autoalójate cuando el control, la configuración personalizada, la ubicación física, la escala sostenida o los requisitos de política justifiquen un equipo dedicado de infraestructura.