Analyse approfondie de l'ère post-Upgrade de Cancun : Perspectives sur les données et l'investissement
Introduction
Depuis son lancement officiel le 30 juillet 2015, Ethereum a connu 12 mises à niveau, chacune ayant attiré une grande attention.
La mise à niveau Ethereum Cancun-Deneb (, également connue sous le nom de mise à niveau Dencun ), a pour principaux objectifs d'améliorer l'évolutivité et la modularité des réseaux Layer 2, de renforcer les fonctionnalités de sécurité du réseau Ethereum et d'améliorer l'utilisabilité globale.
1. Qu'est-ce que la mise à niveau Dencun ?
1.1 Introduction à la mise à niveau
1.1.1 Origine du nom
La couche de base d'Ethereum est composée de deux parties fusionnées, à savoir la couche d'exécution et la couche de consensus, chacune ayant des règles de nommage différentes.
La règle de nommage des mises à niveau de la couche d'exécution est depuis 2021 nommée d'après les villes accueillant Devcon (la conférence des développeurs Ethereum). Par exemple, mise à niveau Berlin, mise à niveau Londres, mise à niveau Shanghai, etc.
La règle de nommage des mises à niveau de la couche de consensus est basée sur des noms d'astres depuis le lancement de la chaîne de balises, en suivant l'ordre alphabétique. Par exemple, Altair (Aldebaran), Bellatrix (Betelgeuse) et Capella (Capricorne) etc.
Chaque mise à niveau d'Ethereum est nommée en combinant deux noms de mise à niveau différents pour former un nom de mise à niveau global. Étant donné que cette Devcon se tient à Cancun, au Mexique, et que la mise à niveau de la couche de consensus est Deneb, cette mise à niveau d'Ethereum est donc abrégée en mise à niveau Dencun.
1.1.2 Contexte de la mise à niveau
Le contexte de la mise à niveau de Dencun est d'une part un plan à long terme basé sur le développement d'Ethereum, et d'autre part, l'objectif principal est d'améliorer l'expérience d'Ethereum, pour finalement réaliser un écosystème sans autorisation, décentralisé, résistant à la censure et open source.
D'un côté, le plan publié par le fondateur d'Ethereum, Vitalik Buterin, le 31 décembre 2023, indique que la mise à niveau Dencun correspond à une partie de The Surge, mettant l'accent sur l'expérience utilisateur (par exemple, en améliorant la vitesse des transactions et en réduisant les frais de Gas), avec pour objectif d'améliorer l'efficacité du réseau, de réduire les coûts des transactions et de poser des bases solides pour le développement futur.
D'autre part, dans l'article publié par Vitalik Buterin le 28 décembre 2023 intitulé « Make Ethereum Cypherpunk Again », Vitalik estime que l'une des raisons principales qui limite de plus en plus la blockchain à la spéculation sur les actifs est la hausse des frais de transaction, ce qui fait des Degen Gamblers un groupe dominant, nuisant à la réalisation de la valeur d'application de la blockchain. Par conséquent, il est nécessaire de réduire les frais de transaction.
1.1.3 Temps de mise à jour
Selon le plan d'Ethereum, les informations sur le temps de mise à niveau et d'activation sont :
Hauteur du bloc de mise à niveau de la couche d'exécution : 18,963,249
Époque de la couche de consensus : 269,568
Date prévue : 13 mars 2024 (heure UTC)
1.1.4 Contenu concerné
Les mises à niveau Cancun-Deneb d'Ethereum ont apporté une série d'améliorations à la fois au niveau d'exécution (EL) et au niveau de consensus (CL). Cancun a perfectionné le niveau d'exécution, tandis que Deneb a renforcé le niveau de consensus, et a intégré une série de propositions d'amélioration d'Ethereum (EIP) qui sont cruciales pour le développement du réseau Ethereum. Au total, il y a 9 EIP, et nous introduirons les EIP clés dans les prochaines sections.
1.2 Les points clés de la mise à niveau de Dencun
1.2.1 EIP-4844 Transactions Blob de fragmentation (Proto-Danksharding)
EIP-4844 est le principal atout de cette mise à niveau, visant à réduire les frais de transaction, à augmenter le volume de transactions par seconde (TPS) et à améliorer l'évolutivité. En essence, il s'agit d'une mise à niveau transitoire préparant l'avenir pour réaliser un Danksharding complet (la dernière partie de la mise à niveau "Calme" d'Ethereum), le Proto-Danksharding posant les bases pour le Danksharding.
La disponibilité des données sur la chaîne principale d'Ethereum est fournie par le Calldata (qui peut être compris comme les données générées lors d'un appel de transaction de contrat), et les données renvoyées de la couche 2 à la couche 1 sont toutes stockées dans le Calldata. De plus, par souci de sécurité, chaque étape d'exécution du Calldata nécessite des frais de Gas, ce qui entraîne des coûts de Gas relativement élevés. Cependant, une fois les données de transaction dans le Calldata vérifiées, elles n'ont en réalité pas beaucoup d'utilité, car des données anciennes peuvent être téléchargées et vérifiées et même ne pas avoir besoin d'être transmises à la couche d'exécution. En prenant l'exemple de la composition historique des frais de transaction moyens de la chaîne Layer2-OP, on peut voir que près de 80 % des frais proviennent des frais de données de L1.
Ainsi, l'EIP-4844 introduit une nouvelle structure de stockage de données - le Blob, spécialement conçu pour stocker les données de transaction soumises par L2 à L1. Après son introduction, les données de transaction L2 sont directement soumises au Blob pour être stockées, pouvant être complètement téléchargées par les nœuds de consensus, et pouvant être supprimées après un court délai, réduisant ainsi la charge de stockage inutile. Cela signifie que l'introduction du Blob réduira considérablement les frais de transaction de L2. En même temps, le Blob équivaut également à une extension supplémentaire de l'espace de bloc pour L2, tandis que le débit des transactions L2 augmentera également de manière significative.
1.2.2 EIP-1153 OpCode de stockage transitoire
L'objectif principal de l'EIP-1153 est d'économiser de l'espace de stockage et des coûts de stockage. Le stockage transitoire est rejeté après chaque transaction, donc le stockage temporaire est moins cher car il ne nécessite pas d'accès au disque.
EIP-1153 est plus convivial pour les développeurs de Dapp, introduisant de nouveaux codes d'opération TSTORE et TLOAD dans l'EVM, dont le coût en Gas pour les appeler est d'environ 100 Gas chacun, soit 95 % moins cher que les appels de stockage traditionnels (SLOAD et SSTORE). De plus, une fois la transaction complète exécutée, cette partie du stockage sera effacée, réduisant ainsi les coûts de stockage et la consommation de Gas, ce qui pourrait à l'avenir permettre à de nouveaux contrats DeFi d'économiser davantage de Gas.
1.2.3 EIP-4788 racine de bloc de balise dans l'EVM
EIP-4788 permettra la communication entre l'EVM (Machine Virtuelle Ethereum) et la chaîne de balises (Beacon). Cette fonctionnalité prend en charge divers cas d'utilisation, pouvant améliorer les pools de staking, les constructions de restaking, les ponts de contrats intelligents, le MEV, etc.
Auparavant, l'EVM ne pouvait pas accéder directement aux données et à l'état de Beacon, il devait se fier à des oracles externes de confiance pour capturer l'état. Il a donc été proposé de placer une racine de bloc Beacon parent (parent_beacon_block_root) dans chaque bloc EVM, de sorte que lorsqu'il y a une mise à jour de Beacon, l'EVM puisse immédiatement obtenir des informations précises.
Le racine du bloc de signalisation parent sera stockée dans un tampon circulaire, ne conservant que pendant environ 1 jour. Une fois qu'un nouveau racine de bloc de signalisation parent entre et que la capacité du tampon atteint un seuil critique, le racine de bloc de signalisation parent le plus ancien sera remplacé, permettant ainsi un stockage de consensus efficace et limité. Cela permet d'atteindre une communication de manière minimisée sur la confiance, tout en éliminant les pannes des oracles externes et les risques malveillants, augmentant ainsi la sécurité.
1.2.4 EIP-5656 MCOPY - Instruction de copie de mémoire
EIP-5656 optimise le coût du processus de copie de zones de mémoire en introduisant une nouvelle instruction EVM MCOPY, ce qui améliore l'efficacité du déplacement des données dans l'EVM.
La copie de mémoire est une opération fondamentale, mais sa mise en œuvre sur l'EVM entraîne des coûts. Prenons l'exemple de la copie de données de mémoire de 256 octets, les développeurs peuvent réduire le coût de 96 Gas (en utilisant MLOAD et MSTORE) à seulement 27 Gas grâce à l'opcode MCOPY. On s'attend à ce que la plupart des développeurs utilisent MCOPY à la place de MSTORE/MLOAD à l'avenir, et des contrats Gas plus efficaces bénéficieront finalement aux utilisateurs finaux.
MCOPY comble en même temps le vide dans les méthodes de copie de mémoire dans l'EVM.
1.2.5 EIP-6780 SELFDESTRUCT uniquement dans la même transaction
EIP-6780 limite la fonction de l'opcode SELFDESTRUCT, la nouvelle fonctionnalité ne fait que transférer tous les fonds du compte vers la cible, mais n'affecte pas le code, le stockage et d'autres informations, tout en préparant également la mise à niveau ultérieure de l'arbre Verkle.
Avant l'EIP-6780, si le code de contrat faisait référence à l'opcode SELFDESTRUCT, les fonds pouvaient être envoyés à la destination, mais le code, le stockage et d'autres informations seraient supprimés. Cependant, cette fonctionnalité pouvait engendrer des dangers et des conséquences inattendues. Après l'EIP-6780, tout cela ne sera plus affecté, les développeurs pourront mieux gérer leurs projets, permettant ainsi d'atteindre une blockchain plus stable et prévisible.
2. Impact sur les données après la mise à niveau
2.1 L'impact des frais de gaz
La modification la plus essentielle de cette mise à niveau, et celle qui préoccupe le plus tout le monde, est sans aucun doute le changement des frais de Gas. Grâce à l'introduction de l'EIP-4844, les Layer 2 en bénéficient le plus, avec une réduction très significative des frais de Gas, ce qui améliore l'expérience utilisateur. Cela correspond essentiellement à l'attente d'une réduction de 90 % des frais de Layer 2 avant la mise à niveau.
Quant à Layer1 (Ethereum lui-même), les frais de Gas ont légèrement diminué après la mise à jour, mais pas de manière significative ; les utilisateurs ne ressentent en réalité aucun changement dans leur utilisation quotidienne.
2.2 Impact du volume des transactions
L'upgrade vise non seulement à réduire le Gas, mais aussi à améliorer le débit, ce qui est également un point clé du plan de développement de l'extension d'Ethereum.
Après la mise à niveau, le volume de transactions de Base a d'abord explosé, franchissant l'ancienne limite, passant de 500 000 à 2 millions, ce qui signifie que l'EIP-4844 a eu un impact direct sur cela, et les bénéfices sont également les plus évidents.
Impact de 2.3 TPS
L'optimisation du TPS (transactions par seconde) signifie que les développeurs disposent d'une plus grande flexibilité lors de la construction et du déploiement de dApps, ce qui devrait donner naissance à des applications plus complexes et riches en données, attirant ainsi un public plus large.
Après la mise à niveau, le TPS de chaque Layer2 a généralement augmenté, mais ne dépasse pas 30 transactions par seconde.
Le faible TPS est un phénomène courant dans l'industrie Web3 actuelle, contrairement aux caractéristiques de haut TPS de l'industrie traditionnelle Web2. Le TPS maximal de Layer2 n'a pas non plus dépassé 500, mais d'un point de vue de développement industriel, cette mise à niveau pose également les bases pour l'avenir, tout en répondant aux attentes de développement d'Ethereum ------ atteindre un TPS de 100 000+.
Utilisation de Blob 2.4
La principale raison de la baisse globale des frais de transaction Layer2 est l'introduction du type Blob. Plus il y a de Blobs en attente dans les transactions, plus le débit global sera élevé, ce qui jettera également les bases pour les futures mises à niveau d'Ethereum.
Au départ, on s'attendait à ce que, si un objectif moyen de 3 Blob par bloc était atteint, le débit de L2 augmenterait d'environ 2 fois. Si l'objectif final de 64 Blob par bloc était atteint, le débit de L2 augmenterait d'environ 40 fois. La mise à niveau actuelle fixe la limite maximale à 6 Blob.
D'après la situation actuelle, le Blob a commencé à être utilisé dans les transactions, mais le taux d'utilisation global n'est pas très élevé, le pic étant également survenu juste après la mise à niveau. Par la suite, il a progressivement diminué et n'a pas encore atteint l'objectif moyen estimé de 3 Blobs.
Cependant, l'introduction du type Blob améliore réellement les frais de données de Layer2 sur Layer1. Comme le montre l'exemple de la chaîne OP mentionné ci-dessus, on peut constater de manière intuitive que les frais de données utilisés par L1 dans les frais de transaction moyens de Layer2 sont considérablement réduits, presque éliminés. Cela laisse également supposer, d'un autre point de vue, que la marge bénéficiaire de Layer2 pourrait augmenter.
Le modèle de profit de L2 est relativement simple et clair, et peut être résumé comme suit : profit en chaîne = frais de transaction L2 - coût de paiement L1 ; prenons l'exemple de la chaîne OP, bien que la mise à niveau ait réduit à la fois les frais de transaction L2 et le coût de paiement L1, en raison de l'augmentation du volume de transactions et de la base d'utilisateurs, la diminution des deux n'est pas du tout au même ordre de grandeur. Les frais de transaction sont passés de plusieurs centaines de milliers à plusieurs dizaines de milliers, tandis que le coût de paiement est passé de plusieurs centaines de milliers à moins de 1k, le profit en chaîne a également augmenté après la mise à niveau.
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.
Nouveau paysage de l'écosystème Ethereum après la mise à niveau de Cancun : les frais de transaction L2 chutent de 90 %
Analyse approfondie de l'ère post-Upgrade de Cancun : Perspectives sur les données et l'investissement
Introduction
Depuis son lancement officiel le 30 juillet 2015, Ethereum a connu 12 mises à niveau, chacune ayant attiré une grande attention.
La mise à niveau Ethereum Cancun-Deneb (, également connue sous le nom de mise à niveau Dencun ), a pour principaux objectifs d'améliorer l'évolutivité et la modularité des réseaux Layer 2, de renforcer les fonctionnalités de sécurité du réseau Ethereum et d'améliorer l'utilisabilité globale.
1. Qu'est-ce que la mise à niveau Dencun ?
1.1 Introduction à la mise à niveau
1.1.1 Origine du nom
La couche de base d'Ethereum est composée de deux parties fusionnées, à savoir la couche d'exécution et la couche de consensus, chacune ayant des règles de nommage différentes.
La règle de nommage des mises à niveau de la couche d'exécution est depuis 2021 nommée d'après les villes accueillant Devcon (la conférence des développeurs Ethereum). Par exemple, mise à niveau Berlin, mise à niveau Londres, mise à niveau Shanghai, etc.
La règle de nommage des mises à niveau de la couche de consensus est basée sur des noms d'astres depuis le lancement de la chaîne de balises, en suivant l'ordre alphabétique. Par exemple, Altair (Aldebaran), Bellatrix (Betelgeuse) et Capella (Capricorne) etc.
Chaque mise à niveau d'Ethereum est nommée en combinant deux noms de mise à niveau différents pour former un nom de mise à niveau global. Étant donné que cette Devcon se tient à Cancun, au Mexique, et que la mise à niveau de la couche de consensus est Deneb, cette mise à niveau d'Ethereum est donc abrégée en mise à niveau Dencun.
1.1.2 Contexte de la mise à niveau
Le contexte de la mise à niveau de Dencun est d'une part un plan à long terme basé sur le développement d'Ethereum, et d'autre part, l'objectif principal est d'améliorer l'expérience d'Ethereum, pour finalement réaliser un écosystème sans autorisation, décentralisé, résistant à la censure et open source.
D'un côté, le plan publié par le fondateur d'Ethereum, Vitalik Buterin, le 31 décembre 2023, indique que la mise à niveau Dencun correspond à une partie de The Surge, mettant l'accent sur l'expérience utilisateur (par exemple, en améliorant la vitesse des transactions et en réduisant les frais de Gas), avec pour objectif d'améliorer l'efficacité du réseau, de réduire les coûts des transactions et de poser des bases solides pour le développement futur.
D'autre part, dans l'article publié par Vitalik Buterin le 28 décembre 2023 intitulé « Make Ethereum Cypherpunk Again », Vitalik estime que l'une des raisons principales qui limite de plus en plus la blockchain à la spéculation sur les actifs est la hausse des frais de transaction, ce qui fait des Degen Gamblers un groupe dominant, nuisant à la réalisation de la valeur d'application de la blockchain. Par conséquent, il est nécessaire de réduire les frais de transaction.
1.1.3 Temps de mise à jour
Selon le plan d'Ethereum, les informations sur le temps de mise à niveau et d'activation sont :
1.1.4 Contenu concerné
Les mises à niveau Cancun-Deneb d'Ethereum ont apporté une série d'améliorations à la fois au niveau d'exécution (EL) et au niveau de consensus (CL). Cancun a perfectionné le niveau d'exécution, tandis que Deneb a renforcé le niveau de consensus, et a intégré une série de propositions d'amélioration d'Ethereum (EIP) qui sont cruciales pour le développement du réseau Ethereum. Au total, il y a 9 EIP, et nous introduirons les EIP clés dans les prochaines sections.
1.2 Les points clés de la mise à niveau de Dencun
1.2.1 EIP-4844 Transactions Blob de fragmentation (Proto-Danksharding)
EIP-4844 est le principal atout de cette mise à niveau, visant à réduire les frais de transaction, à augmenter le volume de transactions par seconde (TPS) et à améliorer l'évolutivité. En essence, il s'agit d'une mise à niveau transitoire préparant l'avenir pour réaliser un Danksharding complet (la dernière partie de la mise à niveau "Calme" d'Ethereum), le Proto-Danksharding posant les bases pour le Danksharding.
La disponibilité des données sur la chaîne principale d'Ethereum est fournie par le Calldata (qui peut être compris comme les données générées lors d'un appel de transaction de contrat), et les données renvoyées de la couche 2 à la couche 1 sont toutes stockées dans le Calldata. De plus, par souci de sécurité, chaque étape d'exécution du Calldata nécessite des frais de Gas, ce qui entraîne des coûts de Gas relativement élevés. Cependant, une fois les données de transaction dans le Calldata vérifiées, elles n'ont en réalité pas beaucoup d'utilité, car des données anciennes peuvent être téléchargées et vérifiées et même ne pas avoir besoin d'être transmises à la couche d'exécution. En prenant l'exemple de la composition historique des frais de transaction moyens de la chaîne Layer2-OP, on peut voir que près de 80 % des frais proviennent des frais de données de L1.
Ainsi, l'EIP-4844 introduit une nouvelle structure de stockage de données - le Blob, spécialement conçu pour stocker les données de transaction soumises par L2 à L1. Après son introduction, les données de transaction L2 sont directement soumises au Blob pour être stockées, pouvant être complètement téléchargées par les nœuds de consensus, et pouvant être supprimées après un court délai, réduisant ainsi la charge de stockage inutile. Cela signifie que l'introduction du Blob réduira considérablement les frais de transaction de L2. En même temps, le Blob équivaut également à une extension supplémentaire de l'espace de bloc pour L2, tandis que le débit des transactions L2 augmentera également de manière significative.
1.2.2 EIP-1153 OpCode de stockage transitoire
L'objectif principal de l'EIP-1153 est d'économiser de l'espace de stockage et des coûts de stockage. Le stockage transitoire est rejeté après chaque transaction, donc le stockage temporaire est moins cher car il ne nécessite pas d'accès au disque.
EIP-1153 est plus convivial pour les développeurs de Dapp, introduisant de nouveaux codes d'opération TSTORE et TLOAD dans l'EVM, dont le coût en Gas pour les appeler est d'environ 100 Gas chacun, soit 95 % moins cher que les appels de stockage traditionnels (SLOAD et SSTORE). De plus, une fois la transaction complète exécutée, cette partie du stockage sera effacée, réduisant ainsi les coûts de stockage et la consommation de Gas, ce qui pourrait à l'avenir permettre à de nouveaux contrats DeFi d'économiser davantage de Gas.
1.2.3 EIP-4788 racine de bloc de balise dans l'EVM
EIP-4788 permettra la communication entre l'EVM (Machine Virtuelle Ethereum) et la chaîne de balises (Beacon). Cette fonctionnalité prend en charge divers cas d'utilisation, pouvant améliorer les pools de staking, les constructions de restaking, les ponts de contrats intelligents, le MEV, etc.
Auparavant, l'EVM ne pouvait pas accéder directement aux données et à l'état de Beacon, il devait se fier à des oracles externes de confiance pour capturer l'état. Il a donc été proposé de placer une racine de bloc Beacon parent (parent_beacon_block_root) dans chaque bloc EVM, de sorte que lorsqu'il y a une mise à jour de Beacon, l'EVM puisse immédiatement obtenir des informations précises.
Le racine du bloc de signalisation parent sera stockée dans un tampon circulaire, ne conservant que pendant environ 1 jour. Une fois qu'un nouveau racine de bloc de signalisation parent entre et que la capacité du tampon atteint un seuil critique, le racine de bloc de signalisation parent le plus ancien sera remplacé, permettant ainsi un stockage de consensus efficace et limité. Cela permet d'atteindre une communication de manière minimisée sur la confiance, tout en éliminant les pannes des oracles externes et les risques malveillants, augmentant ainsi la sécurité.
1.2.4 EIP-5656 MCOPY - Instruction de copie de mémoire
EIP-5656 optimise le coût du processus de copie de zones de mémoire en introduisant une nouvelle instruction EVM MCOPY, ce qui améliore l'efficacité du déplacement des données dans l'EVM.
La copie de mémoire est une opération fondamentale, mais sa mise en œuvre sur l'EVM entraîne des coûts. Prenons l'exemple de la copie de données de mémoire de 256 octets, les développeurs peuvent réduire le coût de 96 Gas (en utilisant MLOAD et MSTORE) à seulement 27 Gas grâce à l'opcode MCOPY. On s'attend à ce que la plupart des développeurs utilisent MCOPY à la place de MSTORE/MLOAD à l'avenir, et des contrats Gas plus efficaces bénéficieront finalement aux utilisateurs finaux.
MCOPY comble en même temps le vide dans les méthodes de copie de mémoire dans l'EVM.
1.2.5 EIP-6780 SELFDESTRUCT uniquement dans la même transaction
EIP-6780 limite la fonction de l'opcode SELFDESTRUCT, la nouvelle fonctionnalité ne fait que transférer tous les fonds du compte vers la cible, mais n'affecte pas le code, le stockage et d'autres informations, tout en préparant également la mise à niveau ultérieure de l'arbre Verkle.
Avant l'EIP-6780, si le code de contrat faisait référence à l'opcode SELFDESTRUCT, les fonds pouvaient être envoyés à la destination, mais le code, le stockage et d'autres informations seraient supprimés. Cependant, cette fonctionnalité pouvait engendrer des dangers et des conséquences inattendues. Après l'EIP-6780, tout cela ne sera plus affecté, les développeurs pourront mieux gérer leurs projets, permettant ainsi d'atteindre une blockchain plus stable et prévisible.
2. Impact sur les données après la mise à niveau
2.1 L'impact des frais de gaz
La modification la plus essentielle de cette mise à niveau, et celle qui préoccupe le plus tout le monde, est sans aucun doute le changement des frais de Gas. Grâce à l'introduction de l'EIP-4844, les Layer 2 en bénéficient le plus, avec une réduction très significative des frais de Gas, ce qui améliore l'expérience utilisateur. Cela correspond essentiellement à l'attente d'une réduction de 90 % des frais de Layer 2 avant la mise à niveau.
Quant à Layer1 (Ethereum lui-même), les frais de Gas ont légèrement diminué après la mise à jour, mais pas de manière significative ; les utilisateurs ne ressentent en réalité aucun changement dans leur utilisation quotidienne.
2.2 Impact du volume des transactions
L'upgrade vise non seulement à réduire le Gas, mais aussi à améliorer le débit, ce qui est également un point clé du plan de développement de l'extension d'Ethereum.
Après la mise à niveau, le volume de transactions de Base a d'abord explosé, franchissant l'ancienne limite, passant de 500 000 à 2 millions, ce qui signifie que l'EIP-4844 a eu un impact direct sur cela, et les bénéfices sont également les plus évidents.
Impact de 2.3 TPS
L'optimisation du TPS (transactions par seconde) signifie que les développeurs disposent d'une plus grande flexibilité lors de la construction et du déploiement de dApps, ce qui devrait donner naissance à des applications plus complexes et riches en données, attirant ainsi un public plus large.
Après la mise à niveau, le TPS de chaque Layer2 a généralement augmenté, mais ne dépasse pas 30 transactions par seconde.
Le faible TPS est un phénomène courant dans l'industrie Web3 actuelle, contrairement aux caractéristiques de haut TPS de l'industrie traditionnelle Web2. Le TPS maximal de Layer2 n'a pas non plus dépassé 500, mais d'un point de vue de développement industriel, cette mise à niveau pose également les bases pour l'avenir, tout en répondant aux attentes de développement d'Ethereum ------ atteindre un TPS de 100 000+.
Utilisation de Blob 2.4
La principale raison de la baisse globale des frais de transaction Layer2 est l'introduction du type Blob. Plus il y a de Blobs en attente dans les transactions, plus le débit global sera élevé, ce qui jettera également les bases pour les futures mises à niveau d'Ethereum.
Au départ, on s'attendait à ce que, si un objectif moyen de 3 Blob par bloc était atteint, le débit de L2 augmenterait d'environ 2 fois. Si l'objectif final de 64 Blob par bloc était atteint, le débit de L2 augmenterait d'environ 40 fois. La mise à niveau actuelle fixe la limite maximale à 6 Blob.
D'après la situation actuelle, le Blob a commencé à être utilisé dans les transactions, mais le taux d'utilisation global n'est pas très élevé, le pic étant également survenu juste après la mise à niveau. Par la suite, il a progressivement diminué et n'a pas encore atteint l'objectif moyen estimé de 3 Blobs.
Cependant, l'introduction du type Blob améliore réellement les frais de données de Layer2 sur Layer1. Comme le montre l'exemple de la chaîne OP mentionné ci-dessus, on peut constater de manière intuitive que les frais de données utilisés par L1 dans les frais de transaction moyens de Layer2 sont considérablement réduits, presque éliminés. Cela laisse également supposer, d'un autre point de vue, que la marge bénéficiaire de Layer2 pourrait augmenter.
Le modèle de profit de L2 est relativement simple et clair, et peut être résumé comme suit : profit en chaîne = frais de transaction L2 - coût de paiement L1 ; prenons l'exemple de la chaîne OP, bien que la mise à niveau ait réduit à la fois les frais de transaction L2 et le coût de paiement L1, en raison de l'augmentation du volume de transactions et de la base d'utilisateurs, la diminution des deux n'est pas du tout au même ordre de grandeur. Les frais de transaction sont passés de plusieurs centaines de milliers à plusieurs dizaines de milliers, tandis que le coût de paiement est passé de plusieurs centaines de milliers à moins de 1k, le profit en chaîne a également augmenté après la mise à niveau.
2,5 impact sur le prix
Pour cette mise à niveau