Comment lire une transaction sur un explorateur de blocs comme Etherscan ? (Comprendre les détails)

Comprendre les bases des transactions

1. Chaque transaction sur Ethereum apparaît sous la forme d'un identifiant unique appelé hachage de transaction – une chaîne hexadécimale de 64 caractères commençant par « 0x ». Ce hachage sert d’empreinte digitale immuable de l’action entreprise en chaîne.

2. Le numéro de bloc indique quel bloc contient la transaction. Les blocs sont des unités de données séquentielles, et chacun comporte un horodatage, une difficulté et des mesures de consommation de gaz qui reflètent les conditions du réseau au moment de l'exécution.

3. L'état est affiché comme « Succès » ou « Échec ». Une transaction échouée consomme toujours du gaz et apparaît sur la chaîne mais ne modifie pas l'état des contrats ou des soldes intelligents.

4. Le champ « De » affiche l'adresse d'origine – toujours un compte externe (EOA), à moins qu'il ne soit déclenché par un contrat via un appel de délégué ou des mécanismes similaires.

5. Le champ « À » peut afficher une adresse de contrat, un autre EOA ou « Création de contrat » si la transaction a déployé un nouveau bytecode sur la chaîne.

Décryptage du gaz et des frais

1. Le prix du gaz est libellé en gwei et reflète le montant que l'expéditeur était prêt à payer par unité de gaz. Cela influence directement la priorité des transactions dans les pools de mémoire des mineurs/validateurs.

2. Le gaz utilisé représente les ressources de calcul réelles consommées pendant l'exécution, et non la limite. L'écart entre la limite de gaz et le gaz utilisé révèle des opportunités d'optimisation ou des retours inattendus.

3. Frais de transaction = Gaz utilisé × Prix du gaz — cette valeur est déduite du solde de l'expéditeur et distribuée aux validateurs dans le cadre d'incitations consensuelles.

4. Les frais de base par gaz apparaissent dans les transactions de mise à niveau post-Londres et sont brûlés, supprimant définitivement l'ETH de la circulation plutôt que de récompenser les mineurs.

5. Les frais prioritaires (ou pourboires) sont facultatifs et sont entièrement reversés aux validateurs pour encourager une inclusion plus rapide, en particulier en cas de congestion.

Analyse des données d'entrée et des appels de fonction

1. Les données d'entrée sont codées en hexadécimal et souvent illisibles sans décodage ABI. Lorsqu'une transaction interagit avec un contrat intelligent, les quatre premiers octets représentent le sélecteur de fonction dérivé du hachage keccak-256 de la signature de fonction.

2. Etherscan tente une détection automatique de l'ABI pour les contrats vérifiés et affiche des noms de fonctions lisibles par l'homme, tels que « transfert (adresse, uint256) » à côté des paramètres décodés.

3. Pour les contrats non vérifiés, les données d'entrée restent brutes hexadécimales : les analystes s'appuient sur des outils comme ABIDecoder ou de la rétro-ingénierie manuelle utilisant des normes connues telles que ERC-20 ou ERC-721.

4. Les transactions internes – pas de véritables événements blockchain mais des traces simulées – révèlent des transferts de valeur de contrat à contrat invisibles dans les champs de niveau supérieur. Ceux-ci apparaissent sous l'onglet « Txns internes ».

5. La présence de « 0x » suivi d'octets non nuls dans les données d'entrée signale presque toujours une interaction contractuelle, et non un simple transfert ETH .

Vérification des transferts de jetons et des événements

1. Les mouvements de jetons sont enregistrés en tant qu'événements émis par des contrats intelligents, et non en tant qu'opérations blockchain natives. Etherscan analyse ces journaux pour remplir la section « Tokens transférés ».

2. Chaque transfert de jeton inclut le De, le To, la valeur et l'adresse du contrat du jeton, permettant un suivi précis entre les portefeuilles et les protocoles.

3. Les transferts ERC-20 déclenchent des événements Transfer (adresse indexée depuis, adresse indexée vers, valeur uint256), tandis que ERC-721 émet des événements Transfer (adresse indexée depuis, adresse indexée vers, tokenId indexé uint256).

4. Les journaux d'événements sont stockés dans le reçu, et non dans la transaction elle-même, ce qui signifie qu'ils ne sont accessibles qu'après confirmation .

5. Des schémas inhabituels, tels que des transferts de valeur nulle vers des adresses inconnues ou des approbations répétées de contrats suspects, indiquent souvent un comportement de phishing ou de token malveillant.

Foire aux questions

Q : Pourquoi une transaction affiche-t-elle « Avertissement ! Erreur rencontrée lors de l'exécution du contrat » mais indique-t-elle toujours « Succès » ? R : Cela se produit lorsqu'un contrat génère une erreur en interne mais l'attrape à l'aide de try/catch ou annule conditionnellement sans interrompre l'intégralité de l'appel : l'état de niveau supérieur reflète le succès externe même si la logique interne échoue.

Q : Puis-je voir les informations de clé privée d'une transaction sur Etherscan ? R : Non. Les clés privées n’apparaissent jamais sur la chaîne. Seules les clés publiques et les signatures qui en dérivent sont visibles, et celles-ci ne peuvent pas être inversées pour récupérer des secrets.

Q : Que signifie « Nonce trop faible » dans une transaction en attente ? R : Cela signifie que la transaction utilise un nombre occasionnel inférieur au nombre occasionnel du compte courant, ce qui indique qu'il s'agit d'une tentative en double ou obsolète : les nœuds la rejettent catégoriquement.

Q : Comment savoir si un contrat a été vérifié sur Etherscan ? R : Les contrats vérifiés affichent un badge vert « Vérifié » à côté de l'adresse du contrat et fournissent des onglets pour « Code », « Lire le contrat » et « Écrire le contrat » — les contrats non vérifiés n'affichent que le bytecode.