Nous utilisons deux méthodes de calcul pour évaluer la réduction possible des frais de gaz, les TPS (transactions par seconde) et la capacité à prendre en charge les Rollups après la mise en œuvre de l'EIP-4844.
On estime que l'EIP-4844 peut accueillir davantage de données d'appel, allant de 38 fois à 192 fois, avec des tailles de données d'appel de 10 Ko et 2 Ko respectivement. Étant donné que davantage de Calldata peuvent être hébergées dans le même bloc, le coût par unité de Calldata sera également réduit en conséquence.
En supposant que la taille des données d'appel de chaque cumul est uniformément de 2 Ko, EIP-4844 ne peut prendre en charge que 384 cumuls maximum.
Dans des circonstances normales (c'est-à-dire lorsque le bloc atteint la taille cible), Ethereum atteindra 175 TPS via EIP-4844, avec un maximum de 350.
**5. Contrairement à la croyance populaire, l’EIP-4844 à lui seul ne suffit pas à améliorer considérablement l’évolutivité d’Ethereum. **
L'utilisation de couches DA alternatives (telles que Celestia) ou DAC (telles que zkPorter), l'amélioration du taux de compression des données de transaction L2 et l'augmentation de la proportion de zk Rollups auront un impact important sur l'amélioration de l'évolutivité d'Ethereum.
Proto-danksharding (également connu sous le nom d'EIP-4844) propose d'implémenter la plupart de la logique et des règles que Danksharding pourrait utiliser à l'avenir. Actuellement, en raison du coût de stockage élevé sur L1, les frais de transition pour L2 sont également relativement élevés. Pour résoudre ce problème, EIP-4844 introduit un nouveau type de données Blob, moins cher et plus volumineux que les données d'appel, offrant ainsi un autre moyen de stockage de données cumulées.
Avec le lancement prochain de l'EIP-4844, les séquenceurs L2 pourraient devenir plus rentables. En effet, le séquenceur est responsable de l'importation des lots de transactions dans L1 et du paiement des frais de données, et les frais de données L1 payés par le séquenceur seront considérablement réduits. De faibles frais de transaction ont le potentiel de générer plus de MEV en augmentant le nombre de commandes sur L2.
La mise à niveau de Cancún inclura l'EIP-4844, mais il n'y a pas encore d'heure exacte pour la mise à niveau. L'équipe de recherche de la Fondation Ethereum a déclaré que la mise à niveau de Cancun pourrait être lancée fin octobre. Cependant, il est plus probable qu’il soit lancé vers le premier trimestre 2024.
**Alors, dans quelle mesure l'EIP-4844 peut-il réduire les frais de transaction ? **Actuellement, les frais de transaction L2 se composent principalement de deux parties :
**Coût cumulatif : **Le coût de conditionnement, de soumission et de stockage d'une transaction sur Ethereum.
**Coût d'exécution : **Le coût d'exécution d'une transaction sur L2
Frais de transaction L2 = Coûts de cumul + Coûts de mise en service
= [ Prix du gaz L1 * (données d'appel + frais généraux fixes) ] + [ Prix du gaz L2 * Gaz L2 utilisé ]
En prenant Optimism comme exemple, actuellement, près de 80 % du total des frais de transaction proviennent des coûts de stockage L1 (c'est-à-dire les coûts de Calldata). Nous ignorons pour l'instant l'impact des autres frais et proposons deux méthodes pour estimer dans quelle mesure les frais de transaction L2 peuvent être réduits après EIP-4844.
Dans EIP-4844, une fois la proposition mise en œuvre, la taille de chaque Blob est de 128 Ko et chaque Blob consomme 131 072 Gas. Par conséquent, en moyenne, chaque octet de données Blob consommera 128 * 1024/131, 072 = 1 Gas. En comparaison, le stockage actuel d’un seul octet de données d’appel consomme 16 gaz. Cela montre que le coût de stockage des transactions L2 sera réduit de 16 fois.
Cependant, cette méthode compare uniquement le coût de stockage par octet et ne prend pas en compte la capacité totale de gaz du bloc. Étant donné que la quantité totale de gaz qu'un seul bloc peut transporter peut changer après EIP-4844, les coûts de stockage des transactions L2 peuvent être réduits de plus de 16 fois.
La deuxième méthode prend en compte la taille du bloc et vérifie le nombre de fois où les données d'appel actuelles peuvent être hébergées sous différentes tailles de bloc. Selon les paramètres actuels, dans le scénario de taille de bloc cible, un bloc peut accueillir 3 blobs (0,375 Mo) et un maximum de 6 blobs (0,75 Mo). Considérant que les données d'appel de chaque bloc occupent actuellement environ 2 à 10 Ko, après EIP-4844, elles peuvent accueillir jusqu'à 0,75 * 1024/2 = 384 fois les données d'appel.
Cependant, à mesure que la taille du bloc augmente de la valeur cible à la valeur maximale, le prix du gaz augmente de façon exponentielle. Par conséquent, dans le cas le plus courant (c'est-à-dire lorsque le bloc atteint la taille cible), EIP-4844 peut accueillir 38 à 192 fois les données d'appel de 10 Ko et 2 Ko de données d'appel respectivement. ** À mesure que la capacité de Calldata au sein du bloc augmente, le coût de stockage de Calldata diminuera également en conséquence. Par conséquent, le coût des transactions L2 sera également réduit en conséquence.
De plus, en supposant que la taille des données d'appel de chaque cumul est uniformément de 2 Ko, EIP-4844 ne peut prendre en charge que 384 cumuls maximum. Cela n’atteint pas les milliers de cumuls que beaucoup de gens envisageaient.
Sur cette base, nous pouvons également déduire l’ordre de TPS qu’Ethereum peut atteindre après EIP-4844. Actuellement, une transaction L2 moyenne nécessite environ 3 000 données d’appels de gaz sur L1. Étant donné que Calldata a un coût de gaz de 16 par octet, cela indique que chaque transaction L2 sur L1 fait environ 187 octets.
Après EIP-4844, la taille de bloc cible est de 0,375 Mo et Ethereum génère un bloc toutes les 12 secondes. Par conséquent, l'espace disponible par seconde est de 0,375/12 * 1024 = 32 Ko, ce qui peut accueillir 32 * 1024/187 = 175 transactions. Par conséquent, dans des circonstances normales (c'est-à-dire lorsque le bloc atteint la taille cible), le TPS d'Ethereum après la mise à niveau EIP-4844 devrait être de 175, avec un maximum de 350.
Bien qu’un TPS plus élevé puisse améliorer l’efficacité, il convient de noter que même avec la mise en œuvre de l’EIP-4844, Ethereum n’est toujours pas aussi bon que Visa, qui a actuellement un TPS allant jusqu’à 1 700. Cet écart peut encore provoquer une congestion du réseau L1 et L2, en particulier dans les scénarios de forte demande.
**Par conséquent, l'EIP-4844 à lui seul ne suffit pas à permettre à Ethereum d'atteindre une plus grande évolutivité. **Nous avons toujours besoin d'une solution de disponibilité des données plus rentable et plus efficace pour stocker davantage de données d'appel (comme une couche DA comme Celestia ou un DAC comme zkPorter), qui sont toujours essentielles pour atteindre l'évolutivité.
Enfin, le taux de compression des transactions L2 affecte directement la taille des Calldata stockées dans L1. Plus le taux de compression est élevé, plus le coût L1 requis est faible. À mesure que zkRollup continue de se développer, la quantité de données devant être stockées sur L1 deviendra de moins en moins importante, ce qui sera également plus propice à l'amélioration de l'évolutivité d'Ethereum. Étant donné que zkRollup est différent de Optimistic Rollup, zkRollup n'a besoin que de stocker les changements d'état au lieu de l'intégralité de la transaction.
en conclusion
Dans cet article, nous utilisons deux méthodes de calcul différentes pour évaluer les réductions possibles des frais de gaz, des TPS (transactions par seconde) et la capacité à prendre en charge les cumuls après la mise en œuvre de l'EIP-4844. Les résultats montrent que, en supposant que la taille des données d'appel de chaque cumul est uniformément de 2 Ko, EIP-4844 ne peut prendre en charge que moins de 400 cumuls au maximum. On est loin de la demande de milliers de Rollups à laquelle beaucoup s’attendaient. L'utilisation de couches DA ou DAC alternatives, l'amélioration de la compression des données de transaction L2 et l'augmentation de la proportion de cumuls zk auront tous un impact significatif sur l'amélioration supplémentaire de l'évolutivité d'Ethereum.
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
Impact potentiel de l'EIP-4844 : dans quelle mesure peut-il améliorer l'évolutivité et réduire les frais de transaction ?
Auteur original : 0x fan, Smarti Lab
Compilation originale : Peng SUN, Foresight News
TL;DR：
Nous utilisons deux méthodes de calcul pour évaluer la réduction possible des frais de gaz, les TPS (transactions par seconde) et la capacité à prendre en charge les Rollups après la mise en œuvre de l'EIP-4844.
On estime que l'EIP-4844 peut accueillir davantage de données d'appel, allant de 38 fois à 192 fois, avec des tailles de données d'appel de 10 Ko et 2 Ko respectivement. Étant donné que davantage de Calldata peuvent être hébergées dans le même bloc, le coût par unité de Calldata sera également réduit en conséquence.
En supposant que la taille des données d'appel de chaque cumul est uniformément de 2 Ko, EIP-4844 ne peut prendre en charge que 384 cumuls maximum.
Dans des circonstances normales (c'est-à-dire lorsque le bloc atteint la taille cible), Ethereum atteindra 175 TPS via EIP-4844, avec un maximum de 350.
**5. Contrairement à la croyance populaire, l’EIP-4844 à lui seul ne suffit pas à améliorer considérablement l’évolutivité d’Ethereum. **
Proto-danksharding (également connu sous le nom d'EIP-4844) propose d'implémenter la plupart de la logique et des règles que Danksharding pourrait utiliser à l'avenir. Actuellement, en raison du coût de stockage élevé sur L1, les frais de transition pour L2 sont également relativement élevés. Pour résoudre ce problème, EIP-4844 introduit un nouveau type de données Blob, moins cher et plus volumineux que les données d'appel, offrant ainsi un autre moyen de stockage de données cumulées.
Avec le lancement prochain de l'EIP-4844, les séquenceurs L2 pourraient devenir plus rentables. En effet, le séquenceur est responsable de l'importation des lots de transactions dans L1 et du paiement des frais de données, et les frais de données L1 payés par le séquenceur seront considérablement réduits. De faibles frais de transaction ont le potentiel de générer plus de MEV en augmentant le nombre de commandes sur L2.
La mise à niveau de Cancún inclura l'EIP-4844, mais il n'y a pas encore d'heure exacte pour la mise à niveau. L'équipe de recherche de la Fondation Ethereum a déclaré que la mise à niveau de Cancun pourrait être lancée fin octobre. Cependant, il est plus probable qu’il soit lancé vers le premier trimestre 2024.
**Alors, dans quelle mesure l'EIP-4844 peut-il réduire les frais de transaction ? **Actuellement, les frais de transaction L2 se composent principalement de deux parties :
En prenant Optimism comme exemple, actuellement, près de 80 % du total des frais de transaction proviennent des coûts de stockage L1 (c'est-à-dire les coûts de Calldata). Nous ignorons pour l'instant l'impact des autres frais et proposons deux méthodes pour estimer dans quelle mesure les frais de transaction L2 peuvent être réduits après EIP-4844.
Dans EIP-4844, une fois la proposition mise en œuvre, la taille de chaque Blob est de 128 Ko et chaque Blob consomme 131 072 Gas. Par conséquent, en moyenne, chaque octet de données Blob consommera 128 * 1024/131, 072 = 1 Gas. En comparaison, le stockage actuel d’un seul octet de données d’appel consomme 16 gaz. Cela montre que le coût de stockage des transactions L2 sera réduit de 16 fois.
Cependant, cette méthode compare uniquement le coût de stockage par octet et ne prend pas en compte la capacité totale de gaz du bloc. Étant donné que la quantité totale de gaz qu'un seul bloc peut transporter peut changer après EIP-4844, les coûts de stockage des transactions L2 peuvent être réduits de plus de 16 fois.
La deuxième méthode prend en compte la taille du bloc et vérifie le nombre de fois où les données d'appel actuelles peuvent être hébergées sous différentes tailles de bloc. Selon les paramètres actuels, dans le scénario de taille de bloc cible, un bloc peut accueillir 3 blobs (0,375 Mo) et un maximum de 6 blobs (0,75 Mo). Considérant que les données d'appel de chaque bloc occupent actuellement environ 2 à 10 Ko, après EIP-4844, elles peuvent accueillir jusqu'à 0,75 * 1024/2 = 384 fois les données d'appel.
Cependant, à mesure que la taille du bloc augmente de la valeur cible à la valeur maximale, le prix du gaz augmente de façon exponentielle. Par conséquent, dans le cas le plus courant (c'est-à-dire lorsque le bloc atteint la taille cible), EIP-4844 peut accueillir 38 à 192 fois les données d'appel de 10 Ko et 2 Ko de données d'appel respectivement. ** À mesure que la capacité de Calldata au sein du bloc augmente, le coût de stockage de Calldata diminuera également en conséquence. Par conséquent, le coût des transactions L2 sera également réduit en conséquence.
De plus, en supposant que la taille des données d'appel de chaque cumul est uniformément de 2 Ko, EIP-4844 ne peut prendre en charge que 384 cumuls maximum. Cela n’atteint pas les milliers de cumuls que beaucoup de gens envisageaient.
Sur cette base, nous pouvons également déduire l’ordre de TPS qu’Ethereum peut atteindre après EIP-4844. Actuellement, une transaction L2 moyenne nécessite environ 3 000 données d’appels de gaz sur L1. Étant donné que Calldata a un coût de gaz de 16 par octet, cela indique que chaque transaction L2 sur L1 fait environ 187 octets.
Après EIP-4844, la taille de bloc cible est de 0,375 Mo et Ethereum génère un bloc toutes les 12 secondes. Par conséquent, l'espace disponible par seconde est de 0,375/12 * 1024 = 32 Ko, ce qui peut accueillir 32 * 1024/187 = 175 transactions. Par conséquent, dans des circonstances normales (c'est-à-dire lorsque le bloc atteint la taille cible), le TPS d'Ethereum après la mise à niveau EIP-4844 devrait être de 175, avec un maximum de 350.
Bien qu’un TPS plus élevé puisse améliorer l’efficacité, il convient de noter que même avec la mise en œuvre de l’EIP-4844, Ethereum n’est toujours pas aussi bon que Visa, qui a actuellement un TPS allant jusqu’à 1 700. Cet écart peut encore provoquer une congestion du réseau L1 et L2, en particulier dans les scénarios de forte demande.
**Par conséquent, l'EIP-4844 à lui seul ne suffit pas à permettre à Ethereum d'atteindre une plus grande évolutivité. **Nous avons toujours besoin d'une solution de disponibilité des données plus rentable et plus efficace pour stocker davantage de données d'appel (comme une couche DA comme Celestia ou un DAC comme zkPorter), qui sont toujours essentielles pour atteindre l'évolutivité.
Enfin, le taux de compression des transactions L2 affecte directement la taille des Calldata stockées dans L1. Plus le taux de compression est élevé, plus le coût L1 requis est faible. À mesure que zkRollup continue de se développer, la quantité de données devant être stockées sur L1 deviendra de moins en moins importante, ce qui sera également plus propice à l'amélioration de l'évolutivité d'Ethereum. Étant donné que zkRollup est différent de Optimistic Rollup, zkRollup n'a besoin que de stocker les changements d'état au lieu de l'intégralité de la transaction.
en conclusion
Dans cet article, nous utilisons deux méthodes de calcul différentes pour évaluer les réductions possibles des frais de gaz, des TPS (transactions par seconde) et la capacité à prendre en charge les cumuls après la mise en œuvre de l'EIP-4844. Les résultats montrent que, en supposant que la taille des données d'appel de chaque cumul est uniformément de 2 Ko, EIP-4844 ne peut prendre en charge que moins de 400 cumuls au maximum. On est loin de la demande de milliers de Rollups à laquelle beaucoup s’attendaient. L'utilisation de couches DA ou DAC alternatives, l'amélioration de la compression des données de transaction L2 et l'augmentation de la proportion de cumuls zk auront tous un impact significatif sur l'amélioration supplémentaire de l'évolutivité d'Ethereum.