La machine virtuelle Ethereum, ou EVM pour Ethereum Virtual Machine, est l’environnement d’exécution des contrats intelligents sur Ethereum. Pour comprendre son rôle, suivons trois éléments : un contrat contient du bytecode compilé, l’EVM exécute ce code sous forme d’instructions et l’état d’Ethereum évolue selon des règles définies. Le gas mesure le travail de calcul et limite les ressources qu’une transaction peut utiliser.
Cette description explique le traitement d’un contrat, sans garantir que l’application atteindra le résultat souhaité. Les questions utiles sont concrètes : quel code s’exécute, quelles informations stockées sont concernées et que se passe-t-il si le budget d’exécution est épuisé ?
Ce que la machine virtuelle Ethereum exécute
Il faut distinguer un programme de son environnement d’exécution. Le contrat intelligent fournit le code ; l’EVM définit les règles permettant de l’exécuter. La documentation Ethereum sur l’EVM décrit des comptes de contrat contenant du bytecode compilé. Lorsqu’un autre compte adresse un appel au contrat, ce bytecode s’exécute.
Le bytecode est la forme compilée du programme. Il s’exécute au moyen d’instructions EVM appelées opcodes. On peut donc considérer le bytecode comme le programme encodé et les opcodes comme les instructions élémentaires qui réalisent son traitement. Comprendre cette relation est plus utile, pour débuter, que mémoriser une liste d’instructions.
Dans une présentation de contrat, séparez ainsi sa fonction annoncée de son comportement effectif. Dire qu’un contrat sert à enregistrer une valeur décrit son objectif. Expliquer les instructions exécutées et la valeur finalement conservée décrit son fonctionnement.
L’EVM n’est ni un portefeuille ni l’algorithme de consensus d’Ethereum. Son rôle est ici l’exécution des contrats. La formule « traité par l’EVM » ne suffit donc pas à établir tout ce qui concerne une interaction avec une application.
Les transitions d’état suivent des règles
L’état d’Ethereum comprend les comptes, les soldes et le stockage des contrats. L’EVM définit les règles de changement de cet état. La documentation présente cette relation sous la forme Y(S, T) = S' : un état initial valide et des transactions valides produisent un nouvel état valide selon les règles de transition.
Cette formule relie des données d’entrée, des règles et un résultat. L’état initial fournit le contexte de départ. Les transactions apportent les instructions à traiter. Les règles déterminent l’état obtenu. La seule description de l’objectif d’un contrat laisse donc de côté son contexte initial.
La fonction de transition est décrite comme déterministe : ses données d’entrée et les règles applicables déterminent son résultat. Le déterminisme ne garantit pas la réussite attendue par l’utilisateur. Reproduire un traitement et satisfaire un objectif sont deux questions différentes.
Une déduction limitée découle de deux éléments documentés : les transitions respectent les règles du protocole, et une exécution peut épuiser son gas, entraînant l’annulation de ses changements. Une transition d’état valide ne garantit donc pas qu’un appel de contrat atteigne son objectif. Il s’agit d’une déduction fondée sur ces éléments, et non d’une promesse contenue dans la formule.
Le stockage persistant fait partie de l’état
Le stockage persistant d’un contrat est associé à son compte et appartient à l’état global d’Ethereum. Il permet, conceptuellement, de conserver des informations plutôt que de calculer seulement un résultat intermédiaire.
La distinction essentielle oppose l’exécution d’instructions à la modification persistante effectivement obtenue. Mentionner une opération d’écriture ne suffit pas à établir que la mise à jour souhaitée a pris effet. Il faut encore des éléments concernant la valeur stockée après le traitement.
Toutes les données utilisées pendant l’exécution ne sont pas persistantes. La documentation distingue notamment le stockage du contrat de la mémoire d’exécution, qui ne subsiste pas entre les transactions. Sans entrer dans la structure technique du stockage, retenez deux questions : quelles informations appartiennent à l’état persistant du contrat, et qu’est-ce qui établit leur valeur finale ?
Le gas mesure le travail et borne le budget
Le gas mesure l’effort de calcul nécessaire aux opérations Ethereum. La limite de gas d’une transaction fixe la quantité maximale de gas fournie pour son traitement. Le gas constitue ainsi l’unité de mesure ; la limite borne le budget disponible.
La documentation définit aussi les frais à partir du gas utilisé et d’un coût par unité. On en déduit que la limite de gas et le prix unitaire sont deux grandeurs distinctes : une quantité maximale d’un côté, un coût par unité de l’autre. Ici, l’objectif est de comprendre le budget de calcul, sans détailler les tarifs des opcodes ni calculer des frais. Fournir un budget ne garantit pas le résultat demandé au contrat.
Gas intrinsèque insuffisant : rejet à la validation
La documentation Ethereum sur le gas distingue une transaction dont le gas intrinsèque est insuffisant pour passer la validation d’une transaction qui épuise son budget pendant l’exécution. Dans le premier cas décrit, la transaction est rejetée avant son inclusion dans un bloc et aucun gas n’est consommé.
La source illustre ce rejet par un simple transfert d’ETH dont la limite est inférieure au minimum requis pour la validation. Cet exemple ne définit pas le gas nécessaire à toutes les opérations de contrat. La distinction importante est le rejet avant l’exécution.
Épuisement du gas pendant l’exécution
Dans le cas d’épuisement du gas à l’échelle de la transaction décrit par la source, l’exécution commence puis consomme tout le budget fourni. L’EVM annule les changements de cette exécution, tandis que tout le gas fourni est consommé pour le travail effectué.
Cette explication concerne précisément cet épuisement du gas, pas toutes les causes possibles d’échec. Elle n’établit aucune récupération d’actifs, aucune annulation de la consommation de gas ni le traitement des échecs survenant dans des appels internes particuliers.
Exemple hypothétique : un compteur stocké
Exemple entièrement hypothétique : imaginons un contrat pédagogique dont le stockage persistant contient un compteur égal à 7. L’opération prévue doit le faire passer à 8. Le contrat et ces valeurs sont inventés pour l’explication ; aucune transaction réelle n’est nécessaire.
- Identifier le programme : le contrat contient du bytecode compilé, exécuté sous forme d’opcodes lors de l’appel.
- Identifier l’état initial : le compteur vaut 7 dans le stockage persistant.
- Préciser l’objectif : l’exercice attend une valeur finale de 8.
- Examiner la limite du budget : si la transaction épuise son gas pendant l’exécution, les changements de cette exécution sont annulés et tout le gas fourni est consommé.
Décrire la mise à jour souhaitée ne suffit donc pas. Il faut distinguer la valeur initiale, le traitement exécuté et la valeur finalement stockée. Dans la variante où le gas est épuisé, le seul démarrage de l’exécution n’établit pas que le compteur a été mis à jour.
Distinguer exécution et accord du réseau
Le client d’exécution traite les transactions dans l’EVM. Le client de consensus met en œuvre l’accord par preuve d’enjeu à partir des données validées par le client d’exécution. La documentation sur les nœuds et les clients présente cette répartition.
L’exécution concerne les instructions et l’état ; le consensus concerne l’accord du réseau à partir des données validées. Pour approfondir les rôles logiciels, consultez notre article sur les nœuds et clients Ethereum. Les étapes de vérification sont développées séparément dans notre explication de la validation d’une transaction Ethereum.
Pour évaluer une explication de l’EVM, utilisez cette liste de contrôle :
- Identifier le code compilé et l’opération prévue.
- Préciser l’état initial et le stockage persistant concernés.
- Distinguer une transition conforme aux règles des preuves du résultat attendu.
- Séparer le budget de gas du prix par unité.
- Distinguer le rejet pour gas intrinsèque insuffisant de l’épuisement pendant l’exécution.
- Garder séparés le traitement dans l’EVM et l’accord du réseau.
Ces questions aident à interpréter une description technique. Un lien vers une source ne suffit pas, à lui seul, à établir la sécurité d’un contrat particulier.
Article pédagogique préparé avec l’aide d’une IA. L’exemple est hypothétique et ne demande ni d’envoyer une transaction ni de signer une requête dans un portefeuille.