Presentamos shredTransactionSubscribe: visibilidad de las transacciones de Solana s antes de su ejecución
Presentamos shredTransactionSubscribe: visibilidad de las transacciones de Solana s antes de su ejecución
La función `shredTransactionSubscribe` de Blazar ofrece visibilidad de las transacciones de ` Solana ` antes de su ejecución mediante una suscripción WebSocket JSON-RPC. Descubre los filtros, el formato de las notificaciones y las solicitudes de ejemplo.
30 de junio de 2026 — 9 minutos de lectura
Solana Es rápido, en parte, porque los bloques no se transmiten por la red como objetos únicos de gran tamaño. Los validadores dividen los datos del bloque en pequeños fragmentos, denominados «shreds», y los envían antes de que el bloque se haya reproducido por completo. Esto ocurre antes de que las suscripciones RPC normales puedan mostrar ningún dato de ejecución.
Blazar, el motor WebSocket de Quicknode( Solana ), incluye ahora shredTransactionSubscribe. Convierte esa señal inicial en un método WebSocket que los desarrolladores pueden utilizar. Se suscribe a las transacciones detectadas durante el desglose y la ingesta de entradas, antes de la ejecución.
shredTransactionSubscribe se encuentra en fase beta, por lo que lo descrito en esta entrada podría sufrir cambios.
¿Qué es un «shred»?
Un «shred» es una parte de tamaño fijo de un bloque Solana , que se envía a través de la red mientras se genera el bloque. La lectura de los «shreds» permite ver los datos de las transacciones a medida que circulan por la red, antes de que el bloque finalizado pueda consultarse mediante métodos RPC posteriores a la ejecución.
Los fragmentos se pueden reconstruir para formar entradas. Las entradas contienen Solana Transacción con control de versiones valores: firmas, mensajes, claves estáticas de cuenta, instrucciones, hash de bloques recientes y referencias a tablas de búsqueda de direcciones para transacciones v0.
La diferencia fundamental radica en el momento:
La ingestión de fragmentos/entradas tiene lugar antes de la reproducción/ejecución.
Los metadatos normales de una transacción solo están disponibles tras su ejecución.
Los datos de «shred-time» pueden llegar antes que los datos de ejecución. Sin embargo, no pueden incluir resultados de ejecución como «meta», «err», registros, saldos de tokens, unidades de cálculo o instrucciones internas.
Cómo obtiene y normaliza los datos Blazar
Trabajar con datos sin procesar de Shred presenta dos carencias que la mayoría de los desarrolladores no pueden subsanar fácilmente.
En primer lugar, las herramientas. Un flujo «SubscribeEntries» sin procesar requiere un gRPC, la decodificación de Bincode, el análisis de transacciones y la resolución de la tabla de búsqueda de direcciones. Además, es necesario saber exactamente qué se conoce y qué no antes de la ejecución. La mayoría de los desarrolladores de aplicaciones solo quieren una suscripción JSON-RPC a través de WebSocket.
En segundo lugar, el filtrado de cuentas requiere tablas de consulta. La mayoría de las transacciones de la versión 0 de Solana utilizan tablas de consulta de direcciones (ALT). Si no se resuelven las ALT localmente, los filtros de cuentas pueden pasar por alto una transacción que solo afecte a una cuenta a través de una tabla de consulta. Blazar resuelve las claves estáticas y las direcciones ALT cargadas al filtrar por cuenta.
Blazar recibe un flujo de transacciones « Solana » (en tiempo real) de la infraestructura de «shred-streaming». Convierte esa señal de red de bajo nivel en una suscripción estándar a WebSocket JSON-RPC. Blazar puede ver las transacciones antes de que lo hagan los métodos RPC habituales tras la ejecución. A continuación, envía un shredTransactionNotification junto con el cuerpo de la transacción, la ranura, la firma, la versión y las direcciones cargadas resueltas, cuando estén disponibles.
Considera el flujo como una señal inicial de «mejor esfuerzo». Las notificaciones llegan más o menos en el orden en que se envían, sin garantía de un orden estricto. En ocasiones, una misma transacción puede aparecer más de una vez, por lo que debes eliminar los duplicados basándote en la firma si necesitas una entrega «exactamente una vez».
Blazar también enriquece los datos derivados de Shred antes de enviarlos. En lugar de transmitir una señal sin procesar y hacer que cada cliente realice el mismo trabajo, normaliza el formato de la transacción y resuelve las direcciones de las tablas de consulta siempre que puede. Los suscriptores obtienen una visión más completa de las cuentas antes de la ejecución sin necesidad de utilizar una infraestructura de red especial Solana ni de desarrollar su propio analizador de Shred.
Fragmentos sobre la cronología de la transacción de « Solana »
La visibilidad del tiempo de trituración añade un nuevo punto, anterior, a la línea temporal de datos de « Solana »:
Difusión de la transacción -> fragmentos detectados -> entradas descodificadas -> reproducción/ejecución -> datos RPC procesados/confirmados/finalizados
La mayoría de los métodos WebSocket de Solana funcionan tras la ejecución o en torno a los cambios de estado del validador. shredTransactionSubscribe muestra el punto anterior en el que se descodifican las entradas.
No sustituye a suscribirse a transacciones. Se trata de un complemento previo a la ejecución, destinado a flujos de trabajo que se benefician de conocer la intención de la transacción lo antes posible.
Ejemplos de casos de uso
shredTransactionSubscribe admite casos de uso que los métodos posteriores a la ejecución no pueden cubrir y mejora otros al proporcionar datos antes de la ejecución.
Intención de transacción temprana
Los sistemas de negociación, los análisis de los DEX, los motores de enrutamiento y la infraestructura de mercado pueden ver las transacciones antes de que se ejecuten. Esto permite detectar la presión sobre las cuentas, la actividad de los programas y el « flow » de las órdenes entrantes antes de lo que lo hacen los análisis habituales posteriores a la ejecución streams.
Supervisión previa a la ejecución con reconocimiento de cuentas
Un cliente puede suscribirse a las transacciones que afecten a cuentas específicas, incluidas las cuentas cargadas a través de tablas de búsqueda de direcciones. Utilízalo para supervisar cuentas activas, fondos comunes, cuentas de tokens, cajas fuertes o cuentas de estado del protocolo.
Seguimiento del ciclo de vida a nivel de firma
Combínalo con firmaSuscribirse y enableReceivedNotification: true para saber cuándo se detectó por primera vez una firma antes de la ejecución y, posteriormente, si se completó con éxito o falló.
Diagnóstico operativo
Los equipos de soporte e infraestructura pueden responder a preguntas como: ¿Se detectó la transacción antes de su ejecución? ¿Se registró más tarde? ¿Nunca se detectó? ¿Utilizó direcciones de la tabla de consulta? Esto facilita el diagnóstico de los problemas relacionados con el ciclo de vida de las transacciones.
Señales de votación y de tragaperras
Blazar utiliza la misma ruta de ingestión «shred» y «entry» para las notificaciones de votación previas a la ejecución y las señales de nuevas ranuras. «shredTransactionSubscribe» es el método específico para transacciones basado en esa misma fuente de datos inicial.
Descripción general del método
shredTransactionSubscribe se suscribe a las notificaciones de transacciones previas a la ejecución procedentes de shred y de la ingesta de entradas. Se ha decidido deliberadamente que no sea una opción de configuración en transactionSubscribe. La carga útil es diferente porque los datos proceden de una etapa distinta.
Acepta un objeto de filtro opcional como primer y único parámetro.
{
"jsonrpc": "2.0",
"id": 1,
"method": "shredTransactionSubscribe",
"params": [
{
"vote": false,
"signature": "optional-signature",
"accounts": {
"include": ["optional-pubkey"],
"exclude": ["optional-pubkey"],
"required": ["optional-pubkey"]
}
}
]
}Todos los campos son opcionales. Cada lista de cuentas (incluir, excluir, obligatorias) admite hasta 50 000 entradas.
Filtros compatibles
voto
verdadero: solo transacciones de voto sencillas.
false: excluir las transacciones de voto simples.
omitido: incluir tanto las transacciones con voto como las que no tienen voto.
El filtro de votos utiliza la clasificación de transacciones de «voto simple» de Agave. Esto no significa «cualquier transacción que contenga una instrucción del programa Vote». Las transacciones mixtas que incluyen una instrucción de voto no se clasifican como votos simples. voteSubscribe es un método independiente con su propio análisis sintáctico de votos por chisme.
firma
Devuelve únicamente la transacción con la firma indicada.
cuentas.incluir
Proporciona transacciones que afectan al menos a una de las cuentas indicadas.
Coincide con las claves de cuenta estáticas y con las direcciones resueltas cargadas mediante ALT.
cuentas.excluir
Elimina las transacciones que afecten a cualquiera de las cuentas indicadas.
Coincide con las claves de cuenta estáticas y con las direcciones resueltas cargadas mediante ALT.
cuentas.obligatorias
Muestra únicamente las transacciones que afectan a todas las cuentas indicadas.
Coincide con las claves de cuenta estáticas y con las direcciones resueltas cargadas mediante ALT.
Parámetros no admitidos
«commitment», «encoding», «transactionDetails», «showRewards», «maxSupportedTransactionVersion» y «failed» no son compatibles. Las transacciones derivadas de «shred» son cargas útiles JSON previas a la ejecución, por lo que no tienen resultados de ejecución ni niveles de compromiso.
Ejemplos de solicitudes
Suscríbete a todas las transacciones previas a la ejecución que no impliquen votación
{
"jsonrpc": "2.0",
"id": 11,
"method": "shredTransactionSubscribe",
"params": [
{ "vote": false }
]
}Suscribirse a una firma concreta
{
"jsonrpc": "2.0",
"id": 12,
"method": "shredTransactionSubscribe",
"params": [
{
"signature": "5VERv8NMvzbJMEkV8xnqLkEaWRtSz9CosKDYjCJjBRnbJLgp8uirBgmQpjKhoR4tjF3ZpRzrFmBV6UjKdiSZkQUW"
}
]
}Suscríbete a las transacciones relacionadas con una cuenta
{
"jsonrpc": "2.0",
"id": 13,
"method": "shredTransactionSubscribe",
"params": [
{
"accounts": {
"include": ["TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA"]
}
}
]
}Exigir varias cuentas y excluir otra
{
"jsonrpc": "2.0",
"id": 14,
"method": "shredTransactionSubscribe",
"params": [
{
"accounts": {
"required": [
"AccountA11111111111111111111111111111111111",
"AccountB22222222222222222222222222222222222"
],
"exclude": [
"AccountC33333333333333333333333333333333333"
]
}
}
]
}Respuesta sobre la suscripción
Si la operación se realiza correctamente, el servidor devuelve un ID de suscripción. Utiliza este ID para darte de baja.
{
"jsonrpc": "2.0",
"result": 123,
"id": 14
}Darse de baja
{
"jsonrpc": "2.0",
"id": 15,
"method": "shredTransactionUnsubscribe",
"params": [123]
}Forma de la notificación
Una notificación utiliza la envoltura estándar PubSub de JSON-RPC, pero el valor de la transacción interna corresponde a datos previos a la ejecución.
{
"jsonrpc": "2.0",
"method": "shredTransactionNotification",
"params": {
"result": {
"context": { "slot": 418437508 },
"value": {
"slot": 418437508,
"signature": "5VERv8NMvzbJMEkV8xnqLkEaWRtSz9CosKDYjCJjBRnbJLgp8uirBgmQpjKhoR4tjF3ZpRzrFmBV6UjKdiSZkQUW",
"transaction": {
"signatures": [
"5VERv8NMvzbJMEkV8xnqLkEaWRtSz9CosKDYjCJjBRnbJLgp8uirBgmQpjKhoR4tjF3ZpRzrFmBV6UjKdiSZkQUW"
],
"message": {
"header": {
"numRequiredSignatures": 1,
"numReadonlySignedAccounts": 0,
"numReadonlyUnsignedAccounts": 2
},
"accountKeys": [
"FeePayer11111111111111111111111111111111111",
"Program111111111111111111111111111111111111"
],
"recentBlockhash": "Eit7...",
"instructions": [
{
"programIdIndex": 1,
"accounts": [0],
"data": "3Bxs4NN8M2Yn4TLb",
"stackHeight": 1
}
]
}
},
"version": "legacy"
}
},
"subscription": 123
}
}Ejemplo de transacción versionada con direcciones cargadas
En las transacciones de la versión v0, `transaction.message.addressTableLookups` conserva las referencias a las tablas de búsqueda, y `value.loadedAddresses` contiene las claves públicas resueltas.
{
"jsonrpc": "2.0",
"method": "shredTransactionNotification",
"params": {
"result": {
"context": { "slot": 418437509 },
"value": {
"slot": 418437509,
"signature": "7rYg...",
"transaction": {
"signatures": ["7rYg..."],
"message": {
"header": {
"numRequiredSignatures": 1,
"numReadonlySignedAccounts": 0,
"numReadonlyUnsignedAccounts": 1
},
"accountKeys": [
"FeePayer11111111111111111111111111111111111",
"Program111111111111111111111111111111111111"
],
"recentBlockhash": "AbCd...",
"instructions": [
{
"programIdIndex": 1,
"accounts": [0, 2, 3],
"data": "3Bxs4NN8M2Yn4TLb",
"stackHeight": 1
}
],
"addressTableLookups": [
{
"accountKey": "LookupTab1e11111111111111111111111111111111",
"writableIndexes": [12],
"readonlyIndexes": [3]
}
]
}
},
"version": 0,
"loadedAddresses": {
"writable": ["Writab1eLoaded11111111111111111111111111111"],
"readonly": ["Readon1yLoaded11111111111111111111111111111"]
}
}
},
"subscription": 124
}
}Si Blazar no puede resolver una o varias tablas de consulta desde la caché, se establecen las notificaciones v0:
"loadedAddresses": null
Incluso con el precalentamiento al inicio y las actualizaciones en tiempo real de Solana gRPC , una tabla que acaba de ampliarse puede entrar en conflicto con la caché. Cuando eso ocurre, Blazar establece loadedAddresses: null para las transacciones v0 cuyas direcciones cargadas estén incompletas, de modo que la notificación siga siendo precisa.
Las transacciones heredadas omiten «loadedAddresses».
Lo que no incluye la carga útil
Dado que se trata de datos previos a la ejecución, la notificación no incluye:
meta
err
registros
instrucciones internas
saldos iniciales y finales
saldos de tokens antes y después
unidades de cálculo consumidas
datos de retorno
recompensas
índice de la última transacción del bloque
shredTransactionSubscribe es un método de observación temprana, no un método de resultado de ejecución.
Primeros pasos
Inicia sesión en tu panel de control deQuicknode .
Selecciona tu Solana endpoint.
Copia la URL de tu WSS endpoint (wss://your-endpoint-name.solana-mainnet.quiknode.pro/abc123) y conéctate utilizando tu código de cliente WebSocket actual.
Consulta las «Solicitudes de ejemplo» anteriores para enviar una solicitud «shredTransactionSubscribe» con un filtro opcional.
Procesa los mensajes «shredTransactionNotification» a medida que vayan llegando.
¿Eres nuevo en los WebSockets de Solana ? La guía «Cómo crear suscripciones a WebSockets en Solana » te explica todo lo que necesitas saber.
Para los equipos que necesitan una transmisión de « Solana » con menor latencia más allá de WebSockets, el producto de QuicknodeSolana gRPC ofrece una streams en tiempo real compatible con Yellowstone desde el mismo ecosistema de endpoint .
Preguntas frecuentes
¿Es «shredTransactionSubscribe» lo mismo que «transactionSubscribe» con un compromiso anterior?
La transacción «transactionSubscribe» se ejecuta tras la ejecución y contiene metadatos sobre el estado de la transacción. La transacción «shredTransactionSubscribe» se ejecuta antes de la ejecución y no contiene registros, metadatos, errores, saldos ni unidades de cálculo.
¿Puede fallar una transacción de «shred» más adelante?
Sí. Una transacción observada a partir de fragmentos puede, posteriormente, no completarse, caducar o no aparecer en el libro mayor definitivo. Este método constituye una señal de observación temprana, no una señal de finalidad.
¿Los filtros de cuentas incluyen las cuentas de la tabla de búsqueda de direcciones?
Sí. Los filtros de cuentas coinciden con las claves de cuenta estáticas y con las direcciones resueltas cargadas mediante ALT procedentes de la caché de la tabla de búsqueda local de Blazar.
¿Qué ocurre cuando se desactiva un ALT?
Una ALT desactivada puede seguir utilizándose durante el periodo de enfriamiento de sus SlotHashes. Blazar resuelve las tablas desactivadas durante ese periodo de enfriamiento y trata las tablas que han caducado claramente como no resueltas.
¿Quién debería utilizar este método?
Úsalo cuando la intención inicial de la transacción sea más importante que el resultado de la ejecución: análisis de baja latencia, supervisión de la actividad de las cuentas, diagnóstico del ciclo de vida de las transacciones, infraestructura de negociación y observabilidad previa a la ejecución.
¿Quiénes no deberían utilizar este método?
No lo utilices si necesitas el estado definitivo de una transacción, registros, saldos, cambios en el saldo de tokens, unidades de cálculo, recompensas o la composición de los bloques finalizados. Para ello, utiliza los métodos RPC/WebSocket posteriores a la ejecución.
Conclusión
Hasta ahora, los datos de transacciones previos a la ejecución requerían una infraestructura de red personalizada de tipo « Solana »: clientes « gRPC », decodificación de «bincode» y procesos de análisis de «shred». La función «shredTransactionSubscribe» de Blazar elimina esa necesidad. Proporciona la intención de la transacción antes de su ejecución como una suscripción estándar de WebSocket JSON-RPC.
Ya está disponible en todos los Quicknode Blazar WebSocket endpoint . Inicia sesión en tu panel de control deQuicknode para empezar, o crea una cuenta en Quicknode si aún no tienes una.
Dado que shredTransactionSubscribe se encuentra actualmente en fase beta, te invitamos a que nos envíes tus comentarios o sugerencias. Envíanos un correo electrónico a solana@quicknode.com o ponte en contacto con nosotros a través de Discord.
Acerca de Quicknode
Fundada en 2017, Quicknode ofrece una infraestructura de blockchain de nivel institucional para desarrolladores y empresas. Con un tiempo de actividad del 99,99 % y compatibilidad con más de 76 cadenas, los equipos pueden crear y ampliar aplicaciones en cadena sin renunciar a nada.
Mantente al día
Las últimas novedades sobre ingeniería, actualizaciones de productos y noticias sobre la Web3, directamente en tu bandeja de entrada.