Que sont les niveaux d’engagement de Solana ?

Que sont les niveaux d’engagement de Solana ?

Les niveaux d’engagement de Solana constituent une méthode standardisée pour mesurer le consensus du réseau sur un bloc ou une transaction. Lorsque vous interrogez un nœud RPC Solana sur le statut d’une transaction ou les données d’un compte (par exemple, getTransaction), vous pouvez préciser un niveau d’engagement pour indiquer le degré de finalisation souhaité. Solana utilise ce niveau pour permettre aux clients d’équilibrer latence et certitude : un niveau plus faible fournit un retour plus rapide, tandis qu’un niveau plus élevé donne aux développeurs davantage de garanties que l’état ne sera pas annulé.

Solana définit trois niveaux d’engagement principaux, par ordre décroissant de finalité :

Finalized

Le niveau de certitude le plus élevé. Il indique que le bloc a été confirmé par une supermajorité des SOL en staking (≥66 %) et qu’au moins 31 blocs confirmés supplémentaires ont été construits au-dessus de lui, ce qui confère au slot le verrouillage maximal de 32 votes. Une transaction finalized est, dans les faits, irréversible.

Confirmed

Un niveau intermédiaire auquel le bloc a reçu les votes d’une supermajorité des SOL en staking (≥66 %), mais n’a pas encore été finalisé par une période prolongée de votes continus qui rendrait son annulation plus difficile. On parle souvent de confirmation optimiste. Celle-ci garantit fortement que la transaction se trouve sur le « fork principal », ou chaîne canonique.

Processed

Processed signifie que la transaction vient d’être traitée par un leader et incluse dans le bloc le plus récent connu du nœud. Toutefois, ce bloc n’a peut-être encore reçu aucun vote à l’échelle du cluster. La transaction pourrait encore être abandonnée si ce bloc ne rejoint pas le fork majoritaire.

Ces niveaux représentent les différentes étapes du cycle de vie d’une transaction. 

Une transaction qui vient d’être soumise passe de Processed → Confirmed → Finalized à mesure que le réseau observe le bloc qui la contient, vote pour celui-ci et construit de nouveaux blocs au-dessus. Un engagement plus élevé signifie que davantage de nœuds ont accepté l’inclusion de la transaction, ce qui réduit le risque de fork ou d’annulation. 

Examinons chaque niveau en détail.

Niveau d’engagement Processed

Une transaction devient Processed dès qu’un nœud validateur, c’est-à-dire le leader actuel, l’inclut dans un bloc. Il s’agit du premier accusé de réception : la transaction a été reçue et intégrée localement à l’état du registre.

Les principales caractéristiques du niveau Processed sont les suivantes :

• Inclusion dans un bloc : la transaction se trouve dans un bloc produit par un validateur.
• Aucune garantie de rejoindre le fork majoritaire : ce bloc peut ou non rejoindre le fork majoritaire, c’est-à-dire le plus long ou le plus lourd.
• Retour le plus rapide : il fournit une indication immédiate que la transaction a été traitée par un nœud. C’est utile pour mettre rapidement à jour l’interface côté client, par exemple afin d’afficher une transaction en attente dans un portefeuille.
• Sécurité incomplète : à ce stade, rien ne garantit que les autres validateurs aient vu le bloc ou voté pour lui. Le cluster peut encore « ignorer » ce bloc ou le remplacer par un autre fork. Autrement dit, Processed signifie que la transaction est incluse, mais pas encore confirmée par les autres validateurs.

Exemple de bloc Processed : 

Supposons qu’Alice soumette un transfert sur Solana. Dès que le leader actuel l’ajoute à un bloc (slot N), la transaction prend le statut Processed. Le portefeuille d’Alice peut immédiatement l’afficher comme en attente/traitée. 

Cependant, si le bloc de ce leader n’est pas accepté par la majorité des validateurs — par exemple, parce que le leader était lent ou hors ligne et qu’un autre fork a pris le dessus — la transaction d’Alice peut disparaître, c’est-à-dire être abandonnée, car le bloc traité n’a pas rejoint la chaîne principale.

Niveau d’engagement Confirmed

Le niveau d’engagement Confirmed indique que le bloc de la transaction a été accepté par la supermajorité du cluster et qu’il appartient très probablement à la chaîne canonique. Techniquement, « confirmed » signifie qu’au moins 66 % des validateurs, pondérés selon leurs SOL en staking, ont directement voté pour ce bloc. 

Principales caractéristiques :

• Sur le fork majoritaire : le bloc contenant la transaction est reconnu comme appartenant au fork majoritaire du registre. Le réseau le considère donc comme un bloc canonique.

• Votes d’une supermajorité : au moins deux tiers de l’ensemble des SOL en staking ont voté pour confirmer le bloc. Ces votes sont recueillis au moyen du mécanisme de gossip de Solana : les validateurs ont diffusé et observé les votes en faveur de ce bloc sur l’ensemble du réseau. Cette étape s’appuie sur la confirmation optimiste, introduite dans Solana v1.3, qui permet aux nœuds de considérer un bloc comme confirmé dès qu’une supermajorité vote pour lui, avant même sa finalisation.

• Faible risque d’annulation : avec un consensus supérieur ou égal à 66 %, il est très peu probable, mais pas impossible, qu’un fork concurrent remplace ce bloc. Tous les validateurs honnêtes se sont effectivement engagés sur ce bloc, sauf en cas de réorganisation majeure. Aucun bloc confirmé n’a été annulé au cours des cinq années d’existence de Solana.

• Plus rapide que Finalized : le statut confirmed intervient généralement peu après le statut processed d’un bloc ou d’une transaction, en une ou deux secondes, car les validateurs votent rapidement sur les nouveaux blocs. Il n’attend pas la production de nombreux blocs supplémentaires. Dans des conditions normales, Confirmed offre donc un bon équilibre entre rapidité et confiance.

• Finalité optimiste : dans la plupart des cas pratiques, les développeurs considèrent souvent une transaction confirmed comme pratiquement définitive en raison de la rapidité du consensus de Solana. Un faible risque d’annulation subsiste toutefois jusqu’à la finalisation.

Exemple de bloc Confirmed : 

La transaction d’Alice mentionnée ci-dessus devient Confirmed lorsque les validateurs du cluster votent pour le bloc N. En pratique, si les validateurs des slots suivants — N+1, N+2, etc. — votent et voient le bloc N, et que le seuil de 66 % est atteint, le réseau marque le bloc N comme confirmed. Le portefeuille d’Alice peut alors afficher la transaction à l’utilisateur comme confirmée en toute sécurité. 

À ce stade, la probabilité que le transfert d’Alice soit annulé est très faible. Cela ne pourrait arriver qu’en cas de fork rare ou de problème réseau. Ce mécanisme est analogue aux « N confirmations » d’autres chaînes, mais repose sur les votes pondérés selon les SOL en staking plutôt que sur un nombre fixe de confirmations de blocs.

Niveau d’engagement Finalized

Une transaction devient Finalized lorsque son bloc a reçu les votes d’une supermajorité et qu’un nombre suffisant de blocs supplémentaires ont été construits au-dessus de lui. Dans le consensus de Solana, cela correspond à l’obtention par le bloc du verrouillage maximal, généralement après sa confirmation par 32 votes consécutifs (slots). Finalized est le niveau d’engagement le plus élevé et offre le plus haut degré de certitude que la transaction ne sera pas annulée. 

Les caractéristiques du niveau Finalized sont les suivantes :

• Bloc irréversible : le cluster a reconnu ce bloc comme finalisé, ce qui signifie qu’il est devenu une racine dans l’état du registre. Les validateurs ne l’annuleront pas et il est, dans les faits, permanent.

• Supermajorité et verrouillage : comme pour Confirmed, au moins 66 % des SOL en staking ont approuvé le bloc. De plus, au moins 31 blocs confirmés ultérieurs ont été ajoutés après lui. Autrement dit, le réseau a construit une chaîne profonde au-dessus de ce bloc, jusqu’à atteindre la profondeur de verrouillage qui rend toute réorganisation irréalisable.

• Verrouillage maximal (32 votes) : le mécanisme Tower BFT de Solana double de manière exponentielle la période de verrouillage des votes. Lorsqu’un bloc a accumulé 32 votes dans la tour, ce qui signifie qu’il est resté à la tête du fork pendant 32 slots supplémentaires, il atteint le verrouillage maximal et devient finalisé. À ce stade, tout validateur qui tenterait de voter pour un autre fork enfreindrait les règles du consensus.

• Sécurité maximale, confirmation la plus lente : la finalisation intervient généralement après les niveaux processed et confirmed, avec un délai d’environ ~10 à 20 secondes dans des conditions normales, puisque 32 slots de ~400 ms représentent environ 13 secondes. C’est le compromis nécessaire pour obtenir la certitude de Finalized. En attendant la finalisation, les clients éliminent tout risque d’abandon ou d’annulation de la transaction, au prix d’une latence supplémentaire.

• Confirmé et recouvert par d’autres blocs : on peut aussi voir la finalisation comme un bloc confirmed qui a été enfoui sous de nombreux autres blocs. Tous les nœuds honnêtes ont verrouillé ce bloc de manière vérifiable dans le registre permanent.

Exemple de bloc Finalized :

La transaction d’Alice atteint le statut Finalized lorsque le réseau continue de produire des blocs après le slot N. Supposons qu’au slot N+32, une supermajorité de validateurs ait voté pour chaque bloc successif jusqu’à N+32, sans qu’un autre fork ne prenne le dessus. Le bloc N, qui contient la transaction d’Alice, est alors finalisé. 

À ce stade, la transaction d’Alice est définitivement inscrite dans le registre de Solana. Même si elle attend, l’état qui comprend son transfert ne changera pas. 

Toute application exigeant une finalité forte, par exemple une plateforme d’échange qui débloque des fonds, peut alors agir sur cette transaction en toute sécurité. Pour l’annuler, un attaquant devrait notamment contrôler plus d’un tiers des SOL en staking et enfreindre le consensus.

Niveaux d’engagement obsolètes

Les anciennes versions de Solana, antérieures à 2021, proposaient des niveaux d’engagement supplémentaires qui sont depuis devenus obsolètes au profit des trois niveaux ci-dessus.

Par souci d’exhaustivité, voici les anciens termes et leur correspondance avec les niveaux actuels :

• recent – Obsolète ; équivaut à Processed. Dans l’ancienne documentation, « recent » désignait simplement l’état le plus récent connu du nœud.

• single et singleGossip – Obsolètes ; équivalent à Confirmed. Ces termes désignaient des confirmations impliquant un seul validateur ou transmises par gossip, ce qui correspond à la définition de confirmed.

• root et max – Obsolètes ; équivalent à Finalized. « Root » désignait l’état racine finalisé dans le cluster, tandis que « max » faisait référence au verrouillage maximal. Les deux signifiaient donc, dans les faits, finalized.

Aujourd’hui, les développeurs doivent uniquement utiliser processed, confirmed ou finalized pour préciser un niveau d’engagement. Depuis la version v1.5.5, l’API JSON-RPC de Solana utilise ces termes par défaut et traite les termes obsolètes comme des alias du niveau correspondant. 

De plus, si aucun engagement n’est indiqué dans une requête RPC, la valeur par défaut est Finalized : le nœud renvoie donc par défaut l’état le plus finalisé.

Différences entre les niveaux d’engagement

Les différences entre Processed, Confirmed et Finalized dépendent de la part du réseau qui a reconnu la transaction et de la probabilité que celle-ci soit annulée. Le tableau ci-dessous, adapté de la documentation officielle de Solana, résume les principales distinctions :

En résumé, Processed signifie uniquement que la transaction se trouve dans un bloc. Confirmed signifie que le cluster a accepté ce bloc grâce aux votes d’une supermajorité, mais que celui-ci reste proche de la tête de la chaîne. Finalized signifie que le bloc se trouve profondément dans la chaîne et dispose de nombreuses confirmations, au point d’être pratiquement immuable.

On peut également considérer la différence sous l’angle de la probabilité que la transaction reste dans le registre canonique au fil du temps. 

Au moment où elle devient processed, cette probabilité n’est pas de 100 %, car un fork ou un échec reste possible. Une fois la transaction confirmée par plus de 66 % des SOL en staking, sa probabilité d’inclusion devient très élevée. Lorsqu’elle est finalized, avec des dizaines de blocs construits au-dessus, cette probabilité atteint ~100 %. 

Le graphique ci-dessous illustre cette évolution. Il montre comment la probabilité de finalisation d’une transaction augmente à mesure que les slots passent et que le niveau d’engagement progresse :

La probabilité qu’une transaction soit incluse dans la chaîne canonique finale augmente au fil du temps. Initialement, au slot n, lorsque la transaction est processed, celle-ci risque encore d’être « ignorée » ou exclue par un fork. Avec la confirmation optimiste, ou statut confirmed, sa probabilité d’inclusion augmente fortement à mesure que les validateurs votent. Après la construction d’un nombre suffisant de forks consécutifs au-dessus de celle-ci, elle devient finalized et la probabilité d’annulation tombe pratiquement à zéro. Cela illustre la diminution du risque d’annulation à mesure que le niveau d’engagement augmente.

Comment Solana détermine-t-elle les niveaux d’engagement ?

Comprendre le fonctionnement interne du consensus de Solana permet de mieux saisir la raison d’être de ces niveaux d’engagement :

Proof of History (PoH) et production de blocs

Les leaders de Solana produisent rapidement des blocs successifs, avec un leader par slot et des slots d’environ ~400 ms. Les transactions sont diffusées dans une chaîne de hachage Proof of History (PoH), où elles forment les entrées d’un bloc. Les blocs se propagent rapidement sur le réseau par l’intermédiaire de Turbine, le protocole de propagation de blocs de Solana. Lorsqu’un leader produit un bloc contenant votre transaction, ce bloc est immédiatement propagé, mais pas encore confirmé : cela correspond à l’étape Processed.

Vote (Tower BFT)

Solana utilise un algorithme de consensus BFT appelé Tower BFT. Les validateurs, qui contrôlent chacun une certaine quantité de SOL en staking, votent pour les blocs qui devraient, selon eux, devenir la prochaine partie du registre. Les votes sont eux-mêmes des transactions Solana et intègrent une notion de verrouillage. Chaque fois qu’un validateur vote pour un bloc au slot N, il subit un verrouillage. S’il vote ensuite pour un fork concurrent, il risque de ne plus pouvoir voter pendant un certain temps. 

Ces verrouillages doublent de manière exponentielle à chaque vote successif sur le même fork — 1, 2, 4, 8... slots de verrouillage — jusqu’à un maximum de 32 votes. Si un validateur a voté 32 fois de suite sur un fork, ce qui signifie que le bloc datant de 32 slots appartient toujours au fork le plus lourd, ce bloc atteint le verrouillage maximal. Ce mécanisme incite les validateurs à rester sur le fork majoritaire et à finaliser les blocs.

Confirmation (confirmation optimiste)

Lorsqu’un bloc est produit, les validateurs diffusent leurs votes en sa faveur. Dès qu’une supermajorité représentant au moins 66 % des SOL en staking a voté pour un bloc, les nœuds Solana considèrent celui-ci comme confirmé de manière optimiste. Il s’agit du niveau d’engagement Confirmed. Cela se produit rapidement, souvent dans le ou les deux slots qui suivent le bloc, car les votes sont propagés par gossip. 

Il est important de noter que l’implémentation de Solana n’exige pas d’attendre que le bloc devienne une racine dans le registre. Elle considère le vote de la supermajorité comme un signal optimiste indiquant que le bloc finira par être finalisé, à condition que moins de <33 % des SOL en staking aient un comportement malveillant. 

C’est pourquoi on parle de confirmation optimiste : selon les hypothèses habituelles de tolérance aux fautes byzantines, avec au maximum un tiers de participants malhonnêtes, le vote d’une supermajorité signifie que le bloc ne sera pas annulé. Pour qu’un fork le remplace, plus de 33 % des validateurs devraient voter pour une autre chaîne, ce qui invaliderait ces hypothèses.

Finalisation (création d’une racine de bloc)

À mesure que de nouveaux blocs sont produits et soumis au vote, chaque bloc confirmé s’enfonce davantage dans le fork. Lorsqu’un bloc a accumulé des votes sur 32 slots consécutifs après sa création, il atteint le verrouillage maximal. Le réseau fait alors de ce bloc une racine, ce qui le rend finalisé et irréversible. La finalisation signifie que le bloc se trouve au moins 31 blocs derrière la tête et qu’il n’a jamais été abandonné au profit d’un autre fork. Tous les nœuds le considèrent désormais comme appartenant à l’historique immuable, et l’état du registre jusqu’à ce slot est figé. 

Par analogie avec une chaîne PoW, l’engagement Finalized correspond dans les faits à un « bloc disposant d’au moins 32 confirmations ». Solana y parvient toutefois grâce à des votes verrouillés dans le temps plutôt qu’à des confirmations par preuve de travail. La règle des 32 slots découle de la conception de Tower BFT, dont les verrouillages doublent jusqu’à 2^32, et offre une garantie mathématique de finalité selon l’hypothèse d’une tolérance aux fautes d’un tiers.

Choix du fork et annulation

Le consensus de Solana évalue continuellement les forks. Les validateurs utilisent un algorithme de sélection du fork le plus lourd, basé sur le poids des votes pondérés selon les SOL en staking, pour choisir celui sur lequel construire. Si un bloc n’est traité que par une partie des validateurs et ne recueille pas de votes, un autre fork peut le remplacer. C’est pourquoi une transaction Processed peut être abandonnée. 

Lorsqu’un bloc est confirmé par deux tiers des SOL en staking, un autre fork devrait obtenir le soutien de plus d’un tiers des SOL en staking pour l’emporter. C’est très improbable et cela impliquerait un comportement malveillant. 

Après la finalisation, il est pratiquement impossible qu’un fork revienne sur ce bloc sans défaillance catastrophique du consensus. Même en cas d’arrêt ou d’attaque du réseau, l’annulation des slots finalisés exigerait une coordination en dehors des règles du protocole.

En résumé : Processed signifie que le bloc a été produit avec PoH, mais n’a pas encore reçu de nombreux votes ; Confirmed signifie que les votes du cluster avec Tower BFT ont atteint une supermajorité sur le bloc, soit un consensus optimiste ; Finalized signifie que le bloc a persisté en tant que « racine » de la chaîne après de nombreux votes supplémentaires, soit une finalité absolue du consensus. La conception de Solana garantit que les blocs confirmed deviennent finalized après un court délai, ce qui assure une confirmation rapide suivie d’une finalité absolue.

Cas d’usage de chaque niveau d’engagement pour les développeurs

Le choix du niveau d’engagement approprié est essentiel lors du développement sur Solana. Les exigences de rapidité et de certitude varient selon les applications. 

Voici les cas d’usage et les bonnes pratiques habituels pour chaque niveau :

Utilisez Processed pour un retour immédiat et les opérations non critiques

Les développeurs peuvent utiliser l’engagement Processed lorsque la rapidité est primordiale et qu’un certain risque d’annulation est acceptable. Pendant le développement et les tests, par exemple, vous pouvez vouloir confirmer immédiatement qu’une transaction a été reçue par un validateur. 

Les applications dotées d’une interface utilisateur, comme les portefeuilles ou les jeux, peuvent afficher une transaction de manière optimiste dès qu’elle est processed afin d’améliorer l’expérience utilisateur, par exemple avec un statut « en attente ». 

Toutefois, comme rien ne garantit que les transactions processed seront conservées, ce niveau n’est pas recommandé pour les flux critiques en production. Si vous l’utilisez, réservez-le aux transactions de faible valeur ou non critiques, pour lesquelles une éventuelle annulation n’entraînerait pas de graves problèmes.

Utilisez Confirmed pour la plupart des transactions

Le niveau Confirmed est généralement recommandé par défaut pour de nombreux cas d’usage sur Solana. Il offre une solide garantie de réussite avec un impact minimal sur la latence. 

Par exemple, une application DeFi qui effectue un échange de tokens ou un utilisateur qui transfère des fonds s’appuiera généralement sur le statut confirmed. Une fois la transaction confirmée, l’application peut normalement la considérer comme terminée. Ce niveau réduit considérablement le risque d’abandon d’une transaction par rapport à Processed. La bonne pratique consiste à utiliser le niveau d’engagement Confirmed, notamment lors de la récupération de blockhashes récents et de l’envoi de transactions, car il offre un meilleur équilibre entre latence et sécurité.

Utilisez Finalized pour les transactions critiques ou de grande valeur

Lorsqu’une certitude absolue est nécessaire, par exemple pour déplacer des actifs de grande valeur, utiliser des ponts interchaînes ou confirmer des dépôts sur une plateforme d’échange, les développeurs doivent choisir le niveau d’engagement Finalized. Ce choix est courant lorsqu’un risque d’annulation, même infime, est inacceptable. 

Une plateforme d’échange peut, par exemple, attendre la finalisation d’une transaction avant de créditer un dépôt sur le compte d’un utilisateur. Elle évite ainsi qu’une réorganisation ultérieure n’annule le dépôt. 

Ce niveau peut aussi être utilisé après une série de transactions : il est possible de vérifier que l’état final est finalized avant de considérer une opération complexe comme terminée, par exemple lors d’un audit ou d’un règlement nécessitant l’état définitif du registre. 

Les développeurs doivent savoir qu’exiger un engagement Finalized augmente la latence et peut, en cas de forte charge du réseau, accroître le risque d’expiration des transactions, puisque vous attendez en pratique la finalisation du hash d’un bloc plus ancien. Utilisez Finalized avec discernement, uniquement pour les transactions les plus critiques, lorsque la sécurité supplémentaire justifie le compromis en matière de latence.

En résumé, Processed sert principalement à obtenir un retour rapide et aux usages hors production. Confirmed convient à la plupart des opérations et équilibre sécurité et performances. Finalized est réservé aux situations où une finalité garantie est indispensable malgré l’attente. 

De nombreuses applications combinent ces niveaux : elles mettent à jour l’interface au statut Processed, considèrent l’opération comme terminée au statut Confirmed et l’enregistrent au statut Finalized.

Effets sur la fiabilité, les performances et la sécurité des transactions

Le choix du niveau d’engagement a des conséquences directes sur la fiabilité — la transaction sera-t-elle conservée ? —, les performances — la latence — et la sécurité — le risque de double dépense ou de problème lié à un fork :

Fiabilité

Un niveau d’engagement plus élevé augmente la probabilité qu’une transaction soit enregistrée de manière permanente. Une transaction finalized offre une fiabilité pratiquement égale à 100 % quant à sa présence dans le registre, sauf événement extraordinaire. Une transaction confirmed présente une fiabilité très élevée, mais pas absolue, tandis qu’une transaction processed est moins fiable. 

Comme indiqué précédemment, environ ~5 % des transactions pourraient être abandonnées si seul le statut processed était pris en compte, en raison des changements de forks. Le statut confirmed ramène ce risque près de 0 %. 

Dans les applications critiques, l’utilisation de l’engagement finalized élimine le risque que votre transaction se trouve dans un fork abandonné par la suite.

Performances (latence)

Il existe un compromis clair entre la rapidité de la confirmation et le niveau d’engagement. 

La confirmation Processed est presque instantanée : elle intervient pendant le temps de production du bloc, souvent en moins d’une seconde. 

Confirmed ajoute un léger délai, de l’ordre d’un ou deux slots, soit environ ~0,5 à 1 seconde supplémentaire, afin de recueillir les votes des validateurs. Cela reste très rapide et généralement imperceptible pour les utilisateurs. 

Finalized entraîne le délai le plus important, car la transaction n’est signalée comme finalized qu’après la production d’environ 30 blocs supplémentaires ou plus. Il faut généralement ~10 à 20 secondes pour atteindre la finalité. 

Pendant les périodes de congestion du réseau ou de ralentissement de la production des blocs, ce délai peut s’allonger. Exiger un engagement Finalized peut donc ralentir l’expérience utilisateur et le débit si ce niveau est utilisé trop souvent. Une application qui attend la finalisation doit tenir compte de ce délai supplémentaire. Cela ne signifie toutefois pas que l’exécution on-chain de la transaction prend plus de temps : seul le client attend davantage pour vérifier sa finalisation. Pendant ce temps, Solana continue de traiter de nouvelles transactions.

Débit et expiration

L’expiration des transactions et l’utilisation des blockhashes constituent un effet important, mais plus subtil. Les transactions Solana contiennent un blockhash récent et ne sont valides que pendant environ ~150 slots après ce blockhash. 

Si vous demandez un blockhash finalized pour signer votre transaction, ce blockhash est plus ancien, car le statut finalized est en retard sur la tête de la chaîne. Il reste donc moins de slots avant l’expiration de la transaction. Cela peut accroître le risque d’expiration si le réseau est congestionné et que votre transaction n’est pas traitée rapidement. 

L’utilisation d’un blockhash plus récent, au statut Confirmed, offre une fenêtre plus longue. La recommandation officielle consiste à utiliser Confirmed pour getLatestBlockhash afin de réduire le risque d’expiration. 

L’utilisation de Finalized pour la simulation préalable ou le blockhash peut donc réduire légèrement le temps pendant lequel votre transaction peut être sélectionnée, ce qui affecte sa fiabilité sous forte charge. 

En bref, un engagement Finalized peut réduire la disponibilité en période de forte charge : vous gagnez en certitude, mais risquez davantage d’expirations de transactions si le réseau approche de sa capacité maximale.

Sécurité

Du point de vue de la sécurité, par exemple pour empêcher les doubles dépenses et se protéger des forks, Finalized est le niveau le plus sûr. 

Une fois la transaction finalisée, son annulation exigerait qu’une part supérieure au tiers de l’ensemble des SOL en staking agisse de manière malveillante, ce qui serait probablement détecté et sanctionné. 

Confirmed est très sûr dans des conditions normales. Un attaquant devrait créer un fork concurrent et convaincre plus de 33 % des validateurs de le soutenir après le vote d’une supermajorité, ce qui est extrêmement improbable sans attaque coordonnée de grande ampleur. 

Il existe toutefois un scénario théorique dans lequel un bloc Confirmed pourrait devenir orphelin : certains validateurs représentant un peu moins de 33 % pourraient retenir leurs votes, ou un fork pourrait se trouver juste à la limite du seuil. La conception de Solana, fondée sur la confirmation optimiste, suppose néanmoins une majorité honnête pour prévenir ce cas. 

Processed offre le moins de sécurité : tant que les votes n’ont pas été reçus, rien ne garantit que les autres validateurs connaissent même l’existence de la transaction. Un leader malveillant pourrait inclure une transaction, puis ne pas transmettre correctement le bloc, entre autres possibilités. 

Ne vous fiez donc pas à Processed pour une confirmation critique en matière de sécurité. Ce statut ressemble davantage à une « notification » indiquant que le processus a commencé. 

En résumé, pour la protection contre les forks et les doubles dépenses : Finalized > Confirmed > Processed.

Utilisation de l’engagement pour les lectures et les écritures

Lorsque vous lisez l’état de Solana, par exemple en consultant le solde d’un compte par RPC, vous précisez également un niveau d’engagement. Avec un niveau Processed, vous pouvez obtenir des données très récentes, mais provenant éventuellement d’un fork non finalisé. Utiliser Finalized pour les lectures garantit une cohérence absolue, c’est-à-dire l’état accepté par tous, mais celui-ci peut avoir quelques slots de retard. Dans la plupart des cas, Confirmed offre un bon équilibre pour les requêtes d’état, comme pour les transactions. Vous évitez ainsi de prendre des décisions à partir d’un fork susceptible d’être annulé. 

Pour les requêtes d’écriture, c’est-à-dire l’envoi de transactions, l’engagement détermine principalement la manière dont la bibliothèque cliente attend la confirmation. Une pratique courante consiste à envoyer une transaction avec un certain preflightCommitment, qui peut simuler la TX selon l’état le plus récent, puis à utiliser confirmTransaction avec le même niveau d’engagement. Les développeurs peuvent choisir d’attendre une confirmation finalized si nécessaire.

Pour donner des chiffres concrets : selon des mesures récentes, Solana a traité une transaction en ~0,4 seconde, atteint l’état confirmed en ~0,6 seconde et obtenu la finalisation en ~13 secondes. 

Si votre application, par exemple une application de paiement, ne peut pas attendre ~13 secondes par transaction, utilisez confirmed, qui offre tout de même une sécurité élevée. 

Si vous transférez une somme importante entre plusieurs chaînes, vous pouvez attendre les ~13 secondes complètes pour obtenir une certitude totale. À l’inverse, si vous créez un produit pour lequel la rapidité est essentielle et où un faible risque reste acceptable, par exemple pour mettre à jour une interface de manière optimiste, vous pouvez vous appuyer sur le statut processed afin d’offrir une expérience utilisateur réactive.

Conclusion

Les niveaux d’engagement de Solana — Processed, Confirmed et Finalized — sont une fonctionnalité essentielle qui permet aux développeurs d’adapter l’équilibre entre rapidité et certitude pour chaque transaction.

Processed fournit des résultats immédiats, mais incertains. Confirmed offre une garantie proche de la finalité en une ou deux secondes, ce qui suffit à la plupart des applications. Finalized assure une finalité absolue après un délai supplémentaire. 

En interne, ces niveaux correspondent aux étapes du consensus de Solana : le bloc est d’abord produit, puis soumis au vote d’une supermajorité, avant de devenir une racine dans le registre avec un verrouillage maximal.

Lorsque vous développez sur Solana, il est essentiel de choisir le niveau d’engagement adapté à votre tâche :

• Utilisez les engagements plus faibles pour obtenir un retour rapide ou effectuer des actions non critiques
• Utilisez confirmed pour les opérations courantes qui exigent à la fois rapidité et sécurité
• Utilisez finalized lorsqu’une finalité totale est la seule option acceptable

Chaque niveau influe sur la fiabilité de l’inclusion de la transaction et sur le temps d’attente. 

En comprenant leur signification technique — 66 % des votes, 32 blocs, forks et verrouillages — et en suivant les bonnes pratiques les plus récentes, les développeurs peuvent obtenir les performances promises par Solana sans sacrifier la cohérence ni la sécurité de leurs applications.

Ressources supplémentaires

• Documentation de Solana – Configuration de l’engagement de l’état, tableau des statuts d’engagement
• Blog Helius – Le consensus sur Solana (mécanismes de consensus et de finalité)