Auteur : connaisseur, crypto KOL Traduction : Golden Finance xiaozou ;

1. Introduction à MégaETH

Le contenu principal de cet article sera quelques-unes de mes réflexions personnelles sur le livre blanc MegaETH, et je pourrai développer davantage à partir d'ici si je le peux. Quel que soit le contenu de cet article, j’espère que vous en avez appris quelque chose de nouveau.

Le site Web de MegaETH est cool car il contient un lapin mécanique avec une palette de couleurs très accrocheuse. Avant cela, il n'y avait qu'un seul Github : avoir un site Web rend tout beaucoup plus facile.

J'ai jeté un œil au MegaETH Github et j'ai appris qu'ils développaient une sorte de couche d'exécution, mais je dois être honnête, j'avais peut-être tort à ce sujet. La vérité est que je n'en savais pas assez sur MegaETH et maintenant c'est un sujet brûlant sur EthCC.

J'avais besoin de tout savoir et de m'assurer que je voyais la même technologie que les gars cool.

Le livre blanc MegaETH indique qu'il s'agit d'une blockchain en temps réel compatible EVM, conçue pour apporter des performances de type Web2 au monde de la cryptographie. Leur objectif est d'améliorer l'expérience d'utilisation d'Ethereum L2 en fournissant des attributs tels que plus de 100 000 transactions par seconde, des temps de blocage inférieurs à une milliseconde et des frais de transaction d'un centime.

Leur livre blanc met en évidence le nombre croissant de L2 (discuté dans l'un de mes articles précédents, bien que ce nombre ait grimpé à plus de 50, avec beaucoup plus de L2 en « développement actif ») et leurs efforts en matière de cryptographie. Il y a un manque de PMF dans le monde. Ethereum et Solana sont les blockchains les plus populaires, et les utilisateurs seront attirés par l'une d'elles et ne choisiront l'autre L2 que s'il y a des jetons à exploiter.

Je ne pense pas que trop de L2 soit une mauvaise chose, tout comme je ne pense pas que ce soit nécessairement une bonne chose, mais je suis d’accord sur le fait que nous devons prendre du recul et examiner pourquoi notre industrie crée autant de L2.

Le rasoir d'Occam dirait que les investisseurs en capital-risque apprécient le sentiment de savoir qu'ils ont vraiment le potentiel de construire le prochain roi de L2 (ou L1) et d'obtenir la satisfaction d'investir dans ces projets, mais je pense aussi que peut-être de nombreux développeurs de Crypto veulent réellement plus de L2. . Les deux côtés ont peut-être raison, mais la conclusion quant à savoir lequel a le plus raison n’a pas d’importance. Il est préférable de jeter un regard objectif sur l’écosystème actuel des infrastructures et de tirer le meilleur parti de ce dont nous disposons.

Les performances du L2 dont nous disposons actuellement sont élevées, mais pas suffisantes. Le livre blanc de MegaETH indique que même avec les 100 MGas/s (relativement) élevés d’opBNB, cela ne signifierait que 650 transactions Uniswap par seconde – une infrastructure moderne ou web2 peut effectuer 1 million de transactions par seconde.

Nous savons que malgré les avantages de la cryptographie provenant de la nature décentralisée et permettant des paiements sans autorisation, elle reste assez lente. Si une société de développement de jeux comme Blizzard veut mettre Overwatch en chaîne, elle ne peut pas le faire - nous avons besoin d'un taux de clics plus élevé pour fournir le PvP en temps réel et d'autres fonctionnalités que les jeux Web2 fournissent naturellement.

L’une des solutions de MegaETH au dilemme L2 consiste à déléguer la sécurité et la résistance à la censure à Ethereum et EigenDA respectivement, faisant de MegaETH le L2 le plus performant au monde sans aucun compromis.

L1 nécessite généralement des nœuds homogènes qui effectuent les mêmes tâches, sans possibilité de spécialisation. Dans ce cas, la spécialisation fait référence à un travail comme le séquençage ou la preuve. L2 contourne ce problème, permettant l'utilisation de nœuds hétérogènes, séparant les tâches pour améliorer l'évolutivité ou alléger une partie de la charge. Cela se voit dans la popularité croissante des séquenceurs partagés (tels que Astria ou Espresso) et la montée en puissance des services spécialisés de preuve zk (tels que Succinct ou Axiom).

«La création d'une blockchain en direct implique plus que simplement l'utilisation d'un client d'exécution Ethereum prêt à l'emploi et l'ajout de matériel séquenceur. Par exemple, nos expériences de performances montrent que même avec un serveur puissant équipé de 512 Go de RAM, les performances de Reth sur les blocs Ethereum récents peuvent être atteintes. n'atteignez également qu'environ 1 000 TPS dans le paramètre de synchronisation en temps réel, ce qui équivaut à environ 100 MGas/s.

MegaETH étend ce partitionnement en faisant abstraction de l'exécution des transactions à partir de nœuds complets, en utilisant uniquement un séquenceur « actif » pour éliminer la surcharge de consensus dans l'exécution typique des transactions. "La plupart des nœuds complets reçoivent les différences d'état de cet ordonnateur via le réseau p2p et appliquent les différences directement pour mettre à jour l'état local. Ils ne réexécutent notamment pas les transactions, mais utilisent indirectement les preuves fournies par les prouveurs."

Je n'ai pas lu beaucoup d'analyses sur la qualité de MegaETH autres que les commentaires « c'est rapide » ou « c'est bon marché », je vais donc essayer d'analyser attentivement son architecture et de la comparer aux autres L2.

MegaETH utilise EigenDA pour gérer la disponibilité des données, ce qui est une pratique assez courante de nos jours. Les plateformes Rollup-as-a-Service (RaaS : rollup as a service) comme Conduit vous permettent de choisir Celestia, EigenDA ou même Ethereum (si vous préférez) comme fournisseur de disponibilité des données pour le rollup. La différence entre les deux est plutôt technique et pas tout à fait pertinente, et il semble que la décision de choisir l’un plutôt que l’autre soit basée davantage sur la résonance qu’autre chose.

Le séquenceur ordonne et exécute finalement les transactions, mais est également responsable de la publication des blocs, des témoins et des différences d'état. Dans un contexte L2, un témoin est une donnée supplémentaire utilisée par le prouveur pour vérifier le bloc séquenceur.

Les différences d'état sont des changements dans l'état de la blockchain et peuvent concerner essentiellement tout ce qui se passe sur la chaîne - la fonction de la blockchain est d'ajouter et de vérifier constamment les nouvelles informations ajoutées à son état, et la fonction de ces différences d'état est de permettre nœuds Confirmez la transaction sans la réexécuter.

Prover se compose d'un matériel spécial utilisé pour calculer des preuves cryptographiques afin de vérifier le contenu des blocs. Ils permettent également aux nœuds d'éviter les exécutions en double. Il existe des preuves de connaissance nulle et des preuves de fraude (ou des preuves optimistes ?), mais la différence entre elles n'est pas importante pour le moment.

Rassembler tout cela est la tâche du réseau de nœuds complet, qui agit comme une sorte d'agrégateur entre les prouveurs, les commanditaires et EigenDA pour (espérons-le) faire de la magie MegaETH une réalité.

La conception de MegaETH repose sur une incompréhension fondamentale de l’EVM. Bien que L2 reproche souvent à EVM ses mauvaises performances (débit), il s'est avéré que revm était capable d'atteindre 14 000 TPS. Si ce n'est pas EVM, quelle en est la raison ?

2. Problèmes d'évolutivité actuels

Les trois principales inefficacités de l'EVM qui entraînent des goulots d'étranglement en termes de performances sont le manque d'exécution parallèle, la surcharge de l'interpréteur et la latence élevée d'accès à l'état.

MegaETH est capable de stocker l'état de l'ensemble de la blockchain grâce à son abondance de RAM, la RAM exacte d'Ethereum est de 100 Go. Cette configuration accélère considérablement l'accès à l'état en éliminant la latence de lecture du SSD.

Je ne connais pas grand-chose à la latence de lecture des SSD, mais il est probable que certains opcodes sont plus intensifs que d'autres, et si vous consacrez plus de RAM au problème, vous pouvez l'éliminer. Est-ce que cela fonctionne toujours à grande échelle ? Je ne suis pas sûr, mais pour cet article, je considérerai cela comme un fait. Je suis toujours sceptique quant au fait que les chaînes puissent déterminer simultanément le débit, les coûts de transaction et la latence, mais j'essaie d'être un apprenant actif.

Une autre chose que je dois mentionner est que je ne veux pas être trop pointilleux. Mon idée est de ne jamais soutenir un protocole plutôt qu'un autre, ni même de les valoriser de la même manière en premier lieu - je le fais uniquement pour une meilleure compréhension et pour aider toute personne lisant ceci à acquérir la même compréhension en même temps.

Vous connaissez peut-être la tendance de l'EVM parallèle, mais on dit qu'il y a un problème. Bien que des progrès aient été réalisés dans le portage de l'algorithme Block-STM sur l'EVM, il est dit que "l'accélération réelle réalisable en production est intrinsèquement limitée par le parallélisme disponible dans la charge de travail". Finalement déployée sur la chaîne EVM du réseau principal, la technologie est également limitée par la réalité fondamentale selon laquelle la plupart des transactions n'ont peut-être pas besoin d'être exécutées en parallèle.

Si la transaction B dépend du résultat de la transaction A, vous ne pouvez pas exécuter les deux transactions en même temps. Si 50 % des transactions d'un bloc sont interdépendantes comme dans ce cas, alors l'exécution parallèle ne constitue pas une amélioration aussi significative qu'on le prétend. Bien que cela soit un peu simpliste (et peut-être même un peu incorrect), je pense que cela fait mouche.

L'écart entre Revm et l'exécution native est très visible, en particulier Revm qui est encore 1 à 2 MOO plus lent et n'est pas digne d'un environnement de VM autonome. Il a également été découvert qu'il n'existe actuellement pas suffisamment de contrats à forte intensité de calcul pour justifier l'utilisation de revm. "Par exemple, nous avons analysé le temps passé par opcode lors de la synchronisation historique et avons constaté qu'environ 50 % du temps dans revm était consacré aux opcodes 'hôte' et 'système'."

En termes de synchronisation d'état, MegaETH a trouvé plus de problèmes. La synchronisation d'état est simplement décrite comme le processus de synchronisation des nœuds complets avec l'activité du donneur d'ordre, une tâche qui peut rapidement consommer la bande passante d'un projet comme MegaETH. Voici un exemple pour illustrer cela : si l’objectif est de synchroniser 100 000 transferts ERC20 par seconde, cela consommera environ 152,6 Mbps de bande passante. On dit que ces 152,6 Mbps dépassent les estimations (ou performances) de MegaETH et introduisent essentiellement une tâche impossible.

Cela ne prend en compte que les simples transferts de jetons et ignore la possibilité de coûts plus élevés si la transaction est plus complexe. Il s'agit d'un scénario possible étant donné la diversité des activités en chaîne dans le monde réel. MegaETH a écrit que la transaction Uniswap a modifié 8 emplacements de stockage (alors que le transfert ERC20 n'a modifié que 3 emplacements de stockage), ce qui porte notre consommation totale de bande passante à 476,1 Mbps, ce qui est un objectif encore moins réalisable.

Un autre problème dans la mise en œuvre d'une blockchain haute performance de 100 000 TPS réside dans la résolution des mises à jour de la racine de l'état de la chaîne, une tâche qui gère l'envoi de preuves de stockage aux clients légers. Même avec des nœuds professionnels, les nœuds complets doivent toujours utiliser le nœud séquenceur du réseau pour conserver la racine d'état. En prenant comme exemple le problème ci-dessus de la synchronisation de 100 000 transferts ERC20 par seconde, cela entraînera le coût de mise à jour de 300 000 clés par seconde.

Ethereum utilise la structure de données MPT (Merkle Patricia Trie : Merkle Prefix Tree) pour calculer l'état après chaque bloc. Pour mettre à jour 300 000 clés par seconde, Ethereum devrait « convertir 6 millions de lectures de bases de données non mises en cache », ce qui est bien plus que ce que n'importe quel SSD grand public est capable de faire aujourd'hui. MegaETH écrit que cette estimation n'inclut même pas les opérations d'écriture (ou les estimations pour les transactions en chaîne comme les transactions Uniswap), ce qui rend le défi plus semblable à celui de Sisyphe que la plupart d'entre nous pourraient préférer.

Il y a un autre problème, nous avons atteint la limite du bloc gaz. La vitesse de la blockchain est en fait limitée par la limite de gaz de bloc, qui est une barrière auto-imposée conçue pour augmenter la sécurité et la fiabilité de la blockchain. « La règle générale pour définir les limites de gaz de bloc est de garantir que tout bloc dans cette limite peut être traité en toute sécurité dans le délai de blocage. » Le livre blanc décrit la limite de gaz de bloc comme un « mécanisme de limitation » garantissant que le nœud peut suivre le rythme. de manière fiable, en supposant qu'il réponde à la configuration matérielle minimale requise.

D'autres disent que la limite de gaz de bloc est un choix conservateur pour éviter le pire des cas, ce qui est un autre exemple d'architecture blockchain moderne axée sur la sécurité plutôt que sur l'évolutivité. L’idée selon laquelle l’évolutivité est plus importante que la sécurité s’effondre si l’on considère combien d’argent est transféré chaque jour entre les blockchains et combien cet argent serait perdu afin d’améliorer légèrement l’évolutivité, provoquant ainsi un hiver nucléaire.

Les blockchains ne sont peut-être pas très efficaces pour attirer des applications grand public de haute qualité, mais elles sont exceptionnellement efficaces pour les paiements peer-to-peer sans autorisation. Personne ne veut gâcher ça.

Il est ensuite mentionné que la vitesse des EVM parallèles dépend de la charge de travail et que leurs performances sont gênées par la « longue chaîne de dépendance » qui minimise « l'accélération » excessive des fonctions de la blockchain. La seule façon de résoudre ce problème est d’introduire une tarification multidimensionnelle du gaz (MegaETH fait référence au marché des frais natifs de Solana), ce qui est encore difficile à mettre en œuvre. Je ne sais pas s'il existe un EIP dédié, ni comment un tel EIP fonctionnerait sur l'EVM, mais je suppose que techniquement, c'est une solution.

Enfin, les utilisateurs n’interagiront pas directement avec le nœud séquenceur et la plupart des utilisateurs n’exécuteront pas un nœud complet chez eux. Par conséquent, l’expérience utilisateur réelle d’une blockchain dépend fortement de son infrastructure sous-jacente, telle que les nœuds RPC et les indexeurs. Quelle que soit la vitesse d'exécution d'une blockchain en direct, si les nœuds RPC ne peuvent pas gérer efficacement le grand nombre de demandes de lecture pendant les heures de pointe, propagent rapidement les transactions aux nœuds du séquenceur ou si l'indexeur ne peut pas mettre à jour la vue de l'application assez rapidement pour suivre la chaîne. vitesse, la vitesse d'exécution de la blockchain en temps réel n'a pas d'importance. "

C'est peut-être trop à dire, mais c'est très important. Nous comptons tous sur Infura, Alchemy, QuickNode, etc., et l'infrastructure sur laquelle ils fonctionnent prend probablement en charge toutes nos transactions. L’explication la plus simple de cette dépendance vient de l’expérience. Si vous avez déjà essayé de réclamer un largage dans les 2-3 heures suivant un largage L2, vous comprendrez à quel point il est difficile pour RPC de gérer ce type de congestion.

3. Conclusion

Cela dit, je veux juste exprimer qu'un projet comme MegaETH doit franchir de nombreux obstacles pour atteindre les sommets qu'il souhaite atteindre. Un article indique qu'ils ont réussi à réaliser un développement haute performance en utilisant une architecture blockchain hétérogène et un environnement d'exécution EVM super optimisé. "Aujourd'hui, MegaETH dispose d'un réseau de développement en direct hautes performances et progresse régulièrement pour devenir la blockchain la plus rapide, limitée uniquement par des limitations matérielles."

Le Github de MegaETH répertorie quelques améliorations majeures, notamment : le bytecode EVM → un compilateur de code natif, un moteur d'exécution dédié pour les nœuds de tri de grande mémoire et un protocole de contrôle de concurrence efficace pour l'EVM parallèle. Un compilateur de bytecode/code natif EVM est maintenant disponible appelé evmone, et même si je ne suis pas suffisamment familiarisé avec le codage pour en connaître le fonctionnement de base, j'ai fait de mon mieux pour le comprendre.

evmone est un déploiement C++ d'EVM qui prend l'API EVMC et la convertit en module d'exécution pour le client Ethereum. Il mentionne d'autres fonctionnalités que je ne comprends pas, comme son approche à double interprète (de base et avancé) et les bibliothèques intx et ethash. En résumé, evmone offre un traitement des transactions plus rapide (grâce à une exécution plus rapide des contrats intelligents), une plus grande flexibilité de développement et une plus grande évolutivité (en supposant que différents déploiements EVM puissent gérer plus de transactions par bloc).

Il existe quelques autres bases de code, mais la plupart d'entre elles sont assez standards et ne sont pas spécifiquement liées à MegaETH (reth, geth). Je pense que j'en ai presque fini avec le livre blanc, alors maintenant je laisse la question à tous ceux qui lisent ceci : quelle est la prochaine étape pour MegaETH ? Est-il vraiment possible de mettre en place des codes d’épandage efficaces ? Combien de temps faudra-t-il pour que cela se produise ?

En tant qu'utilisateur de blockchain, j'ai hâte de voir si cela est possible. J'ai dépensé trop d'argent en frais de transaction sur le réseau principal et il est temps de changer, mais ce changement semble toujours de plus en plus difficile à réaliser et il est peu probable qu'il se produise de si tôt.

Bien que le contenu de cet article se concentre principalement sur les améliorations architecturales et l'évolutivité, les rollups internes doivent toujours partager des outils de liquidité et inter-chaînes pour rendre l'expérience du rollup A cohérente avec celle du rollup B. Nous n’en sommes pas encore là, mais peut-être que d’ici 2037, tout le monde se rappellera à quel point nous étions obsédés par la « résolution » des problèmes d’évolutivité.