Optimisation parallèle EVM : Améliorer les performances de traitement des transactions
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 la cohérence des résultats d'exécution des contrats sur différents nœuds, l'EVM utilise la technologie de machine virtuelle, réalisant ainsi une compatibilité multiplateforme.
Lorsqu'un contrat intelligent est déployé sur la chaîne, il est d'abord compilé en bytecode EVM. Lors de l'exécution du contrat par l'EVM, ce dernier lit ces bytecodes séquentiellement, chaque instruction ayant un coût en Gas correspondant. L'EVM suit la consommation de Gas au cours de l'exécution des instructions, le montant consommé dépendant de la complexité de l'opération.
Les EVM traditionnels traitent les transactions de manière séquentielle, toutes les transactions étant exécutées dans une seule file d'attente. Ce design est simple et facile à entretenir, mais avec l'augmentation du nombre d'utilisateurs et les exigences croissantes en matière de TPS et de débit, les goulets d'étranglement de performance de l'exécution séquentielle deviennent de plus en plus évidents, en particulier dans les Layer 2.
En plus de l'EVM, un autre composant central 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. À chaque exécution de transaction, l'EVM modifie les données dans stateDB, qui se reflètent finalement dans l'arbre d'état global.
En mode sériel, les transactions doivent être exécutées dans l'ordre. Si une transaction de contrat complexe prend beaucoup de temps, les autres transactions doivent attendre, ce qui empêche une utilisation optimale des ressources matérielles et limite considérablement l'efficacité.
Pour résoudre ce problème, l'industrie a proposé une solution d'optimisation parallèle multithread pour l'EVM. Cette solution permet d'ouvrir plusieurs threads pour traiter simultanément plusieurs transactions, ce qui peut multiplier l'efficacité par plusieurs fois. Cependant, l'exécution parallèle fait face à des défis de conflit d'état, nécessitant des mesures appropriées.
Certain projets ont l'idée d'optimisation parallèle pour EVM : allouer une base de données d'état temporaire pour chaque thread (pending-stateDB). Lors de l'exécution des transactions par le thread, les modifications d'état sont temporairement stockées dans pending-stateDB, sans modifier directement la stateDB globale. Une fois toutes les transactions exécutées, les modifications de pending-stateDB sont synchronisées avec la stateDB globale.
Cette solution a également optimisé les opérations de lecture et d'écriture : lors de la lecture, elle vérifie d'abord la pending-stateDB, et si elle n'y trouve rien, elle lit ensuite la global stateDB ; les opérations d'écriture sont enregistrées dans la pending-stateDB et, une fois l'exécution terminée, elles sont fusionnées avec la global stateDB.
Pour gérer les conflits d'état, le plan a introduit un mécanisme de détection des conflits. En surveillant les ensembles de lecture et d'écriture des différentes transactions, les transactions concernées sont marquées pour être réexécutées en cas de conflit.
L'optimisation parallèle multi-thread a considérablement amélioré les performances de l'EVM, en particulier lors du traitement de contrats intelligents complexes. Les recherches montrent qu'avec des charges de travail à faible conflit, le TPS peut être multiplié par 3 à 5 ; avec des charges à fort conflit, il peut théoriquement atteindre 60 fois.
Cette solution d'optimisation parallèle, grâce à une bibliothèque d'état temporaire et à la détection de conflits, permet une parallélisation à grande échelle des transactions tout en garantissant la cohérence des états, établissant ainsi une base importante pour le développement des Rollups Ethereum. À l'avenir, il sera possible d'améliorer encore les performances en optimisant l'efficacité du stockage, en traitant des scénarios à fort conflit et en utilisant l'accélération GPU.
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.
11 J'aime
Récompense
11
6
Partager
Commentaire
0/400
¯\_(ツ)_/¯
· Il y a 20h
Les utilisateurs n'ont enfin plus besoin d'attendre éternellement.
Voir l'originalRépondre0
ReverseTradingGuru
· Il y a 20h
Enfin, un peu de hardcore.
Voir l'originalRépondre0
TxFailed
· Il y a 20h
psa : j'ai appris à propos de l'evm parallèle de la manière coûteuse... rip mes 2,3 eth
Voir l'originalRépondre0
rugpull_survivor
· Il y a 20h
J'ai entendu dire que ça doit être 60 fois plus rapide ? Est-ce que ça peut réduire les frais de gas ?
Voir l'originalRépondre0
SilentAlpha
· Il y a 20h
60 fois, ça ne peut pas ne pas rapporter gros !
Voir l'originalRépondre0
LiquiditySurfer
· Il y a 20h
Le martini a enfin atteint le fond, plus besoin d'attendre le gas.
Optimisation parallèle EVM améliorant les performances de traitement des transactions Ethereum jusqu'à 60 fois.
Optimisation parallèle EVM : Améliorer les performances de traitement des transactions
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 la cohérence des résultats d'exécution des contrats sur différents nœuds, l'EVM utilise la technologie de machine virtuelle, réalisant ainsi une compatibilité multiplateforme.
Lorsqu'un contrat intelligent est déployé sur la chaîne, il est d'abord compilé en bytecode EVM. Lors de l'exécution du contrat par l'EVM, ce dernier lit ces bytecodes séquentiellement, chaque instruction ayant un coût en Gas correspondant. L'EVM suit la consommation de Gas au cours de l'exécution des instructions, le montant consommé dépendant de la complexité de l'opération.
Les EVM traditionnels traitent les transactions de manière séquentielle, toutes les transactions étant exécutées dans une seule file d'attente. Ce design est simple et facile à entretenir, mais avec l'augmentation du nombre d'utilisateurs et les exigences croissantes en matière de TPS et de débit, les goulets d'étranglement de performance de l'exécution séquentielle deviennent de plus en plus évidents, en particulier dans les Layer 2.
En plus de l'EVM, un autre composant central 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. À chaque exécution de transaction, l'EVM modifie les données dans stateDB, qui se reflètent finalement dans l'arbre d'état global.
En mode sériel, les transactions doivent être exécutées dans l'ordre. Si une transaction de contrat complexe prend beaucoup de temps, les autres transactions doivent attendre, ce qui empêche une utilisation optimale des ressources matérielles et limite considérablement l'efficacité.
Pour résoudre ce problème, l'industrie a proposé une solution d'optimisation parallèle multithread pour l'EVM. Cette solution permet d'ouvrir plusieurs threads pour traiter simultanément plusieurs transactions, ce qui peut multiplier l'efficacité par plusieurs fois. Cependant, l'exécution parallèle fait face à des défis de conflit d'état, nécessitant des mesures appropriées.
Certain projets ont l'idée d'optimisation parallèle pour EVM : allouer une base de données d'état temporaire pour chaque thread (pending-stateDB). Lors de l'exécution des transactions par le thread, les modifications d'état sont temporairement stockées dans pending-stateDB, sans modifier directement la stateDB globale. Une fois toutes les transactions exécutées, les modifications de pending-stateDB sont synchronisées avec la stateDB globale.
Cette solution a également optimisé les opérations de lecture et d'écriture : lors de la lecture, elle vérifie d'abord la pending-stateDB, et si elle n'y trouve rien, elle lit ensuite la global stateDB ; les opérations d'écriture sont enregistrées dans la pending-stateDB et, une fois l'exécution terminée, elles sont fusionnées avec la global stateDB.
Pour gérer les conflits d'état, le plan a introduit un mécanisme de détection des conflits. En surveillant les ensembles de lecture et d'écriture des différentes transactions, les transactions concernées sont marquées pour être réexécutées en cas de conflit.
L'optimisation parallèle multi-thread a considérablement amélioré les performances de l'EVM, en particulier lors du traitement de contrats intelligents complexes. Les recherches montrent qu'avec des charges de travail à faible conflit, le TPS peut être multiplié par 3 à 5 ; avec des charges à fort conflit, il peut théoriquement atteindre 60 fois.
Cette solution d'optimisation parallèle, grâce à une bibliothèque d'état temporaire et à la détection de conflits, permet une parallélisation à grande échelle des transactions tout en garantissant la cohérence des états, établissant ainsi une base importante pour le développement des Rollups Ethereum. À l'avenir, il sera possible d'améliorer encore les performances en optimisant l'efficacité du stockage, en traitant des scénarios à fort conflit et en utilisant l'accélération GPU.