Parse Ethereum Hard Forks d’Ethereum – mise à niveau de PECTRA

introduire

Dans notre article précédent, nous avons passé en revue le cycle de vie de Ethereum Validator en détail, en discutant de plusieurs aspects liés à la prochaine Fork Electra Hard Fork.Maintenant, il est temps de se concentrer sur les changements dans les prochaines mises à niveau Electra et Prague et de les expliquer en détail.

L’histoire de la fourche dure de la «preuve de pieu» Ethereum 2.0 est compliquée.Il commence par l’ajout d’une couche de balise à la couche d’exécution existante, qui maintient la preuve de travail (Phase0 et Altair Hard Forks) tandis que la couche de balise initie le consensus de preuve de pieu.Par la suite, le POS est entièrement activé dans la fourche dure Bellatrix (bien que le retrait n’est pas activé).Ensuite, Capella Hard Fork permet les retraits, terminant le cycle de vie du validateur.Les fourches dures récentes Deneb (partie de la mise à niveau Dencun (Deneb / Cancun)) ont fait des révisions mineures des paramètres de la chaîne de balises, tels que les fenêtres temporelles contenant des preuves, la gestion des sorties volontaires et les restrictions de remplacement du validateur.Les principaux changements de Dencun se produisent sur la couche d’exécution, le lancement de transactions Blob, le gaz blob, les promesses KZG pour les blobs et l’abandon des opérations d’autodestruction.

Maintenant, la fourche dure Prague / Electra (c’est-à-dire PECTRA) introduit des mises à niveau importantes aux couches d’exécution et de consensus.En tant qu’auditeurs du projet Lido, nous nous concentrons principalement sur le consensus et les changements liés à la jalonnement dans cette fourche dure.Cependant, nous ne pouvons pas ignorer les changements de couche d’exécution dans Prague, car ils incluent des fonctionnalités importantes qui affectent le réseau Ethereum et les validateurs.Préparez-nous dans les détails de ces modifications.

Un aperçu de niveau supérieur de PECTRA

Electra présente de nombreuses fonctionnalités à la couche de balise.Les principales mises à jour comprennent:

Permet à l’équilibre valide du vérificateur de varier entre 32 et 2048 ETH (plutôt qu’un 32 FIX ETH).
Permet aux vérificateurs d’initier des sorties via des bons « Retrait » secondaire (la clé de vérificateur actif n’est plus requise).
Modifier la façon dont la couche de balise gère les dépôts ETH1 (l’événement n’est plus analysé du contrat de dépôt).
Ajoutez un nouveau cadre commun pour gérer les demandes de contrats ETH1 réguliers sur la couche de balise (similaire à la gestion des dépôts pré-électra).

Pendant ce temps, Prague a introduit les modifications suivantes à la couche d’exécution:

Un nouveau contrat précompilé qui soutient la courbe BLS12-381 pour vérifier les preuves Zksnark (à l’exception de la courbe populaire BN254).
Un nouveau contrat système pour le stockage et l’accès jusqu’à 8192 hachages de blocs historiques (très utiles pour les clients apatrides).
Augmenter les coûts de gaz CallData pour réduire la taille des blocs et encourager les projets à migrer des opérations à forte intensité de calldata telles que Rollup vers des blobs introduits dans Dencun.
Prend en charge plus de blobs par bloc eth1 et fournit une API pour lire ces chiffres.
Permettre à l’EOA (compte détenu externe) d’avoir son propre code de compte élargit considérablement ce que l’EOA peut faire, comme exécuter des multitals ou déléguer une exécution à d’autres adresses.

Passons à la proposition d’amélioration éthereum (EIP) pertinente pour une discussion plus approfondie:

EIP-7251: ajouté max_effective_balance
EIP-7002: la couche d’exécution déclenche la sortie
EIP-6110: le dépôt de vérificateur est fourni à la chaîne
EIP-7549: Déplacez l’indice du comité de la preuve
EIP-7685: Demande de couche d’exécution générale
EIP-2537: précompilation du fonctionnement de la courbe BLS12-381
EIP-2935: Sauver le hachage du bloc historique dans l’état
EIP-7623: augmenter le coût de calldata
EIP-7691: augmentation du débit blob
EIP-7840: ajout de calendrier blob au fichier de configuration EL
EIP-7702: Configuration du code du compte EOA

Certains de ces EIP impliquent principalement la couche de consensus (balise), tandis que d’autres sont liées à la couche d’exécution.Certains s’étendent sur deux couches, car certaines opérations (telles que les dépôts et les retraits) nécessitent des changements synchrones entre le consensus et les couches d’exécution.En raison de cette interdépendance, il n’est pas pratique de séparer l’Electra et Prague, nous examinerons donc chaque EIP et spécifierons les composants Ethereum affectés dans chaque cas.

EIP-7251: ajouté max_effective_balance

Référence: EIP-7251

Depuis la première fourche du hard phase0, afin de préparer la preuve de participation pour Ethereum, le solde maximal valide du vérificateur a été fixé à 32 ETH jusqu’à Electra.Activez les exigences du vérificateur au moins Spec.min_activation_balance (32 ETH).Après l’activation, le validateur commence par cet équilibre valide maximal, mais peut réduire son équilibre valide à Spec.ejection_balance (16 eth) et être expulsé lorsque ce seuil est atteint.Cette logique « minimum » reste inchangée dans Electra, mais maintenant spec.max_effective_balance a été augmentée à 2048 eth.Par conséquent, le validateur peut déposer entre 32 et 2048 ETH pour activer, qui contribueront tous leur solde valide.Ce changement marque le passage de « 32eth-froof of pieu » à « preuve de pieu » 🙂

Ce solde valide variable sera désormais utilisé pour:

Augmenter la probabilité de devenir un proposant de blocs, proportionnel à l’équilibre effectif
Augmenter la probabilité de devenir membre du comité synchrone, proportionnel à l’équilibre effectif
Comme base pour calculer la quantité de coupes relatives et de pénalités inactives

Les deux premières activités sont les actions les plus gratifiantes pour les validateurs.Par conséquent, après Electra, les validateurs d’un grand jalonnement participeront plus fréquemment aux comités de proposition et de synchronisation des blocs, avec une fréquence proportionnelle à leur équilibre efficace.

Un autre impact a à voir avec les coupes.Toutes les coupes sont proportionnelles à l’équilibre valide du vérificateur:

Les coupes « immédiates » et « retard » sont encore plus grandes pour les validateurs de participations élevées.
Les amendes de coupe «retardées» avec des validateurs de coupure avec des engagements élevés sont également plus importants, car la partie «coupure» de l’engagement total devient plus grande.
Les dénonciateurs qui déclarent les validateurs avec des soldes plus élevés valides reçoivent une plus grande proportion de enjeux réduits.

Electra a également proposé des modifications du rapport de coupe, définissant une partie de l’équilibre du validateur réduit et la réceptant par le dénonciateur.

Vient ensuite l’impact de l’invalidité.Lorsque le validateur est hors ligne lorsqu’il est actif (prouver ou proposer), le score d’invalidité s’accumule, entraînant l’imposition d’une pénalité d’invalidité pour chaque cycle.Ces pénalités ont également à voir avec le solde valide du validateurProportionrelation.

En raison de l’augmentation de l’équilibre valide, la « limite de remplacement » du vérificateur a également changé.Dans Ethereum « Avant Electra », les validateurs ont généralement le même équilibre valide, et la limite de remplacement de sortie est définie comme « Dans un cycle, il ne peut pas y avoir un maximum de la participation totale. » Crée un nombre « fixe » de sorties de vérificateur avec le même pieu.Cependant, après Electra, il ne peut y avoir que quelques « baleines » car elles représentent une partie importante de l’engagement total.

Une autre considération est la rotation de nombreuses clés de vérificateur sur une seule instance de vérificateur.Les grands validateurs sont actuellement obligés d’exécuter des milliers de clés de validateur sur une instance pour accueillir un grand stimulation, en les divisant en 32 sections d’ETH.Avec Electra, ce comportement n’est plus obligatoire.D’un point de vue financier, ce changement a peu d’impact car les récompenses et la probabilité sont à l’échelle linéairement avec la quantité de gage.Par conséquent, 100 validateurs par 32 ETH équivalent à un 3200 ETH.De plus, plusieurs clés de vérificateur actif peuvent avoir le même diplôme de retrait ETH1, permettant à toutes les récompenses d’être retirées à une seule adresse ETH, évitant les coûts de gaz associés aux fusions de récompenses.Cependant, la gestion de grandes quantités de clés entraîne des coûts administratifs supplémentaires.

La possibilité d’agréger les équilibres du validateur ajoute un nouveau type de demande de couche d’exécution.Avant, nous avions des dépôts et des retraits.Maintenant, il y aura un autre type: demande agrégée.Il combine deux validateurs en un.Cette demande d’opération comprendra la clé publique du vérificateur source et la clé publique cible et sera traitée de manière similaire aux dépôts et retraits.Les agrégations auront également des demandes en attente et des restrictions de remplacement de l’équilibre, tout comme les dépôts et les retraits.

Le résumé est le suivant:

Pour les petits validateurs indépendants, Electra introduit la capacité d’augmenter automatiquement leur équilibre (et récompenses) efficaces.Auparavant, tout excédent dépassant 32 ETH ne pouvait être retiré, mais après Electra, cet excédent contribuera éventuellement à son équilibre efficace.Cependant, l’équilibre effectif ne peut qu’augmenter les multiples de Spec.Effective_Balance_Increment (1 ETH), ce qui signifie que l’augmentation ne se produit qu’après la prochaine « limite ETH 1.
Pour les grands validateurs indépendants, Electra fournit une simplification de gestion significative en permettant à plusieurs clés de validateurs actifs d’être consolidés en un seul.Bien que cela ne changera pas le jeu, l’exploitation d’une pieu 1×2048 est sans aucun doute beaucoup plus facile que de gérer des enjeux 64×32.
Pour les fournisseurs d’allumage mobile, qui recueillent un petit jalonnement des utilisateurs et allouent entre les validateurs, Electra ajoute plus de flexibilité dans le schéma d’allocation de mise en œuvre, mais nécessite également la prise en compte des validateurs en fonction des balances fixes de 32 ETH, effectué un refactorisation sévère.

Un autre sujet important est l’estimation historique des données et des bénéfices des validateurs, particulièrement pertinents pour les nouveaux participants, qui tentent d’évaluer les risques et les récompenses.Avant Electra (à ce jour), le 32 CAP ETH (à la fois le plus petit ou le plus important, réellement) a créé l’uniformité dans les données historiques.Tous les validateurs ont le même équilibre de validation, les récompenses, les pénalités de coupe individuelles, la fréquence des propositions de blocs et d’autres mesures.Cette uniformité permet à Ethereum de tester son mécanisme de consensus sans valeurs aberrantes, collectant ainsi de précieuses données de comportement du réseau.

Après Electra, la distribution du jalonnement changera considérablement.Les grands validateurs seront impliqués dans les propositions de blocs et les comités de synchronisation plus fréquemment, avec de plus grandes pénalités dans les coupes et un plus grand impact sur les coupes retardées, les files d’attente d’activation et les files d’attente de sortie.Bien que cela puisse créer un défi dans l’agrégation de données, le consensus d’Ethereum garantit que l’informatique non linéaire est minime.Le seul composant non linéaire utilise SQRT (total_effective_balance) pour calculer la récompense de base, qui s’applique à tous les validateurs.Cela signifie que les récompenses et les coupes de validator peuvent toujours être estimées sur une base « Per-1 eth » (ou plus précisément, sur la base de Spec.Effective_Balance_increment, qui pourrait changer à l’avenir).

Pour plus de détails, consultez notre article précédent sur le comportement du validateur.

EIP-7002: sortie de la couche d’exécution déclenchable

Référence: EIP-7002

Chaque validateur de Ethereum a deux paires de clés: une clé active et une clé de retrait.Une clé BLS publique active sert d’identité principale du vérificateur dans la chaîne de balises, qui est utilisée pour signer des blocs, des preuves, des coupes, synchroniser les agrégations du comité et (avant cette EIP) de sortie volontaire (pour suivre un retard initier le consensus du vérificateur du vérificateur sortie).La deuxième paire de clés (« Retral Voucher ») peut être une autre paire de clés BLS ou un compte ETH1 ordinaire (clé privée et adresse).Maintenant, les messages de retrait signés par la clé privée BLS active doivent être extraits à l’adresse ETH.Cet EIP a été modifié.

En fait, les propriétaires de ces deux paires clés (actifs et de retrait) peuvent être différents.La clé active du vérificateur est responsable des responsabilités de vérification: exécuter le serveur, le maintenir en marche normalement, etc., et les bons de retrait sont généralement contrôlés par le propriétaire du pieu, qui reçoit des récompenses et est responsable des fonds.À l’heure actuelle, seul le propriétaire de l’engagement qui contrôle le bon de retrait ne peut pas lancer la sortie du vérificateur et ne peut que retirer la récompense.Cette situation permet au propriétaire de la clé active du vérificateur de maintenir efficacement l’équilibre du vérificateur en « otage » dans sa main.Le vérificateur peut «pré-séparer» le message de sortie et le remettre à la partie prenante, mais cette solution de contournement n’est pas idéale.De plus, l’extraction et la sortie nécessitent actuellement une interaction avec les validateurs de couche de balise via une API dédiée.

La meilleure solution consiste à permettre au propriétaire du pieu d’effectuer des opérations de sortie et de retrait par le biais d’appels de contrat intelligents réguliers.Cela implique la vérification standard de la signature ETH1, ce qui simplifie considérablement les opérations.

Cet EIP permet aux parties prenantes de déclencher des retraits et des sorties en envoyant des transactions standard aux contrats intelligents dédiés à partir de leur adresse ETH (similaire au processus de dépôt existant à l’aide de contrats « Deposit »).Le processus d’extraction (ou de sortie lorsque la participation suffisante est supprimée) est la suivante:

Le Pledger envoie une demande de retrait (« en » demande) au contrat « retrait » du système.
Le contrat facture des frais spécifiques (en ETH) pour atténuer les attaques malveillantes potentielles et, similaire à l’EIP-1559, les frais augmentent lorsque la file d’attente de demande est occupée.
Le contrat économise la demande de retrait / sortie « en » à son stockage.
Lorsqu’un bloc est proposé à la couche de balise, la demande de retrait / sortie « en » dans la file d’attente est récupérée du stockage.
La couche de balise traite la demande « in », interagit avec le solde du vérificateur actif, organise le vérificateur pour quitter et forme une demande de retrait « Out ».
La demande de retrait « OUT » est traitée sur la couche d’exécution, et la partie prenante reçoit son ETH.

Bien que les dépôts soient des opérations déclenchées dans le bloc ETH1, puis « déplacées » vers la couche de balise à travers la file d’attente de dépôt « en attente », les retraits suivent différents schémas.Ils sont déclenchés sur la couche de balise (via la CLI) puis « déplacés » vers le bloc ETH1.Les deux schémas fonctionneront désormais via le même cadre commun (comme décrit ci-dessous): créer une demande sur la couche ETH1, traiter les files d’attente de dépôt / retrait / de fusion en attente « et de le traiter au niveau de la couche de balise.Pour les opérations « de sortie » comme le retrait, la file d’attente de sortie sera également traitée et le résultat sera « réglé » dans le bloc ETH1.

Avec cette EIP, les Stakers peuvent utiliser des transactions d’ETH régulières pour extraire et quitter leurs validateurs sans interagir directement avec le Validator CLI ou accéder à l’infrastructure du validateur.Cela simplifie considérablement les opérations de jalonnement, en particulier pour les grands fournisseurs de jalonnement.L’infrastructure du vérificateur peut désormais être presque complètement isolée car seule la clé du vérificateur actif est maintenue, tandis que toutes les opérations de mise en œuvre peuvent être manipulées ailleurs.Il élimine la nécessité pour les Stakers indépendants d’attendre des actions de validateur actif et simplifie considérablement la partie hors chaîne des services Lido comme le module de mise en place communautaire.

Par conséquent, cette EIP « complète » l’opération de mise en œuvre, la migrant complètement vers la couche ETH1, réduisant considérablement les risques de sécurité des infrastructures et améliorant la décentralisation des initiatives d’allumage indépendantes.

EIP-6110: fourniture de dépôts de vérificateur sur la chaîne

Référence: EIP-6110

Actuellement, les dépôts sont réalisés grâce à des événements du contrat de «dépôt» du système (comme discuté en détail dans les articles précédents).Le contrat accepte les références et les émissions et les émissions « de dépôt () », qui sont ensuite analysés et convertis en demandes de dépôt sur la couche de balise.Le système présente de nombreux inconvénients: il nécessite de voter sur l’ETH1DATA de la couche de chaîne de balises, ce qui ajoute des retards importants.De plus, la couche de balise doit interroger la couche d’exécution, ce qui augmente encore la complexité.Ces questions sont discutées en détail dans le PDE.Un moyen plus facile de faire sans traiter plusieurs de ces problèmes consiste à inclure les demandes de dépôt directement dans le bloc ETH1 à l’emplacement spécifié.Ce mécanisme est similaire au processus de traitement de sevrage décrit dans l’EIP précédent.

Les changements proposés dans cette EIP sont prometteurs.Le traitement ETH1DATA peut désormais être complètement supprimé, n’ayant plus à voter ou des retards prolongés entre les événements du côté Eth1 et déposer des inclusions sur la couche de balise (actuellement environ 12 heures).Il supprime également la logique des instantanés du contrat de dépôt.Cette EIP simplifie le traitement des dépôts et l’aligne avec le schéma de traitement de retrait décrit ci-dessus.

Pour les Stakers et les validateurs, ces changements réduisent considérablement le retard entre l’activation du dépôt et du validateur.Lorsque les validateurs sont coupés, les suppléments nécessaires seront également plus rapides.

Il n’y a rien de plus à dire sur cette PPE, sauf qu’il supprime la logique obsolète, simplifie le processus et crée de meilleurs résultats pour toutes les personnes impliquées.

EIP-7685: Demande de couche d’exécution générale

Référence: EIP-7685

Cet EIP aurait dû être proposé avant les trois premiers EIP liés au dépôt / retrait / fusion car il jette les bases de ces EIP.Cependant, l’introduction ici est de mettre en évidence la demande croissante de données dédiées mobiles cohérentes entre les blocs de chaîne ETH1 (exécution) et la balise (consensus) (couches).Cet EIP affecte deux couches, ce qui rend le traitement des demandes déclenché par les transactions ETH conventionnelles plus efficaces.Actuellement, nous observons:

L’événement de dépôt dans le bloc ETH1 est « déplacé » dans le bloc de balise pour le traitement.
La demande de retrait (en utilisant la CLI) dans le bloc de balises est « déplacée » vers le bloc ETH1 pour le traitement.
Vérificateur Merge doit être traité, qui est également une demande ETH1- & gt; Beacon.

Ces trois opérations démontrent la nécessité d’un traitement cohérent de divers types de demandes lors de la commutation entre la couche d’exécution et la couche de balise.En outre, nous avons besoin de la capacité de déclencher ces opérations en utilisant uniquement la couche ETH1, car cela nous permettra d’isoler l’infrastructure du validateur à partir de l’infrastructure de gestion de jalonnement, améliorant ainsi la sécurité.Par conséquent, une solution générale pour gérer ces demandes est à la fois pratique et nécessaire.

Cet EIP établit un cadre pour au moins trois situations principales: les dépôts, les retraits et les fusions.C’est pourquoi EIP a introduit les champs comme retrait_request_type et dépôt_request_type, et maintenant la fusion ajoutera un autre champ, consolidation_request_type.De plus, cette EIP peut inclure un mécanisme commun pour gérer les restrictions sur ces demandes (constantes de référence: en attente_deposits_limit, en attente_partial_withdrawals_limit, en attente_consolidations_limit).

Bien que les détails détaillés de mise en œuvre de ce cadre ne soient toujours pas disponibles, il inclura certainement les types de demandes critiques, les mécanismes d’intégrité (par exemple, les demandes de hachage et de merkelized) et le traitement de file d’attente en attente et la limitation des taux.

Cet EIP est significatif architecturalement, permettant à Eth1 de déclencher des opérations critiques dans la couche de balise via un cadre unifié.Pour les utilisateurs finaux et les projets, cela signifie que toutes les demandes déclenchées sur la couche ETH1 seront livrées et traitées plus efficacement sur la couche de balise.

EIP-2537: précompilation du fonctionnement de la courbe BLS12-381

Référence: EIP-2537

Si vous ne voulez pas obtenir un look plus profond, vous pouvez considérer la précompilation de BLS12-381 comme une opération de hachage de cryptage complexe qui peut désormais être utilisée dans les contrats intelligents.Pour les personnes intéressées, explorons davantage.

Les opérations mathématiques sur les courbes elliptiques telles que BLS12-381 (et leur BN-254 correspondant) sont actuellement principalement utilisées à deux fins:

Signatures BLS, où une opération spéciale est utilisée appelée « appariement » pour vérifier ces signatures.Les signatures BLS sont largement utilisées par les vérificateurs car elles agrégent plusieurs signatures en une seule.Les validateurs s’appuient sur les signatures BLS basées sur les courbes BLS12-381 (bien qu’ils puissent également être implémentés en utilisant n’importe quelle courbe qui prend en charge l’appariement, comme BN254).
Vérification des épreuves Zksnark, où l’appariement est utilisé pour vérifier les preuves.De plus, les engagements KZG pour les gros morceaux introduits par Dencun Hard Forks utilisent également l’appariement pour valider les engagements de blocs.

Si vous souhaitez vérifier les signatures BLS ou les preuves Zksnark dans un contrat intelligent, vous devez calculer ces « paires », qui sont coûteuses par calcul.Ethereum a déjà un contrat précompilé (EIP-196 et EIP-197) pour le fonctionnement de la courbe BN254.Cependant, la courbe BLS12-381 (maintenant considérée comme plus sûre et plus largement utilisée aujourd’hui) n’a pas encore été mise en œuvre comme précompilée.En l’absence d’une telle précompilation, la mise en œuvre de l’appariement et d’autres opérations de courbe dans des contrats intelligents nécessite beaucoup de calculs, comme indiqué ici, et consomme un énorme gaz (environ ~ 10 ^ 5 à 10 ^ 6 gaz).

Cette EIP ouvre la porte à de nombreuses applications potentielles, en particulier dans la vérification de signature BLS bon marché basée sur la courbe BLS12-381.Cela permet d’obtenir des solutions de seuil à diverses fins.Comme mentionné précédemment, les validateurs Ethereum ont utilisé des signatures basées sur BLS12-381.Avec cette EIP, les contrats intelligents standard peuvent désormais vérifier efficacement les signatures de vérificateur agrégées.Cela peut simplifier le pontage de la preuve de consensus et entre les actifs du réseau, 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 seuils efficaces pour le vote, la génération de nombres aléatoires décentralisée, le multi-signature, etc.

La vérification de la preuve Zksnark moins chère débloquera à son tour un grand nombre d’applications.De nombreuses solutions basées sur Zksnark sont actuellement entravées par des coûts de vérification à preuves élevées, ce qui rend certains projets presque peu pratiques.Cet EIP a le potentiel de changer cela.

EIP-2935: Sauver le hachage du bloc historique dans l’état

Référence: EIP-2935

Cet EIP propose de stocker les hachages de blocs historiques 8192 (environ 27,3 heures) dans l’État de blockchain, fournissant des histoires prolongées pour des clients apatrides tels que les rollups et les contrats intelligents.Il recommande de conserver le comportement actuel de l’opcode Blockhash, en maintenant une limite sur 256 blocs, tout en introduisant un nouveau contrat système conçu spécifiquement pour stocker et récupérer des hachages historiques.Ce contrat effectue l’opération SET () lorsque la couche d’exécution traite le bloc.Sa méthode get () est accessible à quiconque pour récupérer le hachage de blocs requis du tampon d’anneau.

Actuellement, il est possible de référencer le hachage historique des blocs dans EVM, mais l’accès est limité aux 256 blocs les plus récents (environ 50 minutes).Cependant, l’accès aux données des blocs plus anciennes est essentiel dans certains cas, en particulier pour les applications transversales (données qui nécessitent des blocs précédents éprouvés) et des clients apatrides, qui nécessitent périodiquement l’accès aux hachages de blocs précoces.

Cet EIP étend le délai disponible pour les applications de roulement et de chaîne croisée, leur permettant d’accéder directement aux données historiques dans l’EVM sans avoir à les collecter en externe.En conséquence, ces solutions deviennent plus robustes et durables.

EIP-7623: augmenter le coût de calldata

Référence: EIP-7623

Le coût CallData régule la taille disponible de la charge utile de transaction et peut être important dans certains cas (par exemple, lors de la transmission de grandes tableaux ou de tampons binaires en tant que paramètres).L’utilisation significative de CallData est principalement attribuée aux Rollups, qui envoient des charges utiles via CallData contenant l’état de rollup actuel.

L’introduction de grandes données binaires éprouvées dans la blockchain est cruciale pour le roulement.La mise à niveau Dencun (Deneb-Cancun) introduit une innovation importante à ces cas d’utilisation – Blob Transactions (EIP-4844).Les transactions Blob ont leurs propres frais de gaz « Blob » spéciaux.Par conséquent, Blob fournit une meilleure solution pour Rollup que d’utiliser CallData pour stocker les données.

Encouragez Rollup à transférer ses données sur le blob.Les frais de gaz blob réduits sont utilisés comme une « carotte », et cette EIP supprime le stockage excessif de données dans les transactions en augmentant le coût de CallData comme « effet de levier ».Cet EIP complète le prochain EIP-7691 (augmentation du débit blob), ce qui augmente le nombre maximal de blobs autorisés par bloc.

EIP-7691: augmentation du débit blob

Référence: EIP-7691

Des blobs ont été introduits dans la fourche dur Dencun précédente, et les valeurs initiales du nombre maximum et cible de blobs « par bloc » sont des estimations conservatrices.Cela est dû à la complexité de la prévision de la façon dont le réseau P2P gérera la propagation de grands objets binaires entre les nœuds validateurs.La configuration précédente s’est avérée bonne, ce qui en fait le bon moment pour tester de nouvelles valeurs.Auparavant, le numéro BLOB cible / maximum pour chaque bloc était défini sur 3/6.Ces restrictions sont maintenant portées respectivement au 6/9.

Combiné avec l’EIP-7623 précédent (augmentation des coûts CallData), cet ajustement motive en outre Rollup pour transférer ses données de CallData vers des blobs.Le travail de trouver les meilleurs paramètres blob se poursuit.

EIP-7840: Ajouter un calendrier Blob au fichier de configuration EL

Référence: EIP-7840

Cet EIP propose d’ajouter le nombre de BLOB cible et maximum « par bloc » (discuté précédemment) et la valeur de configuration BaseFeeUpdateFraction au fichier 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 les tâches telles que l’estimation des coûts de gaz blob.

EIP-7702: configurer le code du compte EOA

Référence: EIP-7702

Il s’agit d’un EIP très important qui apportera des changements importants aux utilisateurs d’Ethereum.Comme nous le savons, l’EOA (compte détenu externe) ne peut avoir aucun code, mais peut fournir une signature de transaction (tx.origin).En revanche, les contrats intelligents ont des bytecode, mais ne peuvent pas proposer de manière proactive une signature directe de « it ».Toute interaction utilisateur qui nécessite une logique supplémentaire, automatique et vérifiable ne peut actuellement effectuer les actions requises qu’en appelant des contrats externes.Cependant, dans ce cas, le contrat externe devient le MSG.Sender du contrat ultérieur, ce qui a provoqué l’appel à « l’appel du contrat, pas à l’utilisateur ».

Cet EIP introduit un nouveau type de transaction SET_CODE_TX_TYPE = 0x04 (nous avons déjà eu de vieilles transactions 0x1, de nouvelles transactions 0x02 à partir de mises à niveau Berlin et EIP-1559 et 0x03 Blob Transactions introduites dans Dencun).Ce nouveau type de transaction permet de définir les codes pour les comptes EOA.En fait, il permet à EOA d’exécuter du code externe « dans le contexte de son propre compte EOA ».D’un point de vue externe, pendant le processus de transaction, l’EOA semble «emprunter» le code du contrat externe et l’exécuter.Techniquement, cela est réalisé en ajoutant un tuple de données autorisé spécial au magasin « Code » de l’adresse EOA (ce magasin « Code » était toujours vide pour l’EOA avant cette EIP).

Actuellement, le nouveau type de transaction 0x04 proposé par cette EIP contient un tableau:

autorisation_list = [[chain_id, adresse, nonce, y_parity, r, s], …]

Chaque élément permet au compte d’utiliser le code à partir de l’adresse spécifiée (à partir du dernier élément d’autorisation valide).Lors du traitement de ces transactions, le code d’EOA donné est défini sur une valeur d’adresse spéciale 0xEF0100 || ne peut pas être inclus une valeur magique spéciale (selon EIP-3541).Cette valeur magique garantit que cet EOA ne peut pas être considéré comme un contrat régulier, et il ne peut pas être appelé comme un contrat régulier.

Lorsque cet EOA initie une transaction, l’adresse spécifiée sera utilisée pour appeler le code correspondant dans le contexte de l’EOA.Bien que les détails complets de la mise en œuvre de cette PDE ne soient pas clairs, il est certain qu’il apportera des changements importants.

Un impact majeur est la possibilité de faire des multitaliens directement à partir de l’EOA.Les appels multiples sont une tendance persistante dans Defi, et de nombreux protocoles fournissent cette fonctionnalité comme un outil puissant (comme UniSwap V4, Balancer V3 ou Euler V2).Avec cette EIP, vous pouvez désormais lancer plusieurs appels directement à partir de l’EOA.

Par exemple, cette nouvelle fonctionnalité résout un problème commun dans Defi: approuver () + n’importe quoi () nécessite l’inefficacité de deux transactions indépendantes.Cet EIP permet une logique courante de « préautorisation », de sorte que l’approbation (x) + le dépôt (x) peut être terminée dans une seule transaction.

Un autre avantage de pouvoir «représenter» l’exécution de la transaction commandée par l’EOA est le concept de parrainage.Le parrainage est une fonctionnalité fréquemment discutée et hautement souhaitée pour aider les nouveaux utilisateurs à saisir Ethereum.

La logique programmable associée à l’EOA déverrouille de nombreuses possibilités telles que la mise en œuvre de restrictions de sécurité, la définition de plafonds de dépenses, les exigences de KYC obligatoires, etc.

Bien sûr, ce changement soulève également de nombreux problèmes de conception.Un problème est l’utilisation de chaîne_id, qui détermine si la même signature peut être valide sur plusieurs réseaux, selon qu’il est inclus ou non inclus dans la signature.Un autre problème complexe est le choix entre l’utilisation de l’adresse du code cible et l’intégration du bytecode réel.Ces deux méthodes ont leurs propres caractéristiques et limitations uniques.De plus, l’utilisation de NONCE joue un rôle clé dans la définition si les autorisations sont «polyvalentes» ou «à usage unique».Ces éléments affectent les problèmes fonctionnels et de sécurité, y compris les signatures de défaillance par lots et la facilité d’utilisation.Vitalik a soulevé ces questions dans une discussion (ici) et mérite une exploration plus approfondie.

Il convient de noter que ce changement affectera un mécanisme de sécurité d’Ethereum, tx.origin.Plus de détails sur cette implémentation EIP sont nécessaires, mais il semble que le comportement de require (tx.origin == msg.sender) changera.Ce chèque a toujours été le moyen le plus fiable de s’assurer que Msg.Sender est EOA, pas un contrat.D’autres méthodes, telles que la vérification d’extcodésize (pour vérifier s’il s’agit d’un contrat), échoue généralement et peut être contournée (par exemple en appelant le constructeur ou en déploiement du code à une adresse prédéfinie après une transaction).Ces chèques sont utilisés pour empêcher la réintégration et les attaques de prêts à la foudre, mais sont loin d’être idéaux, car ils entravent également l’intégration avec des protocoles externes.Après cette EIP, même le contrôle fiable requis (tx.origin == MSG.Sender) semble devenir obsolète.Le protocole doit être adapté en supprimant ces vérifications, car la différence entre « EOA » et « contrat » ne s’appliquera plus – il peut maintenant y avoir du code pertinent pour chaque adresse.

La séparation entre l’EOA traditionnelle et les contrats intelligents continue d’être floue.Cet EIP rapproche Ethereum d’une conception comme TON, où chaque compte est essentiellement un code exécutable.À mesure que les interactions avec les protocoles deviennent plus complexes, l’utilisation de la logique programmable pour améliorer l’expérience utilisateur final est un processus naturel de cette évolution.

en conclusion

La mise à niveau de Prague / Electra (PECTRA) est prévue pour mars 2025.Les changements de plan les plus importants comprennent:

Vérificateur variable Valid Stakes jusqu’en 2048 ETH, qui modifiera considérablement la distribution des pieus, le calendrier des vérificateurs et simplifiera la gestion des grands fournisseurs de pieus en intégrant des enjeux plus petits
Améliorez l’interaction entre la couche d’exécution et la couche de consensus, et simplifiez l’échange de données entre le bloc d’exécution ETH1 et le bloc de chaîne de balises.Cela simplifiera considérablement les dépôts, les activations, les retraits et les sorties, accélérer ces processus et jetera les bases d’une interaction supplémentaire entre la couche consensus et la couche d’exécution
Prise en charge des signatures BLS moins chères et de la vérification Zksnark directement avec une nouvelle précompilation « BLS12-381 ».
Encouragez les rouleaux à adopter les transactions Blob en augmentant les seuils de transaction BLOB et en augmentant les coûts de calldata
Faites en sorte que l’EOA agisse comme un compte programmable, en lui donnant plusieurs appels, parrainages et autres fonctionnalités avancées

Comme vous pouvez le voir, PECTRA aura un impact significatif sur l’expérience utilisateur final de la couche de mise en scène et de consensus, ainsi que sur la couche d’exécution.Bien que nous ne puissions pas analyser tous ces changements de détail via le code à ce stade, car le développement est toujours en cours, nous couvrirons ces mises à jour dans les futurs articles.