EIP-2537 : Le long chemin du calcul des courbes Ethereum
EIP-2537 est une instruction précompilée EVM récemment ajoutée dans la mise à niveau de fork Pectra. Cette instruction ajoute diverses fonctionnalités de calcul de la courbe BLS12-381 à l'EVM, y compris le calcul de paires sur le domaine de la courbe.
EIP-2573 a été initialement proposé en 2020 et n'a été confirmé pour être inclus dans la mise à niveau d'Ethereum qu'en 2025. Cet article présentera le parcours de gouvernance de l'EIP-2537 et explorera pourquoi cette proposition a mis 5 ans à être intégrée à la mise à niveau.
Contexte de la proposition
En janvier 2017, Vitalik Buterin a présenté pour la première fois l'algorithme de couplage et la courbe alt_bn128. Par la suite, Vitalik et Christian Reitwiessner ont proposé EIP-196 et EIP-197, ajoutant le support du calcul de la courbe alt_bn128 pour l'EVM. La mise à niveau de Byzantium en octobre 2017 a officiellement intégré la courbe alt_bn128, permettant le calcul de couplage dans le domaine de la courbe au sein de l'EVM, rendant ainsi la vérification des preuves ZK-Snarks réalisable dans l'EVM.
En novembre 2017, l'équipe de zcash a proposé la courbe BLS12-381, qui offre une sécurité et des performances supérieures par rapport à alt_bn128. De nombreux protocoles de blockchain ont ensuite adopté la courbe BLS12-381, abandonnant la courbe alt_bn128.
En mai 2018, Justin Drake a souligné que les futures mises à niveau PoS et de sharding d'Ethereum pourraient utiliser l'algorithme de signature multiple BLS basé sur la courbe BLS12-381. Cela a conduit à l'abandon du précédent plan EIP-1011, et la mise à niveau ETH2 ultérieure a également finalement adopté la courbe BLS12-381.
Avec le développement d'ETH2, la demande d'introduire BLS12-381 dans la couche d'exécution d'ETH augmente. En février 2020, certains chercheurs ont proposé l'EIP-2537, espérant le tester sur le réseau de test ETH2. L'auteur de l'EIP-2537, Alex Stokes, a appelé à l'intégrer dans le hard fork Berlin.
Il est intéressant de noter que l'auteur de l'EIP-2537 est également co-fondateur de Matter Labs, dont le produit le plus célèbre est ZKSync.
Berlin turbulences
Avant d'introduire le contenu suivant, il est nécessaire de mentionner l'EIP-1962. Il s'agit de la première proposition de précompilation pour le couplage de domaines de courbes elliptiques, proposée par Matter Labs en avril 2019, qui prend en charge trois courbes : BLS12, BN et MNT4/6. Cet EIP prévoit d'ajouter 10 instructions précompilées en une seule fois pour traiter différentes courbes. Cependant, de nombreux développeurs remettent en question la complexité excessive de la proposition et son inaccessibilité pour les ingénieurs en contrats intelligents. En tant que proposant, Matter Labs a terminé le développement de l'algorithme de courbe elliptique et a fourni des implémentations de référence multilingues.
Pour résoudre le problème EIP-1962, Matter Labs a proposé en février 2020 plusieurs EIP décomposés d'EIP-1962, dont une partie hérite de son interface :
EIP-2537 fournit un support pour BLS12-381
EIP-2539 fournit un support BLS12-377
PR#2541 fournit le support de la courbe BLS12-377(Zexe), mais n'a pas obtenu de numéro EIP
Parmi eux, l'EIP-2537 est le plus important, car la couche de consensus utilise également la courbe BLS12-381. Les objectifs principaux de l'EIP-1962 et de l'EIP-2537 sont de mettre en œuvre la vérification des signatures BLS de la couche de consensus sur le réseau principal. À l'époque, ETH2 développait le contrat de dépôt, mais en raison du manque d'algorithmes de vérification BLS dans la couche d'exécution, le contrat de dépôt dans la conception initiale ne vérifiait pas les signatures, mais était vérifié par la couche de consensus. Si une erreur était détectée, cela pouvait entraîner une perte de fonds pour les utilisateurs.
Dans ce contexte, les développeurs principaux souhaitent introduire le précompilé BLS12-381 pour vérifier les signatures dans le contrat de dépôt, afin d'éviter une éventuelle perte de fonds des utilisateurs. C'est la raison pour laquelle de nombreux développeurs se sont intéressés à l'EIP-1962 et à l'EIP-2537 à l'époque.
Lorsque l'EIP-2537 a été proposé, Vitalik a immédiatement souligné qu'il présentait une série de problèmes, principalement liés au contenu de la documentation de l'EIP. Par la suite, l'auteur a répondu et discuté. Lors de la réunion des développeurs principaux du 6 mars 2020, Vitalik a estimé que l'EIP-2537 et d'autres étaient très efficaces pour les preuves SNARK récursives et que, à long terme, cela ne nuirait pas à Ethereum. La réunion a confirmé la priorité de l'EIP-2537, tous les clients étant d'accord pour le mettre en œuvre rapidement et prévoyant de terminer le développement avant la mise à niveau de Berlin.
Ensuite, l'EIP-2537 est devenu une tâche de haute priorité. La réunion du 20 mars a confirmé que l'EIP-2537 remplace l'EIP-1962 en tant que proposition BLS centrale et entre dans la liste de pré-sélection de la mise à niveau Berlin. La réunion d'avril a officiellement inclus l'EIP-2537 dans la mise à niveau du hard fork Berlin, établissant un calendrier pour sa mise en œuvre en avril et des tests en mai-juin, et l'a classé comme une priorité absolue.
Ensuite, l'EIP-2537 entre dans une phase de développement et de test intensive, où près de 20 réunions de développeurs principaux ont presque toutes impliqué des discussions connexes. Les principaux points incluent :
Discussion sur les problèmes de codage ABI
Synchronisation des progrès de chaque client
La mise en œuvre de Geth PR contient 16000 lignes de code, ce qui rend difficile de déterminer sa sécurité et son efficacité.
Les développeurs ont déclaré que Geth aurait du mal à terminer le développement de l'EIP-2537 avant juillet.
Proposer de chercher des ingénieurs en cryptographie pour aider à l'examen des PR, utiliser le réseau de test pour tester la sécurité.
Discuter de la possibilité de supprimer l'optimisation d'assemblage complexe pour réduire la difficulté de la révision.
Les développeurs de contrats de dépôt ont indiqué que la version ne utilisant pas l'EIP-2537 a été auditée et envisagent de ne plus lancer de version utilisant l'EIP-2537.
Décider d'augmenter le test du réseau YOLO pour tester spécifiquement l'EIP-2537
Il est donc clair que l'importance de l'EIP-2537 a considérablement diminué avec l'achèvement du contrat de dépôt, et les développeurs de Geth estiment qu'il sera difficile de le réaliser avant Berlin. Il semble donc que l'EIP-2537 ne sera pas accepté à Berlin.
Des problèmes supplémentaires sont apparus lors des réunions suivantes :
Geth a découvert un problème dans la mise en œuvre du PR EIP-2537, nécessitant des tests supplémentaires pour la réparation.
Le réseau de test YOLO rencontre des problèmes, soupçonné d'être lié à la signature BLS.
Discuter de la diversité des clients, envisager de geler l'implémentation actuelle de l'EIP pour réduire les coûts de développement des autres clients.
Matter Labs souhaite également inclure l'EIP-2539 dans les tests, mais est opposé par les développeurs de Geth.
Finalement, lors de la 99e réunion des développeurs principaux, il a été décidé de retirer l'EIP-2537 du réseau de test YOLO v3 et de la mise à niveau Berlin. La principale raison est que l'EIP-2537 a pris trop de temps aux développeurs principaux, ce qui a entravé le développement d'autres EIP. Un facteur secondaire est que la fondation Ethereum a proposé l'EVM384 comme solution alternative.
En avril 2021, Ethereum a terminé la mise à niveau Berlin, dont les mises en œuvre des EIP-2565 et autres inclus ne sont pas complexes, la mise à niveau semble un peu mince, car l'EIP-2537, le plus complexe, a été exclu.
Développement futur
La mise à niveau de Londres après Berlin est en cours, les développeurs avaient envisagé d'ajouter EIP-2537, mais en raison du changement de bibliothèque de dépendance qui pourrait entraîner des variations de tarification du gaz, cela a finalement été abandonné à nouveau en raison de la complexité.
En juin 2021, il a été officiellement proposé d'intégrer l'EIP-2537 dans la mise à niveau de Shanghai. Cependant, la mise à niveau Merge a occupé beaucoup de temps des développeurs. Après l'achèvement de Merge en septembre 2022, les développeurs ont enfin eu l'occasion de continuer à discuter des objectifs de Shanghai.
En novembre 2022, les développeurs ont estimé que l'EIP-2537 devait être reporté, la mise à niveau de Shanghai étant principalement axée sur le soutien au retrait de PoS. La mise à niveau de Cancun n'a pas non plus discuté de l'EIP-2537 en raison de son attention sur l'EIP-4844.
Jusqu'en février 2024, les développeurs ont discuté de l'intégration de l'EIP-2537 dans la mise à niveau de Pectra, estimant que sa réalisation n'était plus un problème, mais qu'il restait quelques questions de tarification des gaz. De décembre 2024 à janvier 2025, les développeurs ont discuté d'un modèle de calcul des coûts spécifique, résolvant finalement le problème de coût de l'EIP-2537.
Résumé
EIP-2537 a été proposé en février 2020 et a été finalisé en janvier 2025, durant près de 5 ans. Pendant ce temps, il a été retardé plusieurs fois en raison de la complexité de sa mise en œuvre ou de son incompatibilité avec les thèmes de mise à niveau. Cela indique que la capacité d'un EIP à être inclus dans une mise à niveau d'Ethereum dépend non seulement de sa valeur intrinsèque, mais aussi des facteurs historiques. Chaque mise à niveau d'Ethereum a son propre thème, et bien que l'EIP-2537 ait été l'EIP le plus important de la mise à niveau Berlin, il a été abandonné en raison de sa difficulté. Par la suite, Ethereum est entré dans un processus historique de PoS, et les EIP de niveau d'exécution pur n'ont pas été pris en compte, ce qui a conduit à l'acceptation prolongée de l'EIP-2537.
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
17 J'aime
Récompense
17
7
Reposter
Partager
Commentaire
0/400
BakedCatFanboy
· Il y a 21h
Après huit ans, ça y est!
Voir l'originalRépondre0
rugpull_ptsd
· 08-06 22:13
Cinq ans pour être mis en chaîne, ça en prend du temps.
Voir l'originalRépondre0
MetaverseHermit
· 08-06 08:26
Cinq ans pour terminer une mise à niveau, c'est vraiment pénible.
Voir l'originalRépondre0
CoconutWaterBoy
· 08-06 08:25
Cinq ans pour une mise à niveau, c'est vraiment stable.
Voir l'originalRépondre0
SignatureVerifier
· 08-06 08:24
techniquement, cette implémentation bls a besoin d'un sérieux pentesting, nous avons déjà vu ces précompilations à moitié cuites auparavant...
Voir l'originalRépondre0
MEVHunterX
· 08-06 08:14
Cette proposition traîne vraiment en longueur.
Voir l'originalRépondre0
TrustMeBro
· 08-06 08:14
5 ans... On dirait que c'est vraiment pas facile de faire une mise à niveau.
EIP-2537 le long chemin : du refus de la mise à niveau Berlin à l'adoption finale de Pectra
EIP-2537 : Le long chemin du calcul des courbes Ethereum
EIP-2537 est une instruction précompilée EVM récemment ajoutée dans la mise à niveau de fork Pectra. Cette instruction ajoute diverses fonctionnalités de calcul de la courbe BLS12-381 à l'EVM, y compris le calcul de paires sur le domaine de la courbe.
EIP-2573 a été initialement proposé en 2020 et n'a été confirmé pour être inclus dans la mise à niveau d'Ethereum qu'en 2025. Cet article présentera le parcours de gouvernance de l'EIP-2537 et explorera pourquoi cette proposition a mis 5 ans à être intégrée à la mise à niveau.
Contexte de la proposition
En janvier 2017, Vitalik Buterin a présenté pour la première fois l'algorithme de couplage et la courbe alt_bn128. Par la suite, Vitalik et Christian Reitwiessner ont proposé EIP-196 et EIP-197, ajoutant le support du calcul de la courbe alt_bn128 pour l'EVM. La mise à niveau de Byzantium en octobre 2017 a officiellement intégré la courbe alt_bn128, permettant le calcul de couplage dans le domaine de la courbe au sein de l'EVM, rendant ainsi la vérification des preuves ZK-Snarks réalisable dans l'EVM.
En novembre 2017, l'équipe de zcash a proposé la courbe BLS12-381, qui offre une sécurité et des performances supérieures par rapport à alt_bn128. De nombreux protocoles de blockchain ont ensuite adopté la courbe BLS12-381, abandonnant la courbe alt_bn128.
En mai 2018, Justin Drake a souligné que les futures mises à niveau PoS et de sharding d'Ethereum pourraient utiliser l'algorithme de signature multiple BLS basé sur la courbe BLS12-381. Cela a conduit à l'abandon du précédent plan EIP-1011, et la mise à niveau ETH2 ultérieure a également finalement adopté la courbe BLS12-381.
Avec le développement d'ETH2, la demande d'introduire BLS12-381 dans la couche d'exécution d'ETH augmente. En février 2020, certains chercheurs ont proposé l'EIP-2537, espérant le tester sur le réseau de test ETH2. L'auteur de l'EIP-2537, Alex Stokes, a appelé à l'intégrer dans le hard fork Berlin.
Il est intéressant de noter que l'auteur de l'EIP-2537 est également co-fondateur de Matter Labs, dont le produit le plus célèbre est ZKSync.
Berlin turbulences
Avant d'introduire le contenu suivant, il est nécessaire de mentionner l'EIP-1962. Il s'agit de la première proposition de précompilation pour le couplage de domaines de courbes elliptiques, proposée par Matter Labs en avril 2019, qui prend en charge trois courbes : BLS12, BN et MNT4/6. Cet EIP prévoit d'ajouter 10 instructions précompilées en une seule fois pour traiter différentes courbes. Cependant, de nombreux développeurs remettent en question la complexité excessive de la proposition et son inaccessibilité pour les ingénieurs en contrats intelligents. En tant que proposant, Matter Labs a terminé le développement de l'algorithme de courbe elliptique et a fourni des implémentations de référence multilingues.
Pour résoudre le problème EIP-1962, Matter Labs a proposé en février 2020 plusieurs EIP décomposés d'EIP-1962, dont une partie hérite de son interface :
Parmi eux, l'EIP-2537 est le plus important, car la couche de consensus utilise également la courbe BLS12-381. Les objectifs principaux de l'EIP-1962 et de l'EIP-2537 sont de mettre en œuvre la vérification des signatures BLS de la couche de consensus sur le réseau principal. À l'époque, ETH2 développait le contrat de dépôt, mais en raison du manque d'algorithmes de vérification BLS dans la couche d'exécution, le contrat de dépôt dans la conception initiale ne vérifiait pas les signatures, mais était vérifié par la couche de consensus. Si une erreur était détectée, cela pouvait entraîner une perte de fonds pour les utilisateurs.
Dans ce contexte, les développeurs principaux souhaitent introduire le précompilé BLS12-381 pour vérifier les signatures dans le contrat de dépôt, afin d'éviter une éventuelle perte de fonds des utilisateurs. C'est la raison pour laquelle de nombreux développeurs se sont intéressés à l'EIP-1962 et à l'EIP-2537 à l'époque.
Lorsque l'EIP-2537 a été proposé, Vitalik a immédiatement souligné qu'il présentait une série de problèmes, principalement liés au contenu de la documentation de l'EIP. Par la suite, l'auteur a répondu et discuté. Lors de la réunion des développeurs principaux du 6 mars 2020, Vitalik a estimé que l'EIP-2537 et d'autres étaient très efficaces pour les preuves SNARK récursives et que, à long terme, cela ne nuirait pas à Ethereum. La réunion a confirmé la priorité de l'EIP-2537, tous les clients étant d'accord pour le mettre en œuvre rapidement et prévoyant de terminer le développement avant la mise à niveau de Berlin.
Ensuite, l'EIP-2537 est devenu une tâche de haute priorité. La réunion du 20 mars a confirmé que l'EIP-2537 remplace l'EIP-1962 en tant que proposition BLS centrale et entre dans la liste de pré-sélection de la mise à niveau Berlin. La réunion d'avril a officiellement inclus l'EIP-2537 dans la mise à niveau du hard fork Berlin, établissant un calendrier pour sa mise en œuvre en avril et des tests en mai-juin, et l'a classé comme une priorité absolue.
Ensuite, l'EIP-2537 entre dans une phase de développement et de test intensive, où près de 20 réunions de développeurs principaux ont presque toutes impliqué des discussions connexes. Les principaux points incluent :
Il est donc clair que l'importance de l'EIP-2537 a considérablement diminué avec l'achèvement du contrat de dépôt, et les développeurs de Geth estiment qu'il sera difficile de le réaliser avant Berlin. Il semble donc que l'EIP-2537 ne sera pas accepté à Berlin.
Des problèmes supplémentaires sont apparus lors des réunions suivantes :
Finalement, lors de la 99e réunion des développeurs principaux, il a été décidé de retirer l'EIP-2537 du réseau de test YOLO v3 et de la mise à niveau Berlin. La principale raison est que l'EIP-2537 a pris trop de temps aux développeurs principaux, ce qui a entravé le développement d'autres EIP. Un facteur secondaire est que la fondation Ethereum a proposé l'EVM384 comme solution alternative.
En avril 2021, Ethereum a terminé la mise à niveau Berlin, dont les mises en œuvre des EIP-2565 et autres inclus ne sont pas complexes, la mise à niveau semble un peu mince, car l'EIP-2537, le plus complexe, a été exclu.
Développement futur
La mise à niveau de Londres après Berlin est en cours, les développeurs avaient envisagé d'ajouter EIP-2537, mais en raison du changement de bibliothèque de dépendance qui pourrait entraîner des variations de tarification du gaz, cela a finalement été abandonné à nouveau en raison de la complexité.
En juin 2021, il a été officiellement proposé d'intégrer l'EIP-2537 dans la mise à niveau de Shanghai. Cependant, la mise à niveau Merge a occupé beaucoup de temps des développeurs. Après l'achèvement de Merge en septembre 2022, les développeurs ont enfin eu l'occasion de continuer à discuter des objectifs de Shanghai.
En novembre 2022, les développeurs ont estimé que l'EIP-2537 devait être reporté, la mise à niveau de Shanghai étant principalement axée sur le soutien au retrait de PoS. La mise à niveau de Cancun n'a pas non plus discuté de l'EIP-2537 en raison de son attention sur l'EIP-4844.
Jusqu'en février 2024, les développeurs ont discuté de l'intégration de l'EIP-2537 dans la mise à niveau de Pectra, estimant que sa réalisation n'était plus un problème, mais qu'il restait quelques questions de tarification des gaz. De décembre 2024 à janvier 2025, les développeurs ont discuté d'un modèle de calcul des coûts spécifique, résolvant finalement le problème de coût de l'EIP-2537.
Résumé
EIP-2537 a été proposé en février 2020 et a été finalisé en janvier 2025, durant près de 5 ans. Pendant ce temps, il a été retardé plusieurs fois en raison de la complexité de sa mise en œuvre ou de son incompatibilité avec les thèmes de mise à niveau. Cela indique que la capacité d'un EIP à être inclus dans une mise à niveau d'Ethereum dépend non seulement de sa valeur intrinsèque, mais aussi des facteurs historiques. Chaque mise à niveau d'Ethereum a son propre thème, et bien que l'EIP-2537 ait été l'EIP le plus important de la mise à niveau Berlin, il a été abandonné en raison de sa difficulté. Par la suite, Ethereum est entré dans un processus historique de PoS, et les EIP de niveau d'exécution pur n'ont pas été pris en compte, ce qui a conduit à l'acceptation prolongée de l'EIP-2537.