jakiro
Auteur: John Otander, Core Ethereum développeur;
Cet article a été inspiré par les réponses d’Ethereum souvent à Vitalik dans le récent Reddit AMA.
Vitalik a souligné qu’il est raisonnable d’augmenter la limite de gaz modérément, et la limite de gaz n’a pas augmenté en près de trois ans, ce qui est le plus long de l’histoire de l’accord.Vitalik a également effectué des calculs simples pour augmenter la limite de gaz Ethereum à 40 millions.
Cet article explique pourquoi il est difficile d’améliorer la limite de gaz Ethereum?Augmentez les risques posés par la limite de gaz Ethereum, ainsi que les solutions connexes.
1,Limite de gaz(Gazlimite)
La limite de gaz détermine la quantité de travail effectuée dans un bloc et détermine donc le nombre de transactions qui peuvent être exécutées par bloc.L’amélioration de la limite de gaz permettra à Ethereum de gérer un débit de transaction plus élevé ou des transactions plus complexes.Les paramètres de limite de gaz spécifiques ont été affectés par les mineurs / parties prenantes et la limite a augmenté au fil des ans.Le chiffre suivant provient de Etherscan.io, montrant l’utilisation historique du gaz (très proche de la limite de gaz, toutes les augmentations de limite ont été digérées par le marché).
2,risque
Désormais, l’augmentation de la limite de gaz comporte plusieurs risques.
(1) Taux de bloc de fuite
J’ai mentionné dans mon article précédent que le taux de l’oncle est l’indicateur le plus discuté lors de l’évaluation de l’augmentation de la limite de gaz.Maintenant, après la fusion Ethereum, il n’y a plus de déblocs.Si nous voulons savoir si le nœud peut bien gérer la limite de gaz actuelle, le seul moyen est de voir le taux de bloc manquant.Mais cette métrique est imparfaite car elle ne montre que les nœuds actuellement sous-estimés.Il ne nous fournit pas une bonne mesure pour montrer l’augmentation de la limite de gaz, et cela ne montre que le cas moyen, pas le pire des cas qui puisse se produire dans l’attaque.
(2) Taille d’état
L’instantané du compte du bloc 18418786 (24 octobre 2023) est de 10,33 Go et l’instantané de stockage est de 76,59 Go, donc l’état global est d’environ 87 Go.Le bloc 17419840 (6 juin 2023) a un statut d’un peu moins de 80 Go.Cela signifie que le statut a augmenté d’environ 7 Go en 4 mois, ce qui signifie environ 2 Go par mois.
Si nous utilisons 87+ (2 * 12 * # années) pour en déduire, le statut sera de 111 Go en un an et 207 Go en cinq ans.Le problème ici n’est pas la taille.Tout le monde peut stocker autant de données, mais l’accès et la modification de ces données deviendront de plus en plus lents.
Ce n’est qu’un instantané, c’est un état normal.Geth doit également stocker cet état sous une forme différente afin de vérifier la racine de l’État.Une autre forme de stockage d’État (nœud de tri) du bloc 18418786 nécessite environ 180 Go.
Par conséquent, la taille totale de l’espace actuellement utilisée pour le stockage d’état est d’environ 267 Go.Si nous augmentons la limite de gaz, la taille de l’état augmentera plus rapidement.
Le problème de la croissance de l’État est que, contrairement au passé, nous n’avons pas de chemin clair pour supprimer l’état.Il n’y a pas de suggestions de délai d’État spécifiques que nous pouvons rapidement mettre en œuvre pour nous sortir d’un état croissant.
(3) Échelle historique
Dans un article en 2021, j’ai mentionné qu’un nœud Geth complet est d’environ 350 Go (nouvellement taillé).Après environ trois ans, un nœud complet (sur PBSS) dépasse 900 Go.Le chiffre suivant montre le volume total accumulé de transactions.Il est facile de voir que le volume des transactions a plus que doublé en trois ans, passant d’environ 980 millions à plus de 2,2 milliards.
Avec l’essor de L2, l’échelle historique est devenue un problème plus important, car ils sont maintenant (avant que le 4844 ne soit mis en ligne) la façon dont ils stockent les données sont appelées données.Le bloc 18418786 a plus de 427 Go de bloc, tandis que le bloc 17419840 (également il y a 4 mois) a 339 Go de bloc, ce qui signifie une croissance de 28 Go en 4 mois, ce qui signifie une croissance d’environ 9 Go par mois.Nous pouvons utiliser 427+ (9 * 12 * # années) pour déduire cette croissance, c’est-à-dire 535 Go après un an et 967 Go après cinq ans (assumez à nouveau la croissance linéaire).
Espérons que cette croissance ralentira après le lancement de l’EIP-4844, lorsque L2 cessera d’utiliser CallData pour obtenir la disponibilité des données et passer à des blobs qui expirent dans quelques semaines.
L’EIP-4444 résoudra le problème de croissance historique, car les nœuds complets n’ont plus besoin de stocker toute l’histoire.La mise en œuvre de l’EIP-4444 nécessite un réseau fiable pour récupérer l’historique, puis nous pouvons faire en sorte que le nœud complet d’arrêter le service de données historique.
(4) Temps synchrone
La limite de gaz peut affecter le temps de synchronisation à bien des égards:
· La synchronisation complète devient très lente.
· Les données historiques simultanées sont lentes.Parce que nous devons télécharger plus de données, la synchronisation de la partie de données historiques sera plus lente.
· L’état de synchronisation des instantanés est plus lent car nous devons télécharger plus de statuts.
· La récupération des instantanés est lente.Étant donné que le point de pivot se déplace pendant la synchronisation des instantanés, nous avons de nombreux états incomplets sur le disque qui doivent être corrigées.Si le pivot se déplace plus fréquemment et qu’il y a plus de changements par bloc, cette phase de réparation sera ralentie.
· La synchronisation avec la chaîne sera plus lente car les nœuds doivent passer plus de changements pour former des en-têtes de bloc.
(5) Diversité des clients
Construire un nouveau client EL est une tâche difficile en soi.Il y a un inconvénient supplémentaire de l’ajout de la limite de gaz, à savoir qu’il rendra plus difficile la création de clients et optimisera pour une utilisation par le MainNet.Geth est développée depuis plus de 10 ans et a subi de nombreuses optimisations.Il peut y avoir une vision opposée que les nouveaux clients peuvent emprunter auprès des clients existants et ne plus commettre les mêmes erreurs.
Cependant, nous avons vu le dilemme MainNet de deux clients (spécifications d’exécution écrites en Python et Ethereumj écrites en javascript).Cela signifie également que les clients écrits dans certaines langues ne fonctionnent pas maintenant.En raison des frais généraux linguistiques et de la maturité de la base de code, l’ajout de limite de gaz laissera certains clients derrière.
Nous le voyons dans KZG, et pour obtenir les performances requises, la plupart des clients s’appuient sur l’appel C-KZG (une base de code écrite en C) plutôt que d’utiliser des bibliothèques écrites dans leur langue choisie.
(6) Pire des cas
Lorsque vous envisagez la limite de gaz, nous ne pouvons pas simplement regarder la situation générale.Nous devons toujours considérer le pire des cas.Bien sûr, les nœuds peuvent bien fonctionner lorsque la chaîne est à une situation de charge moyenne, mais que se passe-t-il si l’E / S de disque de 5 blocs double soudainement?
Le temps d’exécution n’est pas la seule métrique que nous devons considérer, et si un attaquant peut reprendre d’autres ressources telles que les E / S de disque, le temps de processeur ou la mémoire, il peut forcer les machines à faible configuration à la ligne.Surtout après la fusion d’Ethereum, exécuter deux clients sur la même machine, l’attaque de l’un d’eux peut également rendre l’autre client instable.Au début des tests de fusion d’Ethereum, nous avons été témoins plusieurs fois: une fuite de mémoire sur un client entraînerait une écrasement de l’ensemble du système.
Une autre pire scénario à considérer est la taille de la preuve.À mesure que la limite de gaz augmente, les changements d’état potentiels qui peuvent se produire entre les deux blocs augmentent également.Cela a un impact sur la synchronisation des instantanés discuté précédemment, mais cela affecte également la taille de preuve du client léger de la couche d’exécution.Maintenant, ce n’est pas un gros problème, la preuve de l’arbre Merkle-Patricia est trop gros pour envoyer le réseau.Cependant, si nous voulons implémenter l’idée de validation croisée de faire fonctionner plusieurs clients légers sur la même machine, la taille de la preuve est très importante.
3, solution
Sommes-nous finis comme ça?Garderons-nous la limite supérieure de 30 mgas?Non!
Dans un article en 2021, j’ai proposé des solutions au dilemme auquel nous sommes confrontés à ce moment-là.Pour le problème complet de la synchronisation que nous sommes confrontés en 2021, GETH met en œuvre la synchronisation des instantanés et les instantanés.Pour les problèmes d’élagage et de disposition de la base de données, Geth implémente PBSS.Txpool est devenu plus fiable dans la gestion des charges de transaction élevées, et la plupart des transactions RUSH MEV sont transférées aux constructeurs.De nombreuses transactions sont également passées à L2, ce qui à son tour a augmenté la taille moyenne des transactions MainNet.
La seule solution qui n’est pas mise en œuvre est la régénèse.Au fil des ans, les opinions des gens ont un peu changé, et la plupart des gens semblent être enclins à utiliser la date limite historique de l’EIP-4444 comme solution à court terme à la croissance des données historiques.Pour la publication de l’EIP-4444, nous avons besoin d’un solide réseau de nœuds de service de données historiques afin que l’histoire ne soit pas perdue, même si elle n’est plus stockée par tous tous) .
Nous n’avons toujours pas trouvé de moyen décent et réaliste d’aller pour une date limite d’État.
Comme vous avez vu les attaques avant de dégénérer à Shanghai, il y a des attaques connues qui nous empêchent d’élever Gaslimit.(Pour autant que je sache) toutes les vulnérabilités ont été résolues.
Au moment de la rédaction du moment de la rédaction, EIP-4844 est publié en ligne.Cet EIP augmentera les exigences de stockage et d’E / S du nœud.À mon avis, il est le plus sûr d’attendre et de voir l’impact de cette modification sur le maint de main-d’œuvre avant d’essayer tout type d’ajout de limite de gaz.Une fois que L2 se transforme en transactions blob, nous devons augmenter les coûts de calldata (car à mon avis, le calldata est sous-évalué par rapport à d’autres choses que les données doivent être stockées).Cela peut également être utilisé comme fonction coercitive pour L2 à l’aide de Blobspace.
En bref, je voudrais rappeler à tout le monde d’être prudent en envisageant d’améliorer la limite de gaz, car cela affectera de nombreux aspects du nœud, et certains des effets seront relativement évidents.Dans les discussions connexes, il est très important de considérer les effets à long terme et à court terme des changements de limite de gaz.
