Surveillance et Validation des Transactions sur Ethereum

Lorsqu’une transaction est effectuée sur une Blockchain, le réseau doit la valider avant de la reconnaître comme légitime. Il n’est pas toujours évident de déterminer le bon nombre de validations nécessaires pour assurer l’immuabilité d’une transaction (celui-ci peut différer d’une Blockchain à l’autre). L’exploitation de ces informations dans le cadre du développement d’applications implique des défis techniques que nous détaillerons ici.

Contexte

Une chaine de blocs est constituée d’une suite de x blocs numérotés sur l’ensemble [0;+inf[

Chacun de ces blocs contient y transactions numérotées sur l’ensemble [0;+inf[

Chacune de ces transactions contient z logs numérotés sur l’ensemble [0;+inf[

Un bloc est émis toutes les n secondes et contient un nombre y de transactions. Chacune de ces transactions correspond à une interaction sur la Blockchaine EVM. Autrement dit une transaction est le reflet d’un changement d’état. Les smartcontracts communiquent avec l’extérieur via des event dès qu’un event est émis il est stocké sur la transaction, ainsi une transaction contient un nombre z event (aussi appelé logs).

-- Bloc (x)
   -- Transaction (y)
      -- Log (z)

l’unicité d’une transaction sur la chaine canonique est : x,y
l’unicité d’un log sur la chaine canonique est : x,y,z

Remaniement de chaine

Une réorganisation de chaine est provoquée lorsque deux blocs sont publiés en même temps. Les réorganisations de 1 à 15 blocs se produisent souvent en raison de la latence du réseau et/ou d’une mauvaise synchronisation des validateurs. Cela augmente le retard des transactions et peut conduire à l’annulation de certaines d’entre elles. Il s’agit d’un problème important, car attendre un trop grand nombre de confirmations conduirait à une mauvaise UX mais à contrario considérer trop tôt un bloc comme sur pourrait résulter d’une perte de fond pour l’utilisateur.

Pour diverses raisons, il arrive que certains blocs soient invalidés à postériori. La chaine principale se sépare en 2 (fork) et les 2 blocs numérotés x coexistent en parallèle. Le consensus général devra décider lequel de ces 2 blocs fait état et poursuivre la liste chainée à partir de celui-ci. C’est ainsi que se définit la chaine canonique. Le moyen le plus efficace de s’assurer de la validité d’un bloc (au sens de sa persistance) est de compter le nombre de blocs existant devant lui (nombre de confirmation). En fonction des Blochaine et des mécanismes de consensus utilisés, cette valeur peut changer. Par exemple, sur la BSC 5 blocs de confirmations apparait comme suffisamment robuste , alors que sur Polygon 15 blocs sont nécessaires.

Ainsi en cas de fork il existera 2 blocs répondant à cette clé : x,y,z celui de la chaine canonique et celui de la chaine secondaire.

le blockhash est l’empreinte SHA256 de toutes les informations stockées dans le bloc, en cas de fork, les 2 blocs portant le même numéro x auront un blockhash différent.

le txid est l’empreinte SHA256 de toutes les informations stockées dans la transaction, il est probable qu’après un fork les 2 blocs portant le même numéro x ne contiennent pas les mêmes transactions. Par contre, si d’aventure, certaines transactions étaient présentes dans les 2 blocs elles auraient le même txid.

Stratégie de capture et de mise à jour des données

L’identification des transactions en double dues à une réorganisation de chaîne, ainsi que la gestion du temps de latence entre la publication de la transaction et sa validation par le réseau, sont des aspects importants à prendre en compte, en particulier dans le contexte de la création d’applications.

Gestion des Transactions en attente

La gestion des transactions sur la Blockchain est un défi pour les applications cherchant à allier réactivité et fiabilité. Dans un premier temps, il est essentiel de marquer ces transactions comme “en attente”. Ce n’est qu’après avoir atteint le seuil de confirmations nécessaire, qu’elles pourront être reclassifiées comme “confirmées” et jugées fiables.

Dans les cas où une réponse rapide de l’application est nécessaire, il est possible de commencer à traiter les transactions en attente. Cependant, ces traitements doivent être conçus de manière à être réversibles ou conditionnels, compte tenu du risque potentiel d’annulation de ces transactions. Il est crucial d’élaborer des stratégies permettant d’annuler ou de modifier les actions entreprises sur la base de transactions qui pourraient ultérieurement être annulées.

Gestion des transactions en double (reorgs)

Une surveillance continue est essentielle pour le suivi des transactions qui ont été traitées, permettant ainsi une réponse rapide en cas de réorganisation de chaîne. Il est possible de monitorer chaque transaction dès son apparition dans le bloc initial, en associant à chaque transaction son identifiant de bloc (blockhash) et son identifiant de transaction (txid). En cas de réorganisation de chaîne, le système peut identifier une modification du blockhash pour un numéro de bloc spécifique, signalant ainsi la possibilité d’une transaction dupliquée.

Si une telle transaction en double est repérée, il est essentielle de déterminer quelle version de la transaction appartient à la chaîne principale, ou chaîne canonique. Toute transaction qui ne figure pas dans la chaîne canonique doit être considérée comme non valide et être exclue des traitements de l’application.

Conclusion

En adoptant une approche stratégique qui équilibre la réactivité et la sécurité, et en utilisant des outils de suivi et de validation adaptés, les développeurs peuvent construire des applications robustes qui tirent pleinement parti des avantages uniques de la blockchain.