Données d’entrée d’une transaction Ethereum : comprendre les octets et l’ABI

Les données d’entrée d’une transaction Ethereum constituent un champ facultatif qui peut contenir des données arbitraires. Dans un appel de fonction conforme à l’ABI standard, ces octets suivent une structure reconnaissable : un sélecteur de fonction, puis les arguments encodés. Leur interprétation nécessite le schéma d’interface correspondant.

Pour les lire utilement, il faut séparer trois questions : quels octets sont présents, comment un schéma donné les interprète et quelles conclusions restent non établies. Une entrée vide, un sélecteur reconnaissable et un nombre décodé ne répondent chacun qu’à une partie de ces questions.

Ce que contient le champ input

La documentation Ethereum sur les transactions décrit les données d’entrée comme facultatives et susceptibles de contenir des données arbitraires. Cette définition générale compte : toutes les entrées possibles ne sont pas tenues de suivre la convention des appels de fonction ABI. Commencez par les octets effectivement présents avant de leur attribuer un nom de fonction ou un type d’argument.

Pour les tableaux d’octets, l’interface JSON-RPC d’Ethereum emploie une représentation hexadécimale précédée de 0x, avec deux chiffres hexadécimaux par octet. Les conventions d’encodage JSON-RPC distinguent cette représentation DATA du format des quantités numériques. Conservez cette distinction lorsque vous lisez un champ d’entrée.

Dans la représentation des tableaux d’octets, 0x désigne une séquence vide : aucun octet de données ne suit le préfixe. Ce n’est pas l’encodage de la quantité numérique zéro. Décrivez donc cette valeur comme une entrée vide, plutôt que comme un nombre à décoder.

Comment s’articulent sélecteur et arguments

La spécification ABI de Solidity place le sélecteur de fonction dans les quatre premiers octets des données d’un appel de fonction standard. Les arguments encodés suivent à partir du cinquième octet, lorsque des arguments sont présents. Cette organisation ne signifie pas que toutes les fonctions exigent des arguments, et elle ne décrit pas toutes les séquences d’entrée arbitraires.

Le sélecteur correspond aux quatre premiers octets du hachage Keccak-256 de la signature canonique de la fonction. Cette signature comprend le nom de la fonction suivi des types des paramètres entre parenthèses, séparés par des virgules sans espaces. Les types doivent employer leur représentation ABI canonique ; les valeurs particulières des arguments ne font pas partie de cette signature.

Prenons une fonction inventée pour un exercice, avec un seul paramètre uint256, dont la signature canonique serait record(uint256). Cette signature indique le nom de la fonction et le type du paramètre dans l’exercice. Une valeur particulière, comme 6, appartient à la zone des arguments encodés. Nous ne calculons ni n’affirmons ici de valeur de sélecteur pour cette fonction fictive.

Lorsque vous annotez un appel ABI standard, distinguez le sélecteur de la zone des arguments. Vous gardez ainsi la description de l’interface à côté des octets qu’elle sert à interpréter. Pour comprendre le programme auquel l’appel s’adresse, consultez notre guide sur le code, l’état et les appels d’un smart contract.

Pourquoi le schéma ABI est nécessaire

L’encodage ABI n’est pas auto-descriptif. Son décodage nécessite un schéma qui fournit la structure et les types pertinents. Une ABI adaptée au contrat apporte ces informations, même si un fichier JSON particulier n’est pas la seule manière de représenter les connaissances nécessaires sur les types.

Cette exigence peut passer inaperçue lorsqu’un outil affiche un nom de fonction familier. La documentation Ethereum illustre l’ambiguïté des sélecteurs avec 0xa9059cbb : elle mentionne plusieurs fonctions candidates connues pour ce sélecteur. Cet exemple étaye la possibilité de plusieurs correspondances. Il n’établit pas que chaque sélecteur possède plusieurs correspondances connues.

Une recherche par sélecteur doit donc rester une étape d’identification de candidats tant que l’interface du contrat destinataire n’est pas établie. Dans un exercice de lecture, notez l’origine du schéma. S’il est simplement posé comme hypothèse, rendez cette hypothèse visible. S’il demeure inconnu, laissez l’interprétation des types en suspens au lieu de présenter une désignation plausible comme établie.

Un argument hypothétique qui se décode en 6

Considérons un exercice hypothétique reposant sur trois hypothèses explicites : l’entrée est correctement formée selon l’ABI standard, son sélecteur correspond à la fonction visée et cette fonction possède exactement un argument uint256. Après les quatre octets du sélecteur, l’exercice fournit ce mot d’argument :

0000000000000000000000000000000000000000000000000000000000000006

Ce mot contient 31 octets nuls suivis de 06. L’encodage ABI standard représente les entiers non signés pris en charge par des valeurs de 32 octets, en ordre gros-boutiste, complétées à gauche par des octets nuls. Cette règle s’applique à ces types entiers dans l’encodage ABI standard ; ce n’est pas une règle générale de décodage pour tous les types de données ou toutes les entrées de transaction arbitraires.

La déduction est conditionnelle : le schéma posé en hypothèse identifie le mot qui suit le sélecteur comme un uint256, puis la règle d’encodage des entiers non signés donne l’entier 6. La position de l’argument, le schéma de types et la règle d’encodage étayent ensemble cette interprétation.

Retirons maintenant le schéma de l’exercice. Puisque l’encodage n’est pas auto-descriptif, le mot se terminant par 06 ne suffit pas, à lui seul, à établir que son type est uint256. Des informations supplémentaires sur l’interface pourraient établir ce type, mais les octets seuls ne fournissent pas cette prémisse manquante. L’exemple n’établit pas non plus qu’une transaction réelle a eu lieu ou a été exécutée.

Ce qu’une entrée vide permet d’établir, et ses limites

Une entrée vide contient zéro octet, tandis qu’un sélecteur ABI standard en nécessite quatre. De ces deux prémisses, on déduit qu’une entrée vide ne contient aucun sélecteur de fonction ABI standard. Cette conclusion porte sur les octets disponibles. Elle ne permet pas de déterminer le type du compte destinataire.

La documentation Ethereum décrit séparément une transaction adressée à un compte de contrat comme exécutant le code du contrat. Cette affirmation générale ne précise pas le chemin de traitement emprunté et n’établit pas la réussite de l’exécution.

Pour un second exercice hypothétique, posons que le destinataire est un compte de contrat et que l’entrée est vide. L’absence d’octets de sélecteur et la règle relative au destinataire de type contrat peuvent toutes deux s’appliquer. La déduction reste limitée : l’absence de sélecteur n’implique pas l’absence d’exécution de code de contrat. Déterminer le chemin de traitement particulier ou le résultat nécessiterait des éléments supplémentaires.

Liste de contrôle pour lire les données d’entrée

1. Identifier la représentation. Lire le champ comme des données DATA constituées d’octets, en distinguant le format des quantités numériques.
2. Vérifier si l’entrée est vide. Noter que 0x correspond à zéro octet d’entrée, sans en déduire un type de destinataire ou un résultat d’exécution.
3. Établir la convention d’encodage. Appliquer la structure sélecteur et arguments uniquement lorsque l’encodage des appels de fonction ABI standard est l’hypothèse pertinente.
4. Consigner le schéma. Identifier les éléments qui établissent l’interface, ou indiquer clairement les types de paramètres posés en hypothèse.
5. Présenter les noms candidats avec leurs réserves. Une recherche par sélecteur peut être ambiguë et ne suffit pas à établir l’interface du destinataire.
6. Expliquer chaque déduction. Relier une valeur décodée à la position de son argument, au schéma de types et à la règle d’encodage.

Ces questions aident à interpréter les octets avec précision. La liste organise la lecture ; elle ne certifie pas la sécurité d’un contrat. L’attribution des sources indique sur quoi repose l’explication, sans établir la sécurité d’une interaction particulière.

Article pédagogique préparé avec l’aide de l’IA. Les exemples hypothétiques expliquent le décodage des données d’entrée et ne constituent pas une recommandation d’action financière.