Quels EIP ont été retenus pour la mise à niveau Pectra ? Cela va-t-il aggraver l'inflation de l'ETH ?
TechFlow SélectionTechFlow Sélection
Quels EIP ont été retenus pour la mise à niveau Pectra ? Cela va-t-il aggraver l'inflation de l'ETH ?
Les EIP définis amélioreront la programmabilité des comptes, l'efficacité de la validation sur Ethereum et l'optimisation du staking, tandis que les EIP non définis se concentrent sur l'amélioration de l'extensibilité des L2.
Dédié à des analyses Web3 approfondiesRédaction : 0XNATALIE
La prochaine mise à niveau d'Ethereum, Pectra, tire son nom de la combinaison de « Prague » et « Electra ».
« Prague » représente la mise à niveau de la couche d'exécution, nommée d'après la ville hôte de la conférence des développeurs Ethereum (Devcon 4), tandis que « Electra » symbolise la mise à niveau de la couche de consensus, suivant une convention selon laquelle les étoiles sont nommées par ordre alphabétique. Le nom stellaire choisi cette fois, Electra, correspond à la lettre « E ».
Pectra, qui pourrait être le fork dur impliquant le plus grand nombre de propositions d'amélioration d'Ethereum (EIP) dans l'histoire du réseau, inclut non seulement une série de propositions visant à améliorer les opérations des validateurs et les performances du réseau principal, mais introduit également des propositions destinées à optimiser les solutions L2. Le testnet Pectra Devnet 4 vient d'être lancé, et huit EIP ont déjà été confirmés pour intégrer la mise à niveau Pectra.
EIP confirmées et leurs impacts
Ces huit EIP auront un impact sur les utilisateurs en : augmentant la flexibilité des comptes grâce à l’ajout de capacités d’exécution de code aux comptes externes (EOA), permettant des opérations plus complexes ; potentiellement accroître la demande en ETH via une hausse du plafond de mise en gage ; et en améliorant la sécurité, l’efficacité et les débits transactionnels d’Ethereum grâce à l’optimisation des processus des validateurs.
-
EIP-2537 (Prise en charge des signatures BLS) : Ajoute une série de précompilations pour supporter les opérations sur la courbe BLS12-381, permettant ainsi la vérification de signatures BLS et la possibilité d’agréger plusieurs signatures en une seule. Les signatures BLS sont un algorithme cryptographique produisant des signatures compactes et permettant leur agrégation. Cela bénéficiera particulièrement aux solutions L2 nécessitant de nombreuses opérations de vérification de signatures et de données.
-
EIP-2935 (Stockage des hachages de blocs historiques dans l’état) : Stocke les hachages des 8192 derniers blocs dans un contrat système afin de soutenir le modèle des clients sans état (Stateless Clients) et d’offrir une fonctionnalité plus souple de consultation des hachages de blocs historiques. Ces hachages peuvent être consultés directement depuis un contrat et fournis sous forme de preuve (witness) aux clients sans état, qui n’ont alors plus besoin de maintenir eux-mêmes l’historique complet de la blockchain ou de stocker d’importantes quantités de données.
-
EIP-6110 (Dépôts de validateurs sur la chaîne) : Transfère le traitement des dépôts de validateurs de la couche de consensus vers la couche d’exécution, où ils sont traités et validés directement sur la chaîne, sans dépendre d’un mécanisme de vote supplémentaire au niveau du consensus. Cela renforce la sécurité du processus de dépôt, réduit les délais et simplifie la conception de la couche de consensus et des clients.
-
EIP-7002 (Sortie déclenchée par la couche d’exécution) : Permet au propriétaire des informations d’encaissement de lancer indépendamment la procédure de sortie, sans dépendre de la clé active du validateur (clé BLS). Actuellement, seul le détenteur de la clé active peut initier une sortie. Si celle-ci est perdue ou si le validateur a délégué ses fonctions à un tiers (par exemple, un fournisseur de services de mise en gage), le propriétaire réel des fonds ne peut pas contrôler directement ses ETH mis en gage. Cette proposition permet d’initier les opérations de sortie et d’encaissement via la couche d’exécution, en utilisant simplement les informations d’encaissement.
-
EIP-7251 (Augmentation du plafond de mise en gage) : Augmente le solde effectif maximal autorisé par validateur, permettant ainsi à chaque validateur de détenir plus de 32 ETH en gage, tout en maintenant le seuil minimum requis à 32 ETH. L’objectif est de permettre aux grands opérateurs de nœuds de fusionner plusieurs validateurs, réduisant ainsi le nombre total de validateurs sur le réseau, ainsi que la charge liée aux messages P2P, à l’agrégation des signatures et au stockage.
-
EIP-7549 (Suppression de l’indice de comité des attestations) : Supprime le champ d’indice de comité des messages d’attestation (Attestation), permettant une agrégation plus efficace des votes de consensus. Actuellement, chaque attestation contient cet indice, ce qui fait que même lorsque plusieurs validateurs votent pour le même bloc, leurs signatures restent distinctes car signées avec des messages différents. En retirant cet indice du message signé, les votes peuvent être agrégés plus facilement, réduisant ainsi les coûts de validation et la charge réseau.
-
EIP-7685 (Demandes générales de la couche d’exécution) : Définit un cadre générique pour la couche d’exécution (EL) afin de stocker et traiter des demandes déclenchées par des contrats intelligents. Ce cadre permet de prendre en charge davantage de comportements déclenchés par la couche d’exécution, facilite le traitement uniforme de différents types de demandes et simplifie l’ajout de nouveaux types sans modifier la structure des blocs d’exécution.
-
EIP-7702 (Ajout de capacité d’exécution de code aux EOA) : Ajoute aux comptes externes (EOA) la possibilité d’exécuter du code, augmentant ainsi leur flexibilité et leur programmabilité. Un EOA peut, par signature autorisée, désigner un contrat intelligent pour exécuter certaines opérations comme des transactions groupées ou le contrôle d’autorisations, acquérant ainsi certaines fonctionnalités de contrat intelligent sans avoir à en devenir un.
EIP actuellement examinées
Voici quelques EIP actuellement étudiées, principalement centrées sur l’optimisation des blobs, visant à stabiliser les frais de publication de données pour les L2, renforcer leur capacité de traitement des transactions et réduire efficacement leurs coûts. Par ailleurs, l’augmentation du coût du calldata pourrait affecter la quantité d’ETH brûlée, augmentant ainsi la pression inflationniste sur ETH.
-
EIP-7742 (Dissociation du nombre de blobs entre les couches de consensus et d’exécution) : Dissocie le nombre de blobs entre les couches de consensus et d’exécution, simplifiant ainsi le processus de validation des blobs et réduisant la complexité inutile. Actuellement, les deux couches codent en dur la valeur maximale de blobs, entraînant des validations redondantes. Cette proposition supprime la validation du maximum de blobs au niveau de la couche d’exécution, qui reçoit désormais dynamiquement la cible de blobs de la couche de consensus. Cela permet une adaptation plus flexible des paramètres futurs en vue de l’évolutivité. L’EIP-7742 est celle suscitant le moins de controverses parmi les propositions envisagées, et lors de la dernière réunion de la couche de consensus, les développeurs ont convenu de commencer à l’implémenter dans pectra-devnet 5. Toutefois, sa confirmation finale dépendra des retours lors de la réunion ACDE (All Core Developers Execution Layer).
-
EIP-7762 (Frais de base minimum par blob) : Augmente MIN_BASE_FEE_PER_BLOB_GAS afin de réduire le temps nécessaire pour ajuster les prix des blobs à un niveau raisonnable. Actuellement fixé à 1 wei, ce minimum rend trop lent le processus de découverte du prix lorsque la demande excède l’offre. Une augmentation du prix minimum accélère l’équilibre du marché, assurant une stabilité du réseau même en période de forte demande.
-
EIP-7623 (Augmentation du coût du calldata) : Augmente le coût du calldata dans les transactions afin de réduire la taille maximale des blocs et sa variabilité, garantissant un traitement plus stable des transactions. Actuellement, la taille maximale d’un bloc est d’environ 1,79 Mo, mais elle augmente en moyenne à cause des volumes élevés de données publiées par les rollups. En augmentant le coût du calldata — principalement utilisé pour les transactions de disponibilité des données (DA) —, la taille maximale serait ramenée à environ 0,72 Mo, libérant ainsi de l’espace pour une future augmentation du plafond de gaz par bloc ou pour davantage de blobs. Le coût des transactions ordinaires reste inchangé ; cette modification concerne surtout les transactions impliquant de grands volumes de stockage de données sur Ethereum. Toutefois, cela pourrait affaiblir la compétitivité d’Ethereum pour le stockage de données. De plus, une hausse du coût du calldata pourrait réduire le nombre de transactions, diminuant ainsi la quantité d’ETH brûlée via le mécanisme EIP-1559, ce qui accentuerait la pression inflationniste sur ETH.
-
EIP-7782 (Réduction du temps du slot) : Réduit la durée du slot d’Ethereum de 12 à 8 secondes, générant ainsi des blocs plus fréquemment pour traiter davantage de transactions. Cette option pourrait servir d’alternative à l’augmentation du nombre de blobs pour améliorer le débit. Toutefois, cela risque de casser certains contrats intelligents codant en dur une durée de 12 secondes, et accélérerait le problème de croissance de l’état d’Ethereum, augmentant la charge de stockage et de calcul.
-
EIP-7783 (Augmentation progressive de la limite de gaz par bloc) : Présentée comme une alternative plus douce à l’EIP-7782, cette proposition vise à augmenter progressivement la limite de gaz par bloc, permettant ainsi de traiter davantage de transactions par bloc et d’améliorer la capacité du réseau. Comparée à la réduction directe du temps du slot, une augmentation progressive de la limite de gaz permettrait une extension plus fluide du réseau. Cette proposition ne nécessite pas de fork dur, mais pourrait néanmoins impacter les données d’état.
Étant donné que la mise à niveau Pectra comprend un grand nombre d’EIP, afin de réduire la complexité d’une mise à jour unique et d’accélérer le déploiement de certaines EIP, l’équipe d’ingénieurs EthPandaOps de la Fondation Ethereum avait suggéré en mai de diviser Pectra en deux parties, suggestion qui n’avait pas été prise au sérieux à l’époque par crainte de retarder la mise à niveau. En septembre, le chercheur Ethereum Alex Stokes a relancé cette idée, qui a cette fois trouvé l’assentiment des développeurs. Cette division permettrait de finaliser la première partie de la mise à niveau dans un délai de six mois :
-
Première partie : Comprend les EIP déjà en cours d’exécution sur le testnet Pectra Devnet — soit les huit EIP déjà confirmées — qui sont relativement simples à implémenter et ont déjà fait l’objet de nombreux tests.
-
Deuxième partie : Réserve les EIP plus complexes (comme celles liées à PeerDAS ou EOF) et celles nécessitant davantage de temps de test à une seconde phase. Ces propositions requièrent un développement, une auditabilité et des tests supplémentaires, en particulier celles impliquant une coordination entre les couches de consensus et d’exécution.
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
@ChainFeedsxyz
