Hey là,
La scalabilité des transactions a été au centre des discussions. Nous avons exploré comment Monad aide à augmenter le TPS au cours des dernières semaines.
La note ci-dessous est un aperçu de la façon dont Monad fonctionne écrit par @desh_saurabh. Considérez-vous inscrire àDecentralised.coSi vous aimez lire des explications basées sur les données sur tout ce qui concerne Web3. Rendez-vous de l'autre côté !
TPS est une mesure sur laquelle nous sommes obsédés. Nous voulons que nos chaînes soutiennent un TPS plus élevé car elles pourraient supporter plus d'utilisateurs et d'applications. Le graphique ci-dessous montre les chiffres du TPS pour Ethereum et L2s. Aucune chaîne n'a jamais dépassé la barre des 100 TPS. Notez que le TPS est un terme général pour mesurer l'échelle. Le TPS est inexact car toutes les transactions ne sont pas égales, car elles diffèrent en complexité. Mais nous utilisons le TPS comme mesure d'échelle pour simplifier.
Que faisons-nous si nous voulons augmenter le TPS ?
- Une approche consiste à construire un système entièrement nouveau, comme l'a fait Solana. Il sacrifie la compatibilité avec l'EVM au profit de la vitesse. Il utilise une exécution multi-thread au lieu d'une exécution mono-thread (pensez à un CPU multi-cœur par rapport à un CPU mono-cœ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 à mettre à l'échelle Ethereum avec des séquenceurs centralisés.
- Le troisième consiste à décomposer l'EVM en composants séparés et à les optimiser pour améliorer la scalabilité.
Monad, un nouveau L1 compatible avec l'EVM qui a récemment levé 225 millions de dollars, construit l'EVM à partir de zéro au lieu de l'utiliser tel quel. Il a choisi cette troisième approche pour augmenter la scalabilité.
Nous discutons de quelques changements significatifs que Monad apporte sur la table.
Exécution parallèle
La machine virtuelle Ethereum (EVM) exécute les transactions séquentiellement. Jusqu'à ce qu'une transaction soit exécutée, la transaction suivante doit attendre. Pensez-y de cette façon. Disons qu'il y a une plateforme dans un entrepôt d'assemblage de motos. Plusieurs camions déposent des pièces de moto (de telle manière que chaque camion a toutes les pièces nécessaires pour créer 50 motos). L'entrepôt d'assemblage effectue quatre fonctions différentes avec des équipes dédiées - déchargement, tri, assemblage et chargement.
Avec la configuration actuelle de l'EVM, il n'y a qu'une seule plateforme, et le même endroit est utilisé pour le chargement et le déchargement. Ainsi, lorsque le camion est stationné, les composants de moto sont déchargés, triés, assemblés et chargés sur le même camion. Pendant que l'équipe de tri travaille, chaque autre équipe attend simplement. Ainsi, si vous considérez leurs emplois comme des créneaux différents, chaque équipe ne travaille qu'une fois sur quatre créneaux. Cela entraîne des inefficacités significatives, soulignant la nécessité d'une approche plus rationalisée.
Maintenant, imaginez qu'il y ait quatre plates-formes avec des zones de chargement et de déchargement différentes. Même si l'équipe de déchargement ne peut travailler que sur un camion à la fois, elle n'a pas besoin d'attendre les trois emplacements suivants. Elle peut passer directement au camion suivant.
Il en va de même pour les équipes de tri, d'assemblage et de chargement. Une fois que le chargement du camion est terminé, le camion se déplace vers la zone de chargement et attend que l'équipe de chargement charge les motos assemblées. Ainsi, l'entrepôt avec une seule plate-forme et une zone de chargement/déchargement exécute tout séquentiellement, tandis que celui avec 4 plateformes et différentes zones de chargement/déchargement est en parallèle.
Considérez Monad comme une infrastructure équivalente à l'entrepôt avec plusieurs plateformes de camions, mais ce n'est pas si simple. La complexité augmente lorsque les camions sont dépendants. Par exemple, que se passe-t-il si un camion n'a pas toutes les pièces pour fabriquer 50 motos ? Les transactions ne sont pas toujours indépendantes. Ainsi, lorsque Monad les exécute en parallèle, il doit gérer des transactions dépendantes les unes des autres.
Comment? Il effectue quelque chose appelé exécution parallèle optimiste. Le protocole ne peut exécuter que des transactions indépendantes en parallèle. Par exemple, considérez 4 transactions avec le solde de Joel à 1 ETH -
- Joel envoie 0.2 ETH à Saurabh.
- Sid crée un NFT.
- Joel envoie 0.1 ETH à Sid.
- Shlok achète PEPE.
Toutes ces transactions sont exécutées en parallèle avec des résultats en attente qui sont validés un par un. Les transactions sont ré-exécutées si les résultats en attente entrent en conflit avec les entrées d'origine de toute transaction. Les transactions 2 et 4 n'ont pas de résultats en attente en conflit avec les entrées des autres transactions car elles sont indépendantes les unes des autres. Mais 1 et 3 ne sont pas indépendantes.
Notez que puisque les 4 transactions commencent à partir du même état, celle qui nous concerne ici est le solde de Joel de 1 ETH. Le fait que Joel envoie 0,2 ETH entraîne un solde de 0,8 ETH. Après que Joel envoie 0,1 ETH à Sid, son solde est de 0,9 ETH. Les résultats sont engagés un par un, en veillant à ce que les sorties ne soient pas en conflit avec l'un des intrants. Après que le résultat en attente de 1 soit engagé, le nouveau solde de Joel est de 0,8 ETH.
Cet output entre en conflit avec l'input de 3. Donc maintenant 3 est ré-exécuté avec un input de 0.8 ETH. Après l'exécution de 3, le solde de Joel est de 0.7 ETH.
MonadDb
À ce stade, une question évidente est de savoir comment savons-nous que nous n'aurons 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. Le goulot d'étranglement est l'accès à la mémoire d'Ethereum. Il s'avère que la façon dont Ethereum stocke son état dans la base de données rend difficile (long et donc coûteux) l'accès à l'état. C'est ici que l'autre amélioration de Monad entre en jeu - MonadDb. Monad a construit sa base de données de manière à réduire les surcharges associées aux opérations de lecture.
Lorsqu'une transaction doit être ré-exécutée, toutes les entrées sont déjà en mémoire cache, ce qui est nettement plus facile d'accès par rapport à l'état global.
Solana a 50k TPS sur son testnet mais fait environ 1k sur le mainnet maintenant. Monad affirme avoir atteint 10k TPS réels sur son testnet interne. Bien que cela ne soit pas toujours indicatif des performances réelles, nous sommes impatients de voir comment Monad fonctionne dans la nature.
Déclaration :
Cet article initialement intitulé "Comprendre Monad" est reproduit à partir de [chaincatcher]. Tous les droits d'auteur appartiennent à l'auteur original [Decentralised.Co]. Si vous avez des objections à la reproduction, veuillez contacter le Équipe Gate Learn, l'équipe s'en occupera dès que possible.
Avertissement : Les points de vue et opinions exprimés dans cet article ne représentent que les points de vue personnels de l'auteur et ne constituent aucun conseil en investissement.
Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdite.
