RPC y WebSockets en Profundidad
Los clientes de Solana nunca hablan con el ledger como una base de datos cruda; hablan con nodos RPC que exponen JSON-RPC sobre HTTP y actualizaciones en tiempo real sobre WebSockets.
Los saldos de las billeteras, las búsquedas de cuentas de programas, los envíos de transacciones, las esperas de firmas y (en muchos proveedores) las galerías de activos digitales viajan por esa capa de acceso.
Esta página es el paraguas de la sección: HTTP vs suscripciones, métodos baratos vs caros, RPC central vs DAS, y cómo los proveedores, la paginación y las API de tarifas/simulación completan una pila de producción.
Resumen
- RPC de Solana es la superficie de la API orientada al clúster: los clientes usan HTTP JSON-RPC para lecturas y envío de transacciones, suscripciones de WebSocket para actualizaciones push y (en proveedores con DAS habilitado) métodos centrados en activos superpuestos a datos de cadena indexados.
- Por Qué Importa: Las elecciones incorrectas de transporte, método o compromiso crean límites de tasa, UI obsoleta, estados de éxito falsos y tiempos de espera de mainnet; un mapa compartido de HTTP vs WS, métodos baratos vs caros, y RPC central vs DAS evita tratar cada llamada como gratuita e intercambiable.
- Conceptos Clave: JSON-RPC, compromiso (commitment), HTTP RPC, suscripción WebSocket, getAccountInfo, getMultipleAccounts, getProgramAccounts (GPA), filtros, DAS, proveedor, paginación, simulateTransaction, tarifa de prioridad (priority fee).
- Cuándo Usar: Primera orientación antes de cablear clientes de
@solana/kit; elegir sondeo (poll) vs suscripción; planificar lecturas de cartera de NFTs y GPA de mainnet; seleccionar características del proveedor y rutas de estimación de tarifas. - Limitaciones / Compensaciones: RPC público tiene límites de tasa estrictos y sin SLA; DAS y las API de tarifas mejoradas son características del proveedor, no garantizadas en cada URL; las suscripciones de WebSocket son vistas locales del nodo y aún necesitan disciplina de compromiso; GPA no reemplaza a un indexador real a escala.
- Temas Relacionados: Fundamentos de RPC y compromiso, métodos de lectura principales, filtros de GPA, paginación, proveedores y API de tarifas de prioridad/simulación.
Fundamentos
RPC (Remote Procedure Call) es cómo las aplicaciones observan y envían trabajo en un clúster de Solana.
Un nodo RPC ejecuta (o actúa como front-end para) software de validador como Agave, sirve JSON-RPC 2.0 sobre HTTPS y típicamente expone un punto final WebSocket complementario para suscripciones.
Los clientes no necesitan ejecutar un validador; necesitan una URL RPC correcta para el clúster al que se dirigen (mainnet-beta, devnet, testnet o localnet).
Las solicitudes son objetos JSON-RPC: nombres de method como getBalance o sendTransaction, params opcionales y un id que se repite en la respuesta.
Las respuestas llevan un result o un error con un código y un mensaje; el código de la aplicación debe tratar los errores HTTP 429, los tiempos de espera y los errores JSON-RPC como modos de fallo de primera clase.
El compromiso (commitment) (processed, confirmed, finalized) es ortogonal a la elección del método: le dice al nodo cuán profundo en el consenso debe estar una lectura o notificación antes de responder.
Leer en processed es rápido y sensible a bifurcaciones (forks); leer en finalized es más lento y más seguro para decisiones de producto irreversibles.
La ruta HTTP es de solicitud/respuesta: obtén esta cuenta, envía esta transacción, simula esta carga útil, devuelve una vez.
La ruta WebSocket es de larga duración: suscríbete una vez, recibe notificaciones push cuando una cuenta cambie, una firma alcance el compromiso, o aparezcan registros coincidentes.
HTTP y WebSocket son dos caras del mismo producto RPC, no dos ledgers; aún eliges un clúster y una política de compromiso.
Los métodos de lectura principales (core read methods) hidratan el estado de la aplicación a partir de cuentas que el tiempo de ejecución ya conoce por clave pública (pubkey): saldos, datos de cuenta única y cargas de cuentas múltiples en lotes.
getProgramAccounts hace una pregunta más difícil: devuelve cada cuenta propiedad de un programa (opcionalmente filtrada), lo que obliga a un escaneo del estado propiedad del programa y es la fuente clásica de tiempos de espera de mainnet y límites de tasa.
DAS (Digital Asset Standard) Las API extienden JSON-RPC con métodos centrados en activos (getAsset, getAssetsByOwner, consultas de búsqueda/agrupación) respaldados por indexadores de proveedores que unen programas de tokens, metadatos y árboles de compresión en un solo modelo.
DAS no es una función integrada de Agave en cada URL pública; es una capacidad del proveedor que habilitas cuando la experiencia de usuario de activos digitales (NFT, cNFT) y carteras sería dolorosa solo con recorridos de tokens crudos.
Los proveedores (RPC administrado, DAS, webhooks, gRPC) y los validadores auto-alojados intercambian la carga operativa por control; las aplicaciones de producción dejan atrás los puntos finales públicos gratuitos.
La paginación y la eficiencia te mantienen dentro de los límites de RPS y carga útil: agrupa claves públicas conocidas, historial de firmas de cursor, filtra GPA de manera estricta y traslada el descubrimiento a los indexadores cuando los conjuntos crecen.
Las API de simulación y tarifas de prioridad se encuentran en la ruta de escritura: estiman unidades de cómputo y micro-lamports por CU, y usan simulateTransaction para mostrar errores del programa sin gastar tarifas de mainnet en cada ejecución en seco.
Juntos, estas piezas forman un mapa:
Cliente (@solana/kit, billetera, trabajador de backend)
|
+-- HTTPS JSON-RPC --------> Borde RPC / proveedor
| lecturas, envío, simulación, tarifas
|
+-- Suscripciones WSS -----> misma superficie del clúster
| cuenta / registros / firma / slot
|
+-- Métodos DAS (opcional) -> Proveedor con DAS habilitado
getAsset, getAssetsByOwner, searchAssets
Las páginas hermanas de esta sección profundizan en cada rama; esta página mantiene todo el diagrama a la vista.
Mecánicas e Interacciones
Ciclo de vida de la solicitud HTTP
Una lectura típica es un POST con Content-Type: application/json.
El nodo resuelve el método contra la instantánea de su banco en el compromiso solicitado, codifica los datos de la cuenta (base64, base58 o jsonParsed donde sea compatible) y responde.
sendTransaction acepta una transacción serializada y firmada y devuelve un identificador de firma; la durabilidad aún requiere sondeo o una suscripción WebSocket hasta que se alcance el compromiso elegido.
La aplicación construye + firma la tx
|
v
HTTP sendTransaction --> firma S
|
+-- sondea getSignatureStatuses(S), o
+-- suscríbete a la firma signatureSubscribe(S) sobre WSS
|
v
escalera de compromiso: processed -> confirmed -> finalized
Suscripciones WebSocket
El cliente abre wss://..., envía un método *Subscribe y recibe un ID de suscripción más tarde mensajes *Notification.
Suscripciones comunes:
| Suscripción | Se activa cuando |
|---|---|
accountSubscribe | Cambian los lamports o los datos de la cuenta |
logsSubscribe | Las transacciones coinciden con un filtro (ej. menciones) |
signatureSubscribe | La transacción alcanza el compromiso de la suscripción |
slotSubscribe | Avanzan nuevos slots |
Las notificaciones son vistas push desde el nodo al que te conectaste, no un bus global ordenado entre todos los proveedores.
Anula la suscripción (o aborta la suscripción del kit) cuando los componentes se desmonten para que las conexiones no se filtren.
Lecturas baratas vs descubrimiento caro
| Patrón | Métodos | Postura de costo |
|---|---|---|
| Clave pública conocida | getBalance, getAccountInfo, getMultipleAccounts | Bajo a medio; lotes múltiples |
| Escaneo de programa | getProgramAccounts | Alto sin filtros; puede agotar el tiempo de espera |
| Historial | getSignaturesForAddress, getTransaction | Medio a alto; paginar y almacenar en caché |
| Activos | DAS getAsset / getAssetsByOwner | Indexado por proveedor; dependiente del plan |
| UI en vivo | Suscripciones WebSocket | Carga de conexión + notificación |
Siempre prefiere lecturas de clave pública conocida cuando un indexador, la derivación de PDA o una respuesta anterior ya te proporcionaron las direcciones.
Usa GPA con filtros dataSize y memcmp solo cuando necesites descubrir cuentas por diseño; nunca uses GPA sin filtrar por defecto en mainnet para programas grandes.
Cuando GPA aún no puede satisfacer la escala del producto, traslada el descubrimiento a pipelines tipo Geyser/Yellowstone o a un indexador dedicado en lugar de reintentar el mismo escaneo.
DAS en relación con RPC central
RPC central responde "¿cuál es la cuenta en esta dirección?"
DAS responde "¿qué activos digitales posee este propietario, y qué metadatos/prueba de compresión necesito para renderizarlos o verificarlos?"
Usa RPC central (y kit) para cuentas de programas personalizadas, pagadores de tarifas y envío de transacciones.
Usa DAS para galerías de NFTs, consultas de colecciones y activos comprimidos donde el proveedor ya ha pagado el costo de indexación.
Proveedores, límites y eficiencia
Los proveedores administrados actúan como front-end para Agave (o equivalente) con balanceadores de carga, claves de API y sidecars opcionales (DAS, webhooks, estimaciones de tarifas mejoradas).
Las URL de clúster públicas existen para aprendizaje y trabajo ligero en devnet; limitan agresivamente y no son un plan de producción.
Las reglas de eficiencia que se aplican en todas partes:
- Divide
getMultipleAccountsen lotes (a menudo ~50-100 claves por llamada, sujeto a la documentación del proveedor). - Paginación de
getSignaturesForAddresscon cursoresbefore/untily unlimit. - Almacena en caché los datos de cuenta inmutables o que cambian lentamente; actualiza en la suscripción o después de tus propias escrituras.
- Retrocede ante 429; cambia a una URL secundaria cuando los SLA lo permitan.
Simulación y tarifas de prioridad
Antes de confirmar transacciones sensibles, los clientes a menudo:
simulateTransactioncon opciones comosigVerify: falseyreplaceRecentBlockhashpara leerunitsConsumed, registros y errores.- Muestrea
getRecentPrioritizationFees(y/o API de tarifas de percentil del proveedor) para las cuentas involucradas en el conjunto de bloqueo. - Adjunta instrucciones de presupuesto de cómputo con margen por encima de las CU simuladas y un precio de CU en micro-lamports.
La simulación no es un sustituto de la confirmación en mainnet; reduce los fallos evitables y la inclusión infravalorada.
Consideraciones Avanzadas y Aplicaciones
Mapa conceptual de la sección (qué posee cada página hermana)
| Preocupación | Página principal | Conclusión para el desarrollador |
|---|---|---|
| Forma de JSON-RPC, compromiso, límites de tasa | Fundamentos de RPC | Establece el compromiso explícitamente; trata 429 como normal |
| Saldo, información de cuenta, multi-get, descripción general de GPA | Métodos RPC Centrales | Prefiere multi-get a lecturas únicas y ruidosas |
memcmp / dataSize, discriminadores de Anchor | getProgramAccounts y Filtros | Filtra en el lado del servidor o no escanees |
| Cursores, lotes, evitar escaneos pesados | Paginación y Eficiencia | GPA no está paginado; diseña el descubrimiento sin conexión |
| Muestras de tarifas, opciones de simulación, margen de CU | API de Tarifas de Prioridad y Simulación | Estima y luego envía; registra las elecciones de CU y tarifas |
| Proveedores administrados vs auto-alojados, matrices de características | Proveedores RPC | Haz coincidir las necesidades de DAS/gRPC con el proveedor; mantén las claves fuera del código fuente |
Las suscripciones WebSocket y DAS tienen páginas dedicadas de cómo hacerlo en esta sección; operativamente, todavía dependen de la misma URL de proveedor y política de compromiso descritas anteriormente.
Diseño de una pila de cliente
Separa la configuración de HTTP RPC, WSS y DAS incluso cuando un solo proveedor emite los tres.
Fija el compromiso por clase de acción en un módulo en lugar de dispersar literales de cadena.
Para productos con muchas escrituras, combina límites de CU impulsados por simulación con tarifas de prioridad dinámicas y una ruta de confirmación que no trate el éxito de sendTransaction como liquidación.
Cuándo abandonar RPC puro
| Necesidad | Permanecer en RPC / WS central | Abandonar para indexador / gRPC / webhooks |
|---|---|---|
| Saldo de billetera + pocos PDA | Sí | No |
| UI de cuenta única en vivo | WebSocket | Opcional |
| Análisis completo del programa | No | Sí |
| Gran cartera de NFTs + cNFTs | DAS si está disponible | Indexador personalizado si DAS es insuficiente |
| Flujos de cuentas múltiples de milisegundos | Limitado | Clase Yellowstone / Geyser |
Alineación de herramientas
@solana/kit 7.0.0 proporciona createSolanaRpc para HTTP y createSolanaRpcSubscriptions para WSS en métodos estándar.
DAS a menudo usa fetch directo o un SDK de proveedor hasta que lo envuelvas; mantén las URL base de DAS configurables junto a las URL RPC de kit.
La CLI (solana contra la misma URL RPC) es útil para depurar los mismos métodos que llama tu aplicación.
Conceptos erróneos comunes
- "Una firma de transacción de sendTransaction significa que la transferencia es final." La firma es un identificador para el sondeo de estado o
signatureSubscribe; la durabilidad es el nivel de compromiso que esperas después. - "HTTP y WebSocket son intercambiables para todos los casos de uso." HTTP se ajusta a lecturas y envíos de un solo disparo; WebSockets se ajustan a actualizaciones continuas, pero ambos aún necesitan disciplina de compromiso, autenticación y limpieza.
- "getProgramAccounts es solo otra lectura como getAccountInfo." GPA puede escanear grandes conjuntos propiedad de programas; sin filtros, a menudo es la llamada RPC más cara en tu aplicación.
- "Los métodos DAS funcionan en cualquier URL RPC de Solana." DAS requiere un punto final de proveedor habilitado para DAS; RPC público estándar generará un error u omitirá esos métodos.
- "Hacer sondeos cada 200 ms es equivalente a una suscripción." El sondeo agresivo agota los límites de tasa y aún se retrasa; las suscripciones reducen la charla pero no son eventos globales ordenados entre nodos.
- "Las tarifas de prioridad y la simulación garantizan la inclusión." Mejoran la predicción y reducen los fallos evitables; los líderes, la congestión y la expiración del bloquehash aún requieren lógica de reintento y confirmación.
Preguntas Frecuentes
¿Qué es Solana RPC en una oración?
Es la superficie de la API JSON-RPC (y WebSocket) a través de la cual los clientes leen cuentas, envían transacciones y observan el compromiso en un clúster elegido.
¿Cuándo debo usar HTTP vs WebSockets?
Usa HTTP para lecturas de solicitud/respuesta, envíos, simulación y muestras de tarifas; usa WebSockets cuando necesites actualizaciones push para cuentas, registros o confirmación de firmas sin bucles de sondeo ajustados.
¿Qué compromiso debería usar mi dapp por defecto?
Muchas acciones de producto usan confirmed para una UX receptiva; usa finalized antes de efectos externos irreversibles; trata processed como optimista solamente.
¿Por qué falla getProgramAccounts en mainnet?
Los escaneos sin filtrar o débilmente filtrados agotan el tiempo de espera o alcanzan los límites del proveedor; agrega filtros dataSize y memcmp o traslada el descubrimiento a un indexador.
¿Cómo se diferencia getMultipleAccounts de GPA?
getMultipleAccounts carga claves públicas conocidas en un lote; GPA descubre cuentas por propietario (y filtros) cuando aún no conoces las direcciones.
¿Es DAS parte del RPC del protocolo central de Solana?
DAS es una API estandarizada orientada a activos ofrecida por proveedores de indexación sobre datos de cadena; no está garantizada en todos los puntos finales públicos de Agave.
¿Puedo usar DAS para mis cuentas de programas personalizadas?
Generalmente no para diseños arbitrarios; DAS se enfoca en activos digitales (tokens, NFTs, cNFTs). El estado del programa personalizado todavía usa RPC central, filtros o tu propio indexador.
¿Las notificaciones de WebSocket sobreviven a las bifurcaciones (forks) como lo hacen las lecturas finalizadas?
No. Las notificaciones respetan el compromiso con el que te suscribiste; las actualizaciones de processed pueden revertirse en bifurcaciones, por lo que la UI debe permanecer reversible hasta un compromiso más profundo.
¿Cómo pagino los resultados de Solana RPC?
El historial de firmas usa cursores (before / until) y limit; multi-get se divide en lotes por lista de claves públicas; GPA no está paginado por desplazamiento, por lo que los filtros o los índices externos manejan el descubrimiento grande; DAS a menudo expone page / limit en las API del proveedor.
¿Cuáles son las opciones comunes de proveedores?
Las opciones administradas incluyen Helius, Triton y QuickNode para RPC alojado más DAS, gRPC o webhooks opcionales; el auto-alojamiento de Agave intercambia costo operativo por control; RPC público gratuito es para uso ligero no productivo.
¿Cómo encajan las API de simulación y tarifas de prioridad en la ruta de envío?
Simula para estimar unidades de cómputo y detectar errores del programa; muestrea tarifas de priorización recientes (o percentiles del proveedor) para establecer el precio de la CU; luego envía y espera la confirmación.
¿Reemplaza @solana/kit la comprensión de los métodos RPC?
No. Kit 7.0.0 tipifica y envuelve las mismas superficies de JSON-RPC y suscripción; aún eliges métodos, compromiso, filtros y proveedores correctamente.
¿Deberían las aplicaciones de producción compartir una única URL RPC pública global?
No. Usa puntos finales de proveedor autenticados (y a menudo URL HTTP/WSS/DAS separadas), limita la tasa en el lado del cliente y planifica la conmutación por error para rutas críticas.
¿Cuándo es obligatorio un indexador en lugar de solo RPC?
Cuando necesitas análisis históricos completos, descubrimiento a gran escala de programas o flujos de cuentas múltiples que exceden la capacidad de GPA filtrado y suscripción.
¿A dónde debo ir después de esta página?
Comienza con Fundamentos de RPC para el compromiso y la configuración del cliente, luego Métodos RPC Centrales para lecturas cotidianas; abre GPA, paginación, tarifas y proveedores a medida que surjan esos puntos débiles.
Relacionados
- Fundamentos de RPC - Forma de JSON-RPC, niveles de compromiso y límites de tasa
- Métodos RPC Centrales -
getAccountInfo,getBalance,getMultipleAccounts, descripción general de GPA - getProgramAccounts y Filtros -
memcmp,dataSize, y escaneos seguros de programas - Paginación y Eficiencia - lotes, cursores y evitar escaneos pesados
- API de Tarifas de Prioridad y Simulación - muestras de tarifas,
simulateTransaction, y margen de CU - Proveedores RPC - proveedores administrados, RPC público y compensaciones de auto-alojamiento
Versiones de la pila: Esta página fue escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, Rust 1.91.1, y @solana/kit 7.0.0.