Guide de démarrage de Monad : Comprendre rapidement l'EVM parallèle et l'amélioration des performances

L'évolutivité des transactions a toujours été un sujet brûlant. Au cours des dernières semaines, nous avons exploré comment les monades peuvent contribuer à faire évoluer le TPS.

Voici une explication détaillée du fonctionnement des monades, écrite par Saurabh Deshpande.

Explication détaillée du fonctionnement de Monad

Le TPS est un indicateur auquel nous prêtons une attention particulière. Nous voulons que nos chaînes soient capables de prendre en charge des TPS plus élevés, car elles peuvent prendre en charge davantage d'utilisateurs et d'applications. Le graphique ci-dessous montre les numéros TPS pour Ethereum et L2. Aucune chaîne n’a jamais franchi la barre des 100 TPS. Notez que TPS est un terme général utilisé pour mesurer l'échelle. TPS est inexact car toutes les transactions ne sont pas identiques et leur complexité varie. Mais par souci de simplicité, nous utilisons le TPS comme mesure d’échelle.

Si nous voulons augmenter le TPS, que devons-nous faire ?

• La première façon est de construire un système complètement nouveau, comme ce qu'a fait Solana. Cela sacrifie la compatibilité EVM par rapport à la vitesse. Il utilise une exécution multithread au lieu d'une exécution monothread (pensez CPU multicœur vs CPU monocœur), parallélise les transactions et utilise un mécanisme de consensus différent.

• La deuxième approche consiste à utiliser l'exécution hors chaîne et à faire évoluer Ethereum avec un séquenceur centralisé.

• La troisième approche consiste à décomposer l'EVM en composants distincts et à les optimiser pour améliorer l'évolutivité.

Monad est un nouveau L1 compatible EVM qui a récemment levé 225 millions de dollars et qui construit EVM à partir de zéro, plutôt que de l'utiliser directement. Elle a choisi cette troisième approche pour accroître l’évolutivité.

Nous avons discuté de plusieurs changements majeurs apportés par Monads.

Exécution parallèle

La machine virtuelle Ethereum (EVM) exécute les transactions de manière séquentielle. Avant qu'une transaction ne soit exécutée, la transaction suivante doit attendre. Pense-y de cette façon. Considérons une plate-forme dans un atelier d'assemblage de motos. Plusieurs camions livrent des pièces de motos (chaque camion possède toutes les pièces nécessaires pour assembler 50 motos). L'atelier de montage remplit quatre fonctions différentes : déchargement, tri, assemblage et chargement.

Dans la configuration EVM actuelle, il n'y a qu'une seule plate-forme et le même emplacement est utilisé pour le chargement et le déchargement. Ainsi, pendant que le camion est garé, les pièces de moto sont déchargées, triées, assemblées et chargées sur le même camion. Pendant que l'équipe de classification travaille, d'autres équipes attendent. Par conséquent, si vous considérez leur travail comme des créneaux séparés, chaque équipe ne travaille qu’une fois sur quatre créneaux. Cela entraîne d’importantes inefficacités, soulignant la nécessité d’une approche plus rationalisée.

Maintenant, imaginez une plateforme avec quatre zones de chargement et de déchargement différentes. Même si l'équipe de déchargement ne peut travailler qu'avec un seul camion à la fois, elle n'a pas besoin d'attendre les trois créneaux suivants. Ils peuvent être transférés directement vers le prochain camion.

Il en va de même pour les équipes de tri, de montage et de chargement. Une fois le déchargement terminé, le camion se dirige vers le quai de chargement pour attendre que l'équipe de chargement charge les motos assemblées. Ainsi, un entrepôt avec une seule plate-forme et des zones de chargement/déchargement effectue toutes les opérations de manière séquentielle, tandis qu'un entrepôt avec 4 plates-formes et différentes zones de chargement/déchargement effectue la parallélisation.

Considérez Monads comme une infrastructure, équivalente à un entrepôt avec plusieurs plates-formes de camions. Mais ce n'est pas simple. La complexité augmente lorsque l’on compte sur les camions. Par exemple, que se passe-t-il si un camion ne dispose pas de toutes les pièces nécessaires pour assembler 50 motos ? Les transactions ne sont pas toujours indépendantes. Par conséquent, la Monade doit gérer des transactions qui dépendent les unes des autres lorsqu'elle les exécute en parallèle.

Comment y faire face ? Il implémente une méthode appelée exécution parallèle optimiste. Le protocole ne peut exécuter que des transactions indépendantes en parallèle. Par exemple, considérons 4 transactions où le solde de Joel est de 1 ETH :

• Joel envoie 0,2 éther à Saurabh

• Sid crée un NFT

• Joel envoie 0,1 éther à Sid

• Shl ok Achetez PEPE

Toutes ces transactions sont exécutées en parallèle et les résultats en attente sont soumis un par un. Si la sortie du résultat en attente entre en conflit avec l'entrée d'origine d'une transaction, la transaction est réexécutée. Les transactions 2 et 4 n'ont pas de résultats en attente qui entrent en conflit avec les entrées d'autres transactions car elles sont indépendantes l'une de l'autre. Mais les transactions 1 et 4 ne sont pas indépendantes.

Veuillez noter que puisque les 4 transactions partent du même état, l’accent est mis sur le solde de 1 ETH de Joel. Après que Joel ait envoyé 0,2 ETH, le solde était de 0,8 ETH. Après que Joel ait envoyé 0,1 ETH à Sid, son solde est de 0,9 ETH. Les résultats sont soumis un par un, garantissant que le résultat n'entre en conflit avec aucune entrée. Après avoir soumis le résultat en attente de 1, le nouveau solde de Joel est de 0,8 ETH.

Cette sortie est en conflit avec l'entrée de la 3ème transaction. Alors maintenant, 3 est réexécuté avec une entrée de 0,8 ETH. Après avoir exécuté 3, le solde de Joel est de 0,7 ETH.

MonadDb

À ce stade, la question évidente est de savoir comment savoir que nous n'avons pas à réexécuter la plupart des transactions. La réponse est que la réexécution n’est pas le goulot d’étranglement. Le goulot d’étranglement est l’accès à la mémoire d’Ethereum. Il s’avère que la façon dont Ethereum stocke l’état dans une base de données rend l’accès à l’état difficile (cela prend du temps et donc coûte cher). Il s'agit d'une autre amélioration de Monad : MonadDb. La façon dont Monads structure les bases de données réduit la surcharge associée aux opérations de lecture.

Lorsque la transaction doit être réexécutée, toutes les entrées sont déjà dans la mémoire cache, ce qui est plus facile d'accès par rapport à l'état global.

Solana avait 50 000 TPS sur son réseau de test, mais n'a désormais qu'environ 1 000 TPS sur le réseau principal. Monad prétend avoir atteint 10 000 TPS dans le monde réel sur son réseau de test interne. Bien que cela ne représente pas toujours les performances réelles, nous avons hâte de voir comment Monad se comportera dans des applications réelles.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!