Quelle est la couche d’exécution dans Ethereum ?

Définition et fonctionnalités de base

1. La couche d'exécution dans Ethereum fait référence au composant responsable du traitement des transactions, de l'exécution des contrats intelligents et du maintien de l'état des comptes et des soldes.

2. Il fonctionne comme un environnement de machine virtuelle déterministe dans lequel chaque nœud exécute indépendamment le même code et arrive à des résultats identiques avec des entrées identiques.

3. Cette couche gère les actions initiées par l'utilisateur telles que l'envoi d'ETH, le déploiement de contrats et l'interaction avec des applications décentralisées.

4. Avant la fusion, la couche d'exécution fonctionnait sur un consensus de preuve de travail ; après la fusion, il continue de traiter les transitions d'état tout en s'appuyant sur la couche de consensus pour la finalité et la production de blocs.

5. Les clients d'exécution, notamment Geth, Nethermind, Besu et Erigon, implémentent la machine virtuelle Ethereum (EVM) et gèrent les bases de données d'état locales, les pools de transactions et la logique de réseau peer-to-peer.

Interaction avec la couche de consensus

1. La couche d'exécution communique avec la couche de consensus via une interface standardisée connue sous le nom d'API Engine.

2. Lorsqu'un nouveau bloc est proposé par la couche de consensus, la couche d'exécution valide sa charge utile (y compris toutes les transactions) et vérifie que la racine de l'état résultant correspond aux attentes.

3. Si la validation échoue, la couche d'exécution rejette le bloc, déclenchant des règles de choix de fork et conduisant potentiellement à des réorganisations ou à des emplacements manqués.

4. La couche consensus n’interprète pas la sémantique des transactions ; il délègue toutes les responsabilités de calcul et de mutation d'état exclusivement à la couche d'exécution.

5. Cette séparation permet des mises à niveau indépendantes : les améliorations de la couche consensus comme PBS ou DAS ne nécessitent pas de modifications des codes d'opération EVM ou des modèles de tarification du gaz.

Cycle de vie des transactions et gestion de l'état

1. Une transaction entre dans la couche d'exécution via un point de terminaison JSON-RPC ou une diffusion P2P directe et atterrit dans le pool de mémoire local.

2. Les validateurs sélectionnent les transactions en fonction du prix du gaz ou des frais prioritaires, en les classant en blocs candidats avant de soumettre les charges utiles à la couche de consensus.

3. Chaque transaction déclenche l'exécution du bytecode EVM, modifiant le stockage, le solde et le nom occasionnel du compte selon une logique définie.

4. Après l'exécution, la couche calcule une nouvelle racine d'état mondial à l'aide d'un Merkle-Patricia Trie, qui est intégré dans l'en-tête du bloc.

5. Les données d'état historique peuvent être supprimées en fonction de la configuration du client, mais les nœuds d'archivage complet conservent tous les états intermédiaires à des fins de vérification et d'indexation.

Implications en matière de sécurité et vecteurs d'attaque

1. Les vulnérabilités de réentrance persistent au niveau de la couche d'exécution en raison de modèles d'appels externes qui permettent à des contrats malveillants d'interrompre et de réutiliser la logique des fonctions.

2. Les attaques par épuisement des gaz peuvent bloquer l'exécution du contrat en cours de processus, laissant un état incohérent si les développeurs ne parviennent pas à mettre en œuvre des modèles de contrôle et d'effets appropriés.

3. Le front-running reste possible dans les pools de mémoire non fiables, en particulier lorsque l'ordre des transactions est influencé par les extracteurs MEV plutôt que par des mécanismes de séquençage équitables.

4. Les transitions d'état non valides causées par des implémentations client boguées, telles qu'une gestion incorrecte des opcodes EVM, peuvent conduire à des fourchettes de consensus si elles ne sont pas détectées lors des tests.

5. Les bogues de la couche d'exécution ont directement déclenché des hard forks d'urgence dans le passé, y compris le fork DAO et les correctifs DoS d'Istanbul.

Foire aux questions

Q : Un client d'exécution peut-il s'exécuter sans se connecter à un client de consensus ? R : Oui : il peut fonctionner en mode développement ou simuler des blocs localement, mais il ne peut pas participer au consensus du réseau principal ou produire un état de chaîne valide sans coordination via l'API du moteur.

Q : Le changement de client d'exécution affecte-t-il mon ETH misé ? R : Non : les clés de jalonnement et les dépôts du validateur résident sur la chaîne et sont indépendants du choix du client d'exécution, à condition que le client valide correctement les charges utiles et maintienne la synchronisation.

Q : Pourquoi certaines dApps se cassent-elles après certains hard forks ? R : Parce que les hard forks introduisent souvent de nouveaux opcodes, ajustent les coûts de gaz ou modifient les précompilations, ce qui entraîne un comportement différent ou un retour inattendu des contrats précédemment déployés.

Q : L'EVM est-il le seul environnement d'exécution pris en charge par Ethereum ? R : Pour l'instant, oui : le protocole principal impose la compatibilité EVM, bien que des propositions telles que EIP-4844 permettent le proto-danksharding pour la disponibilité des données de cumul sans modifier la sémantique d'exécution.