Un smart contract, ou contrat intelligent, est un programme qui fonctionne sur la blockchain Ethereum. Il réunit du code et des données à une adresse Ethereum précise. Le code définit ses fonctions ; les données constituent son état. Ces trois éléments — code, état et adresse — permettent de comprendre concrètement ce que désigne cette expression.
Pour expliquer comment un utilisateur interagit avec ce programme, il faut ajouter un quatrième élément : l’appel d’une fonction au moyen d’une transaction. Ce guide présente cette relation, distingue le contrôle par clé privée du contrôle par le code et explique pourquoi les informations extérieures à Ethereum nécessitent un mécanisme d’apport distinct.
Code, état et adresse : la structure d’un smart contract
L’introduction aux smart contracts d’Ethereum décrit un contrat comme un ensemble de fonctions et de données situé à une adresse précise. Chaque élément répond à une question différente :
- Le code : quelles fonctions le programme définit-il ?
- L’état : quelles données appartiennent au contrat ?
- L’adresse : de quel contrat parle-t-on ?
Le mot « état » désigne ici des données. Dans un exemple pédagogique inventé, une variable appelée counter pourrait faire partie de cet état. Son nom indique comment elle est désignée dans l’exemple. Il ne précise ni sa valeur de départ ni les opérations qui pourraient la modifier.
Les fonctions relèvent du code. Leur nom facilite la discussion, mais il ne suffit pas à établir leur comportement. Pour comprendre un contrat particulier, il faut disposer d’informations sur les fonctions et les données concernées.
On peut déduire de cette structure une règle de lecture : l’adresse identifie le contrat étudié, tandis que ses fonctions et son état en décrivent des aspects différents. Donner uniquement une adresse laisse son comportement inexpliqué. Cette déduction ne constitue aucune garantie sur le contrat désigné.
Qui contrôle le compte : une clé privée ou le code ?
La documentation Ethereum sur les comptes distingue le compte détenu en externe (EOA) du compte de contrat. Dans le modèle EOA décrit, le contrôle appartient à la personne qui détient les clés privées. Un compte de contrat est contrôlé par le code de son smart contract.
Il faut conserver le sujet précis de chaque affirmation. La première décrit un mode de contrôle par clés privées ; la seconde désigne le code comme logique de contrôle. Aucune des deux ne permet, à elle seule, d’évaluer la sécurité d’un compte ou d’un programme particulier.
Le contrôle par le code ne signifie pas que les utilisateurs ne peuvent pas interagir avec le contrat. Deux questions restent distinctes : qui adresse une demande au programme, et quelle logique régit le comportement de ce programme ?
Pour approfondir le vocabulaire des identifiants sans le confondre avec celui des contrats, consultez notre guide sur les rôles respectifs de l’adresse, de la clé privée et de la phrase de récupération. Ici, l’objectif reste de distinguer les deux modèles de contrôle.
Que signifie appeler une fonction du contrat ?
Un compte utilisateur peut interagir avec un smart contract en soumettant une transaction qui appelle une fonction définie par ce contrat. À ce niveau d’explication, la relation essentielle associe donc un compte utilisateur, un contrat précis et l’une de ses fonctions.
Pour suivre une description d’interaction, posez trois questions :
- Quel compte utilisateur adresse la demande ?
- À quelle adresse de contrat cette demande est-elle destinée ?
- Quelle fonction définie par ce contrat est appelée ?
Ces questions décrivent le mécanisme d’interaction. Elles n’établissent ni la réussite de l’exécution ni une valeur particulière de l’état qui en résulterait. Dire qu’une transaction a été soumise doit donc rester une affirmation sur sa soumission, sauf si des éléments supplémentaires justifient une conclusion plus précise.
Cette distinction aide à lire une explication sans lui faire dire davantage que ce qu’elle démontre. Identifier une fonction appelée renseigne sur la demande décrite ; cela ne suffit pas à expliquer toutes ses conséquences.
Un exemple hypothétique avec une variable compteur
Imaginons un contrat fictif destiné uniquement à un exercice de compréhension. Posons qu’il contient une variable d’état nommée counter et une fonction nommée recordVisit. Ces noms désignent un programme hypothétique, et non un contrat réellement déployé.
On peut présenter cet exemple en trois lignes :
- Le contrat : le programme fictif situé à une adresse Ethereum non précisée.
- L’état : une variable appelée
counter. - La fonction : une fonction définie appelée
recordVisit.
Supposons maintenant qu’un compte utilisateur soumette une transaction appelant recordVisit. Nous avons relié le mécanisme d’interaction à la structure du programme : la demande concerne une fonction définie dans le contrat hypothétique.
À ce stade, aucune valeur finale ne peut être calculée à partir des seules hypothèses de l’exercice. Nous n’avons indiqué ni valeur initiale du compteur ni règle d’augmentation, ni même une modification particulière de la variable. Les noms counter et recordVisit ne remplacent pas une description de la logique.
La déduction est donc limitée : connaître l’existence d’une variable et d’une fonction nommée ne suffit pas à déterminer une valeur résultante. Il faudrait ajouter des hypothèses pour aller plus loin. Laisser cette valeur indéterminée permet de séparer ce que l’exercice énonce de ce que son lecteur pourrait imaginer.
Pourquoi les données extérieures nécessitent un oracle
Les smart contracts ne peuvent pas, à eux seuls, récupérer des données provenant de sources hors chaîne, dites offchain. Dans ce contexte, il s’agit d’informations extérieures à la blockchain. La précision « à eux seuls » est essentielle : cette limite n’exclut pas l’utilisation de données extérieures par une application blockchain.
La documentation Ethereum décrit les oracles comme des outils qui recueillent des données hors chaîne et les rendent disponibles aux smart contracts. Le contrat et le mécanisme qui lui fournit ces informations remplissent donc des rôles distincts dans l’explication.
Pour prolonger notre exemple hypothétique, imaginons que quelqu’un souhaite faire dépendre le compteur d’une présence enregistrée en dehors d’Ethereum. Cette proposition introduit un besoin de données extérieures. Le simple nom recordVisit n’explique pas comment cette information devient disponible pour le contrat.
On en déduit que l’explication doit préciser comment cette donnée est fournie : l’entrée envisagée est hors chaîne, et le contrat ne peut pas la récupérer seul. Le rôle d’approvisionnement d’un oracle ne permet toutefois pas, à lui seul, d’établir l’exactitude ou la fiabilité de l’information fournie.
Une liste de contrôle pour comprendre une explication
- Identifier le programme. Rattacher la description à Ethereum et au contrat dont il est question.
- Séparer code et état. Distinguer les fonctions des données, sans inventer de valeurs initiales.
- Préciser le contrôle. Distinguer le modèle EOA contrôlé par clés privées du compte de contrat contrôlé par le code.
- Nommer l’interaction. Repérer le contrat visé et la fonction appelée dans la description de la transaction.
- Limiter les conclusions aux éléments disponibles. Une soumission ne suffit pas à établir un résultat ; un nom de fonction ne suffit pas à expliquer son comportement.
- Repérer les données extérieures. Si l’explication utilise une information hors chaîne, demander comment elle devient disponible pour le contrat.
Cette liste sert à vérifier que les hypothèses d’une explication sont visibles. Les sources citées étayent les concepts présentés ; leur présence ne démontre pas la sécurité ou la correction d’un contrat particulier.
Article pédagogique préparé avec l’aide de l’IA. L’exemple fictif est un exercice de compréhension, sans recommandation d’effectuer une transaction ni de signer une demande dans un portefeuille.