Présentation de shredTransactionSubscribe : Solana Visibilité des transactions avant leur exécution

Quicknode

30 juin 2026 — 9 min de lecture

Partager

Ajouter comme source préférée

Solana Ce système est rapide, en partie parce que les blocs ne transitent pas sur le réseau sous la forme d'un seul objet volumineux. Les validateurs divisent les données du bloc en petits fragments appelés « shreds » et les envoient avant que le bloc ne soit entièrement reproduit. Cela se produit avant que les abonnements RPC normaux ne puissent afficher la moindre donnée d'exécution.

Blazar, le moteur WebSocket de Quicknode( Solana ), inclut désormais shredTransactionSubscribe. Il transforme ce signal précoce en une méthode WebSocket que les développeurs peuvent utiliser. Il s'abonne aux transactions détectées lors du « shred » et de l'ingestion des entrées, avant leur exécution.

shredTransactionSubscribe est en version bêta, et les informations fournies dans cet article sont susceptibles d'évoluer.

Qu'est-ce qu'un « shred » ?

Un « shred » est un fragment de taille fixe issu d’un bloc de l’ Solana , transmis sur le réseau pendant la création du bloc. La lecture des « shreds » permet de consulter les données des transactions au fur et à mesure de leur circulation sur le réseau, avant que le bloc finalisé ne puisse être interrogé via des méthodes RPC post-exécution.

Les fragments peuvent être reconstitués pour former des entrées. Les entrées contiennent Solana Transaction versionnée valeurs : signatures, messages, clés de compte statiques, instructions, hachages de blocs récents et références aux tables de recherche d'adresses pour les transactions v0.

La principale différence réside dans le moment choisi :

• L'ingestion des données fragmentées/d'entrée a lieu avant la relecture/l'exécution.

• Les métadonnées d'une transaction normale ne sont disponibles qu'après son exécution.

Les données relatives au temps de traitement peuvent arriver avant les données d'exécution. Elles ne peuvent toutefois pas inclure les résultats d'exécution tels que les métadonnées, les erreurs, les journaux, les soldes de jetons, les unités de calcul ou les instructions internes.

Comment Blazar collecte et normalise les données

Le traitement des données brutes de Shred présente deux lacunes que la plupart des développeurs ne parviennent pas à combler facilement.

Tout d'abord, les outils. Un flux « SubscribeEntries » brut nécessite une vérification de l gRPC, un décodage bincode, une analyse des transactions et une résolution de la table de correspondance d'adresses. Il faut également savoir exactement ce qui est connu et ce qui ne l'est pas avant l'exécution. La plupart des développeurs d'applications souhaitent simplement un abonnement WebSocket JSON-RPC.

Deuxièmement, le filtrage des comptes nécessite des tables de correspondance. La plupart des transactions de la version 0 d’ Solana utilisent des tables de correspondance d’adresses (ALT). Sans résolution locale des ALT, les filtres de comptes risquent de ne pas détecter une transaction qui n’affecte un compte que par l’intermédiaire d’une table de correspondance. Blazar résout les clés statiques ainsi que les adresses ALT chargées lors du filtrage par compte.

Blazar reçoit un flux de transactions en temps réel ( Solana ) provenant de l'infrastructure de « shred-streaming ». Il convertit ce signal réseau de bas niveau en un abonnement WebSocket JSON-RPC standard. Blazar peut ainsi détecter les transactions avant même que les méthodes RPC habituelles, qui interviennent après l'exécution, ne le fassent. Il envoie ensuite un flux structuré shredTransactionNotification avec le corps de la transaction, le slot, la signature, la version et les adresses chargées résolues, lorsqu'elles sont disponibles.

Considérez le flux comme un signal précoce, transmis selon le principe du « best-effort ». Les notifications arrivent globalement dans l'ordre d'envoi, sans garantie d'ordre strict. Une même transaction peut parfois apparaître plusieurs fois ; par conséquent, effectuez une déduplication par signature si vous avez besoin d'une livraison « exactement une fois ».

Blazar enrichit également les données issues de Shred avant de les envoyer. Au lieu de transmettre un signal brut et d’obliger chaque client à effectuer le même travail, il normalise le format des transactions et résout les adresses des tables de correspondance lorsque cela est possible. Les abonnés bénéficient ainsi d’une vue plus complète des comptes avant l’exécution, sans avoir à exploiter une infrastructure réseau d’ Solana s spécifique ni à développer leur propre analyseur Shred.

Des fragments sur la chronologie des transactions de l'Solana

La visibilité « Shred-time » ajoute un nouveau point, plus précoce, à la chronologie des données « Solana » :

Diffusion de la transaction -> fragments détectés -> entrées décodées -> relecture/exécution -> données RPC traitées/confirmées/finalisées

La plupart des méthodes WebSocket de ` Solana ` s'exécutent après l'exécution ou lors des changements d'état du validateur. shredTransactionSubscribe indique l'étape précédente au cours de laquelle les entrées sont décodées.

Cela ne remplace pas transactionSubscribe. Il s'agit d'un composant complémentaire utilisé en amont de l'exécution, destiné aux workflows pour lesquels il est utile de connaître l'intention de la transaction le plus tôt possible.

Exemples de cas d'utilisation

shredTransactionSubscribe prend en charge des cas d'utilisation que les méthodes post-exécution ne peuvent pas couvrir, et améliore d'autres cas en fournissant des données avant l'exécution.

Intention de transaction précoce

Les systèmes de négociation, les outils d’analyse des DEX, les moteurs de routage et les infrastructures de marché peuvent détecter les transactions avant même leur exécution. Cela permet de mettre en évidence la pression sur les comptes, l’activité des programmes et l’ flow des ordres entrants bien plus tôt que ne le permettent les streams s standard post-exécution.

Surveillance pré-exécution tenant compte des comptes

Un client peut s'abonner aux transactions qui concernent des comptes spécifiques, y compris ceux chargés via des tables de recherche d'adresses. Utilisez cette fonctionnalité pour surveiller les comptes actifs, les pools, les comptes de jetons, les coffres-forts ou les comptes d'état du protocole.

Suivi du cycle de vie au niveau des signatures

À associer avec signatureS'abonner et enableReceivedNotification : true pour savoir à quel moment une signature a été détectée pour la première fois avant l'exécution, puis si elle a abouti ou échoué.

Diagnostics opérationnels

Les équipes chargées du support et de l'infrastructure peuvent répondre à des questions telles que : la transaction a-t-elle été détectée avant son exécution ? A-t-elle été enregistrée plus tard ? N'a-t-elle jamais été détectée ? A-t-elle utilisé des adresses issues d'une table de correspondance ? Cela facilite le diagnostic des problèmes liés au cycle de vie des transactions.

Signaux de vote et de machines à sous

Blazar utilise le même chemin d'ingestion « shred » et « entry » pour les notifications de vote préalables à l'exécution et les signaux de nouvel emplacement. « shredTransactionSubscribe » est la méthode spécifique à la transaction qui s'appuie sur cette même source de données préliminaire.

Présentation de la méthode

shredTransactionSubscribe permet de s'abonner aux notifications de transaction avant exécution provenant de shred et de l'ingestion des entrées. Il ne s'agit délibérément pas d'une option de configuration de transactionSubscribe. La charge utile est différente, car les données proviennent d'une étape différente.

Elle accepte un objet filtre facultatif comme premier et unique paramètre.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "shredTransactionSubscribe",
  "params": [
    {
      "vote": false,
      "signature": "optional-signature",
      "accounts": {
        "include": ["optional-pubkey"],
        "exclude": ["optional-pubkey"],
        "required": ["optional-pubkey"]
      }
    }
  ]
}

Tous les champs sont facultatifs. Chaque liste de comptes (à inclure, à exclure, obligatoires) peut contenir jusqu'à 50 000 entrées.

Filtres pris en charge

vote

• vrai : uniquement des transactions de vote simples.

• false : exclure les transactions de vote simples.

• (omission) : inclure à la fois les transactions avec vote et celles sans vote.

Le filtre de vote utilise la classification des transactions « vote simple » d'Agave. Cela ne signifie pas « toute transaction comportant une instruction du programme Vote ». Les transactions mixtes qui incluent une instruction de vote ne sont pas classées comme des votes simples. voteSubscribe est une méthode distincte dotée de son propre analyseur syntaxique pour les votes par gossip.

signature

• Ne renvoie que la transaction portant la signature indiquée.

comptes.inclure

• Fournit les opérations qui concernent au moins un compte répertorié.

• Fait correspondre les clés de compte statiques aux adresses résolues chargées via ALT.

comptes.exclure

• Supprime les transactions qui concernent l'un des comptes répertoriés.

• Fait correspondre les clés de compte statiques aux adresses résolues chargées via ALT.

comptes.obligatoires

• Ne renvoie que les opérations qui concernent tous les comptes répertoriés.

• Fait correspondre les clés de compte statiques aux adresses résolues chargées via ALT.

Paramètres non pris en charge

Les paramètres « commitment », « encoding », « transactionDetails », « showRewards », « maxSupportedTransactionVersion » et « failed » ne sont pas pris en charge. Les transactions dérivées de « shred » sont des charges utiles JSON avant exécution ; elles ne comportent donc ni résultats d'exécution ni niveaux de validation.

Exemples de demandes

S'abonner à toutes les transactions sans vote préalables à l'exécution

{
  "jsonrpc": "2.0",
  "id": 11,
  "method": "shredTransactionSubscribe",
  "params": [
    { "vote": false }
  ]
}

S'abonner à une signature spécifique

{
  "jsonrpc": "2.0",
  "id": 12,
  "method": "shredTransactionSubscribe",
  "params": [
    {
      "signature": "5VERv8NMvzbJMEkV8xnqLkEaWRtSz9CosKDYjCJjBRnbJLgp8uirBgmQpjKhoR4tjF3ZpRzrFmBV6UjKdiSZkQUW"
    }
  ]
}

S'abonner aux opérations portant sur un compte

{
  "jsonrpc": "2.0",
  "id": 13,
  "method": "shredTransactionSubscribe",
  "params": [
    {
      "accounts": {
        "include": ["TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA"]
      }
    }
  ]
}

Exiger plusieurs comptes et en exclure un autre

{
  "jsonrpc": "2.0",
  "id": 14,
  "method": "shredTransactionSubscribe",
  "params": [
    {
      "accounts": {
        "required": [
          "AccountA11111111111111111111111111111111111",
          "AccountB22222222222222222222222222222222222"
        ],
        "exclude": [
          "AccountC33333333333333333333333333333333333"
        ]
      }
    }
  ]
}

Réponse concernant l'abonnement

En cas de réussite, le serveur renvoie un identifiant d'abonnement. Utilisez cet identifiant pour vous désabonner.

{
  "jsonrpc": "2.0",
  "result": 123,
  "id": 14
}

Se désabonner

{
  "jsonrpc": "2.0",
  "id": 15,
  "method": "shredTransactionUnsubscribe",
  "params": [123]
}

Forme de la notification

Une notification utilise l'enveloppe PubSub JSON-RPC standard, mais la valeur de la transaction interne correspond à des données préalables à l'exécution.

{
  "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
  }
}

Exemple de transaction versionnée avec des adresses chargées

Pour les transactions v0, la propriété `transaction.message.addressTableLookups` conserve les références aux tables de correspondance, tandis que la propriété `value.loadedAddresses` contient les clés publiques résolues.

{
  "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 ne parvient pas à trouver une ou plusieurs tables de correspondance dans le cache, les notifications v0 suivantes sont générées :

« loadedAddresses » : null

Même avec la phase de préchauffage au démarrage et les mises à jour en temps réel via Solana gRPC , une table qui vient d'être étendue peut entrer en conflit avec le cache. Lorsque cela se produit, Blazar définit `loadedAddresses: null` pour les transactions v0 dont les adresses chargées sont incomplètes, afin que la notification reste exacte.

Les transactions héritées ne prennent pas en compte les `loadedAddresses`.

Ce qui n'est pas inclus dans la charge utile

Comme il s'agit de données antérieures à l'exécution, la notification ne comprend pas :

• méta

• err

• journaux

• instructions internes

• soldes avant/après

• soldes des jetons avant et après

• unités de calcul consommées

• données de retour

• récompenses

• indice de la dernière transaction dans le bloc

shredTransactionSubscribe est une méthode d'observation précoce, et non une méthode de résultat d'exécution.

Pour commencer

1. Connectez-vous à votre tableau de bordQuicknode .

2. Sélectionnez votre Solana endpoint.

3. Copiez l'URL de votre endpoint WSS (wss://votre-endpoint-name.solana-mainnet.quiknode.pro/abc123) et connectez-vous à l'aide de votre code client WebSocket existant.

4. Consultez les exemples de requêtes ci-dessus pour envoyer une requête `shredTransactionSubscribe` avec un filtre facultatif.

5. Traiter les messages « shredTransactionNotification » dès leur réception.

Vous découvrez les WebSockets d'Solana ? Le guide « Comment créer des abonnements WebSocket dans Solana » vous fournit toutes les informations nécessaires.

Pour les équipes qui ont besoin d'un streaming d'Solana s à faible latence allant au-delà des WebSockets, le produit d'QuicknodeSolana gRPC offre une streams en temps réel compatible avec l'Yellowstone, au sein du même écosystème endpoint .

Foire aux questions

La fonction `shredTransactionSubscribe` correspond-elle à la fonction `transactionSubscribe` avec un engagement plus précoce ?

La transaction « transactionSubscribe » est post-exécution et contient des métadonnées sur l'état de la transaction. La transaction « shredTransactionSubscribe » est pré-exécution et ne comporte ni journaux, ni métadonnées, ni erreurs, ni soldes, ni unités de calcul.

Une transaction de destruction de documents peut-elle échouer par la suite ?

Oui. Une transaction observée à partir de fragments peut par la suite échouer, expirer ou ne pas apparaître dans le registre final. Cette méthode constitue un signal d'observation précoce, et non un signal de finalité.

Les filtres de comptes incluent-ils les comptes de la table de recherche d'adresses ?

Oui. Les filtres de compte font correspondre les clés de compte statiques ainsi que les adresses chargées via ALT et résolues à partir du cache de la table de recherche locale de Blazar.

Que se passe-t-il lorsqu'un ALT est désactivé ?

Une table ALT désactivée peut toujours être utilisée pendant la période de temps de recharge de ses SlotHashes. Blazar résout les tables désactivées pendant cette période de temps de recharge et traite les tables dont l'expiration est avérée comme non résolues.

À qui s'adresse cette méthode ?

À utiliser lorsque l'intention initiale d'une transaction prime sur le résultat de l'exécution : analyse à faible latence, surveillance de l'activité des comptes, diagnostics du cycle de vie des transactions, infrastructure de négociation et observabilité avant exécution.

À qui cette méthode est-elle déconseillée ?

Ne l'utilisez pas si vous avez besoin du statut définitif d'une transaction, des journaux, des soldes, des variations de solde des jetons, des unités de calcul, des récompenses ou de la composition des blocs finalisés. Utilisez pour cela les méthodes RPC/WebSocket post-exécution.

En résumé

Jusqu'à présent, les données de transaction préalables à l'exécution nécessitaient une infrastructure réseau et d'Solana s sur mesure : des clients « gRPC », un décodage « bincode » et des pipelines d'analyse « shred ». La fonctionnalité « shredTransactionSubscribe » de Blazar rend tout cela superflu. Elle transmet l'intention de transaction avant l'exécution sous la forme d'un abonnement WebSocket JSON-RPC standard.

Cette fonctionnalité est désormais disponible sur tous les sites WebSocket Blazar d'Quicknode : endpoint . Connectez-vous à votre tableau de bordQuicknode pour commencer, ou créez un compte Quicknode si vous n'en avez pas encore.

Comme shredTransactionSubscribe est actuellement en version bêta, nous vous invitons à nous faire part de vos commentaires et suggestions. N'hésitez pas à nous envoyer un e-mail à l'adresse solana@quicknode.com ou à nous contacter sur Discord.