Que sont les Preconfirmations (Preconfs) sur Solana ?

Le cycle de vie d’une transaction dans le leader

Voici une présentation volontairement ciblée du cycle de vie d’une transaction au sein du leader, dans le contexte des Preconfirmations et de l’observabilité. Pour une présentation complète du cycle de vie d’une transaction sur Solana, consultez notre présentation technique de la machine virtuelle Solana (SVM).

Avant le leader

Sur Solana, les transactions signées sont envoyées directement au producteur de blocs (c’est-à-dire au leader) ainsi qu’aux prochains leaders. Elles arrivent via QUIC, avec une capacité de connexion allouée selon la pondération par stake. Les transactions relayées via des connexions stakées ont donc bien plus de chances d’être acceptées en période de forte charge.

À ce stade, une transaction n’est visible que par son expéditeur et par le nœud RPC ou le service d’acheminement des transactions qui la relaie vers le leader actuel et les prochains leaders. 

À ce stade, il est impossible de connaître le sort de la transaction. 

Étape 1 : ingestion et SigVerify

La Transaction Processing Unit (TPU) du leader reçoit les transactions entrantes sous forme de paquets, les désérialise, vérifie leurs signatures et élimine les doublons. En période de forte charge, les paquets malformés et les transactions indésirables sont abandonnés avant de consommer davantage de ressources.

Une transaction ingérée et validée lors de l’étape SigVerify n’est encore qu’une candidate. Des milliers de transactions candidates arrivent à chaque slot, et beaucoup ne sont jamais incluses dans un bloc.

Cette étape n’offre aucune observabilité utile, car diffuser ces transactions reviendrait à diffuser du bruit. 

Étape 2 : le planificateur

La production des blocs a lieu lors de la Banking Stage. Depuis Agave 1.18, son cœur est le planificateur central : un thread unique disposant d’une vue globale de toutes les transactions en attente et distribuant le travail à un pool de workers d’exécution. L’idée est qu’un thread unique disposant de tout le contexte peut remplir les blocs avec bien moins de conflits de verrouillage que n threads se disputant avidement une file partagée.

En substance, le planificateur fait passer les transactions par trois étapes principales :

1. Mise en mémoire tampon et priorisation

Les transactions entrantes arrivent dans le composant receive and buffer du planificateur, où la priorité et le coût de chacune sont calculés avant son insertion dans un conteneur ordonné par priorité.

À ce stade, une transaction reste l’une des milliers de « possibilités » susceptibles d’être évincées si le tampon se remplit de tâches plus prioritaires.

2. Planification 

La boucle de contrôle du contrôleur du planificateur extrait régulièrement du conteneur les transactions les plus prioritaires, recherche d’éventuels conflits de verrouillage de comptes et les regroupe en lots pour leur exécution.

Depuis Agave 2.3, l’algorithme de planification fourni est le greedy scheduler. Il remplace l’ancienne conception prio-graph après que des tests ont montré que cette approche remplissait les blocs avec moins de surcharge.

3. Distribution 

Le lot planifié est envoyé par un canal à un worker d’exécution. Le leader a désormais engagé de véritables ressources — un thread de worker, des verrous de comptes et une place dans le bloc en cours d’assemblage — pour cette transaction précise.

À ce stade, la transaction est toujours en attente. Le leader prévoit de l’exécuter, mais rien n’a encore été lancé : il n’y a donc aucun résultat à communiquer. Les Preconfirmations arrivent une étape plus tard.

En quoi l’architecture du planificateur de Firedancer diffère-t-elle de celle d’Agave ?

Firedancer atteint le même point avec une architecture légèrement différente. Au lieu de threads partageant de la mémoire, Firedancer exécute des tiles isolées, reliées par des files en mémoire partagée, et sa logique de planification réside dans la pack tile. 

La pack tile conserve toutes les transactions en attente, suit les comptes détenus par chaque bank tile et sélectionne des transactions sans conflit maximisant les frais pour former des microblocs, qu’elle transmet aux bank tiles pour exécution. 

Le même transfert a lieu : les transactions sélectionnées passent de la logique d’empaquetage aux unités d’exécution, où leurs résultats sont déterminés.

Étape 3 : exécution

Les workers d’Agave, ou les bank tiles de Firedancer, exécutent le lot de transactions planifié sur la banque actuelle, chargent les comptes, exécutent les programmes et valident leurs résultats.

C’est aussi à ce stade qu’une transaction planifiée peut échouer pour diverses raisons : fonds insuffisants, erreur de programme, contrôle du slippage qui provoque une annulation ou autres conditions d’exécution. Dans tous les cas, le résultat n’existe encore que localement, sur la machine du leader.

C’est à cet instant qu’une preconfirmation est émise. Le leader diffuse chaque transaction dès son exécution, accompagnée de son statut, avant que les résultats ne soient enregistrés dans une entrée et bien avant que toute donnée du bloc quitte la machine.

C’est le premier moment de tout le cycle de vie où le résultat d’une transaction existe et peut être communiqué. En amont de l’exécution, il n’existe qu’un ensemble de candidates en attente, sans aucun résultat à diffuser. En aval, les informations sont déjà empaquetées dans le bloc qui se propage vers le reste du réseau.

L’exécution est donc le seul point où un signal précoce de ce type peut exister. C’est pourquoi chaque preconfirmation contient le résultat réel de la transaction plutôt qu’une prédiction.

Une preconfirmation ne peut toutefois pas vous indiquer si le bloc contenant la transaction deviendra canonique. Ce bloc n’a pas encore été découpé en shreds, propagé ni soumis au vote. 

C’est pourquoi les Preconfirmations constituent un signal, et non une garantie.

Étape 4 : Proof of History et entrées

Les lots exécutés sont enregistrés dans le flux Proof of History afin de produire des entrées, c’est-à-dire des ensembles hachés de transactions intégrés à l’horloge vérifiable du leader. Les entrées constituent le format natif du registre, mais n’existent encore que sur la machine du leader.

L’observabilité est pratiquement nulle pour quiconque se trouve en dehors du leader.

Notez que Proof of History sera supprimé avec la mise à jour Alpenglow, car Rotor et Votor éliminent le besoin d’une horloge décentralisée sur Solana. Le modèle des Preconfirmations reste inchangé : les leaders continueront d’exécuter les transactions avant de les diffuser. Le premier signal observable restera donc le résultat de leur exécution locale par le leader. 

Étape 5 : découpage en shreds et diffusion

Les entrées sont découpées en shreds, c’est-à-dire en fragments de la taille d’une MTU, puis encodées avec un code d’effacement pour résister aux pertes. Ces shreds sont signés et diffusés via l’arbre pondéré par stake de Turbine.

C’est ici que l’observabilité devient pleinement accessible. Les shreds sont les premiers artefacts d’un bloc donné à quitter la machine du leader. C’est pourquoi tous les autres produits de données précoces sur Solana, y compris les flux de shreds, commencent ici. Quiconque reconstruit des transactions à partir de shreds est rapide par rapport aux niveaux d’engagement RPC, mais en retard par rapport à une preconfirmation, puisque le leader a exécuté la transaction avant même que les shreds existent. 

Le processus se poursuit ensuite : les validateurs rejouent le bloc, votent, et les transactions progressent à travers les niveaux d’engagement processed, confirmed et finalized. 

Où se situent les Preconfirmations dans l’échelle de latence ?

Les Preconfirmations sont le signal le plus rapide sur Solana, devant tous les autres, notamment les shreds bruts et décodés, LaserStream et les autres méthodes de streaming de données. 

Les preconfs se comprennent toutefois mieux comme un échelon d’une échelle de latence, où chaque échelon sacrifie une part d’exhaustivité ou de certitude en échange d’une observation plus précoce.

Du plus précoce au plus tardif :

Deux observations ressortent de ce tableau. 

Premièrement, tous ces signaux sont complémentaires plutôt que de se remplacer directement les uns les autres.

Par exemple, les Preconfirmations indiquent ce qu’un leader vient d’exécuter avant que le réseau ne le sache, tandis qu’un message de LaserStream indique ce qui s’est produit avec toutes les métadonnées.

Les systèmes en production doivent généralement utiliser les deux : agir sur les Preconfirmations et employer les signaux en aval pour la vérification.  

Deuxièmement, l’écart entre les échelons n’est pas uniforme.

Passer des flux processed aux shreds permet de gagner quelques millisecondes, tandis que passer des shreds aux Preconfirmations évite le reste du pipeline de production du bloc — à savoir l’enregistrement des entrées, le découpage en shreds et la propagation — car le point d’observation passe du premier artefact public du bloc à des résultats qui n’existent qu’au sein du leader. 

Ainsi, les Preconfirmations sont environ 5 à 50 millisecondes plus rapides que les shreds. 

Le modèle de confiance des Preconfirmations : un signal, pas une garantie

Tout ce que promet une preconfirmation tient en une seule phrase : le leader a exécuté cette transaction avec ce résultat. Tout ce qu’une preconf ne promet pas découle de cette même phrase.

Une transaction exécutée n’est pas encore une transaction aboutie, ce qui signifie que le bloc qui la contient n’a pas encore été découpé en shreds, propagé ni soumis au vote. Ce bloc peut encore être ignoré ou exclu par un fork avant d’être confirmé par le réseau. Presque toutes les transactions préconfirmées aboutissent correctement onchain. Toutefois, tout système agissant sur la base des Preconfirmations doit confirmer les résultats par d’autres contrôles d’observabilité avant de les considérer comme définitifs.

La couverture est également partielle par conception. Les Preconfirmations n’existent que pour les slots dont le leader transmet à Helius son flux de transactions planifiées. La couverture évolue donc avec la part du stake du réseau qui participe, et le flux n’est pas nécessairement continu.

Si des services ont absolument besoin d’une couverture continue, ils doivent envisager de se rabattre sur LaserStream ou Shred Delivery en cas d’interruption.

Comme les Preconfirmations sont émises après l’exécution, un abonné voit des résultats déjà déterminés, et non un flux d’ordres en attente susceptible d’être exploité. Cela signifie que la fenêtre permettant de devancer cette transaction dans le bloc est déjà fermée. C’est la différence essentielle entre vendre une visibilité précoce et divulguer le flux d’ordres avant sa planification : la première permet aux abonnés de réagir plus vite que le reste du réseau, tandis que la seconde leur permettrait d’agir contre les transactions mêmes qui sont diffusées. Les Preconfirmations relèvent strictement du premier cas.

Le signal indique clairement ce qu’il est : aucune garantie économique ne soutient une preconfirmation, et aucune n’est revendiquée. Le leader communique ses résultats locaux, mais ne met rien en jeu quant à leur concrétisation. Pour les stratégies auxquelles servent les Preconfirmations, c’est le bon compromis.

Un bot de liquidation, par exemple, n’a pas besoin d’une promesse infaillible, assortie d’un slashing, qu’une transaction aboutira. Il doit connaître le résultat d’une transaction donnée quelques millisecondes avant ses concurrents.

Comment fonctionnent les Preconfirmations de Helius ?

Les Preconfirmations de Helius sont fournies via un seul abonnement WebSocket. Un client peut se connecter à notre endpoint Gatekeeper (c’est-à-dire wss://beta.helius-rpc.com) et envoyer une requête preconfSubscribe :

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "preconfSubscribe",
  "params": [
    {
      "failed": false,
      "regionInclude": ["ewr", "fra"],
      "accountInclude": ["TARGET_WALLET_ADDRESS"],
      "accountExclude": [],
      "accountRequired": []
    }
  ]
}

Les filtres sont appliqués côté serveur selon le compte — inclusion, exclusion et obligation —, la région et le statut, avec prise en charge des tables de recherche (LUT). Ainsi, l’abonné ne reçoit et ne paie que les transactions planifiées pertinentes pour sa stratégie. 

Comme les Preconfirmations sont émises après l’exécution, le filtre de statut s’applique à des résultats réels : failed: false, ce qui signifie que les transactions ayant échoué ne sont jamais diffusées ni facturées.

La tarification repose sur des crédits, comme pour les autres abonnements WebSocket de Helius : 10 crédits par message, avec un message par transaction diffusée. Le service est disponible à partir des plans Professional. 

Ensuite, chaque transaction planifiée correspondant aux filtres arrive sous la forme d’une trame binaire compacte. Celle-ci comprend un en-tête fixe de 18 octets contenant la version de la transaction, le slot dans lequel elle est planifiée, son index dans le slot et son statut, suivi de l’ensemble des octets de la transaction. 

Le format est volontairement minimaliste, car un en-tête fixe peut être décodé en quelques nanosecondes, sans avoir à analyser du JSON sur le chemin critique. Le seul JSON nécessaire à cet échange est l’accusé de réception de l’abonnement, pour plus de commodité. 

Notez qu’une preconfirmation ne représente que la moitié d’une opération. Voir une transaction en premier n’a d’intérêt que si la réponse aboutit en premier. C’est pourquoi nous avons également lancé Sender Max, le niveau le plus performant de Helius Sender.

Sender Max achemine une soumission — c’est-à-dire une transaction unique ou un bundle atomique comptant jusqu’à quatre transactions — par toutes les voies à haut débit disponibles et l’insère dans un tampon de pourboires prioritaires qui favorise les pourboires les plus élevés. Le pourboire minimal est de 0,001 SOL.

Recevez des signaux avec preconfSubscribe, faites aboutir vos transactions avec Sender Max.  

Que pouvez-vous créer avec les Preconfirmations ?

Toute stratégie dont les bénéfices diminuent à chaque milliseconde écoulée entre la décision d’une transaction et son observation profite des preconfs. Cela comprend notamment les cas d’utilisation suivants : 

Sniping

Les créations de nouveaux pools et les lancements de tokens sont visibles dès que la transaction de déploiement est exécutée au sein du leader. Un sniper qui utilise les Preconfirmations réagit alors que ceux qui surveillent les shreds attendent encore l’arrivée des premiers fragments du bloc. 

Copy trading

Les mouvements d’un wallet cible apparaissent dans le flux de Preconfirmations dès que le leader les exécute. Le filtrage d’une adresse cible avec accountInclude transforme le flux en source miroir dédiée, offrant des informations sur les mouvements avant les autres adeptes du copy trading.

Liquidations

Une mise à jour d’oracle qui rend une position insolvable est détectable dès son exécution. Le bot de liquidation qui la voit à cet instant déclenche tout un pipeline avant celui qui surveille les shreds ou un niveau d’engagement processed. Les Preconfirmations sont donc extrêmement importantes pour les activités de liquidation.

Market making et propAMMs

Le flux entrant visible au moment de l’exécution donne aux propAMMs et aux autres systèmes de cotation une longueur d’avance pour réévaluer ou retirer les cotations obsolètes avant que ce flux ne devienne public. 

Dans chaque cas, les Preconfirmations font passer le point de réaction de la stratégie d’« après que le réseau en a pris connaissance » à « au moment où le leader exécute ».

Gagnez des revenus en transmettant les Preconfirmations

La couverture des Preconfirmations repose sur un effet de réseau, avec les validateurs du côté de l’offre. Tout validateur peut transmettre son flux à Helius et générer des revenus en le faisant. Il transforme ainsi un sous-produit de la production de blocs en source de revenus, qu’il monétise ou non sa position par ailleurs.

Plus le stake participant est important, plus la couverture est étendue. Les validateurs souhaitant participer peuvent nous contacter et trouver davantage d’informations dans notre documentation sur les Preconfirmations pour les validateurs. 

Quelle est la différence entre les preconfs Ethereum et les preconfs Solana ?

Les Preconfirmations Ethereum sont des engagements de proposeurs qui garantissent qu’une transaction sera incluse dans un bloc futur. Les Preconfirmations Solana sont, quant à elles, des signaux de transaction onchain en temps réel pour les transactions que le leader vient d’exécuter localement dans le bloc actuel. Les premières permettent de savoir plus tôt, tandis que les secondes permettent de voir plus tôt.

Preconfirmations Ethereum

Sur Ethereum, les Preconfirmations — souvent appelées based preconfs dans les travaux de recherche, selon une conception formulée pour la première fois par Justin Drake en 2023 — sont des engagements d’inclusion. Avant son slot, un proposeur promet qu’une transaction sera incluse dans un bloc futur, cette promesse étant soutenue par un mécanisme économique comme le slashing. 

Plusieurs implémentations sont déjà opérationnelles : 

• MEV-Commit de Primev, une place de marché où les wallets, les searchers et les protocoles d’intention proposent des offres aux fournisseurs d’exécution — constructeurs de blocs et séquenceurs — en échange d’engagements
• ETHGas, un réseau de Preconfirmations assorti de garanties économiques
• Bolt de Chainbound, qui propose des engagements de proposeurs sans permission et compatibles avec MEV-Boost

Plus important encore, les Preconfirmations Ethereum :

• Concernent votre propre transaction
• Sont émises avant l’exécution
• Sont optimisées pour la certitude

Les Preconfirmations Ethereum garantissent que votre transaction aboutira avant même qu’elle n’aboutisse réellement.

Ethereum a besoin de ce mécanisme en raison de la manière dont ses blocs sont construits. La plupart des proposeurs délèguent la construction des blocs aux enchères juste à temps via MEV-Boost. Rien concernant un bloc ne peut donc être promis de manière crédible avant la clôture de cette enchère. Solana n’a toutefois jamais connu cette lacune. Le calendrier des leaders est connu à l’avance, il n’existe pas de mempool, et un seul leader reçoit, ordonne, exécute et diffuse son bloc en continu pendant le slot. Le signal précoce qu’Ethereum doit fabriquer à l’aide d’une infrastructure économique existe nativement dans le pipeline de production des blocs de Solana ; il suffisait de l’exposer.

Preconfirmations Solana

Les Preconfirmations Solana sont des signaux onchain en temps réel plutôt qu’une promesse future : le leader signale les transactions qu’il a déjà exécutées avant leur propagation au reste du réseau.

Plus important encore, les Preconfirmations Solana :

• Incluent les transactions de tout le monde
• Sont émises après l’exécution
• Sont optimisées pour la latence

Les Preconfirmations Solana vous permettent de voir les transactions exécutées quelques millisecondes avant qu’elles ne soient observées sur l’ensemble du réseau via les shreds ou les requêtes RPC aux niveaux d’engagement standard.

L’équivalent le plus proche sur Solana des Preconfirmations Ethereum réservant de l’espace dans un bloc est la place de marché d’unités de calcul de Raiku pour les Ahead-of-Time (AOT) Transactions, qui permet aux applications de réserver une inclusion garantie dans de futurs blocs.

Conclusion

Chaque transaction sur Solana passe par un instant précis où son sort bascule de l’inconnu au décidé : le moment où le leader l’exécute. Les Preconfirmations correspondent à cet instant, diffusé avant que le reste du réseau puisse le voir. Elles se situent au-dessus des shreds dans l’échelle de latence, car elles observent les résultats d’exécution du leader plutôt que les artefacts publics du bloc. Les Preconfirmations sont un signal, pas une garantie, car un bloc n’est considéré comme canonique qu’après sa confirmation par le réseau.

Pour les systèmes sensibles à la latence — snipers, adeptes du copy trading, liquidateurs, market makers et searchers —, abonnez-vous avec preconfSubscribe, filtrez les comptes pertinents, répondez aux signaux avec Sender Max et vérifiez les résultats à l’aide des contrôles d’engagement standard.

La référence complète de l’abonnement, le format des messages et les exemples d’intégration sont disponibles dans notre documentation sur les Preconfirmations.