Skip to main content
Al crear aplicaciones que deben responder a cambios en cadena, consultar periódicamente los endpoints RPC para obtener actualizaciones de cuentas es ineficiente y lento. Las suscripciones de cuentas solucionan este problema al enviar actualizaciones en tiempo real sobre los cambios de estado de las cuentas directamente a tu aplicación. Esta guía abarca todo lo que necesitas saber sobre las suscripciones de cuentas: qué son, cómo funcionan y cómo optimizarlas para tu caso de uso específico.

Contexto del modelo de cuentas

Omite esta sección si ya conoces las cuentas de Solana y su estructura.
Solana utiliza un modelo basado en cuentas en el que cada dato reside en una cuenta: un contenedor que almacena tanto datos como metadatos. Cada cuenta tiene:
  • Datos: Los bytes reales que almacenan el estado del programa, los saldos de tokens u otra información
  • Propietario: El programa que controla esta cuenta y puede modificar sus datos
  • Lamports: El saldo de SOL de la cuenta para la exención de renta
  • Ejecutable: Indica si esta cuenta contiene código de programa
Los programas no tienen estado: no almacenan datos internamente. En su lugar, crean y administran cuentas separadas para almacenar su estado. Cuando interactúas con un programa, proporcionas las cuentas de las que debe leer o en las que debe escribir. Este diseño hace que las suscripciones de cuentas sean potentes: puedes monitorear los cambios en cuentas específicas, en todas las cuentas que pertenecen a un programa o en las cuentas que cumplen ciertos criterios.

Suscripción básica de cuentas

Comencemos con un ejemplo sencillo que se suscribe a los cambios en las cuentas de tokens. Este script te notificará cada vez que cambien los saldos de tokens:
Cuando ejecutes esta suscripción básica, verás las actualizaciones de cuentas en tiempo real transmitidas a tu consola:
¿Qué acaba de suceder? ¡Nuestra suscripción funcionó perfectamente! Le pedimos a Laserstream que nos notificara sobre los cambios en las cuentas de tokens y nos envió una actualización sobre la cuenta BKMHWYLAX4un3HUbR7a3u9jPmzCiLNa4mSj1RiX11eWF. Esta cuenta tiene:
  • 2,039,280 lamports (saldo de ~0.002 SOL; esta es la cantidad exenta de renta para esta cuenta de token)
  • Programa propietario TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA (este es el programa SPL Token)
  • Firma de la transacción 5C9Hr5nG2j8eQz6inxPmfyjbYdmXddzUDyR1iQgEnjYQ3RNvuP4Zzc8t1enLNy7Rk8KNCtQPEQztENYWxkt9GaVD que muestra qué transacción específica provocó el cambio en esta cuenta
  • Slot 352366983 que indica cuándo ocurrió esta actualización en la blockchain
  • Campo de datos que contiene 165 bytes de datos de la cuenta codificados en base58

Cómo filtrar cuentas con datasize

El campo de datos es fundamental: contiene la estructura real de la cuenta de token. Usemos este conocimiento para aplicar un filtrado inteligente de cuentas.

¿Por qué usar el filtrado por datasize?

Para entender por qué necesitamos filtrar, primero debemos comprender qué son realmente las cuentas de tokens. Por cada token que contiene una billetera, existe una cuenta separada en cadena. Si tu billetera contiene 3 tokens diferentes (USDC, BONK y SOL), en realidad tienes 1 cuenta de billetera (tu cuenta principal de SOL) más 3 cuentas de tokens (una por cada tipo de token). Cada cuenta de token tiene exactamente 165 bytes y almacena qué token contiene (dirección de mint), quién es su propietario (la dirección de tu billetera) y qué cantidad de ese token contiene. El programa Token posee millones de cuentas en Solana, pero no todas son lo que consideramos «cuentas de tokens» que contienen saldos de usuarios. Esto es lo que ocurre con y sin filtrado: Sin filtrado: la avalancha:
Esto se suscribe a TODAS las cuentas que pertenecen al programa Token, entre ellas:
  • Cuentas de tokens (165 bytes): saldos de usuarios; millones de cuentas
  • Cuentas de mint (82 bytes): definiciones de tokens; cientos de miles de cuentas
  • Cuentas multifirma (355 bytes): controles de billeteras compartidas; decenas de miles de cuentas
  • Cuentas del programa Associated Token (varios tamaños): millones de cuentas
Resultado: Tu aplicación recibe constantemente millones de actualizaciones de cuentas, la mayoría de las cuales no te interesan.
Con filtrado inteligente: precisión quirúrgica:
Esto limita los resultados únicamente a las cuentas de 165 bytes, que son específicamente las cuentas de saldos de tokens de usuarios: justo lo que necesitas para monitorear transferencias de tokens, cambios de saldo y actualizaciones de portafolios. La diferencia:
  • Sin filtrado: Millones de actualizaciones de cuentas (creaciones de mint, cambios en multifirmas, etc.)
  • Con filtrado por datasize: Solo cambios en los saldos de tokens
Esto reduce considerablemente el ruido y se centra solo en las cuentas que realmente representan las tenencias de tokens de los usuarios.

¿De dónde provienen los 165 bytes?

No es magia: provienen de la estructura de cuentas del programa SPL Token. Al revisar el código fuente, podemos ver que la estructura Account define exactamente 165 bytes:
Este tamaño fijo nos permite filtrar con precisión las cuentas de tokens estándar y excluir:
  • Cuentas de mint (82 bytes)
  • Cuentas multifirma (355 bytes)
  • Cuentas del programa de cuentas de tokens asociadas
  • Otras cuentas relacionadas con tokens que tienen tamaños diferentes
Para calcular los tamaños de las cuentas en otros programas, consulta la Referencia de espacio de Anchor, que muestra cuánto espacio ocupan los distintos tipos de datos (Pubkey = 32 bytes, u64 = 8 bytes, etc.).

Decodificación de la estructura de la cuenta

Ahora que entendemos por qué filtramos por 165 bytes, decodifiquemos el contenido de nuestra cuenta de ejemplo:
Los 165 bytes se distribuyen de la siguiente manera:
  • Bytes 0-31: Dirección de mint (qué token contiene esta cuenta)
  • Bytes 32-63: Dirección del propietario (quién posee esta cuenta de token)
  • Bytes 64-71: Cantidad de tokens (cuántos tokens hay en la cuenta)
  • Bytes 72-164: Metadatos adicionales (delegado, estado, autoridad de cierre, etc.)
Este enfoque estructurado nos brinda precisión quirúrgica: solo recibimos actualizaciones de cuentas de tokens estándar, sin el ruido de otros tipos de cuentas.

Combinación de filtros: datasize + memcmp para una precisión extrema

Ahora que sabemos que la dirección de mint se encuentra en los bytes 0-31, podemos ser aún más específicos. Supongamos que solo queremos monitorear cuentas de tokens USDC. Podemos combinar nuestro filtro datasize con un filtro memcmp para apuntar a la dirección de mint exacta:
Estrategia de filtrado progresivo:
  1. Filtro por propietario: «Dame las cuentas que pertenecen al programa Token» (millones de cuentas)
  2. Filtro por datasize: «Pero solo las cuentas de tokens estándar de 165 bytes» (cientos de miles)
  3. Filtro memcmp: «Y solo las que contienen USDC» (miles)
Esta progresión de lo general a lo específico es la clave para monitorear cuentas de forma eficiente. Cada filtro reduce el conjunto de resultados para que solo recibas las actualizaciones exactas que te interesan. Importante: Todos los filtros usan lógica AND: deben cumplirse todas las condiciones para que se active una actualización de cuenta.

Lectura de actualizaciones de cuentas de USDC: ¿quién, cuánto y dónde?

Ahora veamos qué contienen realmente estas actualizaciones filtradas. Creemos un monitor específico para USDC que responda las preguntas clave cuando cambia una cuenta de token:
  • ¿Quién posee esta cuenta de token?
  • ¿Cuánto USDC contiene ahora?
  • ¿Dónde ocurrió el cambio (en qué cuenta específica)?
  • ¿Cuándo ocurrió este cambio?
  • ¿Qué transacción provocó el cambio?
Las actualizaciones sin procesar de las cuentas contienen datos binarios que debemos decodificar. Como Solana utiliza la codificación base58 para las direcciones y las firmas, usamos la función bs58.encode() para convertir los objetos Buffer binarios en cadenas legibles.
Cuando ejecutes este monitor de USDC, verás un resultado claro y estructurado como este:
Cada bloque representa una cuenta de USDC cuyo estado cambió. La primera cuenta ahora contiene 1,500 USDC, mientras que la segunda se vació y ahora contiene 0 USDC. Obtienes el saldo actual inmediatamente después de cada transacción, junto con la cuenta específica que cambió y el momento en que ocurrió. Las suscripciones de cuentas te muestran el resultado final de lo que ocurrió en cada cuenta, no los detalles de la transacción. Si necesitas comprender todo el contexto de la transacción (quién envió a quién, las comisiones, etc.), debes obtener la transacción completa mediante la firma mostrada.

Referencia completa de filtrado

Además de los filtros básicos owner, datasize e memcmp que usamos, las suscripciones de cuentas admiten opciones de filtrado adicionales para limitar aún más los resultados:

Filtrado de cuentas específicas

Monitorea cuentas exactas mediante sus claves públicas:
Este enfoque funciona bien cuando sabes exactamente qué cuentas son importantes para tu aplicación, como al monitorear las cuentas de tesorería de tu aplicación o cuentas de usuarios específicas. Para conjuntos de cuentas muy grandes, las listas explícitas de pubkeys resultan costosas: 32 bytes por cuenta en la solicitud de suscripción. Para más de ~10,000 cuentas, usa un filtro de cuco comprimido (~3–4 bytes por cuenta) para monitorear cientos de miles de cuentas en un único stream. Está disponible en los SDK de Rust y JavaScript.

Estrategias de filtrado combinado

La potencia proviene de combinar varios tipos de filtros. Este es el modelo mental:
  1. Abarca un conjunto amplio con owner: «Dame todas las cuentas administradas por este programa»
  2. Filtra por estructura con datasize: «Pero solo las cuentas de este tipo específico»
  3. Apunta a datos específicos con memcmp: «Y solo las que contienen esta información específica»
  4. Monitorea cuentas conocidas con account: «O simplemente observa estas cuentas exactas que me interesan»
Por ejemplo, para monitorear cuentas de USDC de alto valor:
La idea clave es que cada filtro reduce el volumen de actualizaciones que recibes. Sin filtrado, podrías recibir una cantidad abrumadora de actualizaciones de cuentas. Con un filtrado inteligente, solo recibes las actualizaciones relevantes para tu caso de uso específico.

Comprensión del panorama general

Piensa en las suscripciones de cuentas como si observaras un feed en vivo de cambios en una base de datos. El estado de Solana es, en esencia, un enorme almacén de clave-valor donde cada cuenta es una entrada. Cuando los programas se ejecutan, modifican estas cuentas. Tu suscripción te permite observar en tiempo real cómo cambian entradas específicas. El sistema de filtrado funciona como los índices de una base de datos: no solo observas «todos los cambios», sino «los cambios en las cuentas que cumplen estos criterios». Esto permite crear aplicaciones con gran capacidad de respuesta que reaccionan de inmediato a eventos relevantes en cadena sin saturar tu sistema con datos irrelevantes.

Aplicación de este patrón a otros programas

El enfoque que aprendimos funciona para cualquier programa de Solana. Este es el patrón general:
  1. Investiga la estructura de las cuentas: consulta el código fuente o la documentación del programa
  2. Comienza con el filtrado por propietario: apunta al programa que administra las cuentas
  3. Aplica filtros estructurales: usa el tamaño de la cuenta, patrones de datos u otras características para limitar los resultados a tipos de cuentas específicos
  4. Agrega filtros dirigidos: céntrate en cuentas, estados o valores de datos específicos que sean importantes para tu aplicación