Le chemin de l'optimisation de la parallélisation de l'EVM
Il est bien connu que l'EVM est l'un des composants clés d'Ethereum, jouant un rôle crucial en tant que "moteur d'exécution" et "environnement d'exécution des contrats intelligents". Dans un réseau de blockchain public composé de milliers de nœuds, la présence de la machine virtuelle permet aux contrats intelligents de s'exécuter de la même manière sur des nœuds avec des configurations matérielles différentes, garantissant la cohérence des résultats. Cette compatibilité multiplateforme est assez similaire à celle de la machine virtuelle Java (JVM).
Les contrats intelligents sont compilés en bytecode EVM avant d'être mis sur la chaîne. Lorsque l'EVM exécute le contrat, il lit ces bytecodes dans l'ordre, chaque instruction ayant un coût en Gas correspondant. L'EVM suit la consommation de Gas au cours de l'exécution des instructions, et la quantité consommée dépend de la complexité des opérations.
En tant que moteur d'exécution central d'Ethereum, l'EVM traite les transactions selon un mode d'exécution séquentiel. Toutes les transactions sont mises en file d'attente dans une seule file, exécutées dans l'ordre déterminé. Ce design est simple et facile à maintenir, mais à mesure que la base d'utilisateurs s'élargit et que la technologie évolue, ses goulets d'étranglement en matière de performance deviennent de plus en plus évidents, en particulier après la maturation de la technologie Rollup, qui se manifeste de manière particulièrement évidente dans le réseau de deuxième couche d'Ethereum.
Le séquenceur, en tant que composant clé de Layer2, assume toutes les tâches de calcul sous la forme d'un serveur unique. Si les modules externes associés sont suffisamment efficaces, le goulot d'étranglement final dépendra de l'efficacité du séquenceur lui-même, et à ce moment-là, l'exécution séquentielle deviendra un énorme obstacle.
Une équipe a optimisé de manière extrême la couche DA et le module de lecture/écriture des données, permettant au Séquenceur d'exécuter jusqu'à environ 2000 transactions ERC-20 par seconde. Ce chiffre semble élevé, mais pour des transactions complexes, le nombre de TPS sera nécessairement réduit. Par conséquent, la parallélisation du traitement des transactions sera une tendance inévitable pour l'avenir.
Les deux composants clés de l'exécution des transactions Ethereum
En dehors de l'EVM, un autre composant central lié à l'exécution des transactions dans go-ethereum est stateDB, 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 par l'EVM modifie certaines données dans stateDB, ces modifications se reflètent finalement dans l'arbre d'état global.
stateDB est responsable de la maintenance de tous les états des comptes Ethereum, y compris les comptes EOA et les comptes de contrats, les données stockées comprennent le solde des comptes, le code des contrats intelligents, etc. Au cours du processus d'exécution des transactions, stateDB effectue des opérations de lecture et d'écriture sur les données des comptes correspondants. Une fois l'exécution de la transaction terminée, stateDB doit soumettre le nouvel état à la base de données sous-jacente pour un traitement de persistance.
Dans l'ensemble, 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 les changements d'état de tous les comptes et 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 types de transaction Ethereum se divisent en transferts EOA et en transactions de contrat. Le transfert EOA est le type de transaction le plus simple, c'est-à-dire un transfert d'ETH entre comptes ordinaires, sans appel de contrat, avec une vitesse de traitement très rapide et des frais de gaz très bas.
Le trading de contrats implique l'appel et l'exécution de contrats intelligents. L'EVM, lors du traitement des transactions de contrat, doit interpréter et exécuter une par une les instructions de bytecode dans le 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 des transferts ERC-20 est environ deux fois plus long que celui des transferts EOA, tandis que des contrats intelligents plus complexes, tels que 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 pools de liquidités, des calculs de prix, des échanges de tokens et d'autres logiques complexes lors des transactions, nécessitant des calculs très complexes.
Dans le mode d'exécution séquentielle, le processus de collaboration entre l'EVM et la stateDB est le suivant :
Les transactions dans le bloc sont traitées une par une dans l'ordre d'arrivée, 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 constamment avec la stateDB, lire les données pertinentes et écrire les données modifiées dans la stateDB.
Une fois toutes les transactions traitées, les données dans stateDB seront soumises à l'arbre d'état global et un nouveau racine d'état sera généré.
Le goulot d'étranglement du mode d'exécution séquentielle de l'EVM est évident : les transactions doivent être exécutées dans l'ordre, et si une transaction de contrat intelligent prend beaucoup de temps, les autres transactions ne peuvent qu'attendre, ce qui empêche une utilisation optimale des ressources matérielles et limite considérablement l'efficacité.
Solution d'optimisation parallèle multithread pour EVM
L'EVM parallèle est similaire à une banque avec plusieurs guichets, où plusieurs threads peuvent être ouverts pour traiter simultanément plusieurs transactions, ce qui permet d'améliorer l'efficacité de plusieurs fois. Mais le problème difficile est celui des conflits d'état, qui nécessite un traitement coordonné.
Une approche d'optimisation parallèle de l'EVM pour un projet ZKRollup est la suivante :
Exécution parallèle des transactions multithread : configurez plusieurs threads pour traiter simultanément différentes transactions, les threads n'interfèrent pas les uns avec les autres, 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 : chaque thread se voit attribuer une base de données d'état temporaire indépendante (pending-stateDB). Lorsque les threads exécutent des transactions, ils ne modifient pas directement la base de données d'état globale, mais enregistrent 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 vers la stateDB globale. Si aucune collision d'état ne se produit lors de l'exécution de transactions différentes, les enregistrements du pending-stateDB peuvent être intégrés avec succès dans la stateDB globale.
Le projet a optimisé le traitement des opérations de lecture et d'écriture afin de 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 de l'état, l'EVM vérifie d'abord le ReadSet de l'état en attente. Si les données nécessaires existent, elles sont directement lues à partir de la base de données de l'état en attente. Si la paire clé-valeur correspondante n'est pas trouvée dans le ReadSet, les données d'état historique sont lues à partir de la base de données d'état global correspondante du bloc précédent.
Opérations d'écriture : toutes les opérations d'écriture ne sont pas directement écrites dans le stateDB global, mais sont d'abord enregistrées dans le WriteSet de l'état en attente. Une fois l'exécution de la transaction terminée, une détection des conflits est effectuée avant d'essayer de fusionner les résultats des modifications d'état dans le stateDB global.
Pour résoudre le problème de conflit d'état, un mécanisme de détection des conflits a été introduit :
Détection des conflits : L'EVM surveille les ReadSet et WriteSet 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 conflictuelle sera marquée comme nécessitant une réexécution.
Après l'exécution de toutes les transactions, plusieurs enregistrements de changement dans la pending-stateDB seront fusionnés dans la stateDB globale. Si la fusion est réussie, l'EVM soumettra l'état final à l'arbre d'état global et générera une nouvelle racine d'état.
L'optimisation parallèle multithreading améliore considérablement les 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 a été amélioré de 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 mises en œuvre, une amélioration allant jusqu'à 60 fois pourrait même être atteinte.
Résumé
La solution d'optimisation de la parallélisation multithread de l'EVM améliore considérablement 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 blockchain publique de l'EVM peut réaliser une parallélisation massive des transactions tout en garantissant la cohérence des états, résolvant ainsi le goulot d'étranglement de performance posé par le mode d'exécution séquentielle traditionnel. Cela jette une base importante pour le développement futur des Rollups d'Ethereum.
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.
15 J'aime
Récompense
15
8
Reposter
Partager
Commentaire
0/400
TokenVelocityTrauma
· 08-02 02:05
Les goulots d'étranglement de performance doivent être améliorés.
Voir l'originalRépondre0
ForkPrince
· 07-30 22:41
J'attends avec impatience l'optimisation et l'amélioration.
Voir l'originalRépondre0
MEVVictimAlliance
· 07-30 14:54
L'efficacité a été considérablement améliorée.
Voir l'originalRépondre0
FalseProfitProphet
· 07-30 10:43
La parallélisation accélère incroyablement.
Voir l'originalRépondre0
ShitcoinConnoisseur
· 07-30 10:42
Le goulot d'étranglement des performances en série est important.
Optimisation EVM : amélioration de l'efficacité du traitement des transactions grâce au parallélisme multithread.
Le chemin de l'optimisation de la parallélisation de l'EVM
Il est bien connu que l'EVM est l'un des composants clés d'Ethereum, jouant un rôle crucial en tant que "moteur d'exécution" et "environnement d'exécution des contrats intelligents". Dans un réseau de blockchain public composé de milliers de nœuds, la présence de la machine virtuelle permet aux contrats intelligents de s'exécuter de la même manière sur des nœuds avec des configurations matérielles différentes, garantissant la cohérence des résultats. Cette compatibilité multiplateforme est assez similaire à celle de la machine virtuelle Java (JVM).
Les contrats intelligents sont compilés en bytecode EVM avant d'être mis sur la chaîne. Lorsque l'EVM exécute le contrat, il lit ces bytecodes dans l'ordre, chaque instruction ayant un coût en Gas correspondant. L'EVM suit la consommation de Gas au cours de l'exécution des instructions, et la quantité consommée dépend de la complexité des opérations.
En tant que moteur d'exécution central d'Ethereum, l'EVM traite les transactions selon un mode d'exécution séquentiel. Toutes les transactions sont mises en file d'attente dans une seule file, exécutées dans l'ordre déterminé. Ce design est simple et facile à maintenir, mais à mesure que la base d'utilisateurs s'élargit et que la technologie évolue, ses goulets d'étranglement en matière de performance deviennent de plus en plus évidents, en particulier après la maturation de la technologie Rollup, qui se manifeste de manière particulièrement évidente dans le réseau de deuxième couche d'Ethereum.
Le séquenceur, en tant que composant clé de Layer2, assume toutes les tâches de calcul sous la forme d'un serveur unique. Si les modules externes associés sont suffisamment efficaces, le goulot d'étranglement final dépendra de l'efficacité du séquenceur lui-même, et à ce moment-là, l'exécution séquentielle deviendra un énorme obstacle.
Une équipe a optimisé de manière extrême la couche DA et le module de lecture/écriture des données, permettant au Séquenceur d'exécuter jusqu'à environ 2000 transactions ERC-20 par seconde. Ce chiffre semble élevé, mais pour des transactions complexes, le nombre de TPS sera nécessairement réduit. Par conséquent, la parallélisation du traitement des transactions sera une tendance inévitable pour l'avenir.
Les deux composants clés de l'exécution des transactions Ethereum
En dehors de l'EVM, un autre composant central lié à l'exécution des transactions dans go-ethereum est stateDB, 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 par l'EVM modifie certaines données dans stateDB, ces modifications se reflètent finalement dans l'arbre d'état global.
stateDB est responsable de la maintenance de tous les états des comptes Ethereum, y compris les comptes EOA et les comptes de contrats, les données stockées comprennent le solde des comptes, le code des contrats intelligents, etc. Au cours du processus d'exécution des transactions, stateDB effectue des opérations de lecture et d'écriture sur les données des comptes correspondants. Une fois l'exécution de la transaction terminée, stateDB doit soumettre le nouvel état à la base de données sous-jacente pour un traitement de persistance.
Dans l'ensemble, 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 les changements d'état de tous les comptes et 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 types de transaction Ethereum se divisent en transferts EOA et en transactions de contrat. Le transfert EOA est le type de transaction le plus simple, c'est-à-dire un transfert d'ETH entre comptes ordinaires, sans appel de contrat, avec une vitesse de traitement très rapide et des frais de gaz très bas.
Le trading de contrats implique l'appel et l'exécution de contrats intelligents. L'EVM, lors du traitement des transactions de contrat, doit interpréter et exécuter une par une les instructions de bytecode dans le 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 des transferts ERC-20 est environ deux fois plus long que celui des transferts EOA, tandis que des contrats intelligents plus complexes, tels que 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 pools de liquidités, des calculs de prix, des échanges de tokens et d'autres logiques complexes lors des transactions, nécessitant des calculs très complexes.
Dans le mode d'exécution séquentielle, le processus de collaboration entre l'EVM et la stateDB est le suivant :
Le goulot d'étranglement du mode d'exécution séquentielle de l'EVM est évident : les transactions doivent être exécutées dans l'ordre, et si une transaction de contrat intelligent prend beaucoup de temps, les autres transactions ne peuvent qu'attendre, ce qui empêche une utilisation optimale des ressources matérielles et limite considérablement l'efficacité.
Solution d'optimisation parallèle multithread pour EVM
L'EVM parallèle est similaire à une banque avec plusieurs guichets, où plusieurs threads peuvent être ouverts pour traiter simultanément plusieurs transactions, ce qui permet d'améliorer l'efficacité de plusieurs fois. Mais le problème difficile est celui des conflits d'état, qui nécessite un traitement coordonné.
Une approche d'optimisation parallèle de l'EVM pour un projet ZKRollup est la suivante :
Exécution parallèle des transactions multithread : configurez plusieurs threads pour traiter simultanément différentes transactions, les threads n'interfèrent pas les uns avec les autres, 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 : chaque thread se voit attribuer une base de données d'état temporaire indépendante (pending-stateDB). Lorsque les threads exécutent des transactions, ils ne modifient pas directement la base de données d'état globale, mais enregistrent 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 vers la stateDB globale. Si aucune collision d'état ne se produit lors de l'exécution de transactions différentes, les enregistrements du pending-stateDB peuvent être intégrés avec succès dans la stateDB globale.
Le projet a optimisé le traitement des opérations de lecture et d'écriture afin de 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 de l'état, l'EVM vérifie d'abord le ReadSet de l'état en attente. Si les données nécessaires existent, elles sont directement lues à partir de la base de données de l'état en attente. Si la paire clé-valeur correspondante n'est pas trouvée dans le ReadSet, les données d'état historique sont lues à partir de la base de données d'état global correspondante du bloc précédent.
Opérations d'écriture : toutes les opérations d'écriture ne sont pas directement écrites dans le stateDB global, mais sont d'abord enregistrées dans le WriteSet de l'état en attente. Une fois l'exécution de la transaction terminée, une détection des conflits est effectuée avant d'essayer de fusionner les résultats des modifications d'état dans le stateDB global.
Pour résoudre le problème de conflit d'état, un mécanisme de détection des conflits a été introduit :
Après l'exécution de toutes les transactions, plusieurs enregistrements de changement dans la pending-stateDB seront fusionnés dans la stateDB globale. Si la fusion est réussie, l'EVM soumettra l'état final à l'arbre d'état global et générera une nouvelle racine d'état.
L'optimisation parallèle multithreading améliore considérablement les 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 a été amélioré de 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 mises en œuvre, une amélioration allant jusqu'à 60 fois pourrait même être atteinte.
Résumé
La solution d'optimisation de la parallélisation multithread de l'EVM améliore considérablement 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 blockchain publique de l'EVM peut réaliser une parallélisation massive des transactions tout en garantissant la cohérence des états, résolvant ainsi le goulot d'étranglement de performance posé par le mode d'exécution séquentielle traditionnel. Cela jette une base importante pour le développement futur des Rollups d'Ethereum.