Qu'est-ce que la machine virtuelle Ethereum (EVM) ? Pourquoi est-ce important ?

Architecture de base de l'EVM

1. L’EVM fonctionne comme un environnement d’exécution décentralisé et déterministe répliqué sur chaque nœud complet du réseau Ethereum.

2. Il implémente un modèle informatique basé sur la pile dans lequel chaque entrée de pile occupe exactement 32 octets et la profondeur maximale est plafonnée à 1 024 entrées.

3. Il existe trois couches de mémoire distinctes : la mémoire volatile pour le calcul transitoire, le stockage persistant par compte de contrat et les données d'appel immuables pour les paramètres d'entrée.

4. Chaque instruction exécutée par l'EVM consomme une quantité de gaz prédéterminée, ce qui impose une responsabilité stricte des ressources et empêche les boucles infinies ou les attaques DoS.

5. Le compteur de programme suit la position d'exécution au niveau de l'octet dans le bytecode compilé, permettant un contrôle précis des sauts et un branchement conditionnel via les opcodes JUMP et JUMPI.

Flux de travail d'exécution à l'intérieur de l'EVM

1. Le code source de Solidity est compilé en bytecode compatible EVM contenant des séquences d'opcodes d'un octet.

2. Lors de la soumission de la transaction, l'EVM charge le bytecode du contrat ainsi que l'état actuel du monde, y compris les soldes des comptes et les valeurs de stockage.

3. Chaque opcode déclenche une transition d'état spécifique, telle qu'une opération arithmétique, une écriture en mémoire ou une lecture de stockage, avec des effets secondaires enregistrés uniquement une fois l'opération réussie.

4. Si l'épuisement des gaz se produit en cours d'exécution, tous les changements d'état depuis le lancement de la transaction sont annulés de manière atomique, préservant ainsi la cohérence de la blockchain.

5. Les données renvoyées par les appels de fonction sont codées en mémoire et copiées dans le tampon de sortie avant l'engagement de l'état final.

Propriétés de sécurité et d'isolation

1. L'EVM applique un sandboxing strict : aucun accès au système de fichiers, aucune E/S réseau et aucune interaction directe avec les ressources du système d'exploitation hôte.

2. Le code du contrat ne peut pas manipuler directement le stockage d'un autre contrat sans invocation explicite d'interface et sans logique de contrôle d'accès appropriée.

3. Tous les appels externes, y compris les appels délégués, sont soumis à des limites de gaz et à des règles de propagation inversée, limitant la profondeur des appels récursifs et l'influence des contrats croisés.

4. L'allocation de mémoire est linéaire et limitée ; les lectures hors limites renvoient zéro, tandis que les écritures au-delà de l'espace alloué déclenchent une expansion gourmande en gaz.

5. La sémantique de retour garantit qu'un échec partiel ne laisse pas d'états intermédiaires incohérents : qu'il s'agisse d'un succès total ou d'un retour en arrière complet.

Classification et fonctionnalité des opcodes

1. Les opcodes de manipulation de pile tels que PUSH1, POP, DUP1 et SWAP1 régissent le positionnement et la duplication des opérandes pendant l'évaluation.

2. Les instructions arithmétiques et bit à bit, notamment ADD, MUL, AND, XOR, effectuent des calculs de bas niveau sur des mots de 256 bits.

3. Les opérations de stockage SLOAD et SSSTORE interagissent avec le magasin clé-valeur persistant lié à chaque adresse de contrat.

4. Les opcodes d'environnement tels que CALLER, ORIGIN, BLOCKHASH et TIMESTAMP exposent les métadonnées contextuelles de la blockchain aux contrats en cours d'exécution.

5. Les primitives de flux de contrôle telles que JUMPDEST, JUMP et JUMPI permettent un flux de programme structuré et une répartition dynamique en fonction des conditions d'exécution.

Comptabilité du gaz et application économique

1. Les calendriers de coûts du gaz sont définis par opcode et mis à jour via les propositions d'amélioration d'Ethereum pour refléter l'évolution de l'efficacité du matériel et l'analyse de la surface d'attaque.

2. Les initiateurs de transactions doivent spécifier à la fois la limite de gaz et le prix du gaz, déterminant ainsi le budget de calcul maximum et la priorité dans l'inclusion des blocs.

3. Le gaz non utilisé est remboursé à l'expéditeur après exécution, ce qui encourage des pratiques de codage efficaces et une estimation précise du gaz.

4. Certaines opérations, comme SSTORE lors de l'écrasement de valeurs non nulles, entraînent des coûts asymétriques pour décourager le spam et encourager une conception réfléchie de l'état.

5. La fonctionnalité d'autodestruction fournit un mécanisme de retrait de contrat avec remboursement partiel du gaz, réduisant ainsi l'encombrement du stockage à long terme.

Foire aux questions

Q : Le bytecode EVM peut-il être rétro-conçu pour devenir une source Solidity lisible ? La récupération de la logique de haut niveau d'origine est généralement impossible en raison de la compilation avec perte, des transformations de l'optimiseur et de l'absence de tables de symboles ou de commentaires dans le bytecode déployé.

Q : Pourquoi EVM utilise-t-il une architecture basée sur la pile plutôt que sur les registres ? La conception basée sur la pile simplifie le codage des instructions, réduit la surcharge de taille des opcodes et permet une exécution déterministe sur du matériel hétérogène sans nécessiter de stratégies d'allocation de registres.

Q : Que se passe-t-il lorsque deux contrats tentent d'écrire simultanément sur le même emplacement de stockage ? Les emplacements de stockage sont limités à l'adresse du contrat ; aucun état mutable partagé n'existe entre les contrats à moins d'être explicitement médiatisé via des appels de fonction et des interfaces convenues.

Q : Comment l'EVM gère-t-il le dépassement ou le dépassement inférieur d'entier ? Avant la mise à niveau d'Istanbul, les opérations arithmétiques étaient exécutées silencieusement ; après la mise à niveau, les contrôles de débordement intégrés entraînent un retour immédiat sur les résultats arithmétiques invalides.