Analyse du prochain fork dur d'Ethereum : la mise à jour Pectra
TechFlow SélectionTechFlow Sélection
Analyse du prochain fork dur d'Ethereum : la mise à jour Pectra
La mise à niveau de Prague / Electra (Pectra) est prévue pour mars 2025.
Dédié à des analyses Web3 approfondiesRédaction : Sergey Boogerwooger, Dmitry Zakharov, MixBytes
Traduction : Traducteur IA, Communauté Denlian
Introduction
Dans nos précédents articles, nous avons passé en revue en détail le cycle de vie des validateurs Ethereum et discuté de plusieurs aspects liés au prochain hardfork Electra. Il est maintenant temps de se concentrer sur les modifications apportées par les mises à jour imminentes Electra et Prague, et de les expliquer en détail.
L’histoire du hardfork « preuve d’enjeu » d’Ethereum 2.0 est complexe. Elle a commencé par l’ajout d’une couche Beacon au niveau d’exécution existant, la preuve d’enjeu (PoS) étant activée sur la couche Beacon tandis que la couche d’exécution conservait encore la preuve de travail (Phase 0 et hardfork Altair). Ensuite, lors du hardfork Bellatrix, la PoS a été pleinement activée (bien que les retraits n’aient pas encore été autorisés). Puis le hardfork Capella a permis les retraits, complétant ainsi le cycle de vie des validateurs. Le dernier hardfork Deneb (partie de la mise à niveau Dencun — Deneb/Cancun) a apporté de légères modifications aux paramètres de la chaîne Beacon, comme la fenêtre temporelle de traitement des attestations, la gestion des retraits volontaires et les limites de rotation des validateurs. Les principales évolutions de Dencun ont eu lieu au niveau d’exécution, avec l’introduction des transactions blob, du blob gas, des engagements KZG pour les blobs, et la dépréciation de l’opération SELFDESTRUCT.
Aujourd’hui, le hardfork Prague/Electra (soit Pectra) introduit d’importantes améliorations aux couches d’exécution et de consensus. En tant qu’auditeurs du projet Lido, nous nous concentrons principalement sur les changements relatifs au consensus et au staking dans ce hardfork. Toutefois, nous ne pouvons ignorer les modifications au niveau d’exécution de Prague, car elles incluent des fonctionnalités importantes affectant le réseau Ethereum et les validateurs. Examinons maintenant ces changements en détail.
Vue d’ensemble générale de Pectra
Electra introduit de nombreuses fonctionnalités à la couche Beacon. Les principales mises à jour comprennent :
-
Permettre aux validateurs d’avoir un solde effectif variable entre 32 et 2048 ETH (au lieu d’un montant fixe de 32 ETH).
-
Permettre aux validateurs d’initier un retrait via une deuxième « credential » de retrait (sans nécessiter la clé active du validateur).
-
Modifier la manière dont la couche Beacon traite les dépôts Eth1 (plus besoin d’analyser les événements depuis le contrat de dépôt).
-
Ajouter un nouveau cadre générique pour traiter les requêtes provenant de contrats Eth1 standards sur la couche Beacon (similaire à la gestion des dépôts avant Electra).
Parallèlement, Prague apporte les changements suivants au niveau d’exécution :
-
Un nouveau contrat précompilé supportant la courbe BLS12-381 afin de valider des preuves zkSNARK (en complément de la courbe populaire BN254).
-
Un nouveau contrat système permettant de stocker et d’accéder aux hachages des 8192 derniers blocs (très utile pour les clients sans état).
-
Augmenter le coût du calldata afin de réduire la taille des blocs et inciter les projets à migrer leurs opérations intensives en calldata (comme les rollups) vers les blobs introduits dans Dencun.
-
Permettre davantage de blobs par bloc Eth1, avec une API pour lire ces quantités.
-
Permettre aux comptes externes (EOA) d’avoir leur propre code, étendant considérablement les opérations possibles, telles que les multicalls ou la délégation d’exécution à d’autres adresses.
Consultons maintenant les propositions d’amélioration d’Ethereum (EIP) associées pour approfondir notre analyse :
-
EIP-7251 : Augmentation de MAX_EFFECTIVE_BALANCE
-
EIP-7002 : Retraits déclenchés par la couche d’exécution
-
EIP-6110 : Dépôts de validateurs intégrés à la chaîne
-
EIP-7549 : Suppression de l’index du comité des attestations
-
EIP-7685 : Requêtes générales au niveau d’exécution
-
EIP-2537 : Précompilation des opérations sur la courbe BLS12-381
-
EIP-2935 : Conservation des hachages des blocs historiques dans l’état
-
EIP-7623 : Augmentation du coût du calldata
-
EIP-7691 : Augmentation du débit des blobs
-
EIP-7840 : Ajout de la planification des blobs au profil EL
-
EIP-7702 : Attribution de code aux comptes EOA
Certaines de ces EIP concernent principalement la couche de consensus (Beacon), d’autres la couche d’exécution. Certaines touchent les deux couches, car certaines opérations (comme les dépôts et retraits) nécessitent des modifications synchronisées entre le consensus et l’exécution. En raison de cette interdépendance, séparer Electra et Prague serait peu pratique. Nous passerons donc en revue chaque EIP successivement, en précisant le composant Ethereum concerné dans chaque cas.
EIP-7251 : Augmentation de MAX_EFFECTIVE_BALANCE
Référence : EIP-7251
Depuis le premier hardfork Phase 0, en préparation de la preuve d’enjeu d’Ethereum, jusqu’à Electra, le solde effectif maximum d’un validateur était fixé à 32 ETH. Pour activer un validateur, il fallait au moins atteindre spec.min_activation_balance (32 ETH). Après activation, le validateur commençait avec ce solde maximal, mais pouvait réduire son solde effectif jusqu’à spec.ejection_balance (16 ETH), moment où il était expulsé. Cette logique du « minimum » reste inchangée dans Electra, mais désormais spec.max_effective_balance est augmenté à 2048 ETH. Ainsi, les validateurs peuvent désormais déposer entre 32 et 2048 ETH pour s’activer, et tous ces montants contribueront à leur solde effectif. Ce changement marque la transition d’un modèle « preuve d’enjeu à 32 ETH » vers une véritable « preuve d’enjeu » :)
Ce solde effectif variable sera désormais utilisé pour :
-
Augmenter la probabilité d’être sélectionné comme proposant de bloc, proportionnellement au solde effectif
-
Augmenter la probabilité d’entrer dans le comité de synchronisation, proportionnellement au solde effectif
-
Servir de base pour calculer les sanctions relatives de slashing et d’inactivité
Les deux premières activités sont celles qui rapportent le plus aux validateurs. Par conséquent, après Electra, les validateurs ayant un gros enjeu participeront plus fréquemment aux propositions de blocs et aux comités de synchronisation, selon une proportion directe avec leur solde effectif.
Un autre impact concerne le slashing. Toutes les pénalités de slashing sont proportionnelles au solde effectif du validateur :
-
Les pénalités de slashing « immédiates » et « différées » sont plus élevées pour les validateurs fortement enjeunés.
-
Les pénalités différées subies par les validateurs co-enjeunés avec un validateur sanctionné sont aussi plus élevées, car la part « slashée » du total en jeu devient plus importante.
-
Les informateurs signalant un validateur ayant un solde effectif élevé obtiennent une plus grande part du montant enjeu du validateur sanctionné.
Electra propose également des modifications au ratio de slashing, définissant quelle partie du solde du validateur sanctionné est distribuée à l’informateur.
Vient ensuite l’impact sur l’inactivité. Lorsqu’un validateur est hors ligne pendant qu’il est actif (attestation ou proposition), un score d’inactivité s’accumule, entraînant une pénalité d’inactivité chaque période. Ces pénalités sont également proportionnelles au solde effectif du validateur.
En raison de l’augmentation du solde effectif, la « limite de remplacement » des validateurs a aussi été modifiée. Dans Ethereum « avant Electra », les validateurs avaient généralement le même solde effectif, et la limite de remplacement était définie comme suit : « durant une période, au maximum 1/65536 (spec.churn_limit_quotient) du total en jeu peut sortir ». Cela créait un nombre « fixe » de validateurs pouvant sortir, chacun avec un enjeu identique. Mais « après Electra », quelques seuls « baleines » pourraient suffire à atteindre cette limite, car elles représentent une part importante du total en jeu.
Un autre point concerne la rotation de multiples clés de validateur sur une seule instance. Actuellement, les grands validateurs sont obligés d’exécuter des milliers de clés de validateur sur une même instance pour gérer de gros enjeux, divisés en parties de 32 ETH. Avec Electra, cette contrainte n’est plus nécessaire. Sur le plan financier, ce changement n’a pas grand impact, car les récompenses et probabilités s’échelonnent linéairement avec le montant enjeu. Ainsi, 100 validateurs de 32 ETH chacun équivalent à un seul validateur de 3200 ETH. De plus, plusieurs clés de validateur actives peuvent partager la même credential de retrait Eth1, permettant de retirer toutes les récompenses vers une seule adresse ETH, évitant ainsi les frais de gaz liés à la consolidation des gains. Toutefois, la gestion de nombreuses clés engendre des coûts administratifs supplémentaires.
La capacité de regrouper les soldes des validateurs ajoute un nouveau type de requête au niveau d’exécution. Avant, nous avions les dépôts et les retraits. Maintenant, un troisième type apparaît : la requête de consolidation. Elle fusionne deux validateurs en un seul. Cette requête inclura la clé publique source et la clé cible, et sera traitée de façon similaire aux dépôts et retraits. La consolidation aura aussi sa file de requêtes en attente et sa limite de rotation, tout comme les dépôts et retraits.
Résumé :
-
Pour les petits validateurs indépendants, Electra introduit la possibilité d’augmenter automatiquement leur solde effectif (et leurs récompenses). Avant, tout excédent au-delà de 32 ETH ne pouvait être que retiré, mais après Electra, cet excédent contribuera finalement à leur solde effectif. Toutefois, le solde effectif ne peut augmenter que par multiples de spec.effective_balance_increment (1 ETH), ce qui signifie que l’augmentation intervient seulement après avoir franchi le seuil du « prochain ETH ».
-
Pour les grands validateurs indépendants, Electra simplifie considérablement la gestion en permettant de regrouper plusieurs clés de validateur actives en une seule. Bien que cela ne change pas fondamentalement la donne, gérer un seul enjeu de 2048 ETH est nettement plus simple que 64 enjeux de 32 ETH.
-
Pour les fournisseurs de staking liquide, qui collectent de petits enjeux auprès des utilisateurs et les allouent entre différents validateurs, Electra offre plus de flexibilité dans les schémas d’allocation, mais nécessite une refonte importante de la comptabilité basée sur le solde effectif fixe de 32 ETH.
Un autre sujet important est l’historique des données des validateurs et l’estimation des profits, particulièrement pertinent pour les nouveaux arrivants cherchant à évaluer risques et rendements. Avant Electra (au moment de la rédaction), la limite supérieure de 32 ETH (minimum et maximum en pratique) créait une uniformité dans les données historiques. Tous les soldes effectifs, récompenses, sanctions individuelles de slashing, fréquence de proposition de blocs et autres indicateurs étaient identiques. Cette uniformité a permis à Ethereum de tester son mécanisme de consensus sans valeurs aberrantes statistiques, collectant ainsi des données précieuses sur le comportement du réseau.
Après Electra, la distribution des enjeux va changer radicalement. Les grands validateurs participeront plus souvent aux propositions de blocs et aux comités de synchronisation, subiront des sanctions plus lourdes en cas de slashing, et auront un impact plus grand sur les sanctions différées, ainsi que sur les files d’activation et de sortie. Bien que cela puisse poser des défis pour l’agrégation des données, le consensus d’Ethereum garantit que les calculs non linéaires restent minimes. Le seul composant non linéaire utilise sqrt(total_effective_balance) pour calculer la récompense de base, applicable à tous les validateurs. Cela signifie que les récompenses et sanctions peuvent toujours être estimées « par 1 ETH » (ou plus précisément selon spec.effective_balance_increment, susceptible d’évoluer à l’avenir).
Pour plus de détails, veuillez consulter notre article précédent sur le comportement des validateurs.
EIP-7002 : Retraits déclenchables par la couche d’exécution
Référence : EIP-7002
Chaque validateur sur Ethereum possède deux paires de clés : une paire active et une paire de retrait. La clé publique BLS active sert d’identité principale du validateur sur la chaîne Beacon ; elle est utilisée pour signer des blocs, des attestations, des preuves de slashing, des agrégats du comité de synchronisation, et (avant cette EIP) pour initier des retraits volontaires (déclenchant la sortie du validateur du consensus après un délai). La deuxième paire de clés (« credential de retrait ») peut être soit une autre paire BLS, soit un compte Eth1 standard (clé privée et adresse). Actuellement, pour retirer des fonds vers une adresse ETH, un message de retrait signé par la clé privée BLS active est requis. Cette EIP modifie cette règle.
En pratique, les propriétaires des deux paires (active et retrait) peuvent être différents. La clé active gère les responsabilités de validation : exécuter le serveur, le maintenir opérationnel, etc., tandis que la credential de retrait est généralement contrôlée par le propriétaire de l’enjeu, qui reçoit les récompenses et contrôle les fonds. Actuellement, seul le propriétaire de la credential de retrait ne peut pas initier la sortie du validateur, uniquement retirer les récompenses. Cela permet au propriétaire de la clé active de garder le solde du validateur comme « otage ». Un validateur peut « pré-signer » un message de retrait et le remettre au propriétaire, mais cette solution de contournement n’est pas idéale. De plus, actuellement, les retraits et les sorties exigent une interaction spécifique avec la CLI du validateur sur la couche Beacon.
La meilleure solution consiste à permettre au propriétaire de l’enjeu d’effectuer simultanément le retrait et la sortie via un appel standard à un contrat intelligent. Cela implique une vérification de signature Eth1 standard, simplifiant grandement l’opération.
Cette EIP permet au détenteur de l’enjeu de déclencher un retrait ou une sortie en envoyant une transaction standard depuis son adresse ETH vers un contrat intelligent dédié (similaire au processus existant de dépôt via le « contrat de dépôt »). Le processus de retrait (ou de sortie si l’enjeu est suffisamment réduit) se déroule comme suit :
-
Le détenteur envoie une demande de retrait au contrat système « retrait » (requête « in »).
-
Le contrat prélève des frais spécifiques (en ETH) pour limiter les attaques potentielles, augmentant les frais lorsque la file d’attente est saturée, à la manière de l’EIP-1559.
-
Le contrat sauvegarde la requête de retrait/sortie « in » dans son stockage.
-
Lorsqu’un bloc est proposé sur la couche Beacon, les requêtes « in » sont récupérées depuis le stockage.
-
La couche Beacon traite les requêtes « in », interagit avec le solde du validateur actif, planifie sa sortie et crée une requête de retrait « out ».
-
La requête de retrait « out » est traitée au niveau d’exécution, et le détenteur reçoit ses ETH.
Bien que les dépôts soient déclenchés par un bloc Eth1, puis « déplacés » vers la couche Beacon via une file de dépôts en attente, les retraits suivaient un schéma différent : ils étaient initiés sur la couche Beacon (via CLI), puis « transférés » vers un bloc Eth1. Désormais, les deux schémas utiliseront un cadre générique commun (décrit ci-dessous) : création de requêtes au niveau Eth1, gestion des files de dépôts/retraits/consolidations en attente, et traitement sur la couche Beacon. Pour les opérations de type « sortie », une file de sortie sera aussi traitée, et le résultat sera « réglé » dans un bloc Eth1.
Grâce à cette EIP, les détenteurs peuvent retirer et sortir leurs validateurs via des transactions ETH standards, sans interagir directement avec la CLI du validateur ni accéder à son infrastructure. Cela simplifie considérablement les opérations de staking, surtout pour les grands fournisseurs. L’infrastructure des validateurs peut désormais être presque entièrement isolée, nécessitant uniquement la maintenance des clés actives, tandis que toutes les opérations de staking peuvent être gérées ailleurs. Cela élimine la dépendance des stakers indépendants vis-à-vis des actions du validateur actif et simplifie grandement la partie hors chaîne des services comme le Community Staking Module de Lido.
En résumé, cette EIP « achève » les opérations de staking, les déplaçant entièrement vers la couche Eth1, réduisant significativement les risques liés à la sécurité de l’infrastructure et renforçant la décentralisation des initiatives de staking autonome.
EIP-6110 : Approvisionnement des dépôts de validateurs en chaîne
Référence : EIP-6110
Actuellement, les dépôts sont réalisés via des événements émis par le contrat système « dépôt » (comme discuté en détail dans des articles précédents). Le contrat accepte des ETH et les informations d’identification du validateur, émet un événement « Deposit() », qui est ensuite analysé et converti en requête de dépôt sur la couche Beacon. Ce système présente plusieurs inconvénients : il nécessite un vote sur les données eth1data au niveau de la chaîne Beacon, entraînant un retard significatif. De plus, la couche Beacon doit interroger la couche d’exécution, ajoutant encore de la complexité. Ces problèmes sont bien documentés dans l’EIP. Une méthode plus simple, évitant bon nombre de ces complications, consiste à inclure directement les requêtes de dépôt à un emplacement désigné dans les blocs Eth1. Ce mécanisme est similaire au flux de traitement des retraits décrit dans l’EIP précédente.
Les changements proposés dans cette EIP sont prometteurs. Le traitement de eth1data peut désormais être totalement supprimé, sans besoin de vote ni de long retard entre l’événement sur le côté Eth1 et l’inclusion du dépôt sur la couche Beacon (actuellement environ 12 heures). Cela supprime aussi la logique de snapshot du contrat de dépôt. Cette EIP simplifie le traitement des dépôts et l’aligne sur le schéma de traitement des retraits décrit ci-dessus.
Pour les détenteurs et validateurs, ces changements réduisent considérablement le délai entre le dépôt et l’activation du validateur. En cas de slashing, les reconstitutions nécessaires seront aussi plus rapides.
Peu de choses à ajouter sur cette EIP, hormis qu’elle supprime une logique obsolète, simplifie le processus et produit de meilleurs résultats pour toutes les parties concernées.
EIP-7685 : Requêtes générales au niveau d’exécution
Référence : EIP-7685
Cette EIP aurait dû être présentée avant les trois autres liées aux dépôts/retraits/consolidations, car elle en constitue la base. Toutefois, elle est introduite ici pour souligner le besoin croissant de déplacer de manière cohérente des données spécialisées entre les blocs (couches) Eth1 (exécution) et Beacon (consensus). Cette EIP touche les deux couches, rendant le traitement des requêtes déclenchées par des transactions ETH standards plus efficace. Actuellement, on observe :
-
Les événements de dépôt dans les blocs Eth1 sont « déplacés » vers les blocs Beacon pour traitement.
-
Les requêtes de retrait dans les blocs Beacon (via CLI) sont « déplacées » vers les blocs Eth1 pour traitement.
-
La consolidation des validateurs doit aussi être traitée, ce qui constitue une requête Eth1 → Beacon.
Ces trois opérations montrent la nécessité d’un traitement homogène des divers types de requêtes lors des transitions entre la couche d’exécution et la couche Beacon. De plus, nous avons besoin de pouvoir déclencher ces opérations uniquement via la couche Eth1, car cela nous permettrait d’isoler l’infrastructure des validateurs de celle de gestion du staking, améliorant ainsi la sécurité. Par conséquent, une solution générique pour gérer ces requêtes est à la fois pratique et indispensable.
Cette EIP établit un cadre pour au moins trois cas principaux : dépôts, retraits et consolidations. C’est pourquoi les anciennes EIP ont introduit des champs comme WITHDRAWAL_REQUEST_TYPE et DEPOSIT_REQUEST_TYPE, et la consolidation ajoutera maintenant CONSOLIDATION_REQUEST_TYPE. De plus, cette EIP pourrait inclure un mécanisme général pour limiter le traitement de ces requêtes (voir constantes : PENDING_DEPOSITS_LIMIT, PENDING_PARTIAL_WITHDRAWALS_LIMIT, PENDING_CONSOLIDATIONS_LIMIT).
Bien que les détails d’implémentation complets de ce cadre ne soient pas encore disponibles, il inclura certainement les types de requêtes clés, des mécanismes d’intégrité (par exemple, hachage et Merklisation des requêtes), ainsi que le traitement des files d’attente en attente et les limitations de débit.
Cette EIP a une importance architecturale, permettant à Eth1 de déclencher des opérations critiques sur la couche Beacon via un cadre unifié. Pour les utilisateurs finaux et les projets, cela signifie que toutes les requêtes déclenchées au niveau Eth1 seront transmises et traitées plus efficacement sur la couche Beacon.
EIP-2537 : Précompilation des opérations sur la courbe BLS12-381
Référence : EIP-2537
Si vous ne souhaitez pas entrer dans les détails, vous pouvez voir la précompilation BLS12-381 comme une opération cryptographique complexe de type « hachage », désormais utilisable dans les contrats intelligents. Pour ceux intéressés, approfondissons.
Les opérations mathématiques sur des courbes elliptiques comme BLS12-381 (et sa cousine BN-254) sont actuellement utilisées principalement à deux fins :
-
Les signatures BLS, où une opération spéciale appelée « pairing » est utilisée pour vérifier ces signatures. Les validateurs utilisent largement les signatures BLS car elles permettent d’agréger plusieurs signatures en une seule. Les validateurs s’appuient sur des signatures BLS basées sur la courbe BLS12-381 (bien qu’ils puissent aussi utiliser toute courbe supportant les pairings, comme BN254).
-
La vérification des preuves zkSNARK, où les pairings sont utilisés pour valider les preuves. De plus, les engagements KZG pour les gros blocs, introduits par le hardfork Dencun, utilisent aussi des pairings pour valider les engagements de bloc.
Si vous souhaitez vérifier des signatures BLS ou des preuves zkSNARK dans un contrat intelligent, vous devez calculer ces « pairings », ce qui est extrêmement coûteux en termes de calcul. Ethereum dispose déjà d’un contrat précompilé pour les opérations sur la courbe BN254 (EIP-196 et EIP-197). Cependant, la courbe BLS12-381 (aujourd’hui considérée comme plus sûre et plus largement utilisée) n’est pas encore implémentée en tant que précompilation. Sans cette précompilation, implémenter les pairings et autres opérations sur la courbe dans un contrat intelligent nécessite d’importants calculs, comme illustré ici, et consomme d’énormes quantités de gaz (environ ~10⁵ à 10⁶).
Cette EIP ouvre la porte à de nombreuses applications potentielles, notamment la vérification économique de signatures BLS basées sur BLS12-381. Cela rend possible la mise en œuvre de divers schémas à seuil. Comme mentionné, les validateurs Ethereum utilisent déjà des signatures basées sur BLS12-381. Grâce à cette EIP, les contrats intelligents standards peuvent désormais vérifier efficacement les signatures agrégées des validateurs. Cela peut simplifier les preuves de consensus et les ponts d’actifs entre réseaux, car les signatures BLS sont largement utilisées dans les blockchains. Les signatures BLS à seuil permettent elles-mêmes de construire de nombreux schémas efficaces pour les votes, la génération aléatoire décentralisée, les multisignatures, etc.
Une vérification moins coûteuse des preuves zkSNARK, à son tour, débloquera de nombreuses applications. Beaucoup de solutions basées sur zkSNARK sont actuellement freinées par le coût élevé de vérification des preuves, rendant certains projets presque impraticables. Cette EIP a le potentiel de changer cela.
EIP-2935 : Sauvegarde des hachages des blocs historiques dans l’état
Référence : EIP-2935
Cette EIP propose de stocker 8192 hachages de blocs historiques (environ 27,3 heures) dans l’état de la blockchain, offrant un historique étendu aux clients sans état (comme les rollups) et aux contrats intelligents. Elle recommande de conserver le comportement actuel de l’opcode BLOCKHASH, limité aux 256 derniers blocs, tout en introduisant un nouveau contrat système dédié au stockage et à la récupération des hachages historiques. Ce contrat exécute une opération set() lors du traitement d’un bloc au niveau d’exécution. Sa méthode get() est accessible à tous, permettant de récupérer le hachage du bloc souhaité depuis un tampon circulaire.
Actuellement, il est possible de faire référence aux hachages de blocs historiques dans l’EVM, mais l’accès est limité aux 256 derniers blocs (environ 50 minutes). Toutefois, dans certains cas, l’accès à des données plus anciennes est crucial, notamment pour les applications inter-chaînes (nécessitant de prouver des données de blocs antérieurs) et les clients sans état, qui ont régulièrement besoin d’accéder à des hachages de blocs passés.
Cette EIP étend la fenêtre temporelle disponible aux rollups et aux applications inter-chaînes, leur permettant d’accéder directement aux données historiques dans l’EVM, sans avoir à les collecter en externe. Ces solutions deviennent ainsi plus robustes et durables.
EIP-7623 : Augmentation du coût du calldata
Référence : EIP-7623
Le coût du calldata régule la taille maximale du payload des transactions, qui peut être importante dans certains cas (par exemple, lors du passage de grands tableaux ou tampons binaires comme paramètres). L’utilisation intensive du calldata est principalement due aux rollups, qui envoient des payloads contenant l’état actuel du rollup dans le calldata.
L’intégration de données binaires volumineuses et vérifiables dans la blockchain est cruciale pour les rollups. La mise à niveau Dencun (Deneb-Cancun) a introduit une innovation majeure pour ces cas d’usage : les transactions blob (EIP-4844). Les transactions blob ont leur propre frais de « blob gas » spécialisé, et bien que leur contenu soit temporairement stocké, leur preuve cryptographique (engagement KZG) ainsi que leur hachage sont intégrés à la couche de consensus. Ainsi, par rapport au stockage via calldata, les blobs offrent une meilleure solution aux rollups.
Encourager les rollups à déplacer leurs données vers les blobs peut se faire via une approche « carotte et bâton ». La réduction du blob gas agit comme la « carotte », et cette EIP joue le rôle du « bâton » en augmentant le coût du calldata, dissuadant ainsi le stockage excessif de données dans les transactions. Cette EIP complète l’EIP-7691 suivante (Augmentation du débit des blobs), qui augmente le nombre maximal de blobs autorisés par bloc.
EIP-7691 : Augmentation du débit des blobs
Référence : EIP-7691
Les blobs ont été introduits lors du précédent hardfork Dencun, avec des valeurs initiales conservatrices pour le nombre maximal et cible de blobs par bloc. Cela s’expliquait par la difficulté de prévoir comment le réseau p2p gérerait la propagation d’objets binaires volumineux entre les nœuds validateurs. La configuration précédente s’est révélée satisfaisante, rendant opportun de tester de nouvelles valeurs. Précédemment, le nombre cible/maximal de blobs par bloc était fixé à 3/6. Ces limites sont désormais portées à 6/9 respectivement.
Combiné à l’EIP-7623 précédente (augmentation du coût du calldata), cet ajustement incite davantage les rollups à transférer leurs données du calldata vers les blobs. Les travaux pour trouver les meilleurs paramètres de blobs se poursuivent.
EIP-7840 : Ajout de la planification des blobs au profil EL
Référence : EIP-7840
Cette EIP propose d’ajouter au profil de la couche d’exécution Ethereum (EL) les valeurs du nombre cible et maximal de blobs par bloc (discutées précédemment), ainsi que la valeur baseFeeUpdateFraction. Elle permettra aussi aux clients de récupérer ces valeurs via l’API du nœud. Cette fonctionnalité est particulièrement utile pour des tâches comme l’estimation des frais de blob gas.
EIP-7702 : Attribution de code aux comptes EOA
Référence : EIP-7702
Il s’agit d’une EIP très importante qui apportera des changements majeurs aux utilisateurs d’Ethereum. Comme nous le savons, les comptes externes (EOA) ne peuvent pas contenir de code, mais peuvent fournir des signatures de transaction (tx.origin). En revanche, les contrats intelligents ont un bytecode, mais ne peuvent pas proposer directement une signature « de leur fait ». Toute interaction utilisateur nécessitant une logique supplémentaire, automatisée et vérifiable ne peut actuellement être réalisée qu’en appelant un contrat externe pour exécuter l’opération requise. Toutefois, dans ce cas, le contrat externe devient le msg.sender des appels ultérieurs, ce qui signifie que l’appel provient « d’un contrat, pas d’un utilisateur ».
Cette EIP introduit un nouveau type de transaction SET_CODE_TX_TYPE=0x04 (nous avions auparavant les anciennes transactions 0x1, les nouvelles 0x02 issues des mises à jour Berlin et EIP-1559, et les transactions blob 0x03 introduites dans Dencun). Ce nouveau type permet d’attribuer du code à un compte EOA. En pratique, cela permet à un EOA d’exécuter du code externe « dans le contexte de son propre compte ». Du point de vue extérieur, pendant la transaction, l’EOA « emprunte » temporairement le code d’un contrat externe pour l’exécuter. Techniquement, cela est réalisé en ajoutant un tuple de données d’autorisation spéciales au stockage « code » de l’adresse EOA (ce stockage était toujours vide pour les EOA avant cette EIP).
Actuellement, ce nouveau type de transaction 0x04 proposé par cette EIP contient un tableau :
authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]
Chaque élément permet au compte d’utiliser le code provenant de l’adresse spécifiée (depuis la dernière entrée d’autorisation valide). Lors du traitement de cette transaction, le code de l’EOA donné est défini comme 0xef0100 || valeur_adresse (23 octets), où l’adresse pointe vers le contrat contenant le code désiré, || indique la concaténation, et 0xef0100 est une valeur magique spéciale que les contrats intelligents normaux ne peuvent pas contenir (selon l’EIP-3541). Cette valeur magique garantit que cet EOA ne peut pas être considéré comme un contrat standard, ni appelé comme tel.
Lorsque cet EOA lance une transaction, l’adresse spécifiée est utilisée pour appeler le code correspondant dans le contexte de cet EOA. Bien que les détails complets d’implémentation de cette EIP ne soient pas encore connus, on peut affirmer qu’elle apportera des changements importants.
Un effet majeur est la possibilité d’effectuer des multicalls directement depuis un EOA. Les multicalls sont une tendance constante dans la DeFi, et de nombreux protocoles offrent cette fonctionnalité comme outil puissant (par exemple Uniswap V4, Balancer V3 ou Euler V2). Avec cette EIP, les multicalls peuvent désormais être lancés directement depuis un EOA.
Par exemple, cette nouvelle fonctionnalité résout un problème courant en DeFi : l’inefficacité de devoir effectuer deux transactions séparées pour approve() + anything(). Cette EIP permet une logique de « pré-autorisation » générique, faisant que des opérations comme approve(X) + deposit(X) peuvent désormais être réalisées en une seule transaction.
Un autre avantage est la possibilité de déléguer l’exécution de transactions « au nom de » l’EOA, ce qui ouvre la voie au concept de sponsoring. Le sponsoring est fréquemment discuté et fortement souhaité pour aider les nouveaux utilisateurs à entrer sur Ethereum.
La logique programmable associée à un EOA débloque de nombreuses possibilités, comme la mise en œuvre de restrictions de sécurité, de plafonds de dépenses, d’exigences KYC, etc.
Bien sûr, ce changement soulève aussi de nombreuses questions de conception. L’une concerne l’utilisation de chain_id, qui détermine si une même signature peut être valide sur plusieurs réseaux selon qu’elle inclut ou non chain_id. Un autre point complexe est le choix entre utiliser l’adresse du code cible ou intégrer directement le bytecode. Chaque méthode a ses caractéristiques et limites propres. De plus, le nonce joue un rôle clé dans la définition de permissions « multi-usages » ou « usage unique ». Ces éléments influencent les questions de fonctionnalité, de sécurité, d’annulation groupée de signatures et de facilité d’utilisation. Vitalik a soulevé ces points dans une discussion (ici), méritant une exploration plus approfondie.
Il convient de noter que ce changement affecte un mécanisme de sécurité d’Ethereum : tx.origin. Plus de détails sur l’implémentation de cette EIP sont nécessaires, mais il semble que le comportement de require(tx.origin == msg.sender) va changer. Ce contrôle était la méthode la plus fiable pour s’assurer que msg.sender est un EOA, pas un contrat. D’autres méthodes, comme vérifier EXTCODESIZE (pour savoir si c’est un contrat), échouent souvent et peuvent être contournées (par exemple, en appelant un constructeur ou en déployant du code après la transaction). Ces vérifications servent à prévenir les attaques de réentrance et de prêt flash, mais sont loin d’idéales car elles bloquent aussi l’intégration avec d’autres protocoles. Après cette EIP, même le contrôle fiable require(tx.origin == msg.sender) semble devenir obsolète. Les protocoles devront s’adapter en supprimant ces vérifications, car la distinction entre « EOA » et « contrat » ne tiendra plus — désormais, toute adresse pourrait avoir du code associé.
La séparation traditionnelle entre EOA et contrats intelligents continue de s’estomper. Cette EIP rapproche Ethereum d’architectures comme TON, où chaque compte est essentiellement du code exécutable. Alors que les interactions avec les protocoles deviennent de plus en plus complexes, l’utilisation de logique programmable pour améliorer l’expérience utilisateur est un processus naturel d’évolution.
Conclusion
La mise à niveau Prague/Electra (Pectra) est prévue pour mars 2025. Ses changements planifiés les plus notables incluent :
-
Un solde effectif de staking variable pour les validateurs, allant jusqu’à 2048 ETH, ce qui modifiera profondément la distribution du staking, les calendriers des validateurs, et simplifiera la gestion pour les grands fournisseurs grâce à la consolidation des petits enjeux
-
L’amélioration de l’interaction entre les couches d’exécution et de consensus, simplifiant l’échange de données entre les blocs d’exécution Eth1 et les blocs de la chaîne Beacon. Cela simplifiera considérablement les dépôts, activations, retraits et sorties, accélérera ces processus, et jettera les bases d’interactions futures entre les couches de consensus et d’exécution
-
Le support dans les contrats intelligents de vérifications moins coûteuses de signatures BLS et de preuves zkSNARK, grâce à une nouvelle précompilation BLS12-381 « compatible pairing »
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@MixBytes
