Proveedores de RPC

Elija entre proveedores de RPC administrados (Helius, Triton, QuickNode) y validadores Agave autoalojados en función del tráfico, las características y el costo operativo.

Receta

Tarjeta de receta de referencia rápida, lista para copiar y pegar.

import { createSolanaRpc } from "@solana/kit";
 
// Proveedor (clave API en la URL o encabezado por proveedor)
const rpc = createSolanaRpc(
  "https://mainnet.helius-rpc.com/?api-key=YOUR_KEY"
);
 
await rpc.getSlot().send();

# Autoalojado (operador)
agave-validator --ledger /data/ledger --rpc-port 8899

Cuándo usar esto:

• Aplicaciones Mainnet o devnet que superan los límites de tasa de RPC públicos.
• Necesidad de APIs DAS, webhooks o estimación de tarifas de prioridad.
• Ejecución de indexadores que requieren stake y ancho de banda dedicados.
• Requisitos de cumplimiento para la entrada de RPC privada.

Ejemplo de trabajo

import { createSolanaRpc, createSolanaRpcSubscriptions } from "@solana/kit";
 
const HTTP = process.env.RPC_HTTP_URL!;
const WSS = process.env.RPC_WSS_URL!;
 
const rpc = createSolanaRpc(HTTP);
const rpcSubscriptions = createSolanaRpcSubscriptions(WSS);
 
const slot = await rpc.getSlot().send();
console.log("slot:", slot);
 
// Script de verificación de estado para CI
if (slot < 1) throw new Error("RPC no está en buen estado");

Lo que esto demuestra:

• URLs HTTP y WSS separadas del panel del proveedor.
• Las variables de entorno mantienen las claves API fuera del control de código fuente.
• Una simple sonda getSlot valida el estado del punto final.

Análisis en profundidad

Cómo funciona

• Los proveedores administrados ejecutan validadores Agave además de balanceadores de carga, caché y sidecars de indexación.
• Las claves API autentican y miden las solicitudes por nivel de plan.
• El autoalojamiento ejecuta agave-validator con su propio stake, operaciones y failover.
• La matriz de características (DAS, gRPC, webhooks) varía según el proveedor; no es una RPC genérica.

Comparación de proveedores (alto nivel)

Notas de TypeScript

// Failover: intentar URL secundaria en 429/503
async function rpcWithFallback<T>(fn: (rpc: ReturnType<typeof createSolanaRpc>) => Promise<T>) {
  const primary = createSolanaRpc(process.env.RPC_PRIMARY!);
  try {
    return await fn(primary);
  } catch (e) {
    const secondary = createSolanaRpc(process.env.RPC_SECONDARY!);
    return await fn(secondary);
  }
}

Errores comunes

• Incrustar claves API en el frontend: las claves se extraen de los navegadores. Solución: proxy de lecturas a través de su backend para claves confidenciales.
• Dependencia de un solo proveedor: una interrupción detiene su aplicación. Solución: failover de URL secundaria y lecturas críticas en caché.
• Usar el nivel gratuito para acuñación de producción: 429 durante picos. Solución: plan de pago dimensionado para RPS pico.
• Hosts HTTP/WSS no coincidentes: las suscripciones fallan silenciosamente. Solución: copie los puntos finales emparejados del panel.
• Autoalojamiento sin monitoreo: el disco lleno en el ledger detiene la RPC. Solución: alertas de ledger y nodos redundantes.

Alternativas

Preguntas frecuentes

Relacionado

• Fundamentos de RPC - Fundamentos de JSON-RPC
• Suscripciones WebSocket - Puntos finales WSS
• La API DAS - Características DAS del proveedor
• Mejores prácticas de RPC - Patrones de cliente resilientes

Versiones de la pila: Esta página se escribió para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, anchor-lang 0.32.1, Rust 1.91.1, @solana/kit 7.0.0, Surfpool 0.12.0 y LiteSVM 0.6.x.