La fourchette dure de Pectra est prévue pour un déploiement sur le réseau principal en mars 2025. La mise à niveau de Pectra comprend 11 protocoles techniques (EIP), à savoir :
EIP-2537: Précompilation des opérations sur la courbe BLS12-381
EIP-2935: 在 State 中保存历史区块哈希值
EIP-6110 : Fournit des dépôts de validateurs on-chain
EIP-7002: Exécution de la couche déclenche la sortie
EIP-7251: Ajouter le MAX_EFFECTIVE_BALANCE
EIP-7549: Déplacer l'index du comité en dehors de la validation
EIP-7623: Coût supplémentaire de la calldata
EIP-7685: Demande de couche d'exécution générale
EIP-7691: Augmentation du débit de Blob
EIP-7702 : Définir le code de compte EOA
EIP-7840: Ajouter un plan Blob dans le fichier de configuration EL
Protocole technique lié à la mise en jeu
EIP-6110: Précompilation des opérations de courbe BLS12-381
Simplifiez le processus de participation à la mise en jeu pour réduire considérablement le temps d'attente.
La manière dont les utilisateurs participent au jalonnement est de déposer 32 ETH sur la couche d'exécution et d'enregistrer dans le journal des événements (Event Log), puis la couche de consensus analyse le journal des événements pour déterminer si quelqu'un participe au jalonnement, et les utilisateurs participant au jalonnement deviennent des validateurs.
Cependant, les validateurs de la couche de consensus doivent d'abord décider à quel moment précis ils doivent déposer leur consensus. Sinon, certains validateurs verront 5 nouveaux dépôts, tandis que d'autres n'en verront que 3. Par conséquent, les validateurs de la couche de consensus voteront pour décider quel bloc de couche d'exécution (eth1data) doit être référencé, afin de garantir que tous voient le même bloc de couche d'exécution.
Cependant, lors de la conception initiale, afin d'éviter que des erreurs majeures ne se produisent dans la couche d'exécution et entraînent une bifurcation de la chaîne, le bloc de référence de la couche d'exécution (eth1data) sera un bloc de la couche d'exécution datant d'environ 10 heures plus tôt, garantissant aux développeurs de la couche de consensus suffisamment de temps pour réagir en cas d'erreurs majeures. Cependant, cela signifie également que la participation au jalonnement ne sera effective qu'après plus de 10 heures.
!
△ Les 10900000 eth1data dans le bloc CL, le Block Hash enregistré dans celui-ci est le 21683339 du bloc de couche d’exécution, qui est apparu il y a 10 heures.
Après l'implémentation du protocole technique EIP-6110, les données de mise en jeu sur le contrat deviendront directement une partie de la couche d'exécution, et comme les blocs de la couche de consensus contiendront déjà des blocs de la couche d'exécution (mais pas eth1data), les validateurs de la couche de consensus n'auront plus à se soucier de la question de la « concordance des blocs mémoire de la couche d'exécution ». Il suffit que les blocs mémoire de la couche de consensus obtiennent la confirmation de plus des deux tiers des validateurs par vote, alors tout le monde s'accorde à dire qu'il s'agit du même bloc de la couche d'exécution. Ainsi, après avoir participé à la mise en jeu, les données de mise en jeu peuvent prendre effet en aussi peu que 13 minutes une fois que les blocs mémoire de la couche d'exécution sont traités, et le client de la couche de consensus peut également supprimer la logique complexe initialement utilisée pour traiter les données de mise en jeu.
EIP-7002: Sauvegarder les valeurs de hachage des blocs historiques dans l'état
Il peut être utilisé pour améliorer le processus permettant aux validateurs de retirer ou de retirer des dépôts et des gains, réduisant ainsi les risques pour les validateurs.
La participation au jalonnement nécessite deux clés, à savoir la clé du validateur et le justificatif de retrait.
La clé du validateur est utilisée pour vérifier le contenu du travail du validateur, le certificat de retrait est utilisé pour l'adresse à laquelle les dépôts et les revenus seront retirés lorsque le validateur se retire de la mise en jeu, de plus, actuellement, le retrait de la mise en jeu doit être effectué avec la clé du validateur.
Si vous perdez votre clé de validation, vous ne pouvez pas effectuer de travail de validation et vous ne pouvez pas retirer votre mise en jeu. Si vous perdez votre identifiant de retrait, vous perdrez tous vos dépôts et vos gains. En outre, certains utilisateurs utilisent des services de jalonnement tiers tels que Lido, où les utilisateurs sont tenus de conserver leurs propres identifiants de retrait, tandis que les clés de validation sont détenues par le fournisseur de services et effectuent le travail du validateur en leur nom.
En suivant le protocole technique EIP-7002, les utilisateurs peuvent appeler le contrat "Withdraw" (déployé à l'adresse 0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA) avec leur Credential de Retrait pour sortir leur mise (Exit) ou retirer une partie de leur mise et des gains (Retrait Partiel), ce qui peut réduire les risques associés à l'utilisation de services de mise en gage tiers. Même si un utilisateur participe à la mise en gage de manière autonome mais perd sa clé de validateur, il peut également sortir sa mise de cette manière.
Les paramètres de la demande comprennent validator_pubkey et le montant : validator_pubkey est la clé publique du validateur, amount est la quantité à retirer.
Le retrait des crédits demandés doit être le crédit de retrait du validateur validator_pubkey.
Lors de l'appel du contrat de retrait pour initier une demande, des frais de gaz (ETH) doivent être inclus. Les frais de gaz sont calculés en fonction du nombre actuel de demandes de retrait, et augmenteront si le nombre de demandes est élevé.
Si l’identifiant de retrait de l’utilisateur est un contrat, vous pouvez accéder au contrat de retrait pour obtenir le montant actuel des frais, puis lancer une demande et joindre les frais ; Cependant, si le justificatif de retrait est un compte EOA, il n’y a aucun moyen d’obtenir des frais précis, vous ne pouvez donc que simuler l’off-chain à l’avance et payer les frais excédentaires (qui ne seront pas remboursés) pour vous assurer que la demande sera exécutée avec succès.
*Remarque : Si votre identifiant de retrait est toujours au format de clé publique BLS, n’oubliez pas de le remplacer d’abord par le format d’adresse EL. *
EIP-7251: Ajouter le MAX_EFFECTIVE_BALANCE
La possibilité d'augmenter considérablement la limite de dépôt pour réduire le nombre de validateurs, et les validateurs qui n'ont pas atteint la limite peuvent automatiquement bénéficier des revenus de leur dépôt.
Les utilisateurs qui souhaitent devenir des validateurs doivent fournir une quantité d'ETH égale à MAX_EFFECTIVE_BALANCE, qui est actuellement de 32 ETH. S'ils possèdent 1024 ETH à staker, ils peuvent participer au staking 32 fois, activer 32 validateurs et exécuter 32 nœuds de validation. La participation active au staking a entraîné la présence d'environ 1 million de validateurs, ce qui a considérablement accru la charge sur le réseau P2P de la couche de consensus en raison de l'augmentation des données d'état et du nombre important de signatures des validateurs à transmettre et agréger à chaque slot (toutes les 12 secondes).
Après l'exécution du protocole technique EIP-7251, le seuil de mise en jeu (MIN_ACTIVATION_BALANCE) reste à 32 ETH, mais le plafond (MAX_EFFECTIVE_BALANCE) sera considérablement augmenté à 2048 ETH. Vous pouvez miser n'importe quel montant d'ETH entre 32 et 2048 pour obtenir des gains de mise en jeu, sans avoir à retirer régulièrement les gains. Vous pourrez continuer à miser une fois que vous aurez accumulé 32 ETH.
Currently, existing validators do not need to withdraw their stakes first and then rejoin the stake together. Instead, they can directly use the newly added 'merged deposit contract' on the execution layer (deployed at 0x00431F263cE400f4455c2dCf564e53007Ca4bbBb), and validators' Withdrawal Credentials call the contract to initiate a request to merge the deposit.
Les paramètres de la demande de fusion de dépôt comprennent source_pubkey et target_pubkey : ces deux clés sont la clé de validation du validateur, le validateur source fusionnera avec le validateur cible.
L’identifiant de retrait à l’origine de la demande doit être l’identifiant de retrait du vérificateur de source.
Lors de l'appel du contrat de fusion de dépôt pour initier une demande, des frais (ETH) doivent être inclus, les frais seront calculés en fonction du nombre actuel de demandes, si le nombre de demandes est élevé, les frais augmenteront.
Si l’identifiant de retrait de l’utilisateur est un contrat, vous pouvez appeler le contrat de dépôt de fusion pour obtenir le montant actuel des frais, puis lancer une demande et joindre les frais ; Cependant, si le justificatif de retrait est un compte EOA, il n’y a aucun moyen d’obtenir des frais précis, vous ne pouvez donc que simuler l’off-chain à l’avance et payer les frais excédentaires (qui ne seront pas remboursés) pour vous assurer que la demande sera exécutée avec succès.
Remarque : Si votre identifiant de retrait est au format de clé publique BLS, vous devez d’abord le basculer au format d’adresse EL.
EIP-7685: Demande de couche d'exécution générale
Établissez un pipeline d’informations EL-> CL formel afin que les utilisateurs et les services de jalonnement puissent envoyer des requêtes directement à la couche de consensus.
Les utilisateurs peuvent envoyer des requêtes directement de la couche d’exécution à la couche de consensus, et les services de jalonnement (tels que Lido) peuvent fonctionner de manière plus décentralisée. Il s’agit par exemple de la demande de retrait de l’EIP-7002 et de la demande de fusion des dépôts de l’EIP-7251. Sans ce protocole technique, les utilisateurs de Lido devraient faire confiance au fournisseur de services de nœud Lido pour exécuter le dépôt de désjalonnement ou de fusion au niveau de la couche de consensus. Grâce à ce protocole technique, les utilisateurs de Lido peuvent envoyer des requêtes directement via le contrat de gouvernance au niveau de la couche d’exécution.
Ces requêtes seront différenciées par le type de requête Request Type, ainsi que par l'initiation de la requête par le biais de contrats différents. Enfin, ces requêtes seront toutes écrites dans des blocs de mémoire de la couche d'exécution, de sorte que la couche de consensus puisse directement obtenir ces informations à travers les blocs de mémoire d'exécution, sans avoir besoin d'écrire une logique d'analyse individuelle.
Les EIP-6110, EIP-7002 et EIP-7251 sont tous des normes définies par l'EIP-7685 pour formuler des demandes :
EIP-6110 Ajouter une demande de jalonnement : Type de demande = 0, via le contrat de dépôt
(0x00000000219ab540356cbb839cbe05303d7705fa) Initiation d’une demande.
Demande de retrait EIP-7002 : Type de demande=1, via le contrat de retrait Withdraw
(0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA) Initiation d’une demande.
Fusion de demandes de dépôt EIP-7251: Type de demande=2, via le contrat de consolidation
(0x00431F263cE400f4455c2dCf564e53007Ca4bbBb) Initiation d’une demande.
Protocole technologique pour améliorer l'expérience utilisateur
EIP-7702: Définir le code de compte EOA
Permettre aux comptes EOA de se transformer en comptes de contrat de manière arbitraire, améliorant considérablement l'expérience d'utilisation.
Les comptes EOA ont quelques lacunes dans leur utilisation, notamment :
Il est nécessaire de noter et de conserver la clé privée ou la phrase mnémonique, ce qui rend l'inscription des nouveaux utilisateurs plus contraignante.
Un compte EOA ne peut effectuer qu’une seule opération par transaction, par exemple, si vous souhaitez vous rendre sur Uniswap pour échanger des USDT contre des ETH, vous devez d’abord initier une transaction pour approuver l’USDT, puis vous pouvez envoyer une autre transaction pour exécuter l’échange.
Contrôle des autorisations qui ne peut pas être affiné, comme le transfert de certaines opérations du compte à un tiers pour opérer au nom de l’utilisateur, l’utilisateur doit gérer personnellement chaque corvée et signer une transaction pour chaque opération.
Aucun mécanisme de récupération, vous devez garder vos clés privées ou vos mots de passe en sécurité. Si vous les perdez, vous ne pourrez plus récupérer vos actifs de votre compte.
Si c'est un compte de contrat intelligent (par exemple Safe), tous les problèmes susmentionnés peuvent être résolus :
Les utilisateurs peuvent utiliser la clé privée dans la puce de sécurité du téléphone mobile (ou de l’ordinateur) pour signer l’autorisation, pas besoin de se souvenir d’une clé privée ou de mots mnémoniques, ou d’utiliser le courrier électronique pour signer l’autorisation, ou d’autres méthodes d’autorisation diverses.
Vous pouvez regrouper plusieurs opérations en lots et les exécuter ensemble dans une seule transaction, les opérations complexes des applications décentralisées peuvent être autorisées par une seule signature et complétées par une seule transaction.
Il peut y avoir un contrôle très précis des autorisations, les utilisateurs peuvent autoriser des tiers à contrôler leur compte, mais en même temps spécifier "avec quels contrats intelligents ils peuvent interagir","quelles opérations ne peuvent pas être effectuées","quels actifs peuvent être impliqués dans le transfert d'actifs", ou "combien d'actifs peuvent être utilisés au maximum", ou "combien d'opérations peuvent être effectuées au maximum par semaine", etc.
Vous pouvez ajouter un mécanisme de récupération, et vous pouvez également transférer les actifs du compte vers un nouveau compte via le mécanisme de récupération lorsque vous perdez votre phrase mnémotechnique, votre téléphone portable ou votre e-mail.
La proposition EIP-7702 consiste à donner à un compte EOA le pouvoir de se transformer en compte de contrat. L'utilisateur signe le message de transformation avec la clé privée EOA, le contenu de la signature comprenant l'«ID de chaîne», «l'adresse du contrat devenant» et «la valeur de hachage de l'EOA» :
ID de la chaîne : Utilisé pour empêcher la signature de la chaîne A d’être rejouée par la chaîne B. Toutefois, si l’ID de la chaîne est défini sur 0, cela signifie que vous êtes prêt à vous transformer en chaque chaîne.
L’adresse du contrat que vous souhaitez devenir : si vous renseignez une adresse de contrat Safe, votre compte EOA deviendra un contrat Safe ; Si vous renseignez l’adresse vide (address(0)), cela signifie que vous souhaitez annuler la modification et revenir à un compte EOA pur.
La valeur du Nonce de l'EOA : utilisée pour empêcher la répétition de la signature. Si la valeur du Nonce est augmentée, la signature d'origine deviendra invalide.
Cependant, il y a quelques points à noter :
La clé privée EOA peut continuer à être utilisée
Même si le compte EOA de l’utilisateur devient un contrat, il peut continuer à l’utiliser de la même manière que le compte EOA d’origine. Par exemple, si votre compte EOA devient un contrat Safe, vous pouvez utiliser l’interface Safe, suivre le processus de transaction Safe ou continuer à signer et à envoyer des transactions avec le portefeuille EOA d’origine. Cependant, cela signifie également que la sécurité du compte est toujours limitée à la clé privée.
La sécurité de la clé privée EOA est toujours primordiale
Même si le compte EOA de l'utilisateur devient un compte multi-signatures, tant qu'il ne perd pas la clé privée EOA, la sécurité de son compte dépendra toujours de la sécurité de la clé privée EOA : il devra toujours bien protéger sa clé privée ou sa phrase de récupération, et son compte ne sera pas aussi sécurisé qu'un compte multi-signatures pour autant.
Le stockage du compte EOA n’est pas formaté
Lorsqu'un compte EOA se transforme en contrat et écrit des données dans son stockage, ces données écrites dans le stockage ne seront pas formatées en raison de la transformation du compte EOA en un autre contrat ou de l'annulation de la transformation, à moins que des actions explicites de suppression des données ne soient effectuées. Par conséquent, les développeurs doivent faire attention à ne pas lire les données laissées par les contrats précédemment transformés dans le stockage, comme indiqué dans l'ERC-7201.
Le processus EIP-7702 n’inclut pas l’initialisation
En règle générale, un compte de contrat a besoin d’une étape d’initialisation pour écrire de manière synchrone les informations du propriétaire du compte (telles que la clé publique ou l’adresse) lorsque le compte est déployé, afin d’éviter la perte de propriété du compte en raison de l’exécution anticipée de l’étape de déploiement. Cette opération est généralement effectuée par le contrat d’usine qui déploie le compte de contrat pour effectuer « déploiement + initialisation », mais comme EIP-7702 est un changement direct, plutôt qu’une usine qui déploie le contrat sur EOA, l’attaquant peut copier la signature de transformation de l’utilisateur et envoyer de manière préventive la transaction à la chaîne pour qu’elle se transforme pour l’utilisateur, mais initialise le compte pour qu’il soit contrôlable par l’attaquant, de sorte que les développeurs doivent prêter attention à EIP-7702. Une méthode de défense possible consiste à vérifier la signature du compte EOA dans la fonction d’initialisation, de sorte que même si elle est préemptée, l’attaquant ne sera pas en mesure de générer la signature du compte EOA pour terminer l’initialisation.
Le portefeuille doit surveiller les demandes de changement.
Le portefeuille doit bien surveiller pour les utilisateurs, intercepter et avertir les utilisateurs lorsque des sites Web DApp malveillants demandent à l'utilisateur de signer une transaction de transformation. Sinon, si l'utilisateur signe une transaction de transformation malveillante, les actifs seront instantanément transférés. Voici quelques exemples d'implémentation de contrats de transformation :
Modification du compte Safe Ithaca
Compte d’Ithaque
Protocole technique DApp
EIP-2537 : BLS12-381 Précompilateur d’opérations de courbe
Réduire les coûts et rendre plus réalisable l'application de preuve de connaissance nulle basée sur la courbe BLS.
L’EIP-2537 ajoute plusieurs nouveaux contrats de précompilation pour fournir des opérations de courbe BLS peu coûteuses, ce qui rend plus réalisable le développement d’applications de preuve à divulgation nulle de connaissance basées sur des courbes BLS.
EIP-2935 : Enregistrement des hachages de blocs historiques dans l’état
Permettre aux développeurs ou aux nœuds de lire directement la valeur de hachage du bloc précédent à partir du stockage du contrat système.
Si un développeur a besoin de prouver le contenu d’un bloc de mémoire précédent, par exemple, si le défi de fraude Optimismtic Rollup veut prouver qu’une transaction existe dans 1000 blocs de mémoire précédents, le challenger ne peut pas le dis-le directement.
« Croyez-moi, 1000 blocs de mémoire existaient vraiment avant », il a dû témoigner, mais il n’y avait aucune preuve directe pour prouver que « 1000 blocs de mémoire précédents contenaient ce contenu », il a donc dû prouver la transaction dans une « chaîne » de blocs de mémoire, bloc par bloc, jusqu’à ce qu’elle atteigne 1000 blocs précédents, puis prouver que la transaction existait dans le bloc.
!
△ Chaque bloc pointe vers un bloc parent, ce qui permet de prouver n'importe quel bloc de l'histoire tout au long du chemin.
Supposons qu’il s’agisse actuellement d’un bloc de mémoire avec un numéro 10000, et que le défi de fraude veuille fournir la preuve que le bloc de mémoire avec le numéro 9000 a une transaction X, le challenger doit commencer par le hachage du bloc de mémoire 10000, d’abord prouver le hachage du bloc de mémoire parent 9999 connecté au bloc de mémoire 10000, puis prouver le bloc de mémoire 9998... Jusqu’au bloc mémoire 9000, le contenu du bloc mémoire 9000 est proposé pour contenir la transaction X.
Après EIP-2935, il y aura un contrat système (déployé sur 0x0F792be4B0c0cb4DAE440Ef133E90C0eCD48CCCC) qui stockera les hachages d’un maximum de 8192 blocs de mémoire précédents. Chaque fois qu’un nouveau bloc de mémoire est généré, le contrat système sera automatiquement mis à jour pour écrire le hachage du bloc précédent dans le contrat système (le hachage des 8192 blocs de mémoire précédents sera réécrit).
De cette façon, dans l’exemple du défi de fraude Optimismtic Rollup, le challenger n’a pas besoin de revenir au bloc de mémoire précédent pour prouver un bloc de mémoire à la fois, mais peut prouver directement que dans l’état actuel de la chaîne de blocs de mémoire 10000, la valeur d’un certain stockage (correspondant au bloc de mémoire 9000) du contrat système est la valeur de hachage du bloc de mémoire 9000. Si la plage dépasse 8192, comme le bloc de mémoire 1000, il s’agit tout au plus d’une étape supplémentaire pour prouver la valeur de hachage du bloc de mémoire 1808 (= 10000 - 8192), puis prouver la valeur de hachage du bloc de mémoire 1000 dans le contrat système dans l’état actuel de la chaîne du bloc de mémoire 1808.
Cela ouvre également la voie à un futur client sans état : à l’avenir, les nœuds légers n’auront plus besoin de stocker les en-têtes de bloc de tous les blocs de mémoire historiques, mais n’auront besoin que de demander à quelqu’un d’autre de fournir une preuve en utilisant la méthode de preuve dans l’exemple de défi de fraude précédent lorsqu’il est nécessaire d’utiliser le hachage d’un bloc de mémoire dans l’historique ou le contenu du bloc de mémoire.
EIP-7623 : Augmentation du coût des données d’appel
Augmentez le coût de publication des données avec calldata afin de libérer suffisamment d’espace sécurisé pour augmenter la limite de gaz de bloc et la limite d’objets blob.
Avec la demande croissante de publication de données Rollup, l'introduction de Blob dans l'EIP-4844 permet à Rollup de stocker des données de manière très économique. L'augmentation de la quantité de Blob a toujours été un upgrade attendu par la communauté, tout comme l'augmentation récente de la limite de gaz de bloc poussée par la communauté, qui reflète la demande croissante de ressources dans l'écosystème.
!
△ De plus en plus de validateurs ont exprimé leur soutien à l’augmentation de la limite de gaz de bloc.
Cependant, l’augmentation de la limite de gaz de bloc ou du nombre de blobs mettra plus de pression sur le réseau p2p d’Ethereum à mesure que la quantité de données traitées augmentera, ce qui rendra les attaquants plus efficaces, à moins que le coût de publication des données n’augmente.
Après la publication du protocole EIP-7623, le coût des données d’appel sera multiplié par 2,5 par rapport à l’original « Zéro octet : 4 gaz, octet non nul : 16 gaz » à « Zéro octet : 10 gaz, octet non nul : 40 gaz ».
Si un attaquant utilisait tout le Block Gas Limit (30M) pour des données indésirables, la taille des blocs mémoire serait d'environ 1,79 Mo (30M / 16), comparée à une taille moyenne de bloc mémoire d'environ 100 Ko ; et si le Block Gas Limit était augmenté à 40M, l'attaquant pourrait générer des blocs mémoire d'environ 2,38 Mo. L'augmentation du coût de calldata de 2,5 fois entraînerait une diminution de l'efficacité de l'attaquant, se traduisant par une taille maximale de 0,72 Mo pour 30M et 0,95 Mo pour 40M, permettant ainsi d'augmenter plus sereinement le Block Gas Limit et le nombre de Blobs. Cependant, ce protocole technique ne souhaite pas perturber les utilisateurs ordinaires qui n'utilisent pas calldata pour publier des données, il calcule donc le total de Gas des transactions de deux manières et retient le plus élevé :
La méthode originale de calcul de la consommation de gaz de la transaction est calculée avec l’ancien coût calldata : c’est-à-dire que les calldata sont calculées de la manière suivante : « Zéro octet : 4 gaz, octet non nul : 16 gaz », et le gaz consommé par l’exécution de la transaction et le gaz consommé par le contrat de déploiement sont ajoutés.
Calculer simplement la quantité de gaz calldata, mais en utilisant un nouveau coût: c'est-à-dire calculer calldata de la manière suivante : «Zéro octet : 10 gaz, Octet non nul : 40 gaz», mais sans tenir compte du gaz consommé lors de l'exécution ou du déploiement du contrat, donc pour les utilisateurs généraux qui ne publient pas les données de calldata (par exemple pour échanger sur Uniswap), la principale consommation de gaz est dans la partie d'exécution, même si calldata est calculé avec un nouveau coût, cela ne dépassera pas la consommation de gaz de l'exécution, donc en général, les utilisateurs ne seront pas affectés.
Les Rollup de petite taille seront les plus touchés, car Blob a une taille fixe et des frais fixes. Par conséquent, les petits Rollup qui utilisent Blob sont moins efficaces, il est plus rentable d'utiliser calldata. Cependant, après l'EIP-7623, les coûts de ces petits Rollup augmenteront de 2,5 fois. Ils pourraient donc être contraints de passer à l'utilisation de Blob ou de trouver un moyen de partager un Blob collectivement.
EIP-7691 : Augmenter le débit d’objets blob
Augmentez le nombre d’objets blob et ajoutez plus d’espace pour la publication de données dans les cumuls. *
EIP-7691 augmente le nombre de Blob de "objectif: 6 Blob, limite supérieure: 9 Blob" par rapport à "objectif: 3 Blob, limite supérieure: 6 Blob", offrant ainsi plus d'espace pour la publication de données à Rollup.
Remarque : En outre, il existe certaines conceptions sur le marché des frais Blob qui doivent être affinées, telles que la vitesse d’ajustement des frais n’est pas assez instantanée et le plancher des frais est trop bas, mais ce n’est pas le problème que ce protocole technique vise à résoudre.
Autres protocoles technologiques
EIP-7549: Déplacer l'index du comité en dehors de la validation
Ajuster le contenu du vote du validateur pour faciliter l'agrégation des votes et réduire la pression sur le réseau p2p.
Les validateurs seront répartis aléatoirement en comités à chaque époque et
Dans le vote par bloc de mémoire, les votes des validateurs de chaque comité peuvent être agrégés, ce qui réduit le nombre de votes passés dans le réseau P2P, mais les votes du validateur contiendront des informations sur le nombre de comités auxquels le validateur appartient, ce qui signifie que les votes des différents comités ne peuvent pas être agrégés, même s’ils votent tous sur le même bloc de mémoire.
EIP-7549 retire les informations sur "à quel comité appartient le validateur" du contenu du vote, de sorte que les validateurs de différents comités peuvent être regroupés ensemble lorsque le contenu du vote est le même, réduisant ainsi davantage le nombre de votes transmis dans le réseau peer-to-peer et réduisant la pression sur le réseau peer-to-peer.
EIP-7840: Ajouter un plan Blob au fichier de configuration EL
Créez un fichier de configuration pour les paramètres Blob au niveau d'exécution, évitant ainsi aux nœuds de niveau d'exécution de consulter les paramètres Blob associés au niveau de consensus.
Les paramètres associés à Blob sont actuellement stockés dans les nœuds de la couche de consensus, mais les nœuds d'exécution ont parfois besoin de ces paramètres (par exemple, RPC eth_feeHistory), ils doivent donc tous consulter les nœuds de la couche de consensus.
EIP-7840 crée un fichier de configuration pour les paramètres liés à l’objet blob au niveau de la couche d’exécution, et les nœuds de la couche d’exécution peuvent lire directement les paramètres liés à l’objet blob via ce fichier de configuration sans avoir à demander aux nœuds de la couche de consensus.
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.
Introduction au Hard Fork Ethereum Pectra
Auteur : NIC Lin, Medium
La fourchette dure de Pectra est prévue pour un déploiement sur le réseau principal en mars 2025. La mise à niveau de Pectra comprend 11 protocoles techniques (EIP), à savoir :
Protocole technique lié à la mise en jeu
EIP-6110: Précompilation des opérations de courbe BLS12-381
Simplifiez le processus de participation à la mise en jeu pour réduire considérablement le temps d'attente.
La manière dont les utilisateurs participent au jalonnement est de déposer 32 ETH sur la couche d'exécution et d'enregistrer dans le journal des événements (Event Log), puis la couche de consensus analyse le journal des événements pour déterminer si quelqu'un participe au jalonnement, et les utilisateurs participant au jalonnement deviennent des validateurs.
Cependant, les validateurs de la couche de consensus doivent d'abord décider à quel moment précis ils doivent déposer leur consensus. Sinon, certains validateurs verront 5 nouveaux dépôts, tandis que d'autres n'en verront que 3. Par conséquent, les validateurs de la couche de consensus voteront pour décider quel bloc de couche d'exécution (eth1data) doit être référencé, afin de garantir que tous voient le même bloc de couche d'exécution.
Cependant, lors de la conception initiale, afin d'éviter que des erreurs majeures ne se produisent dans la couche d'exécution et entraînent une bifurcation de la chaîne, le bloc de référence de la couche d'exécution (eth1data) sera un bloc de la couche d'exécution datant d'environ 10 heures plus tôt, garantissant aux développeurs de la couche de consensus suffisamment de temps pour réagir en cas d'erreurs majeures. Cependant, cela signifie également que la participation au jalonnement ne sera effective qu'après plus de 10 heures.
!
△ Les 10900000 eth1data dans le bloc CL, le Block Hash enregistré dans celui-ci est le 21683339 du bloc de couche d’exécution, qui est apparu il y a 10 heures.
Après l'implémentation du protocole technique EIP-6110, les données de mise en jeu sur le contrat deviendront directement une partie de la couche d'exécution, et comme les blocs de la couche de consensus contiendront déjà des blocs de la couche d'exécution (mais pas eth1data), les validateurs de la couche de consensus n'auront plus à se soucier de la question de la « concordance des blocs mémoire de la couche d'exécution ». Il suffit que les blocs mémoire de la couche de consensus obtiennent la confirmation de plus des deux tiers des validateurs par vote, alors tout le monde s'accorde à dire qu'il s'agit du même bloc de la couche d'exécution. Ainsi, après avoir participé à la mise en jeu, les données de mise en jeu peuvent prendre effet en aussi peu que 13 minutes une fois que les blocs mémoire de la couche d'exécution sont traités, et le client de la couche de consensus peut également supprimer la logique complexe initialement utilisée pour traiter les données de mise en jeu.
EIP-7002: Sauvegarder les valeurs de hachage des blocs historiques dans l'état
Il peut être utilisé pour améliorer le processus permettant aux validateurs de retirer ou de retirer des dépôts et des gains, réduisant ainsi les risques pour les validateurs.
La participation au jalonnement nécessite deux clés, à savoir la clé du validateur et le justificatif de retrait.
La clé du validateur est utilisée pour vérifier le contenu du travail du validateur, le certificat de retrait est utilisé pour l'adresse à laquelle les dépôts et les revenus seront retirés lorsque le validateur se retire de la mise en jeu, de plus, actuellement, le retrait de la mise en jeu doit être effectué avec la clé du validateur.
Si vous perdez votre clé de validation, vous ne pouvez pas effectuer de travail de validation et vous ne pouvez pas retirer votre mise en jeu. Si vous perdez votre identifiant de retrait, vous perdrez tous vos dépôts et vos gains. En outre, certains utilisateurs utilisent des services de jalonnement tiers tels que Lido, où les utilisateurs sont tenus de conserver leurs propres identifiants de retrait, tandis que les clés de validation sont détenues par le fournisseur de services et effectuent le travail du validateur en leur nom.
En suivant le protocole technique EIP-7002, les utilisateurs peuvent appeler le contrat "Withdraw" (déployé à l'adresse 0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA) avec leur Credential de Retrait pour sortir leur mise (Exit) ou retirer une partie de leur mise et des gains (Retrait Partiel), ce qui peut réduire les risques associés à l'utilisation de services de mise en gage tiers. Même si un utilisateur participe à la mise en gage de manière autonome mais perd sa clé de validateur, il peut également sortir sa mise de cette manière.
*Remarque : Si votre identifiant de retrait est toujours au format de clé publique BLS, n’oubliez pas de le remplacer d’abord par le format d’adresse EL. *
EIP-7251: Ajouter le MAX_EFFECTIVE_BALANCE
La possibilité d'augmenter considérablement la limite de dépôt pour réduire le nombre de validateurs, et les validateurs qui n'ont pas atteint la limite peuvent automatiquement bénéficier des revenus de leur dépôt.
Les utilisateurs qui souhaitent devenir des validateurs doivent fournir une quantité d'ETH égale à MAX_EFFECTIVE_BALANCE, qui est actuellement de 32 ETH. S'ils possèdent 1024 ETH à staker, ils peuvent participer au staking 32 fois, activer 32 validateurs et exécuter 32 nœuds de validation. La participation active au staking a entraîné la présence d'environ 1 million de validateurs, ce qui a considérablement accru la charge sur le réseau P2P de la couche de consensus en raison de l'augmentation des données d'état et du nombre important de signatures des validateurs à transmettre et agréger à chaque slot (toutes les 12 secondes).
Après l'exécution du protocole technique EIP-7251, le seuil de mise en jeu (MIN_ACTIVATION_BALANCE) reste à 32 ETH, mais le plafond (MAX_EFFECTIVE_BALANCE) sera considérablement augmenté à 2048 ETH. Vous pouvez miser n'importe quel montant d'ETH entre 32 et 2048 pour obtenir des gains de mise en jeu, sans avoir à retirer régulièrement les gains. Vous pourrez continuer à miser une fois que vous aurez accumulé 32 ETH.
Currently, existing validators do not need to withdraw their stakes first and then rejoin the stake together. Instead, they can directly use the newly added 'merged deposit contract' on the execution layer (deployed at 0x00431F263cE400f4455c2dCf564e53007Ca4bbBb), and validators' Withdrawal Credentials call the contract to initiate a request to merge the deposit.
Remarque : Si votre identifiant de retrait est au format de clé publique BLS, vous devez d’abord le basculer au format d’adresse EL.
EIP-7685: Demande de couche d'exécution générale
Établissez un pipeline d’informations EL-> CL formel afin que les utilisateurs et les services de jalonnement puissent envoyer des requêtes directement à la couche de consensus.
Les utilisateurs peuvent envoyer des requêtes directement de la couche d’exécution à la couche de consensus, et les services de jalonnement (tels que Lido) peuvent fonctionner de manière plus décentralisée. Il s’agit par exemple de la demande de retrait de l’EIP-7002 et de la demande de fusion des dépôts de l’EIP-7251. Sans ce protocole technique, les utilisateurs de Lido devraient faire confiance au fournisseur de services de nœud Lido pour exécuter le dépôt de désjalonnement ou de fusion au niveau de la couche de consensus. Grâce à ce protocole technique, les utilisateurs de Lido peuvent envoyer des requêtes directement via le contrat de gouvernance au niveau de la couche d’exécution.
Ces requêtes seront différenciées par le type de requête Request Type, ainsi que par l'initiation de la requête par le biais de contrats différents. Enfin, ces requêtes seront toutes écrites dans des blocs de mémoire de la couche d'exécution, de sorte que la couche de consensus puisse directement obtenir ces informations à travers les blocs de mémoire d'exécution, sans avoir besoin d'écrire une logique d'analyse individuelle.
Les EIP-6110, EIP-7002 et EIP-7251 sont tous des normes définies par l'EIP-7685 pour formuler des demandes :
(0x00000000219ab540356cbb839cbe05303d7705fa) Initiation d’une demande.
(0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA) Initiation d’une demande.
(0x00431F263cE400f4455c2dCf564e53007Ca4bbBb) Initiation d’une demande.
Protocole technologique pour améliorer l'expérience utilisateur
EIP-7702: Définir le code de compte EOA
Permettre aux comptes EOA de se transformer en comptes de contrat de manière arbitraire, améliorant considérablement l'expérience d'utilisation.
Les comptes EOA ont quelques lacunes dans leur utilisation, notamment :
Si c'est un compte de contrat intelligent (par exemple Safe), tous les problèmes susmentionnés peuvent être résolus :
La proposition EIP-7702 consiste à donner à un compte EOA le pouvoir de se transformer en compte de contrat. L'utilisateur signe le message de transformation avec la clé privée EOA, le contenu de la signature comprenant l'«ID de chaîne», «l'adresse du contrat devenant» et «la valeur de hachage de l'EOA» :
Cependant, il y a quelques points à noter :
Même si le compte EOA de l’utilisateur devient un contrat, il peut continuer à l’utiliser de la même manière que le compte EOA d’origine. Par exemple, si votre compte EOA devient un contrat Safe, vous pouvez utiliser l’interface Safe, suivre le processus de transaction Safe ou continuer à signer et à envoyer des transactions avec le portefeuille EOA d’origine. Cependant, cela signifie également que la sécurité du compte est toujours limitée à la clé privée.
Même si le compte EOA de l'utilisateur devient un compte multi-signatures, tant qu'il ne perd pas la clé privée EOA, la sécurité de son compte dépendra toujours de la sécurité de la clé privée EOA : il devra toujours bien protéger sa clé privée ou sa phrase de récupération, et son compte ne sera pas aussi sécurisé qu'un compte multi-signatures pour autant.
Lorsqu'un compte EOA se transforme en contrat et écrit des données dans son stockage, ces données écrites dans le stockage ne seront pas formatées en raison de la transformation du compte EOA en un autre contrat ou de l'annulation de la transformation, à moins que des actions explicites de suppression des données ne soient effectuées. Par conséquent, les développeurs doivent faire attention à ne pas lire les données laissées par les contrats précédemment transformés dans le stockage, comme indiqué dans l'ERC-7201.
En règle générale, un compte de contrat a besoin d’une étape d’initialisation pour écrire de manière synchrone les informations du propriétaire du compte (telles que la clé publique ou l’adresse) lorsque le compte est déployé, afin d’éviter la perte de propriété du compte en raison de l’exécution anticipée de l’étape de déploiement. Cette opération est généralement effectuée par le contrat d’usine qui déploie le compte de contrat pour effectuer « déploiement + initialisation », mais comme EIP-7702 est un changement direct, plutôt qu’une usine qui déploie le contrat sur EOA, l’attaquant peut copier la signature de transformation de l’utilisateur et envoyer de manière préventive la transaction à la chaîne pour qu’elle se transforme pour l’utilisateur, mais initialise le compte pour qu’il soit contrôlable par l’attaquant, de sorte que les développeurs doivent prêter attention à EIP-7702. Une méthode de défense possible consiste à vérifier la signature du compte EOA dans la fonction d’initialisation, de sorte que même si elle est préemptée, l’attaquant ne sera pas en mesure de générer la signature du compte EOA pour terminer l’initialisation.
Le portefeuille doit bien surveiller pour les utilisateurs, intercepter et avertir les utilisateurs lorsque des sites Web DApp malveillants demandent à l'utilisateur de signer une transaction de transformation. Sinon, si l'utilisateur signe une transaction de transformation malveillante, les actifs seront instantanément transférés. Voici quelques exemples d'implémentation de contrats de transformation :
Protocole technique DApp
EIP-2537 : BLS12-381 Précompilateur d’opérations de courbe
Réduire les coûts et rendre plus réalisable l'application de preuve de connaissance nulle basée sur la courbe BLS.
L’EIP-2537 ajoute plusieurs nouveaux contrats de précompilation pour fournir des opérations de courbe BLS peu coûteuses, ce qui rend plus réalisable le développement d’applications de preuve à divulgation nulle de connaissance basées sur des courbes BLS.
EIP-2935 : Enregistrement des hachages de blocs historiques dans l’état
Permettre aux développeurs ou aux nœuds de lire directement la valeur de hachage du bloc précédent à partir du stockage du contrat système.
Si un développeur a besoin de prouver le contenu d’un bloc de mémoire précédent, par exemple, si le défi de fraude Optimismtic Rollup veut prouver qu’une transaction existe dans 1000 blocs de mémoire précédents, le challenger ne peut pas le dis-le directement.
« Croyez-moi, 1000 blocs de mémoire existaient vraiment avant », il a dû témoigner, mais il n’y avait aucune preuve directe pour prouver que « 1000 blocs de mémoire précédents contenaient ce contenu », il a donc dû prouver la transaction dans une « chaîne » de blocs de mémoire, bloc par bloc, jusqu’à ce qu’elle atteigne 1000 blocs précédents, puis prouver que la transaction existait dans le bloc.
!
△ Chaque bloc pointe vers un bloc parent, ce qui permet de prouver n'importe quel bloc de l'histoire tout au long du chemin.
Supposons qu’il s’agisse actuellement d’un bloc de mémoire avec un numéro 10000, et que le défi de fraude veuille fournir la preuve que le bloc de mémoire avec le numéro 9000 a une transaction X, le challenger doit commencer par le hachage du bloc de mémoire 10000, d’abord prouver le hachage du bloc de mémoire parent 9999 connecté au bloc de mémoire 10000, puis prouver le bloc de mémoire 9998... Jusqu’au bloc mémoire 9000, le contenu du bloc mémoire 9000 est proposé pour contenir la transaction X.
Après EIP-2935, il y aura un contrat système (déployé sur 0x0F792be4B0c0cb4DAE440Ef133E90C0eCD48CCCC) qui stockera les hachages d’un maximum de 8192 blocs de mémoire précédents. Chaque fois qu’un nouveau bloc de mémoire est généré, le contrat système sera automatiquement mis à jour pour écrire le hachage du bloc précédent dans le contrat système (le hachage des 8192 blocs de mémoire précédents sera réécrit).
De cette façon, dans l’exemple du défi de fraude Optimismtic Rollup, le challenger n’a pas besoin de revenir au bloc de mémoire précédent pour prouver un bloc de mémoire à la fois, mais peut prouver directement que dans l’état actuel de la chaîne de blocs de mémoire 10000, la valeur d’un certain stockage (correspondant au bloc de mémoire 9000) du contrat système est la valeur de hachage du bloc de mémoire 9000. Si la plage dépasse 8192, comme le bloc de mémoire 1000, il s’agit tout au plus d’une étape supplémentaire pour prouver la valeur de hachage du bloc de mémoire 1808 (= 10000 - 8192), puis prouver la valeur de hachage du bloc de mémoire 1000 dans le contrat système dans l’état actuel de la chaîne du bloc de mémoire 1808.
Cela ouvre également la voie à un futur client sans état : à l’avenir, les nœuds légers n’auront plus besoin de stocker les en-têtes de bloc de tous les blocs de mémoire historiques, mais n’auront besoin que de demander à quelqu’un d’autre de fournir une preuve en utilisant la méthode de preuve dans l’exemple de défi de fraude précédent lorsqu’il est nécessaire d’utiliser le hachage d’un bloc de mémoire dans l’historique ou le contenu du bloc de mémoire.
EIP-7623 : Augmentation du coût des données d’appel
Augmentez le coût de publication des données avec calldata afin de libérer suffisamment d’espace sécurisé pour augmenter la limite de gaz de bloc et la limite d’objets blob.
Avec la demande croissante de publication de données Rollup, l'introduction de Blob dans l'EIP-4844 permet à Rollup de stocker des données de manière très économique. L'augmentation de la quantité de Blob a toujours été un upgrade attendu par la communauté, tout comme l'augmentation récente de la limite de gaz de bloc poussée par la communauté, qui reflète la demande croissante de ressources dans l'écosystème.
!
△ De plus en plus de validateurs ont exprimé leur soutien à l’augmentation de la limite de gaz de bloc.
Cependant, l’augmentation de la limite de gaz de bloc ou du nombre de blobs mettra plus de pression sur le réseau p2p d’Ethereum à mesure que la quantité de données traitées augmentera, ce qui rendra les attaquants plus efficaces, à moins que le coût de publication des données n’augmente.
Après la publication du protocole EIP-7623, le coût des données d’appel sera multiplié par 2,5 par rapport à l’original « Zéro octet : 4 gaz, octet non nul : 16 gaz » à « Zéro octet : 10 gaz, octet non nul : 40 gaz ».
Si un attaquant utilisait tout le Block Gas Limit (30M) pour des données indésirables, la taille des blocs mémoire serait d'environ 1,79 Mo (30M / 16), comparée à une taille moyenne de bloc mémoire d'environ 100 Ko ; et si le Block Gas Limit était augmenté à 40M, l'attaquant pourrait générer des blocs mémoire d'environ 2,38 Mo. L'augmentation du coût de calldata de 2,5 fois entraînerait une diminution de l'efficacité de l'attaquant, se traduisant par une taille maximale de 0,72 Mo pour 30M et 0,95 Mo pour 40M, permettant ainsi d'augmenter plus sereinement le Block Gas Limit et le nombre de Blobs. Cependant, ce protocole technique ne souhaite pas perturber les utilisateurs ordinaires qui n'utilisent pas calldata pour publier des données, il calcule donc le total de Gas des transactions de deux manières et retient le plus élevé :
Les Rollup de petite taille seront les plus touchés, car Blob a une taille fixe et des frais fixes. Par conséquent, les petits Rollup qui utilisent Blob sont moins efficaces, il est plus rentable d'utiliser calldata. Cependant, après l'EIP-7623, les coûts de ces petits Rollup augmenteront de 2,5 fois. Ils pourraient donc être contraints de passer à l'utilisation de Blob ou de trouver un moyen de partager un Blob collectivement.
EIP-7691 : Augmenter le débit d’objets blob
EIP-7691 augmente le nombre de Blob de "objectif: 6 Blob, limite supérieure: 9 Blob" par rapport à "objectif: 3 Blob, limite supérieure: 6 Blob", offrant ainsi plus d'espace pour la publication de données à Rollup.
Remarque : En outre, il existe certaines conceptions sur le marché des frais Blob qui doivent être affinées, telles que la vitesse d’ajustement des frais n’est pas assez instantanée et le plancher des frais est trop bas, mais ce n’est pas le problème que ce protocole technique vise à résoudre.
Autres protocoles technologiques
EIP-7549: Déplacer l'index du comité en dehors de la validation
Ajuster le contenu du vote du validateur pour faciliter l'agrégation des votes et réduire la pression sur le réseau p2p.
Les validateurs seront répartis aléatoirement en comités à chaque époque et
Dans le vote par bloc de mémoire, les votes des validateurs de chaque comité peuvent être agrégés, ce qui réduit le nombre de votes passés dans le réseau P2P, mais les votes du validateur contiendront des informations sur le nombre de comités auxquels le validateur appartient, ce qui signifie que les votes des différents comités ne peuvent pas être agrégés, même s’ils votent tous sur le même bloc de mémoire.
EIP-7549 retire les informations sur "à quel comité appartient le validateur" du contenu du vote, de sorte que les validateurs de différents comités peuvent être regroupés ensemble lorsque le contenu du vote est le même, réduisant ainsi davantage le nombre de votes transmis dans le réseau peer-to-peer et réduisant la pression sur le réseau peer-to-peer.
EIP-7840: Ajouter un plan Blob au fichier de configuration EL
Créez un fichier de configuration pour les paramètres Blob au niveau d'exécution, évitant ainsi aux nœuds de niveau d'exécution de consulter les paramètres Blob associés au niveau de consensus.
Les paramètres associés à Blob sont actuellement stockés dans les nœuds de la couche de consensus, mais les nœuds d'exécution ont parfois besoin de ces paramètres (par exemple, RPC eth_feeHistory), ils doivent donc tous consulter les nœuds de la couche de consensus.
EIP-7840 crée un fichier de configuration pour les paramètres liés à l’objet blob au niveau de la couche d’exécution, et les nœuds de la couche d’exécution peuvent lire directement les paramètres liés à l’objet blob via ce fichier de configuration sans avoir à demander aux nœuds de la couche de consensus.