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 lorsque la taille des données d'appel est respectivement de 10 Ko et 2 Ko, l'EIP-4844 peut accueillir plus de données d'appel, allant de 38 fois à 192 fois. É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 accueillir que jusqu'à 384 cumuls.
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.
**Contrairement à la croyance populaire, l'EIP-4844 à lui seul ne suffit pas à Ethereum pour améliorer considérablement son évolutivité. **
L'utilisation de couches DA alternatives (telles que Celestia) ou de DAC (tels 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 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 (ution) : 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 gaz. 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). Étant donné que les données d'appel actuelles de chaque bloc occupent environ 2 à 10 Ko, après EIP-4844, elles peuvent accueillir jusqu'à 0,75 * 1024/2 = 384 fois de 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), l'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 dans le 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'augmentation du taux de 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.
Économie du roll-up : l'impact de l'EIP-4844 sur l'évolutivité est surestimé
Auteur : 0xfan, Smarti Lab ; Compilateur : Peng SUN, Foresight News
TL;DR：
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 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 gaz. 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). Étant donné que les données d'appel actuelles de chaque bloc occupent environ 2 à 10 Ko, après EIP-4844, elles peuvent accueillir jusqu'à 0,75 * 1024/2 = 384 fois de 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), l'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 dans le 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'augmentation du taux de 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.