Faites suivre le titre original : Présentation du hard fork de Prague/Electra (Pectra)

introduire

Dans notre article précédent, nous avons examiné en détail le cycle de vie des validateurs Ethereum, en discutant de plusieurs aspects liés à la prochaine mise à jour Electra. Maintenant, il est temps de se concentrer sur les prochains changements apportés aux mises à jour Electra et Prague et de les expliquer en détail.

L'histoire des hardforks Ethereum 2.0 "preuve d'enjeu" est complexe. Elle a commencé avec l'ajout de la couche de balise à la couche d'exécution existante, lançant le consensus de preuve d'enjeu sur la couche de balise tout en maintenant toujours la preuve de travail sur la couche d'exécution (les hardforks Phase0 et Altair). La PoS a ensuite été entièrement activée lors du hardfork Bellatrix (bien que les retraits n'aient pas été activés). Par la suite, le hardfork Capella a permis les retraits, complétant le cycle de vie du validateur. Le hardfork le plus récent, Deneb (partie de la mise à niveau Dencun (Deneb/Cancun)), a apporté des révisions mineures aux paramètres de la chaîne de balise, tels que la fenêtre temporelle pour inclure des attestations, la gestion des sorties volontaires et la limite de rotation du validateur. Les principaux changements dans Dencun ont été apportés à la couche d'exécution, introduisant des innovations telles que les transactions de blob, le gaz de blob, les engagements KZG pour les blobs et la dépréciation de l'opération SELFDESTRUCT.

Maintenant, le hard fork Prague/Electra introduit des mises à niveau significatives à la fois dans les couches d'exécution et de consensus. En tant qu'auditeurs du projet Lido, notre attention se porte principalement sur les changements liés au consensus et au staking lors de ce hard fork. Cependant, nous ne pouvons pas ignorer les changements de la couche d'exécution à Prague, car ils incluent des fonctionnalités critiques qui impactent le réseau Ethereum et les validateurs. Plongeons dans les détails de ces changements.

Aperçu de haut niveau de Pectra

Electra introduit de nombreuses fonctionnalités pour la couche de balises. Les mises à jour principales comprennent :

• Permettant aux validateurs d'avoir un solde effectif variant de 32 à 2048 ETH (au lieu de 32 ETH fixe).
• Permettre aux validateurs d'initier des sorties avec des "retraits" secondaires (sans nécessiter la clé de validateur active).
• Changer la façon dont les dépôts Eth1 sont traités par la couche beacon (en s'éloignant de l'analyse des événements du contrat de dépôt).
• Ajout d'un nouveau framework polyvalent pour la gestion des demandes des contrats Eth1 réguliers sur la couche beacon (similaire à la gestion des dépôts avant Electra).

Pendant ce temps, Prague apporte des changements à la couche d'exécution, comme :

• Un nouveau contrat précompilé prenant en charge la courbe BLS12-381 pour vérifier les preuves zkSNARK (en plus de la courbe BN254 populaire).
• Un nouveau contrat système pour stocker et accéder à 8192 hachages de blocs historiques (utile pour les clients sans état).
• Augmentation des coûts de gaz de calldata pour réduire la taille des blocs et encourager les projets à déplacer les opérations intensives en calldata (comme les rollups) vers des blobs, qui ont été introduits dans Dencun.
• Prise en charge d'un plus grand nombre de blobs par bloc Eth1, ainsi qu'une API pour lire ces chiffres.
• Permettre aux EOAs (comptes détenus par des entités externes) d'avoir leur propre code de compte, étendant considérablement les capacités des EOAs, comme l'exécution de multi-appels ou la délégation de l'exécution à d'autres adresses.

Référons-nous aux propositions d'amélioration Ethereum (EIP) pertinentes pour faciliter la discussion ultérieure :

• EIP-7251: Augmentation du MAX_EFFECTIVE_BALANCE
• EIP-7002: Sorties déclenchantes de la couche d'exécution
• EIP-6110: Approvisionner les dépôts des validateurs sur la chaîne
• EIP-7549: Déplacez l'index du comité en dehors de l'attestation
• EIP-7685: Demandes de couche d'exécution à usage général
• EIP-2537 : Précompilation pour les opérations de courbe BLS12-381
• EIP-2935: Enregistrer les hachages des blocs historiques dans l'état
• EIP-7623: Augmenter le coût de la calldata
• EIP-7691: débit de blob augmenté
• EIP-7840: Ajouter un calendrier de blob aux fichiers de configuration EL
• EIP-7702: Définir le code du compte EOA

Certains de ces EIP abordent principalement la couche de consensus (beacon), tandis que d'autres concernent la couche d'exécution. Certains couvrent les deux couches, car certaines opérations telles que les dépôts et les retraits nécessitent des changements synchronisés à travers les couches de consensus et d'exécution. En raison de cette interdépendance, séparer Electra et Prague est impraticable, nous examinerons donc chaque EIP séquentiellement et spécifierons le composant Ethereum affecté dans chaque cas.

EIP-7251: Augmenter le MAX_EFFECTIVE_BALANCE

Référence : EIP-7251

Depuis le premier hardfork Phase0, mis en œuvre pour préparer Ethereum au Proof-of-Stake, et jusqu’à Electra, le solde effectif maximum d’un validateur a été fixé à 32 ETH. L’activation d’un validateur nécessite au moins le spec.min_activation_balance (32 ETH). Après l’activation, le validateur commence avec ce solde effectif maximal, mais peut réduire son solde effectif au spec.ejection_balance (16 ETH) et est éjecté lorsqu’il atteint ce seuil. Cette logique « minimale » reste inchangée dans Electra, mais maintenant le spec.max_effective_balance est passé à 2048 ETH. En conséquence, un validateur peut déposer entre 32 et 2048 ETH pour l’activation, tous les montants de cette fourchette contribuant à son solde effectif. Ce changement marque le passage d’une « preuve d’enjeu de 32 ETH » à une :) de « preuve d’enjeu »

Cet équilibre effectif variable sera désormais utilisé :

• pour augmenter la probabilité d'être un proposeur de bloc, proportionnellement au solde effectif
• pour augmenter la probabilité d'être membre du comité de synchronisation, proportionnellement au solde effectif
• comme base de calcul des montants relatifs aux pénalités de réduction et d'inactivité

Les deux premières activités sont les actions les plus gratifiantes pour les validateurs. Par conséquent, après Electra, les validateurs avec des enjeux plus importants participeront plus fréquemment à la proposition de blocs et aux comités de synchronisation, proportionnellement à leur solde effectif.

Un autre effet est lié aux slashings. Toutes les pénalités de slashing sont proportionnelles au solde effectif du validateur :

• Les pénalités de réduction « immédiate » et « différée » sont plus importantes pour les validateurs avec des enjeux plus élevés.
• Les pénalités de réduction « différée » pour les validateurs réduits aux côtés des validateurs à forte mise sont également plus importantes, car la fraction « réduite » de la mise totale devient plus importante.
• Un lanceur d'alerte qui signale un validateur avec un solde effectif plus élevé reçoit une plus grande fraction de l'enjeu réduit.

Electra propose également des changements dans les quotients de réduction, définissant une fraction du solde des validateurs étant réduit et reçu par le lanceur d'alerte.

Les effets d'inactivité viennent ensuite. Lorsqu'un validateur est hors ligne alors qu'il est actif (en attestation ou en proposition), un score d'inactivité s'accumule, ce qui entraîne des pénalités d'inactivité appliquées à chaque époque. Ces pénalités sont également proportionnelles au solde effectif du validateur.

Les limites de rotation des validateurs” connaissent également des changements en raison de l'augmentation des soldes effectifs. Dans l'Ethereum "pré-Electra", les validateurs ont généralement le même solde effectif, et la limite de rotation de sortie est définie comme étant "pas plus de 1/65536 (spec.churn_limit_quotient) du total des enjeux peuvent sortir en une époque." Cela crée un nombre "fixe" de sorties de validateurs avec le même enjeu. Cependant, dans le scénario "post-Electra", il est possible qu'uniquement quelques "baleines" sortent, car elles représentent une part importante du total des enjeux.

Une autre considération est la rotation de nombreuses clés de validation sur une seule instance de validateur. Les grands validateurs sont actuellement contraints de faire fonctionner des milliers de clés de validation sur une seule instance pour accommoder de gros enjeux, les divisant en parties de 32 ETH. Avec Electra, ce comportement n'est plus obligatoire. Financièrement, ce changement fait peu de différence puisque les récompenses et les probabilités augmentent de manière linéaire avec le montant misé. Ainsi, 100 validateurs avec 32 ETH chacun équivalent à un validateur avec 3200 ETH. De plus, plusieurs clés de validation actives peuvent avoir les mêmes informations de retrait Eth1, permettant à toutes les récompenses d'être retirées vers une seule adresse ETH et évitant les coûts de gaz associés à la consolidation des récompenses. Cependant, la gestion d'un grand nombre de clés entraîne des coûts administratifs supplémentaires.

La capacité de consolider les soldes des validateurs ajoute un autre type de demande de couche d'exécution. Auparavant, nous avions des dépôts et des retraits. Maintenant, il y aura un autre type : une demande de consolidation. Il fusionnera deux validateurs en un seul. Cette demande d'opération inclura la pubkey du validateur source et la pubkey cible, et sera traitée de manière similaire aux dépôts et retraits. Les consolidations auront également des demandes en attente et des limites de rotation de solde, tout comme les dépôts et les retraits.

Pour résumer :

• Pour les petits validateurs solo, Electra introduit la possibilité d'augmenter automatiquement leur solde effectif (et leurs récompenses). Auparavant, tout excédent supérieur à 32 ETH ne pouvait être retiré, mais après Electra, cet excédent contribuera finalement à leur solde effectif. Cependant, le solde effectif ne peut augmenter que par multiples de spec.effective_balance_increment (1 ETH), ce qui signifie que l'augmentation se produit uniquement après avoir atteint le prochain "1 ETH bound."
• Pour les grands validateurs solitaires, Electra offre une simplification significative de la gestion en permettant la consolidation de plusieurs clés de validateur actives en une seule. Bien que cela ne révolutionne pas le jeu, gérer une seule mise de 1x2048 est indéniablement plus simple que de gérer 64x32 mises.
• Pour les fournisseurs de validation liquide, qui rassemblent de petits enjeux des utilisateurs et les distribuent entre les validateurs, Electra ajoute plus de flexibilité dans les schémas de distribution des enjeux mais, en même temps, exige une refonte sérieuse de la comptabilité des validateurs, actuellement basée sur un solde effectif fixe de 32 ETH.

Un autre sujet important est les données historiques et l'estimation des profits pour les validateurs, ce qui est particulièrement pertinent pour les nouveaux participants essayant d'évaluer les risques et les rendements. Le plafond de 32 ETH (à la fois minimum et maximum, en pratique) avant Electra (au moment de la rédaction de cet article) a créé une uniformité dans les données historiques. Tous les validateurs avaient des soldes effectifs égaux, des récompenses, des pénalités de réduction individuelles, des fréquences de proposition de blocs et d'autres indicateurs égaux. Cette uniformité a permis à Ethereum de tester son mécanisme de consensus avec un grand nombre de validateurs sans valeurs aberrantes statistiques, recueillant des données précieuses sur le comportement du réseau.

Après Electra, la répartition des enjeux changera de manière significative. Les grands validateurs participeront plus souvent aux propositions de blocs et au comité de synchronisation, recevront des pénalités plus importantes lors d'événements de réduction, et auront une plus grande influence sur les réductions différées, les files d'activation et les files de sortie. Bien que cela puisse créer des défis en matière d'agrégation de données, le consensus d'Ethereum garantit que les calculs non linéaires sont minimes. Le seul composant non linéaire utilise sqrt(total_effective_balance) pour calculer la récompense de base, qui s'applique uniformément à tous les validateurs. Cela signifie que les récompenses et les réductions des validateurs peuvent encore être estimées sur une base "par 1 ETH" (ou, plus précisément, par incrémentation de l'effectif spécifique, qui pourrait potentiellement changer à l'avenir).

Pour plus de détails, veuillez vous référer à notre article précédent sur le comportement du validateur.

EIP-7002: Exits déclenchables de la couche d'exécution

Référence : EIP-7002

Chaque validateur dans Ethereum possède deux paires de clés : une clé active et une clé de retrait. La clé publique BLS active sert d'identité principale du validateur dans la chaîne de balises, et cette paire de clés est utilisée pour signer des blocs, des attestations, des réductions, des agrégats de comités de synchronisation, et (jusqu'à cette EIP) des sorties volontaires (pour initier la sortie du validateur du consensus après un délai). La deuxième paire de clés (« informations de retrait ») peut être une autre paire de clés BLS ou un compte Eth1 régulier (clé privée et adresse). Désormais, effectuer un retrait vers une adresse ETH nécessite un message de retrait signé par la clé privée BLS active. Cette EIP change cela.

En pratique, les propriétaires de ces deux paires de clés (active et de retrait) peuvent être différents. La clé active du validateur est responsable des tâches de validation : exécution des serveurs, maintien de leur opérationnalité, etc., tandis que les informations d'encaissement sont généralement contrôlées par le propriétaire de la mise, qui reçoit des récompenses et est responsable des fonds. Actuellement, un propriétaire de mise qui ne contrôle que les informations d'encaissement ne peut pas initier la sortie du validateur et ne peut que retirer des récompenses. Cette situation permet au propriétaire de la clé active du validateur de retenir effectivement l'équilibre du validateur en otage. Les validateurs peuvent « pré-signer » des messages de sortie et les donner aux propriétaires de mise, mais cette solution de contournement n'est pas idéale. De plus, les retraits et sorties exigent actuellement une interaction avec le validateur de la couche de balise en utilisant des API spécialisées.

La solution optimale consiste à permettre aux détenteurs de mise d'effectuer à la fois des opérations de sortie et de retrait à l'aide d'un appel de contrat intelligent régulier. Cela implique une vérification de signature Eth1 standard, simplifiant grandement les opérations.

Cet EIP permet aux propriétaires de stakes de déclencher des retraits et des sorties via une transaction standard à partir de leur adresse ETH vers un smart contract dédié (similaire au processus de dépôt existant qui utilise le contrat de « Dépôt »). Le processus de retrait (ou de sortie si suffisamment de stake est retiré) fonctionne comme suit :

• Le propriétaire de la participation envoie une demande de retrait (demande « in ») au contrat « Retraits » du système.
• Le contrat facture des frais spécifiques (en ETH) pour atténuer les attaques de griefing potentielles et fonctionne de manière similaire à EIP-1559, les frais augmentant lorsque la file d'attente des demandes est occupée.
• Le contrat enregistre la demande de retrait/sortie « in » dans son stockage.
• Lorsqu'un bloc est proposé à la couche beacon, les demandes de retrait/sortie en attente sont récupérées du stockage.
• La couche du phare traite les demandes "in", interagit avec le solde du validateur actif, planifie la sortie du validateur et forme les demandes de retrait "out".
• Les demandes de retrait "out" sont traitées sur la couche d'exécution, et le propriétaire de l'enjeu reçoit son ETH.

Alors que les dépôts étaient des opérations déclenchées dans les blocs Eth1 puis “déplacées” vers la couche Beacon en utilisant la file d'attente des dépôts “en attente”, les retraits suivaient un schéma différent. Ils étaient déclenchés au niveau de la couche Beacon (via l'interface en ligne de commande) puis “déplacés” vers les blocs Eth1. Désormais, les deux schémas fonctionneront en utilisant le même cadre générique (décrit ci-dessous) : création de demandes au niveau de la couche Eth1, traitement de la file d'attente des dépôts/retraits/consolidations “en attente” et traitement au niveau de la couche Beacon. Pour les opérations de “sortie” comme les retraits, la file de sortie est également traitée et les résultats sont “réglés” dans les blocs Eth1.

Avec cet EIP, les propriétaires de stake peuvent retirer et quitter leurs validateurs en utilisant des transactions ETH régulières sans avoir besoin d'interagir directement avec le CLI du validateur ou d'accéder à l'infrastructure des validateurs. Cela simplifie grandement les opérations de mise en jeu, en particulier pour les grands fournisseurs de mise en jeu. L'infrastructure des validateurs peut maintenant être presque entièrement isolée, car seules les clés de validateur actives doivent être maintenues, tandis que toutes les opérations de mise en jeu peuvent être gérées ailleurs. Cela élimine le besoin pour les miseurs solos d'attendre des actions de validateur actives et simplifie considérablement les parties hors chaîne pour des services comme le module de mise en jeu communautaire de Lido.

En conséquence, cette EIP « complète » les opérations de mise en jeu en les migrant entièrement vers la couche Eth1, réduisant considérablement les risques de sécurité de l'infrastructure et renforçant la décentralisation des initiatives de mise en jeu solo.

EIP-6110: Fournir des dépôts de validateur sur la chaîne

Référence: EIP-6110

Actuellement, les dépôts sont mis en œuvre via des événements dans le contrat “Deposit” du système (comme discuté en détail dans un article précédent). Le contrat accepte l'ETH et les informations d'identification du validateur, émet un événement “Deposit()”, et ces événements sont ensuite analysés et transformés en demandes de dépôt sur la couche de la balise. Ce système présente de nombreux inconvénients : il nécessite un vote pour eth1data sur la couche de la chaîne de balises, ce qui ajoute des retards significatifs. De plus, la couche de la balise doit interroger la couche d'exécution, introduisant une complexité supplémentaire. Ces problèmes sont discutés en détail dans l'EIP. Une méthode plus simple, éliminant bon nombre de ces problèmes, consiste à inclure directement les demandes de dépôt dans les blocs Eth1 à un emplacement désigné. Ce mécanisme reflète le processus de traitement des retraits décrit dans l'EIP précédent.

Les changements proposés dans ce EIP sont prometteurs. Le traitement des données eth1data peut maintenant être entièrement supprimé, éliminant ainsi la nécessité de voter ou de longs retards entre les événements du côté Eth1 et l'inclusion des dépôts sur la couche de balise (actuellement d'environ 12 heures). Il supprime également la logique des instantanés de contrat de dépôt. Cet EIP rationalise le traitement des dépôts et l'aligne sur le schéma de traitement des retraits décrit ci-dessus.

Pour les propriétaires de jetons et les validateurs, ces changements réduisent considérablement le délai entre un dépôt et l'activation du validateur. Les recharges, nécessaires lorsqu'un validateur est pénalisé, seront également plus rapides.

Il n'y a pas grand-chose de plus à dire sur cet EIP si ce n'est qu'il supprime la logique obsolète, simplifie les processus et crée de meilleurs résultats pour tous les intervenants.

EIP-7685: Demandes de couche d'exécution à usage général

Référence : EIP-7685

Cet EIP aurait sans doute dû être présenté avant les trois précédents EIP liés aux dépôts/retraits/consolidations, car il pose les bases pour eux. Cependant, il est introduit ici pour souligner le besoin croissant de mécanismes génériques permettant de déplacer de manière cohérente des données spécialisées entre les blocs (couches) de la chaîne Eth1 (exécution) et Beacon (consensus). Cet EIP affecte les deux couches, rendant le traitement des demandes déclenchées par des transactions ETH régulières plus efficace. Actuellement, nous observons:

• Les événements de dépôt dans les blocs Eth1 sont « déplacés » des blocs Eth1 aux blocs Beacon pour traitement.
• Les demandes de retrait dans les blocs Beacon (utilisant CLI) sont "déplacées" vers les blocs Eth1 pour traitement.
• Le besoin de gérer les consolidations des validateurs, qui sont également les demandes Eth1->Beacon.

Ces trois opérations démontrent la nécessité d'une gestion cohérente des différents types de demandes lors de leur transition entre les couches d'exécution et de balise. De plus, nous avons besoin de la capacité de déclencher ces opérations uniquement à l'aide de la couche Eth1, car cela nous permettra d'isoler l'infrastructure des validateurs de l'infrastructure de gestion des enjeux, renforçant la sécurité. Par conséquent, une solution générique pour la gestion de telles demandes est à la fois pratique et essentielle.

Cet EIP établit un cadre pour au moins trois cas principaux : les dépôts, les retraits et les consolidations. C'est pourquoi les EIP précédents ont introduit des champs tels que WITHDRAWAL_REQUEST_TYPE et DEPOSIT_REQUEST_TYPE, et maintenant les consolidations ajouteront un autre, CONSOLIDATION_REQUEST_TYPE. De plus, cet EIP inclura probablement des mécanismes communs pour gérer les limites de telles demandes (constants de référence : PENDING_DEPOSITS_LIMIT, PENDING_PARTIAL_WITHDRAWALS_LIMIT, PENDING_CONSOLIDATIONS_LIMIT).

Bien que les détails spécifiques de mise en œuvre de ce cadre ne soient pas encore disponibles, il intègrera certainement des types de demandes clés, des mécanismes d'intégrité (par exemple, le hachage et la merkleisation des demandes), ainsi que le traitement de la file d'attente en attente avec limitation du débit.

Ce EIP revêt une importance architecturale, permettant à Eth1 de déclencher des actions critiques dans la couche Beacon à travers un cadre unifié. Pour les utilisateurs finaux et les projets, cela signifie que toutes les demandes déclenchées au niveau Eth1 seront livrées et traitées sur la couche Beacon de manière beaucoup plus efficace.

EIP-2537: Précompilation pour les opérations de courbes BLS12-381

Référence : EIP-2537

Si vous ne voulez pas plonger trop profondément, vous pouvez envisager le précompilé BLS12-381 comme une opération cryptographique complexe de "hachage" qui peut désormais être utilisée dans les contrats intelligents. Pour ceux qui sont intéressés, explorons cela plus en détail.

Les opérations mathématiques sur les courbes elliptiques comme BLS12-381 (et sa contrepartie: BN-254) sont actuellement utilisées à deux fins principales:

• Les signatures BLS, où une opération spéciale appelée "appariement" est utilisée pour vérifier ces signatures. Les signatures BLS sont largement utilisées par les validateurs car elles permettent l'agrégation de plusieurs signatures en une seule. Les validateurs s'appuient sur les signatures BLS basées sur la courbe BLS12-381 (bien qu'elles puissent également être mises en œuvre en utilisant n'importe quelle courbe prenant en charge les appariements, telle que BN254).
• La vérification des preuves zkSNARK, où les appariements sont utilisés pour valider les preuves. De plus, les engagements KZG aux blobs (introduits par la fourche dure Dencun) utilisent également des appariements pour vérifier les engagements des blobs.

Si vous souhaitez vérifier une signature BLS ou une preuve zkSNARK au sein d'un smart contract, vous devez calculer ces « appariements » qui sont coûteux en termes de calcul. Ethereum dispose déjà d'un contrat précompilé pour les opérations de courbe BN254 (EIP-196 et EIP-197). Cependant, la courbe BLS12-381 (reconnue comme étant plus sécurisée et beaucoup plus largement utilisée aujourd'hui) n'a pas été implémentée en tant que précompilée. Sans une telle précompilation, implémenter des appariements et d'autres opérations de courbe dans des smart contracts nécessite des calculs lourds, comme le montre cet exemple, et consomme d'énormes quantités de gaz (~10^5 à 10^6 gaz).

Cette EIP ouvre la porte à de nombreuses applications potentielles, notamment en permettant une vérification bon marché des signatures BLS basées sur la courbe BLS12-381. Cela rend possible la mise en œuvre de schémas de seuil à des fins diverses. Comme mentionné précédemment, les validateurs Ethereum utilisent déjà des signatures basées sur BLS12-381. Avec cette EIP, les contrats intelligents standard peuvent désormais effectuer une vérification efficace des signatures de validateur agrégées. Cela peut simplifier les preuves de consensus et la mise en relation d'actifs entre les réseaux, car les signatures BLS sont largement utilisées dans les blockchains. Les signatures BLS de seuil elles-mêmes permettent la construction de nombreux schémas de seuil efficaces pour le vote, la génération de nombres aléatoires décentralisée, les multisignatures, etc.

La vérification moins chère de la preuve zkSNARK débloquera à son tour de nombreuses applications. De nombreuses solutions basées sur zkSNARK sont actuellement entravées par les coûts élevés de la vérification de la preuve, rendant certains projets presque impraticables. Ce EIP a le potentiel de changer cela.

EIP-2935: Enregistrer les hachages des blocs historiques dans l'état

Référence: EIP-2935

Cette EIP propose de stocker 8192 (~27,3 heures) hachages de blocs historiques dans l'état de la blockchain, offrant ainsi un historique étendu pour les clients sans état (tels que les rollups) et les contrats intelligents. Elle suggère de conserver le comportement actuel de l'opcode BLOCKHASH, en maintenant la restriction à 256 blocs, tout en introduisant un nouveau contrat système spécialement conçu pour stocker et récupérer les hachages historiques. Ce contrat effectue une opération set() lorsque la couche d'exécution traite un bloc. Sa méthode get(), accessible à tous, récupère le hachage de bloc requis à partir d'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 blocs les plus récents (~50 minutes). Cependant, il existe des cas où l'accès aux données de blocs plus anciens est essentiel, comme pour les applications inter-chaînes (qui nécessitent la validation des données des blocs précédents) et les clients sans état, qui ont périodiquement besoin d'accéder aux hachages de blocs antérieurs.

Cet EIP étend l'horizon temporel disponible pour les rollups et les applications inter-chaînes, leur permettant d'accéder directement aux données historiques dans l'EVM sans avoir besoin de les collecter de manière externe. En conséquence, ces solutions deviennent plus robustes et durables.

EIP-7623: Augmenter le coût des données d'appel

Référence : EIP-7623

Les coûts de calldata régulent la taille disponible des charges utiles de transaction, qui peuvent parfois être assez importantes (par exemple, lors du passage de grands tableaux ou tampons binaires en tant que paramètres). Une utilisation significative de calldata est principalement attribuée aux rollups, qui envoient des charges utiles via calldata contenant l'état actuel du rollup.

La capacité d'introduire de grandes données binaires pouvant être prouvées dans la blockchain est essentielle pour les rollups. La mise à niveau de Dencun (Deneb-Cancun) a introduit une innovation majeure pour de tels cas d'utilisation - les transactions blob (EIP-4844). Les transactions blob ont leurs propres frais de gaz dédiés «blob», et tandis que leurs corps sont stockés temporairement, leurs preuves cryptographiques (engagements KZG), ainsi que leurs hachages, sont intégrés dans la couche de consensus. Ainsi, les blobs fournissent une solution supérieure pour les rollups par rapport à l'utilisation de calldata pour le stockage de données.

Encourager les rollups à faire la transition de leurs données en blobs peut être réalisé en utilisant une approche de "la carotte et le bâton". Les frais de gaz réduits des blobs servent de "carotte", tandis que cet EIP fonctionne comme le "bâton" en augmentant les coûts de calldata, décourageant ainsi le stockage excessif de données dans les transactions. Cet EIP complète le prochain EIP-7691 (Augmentation du débit des blobs), qui augmente le nombre maximum de blobs autorisés par bloc.

EIP-7691: Augmentation du débit du blob

Référence: EIP-7691

Les objets blob ont été introduits dans le hard fork précédent de Dencun, et les valeurs initiales du nombre maximal et cible d’objets blob « par bloc » étaient des estimations prudentes. Cela était dû à la complexité de prédire comment le réseau p2p gérerait la propagation d’objets binaires volumineux entre les nœuds de validation. La configuration initiale s’est avérée efficace, ce qui en fait le moment idéal pour tester de nouvelles valeurs. Auparavant, le nombre cible/maximal d’objets blob par bloc était fixé à 3/6. Ces limites sont maintenant portées à 6/9, respectivement.

Lorsqu'il est combiné avec l'EIP-7623 précédent (Augmentation du coût des données d'appel), cet ajustement motive davantage les rollups à transitionner leurs données de calldata à des blobs. La recherche des paramètres de blob optimaux se poursuit.

EIP-7840: Ajouter un programme de blob aux fichiers de configuration EL

Référence : EIP-7840

Cette EIP propose d'ajouter la cible et le nombre maximum de blocs "par bloc" (discutés précédemment) et les valeurs baseFeeUpdateFraction dans les fichiers de configuration de la couche d'exécution Ethereum (EL). Il permet également aux clients de récupérer ces valeurs via l'API du nœud. Cette fonctionnalité est particulièrement utile pour des tâches telles que l'estimation des frais de gaz de blob.

EIP-7702: Définir le code du compte EOA

Référence : EIP-7702

Il s’agit d’un EIP très important qui apportera des changements majeurs pour les utilisateurs d’Ethereum. Comme nous le savons, un EOA (Externally Owned Account) ne peut pas avoir de code mais peut fournir une signature de transaction (tx.origin). En revanche, un smart contract a un bytecode mais ne peut pas mettre en avant « sa » signature directe. Toute interaction d’un utilisateur qui nécessite une logique supplémentaire, automatique et vérifiable ne peut actuellement être réalisée qu’en appelant un contrat externe pour effectuer les actions requises. Cependant, dans de tels cas, le contrat externe devient l’expéditeur msg.sender pour les contrats suivants, ce qui fait de l’appel « un appel à partir d’un contrat, et non de l’utilisateur ».

Cet EIP introduit un nouveau type de transaction SET_CODE_TX_TYPE=0x04 (nous avions auparavant les anciennes transactions 0x1, les transactions 0x02 plus récentes des mises à niveau Berlin et EIP-1559, et les transactions d’objets blob 0x03 introduites dans Dencun). Ce nouveau type de transaction permet de définir le code d’un compte EOA. Essentiellement, il permet à un EOA d’exécuter du code externe « dans le contexte de son propre compte EOA ». D’un point de vue externe, il semble que, lors d’une transaction, l’EOA « emprunte » du code à un contrat externe et l’exécute. Techniquement, cela est rendu possible par l’ajout de tuples de données d’autorisation spéciaux au stockage de « code » de l’adresse EOA (avant cette EIP, ce stockage de « code » était toujours vide pour les EOA).

Actuellement, cette EIP propose que le nouveau type de transaction 0x04 inclue un tableau :

authorization_list = [[chain_id, address, nonce, y_parity, r, s], …]

où chaque élément permet au compte d'utiliser le code de l'adresse spécifiée (du dernier élément d'autorisation valide). Le traitement d'une telle transaction définit le code de l'EOA donné à une valeur spéciale 0xef0100 || adresse (23 octets), où l'adresse pointe vers un contrat avec le code désiré à exécuter, || représente la concaténation et 0xef0100 représente une valeur magique spéciale que les contrats intelligents réguliers ne peuvent pas contenir (selon l'EIP-3541). Cette valeur magique garantit que cet EOA ne peut pas être traité comme un contrat régulier ou recevoir des appels en tant que tel.

Lorsque ce EOA initie une transaction, l'adresse spécifiée sera utilisée pour appeler le code correspondant dans le contexte de ce EOA. Bien que les détails complets de mise en œuvre de cette EIP ne soient pas encore connus, il est certain qu'elle apportera des changements significatifs.

Un impact majeur est de permettre la capacité de passer des appels multiples directement depuis un EOA. Les appels multiples sont une tendance croissante dans la DeFi, de nombreux protocoles offrant cette fonctionnalité comme un outil puissant (des exemples incluent Uniswap V4, Balancer V3 ou Euler V2). Avec cet EIP, les appels multiples peuvent désormais être effectués directement depuis des EOAs.

Par exemple, cette nouvelle fonctionnalité résout un problème courant dans DeFi : l'inefficacité de l'approbation() + de anything() qui nécessite deux transactions distinctes. Cet EIP permet une logique de "pré-approbation" générique, permettant des actions telles que l'approbation(X) + le dépôt(X) d'être complétées en une seule transaction.

Un autre avantage introduit par la possibilité de déléguer l'exécution des transactions "au nom" d'un EOA est le concept de parrainage. Les parrainages sont fréquemment discutés et des fonctionnalités très recherchées pour intégrer de nouveaux utilisateurs à Ethereum.

La logique programmable associée à un EOA ouvre de nombreuses possibilités, telles que la mise en place de restrictions de sécurité, la définition de limites de dépenses, l'application des exigences de KYC, et bien plus encore.

Naturellement, ce changement soulève également de nombreuses questions de conception. Une question concerne l'utilisation de chain_id, qui détermine si la même signature peut être valide ou non sur plusieurs réseaux en fonction de son inclusion ou de son exclusion dans la signature. Une autre question complexe est de savoir s'il faut utiliser l'adresse du code cible ou incorporer le bytecode réel. Les deux approches ont des caractéristiques et des limites uniques. De plus, l'utilisation du nonce joue un rôle clé dans la définition de l'autorisation comme "multi-usage" ou "mono-usage". Ces éléments influencent les fonctionnalités et les préoccupations en matière de sécurité, y compris des aspects tels que l'invalidation massive des signatures et la facilité d'utilisation. Vitalik a soulevé ces questions dans une discussion (ici), qui méritent d'être explorées plus en détail.

Il est crucial de noter que ce changement aura un impact sur l'un des mécanismes de sécurité d'Ethereum, tx.origin. D'autres détails sur la mise en œuvre de cet EIP sont nécessaires, mais il semble que le comportement de require(tx.origin == msg.sender) va changer. Cette vérification a été le moyen le plus fiable de s'assurer que msg.sender est un EOA et NON un contrat. D'autres méthodes, telles que la vérification de EXTCODESIZE (pour vérifier s'il s'agit d'un contrat), échouent souvent et peuvent être contournées (par exemple, en appelant depuis un constructeur ou en déployant du code à une adresse prédéfinie après une transaction). Ces vérifications ont été utilisées pour prévenir les attaques de rentrée et de prêt éclair, mais elles sont loin d'être idéales car elles entravent également les intégrations avec des protocoles externes. Après cet EIP, même la vérification fiable require(tx.origin == msg.sender) semble devenir obsolète. Les protocoles doivent s'adapter en supprimant de telles vérifications, car la distinction entre "EOA" et "contrat" ne s'appliquera plus — désormais chaque adresse peut potentiellement avoir un code associé.

La traditionnelle séparation entre les comptes externes (EOA) et les contrats intelligents continue de s'estomper. Cette EIP rapproche Ethereum de conceptions comme TON, où chaque compte est essentiellement un code exécutable. Cette évolution est naturelle alors que les interactions avec les protocoles deviennent de plus en plus complexes, ce qui rend nécessaire l'utilisation d'une logique programmable pour améliorer l'expérience utilisateur (UX) pour les utilisateurs finaux.

Conclusion

La mise à niveau de Prague/Electra (Pectra) est prévue pour mars 2025. Ses changements planifiés les plus importants incluent :

• la mise effective des validateurs variables, jusqu'à 2048 ETH, ce qui modifiera significativement la distribution des mises, les plannings des validateurs, et simplifiera la gestion pour les grands fournisseurs de mise en consolidant les mises plus petites
• amélioration de l'interaction entre la couche d'exécution et de consensus, rationalisant l'échange de données entre les blocs d'exécution Eth1 et les blocs de la chaîne Beacon. Cela simplifiera grandement les dépôts, les activations, les retraits et les sorties, accélérant ces processus et posant les bases pour de nouvelles interactions entre les couches de consensus et d'exécution
• prise en charge de la signature BLS moins chère et des vérifications zkSNARK directement dans les contrats intelligents grâce à la nouvelle précompilation BLS12-381 « conviviale pour l’appairage »
• Continuer d’encourager les correctifs cumulatifs à adopter les transactions d’objets blob au lieu de CallData en augmentant les seuils de transaction d’objets blob et en augmentant les coûts des données d’appel.
• permettant aux EOAs d'agir en tant que comptes programmables, leur donnant des fonctionnalités telles que les appels multiples, les parrainages et d'autres fonctionnalités avancées

Comme vous pouvez le constater, Pectra aura un impact significatif à la fois sur les couches de jalonnement et de consensus, ainsi que sur l’expérience de l’utilisateur final au niveau de la couche d’exécution. Bien que nous ne puissions pas analyser tous ces changements en détail à travers le code à ce stade, comme le développement est en cours, nous couvrirons ces mises à jour dans de futurs articles.

Avertissement:

1. Cet article est reproduit à partir de [ TechFlow]. Transférer le titre original : L'hard fork Prague/Electra (Pectra) expliqué. Les droits d'auteur appartiennent à l'auteur original [MixBytes (en anglais)]. Si vous avez des objections à la réimpression, veuillez contacter Équipe d'apprentissage Gate, et l'équipe s'en chargera dès que possible selon les procédures pertinentes.
2. Avis de non-responsabilité: Les points de vue et opinions exprimés dans cet article ne représentent que les points de vue personnels de l'auteur et ne constituent pas un conseil en investissement.
3. Les autres versions linguistiques de l'article sont traduites par l'équipe d'apprentissage de la porte. Sauf indication contraire, l'article traduit ne peut être copié, distribué ou plagié.