Dans nos précédents articles, nous avons examiné en détail le cycle de vie des validateurs d'Ethereum, discuté de plusieurs aspects liés à la prochaine bifurcation dure Electra, et maintenant il est temps de se pencher sur les changements à venir dans les mises à niveau Electra et Prague, et de les expliquer en détail.
L'histoire de la fourchette dure de l'ethereum 2.0 «Preuve d'enjeu» est complexe. Il a commencé par l'ajout d'une couche de balises à la couche d'exécution existante, tandis que la couche d'exécution continuait de fonctionner avec la preuve de travail (hardfork Phase0 et Altair). Ensuite, dans la hardfork Bellatrix, PoS a été entièrement activé (bien que les retraits n'aient pas été activés). Ensuite, la hardfork Capella a permis les retraits, achevant ainsi le cycle de vie des validateurs. La récente hardfork Deneb (une mise à niveau de Deneb / Cancun) a apporté de légères modifications aux paramètres de la chaîne de balises, telles que les fenêtres de temps pour les preuves, le traitement des sorties volontaires et les restrictions de remplacement des validateurs. Les principaux changements dans Dencun se sont produits au niveau de l'exécution, avec l'introduction de transactions de blob, de gaz de blob, de promesses KZG pour blob et l'abandon de l'opération SELFDESTRUCT.
Maintenant, la fourchette dure Prague/Electra (alias Pectra) a apporté des mises à jour importantes pour la couche d'exécution et de consensus. En tant qu'auditeur du projet Lido, nous nous concentrons principalement sur les changements de consensus et de mise en jeu dans cette fourchette dure. Cependant, nous ne pouvons ignorer les changements de la couche d'exécution à Prague, car ils incluent des caractéristiques importantes qui affectent le réseau Ethereum et les validateurs. Plongeons dans les détails de ces changements.
Vue d'ensemble de haut niveau de Pectra
Electra a introduit de nombreuses fonctionnalités pour la couche de balises. Les principales mises à jour comprennent :
Les soldes valides des validateurs peuvent varier de 32 à 2048 ETH (au lieu d'être fixés à 32 ETH).
Les validateurs sont autorisés à initier des retraits via des reçus de retrait de niveau deux (plus besoin de clé de validateur actif).
Modifier la manière dont la couche de balises gère les dépôts Eth1 (plus d'extraction d'événements à partir du contrat de dépôt).
Ajout d'un nouveau framework général pour traiter les demandes de contrats Eth1 réguliers au niveau de la couche de balisage (similaire à la gestion des dépôts préalables d'Electra).
En même temps, Prague a introduit les changements suivants dans l'exécution :
Un nouveau contrat pré-compilé prenant en charge la courbe BLS12-381 pour vérifier les preuves zkSNARK (à l'exception de la courbe BN254 populaire).
Un nouveau contrat système permettant de stocker et d’accéder à jusqu’à 8192 hachages de blocs historiques (très utile pour les clients sans état).
Augmenter le coût en gas de calldata pour réduire la taille des blocs et encourager les projets à migrer les opérations intensives en calldata (telles que rollup) vers les blobs introduits dans Dencun.
Prise en charge de plus de blobs par bloc Eth1 et fourniture d'une API pour lire ces quantités.
Permettre aux EOA (External Owned Accounts) de posséder leur propre code de compte, ce qui étend considérablement les opérations que les EOA peuvent effectuer, telles que l'exécution de multicalls ou la délégation de l'exécution à d'autres adresses.
Pour continuer la discussion, permettez-nous de prendre en compte les propositions d'amélioration d'Ethereum (EIP) ( et les références connexes.
EIP-7251: Ajouter MAX_EFFECTIVE_BALANCE
EIP-7002: Sortie déclenchée par la couche d'exécution
EIP-6110 : Dépôt de validateur en chaîne
EIP-7549: Déplacer l'index du comité hors de la preuve
EIP-7685: Demande de couche d'exécution générale
EIP-2537: Précompilation des opérations sur la courbe BLS12-381
EIP-2935: Sauvegarde des hachages des blocs historiques dans l'état
EIP-7623: Coût supplémentaire de la calldata
EIP-7691: Augmentation du débit de blob
EIP-7840: Ajouter la planification de blob au fichier de configuration EL
EIP-7702: Définir le code du compte EOA
Certains de ces EIP concernent principalement la couche de consensus (beacon), tandis que d'autres concernent la couche d'exécution. Certains traversent les deux couches, car certaines opérations (comme les dépôts et retraits) nécessitent des changements synchronisés entre la couche de consensus et la couche d'exécution. En raison de cette interdépendance, séparer Electra et Prague est irréaliste, c'est pourquoi nous examinerons chaque EIP séparément et spécifierons les composants d'Ethereum affectés dans chaque cas.
EIP-7251: Ajouter MAX_EFFECTIVE_BALANCE
Référence : EIP-7251
Depuis le premier hard fork Phase0, en préparation de la preuve d’enjeu d’Ethereum, le solde effectif maximum des validateurs a été fixé à 32 ETH jusqu’à Electra. L’exigence du validateur d’activation est d’au moins spec.min_activation_balance (32 ETH). Une fois activés, les validateurs commencent avec ce solde effectif maximal, mais peuvent réduire leur solde effectif à spec.ejection_balance (16 ETH) et être expulsés lorsque ce seuil est atteint. Cette logique « minimale » reste la même dans Electra, mais maintenant spec.max_effective_balance est passé à 2048 ETH. Par conséquent, les validateurs peuvent déposer entre 32 et 2048 ETH pour les activer, ce qui contribuera à leur solde effectif. Ce changement marque le passage de « 32ETH - Proof of Stake » à « Proof of Stake » : )
Ce solde disponible variable sera maintenant utilisé pour :
Augmente la probabilité de devenir un proposant de blocs en fonction du solde disponible
Augmente la probabilité de devenir membre du comité synchronisé, proportionnelle au solde valide
En tant que base pour calculer les montants de réduction relative et de pénalité d'inactivité
Les deux premières activités sont les opérations les plus rentables pour les validateurs. Par conséquent, après Electra, les validateurs avec des mises importantes participeront plus fréquemment à la proposition de blocs et au comité de synchronisation, leur fréquence étant proportionnelle à leur solde valide.
Un autre effet concerne les coupures. Toutes les pénalités de coupure sont proportionnelles au solde effectif du validateur :
Les réductions immédiates et différées des amendes sont plus importantes pour les validateurs avec des mises en jeu élevées.
*La pénalité de réduction "retardée" avec des validateurs réduits fortement mis en jeu est également plus élevée, car la partie “reduite” du total des enjeux devient plus grande.
Les dénonciateurs signalant les validateurs avec des soldes valides élevés obtiennent une plus grande proportion de la mise réduite.
Electra a également proposé des modifications au ratio de réduction, définissant une partie du solde du validateur réduit et recevant par le dénonciateur.
Ensuite, il y a l'impact de l'invalidité. Lorsque les validateurs sont hors ligne lorsqu'ils sont actifs (preuves ou propositions), le score d'invalidité s'accumule, ce qui entraîne des sanctions d'invalidité appliquées à chaque cycle. Ces sanctions sont également proportionnelles au solde valide du validateur.
En raison de l'augmentation du solde effectif, la "limite de remplacement" des validateurs a également changé. Dans l'Ethereum avant "Electra", les validateurs ont généralement des soldes effectifs similaires, et la limite de remplacement est définie comme suit : "Pendant une période, au maximum 1/65536 (spec.churn_limit_quotient) du total des mises peut être retiré." Cela crée un nombre fixe de validateurs sortant avec des mises similaires. Cependant, après "Electra", il peut arriver que seuls quelques "baleines" se retirent, car elles représentent une part importante du total des mises.
Une autre considération concerne la rotation des clés de validation de nombreux validateurs sur une seule instance de validateur. Les gros validateurs sont actuellement contraints de faire fonctionner des milliers de clés de validation sur une seule instance pour s'adapter à des mises en jeu importantes, en les divisant en parties de 32 ETH. Avec Electra, ce comportement n'est plus obligatoire. Sur le plan financier, ce changement n'a pas beaucoup d'impact car les récompenses et les probabilités sont linéaires par rapport au montant mis en jeu. Ainsi, 100 validateurs de 32 ETH chacun équivalent à un validateur de 3200 ETH. De plus, plusieurs clés de validation actives peuvent avoir le même justificatif de retrait Eth1, ce qui permet de retirer toutes les récompenses vers une seule adresse ETH, évitant ainsi les coûts de gaz liés à la fusion des récompenses. Cependant, la gestion d'un grand nombre de clés entraîne des coûts de gestion supplémentaires.
La capacité de solde des validateurs agrégés a été augmentée d'un nouveau type de demande d'exécution. Auparavant, nous avions les dépôts et les retraits. Maintenant, il y aura un autre type : la demande agrégée. Elle fusionnera deux validateurs en un seul. Cette demande d'opération comprendra la clé publique du validateur source et la clé publique de la cible, et sera traitée de manière similaire aux dépôts et aux retraits. L'agrégation aura également des limites de demandes en attente et de remplacement de solde, tout comme les dépôts et les retraits.
Résumé comme suit :
Pour les petits validateurs indépendants, Electra introduit la capacité d'augmenter automatiquement leur solde effectif (et leurs récompenses). Auparavant, tout excédent de 32 ETH ne pouvait être retiré, mais après Electra, cet excédent contribuera finalement à leur solde effectif. Cependant, le solde effectif ne peut être augmenté que par des multiples de spec.effective_balance_increment (1 ETH), ce qui signifie que l'augmentation se produit uniquement après avoir atteint le prochain "seuil de 1 ETH".
Pour les grands validateurs indépendants, Electra offre une simplification significative de la gestion en permettant l'intégration de plusieurs clés de validation actives en une seule. Bien que cela ne change pas les règles du jeu, gérer une mise en jeu de 1x2048 est sans aucun doute beaucoup plus simple que de gérer 64x32 mises en jeu.
Pour les fournisseurs de mise en garantie liquide, ils collectent de petites mises en garantie des utilisateurs et les répartissent entre les validateurs. Electra ajoute plus de flexibilité au schéma de répartition des mises en garantie, mais nécessite également une refonte importante de la comptabilité des validateurs basée sur le solde effectif fixe de 32 ETH.
Un autre sujet important est l'historique des données des validateurs et l'estimation des profits, ce qui est particulièrement pertinent pour les nouveaux participants qui cherchent à évaluer les risques et les rendements. Avant Electra (au moment de la rédaction de cet article), la limite de 32 ETH (qu'elle soit minimale ou maximale, en réalité) a créé une uniformité dans l'historique des données. Les soldes effectifs de tous les validateurs, les récompenses, les pénalités individuelles de réduction, la fréquence de proposition de blocs et autres indicateurs sont les mêmes. Cette uniformité permet à Ethereum de tester son mécanisme de consensus sans anomalies statistiques, collectant ainsi des données comportementales réseau précieuses.
Après Electra, la répartition des mises en jeu subira des changements majeurs. La participation des validateurs de grande taille aux propositions de blocs et au comité de synchronisation sera plus fréquente, avec des sanctions plus lourdes lors des événements de réduction, et une plus grande influence sur les retards de réduction, les files d'attente d'activation et les files d'attente de sortie. Bien que cela puisse poser des défis dans l'agrégation des données, le consensus d'Ethereum garantit que les calculs non linéaires restent minimes. Le seul composant non linéaire utilise sqrt)total_effective_balance( pour calculer la récompense de base, ce qui s'applique à tous les validateurs. Cela signifie que les récompenses et les réductions des validateurs peuvent toujours être estimées sur une base de "chaque 1 ETH" (ou plus précisément, selon spec.effective_balance_increment, qui pourrait changer à l'avenir).
Pour plus d'informations détaillées, veuillez consulter notre article précédent sur le comportement des validateurs.
EIP-7002: Sortie de couche d'exécution déclenchable
Référence : EIP-7002
Chaque validateur sur Ethereum possède deux paires de clés : une paire de clés active et une paire de clés de retrait. La clé publique BLS active sert d'identité principale du validateur sur la chaîne de balises. Cette paire de clés est utilisée pour signer des blocs, des preuves, des réductions, des agrégats de comités synchronisés et (avant cet EIP) des sorties volontaires (pour initier la sortie du consensus du validateur après un délai). La deuxième paire de clés (le « certificat de retrait ») peut être une autre paire de clés BLS ou un compte Eth1 classique (clé privée et adresse). Maintenant, pour effectuer un retrait vers une adresse ETH, un message de retrait doit être signé par la clé privée BLS active. Cet EIP apporte des modifications.
En fait, les propriétaires de ces deux paires de clés (actives et de retrait) peuvent être différents. La clé active du validateur est responsable des tâches de validation : faire fonctionner le serveur, le maintenir en marche, etc., tandis que le retrait est généralement contrôlé par le propriétaire du staking, qui reçoit des récompenses et est responsable des fonds. Actuellement, seul le propriétaire du retrait ne peut pas déclencher la sortie du validateur, mais peut seulement récupérer les récompenses. Cette situation permet au propriétaire de la clé active du validateur de maintenir l'équilibre du validateur comme un "otage". Le validateur peut "pré-signer" un message de sortie et le remettre au propriétaire du staking, mais cette méthode alternative n'est pas idéale. De plus, les retraits et les sorties nécessitent actuellement une interaction avec les validateurs de couche de beacon via une API spécifique.
La meilleure solution consiste à permettre aux propriétaires de mise de garantie d'exécuter simultanément des opérations de sortie et de retrait en appelant un contrat intelligent standard Eth1 qui effectue des vérifications de signature, ce qui simplifie grandement les opérations.
Cet EIP permet aux propriétaires de dépôts de déclencher des retraits et des sorties en envoyant des transactions standards depuis leur adresse ETH vers un contrat intelligent dédié, similaire au processus de dépôt utilisant déjà un contrat de dépôt. Le processus de retrait (ou de sortie lorsqu'un montant suffisant est retiré) est le suivant :
Les validateurs envoient une demande de retrait (demande 'in') au contrat de retrait du système.
Des frais spécifiques sont facturés pour le contrat (en ETH) afin de réduire les risques d'attaques malveillantes, similaires à l'EIP-1559, les frais augmentent lorsque la file d'attente est chargée.
Le contrat enregistrera la demande de retrait / retrait de "in" dans son stockage.
Lorsqu'un bloc est proposé sur la couche de balises, les demandes de retrait / de sortie de la file d'attente «in» sont récupérées à partir du stockage.
La couche de balise traite les demandes "in", interagit avec les soldes des validateurs actifs, organise la sortie des validateurs et forme les demandes de retrait "out".
Les demandes de retrait "out" sont traitées au niveau d'exécution, les déposants reçoivent leur 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 la balise à partir de la file d'attente de dépôt "en attente", les retraits suivent un schéma différent. Ils sont déclenchés au niveau de la balise (via CLI), puis "déplacés" vers le bloc Eth1. Maintenant, les deux schémas fonctionneront via le même cadre général (tel que décrit ci-dessous) : créer une demande au niveau d'Eth1, traiter la file d'attente de dépôts/encaissements/fusions "en attente", et la traiter au niveau de la balise. Pour des opérations telles que les retraits, la file de sortie sera également traitée et le résultat sera "liquidé" dans le bloc Eth1.
Avec cet EIP, les validateurs peuvent retirer leur mise et sortir de leur validation en utilisant des transactions ETH normales, sans avoir à interagir directement avec le CLI du validateur ou accéder à son infrastructure. Cela simplifie considérablement les opérations de mise, en particulier pour les gros fournisseurs de mises. L'infrastructure du validateur peut maintenant être presque entièrement isolée, car seule la clé des validateurs actifs doit être entretenue, tandis que toutes les opérations de mise peuvent être gérées ailleurs. Cela élimine le besoin pour les validateurs indépendants d'attendre les actions des validateurs actifs, et simplifie considérablement les parties hors chaîne des services tels que le module de mise communautaire de Lido.
Par conséquent, cette EIP "complète" l'opération de mise en gage, la déplaçant entièrement vers la couche Eth1, réduisant considérablement les risques de sécurité de l'infrastructure et renforçant la décentralisation de l'initiative de mise en gage indépendante.
EIP-6110: Fournir un dépôt de validation sur chaîne
Référence : EIP-6110
Actuellement, les dépôts sont effectués via des événements dans le contrat 'Dépôt' du système (comme discuté en détail dans un article précédent). Le contrat accepte de l'ETH et des preuves de validateur, émettant l'événement 'Dépôt)(', ces événements sont ensuite analysés et convertis en demandes de dépôt sur la couche de balises. Ce système présente de nombreux inconvénients : il nécessite un vote sur les données eth1 de la couche de balises, ce qui entraîne des retards significatifs. De plus, la couche de balises doit interroger la couche d'exécution, ce qui ajoute encore de la complexité. Ces problèmes sont discutés en détail dans l'EIP. Une approche plus simple, qui évite bon nombre de ces problèmes, consiste à inclure directement les demandes de dépôt dans les blocs Eth1 à des emplacements spécifiés. Ce mécanisme est similaire au processus de retrait décrit dans les précédentes EIP.
Les changements proposés dans cette EIP sont très prometteurs. Le traitement eth1data peut maintenant être complètement supprimé, éliminant ainsi le besoin de voter ou de subir de longs retards entre les événements du côté Eth1 et les dépôts sur la couche de balise (actuellement d'environ 12 heures). Il élimine également la logique de capture d'écran du contrat de dépôt. Cette EIP simplifie le traitement des dépôts et l'aligne sur le schéma de traitement des retraits mentionné ci-dessus.
Pour les dépositaires et les validateurs, ces changements réduisent considérablement le délai entre le dépôt et l'activation du validateur. Lorsqu'un validateur est réduit, les compléments nécessaires sont également plus rapides.
Il n'y a pas grand-chose de plus à dire à propos de cet EIP, si ce n'est qu'il supprime la logique obsolète, simplifie le processus et crée de meilleurs résultats pour toutes les parties concernées.
EIP-7685: Demande de couche d'exécution générale
Référence : EIP-7685
Ce EIP aurait dû être proposé avant les trois premiers EIP liés aux dépôts, retraits et fusion, car il pose les bases pour ces EIP. Cependant, il est présenté ici pour souligner la demande croissante de déplacement de données spécialisées entre les blocs (couches) d'Eth1 (exécution) et de balises (consensus). Cet EIP affecte deux couches, rendant le traitement des demandes déclenchées par des transactions ETH classiques plus efficace. Pour l'instant, nous observons :
Les dépôts dans le bloc Eth1 sont "déplacés" vers le bloc de balises pour traitement.
La demande de retrait dans le bloc de balises (utilisation de la CLI) a été "déplacée" vers le bloc Eth1 pour traitement.
beacon.
Ces trois opérations illustrent la nécessité d'un traitement cohérent des différents types de demandes lors de la conversion entre la couche d'exécution et la couche de repère. De plus, nous avons besoin de la capacité à déclencher ces opérations uniquement au niveau de la couche Eth1, car cela nous permettrait de séparer l'infrastructure des validateurs de l'infrastructure de gestion du staking, améliorant ainsi la sécurité. Par conséquent, une solution générale pour gérer de telles demandes est à la fois pratique et nécessaire.
Ce EIP établit un cadre pour au moins trois cas principaux : dépôt, retrait et consolidation. C'est pourquoi les premiers EIP ont introduit des champs tels que WITHDRAWAL_REQUEST_TYPE et DEPOSIT_REQUEST_TYPE, et maintenant la consolidation ajoutera un autre champ, CONSOLIDATION_REQUEST_TYPE. De plus, cet EIP peut également inclure un mécanisme général pour gérer les limitations de ce type de demande (référence aux constantes : PENDING_DEPOSITS_LIMIT, PENDING_PARTIAL_WITHDRAWALS_LIMIT, PENDING_CONSOLIDATIONS_LIMIT).
Bien que les détails d'implémentation précis de ce framework ne soient pas encore disponibles, il inclura certainement des types de requêtes clés, des mécanismes d'intégrité (par exemple, des requêtes hash et Merkel), ainsi que la gestion de la file d'attente et des limitations de débit.
Cet EIP a une signification architecturale, permettant à Eth1 de déclencher des opérations clés 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 au niveau d'Eth1 seront transmises et traitées plus efficacement au niveau de la couche de balise.
EIP-2537: Précompilation des opérations de courbe BLS12-381
Référence : EIP-2537
Si vous ne souhaitez pas approfondir, vous pouvez considérer la précompilation de BLS12-381 comme une opération de hachage cryptographique complexe qui peut maintenant être utilisée dans les contrats intelligents. Pour ceux qui sont intéressés, explorons davantage.
Les opérations mathématiques effectuées sur les courbes elliptiques telles que BLS12-381 (et son homologue BN-254) sont actuellement principalement utilisées à deux fins :
*La signature BLS, qui utilise une opération spéciale 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 vérificateurs dépendent des signatures BLS basées sur la courbe BLS12-381 (bien qu'elles puissent également utiliser toute autre courbe prenant en charge l'appariement, comme BN254).
La vérification des preuves zkSNARK, où les paires sont utilisées pour vérifier les preuves. De plus, l'engagement KZG pour les grands blocs introduit par le hard fork Dencun est également vérifié à l'aide de paires pour vérifier l'engagement du bloc.
Si vous souhaitez vérifier une signature BLS ou une preuve zkSNARK dans un smart contract, vous devez calculer ces "appariements", ce qui est très coûteux en termes de calcul. Ethereum dispose déjà d'un contrat précompilé pour les opérations sur la courbe BN254 (EIP-196 et EIP-197). Cependant, la courbe BLS12-381 (aujourd'hui considérée comme plus sûre et largement utilisée) n'est pas encore mise en œuvre en tant que précompilation. Sans une telle précompilation, la mise en œuvre des appariements et d'autres opérations sur la courbe dans un smart contract nécessite des calculs intensifs, comme indiqué ici, et consomme énormément de gaz (environ ~10^5 à 10^6 gaz).
Cette EIP ouvre la voie à de nombreuses applications potentielles, en particulier dans la vérification de signature BLS bon marché basée sur la courbe BLS12-381. Cela rend possible la mise en œuvre de schémas de seuil pour diverses fins. Comme mentionné précédemment, les validateurs Ethereum utilisent déjà des signatures basées sur BLS12-381. Grâce à cette EIP, les contrats intelligents standard peuvent désormais vérifier efficacement les signatures agrégées des validateurs. Cela simplifie la preuve de consensus et le pontage des actifs entre les réseaux, car les signatures BLS sont largement utilisées dans les blockchains. Les signatures BLS seuillées 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 des preuves zkSNARK moins chère débloquera à son tour de nombreuses applications. De nombreuses solutions basées sur zkSNARK sont actuellement entravées par des coûts élevés de vérification des preuves, ce qui rend certains projets presque irréalisables. Cet EIP a le potentiel de changer cela.
EIP-2935: Sauvegarde des hachages des blocs précédents dans l'état
Référence: EIP-2935
Cette proposition EIP propose de stocker 8192 (environ 27,3 heures) hachages d'anciens blocs dans l'état de la blockchain, afin de fournir une extension de l'historique aux clients sans état (tels que Rollup) et aux contrats intelligents. Il propose de conserver le comportement actuel de l'opération BLOCKHASH, en maintenant la limite de 256 blocs, tout en introduisant un nouveau contrat de système spécialement conçu pour stocker et récupérer les hachages historiques. Ce contrat effectue l'opération set)( lors du traitement des blocs au niveau d'exécution. Sa méthode get)( est accessible à tous pour récupérer les hachages de bloc nécessaires à partir d'un tampon circulaire.
Actuellement, dans l'EVM, il est possible de faire référence à l'empreinte historique des blocs, mais l'accès est limité aux 256 derniers blocs (environ 50 minutes). Cependant, il est parfois crucial d'accéder à des données de blocs plus anciens, en particulier pour les applications inter-chaînes (qui nécessitent une preuve des données des blocs précédents) et les clients sans état qui ont régulièrement besoin d'accéder à l'empreinte des blocs plus anciens.
Cet EIP étend la plage de temps disponible pour les applications rollup et cross-chain, leur permettant d'accéder directement aux données historiques dans l'EVM sans avoir besoin de les collecter à l'extérieur. Par conséquent, ces solutions deviennent plus robustes et durables.
EIP-7623: Augmentation du coût de calldata
Référence : EIP-7623
calldata ajuste le coût de la charge utile de transaction disponible, qui peut être important dans certaines circonstances (par exemple, lorsqu'un grand tableau ou un tampon binaire est transmis en tant que paramètre). L'utilisation significative de calldata est principalement due aux rollups, qui envoient la charge utile en incluant le calldata de l'état actuel du rollup.
Introduire des données binaires de grande taille et vérifiables dans la blockchain est crucial pour Rollup. La mise à niveau de Dencun (Deneb-Cancun) a introduit une innovation importante pour de tels cas d'utilisation - les transactions de blob (EIP-4844). Les transactions de blob ont leur propre frais de gaz spécialisé «blob», bien que leur corps soit temporairement stocké, leur preuve de chiffrement (engagement KZG) ainsi que leur hachage sont intégrés à la couche de consensus. Par conséquent, par rapport à l'utilisation de calldata pour stocker des données, les blobs offrent une meilleure solution pour Rollup.
Il est encouragé que rollup déplace ses données vers un blob en utilisant la méthode 'carotte et bâton'. La réduction des frais de gaz du blob est considérée comme 'la carotte', tandis que cet EIP utilise l'augmentation du coût des calldata comme 'le bâton' pour réduire le stockage excessif des données dans les transactions. Cet EIP complète le prochain EIP-7691 (augmentation du débit du blob), qui augmente le nombre maximal de blobs autorisés par bloc.
EIP-7691：augmentation du débit de blob
Référence : EIP-7691
Dans la bifurcation difficile précédente de Dencun, le blob a été introduit, et la valeur maximale et cible de "chaque bloc" blob était une estimation prudente. Cela est dû à la complexité de la manière dont le réseau p2p prévoit de traiter la propagation d'objets binaires de grande taille entre les nœuds validateurs. La configuration précédente s'est avérée efficace, ce qui en fait le bon moment pour tester de nouvelles valeurs. Auparavant, la cible / le nombre maximal de blobs par bloc était réglé à 3/6. Ces limites ont maintenant été respectivement augmentées à 6/9.
En combinant la EIP-7623 précédente (augmentation du coût du calldata), cet ajustement incite encore plus le rollup à transférer ses données de calldata vers des blobs. Les travaux pour trouver les meilleurs paramètres de blob se poursuivent.
EIP-7840: Ajouter la planification des blobs au fichier de configuration EL
Référence : EIP-7840
Cette proposition EIP propose d'ajouter la cible et le nombre maximal de « blobs par bloc » (discutés précédemment) ainsi que la valeur 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 de nœud. Cette fonctionnalité est particulièrement utile pour estimer les frais de gaz de blob, etc.
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 aux utilisateurs d'Ethereum. Comme nous le savons, un compte externe (EOA) ne peut pas avoir de code, mais peut fournir une signature de transaction (tx.origin). En revanche, un contrat intelligent a un bytecode, mais ne peut pas fournir de signature directe « de lui-même ». Toute interaction utilisateur nécessitant une logique supplémentaire, automatique et vérifiable ne peut actuellement être exécutée qu'en appelant un contrat externe pour effectuer les opérations nécessaires. Cependant, dans ce cas, le contrat externe devient le msg.sender des contrats ultérieurs, ce qui signifie que l'appel provient d'un « appel de contrat, pas de l'utilisateur ».
Cet EIP introduit un nouveau type de transaction SET_CODE_TX_TYPE=0x04 (nous avions précédemment une ancienne transaction 0x1, les nouvelles transactions 0x02 de l'upgrade Berlin et EIP-1559, ainsi que la transaction blob 0x03 introduite dans Dencun). Ce nouveau type de transaction permet de définir du code pour un compte EOA. En réalité, il permet à un EOA d'exécuter du code externe « dans le contexte de son propre compte EOA ». Du point de vue externe, lors de la transaction, l'EOA semble « emprunter » du code provenant d'un contrat externe et l'exécuter. Techniquement, cela est réalisé en ajoutant un tuple de données d'autorisation spéciales au « stockage du code » de l'adresse EOA (avant cet EIP, ce stockage du « code » était toujours vide pour les EOA).
Actuellement, ce nouveau type de transaction 0x04 proposé par EIP contient un tableau :
Chaque élément permet à un compte d'utiliser le code provenant de l'adresse spécifiée (à partir de la dernière autorisation valide). Lors du traitement de ce type de transaction, le code de l'EOA donné est défini comme une valeur spéciale 0xef0100 || adresse (23 octets), où l'adresse pointe vers le contrat contenant le code requis, || représente la concaténation, 0xef0100 représente une valeur magique spéciale qui ne peut pas être contenue dans un contrat intelligent ordinaire (selon EIP-3541). Cette valeur magique garantit que cet EOA ne peut pas être considéré comme un contrat ordinaire et ne peut pas être appelé de la même manière qu'un contrat ordinaire.
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 la mise en œuvre de cet EIP ne soient pas encore clairs, il est certain qu'il apportera des changements majeurs.
Une influence majeure est la capacité de faire des appels multiples (multicall) directement à partir d'un EOA. Les appels multiples sont une tendance continue dans la DeFi, avec de nombreux protocoles offrant cette fonctionnalité comme un outil puissant (comme Uniswap V4, Balancer V3 ou Euler V2). Avec cet EIP, il est maintenant possible de lancer directement des appels multiples à partir d'un EOA.
Par exemple, cette nouvelle fonctionnalité résout un problème courant dans DeFi : l'inefficacité de deux transactions distinctes pour approve)( + anything)(. Cette EIP permet une logique de « préautorisation » générique, ce qui permet de réaliser approve)X( + deposit)X( dans une seule transaction.
Une autre caractéristique importante de l'exécution des transactions d'EOA par délégation est le concept de parrainage. Le parrainage est une fonctionnalité souvent discutée et très attendue pour aider les nouveaux utilisateurs à entrer dans Ethereum.
La logique programmable associée à l'EOA a débloqué de nombreuses possibilités, telles que la mise en œuvre de restrictions de sécurité, la définition de limites de dépenses, l'exigence de KYC, etc.
Bien sûr, ce changement soulève également de nombreuses questions de conception. Une question est l'utilisation de chain_id, qui détermine si une même signature est valide sur plusieurs réseaux, en fonction de sa présence ou de son absence dans la signature. Un autre problème complexe est le choix entre l'utilisation d'adresses de code cible et l'incorporation de bytecode réel. Les deux approches ont leurs propres caractéristiques et limitations. De plus, l'utilisation de nonce joue un rôle clé dans la définition des autorisations comme étant "multifonctionnelles" ou "uniques". Ces éléments ont un impact sur les problèmes de fonctionnalité et de sécurité, tels que les signatures en vrac invalides et la convivialité. Vitalik soulève ces questions dans une discussion (ici) qui mérite d'être explorée davantage.
Il convient de noter que ce changement aura un impact sur un mécanisme de sécurité d'Ethereum, tx.origin. Plus de 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 toujours été le moyen le plus fiable de s'assurer que msg.sender est un compte externe (EOA) plutôt qu'un contrat. D'autres méthodes, telles que la vérification de la taille du code externe (EXTCODESIZE) pour déterminer s'il s'agit d'un contrat, échouent souvent et peuvent être contournées (par exemple, en appelant le constructeur ou en déployant du code à une adresse prédéfinie après la transaction). Ces vérifications sont utilisées pour éviter les attaques de réentrance et de prêt éclair, mais elles ne sont pas idéales car elles entravent également l'intégration avec des protocoles externes. Après cet EIP, il semble que même la vérification fiable de require)tx.origin == msg.sender( devienne obsolète. Les protocoles devront s'adapter en supprimant ces vérifications car la distinction entre "EOA" et "contrat" ne sera plus pertinente - chaque adresse peut désormais avoir un code associé.
La séparation traditionnelle entre les EOA et les contrats intelligents continue à s'estomper. Cet EIP rapproche Ethereum de conceptions telles que TON, où chaque compte est essentiellement du code exécutable. À mesure que les interactions avec le protocole deviennent de plus en plus complexes, l'utilisation de la logique programmable pour améliorer l'expérience utilisateur finale est un processus évolutif naturel.
Conclusion
La mise à niveau de Prague / Electra (Pectra) est prévue pour mars 2025. Les changements les plus significatifs de son plan comprennent :
Les validateurs variables peuvent être mis en gage jusqu'à 2048 ETH, ce qui modifiera considérablement la répartition des mises en gage, le calendrier des validateurs et simplifiera la gestion des grands fournisseurs de mise en gage en intégrant des mises en gage plus petites.
Amélioration de l'interaction entre la couche d'exécution et la couche de consensus, simplifiant l'échange de données entre les blocs d'exécution Eth1 et les blocs de chaîne de balises. Cela simplifiera considérablement les dépôts, les activations, les retraits et les sorties, accélérant ces processus et jetant les bases d'une interaction plus poussée entre la couche de consensus et la couche d'exécution.
Prise en charge dans les contrats intelligents de signatures BLS moins chères et de vérifications zkSNARK plus rapides via la nouvelle précompilation "pairing-friendly" BLS12-381.
Encourager les Rollups à adopter des transactions blob en augmentant le seuil de transaction blob et en augmentant le coût calldata
Faire en sorte que l'EOA agisse en tant que compte programmable, lui conférant des fonctions avancées telles que les appels multiples, le parrainage et autres.
Comme vous pouvez le voir, Pectra aura un impact majeur sur l'expérience utilisateur finale en ce qui concerne le staking, la couche de consensus et la couche d'exécution. Bien que nous ne puissions pas analyser en détail toutes ces modifications à ce stade en raison du développement en cours, nous les aborderons dans des articles futurs.
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
Décryptage de la prochaine mise à niveau Hard Fork d'Ethereum - Pectra
Introduction
Dans nos précédents articles, nous avons examiné en détail le cycle de vie des validateurs d'Ethereum, discuté de plusieurs aspects liés à la prochaine bifurcation dure Electra, et maintenant il est temps de se pencher sur les changements à venir dans les mises à niveau Electra et Prague, et de les expliquer en détail.
L'histoire de la fourchette dure de l'ethereum 2.0 «Preuve d'enjeu» est complexe. Il a commencé par l'ajout d'une couche de balises à la couche d'exécution existante, tandis que la couche d'exécution continuait de fonctionner avec la preuve de travail (hardfork Phase0 et Altair). Ensuite, dans la hardfork Bellatrix, PoS a été entièrement activé (bien que les retraits n'aient pas été activés). Ensuite, la hardfork Capella a permis les retraits, achevant ainsi le cycle de vie des validateurs. La récente hardfork Deneb (une mise à niveau de Deneb / Cancun) a apporté de légères modifications aux paramètres de la chaîne de balises, telles que les fenêtres de temps pour les preuves, le traitement des sorties volontaires et les restrictions de remplacement des validateurs. Les principaux changements dans Dencun se sont produits au niveau de l'exécution, avec l'introduction de transactions de blob, de gaz de blob, de promesses KZG pour blob et l'abandon de l'opération SELFDESTRUCT.
Maintenant, la fourchette dure Prague/Electra (alias Pectra) a apporté des mises à jour importantes pour la couche d'exécution et de consensus. En tant qu'auditeur du projet Lido, nous nous concentrons principalement sur les changements de consensus et de mise en jeu dans cette fourchette dure. Cependant, nous ne pouvons ignorer les changements de la couche d'exécution à Prague, car ils incluent des caractéristiques importantes qui affectent le réseau Ethereum et les validateurs. Plongeons dans les détails de ces changements.
Vue d'ensemble de haut niveau de Pectra
Electra a introduit de nombreuses fonctionnalités pour la couche de balises. Les principales mises à jour comprennent :
En même temps, Prague a introduit les changements suivants dans l'exécution :
Pour continuer la discussion, permettez-nous de prendre en compte les propositions d'amélioration d'Ethereum (EIP) ( et les références connexes.
Certains de ces EIP concernent principalement la couche de consensus (beacon), tandis que d'autres concernent la couche d'exécution. Certains traversent les deux couches, car certaines opérations (comme les dépôts et retraits) nécessitent des changements synchronisés entre la couche de consensus et la couche d'exécution. En raison de cette interdépendance, séparer Electra et Prague est irréaliste, c'est pourquoi nous examinerons chaque EIP séparément et spécifierons les composants d'Ethereum affectés dans chaque cas.
EIP-7251: Ajouter MAX_EFFECTIVE_BALANCE
Référence : EIP-7251
Depuis le premier hard fork Phase0, en préparation de la preuve d’enjeu d’Ethereum, le solde effectif maximum des validateurs a été fixé à 32 ETH jusqu’à Electra. L’exigence du validateur d’activation est d’au moins spec.min_activation_balance (32 ETH). Une fois activés, les validateurs commencent avec ce solde effectif maximal, mais peuvent réduire leur solde effectif à spec.ejection_balance (16 ETH) et être expulsés lorsque ce seuil est atteint. Cette logique « minimale » reste la même dans Electra, mais maintenant spec.max_effective_balance est passé à 2048 ETH. Par conséquent, les validateurs peuvent déposer entre 32 et 2048 ETH pour les activer, ce qui contribuera à leur solde effectif. Ce changement marque le passage de « 32ETH - Proof of Stake » à « Proof of Stake » : )
Ce solde disponible variable sera maintenant utilisé pour :
Les deux premières activités sont les opérations les plus rentables pour les validateurs. Par conséquent, après Electra, les validateurs avec des mises importantes participeront plus fréquemment à la proposition de blocs et au comité de synchronisation, leur fréquence étant proportionnelle à leur solde valide.
Un autre effet concerne les coupures. Toutes les pénalités de coupure sont proportionnelles au solde effectif du validateur :
Electra a également proposé des modifications au ratio de réduction, définissant une partie du solde du validateur réduit et recevant par le dénonciateur.
Ensuite, il y a l'impact de l'invalidité. Lorsque les validateurs sont hors ligne lorsqu'ils sont actifs (preuves ou propositions), le score d'invalidité s'accumule, ce qui entraîne des sanctions d'invalidité appliquées à chaque cycle. Ces sanctions sont également proportionnelles au solde valide du validateur.
En raison de l'augmentation du solde effectif, la "limite de remplacement" des validateurs a également changé. Dans l'Ethereum avant "Electra", les validateurs ont généralement des soldes effectifs similaires, et la limite de remplacement est définie comme suit : "Pendant une période, au maximum 1/65536 (spec.churn_limit_quotient) du total des mises peut être retiré." Cela crée un nombre fixe de validateurs sortant avec des mises similaires. Cependant, après "Electra", il peut arriver que seuls quelques "baleines" se retirent, car elles représentent une part importante du total des mises.
Une autre considération concerne la rotation des clés de validation de nombreux validateurs sur une seule instance de validateur. Les gros validateurs sont actuellement contraints de faire fonctionner des milliers de clés de validation sur une seule instance pour s'adapter à des mises en jeu importantes, en les divisant en parties de 32 ETH. Avec Electra, ce comportement n'est plus obligatoire. Sur le plan financier, ce changement n'a pas beaucoup d'impact car les récompenses et les probabilités sont linéaires par rapport au montant mis en jeu. Ainsi, 100 validateurs de 32 ETH chacun équivalent à un validateur de 3200 ETH. De plus, plusieurs clés de validation actives peuvent avoir le même justificatif de retrait Eth1, ce qui permet de retirer toutes les récompenses vers une seule adresse ETH, évitant ainsi les coûts de gaz liés à la fusion des récompenses. Cependant, la gestion d'un grand nombre de clés entraîne des coûts de gestion supplémentaires.
La capacité de solde des validateurs agrégés a été augmentée d'un nouveau type de demande d'exécution. Auparavant, nous avions les dépôts et les retraits. Maintenant, il y aura un autre type : la demande agrégée. Elle fusionnera deux validateurs en un seul. Cette demande d'opération comprendra la clé publique du validateur source et la clé publique de la cible, et sera traitée de manière similaire aux dépôts et aux retraits. L'agrégation aura également des limites de demandes en attente et de remplacement de solde, tout comme les dépôts et les retraits.
Résumé comme suit :
Un autre sujet important est l'historique des données des validateurs et l'estimation des profits, ce qui est particulièrement pertinent pour les nouveaux participants qui cherchent à évaluer les risques et les rendements. Avant Electra (au moment de la rédaction de cet article), la limite de 32 ETH (qu'elle soit minimale ou maximale, en réalité) a créé une uniformité dans l'historique des données. Les soldes effectifs de tous les validateurs, les récompenses, les pénalités individuelles de réduction, la fréquence de proposition de blocs et autres indicateurs sont les mêmes. Cette uniformité permet à Ethereum de tester son mécanisme de consensus sans anomalies statistiques, collectant ainsi des données comportementales réseau précieuses.
Après Electra, la répartition des mises en jeu subira des changements majeurs. La participation des validateurs de grande taille aux propositions de blocs et au comité de synchronisation sera plus fréquente, avec des sanctions plus lourdes lors des événements de réduction, et une plus grande influence sur les retards de réduction, les files d'attente d'activation et les files d'attente de sortie. Bien que cela puisse poser des défis dans l'agrégation des données, le consensus d'Ethereum garantit que les calculs non linéaires restent minimes. Le seul composant non linéaire utilise sqrt)total_effective_balance( pour calculer la récompense de base, ce qui s'applique à tous les validateurs. Cela signifie que les récompenses et les réductions des validateurs peuvent toujours être estimées sur une base de "chaque 1 ETH" (ou plus précisément, selon spec.effective_balance_increment, qui pourrait changer à l'avenir).
Pour plus d'informations détaillées, veuillez consulter notre article précédent sur le comportement des validateurs.
EIP-7002: Sortie de couche d'exécution déclenchable
Référence : EIP-7002
Chaque validateur sur Ethereum possède deux paires de clés : une paire de clés active et une paire de clés de retrait. La clé publique BLS active sert d'identité principale du validateur sur la chaîne de balises. Cette paire de clés est utilisée pour signer des blocs, des preuves, des réductions, des agrégats de comités synchronisés et (avant cet EIP) des sorties volontaires (pour initier la sortie du consensus du validateur après un délai). La deuxième paire de clés (le « certificat de retrait ») peut être une autre paire de clés BLS ou un compte Eth1 classique (clé privée et adresse). Maintenant, pour effectuer un retrait vers une adresse ETH, un message de retrait doit être signé par la clé privée BLS active. Cet EIP apporte des modifications.
En fait, les propriétaires de ces deux paires de clés (actives et de retrait) peuvent être différents. La clé active du validateur est responsable des tâches de validation : faire fonctionner le serveur, le maintenir en marche, etc., tandis que le retrait est généralement contrôlé par le propriétaire du staking, qui reçoit des récompenses et est responsable des fonds. Actuellement, seul le propriétaire du retrait ne peut pas déclencher la sortie du validateur, mais peut seulement récupérer les récompenses. Cette situation permet au propriétaire de la clé active du validateur de maintenir l'équilibre du validateur comme un "otage". Le validateur peut "pré-signer" un message de sortie et le remettre au propriétaire du staking, mais cette méthode alternative n'est pas idéale. De plus, les retraits et les sorties nécessitent actuellement une interaction avec les validateurs de couche de beacon via une API spécifique.
La meilleure solution consiste à permettre aux propriétaires de mise de garantie d'exécuter simultanément des opérations de sortie et de retrait en appelant un contrat intelligent standard Eth1 qui effectue des vérifications de signature, ce qui simplifie grandement les opérations.
Cet EIP permet aux propriétaires de dépôts de déclencher des retraits et des sorties en envoyant des transactions standards depuis leur adresse ETH vers un contrat intelligent dédié, similaire au processus de dépôt utilisant déjà un contrat de dépôt. Le processus de retrait (ou de sortie lorsqu'un montant suffisant est retiré) est le suivant :
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 la balise à partir de la file d'attente de dépôt "en attente", les retraits suivent un schéma différent. Ils sont déclenchés au niveau de la balise (via CLI), puis "déplacés" vers le bloc Eth1. Maintenant, les deux schémas fonctionneront via le même cadre général (tel que décrit ci-dessous) : créer une demande au niveau d'Eth1, traiter la file d'attente de dépôts/encaissements/fusions "en attente", et la traiter au niveau de la balise. Pour des opérations telles que les retraits, la file de sortie sera également traitée et le résultat sera "liquidé" dans le bloc Eth1.
Avec cet EIP, les validateurs peuvent retirer leur mise et sortir de leur validation en utilisant des transactions ETH normales, sans avoir à interagir directement avec le CLI du validateur ou accéder à son infrastructure. Cela simplifie considérablement les opérations de mise, en particulier pour les gros fournisseurs de mises. L'infrastructure du validateur peut maintenant être presque entièrement isolée, car seule la clé des validateurs actifs doit être entretenue, tandis que toutes les opérations de mise peuvent être gérées ailleurs. Cela élimine le besoin pour les validateurs indépendants d'attendre les actions des validateurs actifs, et simplifie considérablement les parties hors chaîne des services tels que le module de mise communautaire de Lido.
Par conséquent, cette EIP "complète" l'opération de mise en gage, la déplaçant entièrement vers la couche Eth1, réduisant considérablement les risques de sécurité de l'infrastructure et renforçant la décentralisation de l'initiative de mise en gage indépendante.
EIP-6110: Fournir un dépôt de validation sur chaîne
Référence : EIP-6110
Actuellement, les dépôts sont effectués via des événements dans le contrat 'Dépôt' du système (comme discuté en détail dans un article précédent). Le contrat accepte de l'ETH et des preuves de validateur, émettant l'événement 'Dépôt)(', ces événements sont ensuite analysés et convertis en demandes de dépôt sur la couche de balises. Ce système présente de nombreux inconvénients : il nécessite un vote sur les données eth1 de la couche de balises, ce qui entraîne des retards significatifs. De plus, la couche de balises doit interroger la couche d'exécution, ce qui ajoute encore de la complexité. Ces problèmes sont discutés en détail dans l'EIP. Une approche plus simple, qui évite bon nombre de ces problèmes, consiste à inclure directement les demandes de dépôt dans les blocs Eth1 à des emplacements spécifiés. Ce mécanisme est similaire au processus de retrait décrit dans les précédentes EIP.
Les changements proposés dans cette EIP sont très prometteurs. Le traitement eth1data peut maintenant être complètement supprimé, éliminant ainsi le besoin de voter ou de subir de longs retards entre les événements du côté Eth1 et les dépôts sur la couche de balise (actuellement d'environ 12 heures). Il élimine également la logique de capture d'écran du contrat de dépôt. Cette EIP simplifie le traitement des dépôts et l'aligne sur le schéma de traitement des retraits mentionné ci-dessus.
Pour les dépositaires et les validateurs, ces changements réduisent considérablement le délai entre le dépôt et l'activation du validateur. Lorsqu'un validateur est réduit, les compléments nécessaires sont également plus rapides.
Il n'y a pas grand-chose de plus à dire à propos de cet EIP, si ce n'est qu'il supprime la logique obsolète, simplifie le processus et crée de meilleurs résultats pour toutes les parties concernées.
EIP-7685: Demande de couche d'exécution générale
Référence : EIP-7685
Ce EIP aurait dû être proposé avant les trois premiers EIP liés aux dépôts, retraits et fusion, car il pose les bases pour ces EIP. Cependant, il est présenté ici pour souligner la demande croissante de déplacement de données spécialisées entre les blocs (couches) d'Eth1 (exécution) et de balises (consensus). Cet EIP affecte deux couches, rendant le traitement des demandes déclenchées par des transactions ETH classiques plus efficace. Pour l'instant, nous observons :
Ces trois opérations illustrent la nécessité d'un traitement cohérent des différents types de demandes lors de la conversion entre la couche d'exécution et la couche de repère. De plus, nous avons besoin de la capacité à déclencher ces opérations uniquement au niveau de la couche Eth1, car cela nous permettrait de séparer l'infrastructure des validateurs de l'infrastructure de gestion du staking, améliorant ainsi la sécurité. Par conséquent, une solution générale pour gérer de telles demandes est à la fois pratique et nécessaire.
Ce EIP établit un cadre pour au moins trois cas principaux : dépôt, retrait et consolidation. C'est pourquoi les premiers EIP ont introduit des champs tels que WITHDRAWAL_REQUEST_TYPE et DEPOSIT_REQUEST_TYPE, et maintenant la consolidation ajoutera un autre champ, CONSOLIDATION_REQUEST_TYPE. De plus, cet EIP peut également inclure un mécanisme général pour gérer les limitations de ce type de demande (référence aux constantes : PENDING_DEPOSITS_LIMIT, PENDING_PARTIAL_WITHDRAWALS_LIMIT, PENDING_CONSOLIDATIONS_LIMIT).
Bien que les détails d'implémentation précis de ce framework ne soient pas encore disponibles, il inclura certainement des types de requêtes clés, des mécanismes d'intégrité (par exemple, des requêtes hash et Merkel), ainsi que la gestion de la file d'attente et des limitations de débit.
Cet EIP a une signification architecturale, permettant à Eth1 de déclencher des opérations clés 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 au niveau d'Eth1 seront transmises et traitées plus efficacement au niveau de la couche de balise.
EIP-2537: Précompilation des opérations de courbe BLS12-381
Référence : EIP-2537
Si vous ne souhaitez pas approfondir, vous pouvez considérer la précompilation de BLS12-381 comme une opération de hachage cryptographique complexe qui peut maintenant être utilisée dans les contrats intelligents. Pour ceux qui sont intéressés, explorons davantage.
Les opérations mathématiques effectuées sur les courbes elliptiques telles que BLS12-381 (et son homologue BN-254) sont actuellement principalement utilisées à deux fins :
*La signature BLS, qui utilise une opération spéciale 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 vérificateurs dépendent des signatures BLS basées sur la courbe BLS12-381 (bien qu'elles puissent également utiliser toute autre courbe prenant en charge l'appariement, comme BN254).
Si vous souhaitez vérifier une signature BLS ou une preuve zkSNARK dans un smart contract, vous devez calculer ces "appariements", ce qui est très coûteux en termes de calcul. Ethereum dispose déjà d'un contrat précompilé pour les opérations sur la courbe BN254 (EIP-196 et EIP-197). Cependant, la courbe BLS12-381 (aujourd'hui considérée comme plus sûre et largement utilisée) n'est pas encore mise en œuvre en tant que précompilation. Sans une telle précompilation, la mise en œuvre des appariements et d'autres opérations sur la courbe dans un smart contract nécessite des calculs intensifs, comme indiqué ici, et consomme énormément de gaz (environ ~10^5 à 10^6 gaz).
Cette EIP ouvre la voie à de nombreuses applications potentielles, en particulier dans la vérification de signature BLS bon marché basée sur la courbe BLS12-381. Cela rend possible la mise en œuvre de schémas de seuil pour diverses fins. Comme mentionné précédemment, les validateurs Ethereum utilisent déjà des signatures basées sur BLS12-381. Grâce à cette EIP, les contrats intelligents standard peuvent désormais vérifier efficacement les signatures agrégées des validateurs. Cela simplifie la preuve de consensus et le pontage des actifs entre les réseaux, car les signatures BLS sont largement utilisées dans les blockchains. Les signatures BLS seuillées 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 des preuves zkSNARK moins chère débloquera à son tour de nombreuses applications. De nombreuses solutions basées sur zkSNARK sont actuellement entravées par des coûts élevés de vérification des preuves, ce qui rend certains projets presque irréalisables. Cet EIP a le potentiel de changer cela.
EIP-2935: Sauvegarde des hachages des blocs précédents dans l'état
Référence: EIP-2935
Cette proposition EIP propose de stocker 8192 (environ 27,3 heures) hachages d'anciens blocs dans l'état de la blockchain, afin de fournir une extension de l'historique aux clients sans état (tels que Rollup) et aux contrats intelligents. Il propose de conserver le comportement actuel de l'opération BLOCKHASH, en maintenant la limite de 256 blocs, tout en introduisant un nouveau contrat de système spécialement conçu pour stocker et récupérer les hachages historiques. Ce contrat effectue l'opération set)( lors du traitement des blocs au niveau d'exécution. Sa méthode get)( est accessible à tous pour récupérer les hachages de bloc nécessaires à partir d'un tampon circulaire.
Actuellement, dans l'EVM, il est possible de faire référence à l'empreinte historique des blocs, mais l'accès est limité aux 256 derniers blocs (environ 50 minutes). Cependant, il est parfois crucial d'accéder à des données de blocs plus anciens, en particulier pour les applications inter-chaînes (qui nécessitent une preuve des données des blocs précédents) et les clients sans état qui ont régulièrement besoin d'accéder à l'empreinte des blocs plus anciens.
Cet EIP étend la plage de temps disponible pour les applications rollup et cross-chain, leur permettant d'accéder directement aux données historiques dans l'EVM sans avoir besoin de les collecter à l'extérieur. Par conséquent, ces solutions deviennent plus robustes et durables.
EIP-7623: Augmentation du coût de calldata
Référence : EIP-7623
calldata ajuste le coût de la charge utile de transaction disponible, qui peut être important dans certaines circonstances (par exemple, lorsqu'un grand tableau ou un tampon binaire est transmis en tant que paramètre). L'utilisation significative de calldata est principalement due aux rollups, qui envoient la charge utile en incluant le calldata de l'état actuel du rollup.
Introduire des données binaires de grande taille et vérifiables dans la blockchain est crucial pour Rollup. La mise à niveau de Dencun (Deneb-Cancun) a introduit une innovation importante pour de tels cas d'utilisation - les transactions de blob (EIP-4844). Les transactions de blob ont leur propre frais de gaz spécialisé «blob», bien que leur corps soit temporairement stocké, leur preuve de chiffrement (engagement KZG) ainsi que leur hachage sont intégrés à la couche de consensus. Par conséquent, par rapport à l'utilisation de calldata pour stocker des données, les blobs offrent une meilleure solution pour Rollup.
Il est encouragé que rollup déplace ses données vers un blob en utilisant la méthode 'carotte et bâton'. La réduction des frais de gaz du blob est considérée comme 'la carotte', tandis que cet EIP utilise l'augmentation du coût des calldata comme 'le bâton' pour réduire le stockage excessif des données dans les transactions. Cet EIP complète le prochain EIP-7691 (augmentation du débit du blob), qui augmente le nombre maximal de blobs autorisés par bloc.
EIP-7691：augmentation du débit de blob
Référence : EIP-7691
Dans la bifurcation difficile précédente de Dencun, le blob a été introduit, et la valeur maximale et cible de "chaque bloc" blob était une estimation prudente. Cela est dû à la complexité de la manière dont le réseau p2p prévoit de traiter la propagation d'objets binaires de grande taille entre les nœuds validateurs. La configuration précédente s'est avérée efficace, ce qui en fait le bon moment pour tester de nouvelles valeurs. Auparavant, la cible / le nombre maximal de blobs par bloc était réglé à 3/6. Ces limites ont maintenant été respectivement augmentées à 6/9.
En combinant la EIP-7623 précédente (augmentation du coût du calldata), cet ajustement incite encore plus le rollup à transférer ses données de calldata vers des blobs. Les travaux pour trouver les meilleurs paramètres de blob se poursuivent.
EIP-7840: Ajouter la planification des blobs au fichier de configuration EL
Référence : EIP-7840
Cette proposition EIP propose d'ajouter la cible et le nombre maximal de « blobs par bloc » (discutés précédemment) ainsi que la valeur 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 de nœud. Cette fonctionnalité est particulièrement utile pour estimer les frais de gaz de blob, etc.
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 aux utilisateurs d'Ethereum. Comme nous le savons, un compte externe (EOA) ne peut pas avoir de code, mais peut fournir une signature de transaction (tx.origin). En revanche, un contrat intelligent a un bytecode, mais ne peut pas fournir de signature directe « de lui-même ». Toute interaction utilisateur nécessitant une logique supplémentaire, automatique et vérifiable ne peut actuellement être exécutée qu'en appelant un contrat externe pour effectuer les opérations nécessaires. Cependant, dans ce cas, le contrat externe devient le msg.sender des contrats ultérieurs, ce qui signifie que l'appel provient d'un « appel de contrat, pas de l'utilisateur ».
Cet EIP introduit un nouveau type de transaction SET_CODE_TX_TYPE=0x04 (nous avions précédemment une ancienne transaction 0x1, les nouvelles transactions 0x02 de l'upgrade Berlin et EIP-1559, ainsi que la transaction blob 0x03 introduite dans Dencun). Ce nouveau type de transaction permet de définir du code pour un compte EOA. En réalité, il permet à un EOA d'exécuter du code externe « dans le contexte de son propre compte EOA ». Du point de vue externe, lors de la transaction, l'EOA semble « emprunter » du code provenant d'un contrat externe et l'exécuter. Techniquement, cela est réalisé en ajoutant un tuple de données d'autorisation spéciales au « stockage du code » de l'adresse EOA (avant cet EIP, ce stockage du « code » était toujours vide pour les EOA).
Actuellement, ce nouveau type de transaction 0x04 proposé par EIP contient un tableau :
authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]
Chaque élément permet à un compte d'utiliser le code provenant de l'adresse spécifiée (à partir de la dernière autorisation valide). Lors du traitement de ce type de transaction, le code de l'EOA donné est défini comme une valeur spéciale 0xef0100 || adresse (23 octets), où l'adresse pointe vers le contrat contenant le code requis, || représente la concaténation, 0xef0100 représente une valeur magique spéciale qui ne peut pas être contenue dans un contrat intelligent ordinaire (selon EIP-3541). Cette valeur magique garantit que cet EOA ne peut pas être considéré comme un contrat ordinaire et ne peut pas être appelé de la même manière qu'un contrat ordinaire.
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 la mise en œuvre de cet EIP ne soient pas encore clairs, il est certain qu'il apportera des changements majeurs.
Une influence majeure est la capacité de faire des appels multiples (multicall) directement à partir d'un EOA. Les appels multiples sont une tendance continue dans la DeFi, avec de nombreux protocoles offrant cette fonctionnalité comme un outil puissant (comme Uniswap V4, Balancer V3 ou Euler V2). Avec cet EIP, il est maintenant possible de lancer directement des appels multiples à partir d'un EOA.
Par exemple, cette nouvelle fonctionnalité résout un problème courant dans DeFi : l'inefficacité de deux transactions distinctes pour approve)( + anything)(. Cette EIP permet une logique de « préautorisation » générique, ce qui permet de réaliser approve)X( + deposit)X( dans une seule transaction.
Une autre caractéristique importante de l'exécution des transactions d'EOA par délégation est le concept de parrainage. Le parrainage est une fonctionnalité souvent discutée et très attendue pour aider les nouveaux utilisateurs à entrer dans Ethereum.
La logique programmable associée à l'EOA a débloqué de nombreuses possibilités, telles que la mise en œuvre de restrictions de sécurité, la définition de limites de dépenses, l'exigence de KYC, etc.
Bien sûr, ce changement soulève également de nombreuses questions de conception. Une question est l'utilisation de chain_id, qui détermine si une même signature est valide sur plusieurs réseaux, en fonction de sa présence ou de son absence dans la signature. Un autre problème complexe est le choix entre l'utilisation d'adresses de code cible et l'incorporation de bytecode réel. Les deux approches ont leurs propres caractéristiques et limitations. De plus, l'utilisation de nonce joue un rôle clé dans la définition des autorisations comme étant "multifonctionnelles" ou "uniques". Ces éléments ont un impact sur les problèmes de fonctionnalité et de sécurité, tels que les signatures en vrac invalides et la convivialité. Vitalik soulève ces questions dans une discussion (ici) qui mérite d'être explorée davantage.
Il convient de noter que ce changement aura un impact sur un mécanisme de sécurité d'Ethereum, tx.origin. Plus de 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 toujours été le moyen le plus fiable de s'assurer que msg.sender est un compte externe (EOA) plutôt qu'un contrat. D'autres méthodes, telles que la vérification de la taille du code externe (EXTCODESIZE) pour déterminer s'il s'agit d'un contrat, échouent souvent et peuvent être contournées (par exemple, en appelant le constructeur ou en déployant du code à une adresse prédéfinie après la transaction). Ces vérifications sont utilisées pour éviter les attaques de réentrance et de prêt éclair, mais elles ne sont pas idéales car elles entravent également l'intégration avec des protocoles externes. Après cet EIP, il semble que même la vérification fiable de require)tx.origin == msg.sender( devienne obsolète. Les protocoles devront s'adapter en supprimant ces vérifications car la distinction entre "EOA" et "contrat" ne sera plus pertinente - chaque adresse peut désormais avoir un code associé.
La séparation traditionnelle entre les EOA et les contrats intelligents continue à s'estomper. Cet EIP rapproche Ethereum de conceptions telles que TON, où chaque compte est essentiellement du code exécutable. À mesure que les interactions avec le protocole deviennent de plus en plus complexes, l'utilisation de la logique programmable pour améliorer l'expérience utilisateur finale est un processus évolutif naturel.
Conclusion
La mise à niveau de Prague / Electra (Pectra) est prévue pour mars 2025. Les changements les plus significatifs de son plan comprennent :
Comme vous pouvez le voir, Pectra aura un impact majeur sur l'expérience utilisateur finale en ce qui concerne le staking, la couche de consensus et la couche d'exécution. Bien que nous ne puissions pas analyser en détail toutes ces modifications à ce stade en raison du développement en cours, nous les aborderons dans des articles futurs.