Image créée avec IA
Avec un rallye d’ETH à son comble, l’équipe de développement d’Ethereum travaille sur Fusaka : un redémarrage du réseau qui rationalisera le moteur d’exécution de la blockchain pour une capacité de traitement et une flexibilité encore plus élevées.
Ce qui a débuté par une série d’idées parfois contradictoires s’est solidifié pour devenir un ensemble clair d’améliorations : un plafond plus élevé sur les frais de gaz, des limites sur le nombre de blocs de données par transaction, et de nouvelles façons de connecter la finance décentralisée (DeFi) au commerce électronique traditionnel.
Tout cela se traduit par un réseau plus rapide qui utilise l’espace de bloc de manière plus efficace, rapprochant ainsi Ethereum de l’intégration hors ligne transparente.
Excellence incrémentielle
Début 2025, Fusaka n’était qu’une collection désordonnée d’idées. Des EIP (propositions d’améliorations Ethereum) étaient en cours de rédaction pour aborder une augmentation de la limite de gaz, régler les frais de blocs de données et répondre aux questions ouvertes concernant la taille des smart contracts.
Au lieu de lancer une série de nouvelles fonctionnalités, la fondation Ethereum a opté pour des ajustements, mais le package cumulatif est important.
Les plus grandes améliorations sont les suivantes :
Plus de capacité de transaction par bloc
Le plus grand changement dans Fusaka est probablement un nouveau plafond de gaz maximal de 45 millions d’unités, qui offre la possibilité d’augmenter la capacité de transaction par bloc.
La limite de gaz d’Ethereum fixe un plafond sur la quantité d’effort de calcul qu’une transaction unique peut consommer. Il s’agit d’un paramètre réseau critique, qui définit les limites de la quantité de calcul que peut utiliser un bloc lors de l’exécution de smart contracts ou du traitement des transactions.
Exprimée en unités de gaz, la nouvelle limite est un outil de gestion du trafic délibérément mis en place par Ethereum. Elle aide à éviter les goulets d’étranglement en limitant la complexité cumulée des opérations incluses dans chaque bloc.
Si ce changement est effectué, il pourrait augmenter la capacité de transaction du réseau Ethereum de ~11%, bien que les développeurs estiment qu’il est nécessaire de surveiller et de comparer la propagation des blocs sur différentes latences. Sans faire explicitement partie de Fusaka, la fondation a déclaré lors de l’appel du 19 juin que ce changement avait été validé par tous les clients.
Parithosh Jayanthi, membre de l’équipe de DevOps de la fondation Ethereum, a déclaré : “Une fois les publications terminées, tous les clients semblent satisfaits de passer à une limite de gaz de 45 millions”.
Nouvelles limites de blocs de données
Les développeurs d’Ethereum envisagent également de nouvelles manières de gérer les données de blocs. L’année dernière, l’ajout de blocs de données lors de la mise à jour de Dencun a permis de réduire les coûts de disponibilité des données hors ligne, mais n’a pas limité le nombre de blocs de données pouvant être inclus dans une seule transaction.
L’EIP-7892 de Fusaka clarifie ce problème, en limitant l’utilisation de blocs par transaction pour éviter qu’une seule application décentralisée (dApp) ou un rollup n’utilise trop l’espace de données disponible.
Un autre ajustement, appelé EIP-7918, impose une limite supérieure sur le nombre total de blocs de données par bloc, en plus d’établir des frais de base minimum. Ces changements synergiques sont utiles pour maintenir l’équilibre entre la scalabilité et la sécurité du réseau. Sans limite inférieure, pendant les périodes d’activité faible, les frais de blocs de données peuvent chuter à environ zéro, ce qui signifie que l’espace de bloc est utilisé de manière efficace.
Un nouvel opcode CLZ
Une autre optimisation qui a peu fait parler d’elle dans Devnet-2 est l’EIP-7939, qui ajoute un opcode de comptage des zéros de tête (CLZ) à la machine virtuelle Ethereum (EVM), l’environnement d’exécution des smart contracts.
Cette correction très technique aidera les développeurs à calculer plus efficacement le nombre de zéros consécutifs au début d’un nombre binaire, quelque chose de crucial pour la cryptographie, la compression de données et les opérations qui manipulent les données au niveau du bit.
L’EVM actuel n’a pas d’opcode CLZ dédié, ce qui oblige les développeurs à implémenter CLZ à l’aide de plusieurs opérations.
Un changement connexe sous EIP-7951 permettrait des connexions directes sur chaîne vers des plateformes mobiles et d’entreprise via une authentification de sécurité Web2 standard. Cela rapprocherait Ethereum de l’intégration hors ligne transparente avec le monde Web2.
Réaction de la communauté
La portée plus ciblée de Fusaka a fait l’objet de critiques de la part des parties prenantes d’Ethereum.
Dans un post sur X qui a été visionné 84 000 fois, Georgios Konstantopoulos, CTO chez Paradigm, a exprimé sa frustration quant au fait de retarder une solution à l’erreur de “pile trop profonde” et à la limite de 24 Ko pour la taille du bytecode d’un smart contract, deux problèmes fréquemment cités par les développeurs EVM.
Le post a suscité un long fil de discussion et au moins une réfutation de la part d’un développeur Prysm anonyme, Potuz, qui a noté qu’une autre mise à jour planifiée appelée EVM object format (EOF) visait à résoudre ces problèmes, bien que ce soit maintenant prévu pour une mise à jour post-Fusaka.
Le retard pris pour EOF semble être dû aux objections des parties prenantes du réseau. Les critiques font valoir que le changement tel qu’il est actuellement pensé est surconçu et pourrait ajouter de la complexité au système de smart contracts déjà difficile à manipuler.
Dans un post sur le portail communautaire Ethereum Magicians, le développeur Pascal Caversaccio s’est inquiété du fait que la proposition EOF pourrait encombrer le réseau avec “des changements inutiles”, en particulier deux nouvelles sémantiques (qui définissent comment les smart contracts sont écrits et exécutés), tout en supprimant et remplaçant plus d’une douzaine d’opcodes.
Il a déclaré que l’erreur de pile trop profonde, le bytecode et d’autres problèmes pourraient être résolus de manière incrémentielle dans le cadre de “mises à jour moins invasives”. Tel qu’il est actuellement, EOF pourrait également nécessiter une mise à jour des outils, risquant de provoquer l’arrivée de nouvelles exploitations de failles à cause d’une surface d’attaque élargie.
Les préoccupations de Caversaccio ont été reprises dans un sondage sur ETHPulse, qui a révélé que près de 40 votants, détenant environ 17 750 ETH au total, s’opposaient également à la mise à jour. Au 2 juillet 2025, seuls huit détenteurs d’ETH ont voté en faveur du changement.
La conclusion
Malgré certaines réserves de la communauté et le manque de fonctionnalités importantes, Fusaka pourrait marquer une étape importante dans l’effort de la fondation pour améliorer les performances de son réseau. La fourchette vise à optimiser de manière précise, sans fanfare ni perturbation technologique.
Avec la mise à jour de mai, Pectra, qui est maintenant un lointain souvenir, Fusaka vise à renforcer l’efficacité et à rapprocher le réseau de l’intégration avec le monde Web2.
Des performances accrues sans risque inutile. L’approche modérée d’Ethereum est une progression soigneuse vers la prochaine phase de maturité technique.
Avis de non-responsabilité de Benzinga : Cet article a été écrit par un contributeur externe non rémunéré. Il ne représente pas les rapports de Benzinga et n’a pas été modifié pour son contenu ou sa précision.