Erreurs de transaction Solana : blockhash expiré et transactions non incluses

2026-08-24

Une transaction Solana peut être décrite simultanément à plusieurs niveaux. Un message décrit les instructions proposées et leur contexte, une transaction signée porte l’autorisation de ce message, une réponse RPC indique ce qu’un service a accepté ou observé, et un enregistrement du cluster constitue une preuve à un niveau de commitment donné. Ces niveaux peuvent produire des formulations d’état différentes sans se contredire. La lecture d’un message d’expiration ou de transaction non incluse commence donc par l’identification du niveau qui l’a produit. Un délai local, une erreur RPC, une réponse d’état et un enregistrement finalisé décrivent des points distincts d’un chemin de soumission, et non une conclusion universelle sur l’état résultant.

Schéma des états d’une transaction Solana, du message au résultat enregistré

État de la transaction et chemin de soumission

Une transaction Solana contient des instructions, des signatures de comptes qui autorisent des changements et un recent blockhash. Lors du traitement, le réseau considère ses instructions comme une unité atomique : l’échec d’une instruction empêche l’inscription conjointe des changements d’état prévus. Avant qu’un tel résultat existe, la transaction peut passer par des étapes distinctes de formation du message, de signature, de relais vers un nœud RPC, de réception par des participants du réseau, de traitement et d’observation à un niveau de commitment. Une étiquette d’état n’a de sens que lorsque son étape est claire.

La méthode RPC sendTransaction renvoie la première signature de transaction lorsque le service RPC accepte la charge signée pour la relayer. La documentation officielle distingue expressément cette acceptation immédiate du traitement ou de la confirmation par le cluster. Dans le langage courant, dropped transaction désigne souvent l’absence d’un enregistrement ultérieur du cluster après un événement antérieur lié à la soumission. Ce n’est pas un unique état de consensus doté d’une cause fixe. L’expression peut être employée par un client, un service RPC ou un observateur, et chacun peut désigner une transition manquante différente sur le chemin.

Le rôle d’un blockhash

Le recent blockhash d’un message de transaction est une référence de fraîcheur fournie par le réseau. La méthode getLatestBlockhash renvoie à la fois un blockhash et lastValidBlockHeight, ce qui rattache cette référence à une limite de hauteur plutôt qu’à une durée d’horloge garantie. Le protocole peut ainsi évaluer si une transaction portant cette référence reste dans la fenêtre de traitement. Le blockhash fait partie du message évalué ; il relève donc de l’identité et du contexte de validation de la transaction, et non d’un affichage ultérieur dans un explorateur.

La hauteur de bloc, la progression des slots et le temps écoulé sont liés, mais ne doivent pas être considérés comme des horloges interchangeables. Le paramètre exact d’âge de traitement, le nombre de slots décrit dans la documentation et le temps représenté par ces slots dépendent de la version pertinente du protocole et du logiciel, ainsi que des conditions du réseau. Un recent blockhash se comprend donc mieux comme une fenêtre de validité dépendante de la version. Le fait durable est l’existence d’une limite ; une durée exacte n’est pas une promesse universelle.

Expiré et introuvable sont différents

Expiré décrit un résultat de validité : le recent blockhash ne peut plus servir à faire traiter une transaction selon les règles applicables. Cela concerne la référence limitée dans le temps de la transaction, et non une étiquette générale pour chaque relais qui échoue ou chaque enregistrement absent. Lorsque des personnes utilisent la requête solana transaction expired, elles nomment souvent un résultat visible dans un client qui correspond à cette limite du cycle de vie. La seule expression ne dit pas ce qu’un nœud RPC précis a reçu et ne décrit pas un résultat de transfert distinct.

Blockhash not found solana est une requête qui associe souvent une chaîne affichée au nom du réseau. Un véritable message blockhash-not-found peut exprimer qu’un nœud, dans sa vue actuelle et au niveau de commitment concerné, ne peut pas résoudre le hachage référencé pour le contexte de validation pertinent. Cette observation n’équivaut pas automatiquement à la preuve que la dernière hauteur valide est dépassée partout. L’état du nœud, le commitment, la version de l’API, le moment et la formulation du client peuvent modifier la manière dont une même condition générale est présentée ; les deux expressions ne doivent donc pas être réduites à un diagnostic immuable.

Signée mais non incluse dans un bloc

Une signature est une autorisation pour un message particulier ; elle n’est pas un enregistrement indiquant que ce message a atteint un bloc. De même, l’acceptation d’une charge par un service RPC pour relais n’est pas un enregistrement indiquant que le cluster l’a traitée. Une transaction signée peut donc être qualifiée de signée tout en n’ayant aucune observation traitée, confirmée ou finalisée. Cet écart ne révèle pas à lui seul si une charge n’a jamais été reçue par un participant pertinent, n’a pas été conservée dans un périmètre d’état visible ou est devenue invalide avant son traitement.

Les méthodes d’état JSON-RPC rendent explicites les limites d’une observation. getSignatureStatuses renvoie les états actuels des signatures fournies et sa recherche par défaut est limitée à un cache d’état récent, sauf si une recherche dans l’historique des transactions est incluse. getTransaction renvoie une transaction confirmée par signature ou null lorsqu’elle n’est pas trouvée ou confirmée au commitment demandé. Une réponse null a donc une portée définie ; elle ne constitue pas une affirmation universelle selon laquelle aucun événement n’a jamais existé dans la vue conservée de chaque nœud.

Différences entre les observations RPC, client et réseau

Une interface cliente condense habituellement plusieurs signaux techniques dans une courte phrase destinée à une personne. Une réponse RPC est au contraire le rapport d’un nœud particulier, avec un slot de contexte, une version d’API, une configuration et un commitment demandé. Une observation du réseau désigne l’état que le commitment pertinent rend visible. Ces observations sont liées, mais elles ne sont pas le même objet et ne doivent pas devenir visibles au même instant.

La dépendance aux versions importe à chaque niveau. Le logiciel de nœud Solana, les bibliothèques clientes, la configuration RPC, la prise en charge des versions de transaction, les valeurs de commitment par défaut, la rétention des états et le texte de l’interface peuvent évoluer. Une interprétation solide identifie donc d’abord l’observateur et le périmètre de l’observation avant de donner un sens à une étiquette d’erreur. Elle ne suppose pas qu’une formule issue d’une interface décrive de manière transportable chaque nœud, chaque commitment ou chaque version du logiciel.

Pourquoi une soumission répétée n’est pas une réponse universelle

Une soumission répétée n’est pas un seul événement technique. Elle peut signifier relayer à nouveau les mêmes octets signés, présenter un message différent ou créer un message ultérieur avec un contexte de validation distinct. Ces cas ont des identifiants, des moments et des effets possibles sur l’état différents. Une transaction déjà examinée par le réseau et une transaction ultérieure distincte qui exprime une intention semblable ne deviennent pas interchangeables du seul fait de cette ressemblance. La répétition peut ainsi compliquer l’interprétation du rapport entre une signature visible, un enregistrement d’état et un changement d’état prévu.

Pour la même raison, une prescription générique de nouvelle tentative confondrait réception, propagation, validation, exécution et commitment dans une seule idée. Le langage d’expiration n’établit pas à lui seul qu’un message ultérieur possède la même identité ou le même effet qu’un message antérieur. Sur le plan analytique, la distinction importante est de savoir si les éléments disponibles concernent le même message de transaction, un message distinct ou seulement une tentative locale de relayer des données. Le sujet de l’article est cette distinction, et non une procédure pour envoyer une autre transaction.

Vocabulaire de diagnostic stable et limites de risque

Un vocabulaire stable aide à séparer les niveaux. Message désigne les instructions, les comptes, le recent blockhash et les autres données autorisées. Signature identifie une transaction signée pour des API orientées vers l’état. Soumission désigne un événement de relais RPC, tandis que traitement, confirmation et finalisation désignent différents niveaux d’observation du réseau. Commitment est le seuil de visibilité demandé qu’emploient les méthodes RPC. L’expiration concerne la référence de fraîcheur et dropped décrit couramment un chemin observé incomplet, non un verdict de protocole doté d’une signification standardisée.

La limite de ces termes est aussi importante que leurs définitions. Un état technique n’établit ni la propriété d’un compte, ni l’intention d’un expéditeur, ni un solde d’actifs, ni le comportement d’un service, ni un recours pour un enregistrement absent. Il ne transforme pas non plus un message client en preuve de ce qu’a observé chaque validateur ou chaque système de rétention de données. Le langage d’état est une preuve relative à un chemin de traitement limité, interprétée au moyen d’une version, d’un observateur, d’un commitment et d’un moment. Préserver clairement cette limite évite d’étendre un signal réseau étroit en affirmation plus large.

Articles associés

Autres articles Bitbase sur ce sujet :

- MEV sur Solana et attaques onchain

- Kamino sur Solana expliqué

- Frais et performance de Solana

Avertissement : Cet article est un contenu pédagogique de Bitbase Academy, fourni à titre d'information uniquement. Il ne constitue pas un conseil en investissement, en trading, en fiscalité ou en finance. Les cryptoactifs sont volatils ; évaluez votre propre risque. Rédigé en août 2026 ; référez-vous aux informations officielles les plus récentes.