Skip to main content
Beta pública. preprocessedSubscribe está disponible en todos los planes de pago y se contabiliza a 0.1 créditos por mensaje (un mensaje por cada transacción entregada).

¿Qué es preprocessedSubscribe?

preprocessedSubscribe es un método WebSocket de Helius que transmite transacciones preprocesadas, es decir, transacciones de Solana previas a la ejecución que se entregan antes de alcanzar el nivel de compromiso processed. Helius agrega varias fuentes previas a la ejecución —principalmente shreds decodificados directamente a medida que llegan al validador, complementados con señales de preconfirmación— y las entrega como un único flujo sin duplicados de mensajes binarios compactos, sin que necesites infraestructura para reconstruir los shreds. Las transacciones provenientes de señales de preconfirmación llegan más tarde a este flujo que al producto dedicado Preconfirmations, que sigue ofreciendo el acceso más temprano a ellas. Es el sucesor del producto anterior LaserStream preprocesado (gRPC). Si actualmente consumes transacciones preprocesadas mediante gRPC, cambia a este método: entrega la misma clase de datos mediante una conexión WebSocket convencional con menor latencia, y la entrega mediante gRPC quedará obsoleta.
preprocessedSubscribe es una señal previa a la ejecución de mejor esfuerzo, no un nivel de compromiso. Una transacción transmitida puede fallar, descartarse o llegar a una bifurcación diferente. Compárala con un flujo procesado o confirmado antes de considerarla definitiva.

Punto de conexión

preprocessedSubscribe se ofrece desde wss://beta.helius-rpc.com —el punto de conexión de Helius Gatekeeper— en lugar de mainnet.helius-rpc.com. Autentícate con tu clave de API como parámetro de consulta:
Cada clave de API está limitada a 10 conexiones/suscripciones simultáneas.

Suscribirse

Envía una solicitud JSON-RPC con el método preprocessedSubscribe. params contiene los filtros de cuentas y es obligatorio: accountInclude y accountRequired deben especificar al menos una cuenta entre ambos (consulta Filtrado):
El servidor confirma la suscripción con una trama de texto JSON que contiene el ID de la suscripción:
Después de esta confirmación, las actualizaciones de transacciones llegan como tramas WebSocket binarias; consulta Carga útil de la notificación.

Filtrado

Cada suscripción está delimitada por los filtros de cuentas de params. El filtrado ocurre en el servidor, por lo que solo recibes las transacciones que te interesan:
Reglas de filtrado:
  • Los tres filtros se combinan con lógica AND.
  • accountInclude y accountRequired deben especificar al menos una cuenta entre ambos; no existe un flujo completo sin filtros.
  • Las cuentas son claves públicas codificadas en base58. Cada lista acepta hasta 5,000 direcciones.

Resolución de tablas de consulta de direcciones (ALT)

Los filtros de cuentas no solo coinciden con las claves de cuentas estáticas de la transacción: Helius resuelve las tablas de consulta de direcciones en el servidor, por lo que accountInclude, accountExclude e accountRequired también coinciden con las cuentas que una transacción carga mediante una ALT. Solo proporciona la clave pública de la cuenta; no necesitas mantener asignaciones de ALT ni resolver las tablas por tu cuenta.

Carga útil de la notificación

Las notificaciones se entregan como tramas WebSocket binarias (no JSON). Cada trama contiene una sola transacción en una estructura compacta de bytes: Lee en orden el prefijo fijo de 73 bytes y luego decodifica los bytes restantes para leer las instrucciones, las cuentas y las consultas de tablas de direcciones. La firma se incluye en el prefijo para que puedas identificar y eliminar duplicados de una transacción sin decodificar todo el cuerpo de la transacción. Siempre lee y verifica primero el byte version. Si Helius necesita actualizar el formato de la carga útil, la versión aumentará. Bifurca la lógica según ese valor para que tu decodificador siga funcionando aunque cambie el esquema.

Decodificación de la transacción

Los bytes de la transacción se reenvían exactamente como se observaron en la red, con la codificación de transmisión estándar correspondiente a la versión de la transacción. Las transacciones heredadas y v0 usan la estructura con las firmas al principio que genera bincode. Las transacciones v1 (SIMD-0385) usan una estructura con el mensaje al principio y las firmas al final, por lo que bincode falla con las cargas útiles v1. Usa un decodificador que admita todas las versiones:
  • Rust: agave-transaction-view analiza transacciones heredadas, v0 y v1 directamente, sin una copia intermedia. Esta es la opción recomendada. wincode, el serializador compatible con bincode que usan los SDK actuales de Solana, también decodifica v1 en VersionedTransaction.
  • JavaScript / TypeScript: asegúrate de que la versión de tu biblioteca admita transacciones v1. Las implementaciones anteriores de VersionedTransaction.deserialize solo admiten transacciones heredadas y v0. Usa @solana/kit 8.0+ o @solana/web3.js v3. Consulta Compatibilidad con transacciones v1.

Ejemplo

¿Qué datos están disponibles?

Cada notificación contiene la transacción firmada, su primera firma y su slot. Como la entrega ocurre antes de la ejecución, el flujo no incluye:
  • Estado o errores de ejecución
  • Saldos previos y posteriores, ni cambios en los saldos de tokens
  • Mensajes de registro ni instrucciones internas
  • Unidades de cómputo consumidas
Piensa en esto como recibir la «propuesta» sin el «resultado»: ves lo que el remitente intentó hacer, pero no lo que realmente ocurrió. Las actualizaciones del estado de cuentas y programas tampoco existen todavía en esta etapa. Si necesitas el estado de las cuentas en tiempo real, usa LaserStream gRPC con el nivel de compromiso processed.

Contrapresión

El flujo no almacena datos indefinidamente para los consumidores lentos. Si tu cliente lee con demasiada lentitud y se acumulan más de 4,000 mensajes en el servidor, Helius cierra la conexión y recibes una trama de cierre de WebSocket correcta. Procesa las tramas más rápido de lo que llegan: mantén las tareas pesadas, como la decodificación de transacciones y la lógica de estrategia, fuera del bucle de recepción; después de una desconexión, vuelve a conectarte y a suscribirte.

Garantías de entrega

La entrega es de mejor esfuerzo, no está garantizada y no existe reproducción histórica. Los clientes deben:
  1. Volver a conectarse y suscribirse después de que se cierre una conexión.
  2. Eliminar duplicados según la firma de la transacción.
  3. Tratar el slot como una observación, no como una finalidad.
  4. Comparar los datos con un flujo procesado o confirmado cuando importen los resultados de la ejecución.

Precios

preprocessedSubscribe está disponible en todos los planes de pago y se contabiliza a 0.1 créditos por mensaje: un mensaje por cada transacción entregada, facturado con cargo a tu plan. Consulta Créditos para obtener más información.

Recursos relacionados

Preconfirmations

Transacciones transmitidas antes de convertirse en shreds: la señal de transacción más temprana.

Raw Shreds (UDP)

Paquetes de shreds sin procesar mediante UDP. Tú implementas su reconstrucción.

transactionSubscribe

Transacciones posteriores a la ejecución con filtros avanzados y metadatos de ejecución.