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.
//
Busca en todas las páginas de la documentación
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.
@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.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, searchAssetsLas páginas hermanas de esta sección profundizan en cada rama; esta página mantiene todo el diagrama a la vista.
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 -> finalizedEl 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.
| 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.
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.
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:
getMultipleAccounts en lotes (a menudo ~50-100 claves por llamada, sujeto a la documentación del proveedor).getSignaturesForAddress con cursores before / until y un limit.Antes de confirmar transacciones sensibles, los clientes a menudo:
simulateTransaction con opciones como sigVerify: false y replaceRecentBlockhash para leer unitsConsumed, registros y errores.getRecentPrioritizationFees (y/o API de tarifas de percentil del proveedor) para las cuentas involucradas en el conjunto de bloqueo.La simulación no es un sustituto de la confirmación en mainnet; reduce los fallos evitables y la inclusión infravalorada.
| 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.
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.
| 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 |
@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.
signatureSubscribe; la durabilidad es el nivel de compromiso que esperas después.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.
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.
Muchas acciones de producto usan confirmed para una UX receptiva; usa finalized antes de efectos externos irreversibles; trata processed como optimista solamente.
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.
getMultipleAccounts carga claves públicas conocidas en un lote; GPA descubre cuentas por propietario (y filtros) cuando aún no conoces las direcciones.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
getAccountInfo, getBalance, getMultipleAccounts, descripción general de GPAmemcmp, dataSize, y escaneos seguros de programassimulateTransaction, y margen de CUVersiones 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.
Revisado por Chris St. John·Última actualización: 15 jul 2026