Fusaka, la dernière mise à jour d’Ethereum, est opérationnelle sur le réseau depuis le 3 décembre. Avec lui, cet écosystème a reçu sa deuxième fourchette dure (hard fork) de l’année, après Pectra en mai.
Comme le rapporte CriptoNoticias, la proposition connue sous le nom de PeerDAS est l’amélioration la plus pertinente de Fusaka et a apporté au réseau quelque chose que Vitalik Buterin lui-même attendait depuis 2015.
PeerDAS introduit un système pour vérifier la disponibilité des données en échantillonnant entre les nœuds. Au lieu que chaque nœud doive télécharger tous les blobs complet (espace où les réseaux de deuxième couche stockent les informations), ne demande désormais que de petits échantillons aléatoires à différents pairs.
Le graphique ci-dessous, pris quelques heures après la libération de Fusaka, reflète PeerDAS fonctionnant comme prévu:
Sur l’image, un nœud situé en Finlande (« tysm ») demande au réseau certaines colonnes de données correspondant à blobs utilisé par Base et Arbitrum.
Ce nœud particulier n’a pas ces échantillons stockés, donc le message « MANQUANT » apparaît. C’est normal dans PeerDAS : les nœuds n’ont plus besoin de sauvegarder toutes les données pour vérifier leur disponibilité.
Plutôt, le nœud consulte d’autres pairs (dans ce cas, un nœud à Taiwan). Ces pairs disposent de ces colonnes et les envoient en moins d’une demi-seconde.
De cette façon, le réseau confirme que les données associées sont disponiblesmême lorsqu’ils ne sont pas entièrement répliqués sur chaque nœud.
Ce comportement reflète exactement l’objectif de PeerDAS sur Ethereum : réduire la charge sur le stockage individuel tout en garantissant que les informations restent accessibles à ceux qui en ont besoin.
Les réseaux Ethereum de deuxième couche publient plus de données sous la forme de blobs
Le graphique suivant « Nombre moyen de Blob par bloc » (moyenne de blobs par bloc) montre le évolution du nombre moyen de blobs par bloc.
La ligne noire s’élève autour du « 4 » (axe de gauche) jusqu’à s’approcher de la cible marquée « 6 » blobs par bloc (horizon horizontal).
Cela indique qu’après Fusaka, le réseau a commencé à utiliser plus d’espace blobs dans les blocs, se rapprochant de l’objectif défini pour ce paramètre.
En termes simples : Les L2 ont commencé à publier davantage de données sous la forme de blobset PeerDAS commence à exercer son rôle de contrôle de cette augmentation du trafic.
Pourquoi est-ce utile pour la L2 ? Parce qu’en partageant et en répartissant la charge sur de nombreux nœuds, le système permet aux couches deux de publier plus de données sans compter sur chaque nœud Ethereum pour tout télécharger et tout vérifier entièrement.
Cela réduit les coûts d’exploitation, améliore la rapidité de traitement des lots et permet L2 continue d’évoluer sans imposer une charge croissante sur le réseau de base.
De plus, ce que montre ce graphique n’est que le début d’une séquence planifiée d’expansions, donc cet effet augmentera à l’avenir.
À partir de la proposition EIP-7892, qui propose une série de mises à jour progressives ajustant exclusivement la limite de des gouttes, Le 9 décembre, un fourchette quoi augmentera l’objectif actuel de blobs de 6 à 10et le 7 janvier de l’année prochaine un autre fourchette Cela vous prendra de 10h à 14h.
Taux blobs: le pic et la correction après Fusaka
Quelques heures avant l’arrivée de Fusaka, la chaîne a enregistré un pic abrupt dans le frais de blobs les frais que les L2 paient pour publier leurs données sur Ethereum en utilisant le des gouttes.
Selon le graphique suivant, ces frais ont atteint environ 1 463 gwei (unité minimale d’éther utilisée pour exprimer les frais dans Ethereum), équivalent à environ 0,0047 dollars actuellement :
Jusqu’à l’intégration de Fusaka, l’étage du frais de blobs C’était pratiquement symbolique. Le minimum possible a été fixé à 0,000000001 Gwei et y est resté bloqué tant qu’il n’y avait pas de congestion.
Ce plancher statique menait au L2 publiera des données sur Ethereum presque gratuitement 99% du tempsmême lorsque leur activité générait un coût réel pour le réseau.
Avec l’activation de Fusaka et notamment de l’EIP-7918, ce tarif « plancher » du blobs Il a cessé d’être réparé et On est passé à un système dynamique lié au coût réel de fonctionnement en L1.
La salle des commissions du blobs se tenait autour d’un seizième (1/16) des frais de base Ethereumselon le texte de l’EIP-7918.
C’est ce que propose le sol dynamique du frais de blobs Visage Tra :
Compte tenu des niveaux habituels d’utilisation d’Ethereum, le système établi par EIP-7918 place le minimum de frais de blobs dans des valeurs généralement comprises entre 0,01 et 0,5 gwei (c’est-à-dire entre des dizaines et des centaines de millions de fois ci-dessus de l’ancien minimum de 1 wei). Contrairement au schéma précédent, il ne peut plus descendre à zéro.
De plus, ce nouveau taux plancher a un effet direct sur l’économie d’Ethereum : en facturant un minimum réaliste pour blobsle réseau cesse de subventionner sa vérification et Cela commence à générer plus de revenus grâce aux commissions.
En revanche, et pour l’utilisateur final, l’impact est quasiment imperceptible : les commissions en L2 sont encore très faibles, car ces coûts ils sont dilués entre des millions de transactions.
Limite de gaz par bloc : plus de capacité de données
À partir d’EIP-7935, après Fusaka, les clients Ethereum fonctionnent par défaut avec une limite de gaz par bloc de 60 millions. Cela implique une croissance de 100 % par rapport aux 30 millions qui utilisaient le réseau début 2025.
La « limite de gaz » définit la quantité de travail de calcul ou d’espace de transaction qui peut être incluse dans un bloc. Hormis Fusaka, la limite de gaz est une mesure convenue par les validateurs et peut être augmentée ou abaissée.
L’augmenter à 60 millions permet de conserver davantage de transactions par bloc, ce qui permet au réseau de supporter plus facilement une charge plus importante sans congestion immédiate.
Le logiciel de consensus Ethereum s’est écrasé après Fusaka
Finalement, quelques heures après la mise en ligne de Fusaka, le client de consensus Prysm (l’un des programmes utilisés par les nœuds pour coordonner la chaîne) a subi une panne. Il a lui-même quitté temporairement hors-jeu à propos 23% du réseau.
D’après ce qu’ils ont communiqué depuis Prysm, il n’y a aucune indication que l’échec a été causé par Fusaka.
L’équipe Prysm a identifié le problème et publié un correctif simple que n’importe quel opérateur pouvait implémenter en quelques minutes en ajoutant une ligne de code à son nœud, sans avoir besoin de télécharger une nouvelle version.
Grâce à cela, le réseau a continué à fonctionner sans conséquences majeures.