Nodos RPC de Solana: Endpoints, Métodos y Ajuste de Carga de Trabajo

Solana no se parece a una cadena EVM desde el punto de vista de RPC. No hay eth_getLogs, no hay un modelo de recibos bloque por bloque y no hay mempool que puedas consultar para transacciones pendientes. En su lugar, lees el estado de las cuentas, envías transacciones firmadas y te suscribes a actualizaciones de slot o de cuenta. Entender esa forma es la manera más rápida de elegir la configuración correcta de nodo RPC.

Qué configuración de RPC de Solana se ajusta a tu carga de trabajo

Antes de comparar proveedores, haz coincidir tu carga de trabajo con el tipo de endpoint que realmente necesita. La mayoría de los equipos aprovisionan en exceso al principio y en defecto después, así que usa esta tabla como filtro inicial.

Si tu aplicación solo lee saldos y ocasionalmente envía una transacción, un endpoint compartido suele ser suficiente. Si envías transacciones en ráfagas, ejecutas getProgramAccounts contra un programa grande o necesitas un margen predecible de unidades de cómputo, un nodo dedicado de Solana te da capacidad que no se comparte con otros inquilinos.

OnFinality proporciona tanto acceso compartido a la API RPC de Solana como infraestructura de nodo dedicado, para que puedas comenzar en un endpoint compartido y pasar a un nodo dedicado sin cambiar el código de tu cliente. Consulta la página de red Solana para detalles actuales del endpoint y Precios de RPC para formas de planes.

La forma del endpoint: HTTP y WebSocket

Un nodo RPC de Solana expone una interfaz JSON-RPC 2.0 sobre HTTP para llamadas de solicitud/respuesta, y una URL WebSocket separada para suscripciones. Las dos no son intercambiables: accountSubscribe, slotSubscribe y logsSubscribe solo funcionan sobre WebSocket.

Un endpoint público de Solana de OnFinality sigue este patrón:

# HTTP JSON-RPC
https://solana.api.onfinality.io/public

# WebSocket subscriptions
wss://solana.api.onfinality.io/public-ws

Una llamada curl mínima para confirmar que el endpoint está activo y devuelve el clúster esperado:

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

Un nodo mainnet saludable devuelve {"jsonrpc":"2.0","result":"ok","id":1}. Si obtienes un desajuste de clúster o un error de estilo -32005, es probable que estés apuntando a la red incorrecta o alcanzando un límite de tasa.

Para uso del lado del cliente, el objeto de conexión @solana/web3.js toma ambas URLs:

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

const connection = new Connection(
  "https://solana.api.onfinality.io/public",
  { wsEndpoint: "wss://solana.api.onfinality.io/public-ws" }
);

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

Mantén las URLs HTTP y WebSocket del mismo proveedor y el mismo clúster. Mezclar un endpoint HTTP de mainnet con un WebSocket de devnet es una fuente común de fallos de suscripción confusos.

Métodos que determinan los requisitos de tu nodo

No todos los métodos JSON-RPC cuestan lo mismo. Algunos métodos de Solana dominan la carga del nodo y son los que vale la pena probar antes de comprometerte con un proveedor.

Si tu aplicación depende de getProgramAccounts o de un historial profundo de firmas, confirma que el proveedor admite esas llamadas con límites razonables y, cuando sea necesario, datos de archivo. Algunos endpoints compartidos restringen o limitan estos métodos porque un solo llamador puede consumir una gran parte de los recursos del nodo.

Conectar una billetera o cliente a Solana

Para una billetera o un frontend, normalmente registras la red una vez y dejas que el usuario cambie. Una entrada típica de red Solana se ve así:

{
  "chainName": "Solana Mainnet",
  "rpcUrls": ["https://solana.api.onfinality.io/public"],
  "nativeCurrency": { "name": "SOL", "symbol": "SOL", "decimals": 9 },
  "blockExplorerUrls": ["https://explorer.solana.com"]
}

Si estás construyendo o probando antes de mainnet, apunta a un endpoint devnet en su lugar y mantén las dos configuraciones separadas. La página de Solana Devnet cubre la configuración del lado de testnet.

Dos notas prácticas:

• Las transacciones de Solana expiran rápidamente. Obtén un blockhash fresco cerca del momento de envío en lugar de almacenar uno en caché.
• Las tarifas prioritarias importan bajo carga. Lee las tarifas de priorización recientes y establece una tarifa que refleje las condiciones actuales de la red en lugar de un valor fijo.

Depurar fallos comunes de RPC de Solana

La mayoría de los problemas de RPC de Solana se reducen a un pequeño conjunto de síntomas. Haz coincidir el síntoma con la causa probable antes de cambiar de proveedor.

Una sonda de monitoreo simple te ayuda a detectar problemas de endpoint antes que los usuarios:

while true; do
  curl -s https://solana.api.onfinality.io/public \
    -X POST -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","id":1,"method":"getSlot"}' \
    | head -c 200
  echo
done

Ejecuta esto contra cada endpoint en tu lista de failover y registra el tiempo de respuesta. Si un endpoint se desvía, puedes desplazar el tráfico antes de que se convierta en una interrupción.

¿Endpoint compartido o nodo dedicado?

La decisión generalmente se reduce a tres preguntas: cuán en ráfagas es tu tráfico, cuán pesados son tus métodos y cuánto control necesitas sobre el nodo mismo.

• RPC compartido se ajusta a aplicaciones con muchas lecturas, billeteras y productos en etapa temprana. Obtienes un endpoint gestionado sin ejecutar infraestructura, y pagas por acceso en lugar de por una máquina.
• Nodo dedicado se ajusta a sistemas de trading, indexadores y aplicaciones que llaman a métodos costosos o necesitan un margen de cómputo consistente. Obtienes un nodo que no se comparte con otros inquilinos, lo que hace que el rendimiento sea más predecible.

Un patrón común es ejecutar RPC compartido para lecturas generales y un nodo dedicado para la ruta sensible a la latencia, y luego hacer failover entre ellos. OnFinality admite ambos modelos, y puedes revisar las ventajas y desventajas en Cómo elegir un proveedor de RPC y la opción de nodo dedicado.

Lista de verificación para evaluar proveedores de Solana

Cuando compares proveedores de RPC de Solana, prueba contra tu carga de trabajo real en lugar de un benchmark genérico.

1. Cobertura de métodos — Confirma que getProgramAccounts, getSignaturesForAddress y las suscripciones WebSocket funcionan con tus filtros.
2. Límites de cómputo y tasa — Pregunta cómo se aplican los límites y si escalan con tu plan.
3. Profundidad de archivo — Si consultas transacciones o firmas antiguas, verifica que los datos históricos estén disponibles.
4. Estabilidad de WebSocket — Prueba suscripciones de larga duración, no solo un único mensaje.
5. Failover — Verifica si puedes ejecutar múltiples endpoints y cambiar entre ellos.
6. Observabilidad — Busca métricas de solicitudes, tasas de error e información de estado sobre la que puedas actuar.
7. Ruta de soporte — Conoce cómo contactar al proveedor cuando se rompe una ruta de transacción.

Puedes revisar las redes disponibles en la página de redes RPC compatibles y comparar formas de planes en Precios de RPC.

Puntos clave

• Los nodos RPC de Solana exponen JSON-RPC sobre HTTP más una URL WebSocket separada para suscripciones.
• getProgramAccounts, getSignaturesForAddress y sendTransaction son los métodos que más afectan los requisitos del nodo.
• Los endpoints compartidos se ajustan a aplicaciones con muchas lecturas; los nodos dedicados se ajustan a cargas de trabajo en ráfagas, sensibles a la latencia o con mucho cómputo.
• La mayoría de los fallos se remontan a blockhashes obsoletos, límites de tasa, caídas de WebSocket o desajustes de clúster.
• Prueba a los proveedores contra tu patrón de llamadas real, incluida la estabilidad de WebSocket y la profundidad de archivo.

Preguntas frecuentes

¿Necesito un nodo dedicado de Solana? No siempre. Si tu aplicación lee saldos y envía transacciones ocasionales, un endpoint compartido suele ser suficiente. Pasa a un nodo dedicado cuando necesites un margen de cómputo predecible, soporte para métodos pesados o menor latencia para el envío de transacciones.

¿Cuál es la diferencia entre los endpoints HTTP y WebSocket de Solana? HTTP maneja llamadas de solicitud/respuesta como getBalance y sendTransaction. WebSocket maneja suscripciones como accountSubscribe y slotSubscribe. Necesitas ambas URLs si tu aplicación usa suscripciones.

¿Por qué falla o no devuelve nada getProgramAccounts? Es un método pesado que a menudo necesita filtros, y algunos endpoints compartidos lo restringen. Verifica tus filtros de tamaño de datos y el discriminador de cuenta, y confirma que el proveedor admite la llamada con el volumen que esperas.

¿Cómo manejo los fallos de transacciones de Solana? Obtén un blockhash fresco cerca del envío, establece una tarifa prioritaria basada en las condiciones recientes de la red e implementa reintentos. La mayoría de los errores Blockhash not found provienen de blockhashes obsoletos.

¿Puedo usar el mismo endpoint para mainnet y devnet? No. Mainnet y devnet son clústeres separados con endpoints separados. Mantén las dos configuraciones distintas y asegúrate de que tus URLs HTTP y WebSocket apunten al mismo clúster.