Après la mise à niveau de Cancún, quel est le goulot d'étranglement en termes de performances des Rollups ?

Compilé par : Azuma, Odaily Planet Daily

Selon midi le 26 mars, heure de Pékin, le co-fondateur de Monad, Keone Hon, a publié un article approfondi sur l'état des performances de Rollup. Dans l'article, Keone a détaillé comment la limite théorique de TPS du Rollup devrait être calculée après la mise à niveau de l'affichage du bloc, et a expliqué qu'après la mise à niveau, les frais de transaction uniques de certaines couches 2 (de base) s'élèvent toujours à plusieurs dollars. En outre, Keone a également souligné certains des goulots d'étranglement rencontrés par Rollup et les améliorations potentielles.

Ce qui suit est le contenu original de Keone, compilé par Odaily Planet Daily Pour la commodité des lecteurs, le traducteur a apporté certains ajouts au texte original.

Récemment, il y a eu des discussions sur le marché concernant les goulots d'étranglement dans l'exécution du Rollup et les limitations de Gas, qui impliquent non seulement la couche 1, mais également la couche 2. Je discute de ces goulots d’étranglement ci-dessous.

Disponibilité des données (DA)

Selon la norme EIP-4844, la structure de données Blob a été introduite dans la mise à niveau de la blockchain. La disponibilité des données (DA) d'Ethereum a été considérablement améliorée. Les transactions de synchronisation des données de Layer2 n'ont plus besoin d'interagir avec Ordinary. Les transactions de couche 1 sont proposées sur le même marché de frais.

Actuellement, l'état de capacité global des Blobs est de produire 3 Blobs de 125 Ko par bloc (12 secondes), soit 31,25 Ko par bloc. Étant donné que la taille d'une transaction est d'environ 100 octets, cela signifie que tous les Rollups partagent le TPS. environ 300.

Bien sûr, il y a ici certaines informations qui nécessitent des remarques particulières.

• Premièrement, si Rollup adopte une meilleure technologie de compression des données de transaction pour réduire la taille d'une seule transaction, TPS peut croître.
• Deuxièmement, en théorie, en plus d'utiliser Blob pour synchroniser les données, Rollup peut également continuer à utiliser les données d'appel pour synchroniser les données (c'est-à-dire l'ancienne solution avant la mise à niveau de Cancun), même si cela apportera une complexité supplémentaire.
• Troisièmement, il existe des différences dans la manière dont les différents rollups ZK publient le statut (en particulier zkSync Era et Starknet), donc pour ces rollups, les méthodes de calcul et les résultats seront également différents.

Limite de gaz du Rollup

Récemment, Base+ a attiré une grande attention en raison de la flambée des frais de gaz. Le coût de certaines transactions ordinaires sur le réseau s'est élevé à plusieurs dollars.

Pourquoi le réseau de base n'a-t-il diminué que pendant un certain temps après la mise à niveau à Cancun, et maintenant il est revenu au niveau d'avant la mise à niveau, voire l'a dépassé ? En effet, il existe une limite totale de gaz sur les blocs de Base, qui est appliquée via un paramètre dans son code.

Les paramètres de gaz actuellement utilisés par Base sont les mêmes que ceux d'Optimism, c'est-à-dire qu'il y a une limite totale de 5 millions de gaz par bloc Layer2 (2 secondes) lorsque la demande (nombre total de transactions) sur le réseau dépasse l'offre. (espace bloc) A ce moment, le règlement des prix adoptera un mécanisme d'exécution à la demande, entraînant une augmentation du volume de gaz sur le réseau.

Pourquoi Base n’augmente-t-il pas cette limite totale de gaz ? Ou en d’autres termes, pourquoi Rollup doit-il fixer une limite totale de gaz ?

En plus de la limite supérieure TPS sur la disponibilité des données mentionnée ci-dessus, il existe en fait deux autres raisons majeures, à savoir le goulot d'étranglement du débit d'exécution et le danger caché de la croissance de l'État.

Problème 1 : Goulot d'étranglement du débit d'exécution

De manière générale, EVM Rollup exécute un EVM fork de Geth, ce qui signifie qu'ils ont des caractéristiques de performances similaires à celles du client Geth.

Le client de Geth est monothread (c'est-à-dire qu'il ne peut gérer qu'une seule tâche à la fois), utilise l'encodage LevelDB/PebbleDB et stocke son état dans un Merkle Patricia trie (MPT). Il s'agit d'une base de données à usage général qui utilise une autre structure arborescente (arborescence LSM) comme couche sous-jacente pour stocker les données sur un disque SSD (Solid State Drive).

Pour Rollup, "state access" (lecture des valeurs du trie merkle) et "state update" (mise à jour du trie merkle à la fin de chaque bloc) sont les liens les plus coûteux dans le processus d'exécution. En effet, le coût d'une seule lecture à partir du SSD est de 40 à 100 microsecondes et, comme la structure de données Merkle trie est intégrée dans une autre structure de données (arborescence LSM), elle nécessite de nombreuses recherches supplémentaires inutiles.

Ce lien peut être imaginé comme le processus de recherche d'un fichier spécifique dans un système de fichiers complexe. Vous devez passer du répertoire racine (nœud racine trie) jusqu'au fichier cible (nœud feuille). Lors de la recherche de chaque fichier, vous devez trouver une clé spécifique dans la base de données LevelDB, et dans LevelDB, vous devez effectuer l'opération de stockage de données réelle via une autre structure de données appelée arborescence LSM. Ce processus entraîne de nombreuses étapes de recherche supplémentaires. Ces étapes supplémentaires rendent la lecture et la mise à jour globales des données assez lentes et inefficaces.

Dans la conception de Monad, nous avons résolu ce problème via MonadDb. MonadDb est une base de données personnalisée qui prend en charge le stockage des trie Merkle directement sur le disque, évitant ainsi la surcharge de LevelDb ; prend en charge les E/S asynchrones, permettant de traiter plusieurs lectures en parallèle ;

De plus, le mécanisme « d'exécution parallèle optimiste » adopté par Monad permet de traiter plusieurs transactions en parallèle et leur statut peut être extrait de MonadDb en parallèle.

Cependant, Rollup ne dispose pas de ces optimisations et présente donc un goulot d'étranglement dans le débit d'exécution.

Il convient de noter que le client Erigon/Reth dispose de certaines optimisations pour l'efficacité de la base de données, et certains clients Rollup sont également construits sur la base de ces clients (comme OP-Reth). Erigon/Reth utilise une structure de données plate, ce qui réduit dans une certaine mesure le coût des requêtes lors de la lecture ; cependant, ils ne prennent pas en charge la lecture asynchrone ou le traitement multithread ; De plus, la racine de Merkle doit être recalculée après chaque bloc, ce qui est également un processus plutôt lent.

Question 2 : Dangers cachés de la croissance de l'état

Comme d'autres blockchains, Rollup limitera également leur débit pour empêcher son état actif de croître trop rapidement.

Un argument courant sur le marché est que la raison pour laquelle le taux de croissance de l'État est inquiétant est que si les données d'État augmentent de manière significative, la demande d'appareils en disques SSD (Solid State Drives) devra également être ajustée à la hausse. Cependant, je pense que c'est un peu inexact, les SSD sont relativement bon marché (un SSD de 2 To de haute qualité coûte environ 200 $) et l'état complet d'Ethereum n'a "que" atteint environ 200 Go au cours de ses près de 10 ans d'histoire. Du point de vue du stockage pur, il y a encore beaucoup de marge de croissance.

Le plus grand danger caché est en fait qu'à mesure que le statut continue de croître, le temps nécessaire pour interroger le fragment de statut spécifié deviendra plus long. En effet, le trie Merkle Patricia actuel utilisera le "raccourci" lorsque la condition "le nœud n'a qu'un seul nœud enfant" est remplie, ce qui peut réduire la profondeur effective du trie et ainsi accélérer le processus de requête. le statut du trie merkle devient de plus en plus complet, il y aura de moins en moins de "raccourcis" disponibles.

En résumé, le danger caché de la croissance de l’État est en fin de compte une question d’efficacité de l’accès à l’État, donc accélérer l’accès à l’État est la clé pour rendre la croissance de l’État plus durable.

Pourquoi la simple optimisation du matériel ne fonctionne pas ?

Layer2 est actuellement encore dans un état relativement centralisé, c'est-à-dire que le réseau s'appuie toujours sur un seul séquenceur pour maintenir l'état et produire des blocs. On pourrait se demander, alors pourquoi ne pas faire fonctionner le trieur sur du matériel avec une RAM (mémoire vive) très élevée afin que tout l'état puisse être stocké en mémoire ?

Il y a deux raisons à cela.

Tout d'abord, cela ne résoudra pas le problème de goulot d'étranglement de la disponibilité des données du réseau principal Ethereum. Bien que sur la base de la situation actuelle de Base, l'augmentation du gaz du réseau n'est pas causée par des capacités de disponibilité des données insuffisantes du réseau principal, mais. à long terme, il semble que cela finira par devenir un goulot d'étranglement majeur limitant le Rollup.

Le deuxième problème est la décentralisation. Bien que le séquenceur soit toujours très centralisé, d'autres rôles impliqués dans le fonctionnement du réseau sont également importants. Ils doivent également être capables d'exécuter des nœuds de manière indépendante, de rejouer le même historique de transactions et de conserver le même statut.

Les données brutes de transaction et la soumission de l'état sur la couche 1 ne suffisent pas pour déverrouiller l'état complet. Tout acteur ayant besoin d'accéder à l'état complet (comme un commerçant, une bourse ou un commerçant automatisé) doit exécuter un nœud Layer2 complet pour traiter les transactions et disposer d'une copie à jour de l'état.

Les rollups sont toujours des blockchains, et les blockchains sont intéressantes en raison de leur capacité à réaliser une coordination mondiale grâce à un état mondial partagé. Pour toutes les blockchains, un logiciel puissant est nécessaire, et l’optimisation du matériel à elle seule ne suffit pas à résoudre le problème.

Interaction avec la communauté

Après que Keone ait publié cet article, le personnel clé de plusieurs projets principaux de Layer2 a interagi sous la mise à jour.

Le co-fondateur de zkSync, Alex Gluchowski, a demandé quelle est la différence entre Monad à cet égard en réponse à l'article « La racine merkle doit être recalculée après chaque bloc » ?

La réponse de Keone est qu'il y aura un algorithme d'optimisation pour calculer la racine de Merkle après chaque bloc.

Jesse Pollak, le responsable de la base, a également utilisé cela pour expliquer pourquoi le coût du gaz a augmenté au lieu de baisser après la mise à niveau de la base à Cancun. Il a déclaré que l'EIP-4844 avait considérablement réduit le coût du DA au niveau de la couche 1. Cependant, étant donné que la demande de transactions sur le réseau a augmenté de plus de cinq fois et que les blocs sur le réseau de base ont une limite de 250 gaz/s, la demande dépasse l'offre, ce qui entraîne une augmentation des frais de gaz.

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!