La voie de la parallélisation de l'EVM : de l'exécution sérielle à l'exécution multithread
Comme tout le monde le sait, l'EVM est le moteur d'exécution central d'Ethereum, responsable de l'exécution des contrats intelligents. Pour garantir que les contrats intelligents sur différents nœuds obtiennent les mêmes résultats d'exécution, l'EVM fournit un environnement virtuel unifié, similaire à la machine virtuelle Java (JVM).
Un contrat intelligent, lorsqu'il est déployé sur la blockchain, est d'abord compilé en bytecode EVM. Lors de l'exécution du contrat, l'EVM lit ces bytecodes dans l'ordre, chaque instruction ayant un coût en Gas correspondant. L'EVM suit la consommation de Gas pour chaque instruction exécutée, et cette consommation dépend de la complexité de l'opération.
L'EVM traditionnel traite les transactions de manière séquentielle, toutes les transactions étant mises en file d'attente dans une seule file d'attente et exécutées dans l'ordre. Ce design est simple et facile à maintenir, mais avec l'augmentation du nombre d'utilisateurs et des exigences en matière de TPS, les goulets d'étranglement de performance de l'exécution séquentielle deviennent de plus en plus évidents, en particulier dans les solutions de couche 2.
En dehors de l'EVM, un autre composant clé de l'exécution des transactions Ethereum est le stateDB, qui gère l'état des comptes et le stockage des données. Chaque fois que l'EVM exécute une transaction, elle met à jour les données dans le stateDB, et ces changements se reflètent finalement dans l'arbre d'état global.
Dans le mode d'exécution en série, le processus par lequel l'EVM et la stateDB collaborent pour traiter les transactions est le suivant :
Les transactions dans un bloc sont traitées une par une dans l'ordre.
Chaque transaction utilise une instance EVM indépendante, mais partage la même stateDB.
L'exécution de l'EVM interagit constamment avec stateDB, lisant et écrivant des données.
Après que toutes les transactions ont été traitées, les modifications dans stateDB seront soumises à l'arbre d'état global.
Le principal problème de ce mode de fonctionnement en série est que des transactions de contrats intelligents complexes peuvent bloquer d'autres transactions et ne pas tirer pleinement parti des ressources matérielles.
Pour résoudre ce problème, certains projets commencent à explorer des solutions d'optimisation parallèle pour l'EVM. Prenons l'exemple d'un projet Layer 2, dont l'idée principale est d'allouer une base de données d'état temporaire à chaque thread (pending-stateDB) :
Exécution parallèle de différentes transactions en multithreading
Chaque thread utilise un enregistrement d'état indépendant dans le pending-stateDB pour enregistrer les modifications d'état.
Une fois toutes les transactions exécutées, synchronisez les modifications de pending-stateDB avec le stateDB global.
Cette solution traite les opérations de lecture et d'écriture de manière spéciale :
Les opérations de lecture vérifient d'abord la pending-stateDB, s'il n'y a pas de données, alors elles lisent la stateDB globale.
Les opérations d'écriture sont temporairement stockées dans pending-stateDB et ne modifient pas directement le stateDB global.
Pour éviter les conflits d'état, ce plan introduit un mécanisme de détection des conflits :
Surveiller si les ensembles de lecture et d'écriture des différentes transactions se chevauchent.
Marquer les transactions concernées à réexécuter en cas de conflit détecté.
Enfin, fusionnez plusieurs modifications de pending-stateDB dans le stateDB global pour générer une nouvelle racine d'état.
Cette solution d'optimisation parallèle peut augmenter le TPS de 3 à 5 fois sous une charge de travail à faible conflit. Dans des situations de conflit élevé, elle peut théoriquement atteindre une amélioration de 60 fois.
Dans l'ensemble, la parallélisation de l'EVM est une direction importante pour améliorer les performances d'Ethereum et de ses Layer 2. Grâce à des technologies telles que l'exécution parallèle multithread et les bibliothèques d'état temporaire, il est possible d'augmenter considérablement la capacité de traitement des transactions tout en garantissant la cohérence. À l'avenir, il sera également possible d'améliorer davantage les performances de l'EVM en optimisant l'efficacité du stockage et en améliorant les stratégies de gestion des conflits.
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.
8 J'aime
Récompense
8
5
Partager
Commentaire
0/400
FlatTax
· 07-24 20:11
60 fois ? bull sans taxe
Voir l'originalRépondre0
FastLeaver
· 07-22 02:02
Pas mal, on peut multiplier le TPS par 60.
Voir l'originalRépondre0
NftDeepBreather
· 07-22 00:27
Après, le roi BTC revient.
Voir l'originalRépondre0
CounterIndicator
· 07-22 00:11
haussier est le sommet, chute est le fond
Voir l'originalRépondre0
SerumDegen
· 07-22 00:10
just another copium to pump eth tbh... montre-moi les vrais chiffres de tps d'abord
Percée de la parallélisation EVM : l'exécution multithread améliore la capacité de traitement des transactions
La voie de la parallélisation de l'EVM : de l'exécution sérielle à l'exécution multithread
Comme tout le monde le sait, l'EVM est le moteur d'exécution central d'Ethereum, responsable de l'exécution des contrats intelligents. Pour garantir que les contrats intelligents sur différents nœuds obtiennent les mêmes résultats d'exécution, l'EVM fournit un environnement virtuel unifié, similaire à la machine virtuelle Java (JVM).
Un contrat intelligent, lorsqu'il est déployé sur la blockchain, est d'abord compilé en bytecode EVM. Lors de l'exécution du contrat, l'EVM lit ces bytecodes dans l'ordre, chaque instruction ayant un coût en Gas correspondant. L'EVM suit la consommation de Gas pour chaque instruction exécutée, et cette consommation dépend de la complexité de l'opération.
L'EVM traditionnel traite les transactions de manière séquentielle, toutes les transactions étant mises en file d'attente dans une seule file d'attente et exécutées dans l'ordre. Ce design est simple et facile à maintenir, mais avec l'augmentation du nombre d'utilisateurs et des exigences en matière de TPS, les goulets d'étranglement de performance de l'exécution séquentielle deviennent de plus en plus évidents, en particulier dans les solutions de couche 2.
En dehors de l'EVM, un autre composant clé de l'exécution des transactions Ethereum est le stateDB, qui gère l'état des comptes et le stockage des données. Chaque fois que l'EVM exécute une transaction, elle met à jour les données dans le stateDB, et ces changements se reflètent finalement dans l'arbre d'état global.
Dans le mode d'exécution en série, le processus par lequel l'EVM et la stateDB collaborent pour traiter les transactions est le suivant :
Le principal problème de ce mode de fonctionnement en série est que des transactions de contrats intelligents complexes peuvent bloquer d'autres transactions et ne pas tirer pleinement parti des ressources matérielles.
Pour résoudre ce problème, certains projets commencent à explorer des solutions d'optimisation parallèle pour l'EVM. Prenons l'exemple d'un projet Layer 2, dont l'idée principale est d'allouer une base de données d'état temporaire à chaque thread (pending-stateDB) :
Cette solution traite les opérations de lecture et d'écriture de manière spéciale :
Pour éviter les conflits d'état, ce plan introduit un mécanisme de détection des conflits :
Enfin, fusionnez plusieurs modifications de pending-stateDB dans le stateDB global pour générer une nouvelle racine d'état.
Cette solution d'optimisation parallèle peut augmenter le TPS de 3 à 5 fois sous une charge de travail à faible conflit. Dans des situations de conflit élevé, elle peut théoriquement atteindre une amélioration de 60 fois.
Dans l'ensemble, la parallélisation de l'EVM est une direction importante pour améliorer les performances d'Ethereum et de ses Layer 2. Grâce à des technologies telles que l'exécution parallèle multithread et les bibliothèques d'état temporaire, il est possible d'augmenter considérablement la capacité de traitement des transactions tout en garantissant la cohérence. À l'avenir, il sera également possible d'améliorer davantage les performances de l'EVM en optimisant l'efficacité du stockage et en améliorant les stratégies de gestion des conflits.