Qu’est-ce que preconfSubscribe ?
preconfSubscribe est une méthode WebSocket de Helius qui diffuse les Preconfirmations, c’est-à-dire les transactions livrées avant d’être regroupées dans des entrées et découpées en shreds. Il s’agit du signal de transaction offrant la plus faible latence chez Helius. Un même abonnement fournit à la fois les Preconfirmations de Helius, émises dès que le leader exécute la transaction et accompagnées de son statut d’exécution, et les Preconfirmations BAM provenant des validateurs qui exécutent le client Block Assembly Marketplace de Jito, émises lorsque le validateur s’engage à exécuter la transaction. L’accès est disponible avec tous les forfaits payants. Consultez la section Tarification.
Le flux n’est pas continu. La couverture évolue avec la part de mise en avant
pour Helius ou exécutant BAM, donc attendez-vous à des créneaux sans messages — gérez
ces lacunes avec souplesse. Voir Couverture.
preconfSubscribe est servi depuis wss://beta.helius-rpc.com — le point de terminaison Gatekeeper Helius — plutôt que mainnet.helius-rpc.com. Authentifiez-vous avec votre clé API en tant que paramètre de requête.
Le nom d’hôte
beta fait référence au déploiement de Gatekeeper,
non à la maturité des préconfirmations. Les préconfirmations sont lancées sur le
point de terminaison Gatekeeper en premier ; cela deviendra le point de terminaison standard à mesure que Helius
migre le trafic vers Gatekeeper.S’abonner
Envoyez une requête JSON-RPC avec la méthodepreconfSubscribe. Le serveur répond avec un identifiant d’abonnement, puis diffuse une notification pour chaque transaction. Passez un filtre optionnel comme premier élément params pour ne recevoir que les transactions correspondantes ; omettez params pour recevoir le flux complet de Helius et BAM.
Réponse d’abonnement
result — c’est l’identifiant d’abonnement que vous utilisez pour vous désabonner. Après cet accusé de réception, les notifications sont diffusées sous forme de trames binaires (voir ci-dessous).
Filtrage
Par défaut,preconfSubscribe diffuse chaque transaction des deux sources. Pour restreindre le flux, passez un objet filtre comme premier élément d’params. Le filtrage se fait côté serveur, vous ne payez donc que pour et ne recevez que les transactions qui vous intéressent.
params) correspond à chaque transaction des deux sources.
Règles de filtrage :
- Tous les prédicats sont combinés par un ET logique et évalués dans l’ordre
includeSource→failed→regionInclude→signatures→accountExclude→accountRequired→accountInclude→signerExclude→signerInclude→instructions. - Les préconfirmations BAM dont le statut est inconnu ignorent le filtre
failed. Les préconfirmations Helius dont le statut est inconnu ne correspondent pas à un filtrefailedexplicite. includeSourcedoit être un tableau contenant uniquementheliusetbam. Une valeur non valide renvoie l’erreur JSON-RPC-32602(paramètres non valides).- Les comptes sont des clés publiques encodées en base58. Une valeur non valide renvoie l’erreur JSON-RPC
-32602(paramètres non valides). - Chaque liste de comptes ou de signataires est limitée à 10 000 entrées.
signaturesest limité à 1 000 entrées.
Le filtre obsolète
includeBam reste disponible à des fins de rétrocompatibilité.
includeBam: false équivaut à includeSource: ["helius"]. includeBam: true ou
l’omission du champ sélectionne les deux sources. N’envoyez pas includeBam et
includeSource ensemble.Filtrage par signataire et par signature
UtilisezsignerInclude pour sélectionner les transactions signées par un compte spécifique. Utilisez signerExclude pour exclure les transactions signées par l’un des comptes répertoriés. Un compte référencé n’est pas considéré comme un signataire.
Utilisez signatures lorsque vous connaissez déjà les transactions à suivre. Le filtre vérifie la première signature de la transaction, qui est celle utilisée par les méthodes RPC de Solana. Le filtre ne peut pas être modifié après votre abonnement. Créez donc un nouvel abonnement pour suivre de nouvelles signatures.
Filtrage des instructions
Utilisezinstructions pour sélectionner les instructions de niveau supérieur selon le programme et les données d’instruction. Chaque filtre d’instructions prend en charge les champs suivants :
Chaque entrée
memcmp accepte l’encodage base58, base64 ou hex. La valeur par défaut est base58. Une transaction correspond lorsqu’une instruction de niveau supérieur satisfait toutes les conditions d’un filtre d’instructions.
La requête suivante sélectionne les instructions buy de pump.fun selon leur discriminateur Anchor :
memcmp par filtre d’instructions. Chaque valeur memcmp doit être décodée en 1 à 128 octets. Le décalage de fin d’un memcmp et dataSize ne doivent pas dépasser 4 096 octets.
Résolution des tables de recherche d’adresses (ALT)
Les filtres de comptes ne se limitent pas aux clés de comptes statiques de la transaction : Helius résout côté serveur les tables de recherche d’adresses v0. Ainsi,accountInclude, accountExclude et accountRequired correspondent également aux comptes chargés par une transaction via une ALT.
Vous pouvez donc filtrer sur n’importe quel compte auquel une transaction accède, même s’il apparaît uniquement derrière une table de recherche. Vous n’avez pas besoin de gérer les correspondances ALT ni de résoudre vous-même les tables. Transmettez simplement la clé publique du compte. Helius effectue la résolution avant d’appliquer le filtre.
Filtrage par région
UtilisezregionInclude pour recevoir uniquement les transactions provenant de régions spécifiques. Transmettez un ou plusieurs codes de région. Une transaction est acceptée lorsque sa région d’origine correspond à l’un de ces codes.
sgp et dal.
Codes de région valides :
Lorsque
regionInclude est défini, les transactions qui ne contiennent aucune information de région sont ignorées. Un code de région non reconnu renvoie l’erreur JSON-RPC -32602 (paramètres non valides).Charge utile des notifications
Les notifications sont transmises sous forme de trames WebSocket binaires et non en JSON. Les préconfirmations Helius et BAM utilisent la même structure. Chaque trame suit une structure d’octets compacte contenant une seule transaction :
La charge utile ne comporte aucun champ indiquant la source. Ne déduisez pas une origine BAM de
tx_index = 0, car d’autres sources peuvent également indiquer 0.
Distinguer les deux sources
Comme il n’existe aucun champ indiquant la source, vous ne pouvez pas identifier un message arbitraire comme provenant de Helius ou de BAM. L’octetstatus fournit une classification à sens unique :
statusvaut0ou1— le message est une préconfirmation Helius et la transaction a été exécutée. BAM n’indique jamais ces valeurs.statusvaut2— la source est ambiguë : il peut s’agir d’une préconfirmation BAM ou d’une préconfirmation Helius dont le statut d’exécution n’était pas disponible.
regionInclude est un filtre d’abonnement et non un champ de la charge utile. Il ne peut donc pas être lu pour chaque message.
Si vous souhaitez que chaque message d’un flux contienne le même type d’indication, définissez includeSource: ["helius"] ou includeSource: ["bam"]. Un flux Helius uniquement contient les préconfirmations émises lors de l’exécution par le leader.
Une préconfirmation est un signal précoce, pas une garantie. La transaction n’a pas
encore été enregistrée on-chain et peut toujours être abandonnée. De plus, le statut
d’exécution d’une préconfirmation Helius reflète le résultat local du leader, qui n’est pas définitif tant que
le bloc n’est pas confirmé. Confirmez l’enregistrement avec les vérifications standard du niveau de commitment
avant de le considérer comme définitif.
Décodage de la transaction
Les octets de la transaction sont transférés exactement tels que le validateur les a sérialisés, dans l’encodage binaire standard correspondant à la version de la transaction. Les transactions legacy et v0 utilisent une structure commençant par les signatures, produite parbincode. Les transactions v1 (SIMD-0385) utilisent une structure commençant par le message et plaçant les signatures à la fin. bincode échoue donc avec les charges utiles v1. Utilisez un décodeur compatible avec toutes les versions :
- Rust :
agave-transaction-viewanalyse sur place les transactions legacy, v0 et v1, sans copie intermédiaire. Cette option est recommandée.wincode, le sérialiseur compatible avec bincode utilisé par les SDK Solana actuels, décode également la v1 dansVersionedTransaction. - JavaScript / TypeScript : assurez-vous que la version de votre bibliothèque prend en charge les transactions v1. Les anciennes implémentations de
VersionedTransaction.deserializene gèrent que les transactions legacy et v0. Utilisez@solana/kit8.0+ ou@solana/web3.jsv3. Consultez Prise en charge des transactions v1.
Notifications en double
Les préconfirmations Helius et BAM sont dédupliquées par source, et non entre les sources. Une faible proportion de transactions atteint Helius par les deux sources. Vous pouvez donc recevoir deux fois la même signature, et les deux exemplaires peuvent indiquer des slots différents. Dédupliquez les transactions par signature côté client et rendez idempotentes les actions déclenchées par les transactions, afin qu’une seconde notification ne déclenche pas deux fois la même action. Confirmez l’exécution et l’enregistrement à l’aide des vérifications standard du niveau de commitment.Exemple
Désabonnement
Pour ne plus recevoir de notifications, appelezpreconfUnsubscribe avec l’identifiant d’abonnement renvoyé par preconfSubscribe.
Tarification
Les Preconfirmations sont disponibles avec tous les forfaits payants : Developer, Business, Professional et Enterprise. Les forfaits gratuits ne sont pas éligibles. Consultez la section Crédits pour plus de détails. Les slots dans lesquels aucun message n’est livré ne coûtent aucun crédit, même lorsqu’ils bénéficient d’une couverture des Preconfirmations. Lorsqu’un slot livre au moins un message, chaque abonnementpreconfSubscribe ouvert est facturé selon le montant le plus élevé entre 300 crédits et 10 crédits par message livré.
Les slots non couverts ne coûtent rien. Consultez la section Tarification pour connaître les conditions de facturation selon la source et la région.
Chaque abonnement simultané est facturé indépendamment dès qu’il reçoit au moins un message. Fermez les abonnements dont vous n’avez plus besoin avec
preconfUnsubscribe. Avec includeSource: ["helius"], les slots couverts uniquement par BAM sont exclus de la facturation. Lorsque regionInclude est défini, les slots couverts en dehors des régions sélectionnées ne coûtent rien pour cet abonnement ; les slots correspondants ne sont facturés que si l’abonnement reçoit au moins un message.
La facturation s’effectue par message, et non par signature unique. Une transaction transmise à la fois par Helius et BAM est comptabilisée deux fois. Définissez includeSource: ["helius"] si vous souhaitez uniquement les préconfirmations Helius.
Preconfirmations est un nouveau produit et sa tarification est susceptible de changer.
Ressources associées
Preconfirmations Overview
Découvrez ce que sont les Preconfirmations et où elles se situent dans le pipeline du validateur.
transactionSubscribe
Diffusez les transactions avec le niveau d’engagement confirmed à l’aide de filtres avancés.
preconfSubscribe API reference
Consultez les paramètres de requête, les champs de filtre et la structure binaire des notifications.