TechFlow – Le développeur principal d’Ethereum, Tim Beiko, a résumé la dernière réunion d’exécution des développeurs principaux d’Ethereum (ACDE). Lors de cette réunion, des mises à jour sur Devnet et Dencun ont été présentées, ainsi qu’un aperçu complet de Reth :
1. Mise à jour sur l’état de Devnet-8 : le réseau est en cours de finalisation, et plusieurs clients ont commencé à y déployer de nouvelles mises à jour. Des tests avec Kurtosis, un système d’outils pour développeurs, ont également commencé afin d’évaluer les flux MEV et de construction de blocs. Nethermind a indiqué que son pool de transactions blob était prêt ; après quelques jours de tests sur un nœud unique, il a été déployé sur tous les nœuds de test Dencun. Le pool de blobs de Geth est quant à lui presque terminé. Besu effectue une refonte plus large de son pool de transactions (afin de limiter la taille combinée des transactions blob et non-blob), dont la sortie est prévue pour la prochaine version. Erigon continue de développer son propre pool et espère être prêt pour devnet-9.
2. La réunion a poursuivi les discussions de la précédente conférence téléphonique ACDC concernant l’ajout d’une limite constante à la file d’activation des validateurs. Cette proposition a désormais été officiellement baptisée EIP-7514 (« Ajout d’une limite maximale de perte par époque »). En résumé, dans le pire des cas, cela ralentirait la croissance du pourcentage d’ETH mis en jeu.
3. Un autre sujet soulevé au dernier moment a été abordé : l’ajout d’un opcode dans la machine virtuelle Ethereum (EVM) permettant d’exposer les frais de base des blobs. Un opcode similaire existe déjà pour exposer le BASEFEE d’EIP-1559, introduit dès l’activation de celle-ci. Cela permettrait aux couches 2 (L2) de déterminer plus facilement le prix correct du gaz à facturer aux utilisateurs en fonction du coût des données sur la couche 1 (L1).
4. Des mises à jour relatives à l’EIP-4788 ont également été discutées, qui consiste à stocker la racine du beacon dans un contrat sur la couche d’exécution (EL). Au cours des dernières semaines, plusieurs audits et tests de fuzzing ont été menés sur ce contrat, entraînant quelques ajustements subtils décrits dans cette PR. Premièrement, la gestion explicite des horodatages (timestamps) à zéro a été clarifiée : elle provoque désormais un rejet (rollback), comme pour tout autre horodatage invalide, plutôt que de renvoyer 0. Deuxièmement, la taille du tampon (buffer) a été modifiée. En supposant que le temps par slot puisse changer, le contrat initial entraînerait un gaspillage de stockage en raison de l’arithmétique modulaire. En utilisant un nombre premier (8191), le tampon devrait désormais être utilisé à 100 % quelle que soit la durée du slot. Enfin, des optimisations de gaz ont été réalisées, réduisant le nombre de chargements requis pour CALLDATA. Les auditeurs examineront ces modifications, et un rapport final devrait être remis avant la prochaine réunion ACDE. Afin de maintenir la fluidité des tests de fuzzing et de l’implémentation, les développeurs ont convenu de fusionner maintenant les changements proposés.
5. La réunion a également examiné la question suivante : comment les clients doivent-ils gérer le cas où une adresse de contrat système fait partie de l’état mais se retrouve vide à la fin de l’exécution ? Bien que cela soit pratiquement impossible sur le réseau principal, ce cas limite peut survenir dans les tests lorsqu’une adresse est définie à la genèse. Compte tenu du caractère particulier de ce scénario et de l’absence de comportement normatif clair, les développeurs ont décidé de prendre davantage de temps pour y réfléchir, et de poursuivre la discussion lors de la prochaine réunion technique prévue lundi.
