Comment gérer les erreurs de blockhash sur Solana

Qu'est-ce qu'un blockhash ?

Pour comprendre ce qu'est un blockhash, vous devez d'abord comprendre ce que sont les slots et les blocs.

• Un slot est une période pendant laquelle un validateur peut produire un bloc 
• Un bloc est un ensemble de transactions et de métadonnées qu'un validateur traite. Les métadonnées de chaque bloc le relient au bloc précédent, formant ainsi une chaîne.

Il est important de comprendre que les slots durent entre 400 et 600 ms et que, dans chaque slot, un validateur peut proposer un nouveau bloc. Si aucun bloc n'est créé, le slot est incrémenté et un autre validateur tente de créer un nouveau bloc. Cela signifie que tous les slots ne sont pas associés à un bloc, mais que tous les blocs sont associés au slot dans lequel ils ont été proposés.

Alors, qu'est-ce qu'un blockhash ? Un blockhash est une valeur de hachage unique représentant toutes les entrées du registre de la blockchain créées pendant un slot. Il est calculé à partir de l'identifiant de la dernière entrée du bloc. Chaque bloc produit entraîne la création d'un blockhash unique. Ces blockhashes servent d'horodatages.

Quels sont les niveaux de confirmation de Solana ?

Un autre concept important à comprendre est celui des niveaux de confirmation. Ces niveaux mesurent la confirmation du réseau pour un bloc donné. Les trois options sont processed, confirmed et finalized.

Lorsqu'un validateur soumet un bloc à la chaîne, celui-ci se trouve dans l'état processed. Dès que le nombre requis de validateurs (66 % des validateurs) a voté pour inclure le bloc, celui-ci est ajouté à la chaîne et son niveau de confirmation passe à confirmed. Une fois que 31 blocs supplémentaires ont été construits par-dessus ce bloc, son niveau de confirmation passe à finalized.

Pourquoi les erreurs de blockhash se produisent-elles ?

Toutes les transactions incluent un blockhash récent qui sert d'horodatage. Une transaction expire lorsque son blockhash n'est plus considéré comme suffisamment récent. Les validateurs qui traitent les transactions consultent la « BlockhashQueue » (une liste des 300 derniers blockhashes) pour vérifier si le blockhash de la transaction est suffisamment récent. Si le blockhash ne figure pas dans la liste, la transaction est rejetée. Comme les slots durent généralement entre 400 et 600 ms, un blockhash reste valide pendant 60 à 90 secondes.

Blockhash introuvable (Échec de la simulation de la transaction : blockhash introuvable)

Les erreurs « Blockhash not found » surviennent lorsque le blockhash inclus dans une transaction n'est pas considéré comme valide au moment où un validateur traite cette transaction. Cela peut être dû au fait qu'il est trop ancien ou, dans certains cas, trop récent. 

La cause la plus fréquente de cette erreur est que le blockhash inclus dans une transaction ne figure pas dans la file des 300 derniers blockhashes auxquels le validateur le compare. Cela provoque l'erreur blockhash not found. Une transaction peut expirer lorsqu'elle est créée et traitée pendant la période requise. Cela peut notamment arriver lorsqu'un utilisateur met trop de temps à signer une transaction. Il peut également arriver qu'une transaction valide soit soumise, mais ne soit pas incluse dans le bloc actuel. Lorsqu'elle peut finalement être incluse dans un bloc ultérieur, le blockhash de la transaction est alors trop ancien.

Dans ce type de situation, où la transaction a effectivement expiré, il est courant de voir apparaître des erreurs de dépassement de hauteur de bloc (TransactionExpiredBlock heightExceededError). Pour mieux comprendre cette erreur, il faut savoir ce que signifie la hauteur de bloc. La hauteur de bloc désigne le nombre de blocs situés sous le bloc actuel. Si le bloc actuel est le bloc 1000, la hauteur de bloc est de 1000. Lorsqu'une transaction est créée, la hauteur de bloc maximale jusqu'à laquelle elle restera valide est enregistrée. Si, pendant le traitement de cette transaction, la hauteur du bloc actuel est supérieure à la hauteur de bloc maximale valide de la transaction, l'erreur est déclenchée.

Une autre situation susceptible de provoquer une erreur « blockhash not found » se produit lorsque le blockhash d'une transaction est plus récent que celui utilisé pour vérifier l'expiration de cette transaction. Cela peut sembler un peu déroutant, voici donc un exemple : vous créez une transaction et y incluez le blockhash d'un bloc donné, par exemple le bloc 1000, puis vous l'envoyez immédiatement à un RPC. Le RPC peut récupérer le blockhash du bloc précédent, ici le bloc 999, parce qu'il utilise un niveau de confirmation plus élevé ou parce que son nœud est en retard sur le réseau. Le blockhash de la transaction est alors introuvable. Cette situation est inhabituelle, mais elle peut se produire dans deux scénarios :

1. Niveaux de confirmation incompatibles

Lors de la création de la transaction, le niveau de confirmation confirmed est utilisé, mais lorsque le RPC calcule sa validité, il utilise par défaut le niveau finalized.

Le blockhash utilisé pour la vérification peut alors être plus ancien que celui de la transaction, car les blocs finalized ont 31 blocs de « retard » sur le dernier bloc.

Si le niveau de confirmation processed est utilisé pour récupérer le blockhash d'une transaction sur une fork minoritaire qui est ensuite abandonnée, le blockhash sera invalide et ne sera pas trouvé pendant le traitement.

2. RPC incompatibles

Si deux RPC différents sont utilisés pour récupérer le blockhash et envoyer la transaction, tout retard subi par le RPC chargé de l'envoi peut l'amener à vérifier la validité à partir d'un bloc plus ancien que celui utilisé lors de la création de la transaction.

Comment corriger les erreurs de blockhash

Quelques mesures permettent de gérer chacune des situations mentionnées ci-dessus.

1. Vérifiez qu'une transaction est soumise avec un blockhash qui n'est pas trop ancien :

Utilisez le niveau de confirmation confirmed lorsque vous récupérez le blockhash d'une transaction. Vous vous assurez ainsi d'inclure un blockhash plus récent qu'avec le niveau de confirmation finalized.

Vous pouvez également utiliser le niveau de confirmation processed pour obtenir un blockhash légèrement plus récent, mais environ 5 % des blocs processed ne sont pas finalisés par le cluster. Le blockhash de la transaction appartiendrait alors à une fork abandonnée et ne serait plus valide.

2. Vérifiez que le blockhash d'une transaction n'est pas plus récent que celui utilisé pour contrôler sa validité :

Définissez toujours preflightCommitment (même lorsque vous utilisez skipPreflight) sur le même niveau de confirmation que celui utilisé pour récupérer le blockhash de la transaction. Vous éviterez ainsi que le blockhash de la transaction soit plus récent que celui utilisé pour contrôler sa validité.

Pour gérer les nœuds RPC en retard lors de l'envoi de transactions, vous devez continuer à renvoyer les transactions au RPC. Vous pouvez le faire à intervalles réguliers afin que, si un RPC est en retard, il finisse par se synchroniser et détecter l'expiration de la transaction.

Si la requête simulateTransaction est utilisée, le paramètre replaceRecentBlockhash doit être défini. Cet indicateur demande au RPC de remplacer le blockhash de la transaction simulée par un blockhash qui sera toujours valide pour la simulation.

3. Continuez à réessayer la transaction tant que le blockhash est valide :

Lorsqu'une transaction est créée et que le dernier blockhash est récupéré, vous devez noter la valeur lastValidBlockHeight de ce blockhash. Vous pouvez ensuite continuer à réessayer la transaction avec ce blockhash jusqu'à ce que la hauteur du bloc actuel dépasse la hauteur de bloc valide de la transaction. L'appel RPC getBlockHeight permet de vérifier en continu si la transaction est toujours valide. Dès que la hauteur du bloc actuel dépasse la hauteur lastValidBlock de la transaction, vous devez récupérer et utiliser un nouveau blockhash.

J'espère que cet article vous aidera à mieux comprendre les erreurs de blockhash et à réduire leur fréquence. Si vous avez d'autres questions, n'hésitez pas à rejoindre notre communauté Discord ou à nous envoyer un message privé sur X.

Ressources supplémentaires :

• Documentation Solana — Transactions 
• Blog Helius — Slots, blocs et epochs

‍