Resumen
Solana expone una interfaz JSON-RPC con un amplio conjunto de métodos para leer cuentas, enviar transacciones y suscribirse a actualizaciones en vivo. Los métodos que habilites dependen de tu carga de trabajo: las wallets necesitan blockhash y sendTransaction, los indexadores necesitan getProgramAccounts y getSignaturesForAddress, y los sistemas de trading se apoyan en suscripciones WebSocket y estimación de priority fees. Esta referencia asigna los métodos RPC comunes de Solana a casos de uso reales, muestra ejemplos de solicitudes y explica los límites que dan forma a la arquitectura de producción. También cubre cómo elegir un endpoint, cuándo un RPC público compartido es suficiente y cuándo un nodo dedicado de Solana de OnFinality tiene más sentido para tráfico sostenido o de alto volumen.
La API JSON-RPC de Solana es la forma principal en que las aplicaciones leen el estado y envían transacciones. A diferencia de las cadenas EVM, donde un pequeño conjunto de métodos cubre la mayoría de los casos de uso, Solana expone una superficie más amplia: consultas de cuentas, búsquedas derivadas de programas, recuperación de blockhash, simulación de transacciones y suscripciones WebSocket. El método que llamas, y con qué frecuencia lo llamas, determina si un endpoint compartido es suficiente o si necesitas infraestructura dedicada.
Empieza aquí: asigna tu carga de trabajo a un conjunto de métodos
Antes de optimizar cualquier cosa, identifica en qué categoría se encuentra tu aplicación. La siguiente tabla asigna cargas de trabajo comunes de Solana a los métodos de los que dependen y a las características del endpoint que más importan.
| Carga de trabajo | Métodos principales | Características del endpoint a priorizar |
|---|---|---|
| Wallet o frontend de dapp | getLatestBlockhash, getBalance, sendTransaction, getSignatureStatuses | HTTP de baja latencia, reenvío confiable de transacciones |
| Indexador o analítica | getProgramAccounts, getSignaturesForAddress, getTransaction | Alto rendimiento de solicitudes, profundidad de archivo, paginación estable |
| Trading o bot | onAccountChange, onLogs, getRecentPrioritizationFees, sendTransaction | Estabilidad de WebSocket, baja latencia, capacidad de ráfaga |
| Herramientas de NFT o tokens | getTokenAccountsByOwner, getAccountInfo, getProgramAccounts | Tiempos de respuesta consistentes, soporte de filtrado |
Si tu carga de trabajo es mayormente de lectura con escrituras ocasionales, un endpoint RPC compartido como el endpoint público de Solana de OnFinality puede cubrir el desarrollo temprano. Si ejecutas suscripciones sostenidas, escaneos grandes de getProgramAccounts o alto volumen de transacciones, un nodo dedicado elimina los efectos de vecinos ruidosos y te da capacidad predecible. Puedes revisar Precios de RPC y redes RPC compatibles para comparar opciones.
Leer cuentas y saldos
Los métodos RPC de Solana más comunes recuperan el estado de las cuentas. Estas son llamadas HTTP POST con un cuerpo JSON.
curl https://solana.api.onfinality.io/public \
-X POST -H "Content-Type: application/json" \
-d '{
"jsonrpc": "2.0",
"id": 1,
"method": "getBalance",
"params": ["<PUBKEY>"]
}'
Métodos clave en este grupo:
- getBalance devuelve el saldo en lamports de una clave pública.
- getAccountInfo devuelve los datos de la cuenta, el propietario, los lamports y el indicador de ejecutable.
- getTokenAccountsByOwner lista las cuentas de tokens SPL de una wallet, con filtrado opcional por mint.
- getProgramAccounts devuelve todas las cuentas propiedad de un programa. Es potente pero costoso; usa siempre filtros (dataSize, memcmp) para acotar los resultados.
getProgramAccounts es el método con más probabilidades de alcanzar los límites del proveedor. Sin filtros, puede escanear millones de cuentas. Si dependes mucho de él, confirma que tu proveedor lo soporte a la escala que necesitas y considera un nodo dedicado donde controles la configuración.
Enviar y rastrear transacciones
Escribir en Solana implica una secuencia específica: obtener un blockhash reciente, construir y firmar la transacción, enviarla y luego confirmarla.
// Flujo mínimo de envío usando fetch contra un endpoint RPC de Solana
const endpoint = "https://solana.api.onfinality.io/public";
async function rpc(method, params) {
const res = await fetch(endpoint, {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({ jsonrpc: "2.0", id: 1, method, params }),
});
return res.json();
}
const { result } = await rpc("getLatestBlockhash", [{ commitment: "confirmed" }]);
// construye y firma la transacción usando result.value.blockhash
// luego:
// await rpc("sendTransaction", [signedTxBase64, { encoding: "base64" }]);
Métodos que debes conocer:
- getLatestBlockhash devuelve un blockhash y su ventana de validez. Los blockhashes expiran, así que obtén nuevos cerca del momento de envío.
- sendTransaction envía una transacción firmada. Configura
skipPreflightcon cuidado; el preflight detecta muchos errores pero añade latencia. - simulateTransaction ejecuta una transacción sin confirmarla, útil para estimar unidades de cómputo y detectar fallos.
- getSignatureStatuses y getTransaction te permiten confirmar si una transacción se procesó.
- getRecentPrioritizationFees te ayuda a establecer una priority fee competitiva durante la congestión.
Un error común es almacenar en caché un blockhash demasiado tiempo. Si el blockhash expira antes de que la transacción se procese, la red la rechaza. Obtén un nuevo blockhash para cada intento y reintenta con retroceso exponencial.
Suscripciones WebSocket y sus límites
Solana admite suscripciones WebSocket para actualizaciones en tiempo real. El endpoint de Solana de OnFinality expone un transporte WebSocket en wss://solana.api.onfinality.io/public-ws.
Métodos de suscripción comunes:
- accountSubscribe observa una sola cuenta en busca de cambios.
- logsSubscribe transmite logs de un programa o cuenta.
- signatureSubscribe notifica cuando se confirma una transacción específica.
- slotSubscribe y rootSubscribe rastrean la progresión de slots.
const ws = new WebSocket("wss://solana.api.onfinality.io/public-ws");
ws.onopen = () => {
ws.send(JSON.stringify({
jsonrpc: "2.0",
id: 1,
method: "logsSubscribe",
params: [{ mentions: ["<PROGRAM_ID>"] }, { commitment: "confirmed" }],
}));
};
ws.onmessage = (event) => {
const msg = JSON.parse(event.data);
// manejar notificación de log
};
Las conexiones WebSocket son con estado y pueden caerse. Los clientes de producción deben implementar lógica de reconexión, volver a suscribirse al reconectar y tratar el flujo como eventualmente consistente. Si mantienes muchas suscripciones concurrentes, los límites de conexión y los tiempos de espera por inactividad del lado del servidor se vuelven relevantes; aquí es donde ayudan los nodos dedicados, porque no compartes la capacidad de suscripción con otros inquilinos.
Lista de verificación para producción
Usa esta lista antes de mover una integración de Solana a producción.
| Verificación | Por qué importa |
|---|---|
| Frescura del blockhash | Los blockhashes expirados causan envíos fallidos |
| Nivel de commitment | processed es rápido pero puede revertirse; confirmed y finalized cambian velocidad por seguridad |
| Estrategia de reintentos | La congestión de la red y las transacciones descartadas requieren reintentos idempotentes |
| Filtros de getProgramAccounts | Los escaneos sin filtro son lentos y pueden tener límite de tasa |
| Reconexión de WebSocket | Las suscripciones caídas detienen las actualizaciones silenciosamente |
| Endpoint de failover | Un solo endpoint es un único punto de fallo |
| Lógica de priority fee | Las tarifas estáticas rinden mal durante la congestión |
Si varias de estas son difíciles de gestionar en un endpoint compartido, esa es la señal para evaluar un nodo dedicado de Solana. OnFinality proporciona acceso a la API RPC e infraestructura de nodos dedicados en redes compatibles, incluida Solana, para que puedas escalar la capacidad sin operar validadores tú mismo.
Niveles de commitment y por qué cambian los resultados
Cada método de lectura acepta un parámetro de commitment. Los tres que más usarás:
- processed refleja el slot más reciente pero puede revertirse.
- confirmed es votado por una supermayoría y es la opción habitual para saldos visibles al usuario.
- finalized es irreversible y el mejor para lógica de liquidación.
Mezclar niveles de commitment entre llamadas causa errores confusos, como un saldo que aparece y luego desaparece. Elige un nivel por característica y aplícalo de forma consistente. Para la confirmación de transacciones, confirmed es un valor predeterminado razonable; para liquidación financiera, usa finalized.
Depurar fallos comunes de Solana RPC
| Síntoma | Causa probable | Siguiente paso |
|---|---|---|
| Transacción no confirmada | Blockhash expirado o priority fee baja | Vuelve a obtener el blockhash, sube la priority fee, reenvía |
getProgramAccounts agota el tiempo | Faltan filtros o resultado demasiado grande | Añade filtros dataSize/memcmp, pagina |
| WebSocket deja de actualizar | Conexión caída | Reconecta y vuelve a suscribirte |
| Saldos inconsistentes | Niveles de commitment mezclados | Estandariza el commitment por característica |
| Respuestas 429 | Tasa de solicitudes excedida | Agrupa solicitudes, cachea lecturas o pasa a capacidad dedicada |
Cuando veas 429s o picos de latencia, captura el nombre del método y el tamaño del payload. Las llamadas grandes a getProgramAccounts y las suscripciones de logs sin filtro son los culpables habituales. Reducir el tamaño del payload a menudo resuelve el problema sin cambiar de proveedor.
Elegir entre RPC de Solana compartido y dedicado
Los endpoints compartidos son rentables para desarrollo, dapps de bajo tráfico y paneles con mucha lectura. Los nodos dedicados tienen sentido cuando necesitas rendimiento consistente, gran cantidad de suscripciones, escaneos grandes de cuentas o aislamiento del tráfico de otros inquilinos. OnFinality ofrece ambos modelos, para que puedas empezar en un endpoint compartido y pasar a un nodo dedicado a medida que crece el uso. Revisa Precios de RPC para las opciones actuales y cómo elegir un proveedor de RPC para criterios de evaluación.
Puntos clave
- Los métodos RPC de Solana se dividen en lecturas (getAccountInfo, getBalance, getProgramAccounts), escrituras (sendTransaction) y suscripciones (logsSubscribe, accountSubscribe).
- Obtén siempre un blockhash nuevo antes de enviar; los blockhashes expirados son una causa principal de transacciones fallidas.
- Usa los niveles de commitment de forma consistente; mezclarlos crea inconsistencias difíciles de depurar.
- Filtra getProgramAccounts de forma agresiva para evitar tiempos de espera y límites de tasa.
- Los clientes WebSocket deben manejar reconexiones y resuscripción.
- Los endpoints compartidos sirven para aplicaciones de bajo tráfico; los nodos dedicados sirven para cargas sostenidas, de alto volumen o con muchas suscripciones.
Preguntas frecuentes
¿Cuál es el método RPC de Solana más usado? Para wallets y dapps, getLatestBlockhash, getBalance y sendTransaction son los más comunes. Los indexadores dependen más de getProgramAccounts y getSignaturesForAddress.
¿OnFinality admite suscripciones WebSocket de Solana? Sí. El endpoint de Solana expone transportes HTTP y WebSocket. Consulta la página de la red Solana para más detalles.
¿Por qué falla o agota el tiempo getProgramAccounts? Normalmente porque la consulta carece de filtros y devuelve demasiados datos. Añade filtros dataSize o memcmp y pagina los resultados.
¿Debo usar un endpoint RPC de Solana público o dedicado? Empieza con uno público para desarrollo y bajo tráfico. Pasa a un nodo dedicado cuando necesites rendimiento predecible, muchas suscripciones o aislamiento del tráfico compartido.
¿Cómo configuro las priority fees? Llama a getRecentPrioritizationFees y luego establece una tarifa que refleje la congestión actual. Las tarifas estáticas a menudo rinden mal en periodos de mucha actividad.