Les développeurs d’Ethereum Core sont en train de régler le moteur d’exécution du protocole pour un débit et une flexibilité plus élevés avant la prochaine fourche Fusaka. Sur l’appel des développeurs All Core du 19 juin, les contributeurs se sont alignés sur un lot d’EIP pour l’inclusion dans DevNet-2 et ont mis à niveau des performances plus agressives pour un Pulsive DevNet-3 (à confirmer).
Le résultat est une mise à niveau étroitement portée mais techniquement significative, concentrée non pas tant sur les nouvelles fonctionnalités, mais sur des optimisations. Lorsque nous avons couvert Fusaka en avril, c’était encore une fusion quelque peu pâteuse d’idées: une augmentation de la limite de gaz provisoire, des discussions précoces sur les correctifs des frais de blob et les questions non résolues autour des limites de taille du contrat. Deux mois plus tard, la fourche s’est durcie dans un package clair.
Les développeurs se sont désormais engagés dans un plafond de 45 millions de gaz, une soumission BLOB plafonnée par transaction, une limite de contrat de 48 Ko rationalisée (EIP-7907) plus un tout nouveau OPCode (EIP-7939) en CLZ (pour «compter les zéros en tête»). Des paramètres controversés auparavant comme le plancher des frais Blob (EIP-7918) ont été réglés, préparant la voie de DevNet-2 lundi.
Commençons par l’augmentation de la limite de gaz, qui est déjà sous les tests et ne faisait pas strictement faire partie de Fusaka. Ce changement, en cas de succès, pourrait augmenter la capacité de transaction d’Ethereum de plus de 11%, mais nécessite une analyse comparative prudente. Les développeurs ont signalé la nécessité de maintenir la propagation des blocs dans des latences sûres en tant que variable clé à surveiller.
« Tous les clients semblent être d’accord pour aller de l’avant avec 45 millions une fois les sorties terminées », a déclaré le Call Parithosh Jayanthi (communément appelé «Pari»).
Parallèlement au débit de débit, les développeurs affinent comment les données blob – introduites avec EIP-4844 pendant la mise à niveau Dencun – seront gérées. Bien que 4844 permette la disponibilité des données hors chaîne moins chaine, cela ne limitait pas le nombre de blobs qu’une seule transaction pourrait inclure. L’EIP-7892 comble cet écart, le plafonnement par utilisation du blob par transaction pour empêcher un seul rouleau ou DAPP de monopoliser le blobspace. Pendant ce temps, l’EIP-7918 définit un plancher de base et plafonne le nombre total de blobs par bloc, un mouvement pour équilibrer l’évolutivité et la sécurité du réseau, a expliqué Ben Adams de l’équipe client de Nethermind.
« Mettre une limite inférieure à la taille maximale des blobs signifie que vous pouvez inclure plus de blobs – paradoxalement », a déclaré Adams.
Sans étage, les frais de base blob peuvent tomber à près de zéro pendant une faible demande, conduisant à une utilisation inefficace de l’espace de bloc.
EIP-7939, qui introduit un OPCode CLZ à l’EVM. Cela peut sembler obscur, mais c’est le type d’outil que les développeurs d’alimentation atteignent lors de la réduction des performances ou de faire des choses intelligentes avec des aléances ou des preuves. La plupart des machines virtuelles modernes l’ont déjà, et maintenant Ethereum le fera aussi. Une niche mais pratique pour l’ergonomie du développeur, avec un impact consensuel minimal.
EIP-7951 est également à noter, le précompilé tant attendu pour SECP256R1 – un type de courbe cryptographique utilisée dans les signatures numériques. Son inclusion débloquera la prise en charge native des clés couramment utilisées dans les plates-formes mobiles et d’entreprise – y compris l’authentification basée sur la WebAuthn – rapprochant ainsi Ethereum à un pas de l’intégration sans faille et sécurisée.
