Le chemin de l'optimisation parallèle de l'EVM

Comme tout le monde le sait, l'EVM est le moteur d'exécution central d'Ethereum et l'environnement d'exécution des contrats intelligents. En tant que réseau ouvert comprenant de nombreux nœuds, la blockchain publique est confrontée au défi d'assurer une exécution cohérente sur des appareils aux paramètres matériels très variés. La technologie des machines virtuelles offre une solution potentielle à ce problème, permettant aux contrats intelligents de s'exécuter de la même manière sur différents systèmes d'exploitation et appareils, assurant ainsi la cohérence des résultats.

Les contrats intelligents sont compilés en bytecode EVM avant d'être mis en chaîne. Lorsque l'EVM exécute le contrat, il lit ces bytecodes séquentiellement, chaque instruction ayant un coût en Gas correspondant. L'EVM suit la consommation de Gas pendant l'exécution de chaque instruction, et la quantité consommée dépend de la complexité de l'opération.

Traditionnellement, l'EVM traite les transactions de manière sérielle, toutes les transactions étant mises en file d'attente dans une seule file et exécutées dans un ordre déterminé. Ce design est simple à maintenir, mais avec l'évolution de la technologie blockchain et l'expansion de la base d'utilisateurs, les exigences en matière de TPS et de débit augmentent constamment. Avec la maturité de la technologie Rollup, le goulet d'étranglement de performance de l'exécution sérielle de l'EVM devient particulièrement évident dans le réseau de seconde couche d'Ethereum.

Le séquenceur, en tant que composant clé de Layer2, assume toutes les tâches de calcul sous la forme d'un serveur unique. Si l'efficacité des modules associés est suffisamment élevée, le goulot d'étranglement final dépendra de l'efficacité du séquenceur lui-même, à ce moment-là, l'exécution séquentielle deviendra un obstacle majeur. Par conséquent, la parallélisation du traitement des transactions devient une tendance inévitable pour l'avenir.

Composant clé de l'exécution des transactions Ethereum

En dehors 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 dans Ethereum. Ethereum utilise une structure d'arbre Merkle Patricia Trie comme index de base de données. Chaque exécution de transaction modifie certaines données dans stateDB, et ces changements se reflètent 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 contrat, stockant des données telles que les soldes de compte et le code des contrats intelligents. Pendant l'exécution des transactions, stateDB lit et écrit les données des comptes correspondants. À la fin de l'exécution de la transaction, stateDB soumet le nouvel état à la base de données sous-jacente pour 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, en tant que stockage d'état global, gère tous les changements d'état des comptes et des contrats. Les deux collaborent pour construire l'environnement d'exécution des transactions d'Ethereum.

Le processus spécifique d'exécution en série

Les transactions Ethereum se divisent en deux types : les transferts EOA et les transactions de contrat. Le transfert EOA est le type de transaction le plus simple, c'est-à-dire le transfert d'ETH entre comptes ordinaires, sans appel de contrat, avec une vitesse de traitement rapide et des frais de gaz bas.

Le trading de contrats implique l'appel et l'exécution de contrats intelligents. Lorsque l'EVM traite les transactions de contrats, elle doit interpréter et exécuter une par une les instructions en bytecode du contrat intelligent. Plus la logique du contrat est complexe, plus il y a d'instructions impliquées et plus les ressources consommées sont importantes.

Par exemple, le temps de traitement d'un transfert ERC-20 est environ deux fois plus long que celui d'un transfert EOA, tandis que des contrats intelligents plus complexes, comme les opérations de trading sur Uniswap, peuvent prendre des dizaines de fois plus de temps qu'un transfert EOA. Cela est dû au fait que les protocoles DeFi doivent gérer des logiques complexes telles que les pools de liquidité, le calcul des prix, les échanges de tokens, ce qui nécessite un grand nombre de calculs.

Dans le mode d'exécution séquentielle, le processus de collaboration entre l'EVM et la stateDB est le suivant :

1. Les transactions dans le 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.
2. Toutes les transactions partagent la même base de données d'état stateDB.
3. Pendant l'exécution de la transaction, l'EVM interagit continuellement avec le stateDB, lit les données pertinentes et écrit les données modifiées dans le stateDB.
4. Une fois que toutes les transactions dans le bloc ont été exécutées, les données dans stateDB sont soumises à l'arbre d'état global, générant une nouvelle racine d'état.

Le goulot d'étranglement de ce mode d'exécution séquentielle est évident : les transactions doivent être exécutées en file d'attente dans l'ordre, et lorsqu'il y a des transactions de contrats intelligents qui prennent beaucoup de temps, les autres transactions doivent attendre, ce qui ne permet pas d'utiliser pleinement les ressources matérielles, limitant ainsi l'efficacité.

Solution d'optimisation parallèle multithread EVM

Le mode d'exécution parallèle permet de lancer plusieurs threads pour traiter plusieurs transactions simultanément, ce qui peut améliorer l'efficacité de plusieurs fois, mais il fait face à des problèmes de conflit d'état. Lorsque plusieurs transactions déclarent simultanément vouloir réécrire les données d'un compte, un conflit se produit et une gestion coordonnée est nécessaire.

Principe d'optimisation parallèle

Prenons l'exemple de l'approche d'optimisation parallèle du projet ZKRollup Reddio, ses principales caractéristiques comprennent :

1. Exécution des transactions en parallèle avec plusieurs threads : configurez plusieurs threads pour traiter simultanément différentes transactions, sans interférence entre les threads, ce qui peut multiplier par plusieurs fois la vitesse de traitement des transactions.

2. Allouer une base de données d'état temporaire pour chaque thread : chaque thread dispose d'une base de données d'état temporaire indépendante (pending-stateDB). Lors de l'exécution des transactions, les résultats des changements d'état sont temporairement enregistrés dans le pending-stateDB, sans modifier directement l'état global stateDB.

3. Synchronisation des changements d'état : Après l'exécution de toutes les transactions dans le bloc, les résultats des changements d'état enregistrés dans chaque pending-stateDB sont synchronisés successivement dans le stateDB global.

Reddio a optimisé le traitement des opérations de lecture et d'écriture :

• Opération de lecture : d'abord vérifier le ReadSet de l'état en attente. S'il existe des données requises, les lire directement depuis la base de données d'état en attente ; sinon, lire les données d'état historiques depuis la base de données d'état global du bloc précédent.

• Opérations d'écriture : toutes les opérations d'écriture sont d'abord enregistrées dans le WriteSet de l'état en attente, puis, une fois que l'exécution de la transaction est terminée, une tentative de fusion des résultats des modifications d'état dans le stateDB global est faite après un contrôle des conflits.

Pour résoudre le problème de conflit d'état, Reddio a introduit un mécanisme de détection des conflits :

• Détection de conflit : surveiller le ReadSet et le WriteSet de 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 : Les transactions en conflit sont marquées comme nécessitant une réexécution.

Après l'exécution de toutes les transactions, plusieurs enregistrements de modifications dans l'état en attente de la base de données sont fusionnés dans la base de données d'état global. Après une 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 multithreading a considérablement amélioré les performances, en particulier lors du traitement de transactions complexes de contrats intelligents. Des études montrent que, dans des charges de travail à faible conflit, le TPS des tests de référence est 3 à 5 fois supérieur à l'exécution séquentielle traditionnelle. Dans des charges de travail à fort conflit, théoriquement, si toutes les mesures d'optimisation sont appliquées, on peut même atteindre une amélioration de 60 fois.

Résumé

La solution d'optimisation multi-threadée EVM de Reddio 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 les transactions 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, la blockchain publique EVM peut réaliser une parallélisation à grande échelle des transactions tout en garantissant la cohérence de l'état, résolvant ainsi le goulet d'étranglement de performance des modèles d'exécution sériels traditionnels. Cela établit une base importante pour le développement futur des Rollups Ethereum.

Nous pourrons discuter plus en détail des spécificités de mise en œuvre de Reddio, y compris comment optimiser l'efficacité du stockage, les solutions d'optimisation en cas de conflits élevés, ainsi que comment utiliser le GPU pour l'optimisation.