Optimisation de la parallélisation EVM : Amélioration de l'efficacité du traitement des transactions Ethereum
L'EVM, en tant que moteur d'exécution central d'Ethereum, est positionné comme un "environnement d'exécution des contrats intelligents". Pour garantir que les contrats intelligents produisent des résultats cohérents sur différents nœuds, l'EVM fournit un environnement virtuel multiplateforme, similaire à la machine virtuelle Java (JVM).
Les contrats intelligents sont compilés en bytecode EVM et stockés sur la chaîne lors de leur déploiement. L'EVM lit ces bytecodes séquentiellement lors de l'exécution des contrats, chaque instruction ayant un coût en Gas correspondant. L'EVM suit la consommation de Gas pendant l'exécution des instructions, et la quantité consommée dépend de la complexité des opérations.
Les EVM traditionnels traitent les transactions de manière séquentielle, toutes les transactions étant exécutées dans un ordre déterminé dans une seule file d'attente. Ce design est simple et facile à maintenir, mais avec l'augmentation de la taille des utilisateurs et l'application de la technologie Rollup, le goulot d'étranglement des performances de l'exécution séquentielle devient de plus en plus évident.
Dans l'architecture Rollup, le Sequencer, en tant que composant clé de la couche 2, assume toutes les tâches de calcul. Si d'autres modules externes sont suffisamment efficaces, l'exécution séquentielle du Sequencer elle-même deviendra le principal goulet d'étranglement. Une équipe a réussi à optimiser au maximum le Sequencer pour qu'il puisse exécuter plus de 2000 transactions ERC-20 par seconde, mais pour des transactions plus complexes, le TPS diminuera considérablement. Par conséquent, la parallélisation du traitement des transactions devient une tendance de développement future.
En plus de l'EVM, un autre composant clé lié à l'exécution des transactions dans go-ethereum est stateDB, qui est utilisé pour gérer l'état des comptes et le stockage des données. Ethereum utilise une structure d'arbre Merkle Patricia Trie comme index de base de données, chaque exécution de transaction par l'EVM modifiant les données dans stateDB, ce qui se reflète finalement dans l'arbre d'état global.
stateDB est responsable de la maintenance de tous les états des comptes Ethereum, y compris le solde des comptes, le code des contrats intelligents, etc. Pendant le processus d'exécution des transactions, stateDB effectue des opérations de lecture et d'écriture sur les données des comptes concernés, et après la fin de l'exécution, il soumet le nouvel état à la base de données sous-jacente pour la persistance.
L'EVM et stateDB collaborent pour construire l'environnement d'exécution des transactions d'Ethereum. 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 de calcul, tandis que stateDB sert de stockage d'état global, gérant tous les changements d'état des comptes et des contrats.
En mode d'exécution séquentielle, les transactions au sein d'un bloc sont traitées une par une dans l'ordre. Chaque transaction utilise une instance EVM indépendante, mais toutes les transactions partagent la même stateDB. L'EVM doit interagir en continu avec la stateDB pendant l'exécution, en lisant les données pertinentes et en écrivant les résultats des modifications.
Après l'exécution de toutes les transactions dans le bloc, les données dans stateDB seront soumises à l'arbre d'état global, générant une nouvelle racine d'état. Le principal goulot d'étranglement de ce mode sériel est que les transactions doivent être exécutées en file d'attente, ce qui ne permet pas d'utiliser pleinement les ressources matérielles, en particulier lorsque l'on fait face à des transactions de contrats intelligents complexes, l'efficacité étant relativement faible.
Pour améliorer l'efficacité du traitement des transactions, certains projets commencent à essayer l'optimisation parallèle multithread de l'EVM. Cela ressemble à une banque qui ouvre plusieurs guichets pour servir les clients en même temps, ce qui peut multiplier par plusieurs la vitesse de traitement, mais il est nécessaire de résoudre les problèmes de conflits d'état qui pourraient survenir.
Un projet ZKRollup a pour approche d'optimisation parallèle de l'EVM d'allouer une base de données d'état temporaire (pending-stateDB) à chaque fil d'exécution. Les détails de l'implémentation incluent :
Exécution des transactions en parallèle avec plusieurs threads, sans interférence.
Chaque thread a sa propre base de données d'état en attente, les changements d'état sont d'abord enregistrés ici lors de l'exécution des transactions.
Une fois toutes les transactions exécutées, synchronisez les modifications de pending-stateDB avec le stateDB global.
Cette solution optimise les opérations de lecture et d'écriture :
Lors de l'opération de lecture, vérifiez d'abord le ReadSet de la pending-stateDB. Si les données nécessaires sont présentes, lisez-les directement ; sinon, lisez l'état historique à partir de la stateDB globale.
Les opérations d'écriture ne sont pas directement enregistrées dans le stateDB global, mais sont d'abord enregistrées dans le WriteSet du pending-stateDB.
Pour gérer les conflits d'état, un mécanisme de détection des conflits a été introduit :
Surveiller les ReadSet et WriteSet des différentes transactions, considérer comme des conflits lorsque plusieurs transactions lisent et écrivent les mêmes éléments d'état.
Les transactions conflictuelles seront marquées comme nécessitant une réexécution.
Après l'exécution de toutes les transactions, plusieurs enregistrements de modifications de la pending-stateDB seront fusionnés dans la stateDB globale, et après succès, soumis à l'arbre d'état global et généreront une nouvelle racine d'état.
Des recherches montrent que, dans des charges de travail à faible conflit, le TPS de l'EVM parallèle est 3 à 5 fois supérieur à celui de l'exécution sérielle traditionnelle. Dans des charges de travail à fort conflit, l'amélioration théorique peut atteindre jusqu'à 60 fois.
Cette solution d'optimisation parallèle multithread améliore considérablement la capacité de traitement des transactions de l'EVM grâce à une bibliothèque d'état temporaire et à une exécution parallèle. L'optimisation des opérations de lecture et d'écriture et l'introduction d'un mécanisme de détection des conflits permettent d'obtenir une parallélisation à grande échelle des transactions tout en garantissant la cohérence des états, résolvant ainsi le goulet d'étranglement de performance de l'exécution séquentielle et posant les bases du 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.
10 J'aime
Récompense
10
5
Partager
Commentaire
0/400
AirdropHunterZhang
· 07-29 02:07
Je ne le ferai plus, 60 fois par jour, les crêpes sont toujours à ce prix.
Voir l'originalRépondre0
GateUser-afe07a92
· 07-28 22:11
C'est juste une amélioration du TPS.
Voir l'originalRépondre0
ZKProofEnthusiast
· 07-28 22:09
Maître, comment TPS peut-il encore assurer la confidentialité off-chain si rapidement ?
Voir l'originalRépondre0
¯\_(ツ)_/¯
· 07-28 21:56
Continuez à Mining comme ça.
Voir l'originalRépondre0
GateUser-aa7df71e
· 07-28 21:48
Entrer dans une position les frères, le big pump de TPS est sur le point d'arriver.
Optimisation parallèle EVM : Augmenter l'efficacité du traitement des transactions Ethereum de 5 à 60 fois
Optimisation de la parallélisation EVM : Amélioration de l'efficacité du traitement des transactions Ethereum
L'EVM, en tant que moteur d'exécution central d'Ethereum, est positionné comme un "environnement d'exécution des contrats intelligents". Pour garantir que les contrats intelligents produisent des résultats cohérents sur différents nœuds, l'EVM fournit un environnement virtuel multiplateforme, similaire à la machine virtuelle Java (JVM).
Les contrats intelligents sont compilés en bytecode EVM et stockés sur la chaîne lors de leur déploiement. L'EVM lit ces bytecodes séquentiellement lors de l'exécution des contrats, chaque instruction ayant un coût en Gas correspondant. L'EVM suit la consommation de Gas pendant l'exécution des instructions, et la quantité consommée dépend de la complexité des opérations.
Les EVM traditionnels traitent les transactions de manière séquentielle, toutes les transactions étant exécutées dans un ordre déterminé dans une seule file d'attente. Ce design est simple et facile à maintenir, mais avec l'augmentation de la taille des utilisateurs et l'application de la technologie Rollup, le goulot d'étranglement des performances de l'exécution séquentielle devient de plus en plus évident.
Dans l'architecture Rollup, le Sequencer, en tant que composant clé de la couche 2, assume toutes les tâches de calcul. Si d'autres modules externes sont suffisamment efficaces, l'exécution séquentielle du Sequencer elle-même deviendra le principal goulet d'étranglement. Une équipe a réussi à optimiser au maximum le Sequencer pour qu'il puisse exécuter plus de 2000 transactions ERC-20 par seconde, mais pour des transactions plus complexes, le TPS diminuera considérablement. Par conséquent, la parallélisation du traitement des transactions devient une tendance de développement future.
En plus de l'EVM, un autre composant clé lié à l'exécution des transactions dans go-ethereum est stateDB, qui est utilisé pour gérer l'état des comptes et le stockage des données. Ethereum utilise une structure d'arbre Merkle Patricia Trie comme index de base de données, chaque exécution de transaction par l'EVM modifiant les données dans stateDB, ce qui se reflète finalement dans l'arbre d'état global.
stateDB est responsable de la maintenance de tous les états des comptes Ethereum, y compris le solde des comptes, le code des contrats intelligents, etc. Pendant le processus d'exécution des transactions, stateDB effectue des opérations de lecture et d'écriture sur les données des comptes concernés, et après la fin de l'exécution, il soumet le nouvel état à la base de données sous-jacente pour la persistance.
L'EVM et stateDB collaborent pour construire l'environnement d'exécution des transactions d'Ethereum. 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 de calcul, tandis que stateDB sert de stockage d'état global, gérant tous les changements d'état des comptes et des contrats.
En mode d'exécution séquentielle, les transactions au sein d'un bloc sont traitées une par une dans l'ordre. Chaque transaction utilise une instance EVM indépendante, mais toutes les transactions partagent la même stateDB. L'EVM doit interagir en continu avec la stateDB pendant l'exécution, en lisant les données pertinentes et en écrivant les résultats des modifications.
Après l'exécution de toutes les transactions dans le bloc, les données dans stateDB seront soumises à l'arbre d'état global, générant une nouvelle racine d'état. Le principal goulot d'étranglement de ce mode sériel est que les transactions doivent être exécutées en file d'attente, ce qui ne permet pas d'utiliser pleinement les ressources matérielles, en particulier lorsque l'on fait face à des transactions de contrats intelligents complexes, l'efficacité étant relativement faible.
Pour améliorer l'efficacité du traitement des transactions, certains projets commencent à essayer l'optimisation parallèle multithread de l'EVM. Cela ressemble à une banque qui ouvre plusieurs guichets pour servir les clients en même temps, ce qui peut multiplier par plusieurs la vitesse de traitement, mais il est nécessaire de résoudre les problèmes de conflits d'état qui pourraient survenir.
Un projet ZKRollup a pour approche d'optimisation parallèle de l'EVM d'allouer une base de données d'état temporaire (pending-stateDB) à chaque fil d'exécution. Les détails de l'implémentation incluent :
Exécution des transactions en parallèle avec plusieurs threads, sans interférence.
Chaque thread a sa propre base de données d'état en attente, les changements d'état sont d'abord enregistrés ici lors de l'exécution des transactions.
Une fois toutes les transactions exécutées, synchronisez les modifications de pending-stateDB avec le stateDB global.
Cette solution optimise les opérations de lecture et d'écriture :
Lors de l'opération de lecture, vérifiez d'abord le ReadSet de la pending-stateDB. Si les données nécessaires sont présentes, lisez-les directement ; sinon, lisez l'état historique à partir de la stateDB globale.
Les opérations d'écriture ne sont pas directement enregistrées dans le stateDB global, mais sont d'abord enregistrées dans le WriteSet du pending-stateDB.
Pour gérer les conflits d'état, un mécanisme de détection des conflits a été introduit :
Surveiller les ReadSet et WriteSet des différentes transactions, considérer comme des conflits lorsque plusieurs transactions lisent et écrivent les mêmes éléments d'état.
Les transactions conflictuelles seront marquées comme nécessitant une réexécution.
Après l'exécution de toutes les transactions, plusieurs enregistrements de modifications de la pending-stateDB seront fusionnés dans la stateDB globale, et après succès, soumis à l'arbre d'état global et généreront une nouvelle racine d'état.
Des recherches montrent que, dans des charges de travail à faible conflit, le TPS de l'EVM parallèle est 3 à 5 fois supérieur à celui de l'exécution sérielle traditionnelle. Dans des charges de travail à fort conflit, l'amélioration théorique peut atteindre jusqu'à 60 fois.
Cette solution d'optimisation parallèle multithread améliore considérablement la capacité de traitement des transactions de l'EVM grâce à une bibliothèque d'état temporaire et à une exécution parallèle. L'optimisation des opérations de lecture et d'écriture et l'introduction d'un mécanisme de détection des conflits permettent d'obtenir une parallélisation à grande échelle des transactions tout en garantissant la cohérence des états, résolvant ainsi le goulet d'étranglement de performance de l'exécution séquentielle et posant les bases du développement futur des Rollups d'Ethereum.