Prague-Electra : que nous réserve le prochain hard fork d’Ethereum ?
Le 13 mars dernier, le hard fork Cancun-Deneb a été déployé sur le réseau Ethereum. En pratique, celui-ci a introduit les blobs, un nouveau type de stockage. Celui-ci est particulièrement utile aux L2 et autres rollups. Ces derniers peuvent y stocker à moindre coût les données relatives aux transactions ayant lieu hors chaîne. Désormais, les développeurs planchent sur le prochain hard fork à venir : Prague-Electra.
Après Cancun-Deneb place à Prague-Electra
Ethereum est loin de sa forme finale. Pour y arriver, le réseau va être témoin d’une 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, impliquant que tous les nœuds doivent évoluer vers la nouvelle version pour continuer à participer au réseau.
Après le déploiement de Cancun-Deneb en mars dernier, les développeurs s’attellent dorénavant 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.
D’une part, Prague, qui met à jour la couche d’exécution d’Ethereum, aussi appelée Execution Layer (EL). De l’autre, Electra qui met à jour la couche consensus d’Ethereum, à savoir le Consensus Layer (CL). Les deux sont indissociables et permettent la mise à niveau de l’ensemble de l’architecture d’Ethereum.
Désormais, les développeurs réfléchissent aux évolutions qui seront intégrées à ce hard fork. Ces dernières sont dans un premier temps proposées par les développeurs sous la forme d’Ethereum Improvement Proposal (EIP). Si elles sont retenues comme prioritaires, les EIP sont validées par les développeurs lors de leurs réunions bimensuelles.
Les EIP qui seront déployées 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 souligné le 9 avril par Christine Kim, chercheuse chez Galaxy, 4 EIP ont d’ores et déjà été validées et seront présentes dans le hard fork Prague-Electra :
- EIP-6110 : Supply validator deposits on chain ;
- EIP-7002 : Execution layer triggerable exits ;
- EIP-7251 : Increase the MAX_EFFECTIVE_BALANCE ;
- EIP-7549 : Move committee index outside Attestation.
Explorons ensemble ces EIPs et leurs implications sur le réseau.
EIP-6110 : Supply validator deposits on chain
Commençons par l’EIP-6110, intitulée « Supply validator deposits on chain » qui a été proposée par les développeurs Mikhail Kalinin, Danny Ryan et Peter Davies.
Cette EIP vient modifier la manière dont sont gérés les dépôts des validateurs. On le rappelle, un validateur doit disposer de 32 ETH, appelé stake, pour participer au processus de validation des blocs.
Jusqu’à présent, ce dépôt était stocké sur la couche de consensus d’Ethereum. Cet EIP vise à changer cela en les intégrant directement à la couche d’exécution.
Ceci élimine la nécessité pour les validateurs de voter sur l’inclusion des dépôts, un processus qui est actuellement géré par un mécanisme de vote proposant des données de dépôt.
En pratique, cela permettra d’améliorer la sécurité en supprimant l’étape du vote des dépôts.
« Le mécanisme proposé assouplit les hypothèses de sécurité et réduit la complexité de la conception du logiciel client, contribuant ainsi à la sécurité du flux de dépôts. Il améliore également l’expérience utilisateur du validateur. »
De surcroît, cela permet de nettement réduire le délai de traitement du dépôt. Celui-ci est actuellement d’environ 12 heures et devrait être réduit à 13 minutes après le déploiement de l’EIP.
EIP-7002: Execution layer triggerable withdrawals
Vient ensuite l’EIP-7002, intitulée « Execution layer triggerable withdrawals » et qui a été proposée par Danny Ryan, Mikhail Kalinin, Ansgar Dietrichs, Hsiao-Wei Wang et lightclient.
Cette EIP vise à introduire un mécanisme permettant aux validateurs de déclencher des retraits et des sorties de staking directement depuis la couche d’exécution (Execution Layer).
Actuellement, seule la clé active (active key) d’un validateur lui permet d’initier un retrait de ses ETH en staking. L’EIP-7002 souhaite permettre de retirer via des withdrawal credentials de type 0x01, en d’autres termes une adresse de smart contact ou de wallet 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 justificatifs de retrait), le propriétaire final des fonds – le détenteur des justificatifs de retrait – ne peut pas choisir de manière indépendante de sortir et de commencer le processus de retrait. 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 les sorties pré-signées. En outre, en cas de perte des clés actives, un utilisateur devrait toujours être en mesure de récupérer ses fonds en utilisant ses identifiants de retrait à froid. »
EIP-7251 : Increase the MAX_EFFECTIVE_BALANCE
La 3ᵉ EIP qui sera déployée via Prague-Electra n’est autre que l’EIP-7251 intitulée « Increase the MAX_EFFECTIVE_BALANCE », mais souvent contracté en MaxEB.
Nous avions déjà abordé cette EIP d’une importance majeure en mars dernier. Celle-ci vient répondre à un problème grandissant sur Ethereum. En effet, le réseau compte toujours plus de validateurs. Cependant, des essais menés sur le testnet Holesky ont montré que le nombre de validateurs ne pourrait augmenter indéfiniment sans impacter négativement le réseau.
Lorsque trop de validateurs sont sur le réseau, celui-ci peut avoir du mal à finaliser. Cela étant principalement causé par un trop grand nombre de messages d’attestations émis par les nœuds.
Ainsi, MaxEB vise à résoudre ce problème en augmentant la limite de dépôt fixée à 32 ETH. Une nouvelle limite serait fixée à 2048 ETH, ce qui permettrait de réduire la multiplication des nœuds validateurs au profit de super nœuds.
« Cela permet aux larges opérateurs de nœuds de se consolider avec moins de validateurs tout en permettant aux solo-stakers de gagner des récompenses composées et de miser dans des incréments plus flexibles. »
EIP-7549 : Move committee index outside Attestation
Enfin, la 4ᵉ et dernière EIP qui a pour le moment été validée pour le hard fork Prague-Electra est l’EIP-7549 intitulée « Move committee index outside Attestation ».
Celle-ci vise à optimiser le processus de vérification des attestations sur Ethereum en rendant l’agrégation des votes plus efficace et en réduisant le coût de traitement nécessaire pour atteindre le consensus.
Jusqu’à présent, chaque attestation émise par un validateur contient un vote LMD GHOST, un vote FFG, et un indice de comité. La signature incluant l’indice de comité fait que des votes identiques produisent des racines de signature différentes. Cela entraîne des traitements supplémentaires.
Si l’on venait à retirer l’indice de comité de l’attestation signée, comme souhaite le faire cette EIP, cela pourrait drastiquement réduire le nombre minimal d’attestations à vérifier pour atteindre le seuil des deux tiers des validateurs. En pratique, cela passerait de 1366 à environ 22.
« Cette proposition vise à rendre les clients Casper FFG plus efficaces en réduisant le nombre moyen d’appariements nécessaires pour vérifier les règles de consensus. Bien que tous les types de clients puissent bénéficier de cette EIP, les circuits ZK prouvant le consensus Casper FFG sont susceptibles d’avoir l’impact le plus important. »
D’autres EIPs pourraient être ajoutées dans les mois à venir, en amont du déploiement du hard fork. En attendant, les différentes équipes de développeurs vont s’atteler au déploiement et à l’intégration de ces 4 EIP. Ces dernières seront ensuite intensivement testées sur différents devnets puis sur les testnets d’Ethereum. Le déploiement sur le mainnet est quant à lui prévu pour le dernier trimestre de 2024. Toutefois, si aucun accroc ne vient retarder le processus.
Renaud H.
Ingénieur en software et en systèmes distribués de formation, passionné de cryptos depuis 2013. Touche à tout, entre mining et développement, je cherche toujours à en apprendre plus sur l’univers des cryptomonnaies et à partager le fruit de mes recherches à travers mes articles.
