Exploration des goulets d'étranglement de l'exécution séquentielle de l'EVM et optimisation de la parallélisation
Comme tout le monde le sait, l'EVM est le moteur d'exécution et l'environnement d'exécution des contrats intelligents d'Ethereum, et c'est l'un des composants les plus critiques d'Ethereum. Dans un réseau de blockchain public composé de nombreux nœuds, la technologie de la machine virtuelle joue un rôle crucial pour garantir que les contrats intelligents obtiennent des résultats d'exécution cohérents sur différents nœuds.
L'EVM peut exécuter des contrats intelligents de manière uniforme sur divers systèmes d'exploitation et appareils, cette compatibilité multiplateforme garantit que chaque nœud obtient des résultats cohérents après avoir exécuté le contrat. Cela fonctionne de manière similaire à la machine virtuelle Java (JVM).
En général, un contrat intelligent est d'abord compilé en bytecode EVM, puis stocké sur la blockchain. Lors de l'exécution du contrat, l'EVM lit ces bytecodes séquentiellement, chaque instruction ayant un coût en Gas spécifique. L'EVM suit la consommation de Gas pendant l'exécution de chaque instruction, le montant spécifique consommé 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 séquentielle a été choisie plutôt qu'une approche parallèle est de répondre strictement aux exigences de cohérence de la blockchain, garantissant qu'un lot de transactions est traité dans le même ordre sur tous les nœuds.
Entre 2014 et 2015, l'équipe fondatrice d'Ethereum a choisi une méthode d'exécution séquentielle simple et facile à maintenir en raison de l'urgence des délais. Cependant, avec le développement de la technologie blockchain et l'expansion de la base d'utilisateurs, les exigences en matière de TPS et de capacité de traitement ont continuellement augmenté. En particulier, après la maturation et la mise en œuvre de la technologie Rollup, le goulot d'étranglement de performance causé par l'exécution séquentielle de l'EVM est devenu encore plus évident dans le réseau de deuxième couche d'Ethereum.
En tant que composant clé de Layer2, le Sequencer assume toutes les tâches de calcul sous la forme d'un seul serveur. Si les modules externes travaillant avec le Sequencer sont suffisamment efficaces, le goulot d'étranglement final dépendra de l'efficacité du Sequencer lui-même, et l'exécution sérielle deviendra un obstacle majeur.
Une équipe a optimisé de manière extrême le niveau DA et le module de lecture/écriture des données, permettant au Séquenceur d'exécuter jusqu'à environ 2000 transferts ERC-20 par seconde. Ce chiffre peut sembler élevé, mais pour des transactions plus complexes, la valeur TPS diminuera inévitablement de manière significative. Par conséquent, la parallélisation du traitement des transactions sera une tendance inévitable à l'avenir.
Les deux composants clés de l'exécution des transactions Ethereum
En plus de l'EVM, un autre composant central lié à l'exécution des transactions est le stateDB, qui est utilisé pour gérer l'état des comptes et le stockage des données dans Ethereum. Ethereum utilise une structure d'arbre Merkle Patricia Trie comme index de base de données, et chaque exécution de transaction de l'EVM modifie certaines données dans le stateDB, ces changements se reflétant 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. Pendant le processus d'exécution des transactions, stateDB effectuera des opérations de lecture et d'écriture sur les données des comptes concernés. Après 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 résumé, l'EVM est responsable de l'interprétation et de l'exécution des instructions de contrat intelligent, 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 les changements d'état de tous les comptes et contrats. Ensemble, ils construisent l'environnement d'exécution des transactions d'Ethereum.
le processus spécifique d'exécution séquentielle
Les types de transactions sur Ethereum se divisent en deux catégories : le transfert EOA et la transaction par contrat. Le transfert EOA est le type de transaction le plus simple, c'est-à-dire le transfert d'ETH entre des comptes ordinaires, sans appel de contrat, avec une vitesse de traitement très rapide et des frais de gas extrêmement bas.
En revanche, le trading de contrats implique l'appel et l'exécution de contrats intelligents. L'EVM, lors du traitement des transactions de contrats, doit interpréter et exécuter ligne par ligne les instructions de bytecode dans le contrat intelligent. Plus la logique du contrat est complexe, plus le nombre d'instructions impliquées est élevé, et 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 les opérations de trading sur un DEX, peuvent prendre des dizaines de fois plus de temps 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, etc., ce qui nécessite un grand nombre de calculs.
Dans le mode d'exécution séquentielle, le processus par lequel l'EVM et le stateDB collaborent pour traiter les transactions est le suivant :
Dans la conception d'Ethereum, les transactions dans 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.
Au cours de l'exécution des transactions, l'EVM doit interagir constamment avec la stateDB, lire les données pertinentes à partir de la stateDB et écrire les données modifiées de retour dans la stateDB.
Lorsque toutes les transactions d'un bloc sont exécutées, les données dans stateDB sont soumises à l'arbre d'état global, et une nouvelle racine d'état est générée. 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.
Il est évident que le mode d'exécution séquentielle de l'EVM présente des goulots d'étranglement évidents : les transactions doivent être exécutées dans l'ordre, et si une transaction de contrat intelligent prend beaucoup de temps, les autres transactions doivent attendre, ne pouvant pas tirer pleinement parti des ressources matérielles, ce qui limite considérablement l'efficacité.
Solutions d'optimisation parallèles multithread pour l'EVM
Si l'on fait une analogie avec des exemples de la vie quotidienne, l'exécution en série 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 pour traiter simultanément plusieurs transactions, ce qui peut améliorer l'efficacité de plusieurs fois, mais il est nécessaire de résoudre le problème des conflits d'état.
Si plusieurs transactions déclarent vouloir modifier les données d'un certain compte en même temps, cela entraînera des conflits lors du traitement. Par exemple, un NFT ne peut être minté qu'une seule fois, et si la transaction 1 et la transaction 2 déclarent toutes deux vouloir minté ce NFT, il est évident que cela entraînera une erreur si les deux demandes sont satisfaites. Dans la pratique, les conflits d'état se produisent souvent plus fréquemment, c'est pourquoi le traitement parallèle doit inclure des mesures pour gérer les conflits d'état.
Principe d'optimisation parallèle de certains projets pour l'EVM
Un 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 :
Exécution parallèle des transactions avec plusieurs threads : configurez plusieurs threads pour traiter simultanément différentes transactions, sans interférence entre les threads, ce qui peut multiplier par plusieurs fois la vitesse de traitement des transactions.
Allouer une base de données d'état temporaire pour chaque thread : Allouer une base de données d'état temporaire indépendante (pending-stateDB) pour chaque thread. Chaque thread, lors de l'exécution des transactions, ne modifie pas directement la stateDB globale, mais enregistre temporairement les résultats des changements d'état dans la pending-stateDB.
Synchronisation des changements d'état : après l'exécution de toutes les transactions dans un bloc, l'EVM synchronise successivement les résultats des changements d'état enregistrés dans chaque pending-stateDB avec la stateDB globale. Si aucune collision d'état ne se produit lors de l'exécution des différentes transactions, les enregistrements du pending-stateDB peuvent être fusionnés sans problème dans la stateDB globale.
Ce projet a optimisé la gestion des opérations de lecture et d'écriture pour garantir que les transactions puissent accéder correctement aux données d'état et éviter les conflits :
Opération de lecture : Lorsque la transaction nécessite la lecture d'un état, l'EVM vérifie d'abord le ReadSet de l'état en attente. Si les données requises se trouvent dans le ReadSet, elles sont lues directement à partir de la pending-stateDB. Si aucune paire clé-valeur correspondante n'est trouvée dans le ReadSet, les données d'état historiques sont lues à 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 base de données d'état globale, mais sont d'abord enregistrées dans le WriteSet de l'état en attente. Une fois l'exécution de la transaction terminée, un test de conflit est effectué pour tenter de fusionner les résultats des modifications d'état dans la base de données d'état globale.
La question clé de l'exécution parallèle réside dans les conflits d'état, qui se manifestent particulièrement lorsque plusieurs transactions tentent de lire et d'écrire l'état du même compte. Pour cela, un mécanisme de détection de conflits a été introduit :
Détection de conflit : Pendant le processus d'exécution des transactions, l'EVM surveille les ReadSet et WriteSet de 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 sera marquée comme nécessitant une réexécution.
Après l'exécution de toutes les transactions, les enregistrements de modifications dans plusieurs stateDB en attente seront fusionnés dans le stateDB global. 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.
L'optimisation parallèle multithread a un impact significatif sur l'amélioration des performances, en particulier lors du traitement de transactions complexes de contrats intelligents. Des études montrent que, dans des charges de travail à faible conflit, le TPS des tests de référence est amélioré d'environ 3 à 5 fois par rapport à l'exécution séquentielle traditionnelle. Dans des charges de travail à fort conflit, théoriquement, si toutes les méthodes d'optimisation sont appliquées, on peut même atteindre une amélioration de 60 fois.
Résumé
La solution d'optimisation de parallélisme multithread EVM améliore de manière significative la capacité de traitement des transactions de l'EVM en attribuant une bibliothèque d'état temporaire à chaque transaction et en exécutant les transactions en parallèle dans différents threads. En optimisant les opérations de lecture et d'écriture et en introduisant un mécanisme de détection des conflits, la chaîne publique EVM peut réaliser un parallélisme massif des transactions tout en garantissant la cohérence de l'état, résolvant ainsi les goulets d'étranglement de performance engendrés par le mode d'exécution séquentiel traditionnel. Cela jette une base importante pour le développement futur des Rollups Ethereum.
À l'avenir, il sera également possible d'explorer comment optimiser l'efficacité du stockage pour améliorer les performances, des solutions d'optimisation en cas de conflits élevés, ainsi que comment utiliser le GPU pour l'optimisation.
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
9 J'aime
Récompense
9
3
Partager
Commentaire
0/400
LeverageAddict
· 07-20 10:07
Encore quelqu'un qui fait du parallèle, c'est aussi lent que ma Position L2.
Voir l'originalRépondre0
WenMoon
· 07-20 09:51
Ouh là là, L2 doit aussi s'accélérer.
Voir l'originalRépondre0
EntryPositionAnalyst
· 07-20 09:44
L2 a déjà été compris et maintenant je suis en train de suivre l'evm.
Optimisation de la parallélisation EVM : surmonter le goulet d'étranglement de l'exécution séquentielle et améliorer les performances de Layer2
Exploration des goulets d'étranglement de l'exécution séquentielle de l'EVM et optimisation de la parallélisation
Comme tout le monde le sait, l'EVM est le moteur d'exécution et l'environnement d'exécution des contrats intelligents d'Ethereum, et c'est l'un des composants les plus critiques d'Ethereum. Dans un réseau de blockchain public composé de nombreux nœuds, la technologie de la machine virtuelle joue un rôle crucial pour garantir que les contrats intelligents obtiennent des résultats d'exécution cohérents sur différents nœuds.
L'EVM peut exécuter des contrats intelligents de manière uniforme sur divers systèmes d'exploitation et appareils, cette compatibilité multiplateforme garantit que chaque nœud obtient des résultats cohérents après avoir exécuté le contrat. Cela fonctionne de manière similaire à la machine virtuelle Java (JVM).
En général, un contrat intelligent est d'abord compilé en bytecode EVM, puis stocké sur la blockchain. Lors de l'exécution du contrat, l'EVM lit ces bytecodes séquentiellement, chaque instruction ayant un coût en Gas spécifique. L'EVM suit la consommation de Gas pendant l'exécution de chaque instruction, le montant spécifique consommé 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 séquentielle a été choisie plutôt qu'une approche parallèle est de répondre strictement aux exigences de cohérence de la blockchain, garantissant qu'un lot de transactions est traité dans le même ordre sur tous les nœuds.
Entre 2014 et 2015, l'équipe fondatrice d'Ethereum a choisi une méthode d'exécution séquentielle simple et facile à maintenir en raison de l'urgence des délais. Cependant, avec le développement de la technologie blockchain et l'expansion de la base d'utilisateurs, les exigences en matière de TPS et de capacité de traitement ont continuellement augmenté. En particulier, après la maturation et la mise en œuvre de la technologie Rollup, le goulot d'étranglement de performance causé par l'exécution séquentielle de l'EVM est devenu encore plus évident dans le réseau de deuxième couche d'Ethereum.
En tant que composant clé de Layer2, le Sequencer assume toutes les tâches de calcul sous la forme d'un seul serveur. Si les modules externes travaillant avec le Sequencer sont suffisamment efficaces, le goulot d'étranglement final dépendra de l'efficacité du Sequencer lui-même, et l'exécution sérielle deviendra un obstacle majeur.
Une équipe a optimisé de manière extrême le niveau DA et le module de lecture/écriture des données, permettant au Séquenceur d'exécuter jusqu'à environ 2000 transferts ERC-20 par seconde. Ce chiffre peut sembler élevé, mais pour des transactions plus complexes, la valeur TPS diminuera inévitablement de manière significative. Par conséquent, la parallélisation du traitement des transactions sera une tendance inévitable à l'avenir.
Les deux composants clés de l'exécution des transactions Ethereum
En plus de l'EVM, un autre composant central lié à l'exécution des transactions est le stateDB, qui est utilisé pour gérer l'état des comptes et le stockage des données dans Ethereum. Ethereum utilise une structure d'arbre Merkle Patricia Trie comme index de base de données, et chaque exécution de transaction de l'EVM modifie certaines données dans le stateDB, ces changements se reflétant 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. Pendant le processus d'exécution des transactions, stateDB effectuera des opérations de lecture et d'écriture sur les données des comptes concernés. Après 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 résumé, l'EVM est responsable de l'interprétation et de l'exécution des instructions de contrat intelligent, 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 les changements d'état de tous les comptes et contrats. Ensemble, ils construisent l'environnement d'exécution des transactions d'Ethereum.
le processus spécifique d'exécution séquentielle
Les types de transactions sur Ethereum se divisent en deux catégories : le transfert EOA et la transaction par contrat. Le transfert EOA est le type de transaction le plus simple, c'est-à-dire le transfert d'ETH entre des comptes ordinaires, sans appel de contrat, avec une vitesse de traitement très rapide et des frais de gas extrêmement bas.
En revanche, le trading de contrats implique l'appel et l'exécution de contrats intelligents. L'EVM, lors du traitement des transactions de contrats, doit interpréter et exécuter ligne par ligne les instructions de bytecode dans le contrat intelligent. Plus la logique du contrat est complexe, plus le nombre d'instructions impliquées est élevé, et 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 les opérations de trading sur un DEX, peuvent prendre des dizaines de fois plus de temps 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, etc., ce qui nécessite un grand nombre de calculs.
Dans le mode d'exécution séquentielle, le processus par lequel l'EVM et le stateDB collaborent pour traiter les transactions est le suivant :
Dans la conception d'Ethereum, les transactions dans 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.
Au cours de l'exécution des transactions, l'EVM doit interagir constamment avec la stateDB, lire les données pertinentes à partir de la stateDB et écrire les données modifiées de retour dans la stateDB.
Lorsque toutes les transactions d'un bloc sont exécutées, les données dans stateDB sont soumises à l'arbre d'état global, et une nouvelle racine d'état est générée. 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.
Il est évident que le mode d'exécution séquentielle de l'EVM présente des goulots d'étranglement évidents : les transactions doivent être exécutées dans l'ordre, et si une transaction de contrat intelligent prend beaucoup de temps, les autres transactions doivent attendre, ne pouvant pas tirer pleinement parti des ressources matérielles, ce qui limite considérablement l'efficacité.
Solutions d'optimisation parallèles multithread pour l'EVM
Si l'on fait une analogie avec des exemples de la vie quotidienne, l'exécution en série 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 pour traiter simultanément plusieurs transactions, ce qui peut améliorer l'efficacité de plusieurs fois, mais il est nécessaire de résoudre le problème des conflits d'état.
Si plusieurs transactions déclarent vouloir modifier les données d'un certain compte en même temps, cela entraînera des conflits lors du traitement. Par exemple, un NFT ne peut être minté qu'une seule fois, et si la transaction 1 et la transaction 2 déclarent toutes deux vouloir minté ce NFT, il est évident que cela entraînera une erreur si les deux demandes sont satisfaites. Dans la pratique, les conflits d'état se produisent souvent plus fréquemment, c'est pourquoi le traitement parallèle doit inclure des mesures pour gérer les conflits d'état.
Principe d'optimisation parallèle de certains projets pour l'EVM
Un 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 :
Exécution parallèle des transactions avec plusieurs threads : configurez plusieurs threads pour traiter simultanément différentes transactions, sans interférence entre les threads, ce qui peut multiplier par plusieurs fois la vitesse de traitement des transactions.
Allouer une base de données d'état temporaire pour chaque thread : Allouer une base de données d'état temporaire indépendante (pending-stateDB) pour chaque thread. Chaque thread, lors de l'exécution des transactions, ne modifie pas directement la stateDB globale, mais enregistre temporairement les résultats des changements d'état dans la pending-stateDB.
Synchronisation des changements d'état : après l'exécution de toutes les transactions dans un bloc, l'EVM synchronise successivement les résultats des changements d'état enregistrés dans chaque pending-stateDB avec la stateDB globale. Si aucune collision d'état ne se produit lors de l'exécution des différentes transactions, les enregistrements du pending-stateDB peuvent être fusionnés sans problème dans la stateDB globale.
Ce projet a optimisé la gestion des opérations de lecture et d'écriture pour garantir que les transactions puissent accéder correctement aux données d'état et éviter les conflits :
Opération de lecture : Lorsque la transaction nécessite la lecture d'un état, l'EVM vérifie d'abord le ReadSet de l'état en attente. Si les données requises se trouvent dans le ReadSet, elles sont lues directement à partir de la pending-stateDB. Si aucune paire clé-valeur correspondante n'est trouvée dans le ReadSet, les données d'état historiques sont lues à 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 base de données d'état globale, mais sont d'abord enregistrées dans le WriteSet de l'état en attente. Une fois l'exécution de la transaction terminée, un test de conflit est effectué pour tenter de fusionner les résultats des modifications d'état dans la base de données d'état globale.
La question clé de l'exécution parallèle réside dans les conflits d'état, qui se manifestent particulièrement lorsque plusieurs transactions tentent de lire et d'écrire l'état du même compte. Pour cela, un mécanisme de détection de conflits a été introduit :
Détection de conflit : Pendant le processus d'exécution des transactions, l'EVM surveille les ReadSet et WriteSet de 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 sera marquée comme nécessitant une réexécution.
Après l'exécution de toutes les transactions, les enregistrements de modifications dans plusieurs stateDB en attente seront fusionnés dans le stateDB global. 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.
L'optimisation parallèle multithread a un impact significatif sur l'amélioration des performances, en particulier lors du traitement de transactions complexes de contrats intelligents. Des études montrent que, dans des charges de travail à faible conflit, le TPS des tests de référence est amélioré d'environ 3 à 5 fois par rapport à l'exécution séquentielle traditionnelle. Dans des charges de travail à fort conflit, théoriquement, si toutes les méthodes d'optimisation sont appliquées, on peut même atteindre une amélioration de 60 fois.
Résumé
La solution d'optimisation de parallélisme multithread EVM améliore de manière significative la capacité de traitement des transactions de l'EVM en attribuant une bibliothèque d'état temporaire à chaque transaction et en exécutant les transactions en parallèle dans différents threads. En optimisant les opérations de lecture et d'écriture et en introduisant un mécanisme de détection des conflits, la chaîne publique EVM peut réaliser un parallélisme massif des transactions tout en garantissant la cohérence de l'état, résolvant ainsi les goulets d'étranglement de performance engendrés par le mode d'exécution séquentiel traditionnel. Cela jette une base importante pour le développement futur des Rollups Ethereum.
À l'avenir, il sera également possible d'explorer comment optimiser l'efficacité du stockage pour améliorer les performances, des solutions d'optimisation en cas de conflits élevés, ainsi que comment utiliser le GPU pour l'optimisation.