Le 13 mars, le Le hard fork Cancun-Deneb a été déployé sur le réseau Ethereum. En pratique, cela a introduit le blobs, un nouveau type de stockage. Ceci est particulièrement utile pour L2 et autres cumuls. Ils peuvent y stocker à moindre coût les données relatives aux transactions qui s’y déroulent hors chaîne. Désormais, les développeurs travaillent sur le prochain hard fork à venir : Prague-Electra.
Après Cancun-Deneb, place à Prague-Electra
Éthereum est loin d’être sa forme définitive. Pour y parvenir, le réseau connaîtra un multitude de hard forks dans les années à venir. Pour rappel, le hard fork est le mécanisme utilisé pour mettre à jour le logiciel Ethereum. Ces mises à jour ne sont pas rétrocompatibles, ce qui signifie que tous les nœuds doivent passer à la nouvelle version pour continuer à participer au réseau.
Après le déploiement de Cancun-Deneb en mars dernier, les développeurs travaillent désormais au développement du prochain hard fork, connu sous le nom de Prague-Electra.
Comme toujours depuis le passage au Proof of Stake, ce hard fork se décompose en deux parties.
Premièrement, Praguequi met à jour le Couche d’exécution Ethereumaussi appelé Couche d’exécution (EL). L’autre, Electre qui met à jour le Couche de consensus Ethereumà savoir le Couche de consensus (CL). Les deux sont indissociables et permettent la mise à niveau de toute l’architecture Ethereum.
Désormais, les développeurs réfléchissent aux développements qui seront intégrés dans ce hard fork. Celles-ci sont initialement proposées par les développeurs sous la forme d’Ethereum Improvement Proposal (EIP). S’ils sont retenus comme prioritaires, les EIP sont validés par les développeurs lors de leurs réunions bimensuelles.
Les EIP qui seront déployés avec Prague-Electra
Un peu plus d’un mois après le déploiement du précédent hard fork, les développeurs ont déjà une bonne vision de ce qui sera ajouté à Prague-Electra.
Comme https://twitter.com/christine_dkim/status/1777697152124280856 le 9 avril par Christine Kimchercheur à Galaxy, 4 EIP ont déjà été validés et seront présents dans le hard fork Prague-Electra :
- EIP-6110 : Fournir des dépôts de validateur sur la chaîne ;
- EIP-7002 : sorties déclenchables de la couche d’exécution ;
- EIP-7251 : augmentez le MAX_EFFECTIVE_BALANCE ;
- EIP-7549 : Déplacer l’index du comité en dehors de l’attestation.
Explorons ensemble ces EIP et leurs implications sur le réseau.
EIP-6110 : Fournir des dépôts au validateur sur la chaîne
Commençons avec l’EIP-6110titré « Fournir les dépôts du validateur en chaîne » qui a été proposé par les développeurs Mikhaïl Kalinine, Danny Ryan Et Peter Davies.
Cet EIP vient modifier la façon dont les dépôts des validateurs sont gérés. Pour rappel, un validateur doit disposer de 32 ETH, appelés mise, pour participer au processus de validation de bloc.
Jusqu’à présent, ce dépôt était stocké sur la couche consensus d’Ethereum. Cet EIP vise à changer cela en s’intégrant directement dans la couche d’exécution.
Cela élimine la nécessité pour les validateurs de voter sur l’inclusion des référentiels, un processus actuellement géré par un mécanisme de vote proposant des données de référentiel.
En pratique, cela améliorera la sécurité en supprimant l’étape de vote sur le dépôt.
« Le mécanisme proposé assouplit les hypothèses de sécurité et réduit la complexité de la conception des logiciels clients, contribuant ainsi à la sécurité du flux de dépôt. Cela améliore également l’expérience utilisateur du validateur. »
De plus, cela permet de clairement réduire le temps de traitement des dépôts. Ce délai est actuellement d’environ 12 heures et devrait être réduit à 13 minutes après le déploiement de l’EIP.
EIP-7002 : Retraits déclenchables au niveau de la couche d’exécution
Vient ensuite l’EIP-7002titré « Retraits déclenchables au niveau de la couche d’exécution » et qui a été proposé par Danny Ryan, Mikhail Kalinin, Ansgar Dietrichs, Hsiao-Wei Wang Et client léger.
Cet EIP vise à introduire un mécanisme permettant aux validateurs de déclencher des retraits et des sorties du jalonnement directement depuis la couche d’exécution (Couche d’exécution).
Actuellement, seule la clé active d’un validateur lui permet d’initier un retrait de son staking ETH. L’EIP-7002 souhaite autoriser le retrait via informations d’identification de retrait de type 0x01, autrement dit un contact intelligent ou une adresse de portefeuille ordinaire (EOA).
« Selon les spécifications actuelles, seule la clé active peut déclencher la sortie d’un validateur. Cela signifie que dans toute relation de garde non standard (c’est-à-dire que la clé active est une entité distincte des informations d’identification de retrait), le propriétaire final des fonds – le détenteur des informations d’identification de retrait – ne peut pas choisir une manière indépendante de sortir et de commencer le retrait. processus. Cela entraîne des problèmes de confiance (par exemple, l’ETH peut être « pris en otage » par le propriétaire de la clé active) ou des solutions de contournement insuffisantes telles que des sorties pré-signées. De plus, en cas de perte des clés actives, un utilisateur devrait toujours pouvoir récupérer ses fonds en utilisant ses identifiants de retrait à froid. »
EIP-7251 : augmentez le MAX_EFFECTIVE_BALANCE
Le 3ème EIP qui sera déployé via Prague-Electra n’est autre que l’EIP-7251 titré “Augmentez le MAX_EFFECTIVE_BALANCE”mais souvent contracté en MaxEB.
Nous avions déjà abordé cet EIP majeur en mars dernier. Cela répond à un problème croissant sur Ethereum. En effet, le réseau compte toujours plus de validateurs. Cependant, les tests effectués sur le testnet Holesky ont montré que le nombre de validateurs ne pouvait pas augmenter indéfiniment sans avoir un impact négatif sur le réseau.
Lorsqu’il y a trop de validateurs sur le réseau, le réseau peut avoir des difficultés difficile de finaliser. Ceci est principalement dû à un trop grand nombre de messages d’attestation envoyés par les nœuds.
Ainsi, MaxEB vise à résolvez ce problème en augmentant la limite de dépôt fixée à 32 ETH. Une nouvelle limite serait fixé à 2048 ETHce qui réduirait la multiplication des nœuds validateurs au profit de gros noeuds.
«Cela permet aux grands opérateurs de nœuds de se consolider avec moins de validateurs tout en permettant aux parieurs solo de gagner des récompenses composées et de miser par incréments plus flexibles. »
EIP-7549 : Déplacer l’index du comité en dehors de la certification
Enfin, le 4ème et dernier EIP qui a jusqu’à présent été validé pour le hard fork Prague-Electra est EIP-7549 titré “Déplacer l’index du comité en dehors de l’attestation”.
Ceci vise à optimiser le processus de vérification des attestations sur Ethereum en redonnant une agrégation des votes plus efficace et réduire le coût de traitement requis pour parvenir à un consensus.
Jusqu’à présent, chaque certificat délivré par un validateur contient un vote LMD GHOST, un vote FFG et un index du comité. La signature incluant l’index du comité fait que des votes identiques produisent des racines de signature différentes. Cela entraîne des traitements supplémentaires.
Si l’on supprimait l’index du comité du certificat signé, comme souhaite le faire cet EIP, cela pourrait réduire drastiquement le nombre minimum de certificats à vérifier pour atteindre le seuil des deux tiers de validateurs. En pratique, cela passerait de 1366 à environ 22.
«Cette proposition vise à rendre les clients de Casper FFG plus efficaces en réduisant le nombre moyen de correspondances nécessaires pour vérifier les règles de consensus. Bien que tous les types de clients puissent bénéficier de cet EIP, les circuits ZK prouvant le consensus Casper FFG sont susceptibles d’avoir le plus grand impact. »
D’autres EIP pourraient être ajoutés dans les mois à venir, avant le déploiement du hard fork. En attendant, les différentes équipes de développeurs travailleront sur le déploiement et l’intégration de ces 4 EIP. Ceux-ci seront ensuite testés intensivement sur différents devnets puis sur les testnets Ethereum. Le déploiement sur le réseau principal est prévu pour le dernier trimestre 2024. Cependant, sans aucun problème, le processus ne sera pas retardé.
