EVM parallélisation : la clé pour résoudre le goulot d'étranglement de performance d'Ethereum
L'EVM, en tant que moteur d'exécution d'Ethereum et environnement d'exécution des contrats intelligents, est l'un de ses composants les plus essentiels. Pour garantir que les contrats intelligents produisent les mêmes résultats sur différents nœuds et répondent aux exigences de cohérence, la technologie de la machine virtuelle est devenue le meilleur choix. L'EVM peut exécuter des contrats intelligents de la même manière sur différents systèmes d'exploitation et appareils, garantissant la compatibilité multiplateforme.
Les contrats intelligents sont compilés en bytecode EVM avant d'être mis en chaîne. Lorsque l'EVM exécute le contrat, il lit ces bytecodes séquentiellement, chaque instruction ayant un coût en Gas correspondant. L'EVM suit la consommation de Gas pendant l'exécution de chaque instruction, et la quantité consommée dépend de la complexité des opérations.
En tant que moteur d'exécution central, l'EVM traite les transactions de manière sérielle, toutes les transactions étant mises en file d'attente dans une seule queue et exécutées dans un ordre déterminé. Cette conception est simple et facile à entretenir, mais à mesure que la base d'utilisateurs s'élargit et que la technologie évolue, ses goulets d'étranglement en termes de performance deviennent de plus en plus évidents, en particulier dans Layer2.
Pour le composant clé Layer2, le séquenceur, si l'efficacité des modules associés est suffisamment élevée, le goulot d'étranglement final dépendra de l'efficacité du séquenceur lui-même. Certaines équipes ont atteint une optimisation extrême, permettant au séquenceur d'exécuter environ 2000 transactions ERC-20 par seconde. Cependant, pour des transactions plus complexes, le TPS diminuera nécessairement de manière significative. Par conséquent, la parallélisation du traitement des transactions devient une tendance inévitable pour l'avenir.
Composant central de l'exécution des transactions Ethereum
En plus de l'EVM, un autre composant central étroitement lié à l'exécution des transactions est le stateDB, utilisé pour gérer l'état des comptes et le stockage de données d'Ethereum. Ethereum utilise une structure d'arbre Merkle Patricia Trie comme index de base de données. Chaque exécution de transaction modifie certaines données dans le stateDB, et ces changements 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, stockant les soldes des comptes, le code des contrats intelligents et d'autres données. Pendant le processus d'exécution des transactions, stateDB lit et écrit les données des comptes correspondants. Une fois l'exécution de la transaction terminée, stateDB soumet le nouvel état à la base de données sous-jacente pour la 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.
Limites de l'exécution séquentielle
Les transactions sur 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, avec une vitesse de traitement rapide et des frais de gas faibles. Les transactions de contrat, en revanche, impliquent l'appel et l'exécution de contrats intelligents, l'EVM doit interpréter et exécuter ligne par ligne les instructions de code byte dans le contrat, ce qui entraîne une complexité et une consommation de ressources plus élevées.
En mode d'exécution séquentielle, les transactions dans le bloc sont traitées une par une dans l'ordre d'arrivée. Chaque transaction dispose d'une instance EVM indépendante, mais toutes les transactions partagent la même stateDB. L'EVM doit interagir continuellement avec la stateDB pendant l'exécution, lisant des données et écrivant les résultats modifiés.
Le goulot d'étranglement de ce mode d'exécution séquentielle est évident : les transactions doivent être exécutées en file d'attente. 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é.
Optimisation du parallélisme multithread de l'EVM
Pour surmonter les limitations de l'exécution séquentielle, l'industrie a proposé un plan d'optimisation multithreading pour l'EVM. Ce plan est similaire à une banque où plusieurs guichets servent en même temps, ce qui permet de traiter plusieurs transactions simultanément et d'améliorer considérablement l'efficacité. Cependant, le principal défi de l'exécution parallèle est le problème de conflit d'état, qui nécessite des mesures spéciales pour y faire face.
L'approche d'optimisation parallèle d'un certain projet pour l'EVM est la suivante :
Configurer plusieurs threads pour traiter simultanément différentes transactions, sans interférence entre les threads.
Allouer une base de données d'état temporaire indépendante (pending-stateDB) pour chaque thread. Lors de l'exécution des transactions par chaque thread, les changements d'état sont temporairement enregistrés dans le pending-stateDB, au lieu de modifier directement le stateDB global.
Une fois que toutes les transactions dans le bloc ont été exécutées, les modifications d'état dans chaque pending-stateDB sont synchronisées séquentiellement avec le stateDB global. S'il n'y a pas de conflit, les enregistrements peuvent être fusionnés sans problème.
Cette solution optimise les opérations de lecture et d'écriture :
Opération de lecture : d'abord vérifier le ReadSet de l'état en attente, si les données nécessaires sont présentes, les lire directement ; sinon, lire l'état historique à partir de la stateDB globale du bloc précédent.
Opérations d'écriture : toutes les modifications sont d'abord enregistrées dans le WriteSet de l'état en attente, puis tentées d'être fusionnées dans la stateDB globale après l'exécution de la transaction.
Pour résoudre le problème des conflits d'état, un mécanisme de détection des conflits a été introduit :
Surveiller les ReadSet et WriteSet de différentes transactions, considérant qu'un conflit se produit lorsque plusieurs transactions tentent de lire et d'écrire le même élément d'état.
Marquer les transactions conflictuelles comme nécessitant une réexécution.
Après l'exécution de toutes les transactions, les enregistrements de modification dans plusieurs stateDB en attente sont fusionnés dans le stateDB global. Après une fusion réussie, l'état final est soumis à l'arbre d'état global, générant une nouvelle racine d'état.
Des études montrent que, dans des charges de travail à faible conflit, le TPS exécuté en parallèle est amélioré de 3 à 5 fois par rapport à une exécution séquentielle traditionnelle. Dans des charges de travail à fort conflit, une optimisation théorique complète peut même atteindre une amélioration de 60 fois.
Résumé
La solution d'optimisation parallèle multithread EVM améliore considérablement la capacité de traitement des transactions en allouant une bibliothèque d'état temporaire pour 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, elle permet une parallélisation à grande échelle des transactions tout en garantissant la cohérence de l'état, résolvant ainsi le goulot d'étranglement de performance du modèle d'exécution séquentielle traditionnel. Cela pose une base importante pour le développement futur des Rollups d'Ethereum.
Dans le futur, il sera possible d'explorer davantage comment optimiser l'efficacité de stockage, faire face à des situations de haute concurrence, ainsi qu'optimiser grâce au GPU, afin d'améliorer encore les performances de l'EVM.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
6 J'aime
Récompense
6
6
Partager
Commentaire
0/400
down_only_larry
· Il y a 7h
hausse ! Vitalik Buterin a enfin compris.
Voir l'originalRépondre0
BlockTalk
· Il y a 7h
Aimez-le ou pas, de toute façon le TPS a augmenté.
Voir l'originalRépondre0
LiquidityOracle
· Il y a 7h
Encore souffler vers le ciel.
Voir l'originalRépondre0
All-InQueen
· Il y a 8h
Cela signifie que les transferts sont plus rapides?
Voir l'originalRépondre0
ProveMyZK
· Il y a 8h
Cette optimisation de performance appartient aux meilleurs joueurs.
Voir l'originalRépondre0
SmartContractPlumber
· Il y a 8h
Regardez directement le risque d'évolutivité, la conception du mécanisme de verrouillage est trop naïve.
Parallélisation de l'EVM : une percée pour améliorer les performances d'Ethereum
EVM parallélisation : la clé pour résoudre le goulot d'étranglement de performance d'Ethereum
L'EVM, en tant que moteur d'exécution d'Ethereum et environnement d'exécution des contrats intelligents, est l'un de ses composants les plus essentiels. Pour garantir que les contrats intelligents produisent les mêmes résultats sur différents nœuds et répondent aux exigences de cohérence, la technologie de la machine virtuelle est devenue le meilleur choix. L'EVM peut exécuter des contrats intelligents de la même manière sur différents systèmes d'exploitation et appareils, garantissant la compatibilité multiplateforme.
Les contrats intelligents sont compilés en bytecode EVM avant d'être mis en chaîne. Lorsque l'EVM exécute le contrat, il lit ces bytecodes séquentiellement, chaque instruction ayant un coût en Gas correspondant. L'EVM suit la consommation de Gas pendant l'exécution de chaque instruction, et la quantité consommée dépend de la complexité des opérations.
En tant que moteur d'exécution central, l'EVM traite les transactions de manière sérielle, toutes les transactions étant mises en file d'attente dans une seule queue et exécutées dans un ordre déterminé. Cette conception est simple et facile à entretenir, mais à mesure que la base d'utilisateurs s'élargit et que la technologie évolue, ses goulets d'étranglement en termes de performance deviennent de plus en plus évidents, en particulier dans Layer2.
Pour le composant clé Layer2, le séquenceur, si l'efficacité des modules associés est suffisamment élevée, le goulot d'étranglement final dépendra de l'efficacité du séquenceur lui-même. Certaines équipes ont atteint une optimisation extrême, permettant au séquenceur d'exécuter environ 2000 transactions ERC-20 par seconde. Cependant, pour des transactions plus complexes, le TPS diminuera nécessairement de manière significative. Par conséquent, la parallélisation du traitement des transactions devient une tendance inévitable pour l'avenir.
Composant central de l'exécution des transactions Ethereum
En plus de l'EVM, un autre composant central étroitement lié à l'exécution des transactions est le stateDB, utilisé pour gérer l'état des comptes et le stockage de données d'Ethereum. Ethereum utilise une structure d'arbre Merkle Patricia Trie comme index de base de données. Chaque exécution de transaction modifie certaines données dans le stateDB, et ces changements 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, stockant les soldes des comptes, le code des contrats intelligents et d'autres données. Pendant le processus d'exécution des transactions, stateDB lit et écrit les données des comptes correspondants. Une fois l'exécution de la transaction terminée, stateDB soumet le nouvel état à la base de données sous-jacente pour la 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.
Limites de l'exécution séquentielle
Les transactions sur 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, avec une vitesse de traitement rapide et des frais de gas faibles. Les transactions de contrat, en revanche, impliquent l'appel et l'exécution de contrats intelligents, l'EVM doit interpréter et exécuter ligne par ligne les instructions de code byte dans le contrat, ce qui entraîne une complexité et une consommation de ressources plus élevées.
En mode d'exécution séquentielle, les transactions dans le bloc sont traitées une par une dans l'ordre d'arrivée. Chaque transaction dispose d'une instance EVM indépendante, mais toutes les transactions partagent la même stateDB. L'EVM doit interagir continuellement avec la stateDB pendant l'exécution, lisant des données et écrivant les résultats modifiés.
Le goulot d'étranglement de ce mode d'exécution séquentielle est évident : les transactions doivent être exécutées en file d'attente. 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é.
Optimisation du parallélisme multithread de l'EVM
Pour surmonter les limitations de l'exécution séquentielle, l'industrie a proposé un plan d'optimisation multithreading pour l'EVM. Ce plan est similaire à une banque où plusieurs guichets servent en même temps, ce qui permet de traiter plusieurs transactions simultanément et d'améliorer considérablement l'efficacité. Cependant, le principal défi de l'exécution parallèle est le problème de conflit d'état, qui nécessite des mesures spéciales pour y faire face.
L'approche d'optimisation parallèle d'un certain projet pour l'EVM est la suivante :
Configurer plusieurs threads pour traiter simultanément différentes transactions, sans interférence entre les threads.
Allouer une base de données d'état temporaire indépendante (pending-stateDB) pour chaque thread. Lors de l'exécution des transactions par chaque thread, les changements d'état sont temporairement enregistrés dans le pending-stateDB, au lieu de modifier directement le stateDB global.
Une fois que toutes les transactions dans le bloc ont été exécutées, les modifications d'état dans chaque pending-stateDB sont synchronisées séquentiellement avec le stateDB global. S'il n'y a pas de conflit, les enregistrements peuvent être fusionnés sans problème.
Cette solution optimise les opérations de lecture et d'écriture :
Opération de lecture : d'abord vérifier le ReadSet de l'état en attente, si les données nécessaires sont présentes, les lire directement ; sinon, lire l'état historique à partir de la stateDB globale du bloc précédent.
Opérations d'écriture : toutes les modifications sont d'abord enregistrées dans le WriteSet de l'état en attente, puis tentées d'être fusionnées dans la stateDB globale après l'exécution de la transaction.
Pour résoudre le problème des conflits d'état, un mécanisme de détection des conflits a été introduit :
Après l'exécution de toutes les transactions, les enregistrements de modification dans plusieurs stateDB en attente sont fusionnés dans le stateDB global. Après une fusion réussie, l'état final est soumis à l'arbre d'état global, générant une nouvelle racine d'état.
Des études montrent que, dans des charges de travail à faible conflit, le TPS exécuté en parallèle est amélioré de 3 à 5 fois par rapport à une exécution séquentielle traditionnelle. Dans des charges de travail à fort conflit, une optimisation théorique complète peut même atteindre une amélioration de 60 fois.
Résumé
La solution d'optimisation parallèle multithread EVM améliore considérablement la capacité de traitement des transactions en allouant une bibliothèque d'état temporaire pour 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, elle permet une parallélisation à grande échelle des transactions tout en garantissant la cohérence de l'état, résolvant ainsi le goulot d'étranglement de performance du modèle d'exécution séquentielle traditionnel. Cela pose une base importante pour le développement futur des Rollups d'Ethereum.
Dans le futur, il sera possible d'explorer davantage comment optimiser l'efficacité de stockage, faire face à des situations de haute concurrence, ainsi qu'optimiser grâce au GPU, afin d'améliorer encore les performances de l'EVM.