La machine virtuelle Ethereum (EVM) est une machine virtuelle quasi-Turing-complète, basée sur une pile, qui sert d'environnement d'exécution pour les contrats intelligents sur la blockchain Ethereum et tous les réseaux compatibles EVM. Véritable moteur de calcul au cœur d'Ethereum, elle traite chaque transition d'état – des simples transferts d'ETH aux interactions complexes des protocoles de finance décentralisée (DeFi) – de manière déterministe et isolée, garantissant ainsi que chaque nœud du réseau obtienne le même résultat pour une transaction donnée.
La machine virtuelle Elastic (EVM) fonctionne en exécutant des instructions de bas niveau appelées opcodes, compilées en bytecode à partir de langages de programmation de haut niveau tels que Solidity et Vyper. Chaque opcode effectue une opération atomique spécifique : calculs arithmétiques, manipulation de la mémoire, lectures et écritures, hachage cryptographique et logique de contrôle. Lorsqu'un utilisateur ou un contrat initie une transaction appelant un contrat intelligent, l'EVM charge le bytecode du contrat depuis l'arbre d'état de la blockchain et le traite instruction par instruction, consommant une ressource mesurée appelée « gas » pour chaque opération. Ce mécanisme de mesure du gaz empêche les boucles infinies et le gaspillage de ressources en obligeant l'expéditeur de la transaction à payer pour la puissance de calcul requise par celle-ci.
Point essentiel, la machine virtuelle Ethereum (EVM) est conçue pour être totalement déterministe et isolée. Avec des entrées identiques et un état de la blockchain identique, chaque nœud exécutant l'EVM produira exactement la même sortie. Ce déterminisme permet à des milliers de nœuds à travers le monde de vérifier indépendamment les transactions et de maintenir un consensus sur l'état global du réseau Ethereum. La conception en environnement isolé de l'EVM garantit également que l'exécution des contrats intelligents ne peut accéder ni au système de fichiers, ni au réseau, ni au système d'exploitation de la machine hôte, empêchant ainsi les contrats malveillants de compromettre les nœuds qui les exécutent.
L'influence de la machine virtuelle Ethereum (EVM) dépasse largement le cadre d'Ethereum. Son architecture est devenue la norme de facto pour l'exécution des contrats intelligents dans l'ensemble du secteur de la blockchain. Des réseaux majeurs tels que BNB Smart Chain (BSC), Polygon, Avalanche C-Chain, Arbitrum, Optimism, Fantom, Cronos et des dizaines d'autres ont adopté la compatibilité EVM, permettant ainsi aux développeurs de déployer les mêmes contrats intelligents Solidity sur plusieurs chaînes avec un minimum de modifications. Cette compatibilité inter-chaînes a créé un vaste écosystème d'outils partagés, de connaissances pour les développeurs et de protocoles composables qui, ensemble, constituent l'épine dorsale de l'écosystème des applications décentralisées (dApps).
Origine & Histoire
2013: Vitalik Buterin a publié le livre blanc d'Ethereum, proposant une blockchain dotée d'un langage de programmation Turing-complet intégré, capable d'exécuter des contrats intelligents arbitraires. Ce livre blanc a exposé le concept de machine virtuelle comme couche d'exécution, distinguant ainsi Ethereum du langage Script limité de Bitcoin.
2014: Gavin Wood est l'auteur du Livre Jaune d'Ethereum, qui spécifie formellement l'architecture de la machine virtuelle Ethereum (EVM) en termes mathématiques rigoureux. Ce document définit le jeu d'instructions, les coûts en gaz, la fonction de transition d'état et le modèle de mémoire qui régissent l'exécution des contrats intelligents. Cette spécification formelle est devenue la référence pour toutes les implémentations de l'EVM.
2015: Ethereum a été lancé le 30 juillet avec la version Frontier. La machine virtuelle Ethereum (EVM) a été mise en service avec son ensemble initial d'environ 140 opcodes, permettant ainsi l'exécution des premiers contrats intelligents sur une blockchain publique. Les premiers contrats étaient simples – émetteurs de jetons et portefeuilles multisignatures – mais ils ont démontré la viabilité de l'EVM en tant que moteur de calcul à usage général.
2016: Le piratage de la DAO le 17 juin a révélé une faille critique de réentrance dans la conception des contrats intelligents de l'EVM. Environ 60 millions de dollars d'ETH (soit environ 3.6 millions d'ETH) ont été dérobés au contrat de la DAO grâce à une exploitation d'appels récursifs. Bien que la vulnérabilité se situât dans le code du contrat intelligent et non dans l'EVM elle-même, cet incident a catalysé des recherches approfondies sur les modèles de sécurité de l'EVM et a conduit au développement des modèles de conception CEI (Checks-Effects-Interactions) et de protection contre la réentrance. Ses répercussions ont également mené à la bifurcation dure controversée d'Ethereum, qui a scindé la chaîne en Ethereum (ETH) et Ethereum Classic (ETC).
2017-2018: L'essor des ICO a entraîné une adoption massive des contrats intelligents Ethereum, mettant à rude épreuve la machine virtuelle Ethereum (EVM) à une échelle sans précédent. Le standard de jeton ERC-20 est devenu le type de contrat le plus répandu, et l'EVM a traité des millions de transferts de jetons. CryptoKitties (décembre 2017) a notamment provoqué une congestion du réseau, révélant les limitations de débit de l'EVM.
2019-2020: L'été 2020, marqué par l'essor de la DeFi, a propulsé des protocoles comme Uniswap, Aave et Compound sur le devant de la scène, contraignant l'EVM à gérer des interactions multi-contrats de plus en plus complexes. Les prix du gaz ont explosé, atteignant des centaines de gwei, et l'optimisation du gaz sur l'EVM est devenue une compétence essentielle pour les développeurs Solidity.
2021-2022: Les chaînes compatibles avec l'EVM ont connu un succès fulgurant. BSC, Polygon, Avalanche, Fantom et Arbitrum ont chacun lancé des environnements d'exécution compatibles avec l'EVM, permettant aux développeurs de porter des dApps Ethereum avec un minimum d'efforts. Le terme « compatible EVM » est devenu un argument marketing incontournable pour les nouvelles chaînes de couche 1 et de couche 2.
2022-2024: La transition d'Ethereum vers le protocole Proof-of-Stake (septembre 2022) n'a pas modifié l'EVM elle-même, mais a transformé la couche de consensus sous-jacente. Les recherches sur les architectures de remplacement de l'EVM se sont intensifiées, avec des propositions de mise à niveau vers l'EOF (EVM Object Format) et des discussions sur une éventuelle migration vers des environnements d'exécution basés sur eWASM ou RISC-V. La mise à niveau Dencun (mars 2024) a introduit les transactions blob EIP-4844, étendant ainsi les capacités de disponibilité des données de l'EVM pour les rollups.
En termes simples
Imaginez l'EVM comme une calculatrice géante partagée exécutant le même programme sur des milliers d'ordinateurs simultanément. Chaque ordinateur obtient exactement le même résultat car les règles de la calculatrice sont parfaitement définies. Si quelqu'un tente de tricher, tous les autres ordinateurs le détectent immédiatement car leurs réponses diffèrent.
Imaginez un distributeur automatique doté d'un mode d'emploi très détaillé. Lorsque vous insérez des pièces (de l'essence) et appuyez sur des boutons (effectuez une transaction), la machine suit ses instructions étape par étape pour vous délivrer votre article (exécuter le contrat). Ce mode d'emploi est identique pour tous les distributeurs automatiques du monde ; vous savez donc toujours à quoi sert chaque bouton.
La machine virtuelle Ethereum (EVM) fonctionne comme un traducteur universel pour les contrats intelligents. Un développeur écrit du code dans un langage lisible par l'humain (Solidity), l'EVM le traduit en instructions machine (bytecode), et chaque nœud Ethereum interprète ce même langage machine. C'est pourquoi un contrat écrit une seule fois peut s'exécuter sur Ethereum, Polygon, BSC et Arbitrum sans avoir besoin d'être réécrit.
Imaginez un service de séquestre notarié avec un robot incorruptible comme agent. Vous lui fournissez des règles précises (« libérer les fonds uniquement après signature des deux parties »), et il les exécute à la lettre : ni pots-de-vin, ni erreurs, ni interruption de service. L’EVM est ce robot, et les règles sont le code du contrat intelligent.
C'est comme une machine d'arcade où chaque partie coûte des jetons. Les parties simples (transferts basiques) coûtent peu de jetons, tandis que les parties complexes (échanges DeFi via plusieurs pools) en coûtent beaucoup plus. Si vous n'avez plus de jetons en cours de partie, la machine s'arrête et la partie est terminée ; vous ne récupérez pas vos jetons. C'est le principe du « gas » dans l'EVM.
Important: La machine virtuelle Elastic (EVM) est déterministe, mais non infaillible. Des bogues dans le code des contrats intelligents déployés sur l'EVM peuvent entraîner des failles de sécurité et des pertes financières. L'EVM exécute les instructions à la lettre ; si celles-ci sont erronées, les résultats le seront également. Il est donc impératif d'auditer systématiquement les contrats intelligents avant toute interaction, surtout lorsque des enjeux financiers importants sont en jeu.
Caractéristiques techniques clés
Architecture basée sur une pile
L'EVM utilise une pile LIFO (dernier entré, premier sorti) d'une profondeur maximale de 1 024 éléments.
Chaque élément de la pile a une largeur de 256 bits (32 octets), correspondant à la taille de mot native d'Ethereum.
Les opérations arithmétiques et logiques dépilent les opérandes et empilent les résultats.
La conception basée sur une pile simplifie la vérification formelle et maintient l'implémentation compacte.
Contrairement aux machines virtuelles à registres (telles que LLVM), l'architecture à pile évite la complexité de l'allocation des registres.
Jeu d'instructions d'opcode
L'EVM définit plus de 140 opcodes organisés en catégories : opérations arithmétiques, de comparaison, bit à bit, de hachage, d'environnement, de bloc, de pile/mémoire/stockage, de journalisation, système et opérations push/dup/swap
Les principaux codes d'opération comprennent ADD, MUL, SLOAD, SSTORE, CALL, DELEGATECALL, CREATE, CREATE2, SELFDESTRUCT, LOG0-LOG4 et REVERT
Chaque opcode a un coût de gaz fixe ou dynamique défini dans le Livre jaune, mis à jour par le biais des EIP (par exemple, l'EIP-2929 a augmenté les coûts d'accès au stockage frigorifique).
Le DELEGATECALL L'opcode active le modèle de proxy, qui est fondamental pour les contrats intelligents évolutifs.
Fonctionnement de l'exécution EVM
Une transaction est soumise au réseau ciblant une adresse de contrat avec des données d'appel spécifiant la fonction et les paramètres
L'EVM charge le bytecode du contrat cible depuis l'arbre d'état du monde dans son contexte d'exécution
Une nouvelle trame d'exécution est créée avec de la mémoire allouée, une pile vide et la limite de gaz de la transaction.
Le compteur de programme démarre à l'octet 0, et l'EVM lit et exécute les codes d'opération séquentiellement.
Chaque opcode consomme du gaz en fonction de son coût défini ; si le gaz vient à manquer, l'exécution s'interrompt avec une exception « manque de gaz » et toutes les modifications d'état sont annulées.
Lorsque l'exécution se termine avec succès, les modifications d'état (écritures dans le stockage, transferts de solde, déploiements de nouveaux contrats) sont enregistrées dans l'état global.
Un reçu de transaction est généré, contenant l'état d'exécution, le gaz utilisé, les journaux d'événements émis et toutes les données de retour.
Système de comptage du gaz
Le gaz sert d'unité d'effort de calcul, chaque opcode étant tarifé proportionnellement à sa consommation de ressources.
Des opérations simples comme ADD coût 3 gaz, tandis que le stockage écrit (SSTORELe coût est de 5 000 à 20 000 unités de gaz, selon que l'emplacement soit initialisé à zéro ou modifié.
Le coût de transaction de base est de 21 000 unités de gaz, avec des coûts supplémentaires pour les données d'appel (4 unités de gaz par octet nul, 16 unités de gaz par octet non nul).
Le projet EIP-1559 (mise à niveau de Londres, août 2021) a introduit des frais de base qui sont brûlés, plus des frais de priorité optionnels (pourboire) versés au constructeur du bloc.
La limite de gaz par bloc (environ 30 millions en 2024) plafonne la puissance de calcul totale par bloc, limitant ainsi le débit de l'EVM.
Modèle de mémoire et de stockage
Pile : Pile LIFO volatile de 1024 éléments pour les calculs intermédiaires – utilisation gratuite mais profondeur limitée
Mémoire : mémoire linéaire volatile, adressable par octet, extensible selon les besoins – le coût en gaz est proportionnel au carré de la taille allouée.
Stockage : Stockage persistant de clés-valeurs de 256 bits associé à chaque adresse de contrat – la ressource la plus coûteuse (20 000 unités de gaz pour une nouvelle écriture dans un emplacement).
Données d'appel : données d'entrée en lecture seule associées à la transaction – moins coûteuses que la mémoire et le stockage, utilisées pour les paramètres de fonction
Avantages désavantages
Avantages
Désavantages
Portabilité inter-chaînes : les contrats intelligents écrits pour l’EVM peuvent être déployés sur des dizaines de chaînes compatibles avec l’EVM (BSC, Polygon, Avalanche, Arbitrum, Optimism) avec des modifications minimales.
Limitations de performance : L’architecture basée sur une pile et le modèle d’exécution séquentielle limitent le débit à environ 15 à 30 transactions par seconde sur le réseau principal Ethereum.
Un vaste écosystème de développeurs : Solidity est le langage de contrats intelligents le plus connu, avec de nombreux outils (Hardhat, Foundry, Remix, OpenZeppelin) et ressources pour les développeurs.
Coûts de gaz élevés : les opérations complexes sur le réseau principal Ethereum peuvent coûter des centaines de dollars en frais de gaz lors des pics de congestion, ce qui exclut les petits utilisateurs.
Sécurité éprouvée au combat : Après près d’une décennie d’utilisation en production et des milliards de dollars sécurisés, la spécification de base de l’EVM a démontré une résistance remarquable face aux attaques directes.
Surcharge liée à la taille des mots de 256 bits : La taille native des mots de 256 bits est excessive pour la plupart des opérations, gaspillant des ressources en remplissage et augmentant les coûts en gaz pour des calculs simples.
Exécution déterministe : résultats identiques garantis sur tous les nœuds, permettant une vérification et un consensus sans confiance et sans coordination centrale.
Modèle de calcul limité : absence de prise en charge native de l’arithmétique à virgule flottante, du parallélisme ou de l’accès aux données hors chaîne, ce qui nécessite des solutions de contournement pour de nombreux cas d’utilisation concrets.
Spécification formelle : Le document de Gavin Wood, intitulé « Yellow Paper », fournit une spécification mathématique rigoureuse, permettant de multiples implémentations indépendantes (Geth, Nethermind, Besu, Erigon) parfaitement interopérables.
Immuabilité des contrats intelligents : une fois déployé, le bytecode ne peut plus être modifié ; les bugs deviennent permanents, sauf si des modèles de proxy (qui ajoutent de la complexité et des risques) sont utilisés.
Composabilité riche : L’interface standardisée de l’EVM permet aux contrats d’interagir de manière fluide, rendant possible la composabilité « brique monétaire » de la DeFi.
Surcharge de stockage : le stockage de l’état persistant croît indéfiniment. Les besoins en stockage des nœuds complets standard sont moindres grâce à l’élagage, mais les nœuds d’archivage spécialisés (qui stockent l’historique complet de l’état) peuvent nécessiter un stockage supérieur à 1 To.
Évolutivité via les EIP : L’ensemble des opcodes et le calendrier des frais de gaz peuvent être mis à jour grâce aux propositions d’amélioration d’Ethereum (EIP), permettant ainsi à la machine virtuelle Ethereum (EVM) d’évoluer sans perturber les contrats existants.
Surface de vulnérabilité liée à la réentrance : La capacité de l’opcode CALL à transférer l’exécution à des contrats externes crée une catégorie de failles de réentrance qui demeurent le vecteur d’exploitation le plus courant.
Gestion du risque
Risque de vulnérabilité des contrats intelligents
La machine virtuelle EVM exécute fidèlement du code défectueux : les attaques par réentrance, les dépassements d’entiers (avant Solidity 0.8) et les failles de contrôle d’accès ont entraîné des pertes se chiffrant en milliards.
Mesures d’atténuation : exiger des audits professionnels réalisés par des entreprises telles que Trail of Bits, OpenZeppelin ou Certik avant le déploiement sur le réseau principal ; utiliser des outils de vérification formelle comme Certora et K Framework.
Implémentez le modèle de contrôle des effets et des interactions et utilisez ReentrancyGuard d'OpenZeppelin pour tous les appels externes.
Risque de volatilité des prix du gaz
Une congestion soudaine du réseau peut faire grimper les prix du gaz de 10 gwei à plus de 500 gwei, rendant les interactions contractuelles excessivement coûteuses.
Mesures d'atténuation : implémenter des oracles de prix du gaz et des paramètres de prix du gaz maximum dans les interfaces des dApps ; utiliser des solutions de couche 2 (Arbitrum, Optimism, Base) pour les opérations sensibles aux coûts.
Envisagez les transactions blob EIP-4844 pour les opérations de consolidation portant sur un grand nombre de données.
Risque de compatibilité inter-chaînes
Les chaînes compatibles EVM peuvent présenter des différences subtiles au niveau du comportement des opcodes, de la disponibilité de la précompilation ou de la planification du gaz.
Mesures d'atténuation : tester les contrats sur le réseau de test de chaque chaîne cible ; être prudent avec les opcodes spécifiques à chaque chaîne, comme CHAINID et BASEFEE; maintenir les configurations de déploiement par chaîne
Déploiement excessif de l'État et risque de durabilité
Chaque déploiement de contrat et chaque écriture dans le stockage augmentent de façon permanente l'état global, ce qui accroît les exigences matérielles pour les nœuds complets.
Mesures d'atténuation : minimiser l'utilisation du stockage grâce à un regroupement efficace des données (plusieurs valeurs par emplacement de 32 octets) ; soutenir la recherche sur Ethereum sans état et les propositions d'expiration d'état (EIP-4444).
Pertinence culturelle
L'EVM est devenue la norme de référence de l'ère des contrats intelligents, faisant des choix architecturaux d'Ethereum le langage commun du calcul décentralisé. L'expression « compatible EVM » est passée d'une spécification technique à un argument marketing : les nouveaux projets blockchain mettent systématiquement en avant la compatibilité EVM comme une fonctionnalité essentielle, reconnaissant que l'accès à l'écosystème de développeurs d'Ethereum et aux bibliothèques de contrats intelligents existantes est indispensable à leur adoption.
Le langage de programmation Solidity, compilé en bytecode EVM, a donné naissance à une véritable catégorie professionnelle de « développeurs Solidity » bénéficiant de salaires très élevés dans le secteur technologique. Des formations intensives, des cursus universitaires et des plateformes en ligne comme CryptoZombies ont formé un grand nombre de développeurs spécialisés dans le développement basé sur l'EVM.
Le mécanisme de gaz de l'EVM a profondément marqué la culture crypto. Des expressions comme « guerre du gaz », « optimisation du gaz » et « à court de gaz » font désormais partie du vocabulaire courant des communautés crypto. La frustration liée aux transactions échouées faute de gaz suffisant a donné naissance à d'innombrables mèmes, et la recherche de frais de gaz plus bas a été au cœur du débat sur la mise à l'échelle de la couche 2.
Dans la communauté des développeurs, la distinction entre « équivalence EVM » et « compatibilité EVM » est devenue cruciale. Des projets comme OP Stack d'Optimism visent une équivalence totale (comportement identique des opcodes), tandis que d'autres se contentent d'une compatibilité (le même code Solidity se compile et se déploie, mais avec de légères différences de comportement). Cette distinction est fondamentale pour la sécurité et la composabilité, et constitue un critère d'évaluation essentiel pour les décisions relatives à l'infrastructure.
Exemples du monde réel
Déploiement multi-chaînes Uniswap
Scénario: Uniswap, la plus grande plateforme d'échange décentralisée en termes de volume, devait s'étendre au-delà du réseau principal Ethereum pour servir les utilisateurs exclus du marché en raison des frais de gaz élevés.
Mise en œuvre: Les contrats intelligents d'Uniswap étant écrits en Solidity pour l'EVM, le protocole a été déployé sur Polygon, Arbitrum, Optimism, BSC, Base, Avalanche et Celo avec des modifications minimales. La même logique AMM (formule du produit constant) fonctionne de manière identique sur toutes les blockchains compatibles EVM.
Résultat: Uniswap traite un volume d'échanges quotidien considérable sur plusieurs chaînes EVM. Sur Arbitrum et Polygon, les utilisateurs paient généralement des fractions de centime par échange, contre plusieurs dollars sur le réseau principal Ethereum en période de congestion, tandis que le modèle de sécurité du protocole reste fondamentalement identique sur tous les déploiements.
Le piratage de la DAO et la réentrance de l'EVM
Scénario: En juin 2016, un attaquant a exploité une faille de réentrance dans le contrat intelligent de The DAO, déployé sur l'EVM. La fonction de retrait du contrat envoyait des ETH avant la mise à jour du solde de l'utilisateur, permettant ainsi à l'attaquant d'appeler récursivement la fonction de retrait avant que le solde ne soit ramené à zéro.
Mise en œuvre: L'attaquant a conçu un contrat malveillant qui, lors de la réception d'ETH via l'EVM, CALL L'opcode appelait immédiatement la fonction de retrait de la DAO. L'EVM a exécuté fidèlement chaque appel récursif, drainant environ 3.6 millions d'ETH (environ 60 millions de dollars à l'époque).
Résultat: La communauté Ethereum a procédé à une bifurcation dure controversée pour annuler le vol, créant ainsi Ethereum (ETH) et Ethereum Classic (ETC). Cet incident est devenu l'étude de cas de référence en matière de sécurité de la machine virtuelle Ethereum (EVM), menant au développement des mécanismes de protection contre la réentrance, du modèle CEI (Checks-Effects-Interactions) et des pratiques d'audit détaillées qui définissent aujourd'hui le secteur.
Aave sur Arbitrum via l'équivalence EVM
Scénario: Aave, un protocole de prêt DeFi de premier plan avec une valeur totale bloquée substantielle, a cherché à se déployer sur Arbitrum pour offrir aux utilisateurs des emprunts et des prêts à moindre coût.
Mise en œuvre: La mise à niveau Nitro d'Arbitrum a permis d'atteindre une équivalence quasi complète avec l'EVM, ce qui signifie que le système complexe multi-contrats d'Aave (incluant les prêts flash, la logique de taux variable/stable et les modules de gouvernance) a pu être déployé sans modification. Le même code source Solidity, compilé en bytecode EVM identique, s'exécute dans l'environnement d'exécution optimiste d'Arbitrum.
Résultat: Le déploiement d'Aave sur Arbitrum est devenu l'un des plus importants déploiements DeFi sur une infrastructure de couche 2, avec des coûts de gaz réduits d'environ 90 à 95 % par rapport au réseau principal Ethereum. Ce déploiement réussi a démontré l'efficacité de l'équivalence EVM pour les migrations de protocoles complexes.
Guerres de gaz de frappe de NFT
Scénario: Lors de lancements de NFT très médiatisés comme Otherside mint de Yuga Labs (30 avril 2022), des milliers d'utilisateurs ont simultanément tenté d'exécuter des transactions EVM pour créer des NFT, créant une concurrence extrême en matière de gaz.
Mise en œuvre: Les utilisateurs ont fixé des prix du gaz de plus en plus élevés pour s'assurer que leurs transactions de création de jetons soient incluses dans le bloc suivant, certains rapports faisant état de coûts de gaz atteignant environ 2 à 2.5 ETH par transaction au plus fort de la crise. La machine virtuelle Ethereum (EVM) traitait chaque demande de création de jeton séquentiellement au sein de chaque bloc, les constructeurs de blocs ordonnant les transactions en fonction du prix du gaz.
Résultat: L'opération Otherside Mint a généré plus de 150 millions de dollars de frais de gaz ETH en 24 heures environ (les estimations varient entre 150 et 176 millions de dollars), démontrant à la fois la robustesse de l'EVM face à une charge extrême et ses limitations fondamentales en termes de débit. Cet événement a accéléré l'adoption de solutions de couche 2 basées sur l'EVM pour les futurs lancements de NFT.
Tableau de comparaison
Fonctionnalité
EVM (Ethereum)
Machine virtuelle Solana (SVM)
CosmWasm (Cosmos)
Déplacer la VM (Aptos/Sui)
Architecture
Mot de 256 bits basé sur une pile
Code octet BPF basé sur les registres
Basé sur WebAssembly
Intégré aux registres et orienté ressources
Langue principale
Solidité, Vyper
Rouille, C
Se reposer
Move
Modèle d'exécution
Séquentiel par bloc
Parallèle (niveau de la mer)
Séquentiel par bloc
Parallèle (centré sur l'objet)
Modèle gaz/frais
Essence avec tarif de base + frais prioritaires
Unités de calcul + frais de priorité
Gaz à prix configurable
Unités à gaz avec remises sur le stockage
Adoption inter-chaînes
Plus de 50 chaînes (BSC, Polygon, Arbitrum, etc.)
chaînes compatibles SVM émergent
Chaînes connectées IBC (50+)
Limité (Aptos, Sui, Mouvement)
Écosystème de développeur
Les plus importants (Hardhat, Foundry, OpenZeppelin)
Croissance (Cadre d'ancrage)
Modéré (Outillage CosmWasm)
Émergent (Démonstrateur de mouvement)
Vérification formelle
Spécifications du Livre jaune ; K-EVM
Outillage formel limité
Modéré (vérifications CosmWasm)
Détecteur de mouvement (intégré)
Termes connexes
Solidité – Le langage de programmation de haut niveau le plus utilisé pour écrire des contrats intelligents EVM, avec typage statique, héritage et une bibliothèque standard étendue.
Gaz (Ethereum) – L’unité d’effort de calcul requise pour exécuter des opérations sur l’EVM, payée par les expéditeurs de transactions pour rémunérer les validateurs pour le traitement de leurs transactions.
Contrat intelligent – Programmes auto-exécutables stockés sur la blockchain et exécutés par l'EVM, contenant la logique métier des applications décentralisées.
Bytecode – Le code machine de bas niveau compilé à partir de Solidity ou Vyper que l'EVM exécute directement, constitué de séquences d'opcodes et de leurs arguments.
Chaîne compatible EVM – Toute blockchain qui implémente la spécification EVM, permettant le déploiement et l'exécution de contrats intelligents Solidity sans modification.
Cumul de couche 2 – Des solutions de mise à l'échelle comme Arbitrum et Optimism qui exécutent les transactions EVM hors chaîne et renvoient les preuves ou les données compressées à Ethereum pour des raisons de sécurité.
Livre jaune Ethereum – La spécification mathématique formelle de l'EVM par Gavin Wood, définissant chaque opcode, coût en gaz et règle de transition d'état.
ABI (Application Binary Interface) – Le format d'encodage standard pour appeler les fonctions de contrats intelligents EVM et décoder leurs valeurs de retour, permettant l'interopérabilité entre les contrats et les interfaces.
EIP-1559 – La proposition d'amélioration d'Ethereum qui a réformé le marché des frais de gaz de l'EVM en introduisant des frais de base brûlés et un mécanisme de pourboire prioritaire optionnel.
Contrat de procuration – Un modèle de conception utilisant l'opcode DELEGATECALL de l'EVM pour créer des contrats intelligents évolutifs en séparant le stockage de la logique.
Opcodes – L’ensemble d’instructions fondamental de l’EVM, chacun effectuant une seule opération atomique telle que l’addition, l’accès au stockage ou l’appel de contrat.
Arbre d'état – La structure de données de l'arbre de Patricia Merkle qui stocke l'état global (soldes des comptes, stockage des contrats, bytecode) auquel accède l'EVM pendant l'exécution.
QFP
Q : Que signifie « compatible EVM » et pourquoi est-ce important ? A : La compatibilité EVM signifie qu'une blockchain implémente la même spécification de machine virtuelle qu'Ethereum, permettant ainsi le déploiement de contrats intelligents écrits en Solidity sans modification. C'est important car cela offre aux nouvelles chaînes un accès immédiat au vaste écosystème d'outils de développement d'Ethereum (Hardhat, Foundry, Remix), aux bibliothèques de contrats auditées (OpenZeppelin) et aux bases de code d'applications décentralisées (dApps) existantes. Des chaînes comme BSC, Polygon, Avalanche C-Chain, Arbitrum et Optimism sont toutes compatibles EVM, ce qui explique pourquoi les mêmes protocoles (Uniswap, Aave, SushiSwap) peuvent fonctionner sur chacune d'elles.
Q : Pourquoi l'EVM utilise-t-elle du gaz au lieu de simplement facturer des frais fixes ? A : Le gaz est nécessaire car les différentes opérations consomment des quantités très différentes de ressources de calcul. Une simple addition ne demande qu'un effort négligeable, tandis que l'écriture sur un stockage persistant nécessite des E/S disque réparties sur des milliers de nœuds à travers le monde. Le prix du gaz est calculé proportionnellement au coût réel des ressources utilisées pour chaque opération, empêchant ainsi les attaquants de saturer le réseau avec des calculs coûteux à bas coût. Ce mécanisme de gaz offre également une garantie d'arrêt naturelle : même si un contrat contient une boucle infinie, il finira par manquer de gaz et s'arrêtera, protégeant ainsi le réseau contre les attaques par déni de service.
Q : Que se passe-t-il lorsqu'un contrat intelligent manque de gaz pendant son exécution sur l'EVM ? A : Lorsque le gaz est épuisé en cours d'exécution, la machine virtuelle Elastic (EVM) s'arrête immédiatement et annule toutes les modifications d'état effectuées pendant la transaction : les écritures dans le stockage, les transferts de solde et les créations de contrats sont annulés comme si la transaction n'avait jamais eu lieu. Cependant, les frais de gaz sont tout de même consommés et payés au validateur de bloc, car le travail de calcul a déjà été effectué. C'est pourquoi il est important de définir une limite de gaz appropriée : trop basse, la transaction échoue (et le gaz est gaspillé) ; trop élevée, vous risquez de payer trop cher si l'opération se termine prématurément (même si le gaz non utilisé est remboursé).
Q : En quoi l'EVM diffère-t-elle du processeur d'un ordinateur classique ? A : Contrairement à un processeur physique, l'EVM est une machine virtuelle, c'est-à-dire un logiciel qui simule un ordinateur. Les principales différences sont les suivantes : (1) l'EVM est totalement déterministe, ce qui signifie qu'elle produit des résultats identiques sur chaque machine, tandis que les processeurs physiques peuvent avoir des comportements non déterministes ; (2) l'EVM facture chaque opération via le gaz, tandis que les processeurs traitent les instructions à la vitesse du matériel ; (3) l'EVM dispose d'un stockage blockchain persistant, tandis que la mémoire des processeurs est volatile ; (4) l'EVM fonctionne de manière identique sur des milliers de nœuds simultanément, tandis qu'un processeur fonctionne sur une seule machine. On peut la considérer comme un ordinateur volontairement lent et coûteux, conçu pour un consensus global sans confiance plutôt que pour la performance.
Q : Les contrats intelligents EVM peuvent-ils être mis à jour ou corrigés après leur déploiement ? R : Directement, non – le bytecode EVM est immuable une fois déployé. Cependant, le modèle de proxy (utilisant l'opcode DELEGATECALL) permet aux développeurs de créer des contrats évolutifs. Un contrat proxy stocke l'état et délègue l'exécution à un contrat d'implémentation contenant la logique. Pour effectuer une mise à jour, les développeurs déploient un nouveau contrat d'implémentation et mettent à jour le proxy pour qu'il pointe vers celui-ci. Ce modèle est utilisé par la plupart des principaux protocoles DeFi, mais il introduit des risques de gouvernance et de centralisation (quiconque contrôle la mise à jour du proxy peut modifier le comportement du contrat). Les proxies transparents (EIP-1967) et les proxies UUPS sont les implémentations les plus courantes.
Q : Quelle est la différence entre l'équivalence EVM et la compatibilité EVM ? A : La compatibilité EVM signifie qu'une chaîne peut exécuter des contrats intelligents Solidity, mais il peut exister de subtiles différences au niveau du comportement des opcodes, des coûts de gaz ou de la disponibilité des précompilations. L'équivalence EVM signifie que la chaîne implémente la spécification EVM de manière identique, opcode par opcode, de sorte que même le bytecode de bas niveau et les outils de débogage fonctionnent exactement comme sur Ethereum. La mise à niveau Bedrock d'Optimism et Arbitrum Nitro visent toutes deux l'équivalence EVM, tandis que les chaînes plus anciennes comme BSC sont compatibles EVM mais pas totalement équivalentes. L'équivalence est importante pour les contrats complexes qui dépendent de coûts de gaz ou de comportements d'opcodes spécifiques.
Q : Le système EVM sera-t-il finalement remplacé ? A: Des propositions et des recherches sont actuellement menées sur les technologies de remplacement de l'EVM, notamment eWASM (WebAssembly pour Ethereum), RISC-V et la migration vers EOF (EVM Object Format). Cependant, le remplacement de l'EVM se heurte à un énorme problème de rétrocompatibilité : des milliards de dollars de contrats intelligents sont déployés sous forme de bytecode EVM, et toute solution de remplacement doit soit prendre en charge les contrats existants, soit offrir une migration fluide. L'évolution la plus probable à court terme est la série de mises à niveau EOF, qui modernise le format du bytecode EVM tout en maintenant la compatibilité. Un remplacement complet, s'il a lieu, ne devrait pas intervenir avant plusieurs années et nécessiterait une coexistence avec l'EVM actuelle pendant une période de transition prolongée.
Les prêts garantis par le Bitcoin entrent dans ce que Silicon Valley Bank décrit comme un nouveau chapitre institutionnel, avec des normes de prêt plus strictes et une croissance croissante.
L’Union européenne réévalue sa réglementation phare sur les cryptomonnaies, trois ans seulement après la mise en place du cadre relatif aux marchés des crypto-actifs (MiCA).
