La voie de l'optimisation de l'EVM parallèle vue à travers Reddio
TechFlow SélectionTechFlow Sélection
La voie de l'optimisation de l'EVM parallèle vue à travers Reddio
Aperçu de l'approche mise en œuvre par Reddio, couche 2 d'Ethereum, pour un EVM parallèle.
Dédié à des analyses Web3 approfondiesRédaction : Wuyue, Geek web3
Comme on le sait, l'EVM (Machine Virtuelle Ethereum) est considérée comme le « moteur d'exécution » et l'« environnement d'exécution des contrats intelligents » d'Ethereum, ce qui en fait l'un des composants centraux les plus importants du réseau. Une blockchain publique est un réseau ouvert composé de dizaines de milliers de nœuds, dont les paramètres matériels varient fortement. Pour garantir que les contrats intelligents produisent exactement le même résultat sur tous les nœuds — c'est-à-dire pour assurer la « cohérence » — il faut réussir à créer un environnement identique sur des équipements différents, objectif que peut atteindre une machine virtuelle.
L'EVM d'Ethereum permet d'exécuter des contrats intelligents de manière uniforme sur différents systèmes d'exploitation (tels que Windows, Linux, macOS) et appareils. Cette compatibilité multiplateforme assure que chaque nœud obtienne un résultat identique après exécution d’un contrat. Le cas le plus emblématique est celui de la JVM (Java Virtual Machine).
Les contrats intelligents que nous voyons couramment sur les explorateurs de blocs ont d’abord été compilés en bytecode EVM avant d'être stockés sur la chaîne. Lors de l’exécution, l’EVM lit directement ces bytecodes séquentiellement, chaque instruction (opCode) correspondante ayant un coût en gaz bien défini. L’EVM suit la consommation de gaz de chaque instruction durant son exécution, cette consommation dépendant de la complexité de l’opération.
En outre, en tant que moteur central d’Ethereum, l’EVM traite les transactions de manière sérielle : toutes les transactions sont placées dans une file d’attente unique et exécutées selon un ordre déterministe. La raison pour laquelle une exécution parallèle n’est pas utilisée tient au fait qu’une blockchain doit strictement respecter la cohérence : un ensemble de transactions doit être traité dans le même ordre sur tous les nœuds. Si l’on parallélisait le traitement, il serait difficile de prédire précisément cet ordre sans introduire un algorithme d’ordonnancement dédié, ce qui compliquerait fortement le système.
L’équipe fondatrice d’Ethereum, en 2014-2015, a opté pour une exécution sérielle en raison de contraintes de temps. Ce choix s’expliquait par une conception simple et facile à maintenir. Cependant, avec l’évolution technologique et la croissance continue de la base d’utilisateurs, les exigences en termes de TPS (transactions par seconde) et de débit augmentent constamment. Depuis l’émergence et la maturation des technologies Rollup, le goulot d’étranglement causé par l’exécution sérielle de l’EVM s’est clairement manifesté sur les solutions Layer 2 d’Ethereum.
Le Séquenceur, composant clé des réseaux Layer 2, prend en charge toutes les tâches de calcul sous forme d’un seul serveur. Si les modules externes associés au Séquenceur sont suffisamment efficaces, le goulet d’étranglement final dépendra alors entièrement de l’efficacité du Séquenceur lui-même, et dans ce cas, l’exécution sérielle devient un obstacle majeur.
Par exemple, l’équipe opBNB a réussi, grâce à une optimisation extrême de la couche DA et des modules de lecture/écriture des données, à atteindre un maximum de plus de 2 000 transferts ERC-20 par seconde. Ce chiffre semble élevé, mais si les transactions à traiter sont beaucoup plus complexes que de simples transferts ERC-20, la valeur de TPS chutera inévitablement. Ainsi, la parallélisation du traitement des transactions constitue une tendance incontournable pour l’avenir.
Nous allons maintenant examiner plus en détail les limites de l’EVM traditionnelle ainsi que les avantages de l’EVM parallèle.
Les deux composants centraux de l’exécution des transactions sur Ethereum
Au niveau des modules logiciels, outre l’EVM, un autre composant central lié à l’exécution des transactions dans go-ethereum est stateDB, chargé de gérer les états des comptes et le stockage des données sur Ethereum. Ethereum utilise une structure arborescente appelée Merkle Patricia Trie comme index (répertoire) de base de données. Chaque exécution de transaction par l’EVM modifie certaines données stockées dans stateDB, modifications qui se reflètent finalement dans l’arbre d’état global (Merkle Patricia Trie, abrégé ici en « arbre d’état global »).
Plus précisément, stateDB gère l’état de tous les comptes Ethereum, y compris les comptes EOA (Externally Owned Accounts) et les comptes de contrats. Les données stockées comprennent notamment le solde des comptes et le code des contrats intelligents. Pendant l’exécution d’une transaction, stateDB effectue des lectures et écritures sur les données des comptes concernés. Une fois la transaction terminée, stateDB doit soumettre le nouvel état à la base de données sous-jacente (comme LevelDB) afin de le rendre persistant.
En résumé, l’EVM interprète et exécute les instructions des contrats intelligents, modifiant ainsi l’état de la blockchain selon les résultats du calcul, tandis que stateDB agit comme un stockage d’état global, gérant toutes les modifications d’état des comptes et contrats. Ensemble, ils forment l’environnement d’exécution des transactions sur Ethereum.
Processus détaillé de l’exécution sérielle
Il existe deux types de transactions sur Ethereum : les transferts EOA et les transactions de contrat. Le transfert EOA est le type le plus simple : un transfert d’ETH entre comptes ordinaires. Cette opération ne fait pas appel à un contrat, donc elle est très rapide. En raison de sa simplicité, les frais de gaz associés sont très bas.
À l’inverse, les transactions de contrat impliquent l’appel et l’exécution d’un contrat intelligent. Lorsqu’il traite ce type de transaction, l’EVM interprète et exécute ligne par ligne les instructions du bytecode du contrat. Plus la logique du contrat est complexe, plus il contient d’instructions, et plus il consomme de ressources.
Par exemple, le traitement d’un transfert ERC-20 prend environ deux fois plus de temps qu’un transfert EOA. Pour des contrats plus complexes, comme une transaction sur Uniswap, le délai est encore plus long — jusqu’à dix fois supérieur à celui d’un transfert EOA. Cela s’explique par le fait que les protocoles DeFi doivent gérer des logiques complexes telles que les pools de liquidité, le calcul des prix et l’échange de jetons, nécessitant des calculs intensifs.
Dans le mode d’exécution sérielle, comment les deux composants EVM et stateDB collaborent-ils pour traiter les transactions ?
Dans la conception d’Ethereum, les transactions d’un bloc sont traitées une par une, selon leur ordre d’arrivée. Chaque transaction (tx) dispose d’une instance indépendante pour exécuter ses opérations spécifiques. Bien que chaque transaction utilise une instance distincte de l’EVM, elles partagent toutes la même base de données d’état, c’est-à-dire stateDB.
Pendant l’exécution, l’EVM interagit constamment avec stateDB : il lit les données nécessaires depuis stateDB et écrit les données modifiées dans stateDB.
Examinons brièvement, du point de vue du code, comment EVM et stateDB collaborent lors de l’exécution des transactions :
1. La fonction processBlock() appelle la fonction Process() pour traiter les transactions incluses dans un bloc ;
2. Dans la fonction Process(), une boucle « for » montre clairement que les transactions sont exécutées une à une ;
3. Une fois toutes les transactions traitées, la fonction processBlock() appelle la fonction writeBlockWithState(), qui à son tour appelle statedb.Commit() pour valider les modifications d’état.
Une fois que toutes les transactions d’un bloc ont été exécutées, les données de stateDB sont validées (commit) dans l’arbre d’état global (Merkle Patricia Trie), générant un nouveau « root d’état » (stateRoot). Le root d’état est un paramètre crucial de chaque bloc : il représente un « condensé » de l’état global après exécution du bloc.
On comprend aisément que le principal goulot d’étranglement du modèle d’exécution sérielle de l’EVM est évident : les transactions doivent s’exécuter séquentiellement. Si une transaction impliquant un contrat particulièrement coûteux est en cours, toutes les autres doivent attendre. Cela ne permet pas d’exploiter pleinement les ressources matérielles comme le CPU, ce qui limite fortement l’efficacité.
Solutions d’optimisation multi-threading (parallèle) pour l’EVM
Pour illustrer la différence entre exécution sérielle et parallèle par un exemple concret, imaginons la première comme une banque avec un seul guichet, et la seconde comme une banque avec plusieurs guichets. Dans le mode parallèle, plusieurs threads peuvent traiter simultanément plusieurs transactions, offrant ainsi un gain de performance pouvant atteindre plusieurs fois celui du mode sériel. Toutefois, le problème délicat réside dans les conflits d’état.
Si plusieurs transactions tentent toutes de modifier les données d’un même compte, un conflit survient lorsqu’elles sont traitées en même temps. Par exemple, supposons qu’un NFT ne puisse être frappé qu’une seule fois, mais que la transaction 1 et la transaction 2 revendiquent toutes deux sa création. Si les deux requêtes étaient satisfaites, cela entraînerait une erreur. Ce type de situation doit être géré avec coordination. En pratique, les conflits d’état sont encore plus fréquents que cet exemple, donc toute parallélisation du traitement des transactions doit intégrer des mécanismes pour gérer ces conflits.
Principe d’optimisation parallèle de l’EVM par Reddio
Observons la stratégie adoptée par le projet ZKRollup Reddio pour paralléliser l’EVM. L’approche de Reddio consiste à attribuer une transaction à chaque thread, en fournissant à chaque thread une base de données d’état temporaire appelée pending-stateDB. Voici les détails :
1. Exécution parallèle des transactions via plusieurs threads : Reddio configure plusieurs threads pour traiter différentes transactions simultanément, sans interférence mutuelle. Cela permet d’accroître la vitesse de traitement des transactions par un facteur multiple.
2. Attribution d’une base de données d’état temporaire à chaque thread : Chaque thread reçoit une base de données d’état temporaire indépendante (pending-stateDB). Lors de l’exécution d’une transaction, les threads n’effectuent pas de modification directe sur la stateDB globale, mais enregistrent temporairement les changements d’état dans pending-stateDB.
3. Synchronisation des modifications d’état : Une fois toutes les transactions d’un bloc exécutées, l’EVM synchronise les modifications d’état enregistrées dans chaque pending-stateDB vers la stateDB globale. Si aucune collision d’état n’a eu lieu pendant l’exécution des différentes transactions, les enregistrements de pending-stateDB peuvent être fusionnés sans problème dans la stateDB globale.
Reddio a optimisé la gestion des opérations de lecture et d’écriture afin de garantir un accès correct aux données d’état et d’éviter les conflits.
-
Lecture : Lorsqu'une transaction a besoin de lire un état, l’EVM vérifie d’abord le ReadSet de Pending-state. Si les données demandées existent dans le ReadSet, l’EVM lit directement depuis pending-stateDB. Si la paire clé-valeur (key-value) correspondante n’est pas trouvée, les données historiques sont lues depuis la stateDB globale du bloc précédent.
-
Écriture : Toutes les opérations d’écriture (modifications d’état) ne sont pas écrites directement dans la stateDB globale, mais d’abord enregistrées dans le WriteSet de Pending-state. Après exécution de la transaction, un contrôle de conflit est effectué avant de tenter de fusionner les modifications dans la stateDB globale.
Le problème clé de l’exécution parallèle réside dans les conflits d’état, particulièrement visibles lorsque plusieurs transactions tentent de lire ou écrire l’état d’un même compte. Pour cela, Reddio a mis en place un mécanisme de détection des conflits :
-
Détection des conflits : Pendant l’exécution des transactions, l’EVM surveille les ReadSet et WriteSet des différentes transactions. Si plusieurs transactions tentent d’accéder ou de modifier le même élément d’état, un conflit est détecté.
-
Gestion des conflits : Lorsqu’un conflit est détecté, les transactions concernées sont marquées comme devant être réexécutées.
Une fois toutes les transactions exécutées, les modifications enregistrées dans les différentes pending-stateDB sont fusionnées dans la stateDB globale. Si la fusion réussit, l’EVM valide l’état final dans l’arbre d’état global et génère un nouveau root d’état.
L’amélioration des performances apportée par l’optimisation multi-threading est évidente, surtout lors du traitement de transactions complexes impliquant des contrats intelligents.
Selon des recherches sur l’EVM parallèle, dans des charges de travail à faible taux de conflits (peu de transactions contradictoires ou concurrentes dans la mempool), les tests montrent un gain de TPS de 3 à 5 fois par rapport à l’exécution sérielle traditionnelle. Dans des scénarios à fort taux de conflits, théoriquement, avec toutes les optimisations combinées, des gains allant jusqu’à 60 fois sont envisageables.
Résumé
La solution d’optimisation multi-threading de l’EVM proposée par Reddio, qui attribue une base de données d’état temporaire à chaque transaction et exécute celles-ci en parallèle sur différents threads, améliore significativement la capacité de traitement des transactions par l’EVM. Grâce à l’optimisation des opérations de lecture/écriture et à l’introduction d’un mécanisme de détection des conflits, les blockchains basées sur l’EVM peuvent désormais paralléliser massivement les transactions tout en préservant la cohérence d’état, résolvant ainsi le goulot d’étranglement lié au modèle d’exécution sérielle traditionnel. Cette avancée pose une base essentielle pour l’avenir des Rollups Ethereum.
Nous analyserons prochainement plus en profondeur les détails techniques de mise en œuvre de Reddio, notamment l’optimisation de l’efficacité du stockage, les stratégies d’optimisation en cas de conflits fréquents, ainsi que l’utilisation potentielle du GPU pour de nouvelles améliorations.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@godrealmx
