La baisse surprenante de l'utilisation d'Ethereum suggère que le réseau a résolu le mauvais problème avec la mise à niveau Fusaka

Source : CryptoNewsNet Titre original : La baisse surprenante de l’utilisation d’Ethereum suggère que le réseau a résolu le mauvais problème avec la mise à jour Fusaka Lien original : Ethereum a activé la mise à jour Fusaka le 3 décembre 2025, augmentant la capacité de disponibilité des données du réseau via des Blob Parameter Overrides qui ont progressivement étendu les cibles et plafonds des blobs.

Deux ajustements successifs ont porté la cible de 6 blobs par bloc à 10, puis à 14, avec un plafond maximum de 21. L’objectif était de réduire les coûts des rollups de couche 2 en augmentant le débit pour les données en blob, les lots de transactions compressés que les rollups publient sur Ethereum pour la sécurité et la finalité.

Trois mois après la collecte des données, les résultats révèlent un écart entre capacité et utilisation. Une analyse de MigaLabs de plus de 750 000 slots depuis l’activation de Fusaka montre que le réseau n’atteint pas le nombre cible de 14 blobs.

L’utilisation médiane des blobs a en fait diminué après le premier ajustement de paramètre, et les blocs contenant 16 blobs ou plus présentent des taux de misses élevés, suggérant une dégradation de la fiabilité aux limites de la nouvelle capacité.

La conclusion du rapport est claire : aucune augmentation supplémentaire du paramètre blob jusqu’à ce que les taux de misses élevés se normalisent et que la demande pour la marge déjà créée se matérialise.

Ce que Fusaka a changé et quand cela s’est produit

Le baseline pré-Fusaka d’Ethereum, établi par l’EIP-7691, fixait la cible à 6 blobs par bloc avec un maximum de 9. La mise à jour Fusaka a introduit deux ajustements séquentiels du Blob Parameter Override.

Le premier a été activé le 9 décembre, portant la cible à 10 et le maximum à 15. Le second a été activé le 7 janvier 2026, portant la cible à 14 et le maximum à 21.

Ces changements n’ont pas nécessité de hard forks, et le mécanisme permet à Ethereum d’ajuster la capacité via la coordination des clients plutôt que par des mises à jour au niveau du protocole.

L’analyse de MigaLabs, qui a publié un code reproductible et une méthodologie, a suivi l’utilisation des blobs et la performance du réseau durant cette transition.

Elle a constaté que le nombre médian de blobs par bloc est passé de 6 avant le premier override à 4 après, malgré l’expansion de la capacité du réseau. Les blocs contenant 16 blobs ou plus restent extrêmement rares, apparaissant entre 165 et 259 fois chacun durant la période d’observation, selon le nombre spécifique de blobs.

Le réseau dispose d’une marge qu’il n’utilise pas.

Une divergence de paramètre : le texte de la chronologie du rapport décrit le premier override comme portant la cible de 6 à 12, mais l’annonce de la Fondation Ethereum sur le mainnet et la documentation des clients décrivent l’ajustement comme passant de 6 à 10.

Nous utilisons comme source les paramètres de la Fondation Ethereum : 6/9 en baseline, 10/15 après le premier override, 14/21 après le second. Néanmoins, nous considérons le jeu de données du rapport pour l’utilisation observée et les patterns de taux de misses comme la base empirique.

Les taux de misses augmentent à haute quantité de blobs

La fiabilité du réseau, mesurée par les slots manqués, c’est-à-dire les blocs qui ne se propagent pas ou n’attestent pas correctement, montre un schéma clair.

À faibles quantités de blobs, le taux de misses de référence tourne autour de 0,5 %. Dès que les blocs atteignent 16 blobs ou plus, les taux de misses montent à 0,77 % à 1,79 %. À 21 blobs, la capacité maximale introduite lors du second override, le taux de misses atteint 1,79 %, soit plus de trois fois le taux de référence.

L’analyse décompose cela selon le nombre de blobs, de 10 à 21, montrant une courbe de dégradation progressive qui s’accélère au-delà de la cible de 14 blobs.

Cette dégradation est importante car elle suggère que l’infrastructure du réseau, comme le matériel des validateurs, la bande passante du réseau et le timing des attestations, a du mal à gérer les blocs en haut de la capacité.

Si la demande finit par augmenter pour remplir la cible de 14 blobs ou pousser vers le maximum de 21 blobs, les taux de misses élevés pourraient entraîner des retards significatifs de finalité ou un risque de réorganisation. Le rapport présente cela comme une limite de stabilité : le réseau peut techniquement traiter des blocs à haute quantité de blobs, mais le faire de manière cohérente et fiable reste une question ouverte.

Économie des blobs : pourquoi le seuil de prix de réserve est important

Fusaka n’a pas seulement étendu la capacité. Elle a aussi modifié la tarification des blobs via l’EIP-7918, qui introduit un seuil de prix de réserve pour empêcher les enchères de blobs de s’effondrer à 1 wei.

Avant ce changement, lorsque les coûts d’exécution dominaient et que la demande de blobs restait faible, la fee de base des blobs pouvait spiraler à la baisse jusqu’à disparaître en tant que signal de prix. Les rollups de couche 2 paient des frais de blobs pour publier leurs données de transaction sur Ethereum, et ces frais doivent refléter les coûts computationnels et réseau que les blobs imposent.

Lorsque les frais tombent près de zéro, la boucle de rétroaction économique se brise, et les rollups consomment la capacité sans payer en proportion. Cela entraîne une perte de visibilité du réseau sur la demande réelle.

Le seuil de prix de réserve de l’EIP-7918 lie les frais de blobs aux coûts d’exécution, garantissant qu’en cas de demande faible, le prix reste un signal significatif.

Cela évite le problème du free-rider où des blobs bon marché encouragent un usage excessif et fournit des données plus claires pour les décisions futures de capacité : si les frais de blobs restent élevés malgré l’augmentation de la capacité, la demande est authentique ; si ils s’effondrent au seuil, il existe une marge.

Les premières données du tableau de bord Dune de Hildobby, qui suit les blobs d’Ethereum, montrent que les frais de blobs se sont stabilisés après Fusaka plutôt que de continuer la spirale descendante observée dans les périodes antérieures.

Le nombre moyen de blobs par bloc confirme la conclusion de MigaLabs : l’utilisation n’a pas explosé pour remplir la nouvelle capacité. Les blocs portent régulièrement moins que la cible de 14 blobs, et la distribution reste fortement biaisée vers des counts plus faibles.

Ce que révèlent les données sur l’efficacité

Fusaka a réussi à augmenter la capacité technique et à prouver que le mécanisme de Blob Parameter Override fonctionne sans nécessiter de hard forks contestés.

Le seuil de prix de réserve semble fonctionner comme prévu, empêchant les frais de blobs de devenir économiquement insignifiants. Mais l’utilisation reste en deçà de la capacité, et la fiabilité aux limites de la nouvelle capacité montre une dégradation mesurable.

La courbe du taux de misses suggère que l’infrastructure actuelle d’Ethereum gère confortablement le baseline pré-Fusaka et les paramètres 10/15 du premier override, mais commence à peiner au-delà de 16 blobs.

Cela crée un profil de risque : si l’activité de couche 2 augmente et pousse régulièrement les blocs vers le maximum de 21 blobs, le réseau pourrait faire face à des taux de misses élevés qui compromettent la finalité et la résistance aux réorganisations.

Les patterns de demande donnent une autre indication. La baisse de l’utilisation médiane des blobs après le premier override, malgré l’augmentation de la capacité, suggère que les rollups de couche 2 ne sont pas actuellement limités par la disponibilité des blobs.

Soit leur volume de transactions n’a pas suffisamment augmenté pour nécessiter plus de blobs par bloc, soit ils optimisent la compression et le batching pour rester dans la capacité existante plutôt que d’étendre leur usage.

Blobscan, un explorateur dédié aux blobs, montre que les rollups individuels publient des counts de blobs relativement constants dans le temps plutôt que d’augmenter pour exploiter la nouvelle marge.

L’inquiétude avant Fusaka était que la capacité limitée des blobs serait un goulot d’étranglement pour la scalabilité de Layer 2 et maintiendrait les frais de rollup élevés en raison de la concurrence pour la disponibilité des données. Fusaka a résolu cette contrainte de capacité, mais le goulot d’étranglement semble avoir changé.

Les rollups ne remplissent pas l’espace disponible, ce qui signifie que soit la demande n’est pas encore arrivée, soit d’autres facteurs, comme l’économie des séquenceurs, l’activité des utilisateurs et la fragmentation entre rollups, limitent la croissance plus que la disponibilité des blobs.

Ce qui vient ensuite

La feuille de route d’Ethereum inclut PeerDAS, une refonte plus fondamentale de l’échantillonnage de disponibilité des données qui permettrait d’étendre encore la capacité des blobs tout en améliorant la décentralisation et la sécurité.

Cependant, les résultats de Fusaka suggèrent que la capacité brute n’est pas la contrainte principale pour l’instant.

Le réseau a encore de la marge pour atteindre les paramètres 14/21 avant qu’une nouvelle expansion ne soit nécessaire, et la courbe de fiabilité à haute quantité de blobs indique que des améliorations de l’infrastructure pourraient devoir précéder de nouvelles augmentations de capacité.

Les données sur le taux de misses donnent une limite claire. Si Ethereum pousse la capacité plus haut alors que les blocs à 16+ blobs montrent encore des taux de misses élevés, cela pourrait introduire une instabilité systémique susceptible d’émerger lors de pics de demande.

Le chemin le plus sûr est de laisser l’utilisation augmenter vers la cible actuelle, de surveiller si les taux de misses s’améliorent à mesure que les clients optimisent la gestion de charges plus importantes, et d’ajuster les paramètres uniquement lorsque le réseau pourra gérer de manière fiable les cas limites.

L’efficacité de Fusaka dépend de cette métrique. Elle a réussi à augmenter la capacité et à stabiliser le prix des blobs via le seuil de réserve. Elle n’a pas entraîné d’augmentation immédiate de l’utilisation ni résolu les défis de fiabilité à pleine capacité.

La mise à jour a créé une marge pour la croissance future, mais la question de savoir si cette croissance se matérialisera reste ouverte, la donnée n’ayant pas encore répondu.