Presentamos Blazar: la solución WebSocket de Quicknode diseñada específicamente para Solana

Quicknode

14 de abril de 2026 — 6 minutos de lectura

Compartir

Añadir como fuente preferida

Los WebSockets son la opción predeterminada para los desarrolladores de « Solana » que necesitan datos en cadena en tiempo real, ya que ofrecen una amplia compatibilidad con aplicaciones front-end y móviles, y suponen una vía más sencilla que « gRPC » para los back-ends basados en eventos.

Sin embargo, la implementación nativa de WebSocket de Solana nunca se diseñó para gestionar grandes volúmenes de datos a gran escala. Un tercio de la API está oficialmente marcada como inestable, el servicio PubSub pierde mensajes cuando se ve sometido a una carga elevada y la mayoría de las aplicaciones lo compensan discretamente con capas de soluciones provisionales que no deberían ser necesarias.

Creamos Blazar para solucionar ese problema de raíz.

¿Qué es un blazar?

Blazar es el motor WebSocket interno de Quicknode Solana , desarrollado desde cero y optimizado específicamente para las cargas de trabajo que los desarrolladores de Solana ejecutan en producción. No se trata de una bifurcación de ninguna solución de código abierto ni de una envoltura alrededor del PubSub nativo de Agave. Implementa el conjunto completo de métodos de suscripción WebSocket de Solana para tus Quicknode Solana endpoint existentes, sin que sea necesario realizar cambios en SDK ni llevar a cabo ninguna migración.

Blazar es más rápido, más fiable y más completo que cualquier otra solución basada en el PubSub nativo de Agave. Gestiona un gran número de suscriptores simultáneos sin pérdida de rendimiento y mantiene una entrega constante, mientras que el PubSub nativo de Agave empezaría a perder mensajes.

Más allá de los aspectos fundamentales del rendimiento, también ofrece un soporte estable para los métodos de suscripción que la mayoría de los proveedores no pueden ofrecer de forma fiable.

Métodos que antes eran inestables, ahora listos para su uso en producción

SolanaLa API de WebSocket ofrece nueve métodos de suscripción. Tres de ellos, «voteSubscribe», «slotsUpdatesSubscribe» y «blockSubscribe», están marcados oficialmente como inestables en la última versión del cliente validador de Agave 3.x y, en la práctica, son inaccesibles en las conexiones WebSocket estándar de Solana .

Para los desarrolladores que necesitan datos de bloques, información sobre votaciones o actualizaciones detalladas sobre el estado de las ranuras, estos métodos son esenciales, no casos excepcionales.

VotarSuscribirse

VotarSuscribirse Proporciona las transacciones de votación tal y como se ejecutan en el nivel de compromiso procesado, antes de que se confirme la ranura y antes de que exista cualquier garantía de finalidad. Debido a su inestabilidad, ha sido prácticamente inaccesible para la mayoría de los desarrolladores de aplicaciones. En Blazar está disponible y es fiable, lo que abre nuevas posibilidades para herramientas de estimación de la confirmación optimista, paneles de control de participación en votaciones o seguimiento de la finalidad de los bloques ponderada por la participación.

tragaperrasActualizacionesSuscríbete

tragaperrasActualizacionesSuscríbete muestra el ciclo de vida completo de una ranura, desde firstShredReceived a través de finalizado, Confirmación optimista, y finalmente arraigado. Ese nivel de detalle es importante si estás midiendo la latencia de extremo a extremo y necesitas saber exactamente cuándo la red detectó por primera vez una ranura y cuándo lo hizo tu aplicación. También te permite activar la lógica en Confirmación optimista, el momento más temprano en el que es prácticamente seguro actuar sobre una ranura, sin necesidad de realizar consultas ni esperar a que se alcance la finalidad completa. Anteriormente, para obtener este tipo de señal a nivel de ranura de forma fiable era necesario disponer de una infraestructura de validador propia. En Blazar, esta señal se transmite a través de tu conexión WebSocket estándar.

blockSubscribe

blockSubscribe prácticamente no está disponible en las conexiones WebSocket nativas de Solana . Cuando sí aparece, un volumen elevado de transacciones suele provocar errores por mensajes de tamaño excesivo, desconexiones o la pérdida silenciosa de datos. En Blazar, es totalmente compatible y estable, lo que convierte a los datos de suscripción a nivel de bloque en una opción viable como nunca antes lo había sido.

Compatibilidad ampliada con métodos

Blazar también es compatible con suscribirse a transacciones, un método introducido originalmente por Triton como parte de su proxy Whirligig WebSocket. No forma parte de la API estándar de WebSocket de Solana , pero se ha convertido en una extensión ampliamente adoptada por los desarrolladores que necesitan datos de transacción más detallados que registrosSuscribirse o CuentaSuscribirse proporcionar. Este método permite filtrar por cuenta, resultado de la transacción y nivel de compromiso, lo que resulta muy útil para realizar un seguimiento en tiempo real de la actividad del programa, recibir alertas sobre transacciones fallidas o crear un feed de swaps en tiempo real sin necesidad de realizar consultas periódicas.

Ventajas en cuanto al rendimiento

Hemos comparado Blazar con el proxy WebSocket de código abierto más utilizado, Solana , en condiciones reales de mainnet . Esto es lo que hemos descubierto.

Entrega fiable

El mecanismo PubSub nativo de Agave se ejecuta, por defecto, en un único hilo de trabajo, lo que provoca un cuello de botella en todo el procesamiento de suscripciones, independientemente del número de núcleos disponibles. Bajo una carga de red elevada, precisamente cuando los datos en tiempo real son más importantes, el sistema PubSub nativo descartará mensajes y provocará picos de latencia impredecibles.

Blazar se ha diseñado específicamente para eliminar estos modos de fallo. En las mismas condiciones de carga pesada, Blazar ofreció resultados estables y uniformes:

Datos más rápidos directamente desde la fuente

La infraestructura estándar de RPC recibe datos a través de la red Turbine en su conjunto, lo que significa que los eventos llegan más adelante en la ruta de propagación. La fuente de datos de origen de Blazar funciona con ShredStream y recibe fragmentos de los 100 principales líderes de Turbine. Una fuente compatible con ShredStream entrega los datos entre 200 y 250 ms más rápido que una fuente pública normal de Turbine. Esa ventaja inicial se incorpora a cada evento antes de que Blazar comience a procesarlo.

La latencia que añade Blazar entre un evento en cadena y el momento en que tu aplicación lo recibe es inferior a 1 ms, incluso bajo una carga elevada. Esto se aplica a las actualizaciones de cuentas, los bloques completos y todos los demás tipos de suscripción.

Blazar proporciona datos a los clientes mucho antes que el servidor WebSocket más habitual en todos los escenarios probados. Se han realizado 200 pruebas de conexión utilizando la cuenta SysvarClock para garantizar que esta se actualice constantemente.

Escalas sin pérdida de calidad

Cada nodo de Agave gestiona un número finito de suscriptores de WebSocket antes de que el rendimiento se vea afectado para todos ellos, lo que requiere hardware adicional y una mayor complejidad operativa. Blazar gestiona un gran número de suscripciones simultáneas sin que se vea afectado el rendimiento por suscriptor. Cada suscriptor recibe una transmisión constante y de baja latencia, independientemente del número total de suscripciones.

El consumo de memoria en Blazar se reduce considerablemente en todos los casos.

Blazar reduce considerablemente el uso de la CPU en la mayoría de los casos.

Las pruebas de rendimiento se realizaron en un entorno controlado y aislado, con los clientes conectados directamente al servidor desde un equipo independiente, sin ningún equilibrador de carga ni capa perimetral de por medio.

Qué significa esto para los desarrolladores

Para los desarrolladores que programan en Quicknode, Blazar cambia lo que se puede dar por sentado sobre la conexión WebSocket:

• Menos soluciones provisionales. La lógica de reintento , la detección de lagunas y las conexiones redundantes sirven para compensar la falta de fiabilidad en la entrega. Al encargarse Blazar de la fiabilidad a nivel de infraestructura, ese código compensatorio deja de ser necesario.

• Datos completos streams. Cuando tu aplicación recibe una notificación, también llegan los eventos que la preceden. Diseña tu lógica partiendo de la base de que el flujo es continuo.

• Rendimiento predecible a gran escala. El rendimiento de la suscripción no se ve afectado a medida que aumenta el número de conexiones. Tu aplicación no sufrirá una caída brusca del rendimiento a medida que crezca.

Blazar no es un producto independiente, un complemento ni una función del plan premium. Se trata de una actualización gratuita para todos los Quicknode Solana WebSocket endpoint, que ya se ha implementado en todos los planes. No hay que activar nada, ni migrar nada, ni pagar ningún coste adicional.

Primeros pasos

1. Inicia sesión en tu panel de control deQuicknode .

2. Selecciona tu « Solana »endpoint.

3. Copia la URL « endpoint » de tu WSS y conéctate utilizando el código de tu cliente WebSocket actual.

¿Eres nuevo en los WebSockets de Solana ? La guía «Cómo crear suscripciones WebSocket a la cadena de bloques de Solana utilizando TypeScript» te explica todo lo que necesitas saber.

Conclusión

Blazar elimina los límites de fiabilidad y rendimiento que impone la implementación nativa de WebSocket de Solana, al ofrecer una sobrecarga de procesamiento inferior a un milisegundo, compatibilidad estable con los nueve métodos de suscripción —incluidos los tres marcados como inestables en Agave— y un rendimiento en pruebas de rendimiento que se mantiene a gran escala.

Los WebSockets siguen siendo una de las formas más sencillas que tienen los desarrolladores de obtener datos en cadena en tiempo real. Ahora, la infraestructura que los sustenta está a la altura de lo que realmente exigen. Inicia sesión en tu panel de control deQuicknode para empezar.