La mise à niveau de Pectra est la prochaine étape importante pour le réseau Ethereum, qui devrait être mise en œuvre au premier trimestre de 2025. Cette mise à niveau se compose de deux composants principaux : la mise à niveau Prague (couche d’exécution) et la mise à niveau Electra (couche de protocole).
Contrairement aux mises à niveau majeures précédentes, Pectra n'a pas un objectif principal unique ; au contraire, elle se concentre sur plusieurs améliorations technologiques et optimisations. Cela contraste avec la mise à niveau Dencun (qui a considérablement réduit les frais de L2) et la mise à niveau Shapella (qui a permis le retrait d'ETH mis en jeu, achevant la transition d'Ethereum vers la preuve d'enjeu (PoS)).
Récemment, les développeurs principaux d’Ethereum (ACD, All Core Developers) ont discuté de la possibilité de diviser la mise à niveau de Pectra en deux phases lors d’une conférence téléphonique. D’après cette proposition :
Cette approche progressive vise à maintenir l'échelle et la complexité de chaque mise à niveau gérables tout en permettant un temps suffisant pour des tests approfondis et des améliorations des différentes technologies.
Cette proposition introduit des opérations précompilées sur la courbe BLS12-381, ce qui améliore considérablement l’efficacité des opérations telles que la vérification des signatures BLS. Par rapport aux opérations précompilées BN254 existantes, BLS12-381 offre une sécurité plus élevée (plus de 120 bits, tandis que BN254 ne fournit que 80 bits). Cette amélioration inclut non seulement les opérations de courbe de base, mais intègre également la multi-exponentiation, jetant ainsi les bases d’une agrégation efficace des clés publiques et des signatures.
Cette proposition suggère de stocker les hachages des 8 192 blocs les plus récents dans un contrat système, principalement pour prendre en charge l’exécution des clients sans état. De cette façon, les clients sans état peuvent accéder plus facilement aux informations historiques nécessaires tout en maintenant la compatibilité avec l’opcode BLOCKHASH existant. Cette modification simplifie le mécanisme de stockage de l’historique de hachage des blocs et fournit une nouvelle approche pour accéder aux données historiques.
Cette proposition intègre directement le processus de dépôts des validateurs dans la structure de bloc de la couche d'exécution d'Ethereum. Ce changement déplace la responsabilité d'inclure et de vérifier les dépôts de la couche de consensus vers la couche d'exécution, éliminant ainsi le besoin pour la couche de consensus de voter sur les dépôts (ou eth1data). En générant une liste de dépôts en analysant les événements de journal de contrat des transactions de dépôt, cette méthode améliore non seulement la sécurité et l'efficacité du traitement des dépôts, mais améliore également l'expérience utilisateur. De plus, cela simplifie la conception des logiciels clients et réduit la complexité globale du système.
Cette proposition introduit un nouveau mécanisme qui permet aux validateurs de retirer leurs justificatifs par le biais de la couche d'exécution (0x01) pour déclencher les opérations de retrait et de sortie. Plus précisément, le message de retrait est attaché au bloc de la couche d'exécution, puis traité par la couche de consensus. Cette approche offre aux validateurs plus d'options de sortie flexibles tout en maintenant la sécurité et la cohérence du système.
Cette proposition vise à augmenter le solde maximum efficace (MAX_EFFECTIVE_BALANCE) pour les validateurs Ethereum tout en maintenant le solde minimum de participation à 32 ETH. Cette modification offre plusieurs avantages:
Cette proposition suggère de supprimer le champ d'index du comité des messages de preuve signés afin de permettre l'agrégation des mêmes votes de consensus. L'objectif principal de ce changement est d'améliorer l'efficacité des clients Casper FFG en réduisant le nombre moyen de paires nécessaires pour vérifier les règles de consensus. Bien que tous les types de clients puissent bénéficier de cette amélioration, il devrait fournir la plus grande amélioration des performances pour les circuits ZK qui doivent prouver le consensus Casper FFG.
Cette proposition définit un cadre général pour stocker et traiter les demandes déclenchées par les contrats intelligents. L'implémentation spécifique ajoute un champ à l'en-tête et au corps de l'exécution pour stocker les informations de demande, exposant ainsi ces demandes à la couche de consensus et lui permettant de traiter chaque demande. Ce mécanisme est principalement conçu pour répondre à la demande croissante de contrôle des validateurs par les contrats intelligents et fournir une base pour des interactions plus complexes sur la chaîne à l'avenir.
Proposée par Vitalik Buterin et d'autres, l'EIP-7702 vise à optimiser l'abstraction de compte sur Ethereum. Cette proposition introduit un nouveau type de transaction qui permet aux comptes détenus par des tiers (EOA) de définir le code du compte grâce à un mécanisme d'autorisation. Cette amélioration prend en charge plusieurs nouvelles fonctionnalités :
En adoptant une nouvelle structure de transaction, cette proposition améliore non seulement la fonctionnalité et l'utilité des EOAs, mais elle offre également une bonne compatibilité et évolutivité pour les futures technologies d'abstraction de compte.
Bien que la mise à niveau Pectra n'ait pas un objectif principal marquant, elle améliorera davantage la fonctionnalité, la sécurité et l'efficacité du réseau Ethereum grâce à une série d'améliorations techniques et d'optimisations. Au fur et à mesure de l'avancement des plans de mise à niveau, nous pourrions voir plus d'EIP incorporés ou ajustés.
Références
[1]EIP-2537: https://eips.ethereum.org/EIPS/eip-2537
[2]EIP-2935: https://eips.ethereum.org/EIPS/eip-2935
[3]EIP-6110: https://eips.ethereum.org/EIPS/eip-6110
[4]EIP-7002: https://eips.ethereum.org/EIPS/eip-7002
[5]EIP-7251 : https://eips.ethereum.org/EIPS/eip-7251
[6]EIP-7549: https://eips.ethereum.org/EIPS/eip-7549
[7]EIP-7685: https://eips.ethereum.org/EIPS/eip-7685
[8]EIP-7702 : https://eips.ethereum.org/EIPS/eip-7702
[9]EIP-7547: https://eips.ethereum.org/EIPS/eip-7547
[10]EIP-7623: https://eips.ethereum.org/EIPS/eip-7623
[11]EIP-7742: https://eips.ethereum.org/EIPS/eip-7742
[12]EIP-7600: métadonnées de la fourchette dure Pectra :https://eips.ethereum.org/EIPS/eip-7600
[13]Réunion de la couche de consensus des développeurs principaux d'Ethereum #197 :https://www.galaxy.com/insights/research/ethereum-all-core-developers-execution-call-197/
Cet article est reproduit à partir de[dwong], titre original « Interpreting Ethereum Pectra : The Next Major Upgrade », copyright Attribution à l’auteur original [dwong], si vous avez des objections à la reproduction, veuillez contacter Équipe d'apprentissage de GateL'équipe s'en occupera dès que possible selon les procédures pertinentes.
Avertissement: Les opinions exprimées dans cet article ne représentent que les opinions personnelles de l'auteur et ne constituent aucun conseil en matière d'investissement.
D’autres versions linguistiques de l’article sont traduites par l’équipe de Gate Learn et ne sont pas mentionnées dans Gate.io, l'article traduit ne peut être reproduit, distribué ou plagié.
La mise à niveau de Pectra est la prochaine étape importante pour le réseau Ethereum, qui devrait être mise en œuvre au premier trimestre de 2025. Cette mise à niveau se compose de deux composants principaux : la mise à niveau Prague (couche d’exécution) et la mise à niveau Electra (couche de protocole).
Contrairement aux mises à niveau majeures précédentes, Pectra n'a pas un objectif principal unique ; au contraire, elle se concentre sur plusieurs améliorations technologiques et optimisations. Cela contraste avec la mise à niveau Dencun (qui a considérablement réduit les frais de L2) et la mise à niveau Shapella (qui a permis le retrait d'ETH mis en jeu, achevant la transition d'Ethereum vers la preuve d'enjeu (PoS)).
Récemment, les développeurs principaux d’Ethereum (ACD, All Core Developers) ont discuté de la possibilité de diviser la mise à niveau de Pectra en deux phases lors d’une conférence téléphonique. D’après cette proposition :
Cette approche progressive vise à maintenir l'échelle et la complexité de chaque mise à niveau gérables tout en permettant un temps suffisant pour des tests approfondis et des améliorations des différentes technologies.
Cette proposition introduit des opérations précompilées sur la courbe BLS12-381, ce qui améliore considérablement l’efficacité des opérations telles que la vérification des signatures BLS. Par rapport aux opérations précompilées BN254 existantes, BLS12-381 offre une sécurité plus élevée (plus de 120 bits, tandis que BN254 ne fournit que 80 bits). Cette amélioration inclut non seulement les opérations de courbe de base, mais intègre également la multi-exponentiation, jetant ainsi les bases d’une agrégation efficace des clés publiques et des signatures.
Cette proposition suggère de stocker les hachages des 8 192 blocs les plus récents dans un contrat système, principalement pour prendre en charge l’exécution des clients sans état. De cette façon, les clients sans état peuvent accéder plus facilement aux informations historiques nécessaires tout en maintenant la compatibilité avec l’opcode BLOCKHASH existant. Cette modification simplifie le mécanisme de stockage de l’historique de hachage des blocs et fournit une nouvelle approche pour accéder aux données historiques.
Cette proposition intègre directement le processus de dépôts des validateurs dans la structure de bloc de la couche d'exécution d'Ethereum. Ce changement déplace la responsabilité d'inclure et de vérifier les dépôts de la couche de consensus vers la couche d'exécution, éliminant ainsi le besoin pour la couche de consensus de voter sur les dépôts (ou eth1data). En générant une liste de dépôts en analysant les événements de journal de contrat des transactions de dépôt, cette méthode améliore non seulement la sécurité et l'efficacité du traitement des dépôts, mais améliore également l'expérience utilisateur. De plus, cela simplifie la conception des logiciels clients et réduit la complexité globale du système.
Cette proposition introduit un nouveau mécanisme qui permet aux validateurs de retirer leurs justificatifs par le biais de la couche d'exécution (0x01) pour déclencher les opérations de retrait et de sortie. Plus précisément, le message de retrait est attaché au bloc de la couche d'exécution, puis traité par la couche de consensus. Cette approche offre aux validateurs plus d'options de sortie flexibles tout en maintenant la sécurité et la cohérence du système.
Cette proposition vise à augmenter le solde maximum efficace (MAX_EFFECTIVE_BALANCE) pour les validateurs Ethereum tout en maintenant le solde minimum de participation à 32 ETH. Cette modification offre plusieurs avantages:
Cette proposition suggère de supprimer le champ d'index du comité des messages de preuve signés afin de permettre l'agrégation des mêmes votes de consensus. L'objectif principal de ce changement est d'améliorer l'efficacité des clients Casper FFG en réduisant le nombre moyen de paires nécessaires pour vérifier les règles de consensus. Bien que tous les types de clients puissent bénéficier de cette amélioration, il devrait fournir la plus grande amélioration des performances pour les circuits ZK qui doivent prouver le consensus Casper FFG.
Cette proposition définit un cadre général pour stocker et traiter les demandes déclenchées par les contrats intelligents. L'implémentation spécifique ajoute un champ à l'en-tête et au corps de l'exécution pour stocker les informations de demande, exposant ainsi ces demandes à la couche de consensus et lui permettant de traiter chaque demande. Ce mécanisme est principalement conçu pour répondre à la demande croissante de contrôle des validateurs par les contrats intelligents et fournir une base pour des interactions plus complexes sur la chaîne à l'avenir.
Proposée par Vitalik Buterin et d'autres, l'EIP-7702 vise à optimiser l'abstraction de compte sur Ethereum. Cette proposition introduit un nouveau type de transaction qui permet aux comptes détenus par des tiers (EOA) de définir le code du compte grâce à un mécanisme d'autorisation. Cette amélioration prend en charge plusieurs nouvelles fonctionnalités :
En adoptant une nouvelle structure de transaction, cette proposition améliore non seulement la fonctionnalité et l'utilité des EOAs, mais elle offre également une bonne compatibilité et évolutivité pour les futures technologies d'abstraction de compte.
Bien que la mise à niveau Pectra n'ait pas un objectif principal marquant, elle améliorera davantage la fonctionnalité, la sécurité et l'efficacité du réseau Ethereum grâce à une série d'améliorations techniques et d'optimisations. Au fur et à mesure de l'avancement des plans de mise à niveau, nous pourrions voir plus d'EIP incorporés ou ajustés.
Références
[1]EIP-2537: https://eips.ethereum.org/EIPS/eip-2537
[2]EIP-2935: https://eips.ethereum.org/EIPS/eip-2935
[3]EIP-6110: https://eips.ethereum.org/EIPS/eip-6110
[4]EIP-7002: https://eips.ethereum.org/EIPS/eip-7002
[5]EIP-7251 : https://eips.ethereum.org/EIPS/eip-7251
[6]EIP-7549: https://eips.ethereum.org/EIPS/eip-7549
[7]EIP-7685: https://eips.ethereum.org/EIPS/eip-7685
[8]EIP-7702 : https://eips.ethereum.org/EIPS/eip-7702
[9]EIP-7547: https://eips.ethereum.org/EIPS/eip-7547
[10]EIP-7623: https://eips.ethereum.org/EIPS/eip-7623
[11]EIP-7742: https://eips.ethereum.org/EIPS/eip-7742
[12]EIP-7600: métadonnées de la fourchette dure Pectra :https://eips.ethereum.org/EIPS/eip-7600
[13]Réunion de la couche de consensus des développeurs principaux d'Ethereum #197 :https://www.galaxy.com/insights/research/ethereum-all-core-developers-execution-call-197/
Cet article est reproduit à partir de[dwong], titre original « Interpreting Ethereum Pectra : The Next Major Upgrade », copyright Attribution à l’auteur original [dwong], si vous avez des objections à la reproduction, veuillez contacter Équipe d'apprentissage de GateL'équipe s'en occupera dès que possible selon les procédures pertinentes.
Avertissement: Les opinions exprimées dans cet article ne représentent que les opinions personnelles de l'auteur et ne constituent aucun conseil en matière d'investissement.
D’autres versions linguistiques de l’article sont traduites par l’équipe de Gate Learn et ne sont pas mentionnées dans Gate.io, l'article traduit ne peut être reproduit, distribué ou plagié.