Optimisation de la parallélisation EVM : un exemple avec Reddio pour explorer les voies d'amélioration des performances
Comme tout le monde le sait, l'EVM est l'un des composants les plus essentiels d'Ethereum, jouant un rôle important en tant que "moteur d'exécution" et "environnement d'exécution des contrats intelligents". Dans un réseau ouvert comme la blockchain, composé de milliers de nœuds, la configuration matérielle de différents nœuds peut varier considérablement. Pour garantir que les contrats intelligents obtiennent des résultats d'exécution cohérents sur tous les nœuds, la technologie de machine virtuelle est devenue la solution idéale.
L'EVM peut exécuter des contrats intelligents de la même manière sur différents systèmes d'exploitation et appareils, cette compatibilité multiplateforme garantit que chaque nœud obtient des résultats cohérents après l'exécution d'un contrat. Cela est similaire au principe de la machine virtuelle Java (JVM).
Les contrats intelligents que nous voyons dans l'explorateur de blocs sont d'abord compilés en bytecode EVM, puis stockés sur la chaîne. Lorsque l'EVM exécute un contrat, il lit ces bytecodes dans l'ordre, chaque instruction ayant un coût en Gas correspondant. L'EVM suit la consommation de Gas pendant l'exécution de chaque instruction, la quantité consommée dépendant de la complexité de l'opération.
En tant que moteur d'exécution central d'Ethereum, l'EVM traite les transactions de manière séquentielle, toutes les transactions faisant la queue dans une seule file et étant exécutées dans un ordre déterminé. La raison pour laquelle une approche parallélisée n'est pas adoptée est que la blockchain doit garantir strictement la cohérence, le même lot de transactions devant être traité dans le même ordre sur tous les nœuds. Si le traitement des transactions était parallélisé, il serait difficile de prévoir avec précision l'ordre des transactions, à moins d'introduire des algorithmes de planification complexes.
Entre 2014 et 2015, l'équipe fondatrice d'Ethereum, par manque de temps, a choisi de concevoir un mode d'exécution séquentielle simple et facile à maintenir. Cependant, avec l'itération de la technologie blockchain et l'élargissement de la base d'utilisateurs, les exigences en matière de TPS et de débit sont devenues de plus en plus élevées. Après l'apparition et la maturation de la technologie Rollup, les goulots d'étranglement de performance causés par l'exécution séquentielle de l'EVM se sont déjà manifestés de manière évidente sur le réseau de deuxième couche d'Ethereum.
Le Sequencer, en tant que composant clé de Layer2, prend en charge toutes les tâches de calcul sous la forme d'un seul serveur. Si l'efficacité des modules externes en coopération avec le Sequencer est suffisamment élevée, le goulot d'étranglement final dépendra de l'efficacité du Sequencer lui-même, à ce moment-là, l'exécution sérielle deviendra un obstacle majeur.
Une équipe a optimisé de manière extrême les couches DA et le module de lecture/écriture des données, permettant au Séquenceur d'exécuter jusqu'à plus de 2000 transactions ERC-20 par seconde. Ce chiffre peut sembler élevé, mais si les transactions à traiter sont beaucoup plus complexes que les transferts ERC-20, la valeur TPS diminuera inévitablement de manière significative. Par conséquent, la parallélisation du traitement des transactions sera une tendance inévitable pour l'avenir.
Les deux composants clés de l'exécution des transactions Ethereum
En plus de l'EVM, un autre composant central lié à l'exécution des transactions dans go-ethereum est le stateDB, qui gère l'état des comptes et le stockage des données dans Ethereum. Ethereum utilise une structure arborescente appelée Merkle Patricia Trie comme index de base de données. À chaque exécution de transaction, l'EVM modifie certaines données stockées dans le stateDB, ces modifications se refléteront finalement dans l'arbre d'état global.
stateDB est responsable de la maintenance de l'état de tous les comptes Ethereum, y compris les comptes EOA et les comptes de contrats, les données stockées incluent les soldes des comptes, le code des contrats intelligents, etc. Pendant le processus d'exécution des transactions, stateDB effectue des lectures et des écritures sur les données des comptes correspondants. Une fois l'exécution de la transaction terminée, stateDB doit soumettre le nouvel état à la base de données sous-jacente pour un traitement de 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.
Processus spécifique d'exécution séquentielle
Les types de transactions sur Ethereum se divisent en transferts EOA et transactions de contrat. Les transferts EOA sont le type de transaction le plus simple, c'est-à-dire les transferts d'ETH entre comptes ordinaires, sans appel de contrat, avec une rapidité de traitement élevée et des frais de gas très bas.
Le trading de contrats implique l'appel et l'exécution de contrats intelligents. Lorsque l'EVM traite des transactions de contrats, il doit interpréter et exécuter ligne par ligne les instructions en bytecode du contrat. Plus la logique du contrat est complexe, plus il y a d'instructions impliquées, plus les ressources consommées sont importantes.
Par exemple, le temps de traitement des transferts ERC-20 est environ deux fois plus long que celui des transferts EOA, tandis que des contrats intelligents plus complexes, comme les opérations de trading sur un DEX, peuvent prendre jusqu'à une dizaine de fois plus de temps que les transferts EOA. Cela est dû au fait que les protocoles DeFi doivent gérer des logiques complexes lors des transactions, telles que les pools de liquidité, le calcul des prix, l'échange de tokens, ce qui nécessite un grand nombre de calculs.
Dans le mode d'exécution sérielle, le processus par lequel l'EVM et le stateDB collaborent pour traiter les transactions est le suivant :
Dans la conception d'Ethereum, les transactions d'un bloc sont traitées une par une dans l'ordre, chaque transaction ayant une instance indépendante pour exécuter des opérations spécifiques. Bien que chaque transaction utilise une instance EVM différente, toutes les transactions partagent la même base de données d'état stateDB.
Au cours de l'exécution de la transaction, l'EVM doit interagir en permanence avec le stateDB, lire les données pertinentes à partir du stateDB et écrire les données modifiées dans le stateDB.
Lorsque toutes les transactions d'un bloc sont exécutées, les données de stateDB sont soumises à l'arbre d'état global et une nouvelle racine d'état est générée. La racine d'état est un paramètre important de chaque bloc, enregistrant le "résultat compressé" du nouvel état global après l'exécution du bloc.
Le goulot d'étranglement du mode d'exécution séquentielle de l'EVM est évident : les transactions doivent être exécutées dans l'ordre, et si une transaction de contrat intelligent prend beaucoup de temps, les autres transactions doivent attendre jusqu'à ce qu'elle soit terminée. Cela ne permet clairement pas d'utiliser pleinement les ressources matérielles comme le CPU, et l'efficacité est fortement limitée.
Solution d'optimisation parallèle multithread pour EVM
L'exécution séquentielle et l'exécution parallèle peuvent être comparées à une banque avec un seul guichet et à une banque avec plusieurs guichets. En mode parallèle, plusieurs threads peuvent être ouverts pour traiter simultanément plusieurs transactions, ce qui peut augmenter l'efficacité de plusieurs fois, mais le problème délicat est celui des conflits d'état.
Si plusieurs transactions déclarent vouloir modifier les données d'un certain compte, des conflits se produiront lorsqu'elles sont traitées simultanément. Par exemple, si un NFT ne peut être minté qu'une seule fois, et que la transaction 1 et la transaction 2 déclarent vouloir minté ce NFT, si les deux demandes sont satisfaites, cela entraînera manifestement une erreur. Les conflits d'état dans les opérations réelles sont souvent plus fréquents, donc le traitement parallèle des transactions doit comporter des mesures pour gérer les conflits d'état.
Principe d'optimisation parallèle de Reddio pour EVM
Un projet ZKRollup a pour idée d'optimisation parallèle de l'EVM d'allouer une transaction à chaque thread et de fournir une base de données d'état temporaire dans chaque thread, appelée pending-stateDB. Les détails spécifiques sont les suivants :
Exécution de transactions en parallèle avec plusieurs threads : configurez plusieurs threads pour traiter simultanément différentes transactions, sans interférence entre les threads. Cela peut multiplier par plusieurs fois la vitesse de traitement des transactions.
Allouer une base de données d'état temporaire pour chaque thread : Allouer une base de données d'état temporaire indépendante (pending-stateDB) pour chaque thread. Lorsque les différents threads effectuent des transactions, ils ne modifient pas directement la stateDB globale, mais enregistrent temporairement les résultats des changements d'état dans la pending-stateDB.
Synchronisation des changements d'état : après que toutes les transactions d'un bloc ont été exécutées, l'EVM synchronisera successivement les résultats des changements d'état enregistrés dans chaque pending-stateDB dans le stateDB global. Si aucune collision d'état ne se produit entre différentes transactions pendant leur exécution, les enregistrements de pending-stateDB peuvent être fusionnés avec succès dans le stateDB global.
Ce projet a optimisé la manière dont les opérations de lecture et d'écriture sont traitées, afin de garantir que les transactions puissent accéder correctement aux données d'état et éviter les conflits :
Opération de lecture : Lorsque la transaction nécessite de lire l'état, l'EVM vérifie d'abord le ReadSet de l'état en attente. Si le ReadSet contient les données requises, il les lit directement à partir de la base de données d'état en attente. Si le couple clé-valeur correspondant n'est pas trouvé dans le ReadSet, il lit les données d'état historiques à partir de la base de données d'état globale du bloc précédent.
Opérations d'écriture : toutes les opérations d'écriture (, c'est-à-dire les modifications d'état ), ne seront pas directement écrites dans le stateDB global, mais seront d'abord enregistrées dans le WriteSet de l'état en attente. Une fois l'exécution de la transaction terminée, une détection de conflit sera effectuée avant d'essayer de fusionner les résultats des modifications d'état dans le stateDB global.
La clé des problèmes d'exécution parallèle réside dans les conflits d'état. Ce problème se manifeste particulièrement lorsque plusieurs transactions tentent de lire et d'écrire l'état du même compte. Pour cela, un mécanisme de détection des conflits a été introduit :
Détection des conflits : Au cours de l'exécution des transactions, l'EVM surveille les ReadSet et WriteSet des différentes transactions. Si plusieurs transactions tentent de lire et d'écrire le même élément d'état, cela est considéré comme un conflit.
Gestion des conflits : Lorsque des conflits sont détectés, les transactions en conflit seront marquées comme nécessitant une réexécution.
Après l'exécution de toutes les transactions, les enregistrements de modifications dans plusieurs pending-stateDB seront fusionnés dans la stateDB globale. Si la fusion est réussie, l'EVM soumettra l'état final à l'arbre d'état global et générera une nouvelle racine d'état.
L'optimisation du parallélisme multithread offre une amélioration significative des performances, en particulier lors du traitement de transactions complexes de contrats intelligents. Des études montrent que, dans un pool de transactions à faible conflit (, les transactions présentant peu de contradictions ou utilisant les mêmes ressources ), le TPS des tests de référence a augmenté d'environ 3 à 5 fois par rapport à l'exécution séquentielle traditionnelle. Dans des charges de travail à fort conflit, théoriquement, si toutes les méthodes d'optimisation étaient appliquées, on pourrait même atteindre une amélioration de 60 fois.
Résumé
La solution d'optimisation du parallélisme multi-thread EVM du projet, en attribuant une bibliothèque d'état temporaire à chaque transaction et en exécutant les transactions en parallèle dans différents threads, a considérablement amélioré la capacité de traitement des transactions de l'EVM. En optimisant les opérations de lecture et d'écriture et en introduisant un mécanisme de détection de conflits, la chaîne publique EVM peut réaliser une parallélisation à grande échelle des transactions tout en garantissant la cohérence des états, résolvant ainsi les goulets d'étranglement de performance résultant du mode d'exécution séquentielle traditionnel. Cela jette une base importante pour le développement futur de Rollup 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.
20 J'aime
Récompense
20
5
Reposter
Partager
Commentaire
0/400
SocialFiQueen
· 08-05 12:02
C'est à égalité avec Hongmeng.
Voir l'originalRépondre0
SerumSquirter
· 08-05 00:36
Connectez-vous à reddio, dépêchez-vous de travailler.
Voir l'originalRépondre0
SocialAnxietyStaker
· 08-03 20:27
Multi-threading incroyable !
Voir l'originalRépondre0
GamefiEscapeArtist
· 08-03 20:25
Après tant de temps, la v1 n'est toujours pas très optimisée.
Voir l'originalRépondre0
AllInDaddy
· 08-03 20:00
reddio qui comprend ? C'est comme Knife Brother, juste pour se sortir.
Optimisation parallèle multithreading EVM : Débloquer les goulets d'étranglement des performances de Rollup
Optimisation de la parallélisation EVM : un exemple avec Reddio pour explorer les voies d'amélioration des performances
Comme tout le monde le sait, l'EVM est l'un des composants les plus essentiels d'Ethereum, jouant un rôle important en tant que "moteur d'exécution" et "environnement d'exécution des contrats intelligents". Dans un réseau ouvert comme la blockchain, composé de milliers de nœuds, la configuration matérielle de différents nœuds peut varier considérablement. Pour garantir que les contrats intelligents obtiennent des résultats d'exécution cohérents sur tous les nœuds, la technologie de machine virtuelle est devenue la solution idéale.
L'EVM peut exécuter des contrats intelligents de la même manière sur différents systèmes d'exploitation et appareils, cette compatibilité multiplateforme garantit que chaque nœud obtient des résultats cohérents après l'exécution d'un contrat. Cela est similaire au principe de la machine virtuelle Java (JVM).
Les contrats intelligents que nous voyons dans l'explorateur de blocs sont d'abord compilés en bytecode EVM, puis stockés sur la chaîne. Lorsque l'EVM exécute un contrat, il lit ces bytecodes dans l'ordre, chaque instruction ayant un coût en Gas correspondant. L'EVM suit la consommation de Gas pendant l'exécution de chaque instruction, la quantité consommée dépendant de la complexité de l'opération.
En tant que moteur d'exécution central d'Ethereum, l'EVM traite les transactions de manière séquentielle, toutes les transactions faisant la queue dans une seule file et étant exécutées dans un ordre déterminé. La raison pour laquelle une approche parallélisée n'est pas adoptée est que la blockchain doit garantir strictement la cohérence, le même lot de transactions devant être traité dans le même ordre sur tous les nœuds. Si le traitement des transactions était parallélisé, il serait difficile de prévoir avec précision l'ordre des transactions, à moins d'introduire des algorithmes de planification complexes.
Entre 2014 et 2015, l'équipe fondatrice d'Ethereum, par manque de temps, a choisi de concevoir un mode d'exécution séquentielle simple et facile à maintenir. Cependant, avec l'itération de la technologie blockchain et l'élargissement de la base d'utilisateurs, les exigences en matière de TPS et de débit sont devenues de plus en plus élevées. Après l'apparition et la maturation de la technologie Rollup, les goulots d'étranglement de performance causés par l'exécution séquentielle de l'EVM se sont déjà manifestés de manière évidente sur le réseau de deuxième couche d'Ethereum.
Le Sequencer, en tant que composant clé de Layer2, prend en charge toutes les tâches de calcul sous la forme d'un seul serveur. Si l'efficacité des modules externes en coopération avec le Sequencer est suffisamment élevée, le goulot d'étranglement final dépendra de l'efficacité du Sequencer lui-même, à ce moment-là, l'exécution sérielle deviendra un obstacle majeur.
Une équipe a optimisé de manière extrême les couches DA et le module de lecture/écriture des données, permettant au Séquenceur d'exécuter jusqu'à plus de 2000 transactions ERC-20 par seconde. Ce chiffre peut sembler élevé, mais si les transactions à traiter sont beaucoup plus complexes que les transferts ERC-20, la valeur TPS diminuera inévitablement de manière significative. Par conséquent, la parallélisation du traitement des transactions sera une tendance inévitable pour l'avenir.
Les deux composants clés de l'exécution des transactions Ethereum
En plus de l'EVM, un autre composant central lié à l'exécution des transactions dans go-ethereum est le stateDB, qui gère l'état des comptes et le stockage des données dans Ethereum. Ethereum utilise une structure arborescente appelée Merkle Patricia Trie comme index de base de données. À chaque exécution de transaction, l'EVM modifie certaines données stockées dans le stateDB, ces modifications se refléteront finalement dans l'arbre d'état global.
stateDB est responsable de la maintenance de l'état de tous les comptes Ethereum, y compris les comptes EOA et les comptes de contrats, les données stockées incluent les soldes des comptes, le code des contrats intelligents, etc. Pendant le processus d'exécution des transactions, stateDB effectue des lectures et des écritures sur les données des comptes correspondants. Une fois l'exécution de la transaction terminée, stateDB doit soumettre le nouvel état à la base de données sous-jacente pour un traitement de 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.
Processus spécifique d'exécution séquentielle
Les types de transactions sur Ethereum se divisent en transferts EOA et transactions de contrat. Les transferts EOA sont le type de transaction le plus simple, c'est-à-dire les transferts d'ETH entre comptes ordinaires, sans appel de contrat, avec une rapidité de traitement élevée et des frais de gas très bas.
Le trading de contrats implique l'appel et l'exécution de contrats intelligents. Lorsque l'EVM traite des transactions de contrats, il doit interpréter et exécuter ligne par ligne les instructions en bytecode du contrat. Plus la logique du contrat est complexe, plus il y a d'instructions impliquées, plus les ressources consommées sont importantes.
Par exemple, le temps de traitement des transferts ERC-20 est environ deux fois plus long que celui des transferts EOA, tandis que des contrats intelligents plus complexes, comme les opérations de trading sur un DEX, peuvent prendre jusqu'à une dizaine de fois plus de temps que les transferts EOA. Cela est dû au fait que les protocoles DeFi doivent gérer des logiques complexes lors des transactions, telles que les pools de liquidité, le calcul des prix, l'échange de tokens, ce qui nécessite un grand nombre de calculs.
Dans le mode d'exécution sérielle, le processus par lequel l'EVM et le stateDB collaborent pour traiter les transactions est le suivant :
Dans la conception d'Ethereum, les transactions d'un bloc sont traitées une par une dans l'ordre, chaque transaction ayant une instance indépendante pour exécuter des opérations spécifiques. Bien que chaque transaction utilise une instance EVM différente, toutes les transactions partagent la même base de données d'état stateDB.
Au cours de l'exécution de la transaction, l'EVM doit interagir en permanence avec le stateDB, lire les données pertinentes à partir du stateDB et écrire les données modifiées dans le stateDB.
Lorsque toutes les transactions d'un bloc sont exécutées, les données de stateDB sont soumises à l'arbre d'état global et une nouvelle racine d'état est générée. La racine d'état est un paramètre important de chaque bloc, enregistrant le "résultat compressé" du nouvel état global après l'exécution du bloc.
Le goulot d'étranglement du mode d'exécution séquentielle de l'EVM est évident : les transactions doivent être exécutées dans l'ordre, et si une transaction de contrat intelligent prend beaucoup de temps, les autres transactions doivent attendre jusqu'à ce qu'elle soit terminée. Cela ne permet clairement pas d'utiliser pleinement les ressources matérielles comme le CPU, et l'efficacité est fortement limitée.
Solution d'optimisation parallèle multithread pour EVM
L'exécution séquentielle et l'exécution parallèle peuvent être comparées à une banque avec un seul guichet et à une banque avec plusieurs guichets. En mode parallèle, plusieurs threads peuvent être ouverts pour traiter simultanément plusieurs transactions, ce qui peut augmenter l'efficacité de plusieurs fois, mais le problème délicat est celui des conflits d'état.
Si plusieurs transactions déclarent vouloir modifier les données d'un certain compte, des conflits se produiront lorsqu'elles sont traitées simultanément. Par exemple, si un NFT ne peut être minté qu'une seule fois, et que la transaction 1 et la transaction 2 déclarent vouloir minté ce NFT, si les deux demandes sont satisfaites, cela entraînera manifestement une erreur. Les conflits d'état dans les opérations réelles sont souvent plus fréquents, donc le traitement parallèle des transactions doit comporter des mesures pour gérer les conflits d'état.
Principe d'optimisation parallèle de Reddio pour EVM
Un projet ZKRollup a pour idée d'optimisation parallèle de l'EVM d'allouer une transaction à chaque thread et de fournir une base de données d'état temporaire dans chaque thread, appelée pending-stateDB. Les détails spécifiques sont les suivants :
Exécution de transactions en parallèle avec plusieurs threads : configurez plusieurs threads pour traiter simultanément différentes transactions, sans interférence entre les threads. Cela peut multiplier par plusieurs fois la vitesse de traitement des transactions.
Allouer une base de données d'état temporaire pour chaque thread : Allouer une base de données d'état temporaire indépendante (pending-stateDB) pour chaque thread. Lorsque les différents threads effectuent des transactions, ils ne modifient pas directement la stateDB globale, mais enregistrent temporairement les résultats des changements d'état dans la pending-stateDB.
Synchronisation des changements d'état : après que toutes les transactions d'un bloc ont été exécutées, l'EVM synchronisera successivement les résultats des changements d'état enregistrés dans chaque pending-stateDB dans le stateDB global. Si aucune collision d'état ne se produit entre différentes transactions pendant leur exécution, les enregistrements de pending-stateDB peuvent être fusionnés avec succès dans le stateDB global.
Ce projet a optimisé la manière dont les opérations de lecture et d'écriture sont traitées, afin de garantir que les transactions puissent accéder correctement aux données d'état et éviter les conflits :
Opération de lecture : Lorsque la transaction nécessite de lire l'état, l'EVM vérifie d'abord le ReadSet de l'état en attente. Si le ReadSet contient les données requises, il les lit directement à partir de la base de données d'état en attente. Si le couple clé-valeur correspondant n'est pas trouvé dans le ReadSet, il lit les données d'état historiques à partir de la base de données d'état globale du bloc précédent.
Opérations d'écriture : toutes les opérations d'écriture (, c'est-à-dire les modifications d'état ), ne seront pas directement écrites dans le stateDB global, mais seront d'abord enregistrées dans le WriteSet de l'état en attente. Une fois l'exécution de la transaction terminée, une détection de conflit sera effectuée avant d'essayer de fusionner les résultats des modifications d'état dans le stateDB global.
La clé des problèmes d'exécution parallèle réside dans les conflits d'état. Ce problème se manifeste particulièrement lorsque plusieurs transactions tentent de lire et d'écrire l'état du même compte. Pour cela, un mécanisme de détection des conflits a été introduit :
Détection des conflits : Au cours de l'exécution des transactions, l'EVM surveille les ReadSet et WriteSet des différentes transactions. Si plusieurs transactions tentent de lire et d'écrire le même élément d'état, cela est considéré comme un conflit.
Gestion des conflits : Lorsque des conflits sont détectés, les transactions en conflit seront marquées comme nécessitant une réexécution.
Après l'exécution de toutes les transactions, les enregistrements de modifications dans plusieurs pending-stateDB seront fusionnés dans la stateDB globale. Si la fusion est réussie, l'EVM soumettra l'état final à l'arbre d'état global et générera une nouvelle racine d'état.
L'optimisation du parallélisme multithread offre une amélioration significative des performances, en particulier lors du traitement de transactions complexes de contrats intelligents. Des études montrent que, dans un pool de transactions à faible conflit (, les transactions présentant peu de contradictions ou utilisant les mêmes ressources ), le TPS des tests de référence a augmenté d'environ 3 à 5 fois par rapport à l'exécution séquentielle traditionnelle. Dans des charges de travail à fort conflit, théoriquement, si toutes les méthodes d'optimisation étaient appliquées, on pourrait même atteindre une amélioration de 60 fois.
Résumé
La solution d'optimisation du parallélisme multi-thread EVM du projet, en attribuant une bibliothèque d'état temporaire à chaque transaction et en exécutant les transactions en parallèle dans différents threads, a considérablement amélioré la capacité de traitement des transactions de l'EVM. En optimisant les opérations de lecture et d'écriture et en introduisant un mécanisme de détection de conflits, la chaîne publique EVM peut réaliser une parallélisation à grande échelle des transactions tout en garantissant la cohérence des états, résolvant ainsi les goulets d'étranglement de performance résultant du mode d'exécution séquentielle traditionnel. Cela jette une base importante pour le développement futur de Rollup d'Ethereum.