Servidor RPC de Solana: Cómo conectar, configurar y escalar

Un servidor RPC de Solana es el servicio con el que tu aplicación se comunica cuando necesita leer el estado de la cadena de bloques o enviar una transacción. En lugar de ejecutar un validador o un nodo RPC tú mismo, apuntas tu cliente a un endpoint HTTP (y normalmente a un endpoint WebSocket) que habla el dialecto JSON-RPC de Solana. Todo, desde una consulta de saldo de una wallet hasta un intercambio de tokens, comienza con una solicitud a ese servidor.

Esta página está escrita para desarrolladores que ya saben que necesitan un servidor RPC de Solana y quieren conectar uno correctamente, y luego decidir si un endpoint compartido es suficiente o si un nodo dedicado es la mejor opción. Si todavía estás comparando proveedores a alto nivel, comienza con cómo elegir un proveedor de RPC y vuelve aquí para la configuración específica de Solana.

Elegir entre RPC de Solana público, gestionado y dedicado

La forma más rápida de decidir es hacer coincidir tu carga de trabajo con el tipo de endpoint. La mayoría de los equipos comienzan con un endpoint público o compartido, y luego suben de nivel cuando alcanzan un límite específico en lugar de una vaga sensación de que las cosas van lentas.

OnFinality proporciona RPC de Solana a través de un servicio de API RPC gestionado y mediante nodos dedicados cuando necesitas capacidad aislada. El endpoint gestionado es el punto de partida adecuado para la mayoría de las aplicaciones; los nodos dedicados son para equipos que han superado el rendimiento compartido o necesitan recursos predecibles.

Una regla general rápida: si tus errores son principalmente respuestas 429, necesitas un plan gestionado con clave o un nodo dedicado. Si tus errores son timeouts en llamadas pesadas como getProgramAccounts, necesitas más memoria y un nodo dedicado en lugar de un plan compartido más grande.

Configuración del servidor RPC de Solana de un vistazo

Cuando configuras una wallet, un framework o un servicio backend, necesitas los parámetros de la red, no solo la URL. Para Solana mainnet, estos son los valores que debes usar.

Para desarrollo y pruebas, usa un endpoint devnet en lugar de mainnet para no gastar SOL real. OnFinality expone un endpoint separado de Solana Devnet, y puedes solicitar SOL de devnet desde el faucet estándar de Solana para financiar transacciones de prueba. Mantén la configuración de devnet y mainnet en variables de entorno separadas para que una clave de prueba nunca apunte a mainnet por accidente.

Un patrón común es almacenar el endpoint en una variable de entorno y leerlo al inicio:

SOLANA_RPC_URL=https://solana.api.onfinality.io/public
SOLANA_WS_URL=wss://solana.api.onfinality.io/public-ws

Conexión con curl y JavaScript

La forma más sencilla de confirmar que un servidor RPC de Solana responde es una llamada JSON-RPC sobre HTTP. Solana usa el mismo sobre JSON-RPC 2.0 que otras cadenas, pero con métodos específicos de Solana.

curl https://solana.api.onfinality.io/public \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getLatestBlockhash",
    "params": [{"commitment": "confirmed"}]
  }'

Una respuesta saludable devuelve un objeto result que contiene un blockhash y lastValidBlockHeight. Si en su lugar obtienes un objeto de error, el endpoint es accesible pero la solicitud fue rechazada, lo que generalmente indica un método o parámetro mal formado en lugar de un problema de red.

En JavaScript, la librería @solana/web3.js envuelve estas llamadas. Apunta la conexión a tu endpoint y pasa un nivel de commitment:

import { Connection, PublicKey, clusterApiUrl } from "@solana/web3.js";

const connection = new Connection(
  process.env.SOLANA_RPC_URL,
  { commitment: "confirmed", wsEndpoint: process.env.SOLANA_WS_URL }
);

const balance = await connection.getBalance(
  new PublicKey("11111111111111111111111111111111")
);
console.log("lamports:", balance);

Los niveles de commitment importan en Solana. processed es el más rápido pero puede revertirse, confirmed es el predeterminado común para la mayoría de las aplicaciones, y finalized es el más seguro para la lógica de liquidación. Elige el nivel que coincida con el riesgo de la acción, no el más rápido disponible.

Suscripciones WebSocket y cuándo usarlas

Los servidores RPC de Solana también exponen un transporte WebSocket para actualizaciones basadas en push. En lugar de sondear getSlot o getAccountInfo en un bucle, te suscribes y recibes notificaciones cuando cambia el estado.

const subId = connection.onAccountChange(
  new PublicKey("11111111111111111111111111111111"),
  (accountInfo, context) => {
    console.log("slot", context.slot, "lamports", accountInfo.lamports);
  },
  "confirmed"
);

Las suscripciones WebSocket son eficientes, pero mantienen una conexión abierta, y los endpoints compartidos a menudo limitan las suscripciones concurrentes. Si ejecutas muchas suscripciones en muchos usuarios, controla tu recuento de conexiones y planifica reconexiones. Las suscripciones pueden caerse durante la congestión de la red, así que siempre maneja el evento de desconexión y vuelve a suscribirte en lugar de asumir que el flujo es permanente.

Para uso de alta frecuencia, un nodo dedicado te da un presupuesto de suscripción estable y evita competir con otros inquilinos por la entrega de notificaciones.

Modos de fallo comunes y cómo interpretarlos

La mayoría de los problemas de RPC de Solana se reducen a un pequeño conjunto de síntomas. Hacer coincidir el síntoma con la causa ahorra muchas conjeturas.

Dos de estos merecen más detalle. Primero, getProgramAccounts sin filtros es una de las llamadas más pesadas en Solana. Puede escanear una gran cantidad de datos de cuentas, y en un endpoint compartido suele ser la primera llamada en ser limitada. Añade filtros de tamaño de datos y memcmp para reducir el conjunto de resultados antes de culpar al endpoint.

Segundo, el aterrizaje de transacciones no se trata solo del servidor RPC. Solana usa un blockhash que expira después de una ventana corta, por lo que una transacción construida con un blockhash antiguo fallará incluso en un endpoint perfectamente saludable. Obtén un blockhash nuevo, establece una tarifa de prioridad razonable y reintenta con retroceso exponencial.

Lista de verificación para producción

Antes de enviar tráfico real a un servidor RPC de Solana, revisa estos puntos. Son la diferencia entre una demo y algo que sobrevive a un día ajetreado.

• Entornos separados. Mantén los endpoints y claves de devnet y mainnet en configuraciones distintas.
• Establece niveles de commitment deliberadamente. Usa confirmed para la mayoría de las lecturas y finalized para liquidación.
• Maneja los límites de velocidad. Detecta respuestas 429 y retrocede en lugar de reintentar inmediatamente.
• Planifica el failover. Configura un endpoint secundario para que una única caída no derribe tu aplicación.
• Monitorea el retraso de slot. Rastrea qué tan lejos está tu nodo de la punta del clúster.
• Vigila la salud de WebSocket. Registra desconexiones y éxito de resuscripción.
• Presupuesta para llamadas pesadas. Conoce qué métodos usa más tu aplicación y dimensiona en consecuencia.

Si varios de estos puntos ya son problemáticos en un endpoint compartido, esa es la señal para evaluar un nodo dedicado. Puedes comparar planes en la página de precios de RPC y ver la lista completa de redes RPC compatibles si también operas en otras cadenas.

Ejecutar tu propio servidor RPC de Solana vs alquilar uno

Puedes ejecutar un nodo RPC de Solana tú mismo. La compensación es operativa, no solo financiera. Un nodo RPC de Solana necesita una cantidad sustancial de RAM, almacenamiento NVMe rápido y atención continua a snapshots, actualizaciones y monitoreo. El ledger crece continuamente, por lo que la planificación del almacenamiento es una tarea recurrente, no una configuración única.

Alquilar un endpoint gestionado o un nodo dedicado traslada esa carga operativa al proveedor. Tú sigues eligiendo la región, la capacidad y el transporte, pero no estás parcheando el nodo o restaurando snapshots a las 2 de la mañana. Para la mayoría de los equipos de producto, ese es el mejor uso del tiempo de ingeniería. Para equipos con estrictos requisitos de localización de datos o cumplimiento, el autoalojamiento puede seguir siendo la opción correcta, y un enfoque híbrido (primario autoalojado, failover gestionado) es común.

OnFinality se sitúa en el campo gestionado: obtienes un endpoint RPC de Solana y, cuando es necesario, un nodo dedicado sin ejecutar la infraestructura tú mismo. La página de red de Solana lista los detalles actuales del endpoint y los transportes.

Migrar desde un endpoint público sin romper cosas

Pasar de un servidor RPC de Solana público a uno gestionado o dedicado debería ser un cambio de configuración, no una reescritura. Los pasos son sencillos si los preparas.

1. Añade el nuevo endpoint junto al antiguo. No elimines todavía la URL pública.
2. Enruta un pequeño porcentaje del tráfico al nuevo endpoint y compara tasas de error y latencia.
3. Actualiza la configuración de WebSocket por separado, ya que los endpoints HTTP y WS son distintos.
4. Verifica que los niveles de commitment se comporten igual en el nuevo endpoint.
5. Cambia el predeterminado una vez que las tasas de error sean estables, manteniendo el endpoint antiguo como failover.
6. Elimina el endpoint público solo después de un ciclo completo de tráfico sin regresiones.

Dado que el RPC de Solana es JSON-RPC sobre HTTP, la migración suele ser un cambio de URL en tus variables de entorno más un redespliegue. El riesgo está en los detalles: olvidar la URL de WebSocket, o cambiar los niveles de commitment al mismo tiempo que el endpoint, lo que dificulta saber qué causó un cambio en el comportamiento.

Puntos clave

• Un servidor RPC de Solana es la interfaz HTTP y WebSocket que tu aplicación usa para leer el estado y enviar transacciones.
• Mainnet usa el nombre de cadena Solana Mainnet, SOL con 9 decimales, y el explorador en explorer.solana.com.
• Comienza con un endpoint compartido o público, luego pasa a un nodo gestionado o dedicado cuando encuentres límites de velocidad o timeouts en llamadas pesadas.
• Los niveles de commitment (processed, confirmed, finalized) deben coincidir con el riesgo de cada acción.
• Las suscripciones WebSocket son eficientes pero necesitan manejo de reconexión y resuscripción.
• getProgramAccounts y los blockhashes expirados son dos de las fuentes más comunes de confusión.
• La migración suele ser un cambio de configuración, pero actualiza los endpoints HTTP y WebSocket juntos.

Preguntas frecuentes

¿Qué es un servidor RPC de Solana?

Es un servicio que expone la API JSON-RPC de Solana sobre HTTP y WebSocket, permitiendo que tu aplicación lea cuentas, envíe transacciones y se suscriba a eventos sin ejecutar un nodo tú mismo.

¿Cuál es la URL RPC de Solana para mainnet?

OnFinality expone Solana mainnet en https://solana.api.onfinality.io/public para HTTP y wss://solana.api.onfinality.io/public-ws para WebSocket. Confirma siempre los endpoints actuales en la página de red de Solana.

¿Por qué recibo errores 429 de mi endpoint RPC de Solana?

Un 429 significa que alcanzaste un límite de velocidad, lo cual es común en endpoints compartidos o públicos. Un plan gestionado con clave o un nodo dedicado elimina ese techo compartido.

¿Debo usar HTTP o WebSocket para Solana?

Usa HTTP para llamadas de solicitud-respuesta y WebSocket para actualizaciones push como cambios de cuenta o slot. La mayoría de las aplicaciones en producción usan ambos.

¿Puedo usar un endpoint RPC de Solana público en producción?

Puedes, pero los endpoints públicos son compartidos y a menudo tienen límites de velocidad. Para tráfico de producción constante, un endpoint gestionado o dedicado te da un comportamiento más predecible y una ruta de actualización clara.

¿Cómo puedo probar sin gastar SOL?

Usa un endpoint devnet y solicita SOL de devnet desde el faucet. Mantén la configuración de devnet separada de mainnet para que las claves nunca se crucen.