Optimisation de la parallélisation EVM : la clé pour améliorer les performances de la Blockchain
L'EVM, en tant que moteur d'exécution central d'Ethereum, a toujours traité les transactions de manière séquentielle. Bien que cette méthode soit simple et facile à maintenir, ses goulets d'étranglement en matière de performance se sont de plus en plus révélés avec l'élargissement de la base d'utilisateurs et les avancées technologiques. En particulier, à l'heure où la technologie Rollup est largement utilisée, l'exécution séquentielle de l'EVM est devenue un facteur limitant le développement des réseaux de deuxième couche.
Le Sequencer, en tant que composant central de Layer2, assume toutes les tâches de calcul sous la forme d'un serveur unique. Lorsque l'efficacité des autres modules est suffisamment élevée, la capacité de traitement du Sequencer lui-même devient le goulot d'étranglement final. Certaines équipes ont optimisé le niveau DA et les modules de lecture et d'écriture des données, permettant au Sequencer d'exécuter environ 2000 transferts ERC-20 par seconde. Ce chiffre semble relativement élevé, mais face à des transactions plus complexes, le TPS diminuera inévitablement de manière significative. Par conséquent, la parallélisation du traitement des transactions devient une tendance inévitable pour le développement futur.
Dans la structure de code d'Ethereum, en plus de l'EVM, le stateDB est également un composant clé étroitement lié à l'exécution des transactions. Il est responsable de la gestion de l'état des comptes et du stockage des données d'Ethereum. Chaque fois que l'EVM exécute une transaction, certaines données dans le stateDB sont modifiées, ces changements se reflètent finalement dans l'arbre d'état global.
stateDB maintient principalement l'état de tous les comptes Ethereum, y compris les comptes ordinaires et les comptes de contrat, stockant les soldes des comptes, le code des contrats intelligents et d'autres informations. Pendant le processus d'exécution des transactions, stateDB lit et écrit les données des comptes correspondants, et après la fin de l'exécution, soumet le nouvel état à la base de données sous-jacente pour un stockage permanent.
Dans le mode d'exécution traditionnel séquentiel, les transactions au sein d'un Bloc sont traitées une par une dans l'ordre. Chaque transaction dispose d'une instance EVM indépendante pour exécuter des opérations spécifiques, mais toutes les transactions partagent la même stateDB. L'EVM nécessite des interactions fréquentes avec la stateDB pendant l'exécution, lisant et écrivant des données connexes.
Les défauts de ce mode d'exécution séquentielle sont évidents : les transactions doivent faire la queue pour être exécutées, et si une transaction de contrat complexe prend beaucoup de temps, les transactions suivantes doivent attendre, ce qui empêche une utilisation optimale des ressources matérielles et limite gravement l'efficacité de traitement.
Pour surmonter ce goulot d'étranglement, l'industrie a proposé une solution d'optimisation parallèle multithread pour l'EVM. L'idée principale est d'ouvrir plusieurs threads pour traiter simultanément plusieurs transactions, ce qui améliore considérablement l'efficacité. Cependant, le principal défi de l'exécution parallèle est de savoir comment gérer les problèmes de conflit d'état.
Une approche d'optimisation parallèle pour EVM d'un certain projet mérite d'être remarquée. Ils attribuent une transaction et une base de données d'état temporaire (pending-stateDB) à chaque thread. Les étapes spécifiques sont les suivantes :
Exécution parallèle des transactions en multithreading, les différents threads n'interfèrent pas les uns avec les autres.
Chaque thread dispose d'un état de base de données en attente indépendant, l'exécution des transactions ne modifie pas directement l'état de la base de données globale, mais conserve temporairement les changements d'état dans l'état de la base de données en attente.
Une fois que toutes les transactions dans le bloc ont été exécutées, l'EVM synchronise successivement les modifications d'état dans les pending-stateDB vers le stateDB global.
Le projet a également optimisé les opérations de lecture et d'écriture :
Lors d'une opération de lecture, l'EVM vérifie d'abord le ReadSet de l'état en attente. Si les données nécessaires sont présentes, elles sont directement lues à partir de la pending-stateDB ; sinon, elles sont lues à partir de l'état global de la stateDB du bloc précédent.
Les opérations d'écriture ne sont pas directement enregistrées dans le stateDB global, mais sont d'abord enregistrées dans le WriteSet d'état en attente. Une fois l'exécution de la transaction terminée, une détection de conflit est effectuée avant d'essayer de fusionner avec le stateDB global.
Pour résoudre le problème des conflits d'état, le projet a introduit un mécanisme de détection des conflits :
Pendant le processus d'exécution, surveillez les ReadSet et WriteSet de différentes transactions, et considérez comme un conflit lorsque plusieurs transactions lisent et écrivent le même élément d'état.
Marquer les transactions conflictuelles comme nécessitant une nouvelle exécution.
Après l'exécution de toutes les transactions, plusieurs enregistrements de modifications de pending-stateDB sont fusionnés dans le stateDB global. Une fois la fusion réussie, l'état final est soumis à l'arbre d'état global, générant une nouvelle racine d'état.
L'optimisation parallèle multithread a considérablement amélioré les performances, notamment lors du traitement de transactions complexes de contrats intelligents. Des études montrent qu'avec une charge de travail à faible conflit, le TPS des tests de référence est augmenté de 3 à 5 fois par rapport à l'exécution séquentielle traditionnelle. Dans des charges de travail à fort conflit, théoriquement, en utilisant toutes les méthodes d'optimisation, on pourrait même atteindre une amélioration de 60 fois.
Cette solution d'optimisation parallèle multithread EVM améliore considérablement la capacité de traitement des transactions de l'EVM en allouant une bibliothèque d'état temporaire pour chaque transaction et en exécutant 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 des états, résolvant ainsi efficacement le goulet d'étranglement de performance du modèle d'exécution séquentielle traditionnel. Cela jette une base importante pour l'expansion future de l'écosystème Ethereum.
Les futures directions de recherche pourraient inclure l'optimisation supplémentaire de l'efficacité du stockage, l'amélioration des solutions de traitement en cas de conflits élevés, ainsi que l'exploration de l'optimisation par le biais des GPU. Ces avancées fourniront une nouvelle dynamique au développement continu de la Blockchain.
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.
14 J'aime
Récompense
14
7
Reposter
Partager
Commentaire
0/400
MEVVictimAlliance
· Il y a 6h
La concurrence est en train de me bloquer.
Voir l'originalRépondre0
MelonField
· Il y a 6h
Toujours en train de vanter l'EVM, c'est une vue désagréable.
Voir l'originalRépondre0
MetaDreamer
· Il y a 6h
Amélioration des performances de 60 fois ? gm doit encore passer une commande pour commencer.
Voir l'originalRépondre0
TestnetScholar
· Il y a 6h
Optimisez cette carte rapidement.
Voir l'originalRépondre0
faded_wojak.eth
· Il y a 6h
卡啦 并行化To the moon啊
Voir l'originalRépondre0
BugBountyHunter
· Il y a 7h
Si ça bloque, il faut aller en parallèle et s'engager dans la compétition!
Voir l'originalRépondre0
DefiPlaybook
· Il y a 7h
Ce goulot d'étranglement n'attend-il pas d'être exploité ? Les Bots de course sont en extase.
Optimisation parallèle EVM : la technologie clé pour améliorer les performances de la Blockchain de 60 fois
Optimisation de la parallélisation EVM : la clé pour améliorer les performances de la Blockchain
L'EVM, en tant que moteur d'exécution central d'Ethereum, a toujours traité les transactions de manière séquentielle. Bien que cette méthode soit simple et facile à maintenir, ses goulets d'étranglement en matière de performance se sont de plus en plus révélés avec l'élargissement de la base d'utilisateurs et les avancées technologiques. En particulier, à l'heure où la technologie Rollup est largement utilisée, l'exécution séquentielle de l'EVM est devenue un facteur limitant le développement des réseaux de deuxième couche.
Le Sequencer, en tant que composant central de Layer2, assume toutes les tâches de calcul sous la forme d'un serveur unique. Lorsque l'efficacité des autres modules est suffisamment élevée, la capacité de traitement du Sequencer lui-même devient le goulot d'étranglement final. Certaines équipes ont optimisé le niveau DA et les modules de lecture et d'écriture des données, permettant au Sequencer d'exécuter environ 2000 transferts ERC-20 par seconde. Ce chiffre semble relativement élevé, mais face à des transactions plus complexes, le TPS diminuera inévitablement de manière significative. Par conséquent, la parallélisation du traitement des transactions devient une tendance inévitable pour le développement futur.
Dans la structure de code d'Ethereum, en plus de l'EVM, le stateDB est également un composant clé étroitement lié à l'exécution des transactions. Il est responsable de la gestion de l'état des comptes et du stockage des données d'Ethereum. Chaque fois que l'EVM exécute une transaction, certaines données dans le stateDB sont modifiées, ces changements se reflètent finalement dans l'arbre d'état global.
stateDB maintient principalement l'état de tous les comptes Ethereum, y compris les comptes ordinaires et les comptes de contrat, stockant les soldes des comptes, le code des contrats intelligents et d'autres informations. Pendant le processus d'exécution des transactions, stateDB lit et écrit les données des comptes correspondants, et après la fin de l'exécution, soumet le nouvel état à la base de données sous-jacente pour un stockage permanent.
Dans le mode d'exécution traditionnel séquentiel, les transactions au sein d'un Bloc sont traitées une par une dans l'ordre. Chaque transaction dispose d'une instance EVM indépendante pour exécuter des opérations spécifiques, mais toutes les transactions partagent la même stateDB. L'EVM nécessite des interactions fréquentes avec la stateDB pendant l'exécution, lisant et écrivant des données connexes.
Les défauts de ce mode d'exécution séquentielle sont évidents : les transactions doivent faire la queue pour être exécutées, et si une transaction de contrat complexe prend beaucoup de temps, les transactions suivantes doivent attendre, ce qui empêche une utilisation optimale des ressources matérielles et limite gravement l'efficacité de traitement.
Pour surmonter ce goulot d'étranglement, l'industrie a proposé une solution d'optimisation parallèle multithread pour l'EVM. L'idée principale est d'ouvrir plusieurs threads pour traiter simultanément plusieurs transactions, ce qui améliore considérablement l'efficacité. Cependant, le principal défi de l'exécution parallèle est de savoir comment gérer les problèmes de conflit d'état.
Une approche d'optimisation parallèle pour EVM d'un certain projet mérite d'être remarquée. Ils attribuent une transaction et une base de données d'état temporaire (pending-stateDB) à chaque thread. Les étapes spécifiques sont les suivantes :
Exécution parallèle des transactions en multithreading, les différents threads n'interfèrent pas les uns avec les autres.
Chaque thread dispose d'un état de base de données en attente indépendant, l'exécution des transactions ne modifie pas directement l'état de la base de données globale, mais conserve temporairement les changements d'état dans l'état de la base de données en attente.
Une fois que toutes les transactions dans le bloc ont été exécutées, l'EVM synchronise successivement les modifications d'état dans les pending-stateDB vers le stateDB global.
Le projet a également optimisé les opérations de lecture et d'écriture :
Lors d'une opération de lecture, l'EVM vérifie d'abord le ReadSet de l'état en attente. Si les données nécessaires sont présentes, elles sont directement lues à partir de la pending-stateDB ; sinon, elles sont lues à partir de l'état global de la stateDB du bloc précédent.
Les opérations d'écriture ne sont pas directement enregistrées dans le stateDB global, mais sont d'abord enregistrées dans le WriteSet d'état en attente. Une fois l'exécution de la transaction terminée, une détection de conflit est effectuée avant d'essayer de fusionner avec le stateDB global.
Pour résoudre le problème des conflits d'état, le projet a introduit un mécanisme de détection des conflits :
Pendant le processus d'exécution, surveillez les ReadSet et WriteSet de différentes transactions, et considérez comme un conflit lorsque plusieurs transactions lisent et écrivent le même élément d'état.
Marquer les transactions conflictuelles comme nécessitant une nouvelle exécution.
Après l'exécution de toutes les transactions, plusieurs enregistrements de modifications de pending-stateDB sont fusionnés dans le stateDB global. Une fois la fusion réussie, l'état final est soumis à l'arbre d'état global, générant une nouvelle racine d'état.
L'optimisation parallèle multithread a considérablement amélioré les performances, notamment lors du traitement de transactions complexes de contrats intelligents. Des études montrent qu'avec une charge de travail à faible conflit, le TPS des tests de référence est augmenté de 3 à 5 fois par rapport à l'exécution séquentielle traditionnelle. Dans des charges de travail à fort conflit, théoriquement, en utilisant toutes les méthodes d'optimisation, on pourrait même atteindre une amélioration de 60 fois.
Cette solution d'optimisation parallèle multithread EVM améliore considérablement la capacité de traitement des transactions de l'EVM en allouant une bibliothèque d'état temporaire pour chaque transaction et en exécutant 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 des états, résolvant ainsi efficacement le goulet d'étranglement de performance du modèle d'exécution séquentielle traditionnel. Cela jette une base importante pour l'expansion future de l'écosystème Ethereum.
Les futures directions de recherche pourraient inclure l'optimisation supplémentaire de l'efficacité du stockage, l'amélioration des solutions de traitement en cas de conflits élevés, ainsi que l'exploration de l'optimisation par le biais des GPU. Ces avancées fourniront une nouvelle dynamique au développement continu de la Blockchain.