Création de contrat Ethereum : code d’initialisation et adresse résultante

Une transaction de création de contrat sur Ethereum n’a pas d’adresse de destination ordinaire. Elle contient du code compilé, et un contrat déployé avec succès possède sa propre adresse. Ces affirmations décrivent deux aspects différents de la création : ce que la transaction précise et ce que le déploiement produit.

Pour comprendre cette distinction, séparons trois éléments : le champ de destination de la transaction, le code intervenant dans l’initialisation et le champ contractAddress du reçu. Cet article explique leur relation à partir d’un exemple hypothétique, sans procédure de déploiement. Pour les notions générales, consultez notre présentation du code, de l’état et des appels d’un smart contract.

Pourquoi une transaction de création n’a pas de destination ordinaire

Dans l’objet transaction décrit par la documentation JSON-RPC d’Ethereum, le champ to identifie normalement le destinataire. Pour une transaction de création de contrat, ce champ vaut null. Cette valeur signifie ici qu’aucune adresse de destinataire ordinaire ne figure dans ce champ ; elle ne constitue pas elle-même une adresse.

La documentation Ethereum sur le déploiement décrit la création au moyen d’une transaction contenant le code compilé du contrat, sans destinataire précisé. L’absence de destination prend ainsi un sens concret : la transaction concerne une création, plutôt qu’une demande adressée à un destinataire existant.

Il faut distinguer le concept de sa représentation. Une explication peut indiquer qu’aucun destinataire n’est précisé, tandis que l’objet renvoyé par JSON-RPC représente la destination par to: null. Lisez ce champ selon son rôle documenté. Il n’est pas nécessaire de le remplacer mentalement par l’adresse qui apparaît après une création réussie.

Code d’initialisation et code déployé : deux étapes distinctes

Dans cette explication conceptuelle, init code désigne le code intervenant à l’étape de création. Le code déployé désigne le code final du contrat, stocké après sa création. Cette terminologie est une déduction explicative tirée du processus documenté ; elle ne constitue pas une spécification complète du contenu de création.

Les prémisses proviennent de la documentation des contrats Solidity : un constructeur s’exécute une fois lors de la création du contrat ; il peut exécuter du code d’initialisation ; le code final du contrat est stocké après l’exécution du constructeur. Solidity précise également que le code déployé exclut le code du constructeur et les fonctions internes appelées uniquement depuis celui-ci.

Ces éléments permettent donc de distinguer le code utilisé pendant la création du code qui reste déployé. Ils ne justifient pas d’assimiler le constructeur, à lui seul, à l’intégralité de l’init code. Ils ne permettent pas non plus de supposer que le contenu compilé de la transaction est simplement une copie inchangée du code final déployé.

Imaginez deux dossiers dans un exercice pédagogique : l’un porte l’étiquette « code de création », l’autre « code final déployé ». Ces étiquettes organisent l’explication. Elles ne montrent ni les instructions individuelles, ni la structure complète du contenu, ni une comparaison octet par octet avec le résultat d’un compilateur particulier. À ce niveau, l’essentiel est de comprendre le rôle différent de chaque étape.

Où apparaît l’adresse du contrat créé ?

Une fois déployé, un contrat possède une adresse Ethereum. Dans le reçu de transaction documenté, contractAddress indique l’adresse du contrat créé lors d’une création ; dans les autres cas, ce champ vaut null. Le champ de destination et le champ de l’adresse créée doivent donc être lus séparément.

Le champ hash identifie la transaction. Cette identification ne suffit pas, à elle seule, à établir la réussite de la création ni à fournir l’adresse du contrat qui en résulte. Le champ décrivant ce résultat de création se trouve dans le reçu.

Le statut d’exécution compte également. Pour les reçus comportant status, la documentation définit 1 comme une réussite et 0 comme un échec. Elle décrit séparément les anciens reçus antérieurs à Byzantium, qui utilisent root ; l’explication du statut donnée ici concerne les reçus contenant status.

Le reçu d’une transaction en attente n’est pas disponible. Il ne faut donc pas supposer que l’enregistrement achevé de notre exemple existe déjà pendant cette attente. L’absence de reçu ne suffit toutefois pas à établir un diagnostic complet de la situation d’une transaction. Ces définitions des champs proviennent de la documentation JSON-RPC d’Ethereum.

Lire un enregistrement hypothétique de création

Prenons un exemple pédagogique inventé comprenant une transaction de création et le reçu correspondant. Posons comme hypothèse que la création s’est achevée avec succès. Les expressions « Transaction T » et « Adresse C » servent de repères : elles ne représentent ni un véritable hash ni une véritable adresse, et aucun calcul d’adresse n’est sous-entendu.

• Identifiant de la transaction : Transaction T.
• Destination de la transaction : to: null.
• Données d’entrée de la transaction : du code compilé intervenant à l’étape de création, selon l’hypothèse de cet exercice.
• Statut du reçu correspondant : 1, soit une réussite.
• Champ contractAddress du reçu correspondant : Adresse C.

La déduction étayée est que la destination null et l’adresse de création indiquée sont cohérentes entre elles. Ses prémisses sont la réussite posée par l’exercice et les significations documentées de to, status et contractAddress. La destination décrit le champ du destinataire de la transaction ; Adresse C décrit le résultat de création dans le reçu correspondant.

Cette déduction reste limitée aux hypothèses données. Elle ne permet pas d’établir qu’une transaction quelconque soumise au réseau s’est achevée avec succès. Elle ne précise pas non plus la valeur de chaque champ du reçu après une création échouée. Enfin, l’exemple ne fournit aucun code réel permettant d’analyser le comportement du contrat hypothétique.

Liste de contrôle pour interpréter une création

Voici les questions à poser lorsque vous étudiez un enregistrement de transaction fourni. Elles organisent les éléments nécessaires à cette interprétation précise :

1. Quel champ lisez-vous ? Distinguez le champ to de la transaction du champ contractAddress du reçu.
2. Que montre la destination ? Dans l’objet transaction de création documenté, la valeur attendue est null plutôt qu’une adresse de destinataire ordinaire.
3. De quelle étape du code parle-t-on ? Séparez l’initialisation du code final déployé, notamment lorsque le constructeur est mentionné.
4. Un reçu est-il disponible ? Les transactions en attente n’ont pas de reçu disponible.
5. Quel résultat les données permettent-elles d’établir ? Lorsque status est présent, lisez sa valeur de réussite ou d’échec avec le champ de l’adresse créée.
6. Quelles hypothèses subsistent ? Gardez visibles les repères fictifs, la réussite supposée et les détails manquants.

Le point central reste la relation entre la transaction de création, l’étape d’initialisation et l’adresse qui en résulte. Chaque champ répond à une question différente ; les réunir dans une explication ne dispense pas de respecter leurs limites respectives.

Article pédagogique préparé avec l’aide de l’IA. L’enregistrement inventé sert uniquement d’exercice de lecture.