Quelles EIP ont été confirmées pour l'intégration dans la mise à niveau Pectra ? Cela va-t-il aggraver l'inflation d'ETH ?

Les EIP déjà confirmés amélioreront la programmabilité des comptes, l'efficacité de la validation sur Ethereum et l'optimisation du staking, tandis que les EIP non confirmés se concentrent sur l'amélioration de l'évolutivité des L2.

Auteur : 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 qu'Electra symbolise la mise à niveau de la couche de consensus, les étoiles étant nommées par ordre alphabétique. Le nom d'étoile choisi cette fois, Electra, correspond à la lettre « E ».

La mise à niveau Pectra pourrait être le hard fork de l'histoire d'Ethereum impliquant le plus grand nombre d'Ethereum Improvement Proposals (EIP). Elle inclut non seulement une série de propositions visant à améliorer les opérations des validateurs et les performances du mainnet, mais introduit également des propositions d'optimisation pour les L2. Le testnet Pectra Devnet 4 vient d'être lancé, et 8 EIP ont déjà été confirmés pour inclusion dans la mise à niveau Pectra.

EIP confirmés et leurs impacts

L'impact de ces 8 EIP sur les utilisateurs se manifeste par : l'ajout de la capacité d'exécution de code aux EOA, ce qui augmente la flexibilité des comptes et leur permet d'effectuer des opérations plus complexes ; l'augmentation du plafond de staking pourrait accroître la demande pour ETH ; en même temps, l'optimisation du processus de validation améliore la sécurité et l'efficacité, augmentant la vitesse et le débit d'Ethereum.

1. EIP-2537 (prise en charge des signatures BLS) : En introduisant une série de contrats précompilés (precompiles), Ethereum prend en charge les opérations sur la courbe BLS12-381, permettant la vérification des signatures BLS et l'agrégation de plusieurs signatures en une seule, réduisant ainsi la complexité lors de la vérification. Les signatures BLS sont un algorithme cryptographique permettant de générer des signatures plus petites et de prendre en charge l'agrégation de signatures. Cela aidera les L2 nécessitant de nombreuses vérifications de signatures et de données à mieux fonctionner.
2. EIP-2935 (stockage des hash des blocs historiques dans l'état) : En stockant les hash des 8192 derniers blocs dans un contrat système, cela prend en charge le modèle Stateless Clients et offre une fonctionnalité de requête plus flexible pour les hash des blocs historiques. Ces hash peuvent être consultés directement via des contrats et fournis comme preuves (witness) aux clients sans état. Les clients n'ont pas besoin de maintenir l'historique complet de la blockchain ni de stocker de grandes quantités de données, ils peuvent vérifier la légitimité des blocs et des transactions en s'appuyant sur les hash stockés dans l'état et les preuves associées.
3. EIP-6110 (dépôts de validateurs on-chain) : Le traitement des dépôts de validateurs est transféré de la couche de consensus à la couche d'exécution, où ils sont traités et vérifiés on-chain, sans dépendre du mécanisme de vote supplémentaire de la couche de consensus pour confirmer la validité des informations de dépôt. Cela renforce la sécurité du processus de dépôt, réduit les délais de traitement et simplifie la conception de la couche de consensus et des clients.
4. EIP-7002 (retrait déclenché par la couche d'exécution) : Permet aux détenteurs de certificats de retrait d'initier un retrait de manière indépendante, sans dépendre de la clé active du validateur (clé BLS), augmentant ainsi l'autonomie des utilisateurs. Actuellement, seule la clé active du validateur peut déclencher un retrait, ce qui signifie qu'en cas de perte de la clé active ou si le validateur délègue la tâche à un tiers (comme un fournisseur de service de staking), le détenteur du certificat de retrait (c'est-à-dire le véritable propriétaire des fonds) ne peut pas contrôler de manière autonome le staking d'ETH. Cette proposition permet de déclencher le retrait et le retrait d'ETH via la couche d'exécution, le détenteur pouvant initier le retrait via le certificat, sans dépendre de la clé active.
5. EIP-7251 (augmentation du plafond de staking) : Augmente le solde effectif maximal des validateurs, permettant à chaque validateur de staker plus de 32 ETH, tout en maintenant le seuil minimum à 32 ETH. L'objectif est de permettre aux grands opérateurs de nœuds de réduire le nombre de validateurs sur le réseau en fusionnant plusieurs validateurs, réduisant ainsi la charge des messages P2P, l'agrégation des signatures et le stockage.
6. EIP-7549 (déplacement de l'index du comité hors de l'attestation) : En déplaçant le champ d'index du comité hors du message d'attestation, cela permet une agrégation plus efficace des votes de consensus. Actuellement, dans le mécanisme de consensus d'Ethereum, chaque validateur vote en incluant : un vote LMD GHOST (incluant la racine du bloc voté et le slot), un vote Casper-FFG (incluant les informations source et cible), et l'index du comité (numéro du comité auquel appartient le validateur). Comme l'index du comité est inclus dans le message signé, lorsque plusieurs validateurs votent pour le même bloc, même si leur contenu de vote est identique, la racine de la signature générée diffère, rendant l'agrégation difficile. En déplaçant l'index du comité hors du message signé, on permet une agrégation plus efficace des votes, réduisant les coûts de validation et la charge du réseau.
7. EIP-7685 (requêtes génériques 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 les requêtes déclenchées par des smart contracts. Ce cadre prend en charge davantage de comportements déclenchés par la couche d'exécution et permet de traiter de manière unifiée différents types de requêtes, simplifiant l'ajout de nouveaux types de requêtes sans modifier la structure des blocs d'exécution.
8. EIP-7702 (ajout de la capacité d'exécution de code aux EOA) : Ajoute la capacité d'exécution de code aux comptes externes (EOA), augmentant ainsi leur flexibilité et leur programmabilité. Les EOA peuvent, via une signature d'autorisation, désigner un smart contract pour exécuter certaines opérations en leur nom, telles que des transactions groupées ou le contrôle des permissions. Cela permet d'obtenir certaines fonctionnalités de smart contract sans avoir à convertir le compte en smart contract.

EIP en cours de considération

Voici quelques EIP activement considérés, principalement axés sur l'optimisation des blobs, ce qui améliore la stabilité des frais de publication des données L2, renforce la capacité de traitement des transactions L2 et réduit efficacement les coûts des L2. De plus, l'ajustement à la hausse du coût du calldata pourrait affecter la quantité d'ETH brûlée, augmentant la pression inflationniste sur ETH.

• EIP-7742 (découplage du comptage des blobs entre la couche de consensus et la couche d'exécution) : Découple le nombre de blobs entre la couche de consensus et la couche d'exécution, simplifie le processus de vérification des blobs, réduit la complexité inutile et améliore l'évolutivité et la flexibilité du protocole. Actuellement, la couche d'exécution et la couche de consensus codent en dur la valeur maximale des blobs, entraînant une vérification redondante. Cette proposition supprime la vérification du maximum de blobs par la couche d'exécution, la couche de consensus fournissant dynamiquement la valeur cible de blobs à la couche d'exécution. Cela permet d'ajuster plus facilement les paramètres cibles des blobs pour répondre aux besoins futurs d'évolutivité. L'EIP-7742 est la proposition la moins controversée parmi celles envisagées pour la mise à niveau. Selon la dernière réunion de la couche de consensus, les développeurs ont accepté de commencer à implémenter l'EIP-7742 dans pectra-devnet 5, mais son inclusion officielle dépendra du retour de la couche d'exécution lors de la réunion ACDE (All Core Devs Execution).
• EIP 7762 (frais de base minimum pour les blobs) : Augmente MIN_BASE_FEE_PER_BLOB_GAS afin de réduire le temps nécessaire pour ajuster le prix des blobs à un niveau raisonnable. Actuellement, le frais de base minimum pour les blobs est fixé à 1 wei ; lorsque la demande de blobs dépasse l'offre, le processus de découverte du prix (c'est-à-dire la détermination du prix du gaz pour les blobs) est trop lent et il faut beaucoup de temps pour atteindre un niveau de frais approprié. En augmentant le frais de base minimum, on peut accélérer l'ajustement des prix, atteindre plus rapidement l'équilibre du marché et garantir la stabilité du réseau lors des pics de 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 plage de variation, assurant ainsi un traitement plus fluide des transactions par le réseau. Actuellement, la taille maximale d'un bloc est d'environ 1,79 MB, mais en raison de la publication massive de données par des applications comme les rollups, la taille moyenne des blocs ne cesse d'augmenter. En augmentant le coût du calldata, principalement utilisé pour les transactions de disponibilité des données (DA), la taille maximale des blocs est réduite à environ 0,72 MB, laissant de la place pour une augmentation future de la limite de gaz des blocs ou pour plus de blobs. Le coût des transactions pour les utilisateurs ordinaires reste inchangé ; ce changement affecte principalement les types de transactions reposant sur Ethereum pour le stockage massif de données. Cependant, l'augmentation du coût du calldata pourrait réduire la compétitivité d'Ethereum dans le stockage de données. De plus, une augmentation du coût du calldata pourrait réduire le nombre de transactions, ce qui entraînerait une diminution de la quantité d'ETH brûlée via le mécanisme EIP-1559, augmentant ainsi la pression inflationniste sur ETH.
• EIP 7782 (réduction du temps de slot) : Réduit le temps de slot d'Ethereum de 12 secondes à 8 secondes, générant des blocs plus fréquemment pour traiter davantage de transactions, comme alternative à l'augmentation du nombre de blobs, afin d'améliorer le débit des transactions. Cependant, cela pourrait perturber certains smart contracts codés en dur pour un slot de 12 secondes et accélérer le problème de gonflement de l'état d'Ethereum, augmentant la charge de stockage et de calcul.
• EIP-7783 (augmentation progressive de la limite de gaz des blocs) : En tant qu'alternative plus douce à l'EIP-7782, ajuste dynamiquement la limite de gaz des blocs pour augmenter progressivement le nombre de transactions pouvant être incluses dans chaque bloc, améliorant ainsi la capacité de traitement du réseau. Par rapport à la réduction directe du temps de slot, l'ajustement progressif de la limite de gaz permet une expansion plus fluide du réseau. Cette proposition ne nécessite pas de hard fork, mais pourrait avoir un impact sur les données d'état.

En raison du grand nombre d'EIP inclus dans la mise à niveau Pectra, afin de réduire la complexité d'une seule mise à niveau et d'accélérer la mise en ligne de certains EIP, en mai, l'équipe d'ingénierie de la Fondation Ethereum, EthPandaOps, a suggéré de diviser Pectra en deux parties. Cependant, à l'époque, on craignait que cela ne retarde la mise à niveau, donc la proposition n'a pas été sérieusement envisagée. En septembre, le chercheur Ethereum Alex Stokes a de nouveau proposé la division, cette fois avec l'accord des développeurs, car cette approche aiderait à compléter la première partie de la mise à niveau en six mois :

• Première partie : Inclut les EIP déjà en fonctionnement sur le testnet Pectra Devnet (c'est-à-dire les 8 EIP déjà confirmés), qui sont relativement plus faciles à mettre en œuvre et ont déjà passé de nombreux tests.
• Deuxième partie : Les EIP plus complexes (tels que PeerDAS, les propositions liées à EOF) et d'autres propositions nécessitant plus de temps de test seront inclus dans la deuxième phase. Ces propositions nécessitent un développement, un audit et des tests supplémentaires, en particulier celles impliquant la coordination entre la couche de consensus et la couche d'exécution.