Transmettre le titre original 'Sommes-nous enfin prêts pour une augmentation de la limite de gas ?'
Il y a eu une discussion croissante autour de la possibilité d'augmenter le débit de gaz d'Ethereum, soit en augmentant la limite de gaz, soit en réduisant le temps de slot. L'argument clé en faveur de cela est que les exigences matérielles pour exécuter un validateur ont diminué régulièrement au cours des quatre dernières années.
De plus, 2 approches pour augmenter la limite de gaz ont fait surface :
Dans cet article, j'analyserai les scénarios potentiels du pire cas et du cas moyen en termes de bande passante, de calcul et de besoins de stockage si la limite de gas était doublée.
Quand Ethereum a été lancé en 2015, la limite de gas était initialement fixée à 5 000 gas par bloc. Avec le temps, cette limite a connu des changements significatifs:
– Suite à la mise à jour Tangerine Whistle et plus précisément à la mise en œuvre de l'EIP-150, la limite de gas a été augmentée à 5,5 millions. Cette modification a été effectuée dans le cadre d'un réajustement de certains opcodes intensifs en E/S en réponse à des attaques de déni de service (DoS).
– En juillet 2017, la limite de gas a été augmentée à 6,7 millions et elle a continué à augmenter:
- Décembre 2017: ~8 millions
– Septembre 2019: ~10 millions
- Août 2020: 12,5 millions
– Avril 2021 : 15 millions
Avec EIP-1559, il existe également une limite maximale (ou "cap hard") de gaz, qui est fixée à deux fois la cible. Cela signifie qu'un bloc peut inclure des transactions avec jusqu'à 30 millions de gaz.
Et depuis près de quatre ans, il n’y a eu aucune augmentation de la limite d’essence.
Pour répondre à cette question, nous devons analyser trois aspects des exigences matérielles: la bande passante, le calcul et le stockage si la limite de gaz était augmentée à 60 millions aujourd'hui.
Lorsque l’on envisage une augmentation de la limite de gaz, le stockage se distingue comme le plus grand goulot d’étranglement et la plus grande préoccupation pour le réseau Ethereum. La raison en est la croissance historique de la taille de l’État d’Ethereum et la pression continue que cela exerce sur les validateurs.
Il existe deux types de «croissance» dans Ethereum:
Croissance de l'État
Croissance de l'histoire
L’état d’Ethereum, c’est-à-dire la collecte de tous les soldes de comptes, le code des contrats intelligents et le stockage, continue de s’étendre à mesure que de plus en plus de transactions sont traitées et que des contrats intelligents sont déployés. Depuis sa création, la taille de l’État a considérablement augmenté, avec des périodes de croissance accélérée dues à la congestion du réseau, à l’augmentation de l’activité transactionnelle et à l’essor de la finance décentralisée (DeFi) et des NFT. Actuellement, la croissance de l’État est d’environ 2,5 Go par mois, soit 30 Go par an.
Cette croissance de l'état peut entraîner les problèmes suivants :
– Temps d'accès plus lents au disque
– Exigences matérielles accrues
Cependant, au moment de la rédaction, aucun de ces problèmes n'est particulièrement significatif. En fait, la différence de temps d'accès entre les systèmes de stockage qui diffèrent de seulement quelques dizaines de gigaoctets est assez négligeable en raison de la complexité algorithmique des requêtes, qui est généralement logarithmique. Les besoins de stockage sont également insignifiants, car le coût du nouveau matériel diminue à un rythme bien supérieur à la croissance relativement faible de la taille de l'état de 30 Go par an. Même si elle était portée à 60 Go/an, la différence ne se démarquerait probablement pas et serait toujours dépassée par les progrès technologiques en matière de matériel de toute façon.
Cette augmentation de la taille de l’État est encore largement dépassée par le progrès technologique. Même si la limite de gaz devait doubler, le coût du matériel continue de diminuer de manière exponentielle, ce qui rend le matériel nécessaire moins cher au fil du temps.
Cependant, il convient de noter que bientôt, les stakers individuels auront besoin de plus de 2 To de stockage pour exécuter un validateur sur Ethereum. Cela augmentera effectivement l'exigence à 4 To de stockage, car la plupart du matériel est vendu par puissances de deux. Paradoxalement, cela signifie qu'Ethereum pourrait aussi bien utiliser le stockage supplémentaire, car les validateurs auraient déjà besoin d'investir dans du matériel de plus grande capacité, que la limite de gaz soit augmentée ou non.
REMARQUE: Il n'y a pas d'analyse moyenne par rapport au pire des cas sur le stockage car manipuler de manière cohérente des blocs pendant une période prolongée (semaines et mois) est une entreprise extrêmement coûteuse.
Pour justifier mes affirmations selon lesquelles le coût du stockage diminue à des taux exponentiels, nous pouvons examiner les fluctuations de prix en USD d'1 Go de SSD au cours des quatre dernières années :
Désolé pour la mauvaise qualité, mais la publication d'où je l'ai prise était comme ça
Il semble que tous les deux ans, le coût d'un Go de SSD a tendance à être divisé par deux.
Si nous comparons cela à la croissance du stockage et de l'état, la différence est négligeable. La croissance actuelle d'Ethereum est linéaire, tandis que les coûts matériels ont tendance à diminuer à un taux exponentiel.
J'ai trouvé un graphique plus révélateur sur cette tendance avec les coûts de stockage, mais il provient d'un message Reddit et non d'une publication scientifique réelle (bien que les résultats correspondent).
Le cas moyen de la bande passante dans Ethereum ressemble à environ 2 Mo/s ; cependant, la plupart de ce nombre provient des blocs CL qui bavardent et s'aggrègent. En ce qui concerne l'augmentation de la limite de gaz, la seule chose à regarder est la taille du bloc.
Actuellement, la taille maximale du bloc enregistrée est de 270 Ko, et la taille actuelle du bloc après Deneb est de 75 Ko. Si nous devions doubler cela, le changement serait équivalent à une augmentation de 0,5 à 2 blobs par rapport au maximum historique et à la moyenne actuelle, ce qui équivaudrait à une augmentation d'environ 2 à 5% de la bande passante du nœud (entrant et sortant). Ainsi, pour le cas moyen, ce n'est pas un changement significatif. En fait, trois blobs supplémentaires seraient bien plus dégradants.
Le pire scénario a été calculé à 1,7 Mo, ce qui deviendrait 3,4 Mo (+50 % de bande passante nécessaire pour le pic). Ce n’est pas grand-chose, mais c’est tout de même significatif. La raison pour laquelle je pense que ce n’est pas beaucoup, c’est qu’un tel DoS serait assez coûteux et que le pic serait de +50% des exigences moyennes actuelles, ce qui est déjà pris en compte. Comme je le disais, remplir des blocs d’une valeur de 15 millions de gaz à ras bord pendant de nombreux blocs successifs est très coûteux. Ainsi, même si un attaquant pourrait potentiellement lancer un DoS pour quelques blocs, il devrait dépenser une somme d’argent importante pour le faire. De plus, ils devraient rivaliser avec d’autres transactions pour entrer dans le bloc, ce qui rend cela encore plus coûteux.
Quoi qu'il en soit, indépendamment des opinions sur les chiffres, une augmentation du coût des données d'appel résoudrait complètement ce problème, donc je ne m'en inquiète pas dans tous les cas. De plus, si la limite de gas est augmentée grâce à EIP-7783, ces risques sont négligeables et maîtrisables.
Le calcul et les temps de blocage n'ont jamais été un problème au départ, mais nous y voilà.
Le cas moyen de calcul de bloc est généralement inférieur à 1 seconde, même pour les machines lentes avec des disques durs défectueux. Il n'y a pas grand-chose à discuter ici - en moyenne, cela n'a jamais été le goulot d'étranglement.
Le pire des cas semble peu clair et dépend du client. Après avoir discuté avec certaines équipes de clients, il semble que le consensus soit que le seul problème serait que certains opcodes ne s’adaptent pas bien (comme MODEXP).
Cependant, tous les vecteurs DoS ici peuvent être corrigés avec un nouveau tarif, et si l'augmentation de la limite de gas est effectuée avec EIP-7783, alors ces risques sont négligeables.
Dans l'ensemble, il semble que la croissance du stockage ne soit pas le goulot d'étranglement pour augmenter la limite de gas, car le matériel tel que le stockage est facile à mettre à niveau. Cependant, la bande passante pose une menace plus importante car elle est beaucoup plus difficile à mettre à l'échelle. Heureusement, avec l'EIP-7783, les risques liés à la bande passante et aux augmentations potentielles des calculs sont efficacement atténués. Néanmoins, il serait peut-être sage de revoir le coût des calldatas pour assurer une sécurité supplémentaire (bien que, selon moi, cela ne soit pas nécessaire).
À mon avis, il est actuellement possible d’augmenter la limite de gaz de 33% ou même de la doubler aujourd’hui si cela est fait avec l’augmentation progressive introduite EIP-7783.
Je pense qu’il est encore trop tôt pour le faire par le biais de l’EIP-7782, car ce serait punitif pour la TVP et la SSF. Cependant, une fois que ceux-ci sont compris, une diminution des temps de créneau est certainement due.
Transmettre le titre original 'Sommes-nous enfin prêts pour une augmentation de la limite de gas ?'
Il y a eu une discussion croissante autour de la possibilité d'augmenter le débit de gaz d'Ethereum, soit en augmentant la limite de gaz, soit en réduisant le temps de slot. L'argument clé en faveur de cela est que les exigences matérielles pour exécuter un validateur ont diminué régulièrement au cours des quatre dernières années.
De plus, 2 approches pour augmenter la limite de gaz ont fait surface :
Dans cet article, j'analyserai les scénarios potentiels du pire cas et du cas moyen en termes de bande passante, de calcul et de besoins de stockage si la limite de gas était doublée.
Quand Ethereum a été lancé en 2015, la limite de gas était initialement fixée à 5 000 gas par bloc. Avec le temps, cette limite a connu des changements significatifs:
– Suite à la mise à jour Tangerine Whistle et plus précisément à la mise en œuvre de l'EIP-150, la limite de gas a été augmentée à 5,5 millions. Cette modification a été effectuée dans le cadre d'un réajustement de certains opcodes intensifs en E/S en réponse à des attaques de déni de service (DoS).
– En juillet 2017, la limite de gas a été augmentée à 6,7 millions et elle a continué à augmenter:
- Décembre 2017: ~8 millions
– Septembre 2019: ~10 millions
- Août 2020: 12,5 millions
– Avril 2021 : 15 millions
Avec EIP-1559, il existe également une limite maximale (ou "cap hard") de gaz, qui est fixée à deux fois la cible. Cela signifie qu'un bloc peut inclure des transactions avec jusqu'à 30 millions de gaz.
Et depuis près de quatre ans, il n’y a eu aucune augmentation de la limite d’essence.
Pour répondre à cette question, nous devons analyser trois aspects des exigences matérielles: la bande passante, le calcul et le stockage si la limite de gaz était augmentée à 60 millions aujourd'hui.
Lorsque l’on envisage une augmentation de la limite de gaz, le stockage se distingue comme le plus grand goulot d’étranglement et la plus grande préoccupation pour le réseau Ethereum. La raison en est la croissance historique de la taille de l’État d’Ethereum et la pression continue que cela exerce sur les validateurs.
Il existe deux types de «croissance» dans Ethereum:
Croissance de l'État
Croissance de l'histoire
L’état d’Ethereum, c’est-à-dire la collecte de tous les soldes de comptes, le code des contrats intelligents et le stockage, continue de s’étendre à mesure que de plus en plus de transactions sont traitées et que des contrats intelligents sont déployés. Depuis sa création, la taille de l’État a considérablement augmenté, avec des périodes de croissance accélérée dues à la congestion du réseau, à l’augmentation de l’activité transactionnelle et à l’essor de la finance décentralisée (DeFi) et des NFT. Actuellement, la croissance de l’État est d’environ 2,5 Go par mois, soit 30 Go par an.
Cette croissance de l'état peut entraîner les problèmes suivants :
– Temps d'accès plus lents au disque
– Exigences matérielles accrues
Cependant, au moment de la rédaction, aucun de ces problèmes n'est particulièrement significatif. En fait, la différence de temps d'accès entre les systèmes de stockage qui diffèrent de seulement quelques dizaines de gigaoctets est assez négligeable en raison de la complexité algorithmique des requêtes, qui est généralement logarithmique. Les besoins de stockage sont également insignifiants, car le coût du nouveau matériel diminue à un rythme bien supérieur à la croissance relativement faible de la taille de l'état de 30 Go par an. Même si elle était portée à 60 Go/an, la différence ne se démarquerait probablement pas et serait toujours dépassée par les progrès technologiques en matière de matériel de toute façon.
Cette augmentation de la taille de l’État est encore largement dépassée par le progrès technologique. Même si la limite de gaz devait doubler, le coût du matériel continue de diminuer de manière exponentielle, ce qui rend le matériel nécessaire moins cher au fil du temps.
Cependant, il convient de noter que bientôt, les stakers individuels auront besoin de plus de 2 To de stockage pour exécuter un validateur sur Ethereum. Cela augmentera effectivement l'exigence à 4 To de stockage, car la plupart du matériel est vendu par puissances de deux. Paradoxalement, cela signifie qu'Ethereum pourrait aussi bien utiliser le stockage supplémentaire, car les validateurs auraient déjà besoin d'investir dans du matériel de plus grande capacité, que la limite de gaz soit augmentée ou non.
REMARQUE: Il n'y a pas d'analyse moyenne par rapport au pire des cas sur le stockage car manipuler de manière cohérente des blocs pendant une période prolongée (semaines et mois) est une entreprise extrêmement coûteuse.
Pour justifier mes affirmations selon lesquelles le coût du stockage diminue à des taux exponentiels, nous pouvons examiner les fluctuations de prix en USD d'1 Go de SSD au cours des quatre dernières années :
Désolé pour la mauvaise qualité, mais la publication d'où je l'ai prise était comme ça
Il semble que tous les deux ans, le coût d'un Go de SSD a tendance à être divisé par deux.
Si nous comparons cela à la croissance du stockage et de l'état, la différence est négligeable. La croissance actuelle d'Ethereum est linéaire, tandis que les coûts matériels ont tendance à diminuer à un taux exponentiel.
J'ai trouvé un graphique plus révélateur sur cette tendance avec les coûts de stockage, mais il provient d'un message Reddit et non d'une publication scientifique réelle (bien que les résultats correspondent).
Le cas moyen de la bande passante dans Ethereum ressemble à environ 2 Mo/s ; cependant, la plupart de ce nombre provient des blocs CL qui bavardent et s'aggrègent. En ce qui concerne l'augmentation de la limite de gaz, la seule chose à regarder est la taille du bloc.
Actuellement, la taille maximale du bloc enregistrée est de 270 Ko, et la taille actuelle du bloc après Deneb est de 75 Ko. Si nous devions doubler cela, le changement serait équivalent à une augmentation de 0,5 à 2 blobs par rapport au maximum historique et à la moyenne actuelle, ce qui équivaudrait à une augmentation d'environ 2 à 5% de la bande passante du nœud (entrant et sortant). Ainsi, pour le cas moyen, ce n'est pas un changement significatif. En fait, trois blobs supplémentaires seraient bien plus dégradants.
Le pire scénario a été calculé à 1,7 Mo, ce qui deviendrait 3,4 Mo (+50 % de bande passante nécessaire pour le pic). Ce n’est pas grand-chose, mais c’est tout de même significatif. La raison pour laquelle je pense que ce n’est pas beaucoup, c’est qu’un tel DoS serait assez coûteux et que le pic serait de +50% des exigences moyennes actuelles, ce qui est déjà pris en compte. Comme je le disais, remplir des blocs d’une valeur de 15 millions de gaz à ras bord pendant de nombreux blocs successifs est très coûteux. Ainsi, même si un attaquant pourrait potentiellement lancer un DoS pour quelques blocs, il devrait dépenser une somme d’argent importante pour le faire. De plus, ils devraient rivaliser avec d’autres transactions pour entrer dans le bloc, ce qui rend cela encore plus coûteux.
Quoi qu'il en soit, indépendamment des opinions sur les chiffres, une augmentation du coût des données d'appel résoudrait complètement ce problème, donc je ne m'en inquiète pas dans tous les cas. De plus, si la limite de gas est augmentée grâce à EIP-7783, ces risques sont négligeables et maîtrisables.
Le calcul et les temps de blocage n'ont jamais été un problème au départ, mais nous y voilà.
Le cas moyen de calcul de bloc est généralement inférieur à 1 seconde, même pour les machines lentes avec des disques durs défectueux. Il n'y a pas grand-chose à discuter ici - en moyenne, cela n'a jamais été le goulot d'étranglement.
Le pire des cas semble peu clair et dépend du client. Après avoir discuté avec certaines équipes de clients, il semble que le consensus soit que le seul problème serait que certains opcodes ne s’adaptent pas bien (comme MODEXP).
Cependant, tous les vecteurs DoS ici peuvent être corrigés avec un nouveau tarif, et si l'augmentation de la limite de gas est effectuée avec EIP-7783, alors ces risques sont négligeables.
Dans l'ensemble, il semble que la croissance du stockage ne soit pas le goulot d'étranglement pour augmenter la limite de gas, car le matériel tel que le stockage est facile à mettre à niveau. Cependant, la bande passante pose une menace plus importante car elle est beaucoup plus difficile à mettre à l'échelle. Heureusement, avec l'EIP-7783, les risques liés à la bande passante et aux augmentations potentielles des calculs sont efficacement atténués. Néanmoins, il serait peut-être sage de revoir le coût des calldatas pour assurer une sécurité supplémentaire (bien que, selon moi, cela ne soit pas nécessaire).
À mon avis, il est actuellement possible d’augmenter la limite de gaz de 33% ou même de la doubler aujourd’hui si cela est fait avec l’augmentation progressive introduite EIP-7783.
Je pense qu’il est encore trop tôt pour le faire par le biais de l’EIP-7782, car ce serait punitif pour la TVP et la SSF. Cependant, une fois que ceux-ci sont compris, une diminution des temps de créneau est certainement due.