Guide d'initiation à Monad : Comprendre rapidement l'EVM parallèle et l'amélioration des performances
TechFlow SélectionTechFlow Sélection
Guide d'initiation à Monad : Comprendre rapidement l'EVM parallèle et l'amélioration des performances
Ce n'est pas la réexécution qui constitue un goulot d'étranglement, mais l'accès à la mémoire d'Ethereum.
Dédié à des analyses Web3 approfondiesRédaction : Decentralised.Co
Traduction : TechFlow
L'extensibilité des transactions a toujours été un sujet brûlant. Au cours des dernières semaines, nous avons exploré comment Monad pourrait aider à augmenter le TPS.
Voici une explication détaillée du fonctionnement de Monad rédigée par Saurabh Deshpande.
Le TPS est un indicateur que nous suivons de près. Nous souhaitons que notre chaîne puisse supporter un TPS plus élevé, car cela signifie qu'elle peut accueillir davantage d'utilisateurs et d'applications. Le graphique ci-dessous illustre les chiffres de TPS pour Ethereum et les L2. Aucune chaîne n'a jamais franchi la barre symbolique des 100 TPS. Notez que le TPS est un terme général utilisé pour mesurer l'échelle. Il n'est pas parfaitement précis, car toutes les transactions ne sont pas identiques et varient en complexité. Toutefois, par simplicité, nous utilisons le TPS comme indicateur de performance.
Que pouvons-nous faire si nous voulons augmenter le TPS ?
-
La première approche consiste à construire un système entièrement nouveau, comme Solana. Cela implique de sacrifier la compatibilité EVM au profit de la vitesse. Solana utilise une exécution multithread plutôt que monothème (pensez à un processeur multi-cœurs contre un processeur mono-cœur), permettant une exécution parallèle des transactions, ainsi qu'un mécanisme de consensus différent.
-
La deuxième méthode repose sur l'exécution hors chaîne, en utilisant un séquenceur centralisé pour étendre Ethereum.
-
La troisième méthode consiste à décomposer l'EVM en composants distincts, puis à les optimiser afin d'améliorer l'extensibilité.
Monad est une nouvelle blockchain de niveau 1 compatible EVM qui a récemment levé 225 millions de dollars. Plutôt que d'utiliser directement l'EVM existante, elle reconstruit celle-ci depuis zéro. Elle adopte donc cette troisième approche pour améliorer l'extensibilité.
Nous allons maintenant examiner plusieurs changements majeurs apportés par Monad.
Exécution parallèle
La Machine Virtuelle Ethereum (EVM) exécute les transactions de manière séquentielle. Avant de passer à la transaction suivante, il faut attendre la fin de l'exécution de la précédente. Imaginons une usine d'assemblage de motos avec un seul quai de chargement. Plusieurs camions livrent des pièces détachées (chaque camion contenant tout le nécessaire pour assembler 50 motos). L’usine effectue quatre tâches différentes : décharger, trier, assembler et recharger.
Dans la configuration actuelle de l’EVM, il n’existe qu’un seul quai, où les opérations de chargement et de déchargement se font au même endroit. Ainsi, lorsque le camion arrive, les pièces sont déchargées, triées, assemblées, puis les motos terminées sont rechargées sur ce même camion. Pendant que l’équipe de tri travaille, les autres équipes doivent attendre. Si l’on considère chaque tâche comme un créneau horaire, chaque équipe n’occupe qu’un seul des quatre créneaux. Cette situation entraîne une inefficacité notable, soulignant le besoin d’une méthode plus fluide.
Maintenant, imaginons quatre quais distincts dédiés respectivement au déchargement, au tri, à l’assemblage et au chargement. 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 autres étapes. Dès qu’elle termine, elle passe immédiatement au camion suivant.
Il en va de même pour les équipes de tri, d’assemblage et de chargement. Une fois le déchargement terminé, le camion se déplace vers le quai de chargement pour attendre que l’équipe place les motos assemblées. Ainsi, un entrepôt avec un seul quai et une zone commune de chargement/déchargement exécute toutes les opérations de manière séquentielle, tandis qu’un entrepôt doté de quatre quais distincts permet une exécution parallèle.
Considérez Monad comme une infrastructure comparable à un entrepôt disposant de plusieurs quais pour camions. Mais ce n’est pas aussi simple. La complexité augmente lorsque les camions sont interdépendants. Que se passe-t-il, par exemple, 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, lorsque Monad exécute des transactions en parallèle, il doit gérer celles qui dépendent les unes des autres.
Comment fait-il ? Il applique une méthode appelée « exécution parallèle optimiste ». Le protocole ne peut exécuter en parallèle que les transactions indépendantes. Prenons par exemple 4 transactions, sachant que Joel possède initialement 1 ETH :
-
Joel envoie 0,2 ETH à Saurabh
-
Sid crée un NFT
-
Joel envoie 0,1 ETH à Sid
-
Shlok achète du PEPE
Toutes ces transactions sont exécutées en parallèle, leurs résultats provisoires étant validés un par un. Si le résultat provisoire entre en conflit avec les données d’entrée d’une transaction, celle-ci est réexécutée. Les transactions 2 et 4 n’ont aucun conflit avec les autres, car elles sont totalement indépendantes. En revanche, les transactions 1 et 3 ne le sont pas.
Notez que toutes les 4 transactions partent du même état initial, à savoir que Joel dispose de 1 ETH. Après avoir envoyé 0,2 ETH, son solde devient 0,8 ETH. Ensuite, après avoir transféré 0,1 ETH à Sid, son solde atteint 0,9 ETH. Les résultats sont validés un par un, garantissant qu’aucun conflit n’apparaît entre sortie et entrée. Une fois le résultat provisoire de la transaction 1 validé, le nouveau solde de Joel est 0,8 ETH.
Ce résultat entre en conflit avec l’entrée de la transaction 3. La transaction 3 doit donc être réexécutée, avec un solde d’entrée de 0,8 ETH. Après exécution, le solde de Joel tombe à 0,7 ETH.
MonadDb
À ce stade, une question évidente se pose : comment savons-nous que nous n’avons pas à réexécuter la majorité des transactions ? La réponse réside dans le fait que la réexécution n’est pas le goulot d’étranglement. Ce dernier se situe plutôt au niveau de l’accès à la mémoire d’Ethereum. En réalité, la manière dont Ethereum stocke l’état dans sa base de données rend l’accès à cet état difficile (long et donc coûteux). C’est là qu’intervient une autre amélioration de Monad : MonadDb. La façon dont Monad conçoit sa base de données réduit considérablement les frais liés aux opérations de lecture.
Lorsqu'une transaction doit être réexécutée, toutes ses entrées sont déjà présentes dans une mémoire cache, beaucoup plus rapide d'accès que l'état global complet.
Solana affiche 50 000 TPS sur son réseau de test, mais n’atteint actuellement qu’environ 1 000 TPS sur le réseau principal. Monad affirme avoir atteint 10 000 TPS réels sur son propre testnet interne. Bien que cela ne reflète pas toujours fidèlement la performance réelle, nous sommes impatients de voir comment Monad se comportera dans des conditions d’utilisation concrètes.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@Decentralisedco
