Le « changement de vitesse continu » dans la mise à niveau Fusaka d’Ethereum : établir un mécanisme de réponse rapide pour le scaling L2

Le futur d’Ethereum ressemblera à l’installation d’une « transmission à variation continue » : l’extension du nombre de Blobs ne sera plus liée à une mise à jour majeure.

Auteur : Zhixiong Pan

Contexte : la mise à niveau du Gas Limit sans hard fork

Avant la mise à niveau Fusaka, la grande majorité des paramètres centraux du protocole Ethereum (tels que la récompense de bloc, l’algorithme d’ajustement de la difficulté, etc.) étaient « codés en dur » dans le logiciel client. Cela signifiait que, même pour modifier une simple valeur, il fallait passer par une longue proposition EIP, des tests sur le réseau de test, puis coordonner tous les nœuds du réseau pour un hard fork à grande échelle, un processus qui prenait généralement six mois ou plus.

Avant cela, la seule exception dans le protocole Ethereum était le Block Gas Limit (la limite de Gas par bloc). Le Gas Limit n’était pas déterminé par un hard fork, mais permettait aux validateurs d’ajuster légèrement la limite lors de la création des blocs via un algorithme (par exemple, cette année, de 30M à 60M). Ce mécanisme conférait une certaine flexibilité au réseau.

L’apparition de l’EIP-7892, BPO (Blob Parameter Only), vise précisément à étendre cette flexibilité au domaine des données. Elle rend les paramètres clés du Blob configurables, et les applique via un BPO, un « hard fork léger » qui ne modifie que les paramètres sans toucher au code. Du point de vue du développement client, cela ressemble presque à une mise à jour à chaud des paramètres.

Cela permet à Ethereum de se libérer du rythme « à chaque modification du nombre de Blobs, il faut attendre le prochain hard fork majeur » pour l’extension, et d’ajuster les paramètres plus fréquemment via de petits forks BPO.

Pourquoi le nombre de Blobs est-il si important ? 

L’objet principal de cet ajustement est le Blob. Depuis la mise à niveau Cancun (Dencun), la plupart des Rollups n’écrivent plus la majorité de leurs données de transaction dans le calldata coûteux, mais les migrent vers le Blob, une « zone de montage temporaire des données » dédiée.

La logique économique du Blob est très simple : le Blob est une ressource rare, et le nombre de Blobs pouvant être montés par bloc est limité. Son prix dépend de l’offre et de la demande : lorsque la demande du Layer 2 dépasse l’offre, le prix unitaire du Blob augmente, ce qui rend les frais sur L2 plus élevés.

Ainsi, dans la mesure où la sécurité est garantie, augmenter autant que possible la limite supérieure du nombre de Blobs est le moyen le plus direct de réduire les coûts pour les utilisateurs L2.

Paramètres clés : le mécanisme Target et Max

Dans le plan d’ajustement BPO, on observe deux chiffres apparaissant en paire (par exemple 10/15). Il s’agit de deux seuils clés définis selon le mécanisme de l’EIP-4844 :

Target (valeur cible) : le « régulateur » des frais 

Il s’agit de la charge idéale définie par Ethereum. Le système ajuste dynamiquement les frais de base (Base Fee) du Blob en fonction de cette valeur. Si l’utilisation réelle > Target, les frais augmentent pour freiner la demande ; si l’utilisation réelle < Target, les frais baissent.

Elle détermine la capacité de traitement et la référence tarifaire du réseau en conditions normales.

Max (valeur maximale) : le « disjoncteur » de sécurité 

Il s’agit de la limite physique stricte fixée pour éviter la paralysie du réseau. Quelle que soit la demande, le protocole impose que le nombre de Blobs par bloc ne dépasse pas cette valeur, afin d’éviter que les nœuds ne tombent en panne ou se déconnectent à cause d’un volume de données trop important à traiter.

C’est le plafond ultime de la capacité du réseau.

Par ailleurs, depuis Pectra, les paramètres blob du mainnet suivent essentiellement le modèle « Max = 1,5 × Target » : 6/9, 10/15, 14/21, tous selon ce ratio.

Feuille de route de la mise à niveau : pourquoi Fusaka opte-t-il pour une approche « progressive » ? 

Cette extension ne sera pas réalisée d’un seul coup le 3 décembre (UTC+8), mais adopte une stratégie rigoureuse en trois étapes : « d’abord déployer la technologie, puis libérer la capacité ».

Première étape : déploiement de la mise à niveau Fusaka (3 décembre (UTC+8))

État des paramètres : Target : 6 / Max : 9 (identique à la version précédente de Pectra, sans changement).

La mise à niveau Fusaka active PeerDAS (Data Availability Sampling), une technologie clé. Bien que la capacité technique à traiter plus de données soit acquise, les développeurs choisissent, par sécurité, de ne pas augmenter la charge du réseau le premier jour de la mise à niveau. Il s’agit d’une « période d’observation de sécurité » destinée à vérifier la stabilité du mécanisme PeerDAS sous le trafic actuel.

Deuxième étape : BPO 1 (prévu le 9 décembre (UTC+8))

Ajustement des paramètres : Target : 10 / Max : 15

Après environ une semaine de fonctionnement stable de PeerDAS, une première mise à jour à chaud est effectuée via le mécanisme BPO. La valeur cible passe de 6 à 10. Il s’agit de la première extension substantielle du cycle Fusaka.

Troisième étape : BPO 2 (prévu le 7 janvier 2026 (UTC+8))

Ajustement des paramètres : Target : 14 / Max : 21

Après un mois de tests de résistance approfondis, une deuxième mise à jour à chaud est effectuée. Par rapport au lancement de Fusaka, la capacité est multipliée par 2,3 (6 → 14). Cela marque la réalisation complète du plan d’extension.

Résumé

L’introduction du BPO est une étape majeure. Elle rompt avec l’ancien paradigme « chaque extension de Blob nécessite un hard fork fonctionnel majeur », et divise l’extension en une série de mini hard forks ne modifiant que les paramètres.

Cela signifie que le futur d’Ethereum ressemblera à l’installation d’une « transmission à variation continue » : l’extension du nombre de Blobs ne sera plus liée à une mise à jour majeure, mais pourra être planifiée régulièrement (BPO3, BPO4, etc.) en fonction des besoins des L2 et des performances des clients, optimisant le débit par de petits hard forks rapprochés, au lieu d’attendre plusieurs années entre chaque modification.