Optimisation de la parallélisation EVM : la clé pour surmonter les goulets d'étranglement de performance

Comme tout le monde le sait, l'EVM est l'un des composants clés les plus importants d'Ethereum, positionné comme "moteur d'exécution" et "environnement d'exécution des contrats intelligents". Étant donné que la blockchain publique est un réseau ouvert contenant de nombreux nœuds, les différences de paramètres matériels entre les différents nœuds peuvent être très grandes. Pour garantir que les contrats intelligents produisent les mêmes résultats sur plusieurs nœuds, satisfaisant ainsi les exigences de "consistance", la technologie de machine virtuelle peut créer un environnement identique sur différents appareils.

L'EVM peut exécuter des contrats intelligents de la même manière sur divers systèmes d'exploitation et appareils, cette compatibilité multiplateforme garantit que chaque nœud obtient des résultats cohérents après l'exécution du contrat. Cela est similaire au principe de la machine virtuelle Java (JVM).

Les contrats intelligents que nous voyons dans les explorateurs de blockchain sont d'abord compilés en bytecode EVM, puis stockés sur la chaîne. Lorsque l'EVM exécute un contrat, il lit ces bytecodes dans l'ordre, chaque instruction ayant un coût en Gas correspondant. L'EVM suit la consommation de Gas pendant l'exécution de chaque instruction, la quantité consommée dépendant de la complexité de l'opération.

En tant que moteur d'exécution central d'Ethereum, l'EVM traite les transactions de manière séquentielle, toutes les transactions étant mises en file d'attente dans une seule file et exécutées dans un ordre déterminé. La raison pour laquelle une approche parallèle n'est pas adoptée est que la blockchain doit strictement satisfaire à la consistance, un lot de transactions doit être traité dans le même ordre sur tous les nœuds. Si le traitement des transactions était parallélisé, il serait difficile de prédire avec précision l'ordre des transactions, à moins d'introduire des algorithmes de planification complexes.

L'équipe fondatrice d'Ethereum, en raison de l'urgence du temps, a choisi en 2014-2015 de concevoir un mode d'exécution séquentielle simple et facile à maintenir. Cependant, avec l'itération de la technologie blockchain et l'expansion de la base d'utilisateurs, les exigences en matière de TPS et de débit deviennent de plus en plus élevées. Après la maturation de la technologie Rollup, le goulot d'étranglement de performance causé par l'exécution séquentielle de l'EVM est désormais clairement visible dans le réseau de deuxième couche d'Ethereum.

Le Sequencer, en tant que composant clé de Layer2, assume toutes les tâches de calcul sous la forme d'un seul serveur. Si l'efficacité des modules externes fonctionnant avec le Sequencer est suffisamment élevée, le goulot d'étranglement final dépendra de l'efficacité du Sequencer lui-même, à ce moment-là, l'exécution en série deviendra un obstacle majeur.

Une certaine équipe a optimisé de manière extrême la couche DA et le module de lecture et d'écriture des données, permettant au séquenceur d'exécuter jusqu'à environ 2000 transactions ERC-20 par seconde. Ce chiffre semble très élevé, mais si les transactions traitées sont beaucoup plus complexes que les transferts ERC-20, la valeur TPS diminuera considérablement. Par conséquent, la parallélisation du traitement des transactions deviendra une tendance inévitable dans le futur.

Ensuite, nous allons explorer en profondeur les limitations de l'EVM traditionnel et les avantages de l'EVM parallèle.

Les deux composants clés de l'exécution des transactions Ethereum

Au niveau du module de code, en plus de l'EVM, un autre composant central lié à l'exécution des transactions dans go-ethereum est le stateDB, qui est utilisé pour gérer l'état des comptes et le stockage de données dans Ethereum. Ethereum utilise une structure arborescente appelée Merkle Patricia Trie comme index de base de données. Chaque exécution de transaction par l'EVM modifie certaines données dans le stateDB, et ces changements se refléteront finalement dans l'arbre d'état global.

stateDB est responsable de la maintenance de l'état de tous les comptes Ethereum, y compris les comptes EOA et les comptes de contrats, les données stockées incluent le solde des comptes, le code des contrats intelligents, etc. Au cours du processus d'exécution des transactions, stateDB effectuera des lectures et des écritures sur les données des comptes correspondants. À la fin de l'exécution de la transaction, stateDB doit soumettre le nouvel état à la base de données sous-jacente pour un traitement de persistance.

En général, l'EVM est responsable de l'interprétation et de l'exécution des instructions des contrats intelligents, modifiant l'état de la blockchain en fonction des résultats des calculs, tandis que le stateDB sert de stockage d'état global, gérant toutes les variations d'état des comptes et des contrats. Les deux collaborent pour construire l'environnement d'exécution des transactions d'Ethereum.

le processus spécifique d'exécution en série

Les transactions Ethereum se divisent en deux catégories : les transferts EOA et les transactions de contrat. Les transferts EOA sont le type de transaction le plus simple, c'est-à-dire le transfert d'ETH entre comptes ordinaires, sans appel de contrat, avec une vitesse de traitement très rapide et des frais de gas très bas.

Le trading de contrats implique l'appel et l'exécution de contrats intelligents. Lorsque l'EVM traite des transactions de contrats, il doit interpréter et exécuter une par une les instructions en bytecode du contrat intelligent. Plus la logique du contrat est complexe, plus il y a d'instructions impliquées, plus les ressources consommées sont importantes.

Par exemple, le temps de traitement d'un transfert ERC-20 est environ deux fois plus long que celui d'un transfert EOA, tandis que des contrats intelligents plus complexes comme l'opération de transaction sur un DEX ( prennent encore plus de temps, pouvant être dix fois plus lents que les transferts EOA. Cela est dû au fait que les protocoles DeFi doivent gérer des logiques complexes telles que les pools de liquidité, le calcul des prix, l'échange de jetons, ce qui nécessite beaucoup de calculs.

Dans le mode d'exécution séquentielle, le processus de traitement des transactions entre l'EVM et la stateDB est le suivant :

Dans la conception d'Ethereum, les transactions d'un bloc sont traitées séquentiellement, chaque transaction ayant une instance indépendante pour exécuter des opérations spécifiques. Bien que chaque transaction utilise une instance EVM différente, toutes les transactions partagent la même base de données d'état stateDB.

Pendant l'exécution de la transaction, l'EVM doit interagir en continu avec la stateDB, lire les données pertinentes et écrire les données modifiées dans la stateDB.

Du point de vue du code, le processus général par lequel l'EVM et le stateDB collaborent pour exécuter des transactions est le suivant :

1. La fonction processBlock)( appelle la fonction Process)( pour traiter les transactions dans un bloc.

2. Process)( la fonction définit une boucle for, les transactions sont exécutées une par une.

3. Une fois que toutes les transactions sont traitées, la fonction processBlock)( appelle la fonction writeBlockWithState)(, puis appelle la fonction statedb.Commit)( pour soumettre le résultat des changements d'état.

Lorsque toutes les transactions d'un bloc sont exécutées, les données dans stateDB sont soumises à l'arbre d'état global et un nouveau racine d'état est généré. La racine d'état est un paramètre important dans chaque bloc, enregistrant le "résultat compressé" du nouvel état global après l'exécution du bloc.

![En prenant Reddio comme exemple, exposons la voie d'optimisation de l'EVM parallèle])https://img-cdn.gateio.im/webp-social/moments-404bb55ec4d21fe81783881149ac0ad6.webp(

Le goulot d'étranglement du mode d'exécution séquentielle de l'EVM est évident : les transactions doivent être exécutées en file d'attente, dans l'ordre. Si une transaction de contrat intelligent prend beaucoup de temps, les autres transactions ne peuvent que patienter, ce qui empêche une utilisation optimale des ressources matérielles comme le CPU, limitant ainsi l'efficacité.

Solution d'optimisation parallèle multithread de l'EVM

En comparant l'exécution séquentielle à l'exécution parallèle, la première est comme une banque avec un seul guichet, tandis que l'EVM parallèle ressemble à une banque avec plusieurs guichets. En mode parallèle, il est possible d'ouvrir plusieurs fils d'exécution pour traiter plusieurs transactions simultanément, ce qui peut augmenter l'efficacité de plusieurs fois, mais le défi auquel on est confronté est le problème des conflits d'état.

Si plusieurs transactions déclarent qu'elles veulent modifier les données d'un certain compte, cela peut entraîner des conflits lors du traitement simultané. Par exemple, un NFT ne peut être frappé qu'une seule fois, et si la transaction 1 et la transaction 2 essaient toutes deux de frapper ce NFT, il est évident que cela provoquera une erreur si les deux demandes sont satisfaites. En pratique, les conflits d'état se produisent souvent plus fréquemment, c'est pourquoi le traitement des transactions en parallèle doit avoir des mesures pour faire face aux conflits d'état.

![En prenant Reddio comme exemple, exposons la voie d'optimisation de l'EVM parallèle])https://img-cdn.gateio.im/webp-social/moments-fc9301b18b6299dc8f792e68961977cd.webp(

) Principe d'optimisation parallèle d'un projet pour l'EVM

Un certain projet ZKRollup a pour idée d'optimisation parallèle de l'EVM d'allouer une transaction à chaque thread et de fournir une base de données d'état temporaire dans chaque thread, appelée pending-stateDB. Les détails spécifiques sont les suivants :

1. Exécution de transactions en parallèle avec plusieurs threads : configurez plusieurs threads pour traiter différentes transactions simultanément, sans interférence entre les threads, ce qui peut multiplier par plusieurs fois la vitesse de traitement des transactions.

2. Allouer une base de données d'état temporaire pour chaque thread : chaque thread se voit attribuer une base de données d'état temporaire indépendante ###pending-stateDB(. Lorsque le thread exécute des transactions, il ne modifie pas directement la stateDB globale, mais enregistre temporairement les résultats des changements d'état dans la pending-stateDB.

3. Synchronisation des changements d'état : Une fois que toutes les transactions d'un bloc ont été exécutées, l'EVM synchronise successivement les résultats des changements d'état enregistrés dans chaque pending-stateDB avec le stateDB global. Si aucune collision d'état n'est survenue pendant l'exécution des transactions différentes, les enregistrements du pending-stateDB peuvent être fusionnés avec succès dans le stateDB global.

![En prenant Reddio comme exemple, décrivant le chemin d'optimisation de l'EVM parallèle])https://img-cdn.gateio.im/webp-social/moments-c62d7268de0c9ada677dc15618b1e024.webp(

Ce projet a optimisé le traitement des opérations de lecture et d'écriture, garantissant que les transactions peuvent accéder correctement aux données d'état et éviter les conflits :

Opération de lecture : Lorsque la transaction nécessite de lire l'état, l'EVM vérifie d'abord le ReadSet de l'état en attente. Si le ReadSet contient les données requises, il les lit directement à partir de la pending-stateDB. Si le ReadSet ne contient pas la paire clé-valeur correspondante, il lit les données d'état historiques à partir de la stateDB globale du bloc précédent.

Opérations d'écriture : toutes les opérations d'écriture ), c'est-à-dire les modifications d'état (, ne sont pas directement écrites dans la stateDB globale, mais sont d'abord enregistrées dans le WriteSet de l'état en attente. Après l'exécution de la transaction, une détection de conflit est effectuée pour tenter de fusionner les résultats des modifications d'état dans la stateDB globale.

La question clé de l'exécution parallèle est le conflit d'état, qui est particulièrement évident lorsque plusieurs transactions tentent de lire et d'écrire l'état du même compte. Pour cela, un mécanisme de détection de conflit a été introduit:

Détection des conflits : pendant l'exécution des transactions, l'EVM surveille les ReadSets et WriteSets des différentes transactions. Si plusieurs transactions tentent de lire et d'écrire le même élément d'état, cela est considéré comme un conflit.

Gestion des conflits : Lorsqu'un conflit est détecté, la transaction en conflit est marquée comme nécessitant une réexécution.

Après l'exécution de toutes les transactions, les enregistrements de modifications dans plusieurs bases de données d'état en attente seront fusionnés dans la base de données d'état globale. Si la fusion réussit, l'EVM soumettra l'état final à l'arbre d'état global et générera une nouvelle racine d'état.

![En prenant Reddio comme exemple, exposer le chemin d'optimisation de l'EVM parallèle])https://img-cdn.gateio.im/webp-social/moments-75575d5ea4bfa2edcc71ad93d3277caf.webp(

L'optimisation parallèle multithreading améliore considérablement les performances, en particulier lors du traitement de transactions complexes de contrats intelligents. Les recherches montrent que, dans les charges de travail à faible conflit, le TPS des tests de référence est amélioré de 3 à 5 fois par rapport à l'exécution séquentielle traditionnelle. Dans les charges de travail à fort conflit, théoriquement, si toutes les méthodes d'optimisation sont appliquées, une amélioration de 60 fois pourrait même être atteinte.

Résumé

La solution d'optimisation de parallélisme multithread EVM ci-dessus, en attribuant une bibliothèque d'état temporaire à chaque transaction et en exécutant les transactions en parallèle dans différents threads, a considérablement amélioré la capacité de traitement des transactions de l'EVM. En optimisant les opérations de lecture et d'écriture et en introduisant un mécanisme de détection des conflits, la blockchain publique EVM peut réaliser une parallélisation à grande échelle des transactions tout en garantissant la cohérence des états, résolvant ainsi le goulet d'étranglement de performance posé par le modèle d'exécution séquentielle traditionnel. Cela constitue une base importante pour le développement futur des Rollups d'Ethereum.

Les futures directions de recherche incluent : l'optimisation supplémentaire de l'efficacité de stockage pour améliorer les performances, des solutions d'optimisation pour faire face à des situations de forte contention, ainsi que l'utilisation des GPU pour l'optimisation.

![En prenant Reddio comme exemple, expliquons le chemin de l'optimisation de l'EVM parallèle])https://img-cdn.gateio.im/webp-social/moments-6274c33f6c958750df5cf3e53949b7fb.webp(