Ethereum et les contrats intelligents : des règles exécutées par le réseau

Imaginons un coffre numérique qui accepte un dépôt, puis autorise son retrait par une adresse déterminée. Le programme conserve les informations nécessaires et applique ses règles lorsqu’il reçoit une transaction. Les participants du réseau vérifient cette exécution. Une application peut ainsi proposer des échanges de jetons, des objets numériques ou une organisation collective autour de contrats.

Exécution et dépendances

L’utilisateur passe généralement par un site et un portefeuille. Le site présente les boutons ; le portefeuille affiche une demande de signature ; le contrat exécute l’action autorisée. Ces éléments restent distincts. Une interface ne prouve pas la qualité du programme, et une signature peut autoriser davantage qu’une simple connexion.

L’exécution mobilise des ressources mesurées en gas. Les frais sont réglés en ether et varient avec le travail demandé et la demande sur le réseau. Ethereum utilise la preuve d’enjeu : des validateurs immobilisent de l’ether pour participer au consensus, avec des récompenses et des pénalités prévues par le protocole. Cela ne signifie pas que tous les utilisateurs deviennent validateurs.

Un contrat intelligent n’est ni un juriste ni une intelligence capable de juger une situation. Il applique son code, y compris lorsqu’un défaut produit un résultat indésirable. Pour connaître un événement extérieur, il dépend d’informations apportées par des mécanismes, souvent appelés oracles. Certains contrats peuvent être modifiés grâce à des droits administratifs ; d’autres ne le peuvent pas. Comprendre une application suppose donc d’examiner ses autorisations, ses possibilités de mise à jour et ses dépendances. L’automatisation remplace certaines interventions humaines, sans faire disparaître les erreurs de conception ni tous les intermédiaires.

Une application en plusieurs couches

Une application utilisant Ethereum peut associer un site internet, un portefeuille et plusieurs contrats. L’écran facilite la lecture des actions possibles, tandis que les programmes déterminent les opérations exécutées sur le réseau. Si le site devient indisponible, cela ne signifie pas automatiquement que les contrats ont disparu. À l’inverse, une interface toujours accessible ne prouve pas que les programmes sous-jacents fonctionnent correctement. Cette distinction explique pourquoi l’expérience visible ne suffit pas à décrire toute une application.

Prenons un programme fictif qui distribue des points lorsqu’une condition informatique est remplie. Il applique les instructions prévues avec les données reçues, sans comprendre les intentions humaines derrière une demande. Une erreur de conception peut donc produire un résultat conforme au code mais contraire à ce que les utilisateurs imaginaient. Le caractère automatique décrit le mode d’exécution ; il ne constitue ni une appréciation de la pertinence du service ni une assurance sur sa fiabilité.

Exécution et pouvoir de modification

Tous les contrats ne présentent pas les mêmes possibilités d’évolution. Certains systèmes comportent des fonctions de mise à jour ou des paramètres administrables. Comprendre qui peut intervenir et sur quelles parties fait partie de la description technique d’un service. Il faut également distinguer une autorisation de jetons d’un transfert immédiat : la première peut permettre une action ultérieure. Enfin, un échec d’exécution et un refus de signature par l’utilisateur correspondent à des événements différents, malgré un résultat visuel parfois semblable.