EIP-2537 : le long chemin de la controverse à l'adoption
EIP-2537 est une instruction précompilée EVM ajoutée lors de la dernière mise à niveau du fork Pectra d'Ethereum. Cette instruction ajoute diverses fonctionnalités de calcul de la courbe BLS12-381 à l'EVM, telles que le calcul de paires sur le domaine de la courbe.
L'EIP-2537 a été proposé pour la première fois 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 finalement adoptée.
Contexte de la proposition
En janvier 2017, Vitalik Buterin a introduit pour la première fois l'algorithme de paire et la courbe alt_bn128 dans un article. Par la suite, Vitalik et Christian Reitwiessner ont proposé l'EIP-196 et l'EIP-197, suggérant d'ajouter le support de calcul de la courbe alt_bn128 à l'EVM.
La mise à niveau de Byzance en octobre 2017 a officiellement introduit la courbe alt_bn128, permettant le calcul de paires de courbes dans le domaine interne de l'EVM, rendant possible la vérification des preuves ZK-Snarks au sein de l'EVM.
Cependant, avec le développement de la cryptographie, l'équipe de développement de zcash a proposé la courbe BLS12-381 en novembre 2017. Par rapport à alt_bn128, BLS12-381 offre une sécurité plus élevée et de meilleures performances. De nombreux protocoles blockchain ont ensuite adopté la courbe BLS12-381, abandonnant alt_bn128.
En mai 2018, Justin Drake a publié un article indiquant que les futures mises à niveau PoS et de fragmentation d'Ethereum pourraient utiliser un algorithme de signature multiple BLS basé sur la courbe BLS12-381. Cette solution résout le problème du nombre limité de validateurs dans les premiers schémas PoS. Il s'est avéré que la mise à niveau ETH2 ultérieure a effectivement adopté la courbe BLS12-381.
Avec l'avancement du développement d'ETH2, la demande d'introduire BLS12-381 dans la couche d'exécution d'ETH devient de plus en plus forte. En février 2020, des chercheurs ont proposé l'EIP-2537, espérant que cette proposition pourrait être testée avec le testnet ETH2. L'auteur de l'EIP-2537, Alex Stokes, a appelé à l'inclusion de cette proposition dans le hard fork de Berlin.
Il convient de noter que l'auteur de l'EIP-2537 est également l'un des co-fondateurs de Matter Labs, la société de développement de ZKSync.
Les rebondissements de la mise à niveau de Berlin
Avant de présenter les développements ultérieurs, nous devons d'abord comprendre l'EIP-1962. Il s'agit de la première proposition de Matter Labs concernant le précompilé de paires de courbes elliptiques, proposée en avril 2019, qui prend en charge trois courbes : BLS12, BN et MNT4/6.
Le plan EIP-1962 propose d'ajouter 10 instructions précompilées en une seule fois pour traiter différentes courbes. Cependant, cette proposition a été remise en question par de nombreux développeurs, qui estiment qu'elle est trop complexe à mettre en œuvre. De plus, en raison de sa grande généralisation, son utilisation est également très compliquée pour les ingénieurs en contrats intelligents. Cependant, en tant que proposant, Matter Labs a déjà terminé le développement de l'algorithme de courbe elliptique et a fourni plusieurs implémentations de référence dans différentes langues.
Pour résoudre le problème de l'EIP-1962, Matter Labs a proposé plusieurs EIP en février 2020 pour diviser l'EIP-1962, ces EIP héritent en partie de l'interface de l'EIP-1962:
EIP-2537 fournit un support BLS12-381
EIP-2539 fournit un support BLS12-377
PR#2541 fournit le support de la courbe BLS12-377(Zexe ), mais cette proposition n'a finalement pas reçu de numéro EIP.
Parmi les plus importants, il y a l'EIP-2537, 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 réaliser la vérification des signatures BLS sur la couche de consensus du réseau principal. À l'époque, ETH2 développait le contrat de dépôt de la couche de consensus. Dans la conception initiale, comme la couche d'exécution ne contenait pas l'algorithme de vérification BLS, le contrat de dépôt ne vérifiait pas les signatures. Les signatures BLS spécifiques seraient vérifiées par la couche de consensus après le dépôt de l'utilisateur. Si une erreur était détectée, le dépôt échouerait, et l'ETH déposé par l'utilisateur pourrait être perdu.
Dans ce contexte, les développeurs principaux souhaitent introduire la précompilation BLS12-381 dans le contrat de dépôt pour réaliser la vérification des signatures, évitant ainsi la perte potentielle de fonds des utilisateurs. C'est également la raison pour laquelle de nombreux développeurs s'intéressaient à l'EIP-1962 et à l'EIP-2537 à l'époque.
Lorsque l'EIP-2537 a été proposé pour la première fois, Vitalik a souligné une série de problèmes liés à la proposition. Ces critiques se sont principalement concentrées sur le contenu du document EIP, et par la suite, l'auteur de l'EIP y a répondu et a discuté.
La 82e réunion des développeurs principaux d'Ethereum, qui a eu lieu le 6 mars 2020, a discuté de l'EIP-2537. Vitalik a estimé que cet EIP est très efficace pour les preuves SNARK récursives et qu'à long terme, il n'aura pas d'impact négatif sur Ethereum. La réunion a confirmé la priorité de l'EIP-2537, tous les clients ont convenu de mettre en œuvre cet EIP dès que possible et prévoient de terminer tous les développements avant la mise à niveau de Berlin.
Ensuite, l'EIP-2537 est devenu une tâche de priorité élevée. La 83e réunion des développeurs principaux, qui a eu lieu le 20 mars, a de nouveau placé cette proposition comme sujet de discussion principal. La réunion a confirmé que l'EIP-2537 remplace l'EIP-1962 en tant que proposition BLS principale et qu'il est inclus dans la liste préliminaire de mise à niveau de Berlin.
La 84ème réunion d'avril a officiellement intégré l'EIP-2537 dans la mise à niveau du hard fork Berlin, et a établi un calendrier de mise en œuvre en avril et de tests en mai-juin. Il est à noter que l'EIP-2537 a été classé comme un sujet de priorité maximale lors de cette discussion.
Par la suite, l'EIP-2537 est entré dans une phase de développement et de tests intensifs, avec des discussions connexes lors de presque chaque réunion des développeurs principaux, qui ont eu lieu près de 20 fois par la suite.
Lors de la 85e réunion, les développeurs ont discuté des problèmes d'encodage ABI de l'EIP-2537. Étant donné que Matter Labs avait déjà essentiellement terminé la mise en œuvre de la version Rust, le client Besu a déclaré avoir presque réalisé les fonctionnalités de l'EIP-2537, mais du côté de Geth, personne ne travaille actuellement sur ce sujet.
Lors de la 86e réunion, différents nœuds ont à nouveau synchronisé les progrès de l'EIP-2537. Geth a indiqué avoir terminé une partie du travail, mais il reste encore de nombreuses tâches à accomplir.
La 87ème réunion a mis l'accent sur les problèmes de mise en œuvre de l'EIP-2537. Les développeurs de Geth ont indiqué qu'il existait une PR de 16000 lignes pour mettre en œuvre l'EIP-2537, mais il n'est pas possible de déterminer si cette PR a été réalisée de manière sécurisée et efficace. On ne peut évaluer l'état du code que par les tests de fuzzing les plus simples.
Les développeurs de Geth ont déclaré : "Selon mon instinct, Geth ne pourra pas être prêt pour l'opération de courbe BLS avant le lancement du mainnet en juillet."
Hudson Jameson a proposé de chercher des ingénieurs en cryptographie pour aider à la révision des PR de Geth, et a suggéré d'utiliser un testnet pour tester la sécurité de l'implémentation de l'EIP-2537. Étant donné que l'équipe de développement ETH2 travaille également sur la validation des signatures BLS, elle peut participer aux tests.
Il convient d'ajouter que la mise en œuvre du PR EIP-2537 de Geth utilise de manière intensive du code assembleur pour garantir l'efficacité, ce qui rend cette partie du code très difficile à lire et à comprendre. Alex Vlasov a proposé de supprimer les optimisations d'assemblage complexes dans le PR afin de réduire la difficulté de révision.
Un des objectifs principaux de l'EIP-2537 est d'assister le contrat de dépôt ETH2, mais lors de cette réunion, les développeurs du contrat de dépôt ont déclaré que le contrat qui n'utilise pas l'EIP-2537 avait été audité, et certains développeurs estiment qu'il vaut mieux ne pas lancer une nouvelle version du contrat utilisant l'EIP-2537.
Enfin, la réunion a décidé d'ajouter un réseau de test YOLO, spécifiquement destiné à tester l'EIP-2537. En réalité, cette réunion montre qu'avec l'achèvement du contrat de dépôt, l'importance de l'EIP-2537 a considérablement diminué, et les développeurs de Geth estiment que cet EIP ne pourra probablement pas être réalisé avant la mise à niveau de Berlin. Il semble désormais acquis que l'EIP-2537 ne sera pas adopté lors de la mise à niveau de Berlin.
Lors de la 88ème réunion, les développeurs de Geth ont découvert qu'il y avait une série de problèmes avec la PR d'implémentation de l'EIP-2537, indiquant qu'il était nécessaire de tester et de corriger davantage. À ce moment-là, il existait deux implémentations de l'EIP-2537 dans le système Geth, l'une comprenant des optimisations en assembleur, l'autre étant entièrement écrite en langage Go. Un développeur a suggéré d'utiliser directement la version en langage Go pour réduire la difficulté de révision du code.
Lors de la 89e réunion, un problème plus grave est survenu, le réseau de test YOLO a présenté des anomalies, les développeurs soupçonnent que cela soit dû à la signature BLS, mais les développeurs de l'EIP-2537 ont contesté cela. La bonne nouvelle est que le contrat de dépôt basé sur l'EIP-2537 est presque terminé et attend actuellement un audit.
La 90e réunion a fixé la date limite pour le lancement de la mise à niveau Berlin en juillet. La réunion a également discuté de la diversité des clients, principalement en rapport avec la situation dominante de Geth, certains développeurs ayant suggéré de geler la mise en œuvre actuelle des EIP pour réduire les coûts de développement des autres clients. Lors de la 91e réunion, des développeurs ont proposé d'utiliser une solution modulaire pour réduire les coûts de développement afin d'augmenter la diversité des clients.
La 92e réunion a confirmé que l'EIP-2537 est nécessaire pour la mise à niveau Berlin.
Lors de la 96e réunion, Celo ayant intégré simultanément l'EIP-2537 et l'EIP-2539 dans son hard fork, Matter Labs espérait également inclure l'EIP-2539 dans les tests de YOLO v2 et dans la mise à niveau de Berlin. Cependant, les développeurs de Geth s'y sont opposés, estimant que l'EIP-2537 n'avait pas encore été complètement testé dans Geth. En fin de compte, la réunion a décidé de ne pas ajouter l'EIP-2696 à la mise à niveau de Berlin, et de laisser cela pour une discussion future.
La 99ème réunion a 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 consommé trop de temps des développeurs principaux, ce qui a entravé le développement d'autres EIP pour la mise à niveau Berlin. Un facteur secondaire est que la Fondation Ethereum a proposé l'EVM384 comme alternative à l'EIP-2537, offrant une solution de calcul de courbes elliptiques plus générale. Cependant, les développeurs principaux ont exprimé des préoccupations concernant les problèmes de sécurité.
Voici le parcours précoce de l'EIP-2537. Nous pouvons voir que l'EIP-2537 était initialement l'un des EIP les plus importants de la mise à niveau Berlin, mais qu'il a finalement été abandonné en raison de problèmes d'implémentation. En avril 2021, Ethereum a complété la mise à niveau Berlin, les EIP clés comme l'EIP-2565 n'étant en réalité pas complexes à mettre en œuvre, la mise à niveau semblait un peu mince, c'est précisément parce que l'EIP-2537, qui était le plus complexe, a été éliminé.
Développement futur
Comme nous le savons tous, chaque mise à niveau d'Ethereum comporte une proposition clé. La mise à niveau de Londres après Berlin a introduit la proposition de frais de transaction la plus importante de l'histoire d'Ethereum, l'EIP-1559. Pour l'ancienne proposition clé EIP-2537, il est difficile d'intégrer des mises à niveau ultérieures.
La mise à niveau de Londres après Berlin est en cours, les développeurs envisagent d'ajouter l'EIP-2537 dans l'issue #369. La 109e réunion des développeurs principaux a synchronisé l'état de développement de l'EIP-2537, et une discussion sur l'utilisation du gaz a été déclenchée en raison de l'utilisation d'autres bibliothèques. Un développeur a proposé de remplacer l'EIP-2537 par l'EVM384. Cependant, lors de la 111e réunion en avril 2021, l'EIP-2537 a été retiré de la mise à niveau de Londres en raison de sa complexité. La principale raison est que la mise en œuvre de la norme EIP-2537 a changé de bibliothèque de dépendance, ce qui pourrait entraîner des variations de tarification du gaz, et différentes implémentations clients nécessitent beaucoup de temps pour réévaluer la consommation de gaz.
En juin 2021, l'issue #343 a officiellement proposé d'inclure l'EIP-2537 dans la mise à niveau de Shanghai. Cependant, après la mise à niveau de Londres, The Merge a occupé une grande partie du temps des développeurs, et les développeurs de la couche d'exécution ont dû écrire une quantité considérable de code pour mettre en œuvre la mise à niveau PoS. En septembre 2022, après l'achèvement de The Merge, les développeurs de la couche d'exécution ont enfin eu l'opportunité de continuer à discuter des objectifs de la mise à niveau de Shanghai.
En novembre 2022, lors de la 150e réunion des développeurs principaux, il a été brièvement discuté de l'opportunité d'inclure l'EIP-2537 dans Shanghai, mais les développeurs ont estimé qu'il fallait le reporter, le cœur de Shanghai étant de soutenir les retraits PoS. Finalement, l'EIP-2537 n'a pas été inclus dans la mise à niveau Shanghai centrée sur les retraits.
Malheureusement, la mise à niveau de Cancun n'a pas encore discuté de l'EIP-2537, car l'accent de Cancun est mis sur le soutien de l'EIP-4844, qui fournit des blobs pour la couche 2 d'Ethereum afin d'utiliser Ethereum comme couche de disponibilité des données.
Ce n'est qu'à la 181e réunion des développeurs principaux en février 2024 que les développeurs ont discuté de l'inclusion de l'EIP-2537 dans la mise à niveau de Pectra. À ce moment-là, les développeurs estimaient que la mise en œuvre de l'EIP-2537 n'était plus un problème, seules certaines questions de tarification de la consommation de gaz devaient être résolues.
Lors de la 202e réunion du 19 décembre 2024, les développeurs de Nethermind ont finalement finalisé le modèle de tarification de l'EIP-2537. Il est à noter qu'à ce moment-là, Matter Labs, l'initiateur initial de l'EIP-2537, s'était essentiellement retiré des discussions. La 203e réunion de janvier 2025 a discuté de la re-tarification du BLS precompile, le développeur de Geth, Jared Wasinger, a proposé d'augmenter le coût en gaz de 20 %, soutenu par les tests de référence de l'équipe Besu.
Résumé
EIP-2537 a traversé un long et tortueux processus depuis sa proposition jusqu'à son adoption finale :
Février 2020 : EIP-2537 proposé officiellement comme une scission de l'EIP-1962
Avril-Octobre 2020 : Plusieurs discussions sur les problèmes de mise en œuvre, finalement abandonné en raison de l'impossibilité de mise en œuvre avec la mise à niveau de Berlin.
Mars-Avril 2021 : Discussion sur le problème des coûts du gaz, abandonné lors de la mise à niveau de Londres en raison de sa complexité.
Novembre 2022 : discussion sur l'inclusion de la mise à niveau Shanghai, sans résultat.
Février 2024 : croire que la réalisation n'est plus un problème, il existe encore des problèmes de coût de gaz, pouvant être intégrés à la mise à niveau de Pectra
Décembre 2024 - Janvier 2025 : discussion sur le modèle de calcul des coûts spécifique, résolution formelle des coûts de gaz
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.
12 J'aime
Récompense
12
6
Partager
Commentaire
0/400
StableGenius
· 08-03 06:12
empiriquement parlant, il leur a fallu 5 ans pour faire ce qui aurait dû être fait en 6 mois. classique théâtre de gouvernance eth
Voir l'originalRépondre0
RugResistant
· 08-01 07:29
a analysé le eip. des drapeaux rouges potentiels dans l'implémentation BLS nécessitent un audit plus approfondi, pour être honnête.
Voir l'originalRépondre0
NFTDreamer
· 08-01 07:29
Merde, Vitalik Buterin voulait déjà faire ça.
Voir l'originalRépondre0
TokenSleuth
· 08-01 07:29
Ah, il faut vraiment attendre cinq ans... C'est assez pénible.
Voir l'originalRépondre0
0xSunnyDay
· 08-01 07:14
Attendre un eip pendant 5 ans, c'est trop difficile.
Voir l'originalRépondre0
LiquidityHunter
· 08-01 07:11
Zut, l'action d'Ethereum est si lente que je m'ennuie d'attendre.
EIP-2537 : Une importante mise à niveau d'Ethereum adoptée après 5 ans de controverses
EIP-2537 : le long chemin de la controverse à l'adoption
EIP-2537 est une instruction précompilée EVM ajoutée lors de la dernière mise à niveau du fork Pectra d'Ethereum. Cette instruction ajoute diverses fonctionnalités de calcul de la courbe BLS12-381 à l'EVM, telles que le calcul de paires sur le domaine de la courbe.
L'EIP-2537 a été proposé pour la première fois 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 finalement adoptée.
Contexte de la proposition
En janvier 2017, Vitalik Buterin a introduit pour la première fois l'algorithme de paire et la courbe alt_bn128 dans un article. Par la suite, Vitalik et Christian Reitwiessner ont proposé l'EIP-196 et l'EIP-197, suggérant d'ajouter le support de calcul de la courbe alt_bn128 à l'EVM.
La mise à niveau de Byzance en octobre 2017 a officiellement introduit la courbe alt_bn128, permettant le calcul de paires de courbes dans le domaine interne de l'EVM, rendant possible la vérification des preuves ZK-Snarks au sein de l'EVM.
Cependant, avec le développement de la cryptographie, l'équipe de développement de zcash a proposé la courbe BLS12-381 en novembre 2017. Par rapport à alt_bn128, BLS12-381 offre une sécurité plus élevée et de meilleures performances. De nombreux protocoles blockchain ont ensuite adopté la courbe BLS12-381, abandonnant alt_bn128.
En mai 2018, Justin Drake a publié un article indiquant que les futures mises à niveau PoS et de fragmentation d'Ethereum pourraient utiliser un algorithme de signature multiple BLS basé sur la courbe BLS12-381. Cette solution résout le problème du nombre limité de validateurs dans les premiers schémas PoS. Il s'est avéré que la mise à niveau ETH2 ultérieure a effectivement adopté la courbe BLS12-381.
Avec l'avancement du développement d'ETH2, la demande d'introduire BLS12-381 dans la couche d'exécution d'ETH devient de plus en plus forte. En février 2020, des chercheurs ont proposé l'EIP-2537, espérant que cette proposition pourrait être testée avec le testnet ETH2. L'auteur de l'EIP-2537, Alex Stokes, a appelé à l'inclusion de cette proposition dans le hard fork de Berlin.
Il convient de noter que l'auteur de l'EIP-2537 est également l'un des co-fondateurs de Matter Labs, la société de développement de ZKSync.
Les rebondissements de la mise à niveau de Berlin
Avant de présenter les développements ultérieurs, nous devons d'abord comprendre l'EIP-1962. Il s'agit de la première proposition de Matter Labs concernant le précompilé de paires de courbes elliptiques, proposée en avril 2019, qui prend en charge trois courbes : BLS12, BN et MNT4/6.
Le plan EIP-1962 propose d'ajouter 10 instructions précompilées en une seule fois pour traiter différentes courbes. Cependant, cette proposition a été remise en question par de nombreux développeurs, qui estiment qu'elle est trop complexe à mettre en œuvre. De plus, en raison de sa grande généralisation, son utilisation est également très compliquée pour les ingénieurs en contrats intelligents. Cependant, en tant que proposant, Matter Labs a déjà terminé le développement de l'algorithme de courbe elliptique et a fourni plusieurs implémentations de référence dans différentes langues.
Pour résoudre le problème de l'EIP-1962, Matter Labs a proposé plusieurs EIP en février 2020 pour diviser l'EIP-1962, ces EIP héritent en partie de l'interface de l'EIP-1962:
Parmi les plus importants, il y a l'EIP-2537, 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 réaliser la vérification des signatures BLS sur la couche de consensus du réseau principal. À l'époque, ETH2 développait le contrat de dépôt de la couche de consensus. Dans la conception initiale, comme la couche d'exécution ne contenait pas l'algorithme de vérification BLS, le contrat de dépôt ne vérifiait pas les signatures. Les signatures BLS spécifiques seraient vérifiées par la couche de consensus après le dépôt de l'utilisateur. Si une erreur était détectée, le dépôt échouerait, et l'ETH déposé par l'utilisateur pourrait être perdu.
Dans ce contexte, les développeurs principaux souhaitent introduire la précompilation BLS12-381 dans le contrat de dépôt pour réaliser la vérification des signatures, évitant ainsi la perte potentielle de fonds des utilisateurs. C'est également la raison pour laquelle de nombreux développeurs s'intéressaient à l'EIP-1962 et à l'EIP-2537 à l'époque.
Lorsque l'EIP-2537 a été proposé pour la première fois, Vitalik a souligné une série de problèmes liés à la proposition. Ces critiques se sont principalement concentrées sur le contenu du document EIP, et par la suite, l'auteur de l'EIP y a répondu et a discuté.
La 82e réunion des développeurs principaux d'Ethereum, qui a eu lieu le 6 mars 2020, a discuté de l'EIP-2537. Vitalik a estimé que cet EIP est très efficace pour les preuves SNARK récursives et qu'à long terme, il n'aura pas d'impact négatif sur Ethereum. La réunion a confirmé la priorité de l'EIP-2537, tous les clients ont convenu de mettre en œuvre cet EIP dès que possible et prévoient de terminer tous les développements avant la mise à niveau de Berlin.
Ensuite, l'EIP-2537 est devenu une tâche de priorité élevée. La 83e réunion des développeurs principaux, qui a eu lieu le 20 mars, a de nouveau placé cette proposition comme sujet de discussion principal. La réunion a confirmé que l'EIP-2537 remplace l'EIP-1962 en tant que proposition BLS principale et qu'il est inclus dans la liste préliminaire de mise à niveau de Berlin.
La 84ème réunion d'avril a officiellement intégré l'EIP-2537 dans la mise à niveau du hard fork Berlin, et a établi un calendrier de mise en œuvre en avril et de tests en mai-juin. Il est à noter que l'EIP-2537 a été classé comme un sujet de priorité maximale lors de cette discussion.
Par la suite, l'EIP-2537 est entré dans une phase de développement et de tests intensifs, avec des discussions connexes lors de presque chaque réunion des développeurs principaux, qui ont eu lieu près de 20 fois par la suite.
Lors de la 85e réunion, les développeurs ont discuté des problèmes d'encodage ABI de l'EIP-2537. Étant donné que Matter Labs avait déjà essentiellement terminé la mise en œuvre de la version Rust, le client Besu a déclaré avoir presque réalisé les fonctionnalités de l'EIP-2537, mais du côté de Geth, personne ne travaille actuellement sur ce sujet.
Lors de la 86e réunion, différents nœuds ont à nouveau synchronisé les progrès de l'EIP-2537. Geth a indiqué avoir terminé une partie du travail, mais il reste encore de nombreuses tâches à accomplir.
La 87ème réunion a mis l'accent sur les problèmes de mise en œuvre de l'EIP-2537. Les développeurs de Geth ont indiqué qu'il existait une PR de 16000 lignes pour mettre en œuvre l'EIP-2537, mais il n'est pas possible de déterminer si cette PR a été réalisée de manière sécurisée et efficace. On ne peut évaluer l'état du code que par les tests de fuzzing les plus simples.
Les développeurs de Geth ont déclaré : "Selon mon instinct, Geth ne pourra pas être prêt pour l'opération de courbe BLS avant le lancement du mainnet en juillet."
Hudson Jameson a proposé de chercher des ingénieurs en cryptographie pour aider à la révision des PR de Geth, et a suggéré d'utiliser un testnet pour tester la sécurité de l'implémentation de l'EIP-2537. Étant donné que l'équipe de développement ETH2 travaille également sur la validation des signatures BLS, elle peut participer aux tests.
Il convient d'ajouter que la mise en œuvre du PR EIP-2537 de Geth utilise de manière intensive du code assembleur pour garantir l'efficacité, ce qui rend cette partie du code très difficile à lire et à comprendre. Alex Vlasov a proposé de supprimer les optimisations d'assemblage complexes dans le PR afin de réduire la difficulté de révision.
Un des objectifs principaux de l'EIP-2537 est d'assister le contrat de dépôt ETH2, mais lors de cette réunion, les développeurs du contrat de dépôt ont déclaré que le contrat qui n'utilise pas l'EIP-2537 avait été audité, et certains développeurs estiment qu'il vaut mieux ne pas lancer une nouvelle version du contrat utilisant l'EIP-2537.
Enfin, la réunion a décidé d'ajouter un réseau de test YOLO, spécifiquement destiné à tester l'EIP-2537. En réalité, cette réunion montre qu'avec l'achèvement du contrat de dépôt, l'importance de l'EIP-2537 a considérablement diminué, et les développeurs de Geth estiment que cet EIP ne pourra probablement pas être réalisé avant la mise à niveau de Berlin. Il semble désormais acquis que l'EIP-2537 ne sera pas adopté lors de la mise à niveau de Berlin.
Lors de la 88ème réunion, les développeurs de Geth ont découvert qu'il y avait une série de problèmes avec la PR d'implémentation de l'EIP-2537, indiquant qu'il était nécessaire de tester et de corriger davantage. À ce moment-là, il existait deux implémentations de l'EIP-2537 dans le système Geth, l'une comprenant des optimisations en assembleur, l'autre étant entièrement écrite en langage Go. Un développeur a suggéré d'utiliser directement la version en langage Go pour réduire la difficulté de révision du code.
Lors de la 89e réunion, un problème plus grave est survenu, le réseau de test YOLO a présenté des anomalies, les développeurs soupçonnent que cela soit dû à la signature BLS, mais les développeurs de l'EIP-2537 ont contesté cela. La bonne nouvelle est que le contrat de dépôt basé sur l'EIP-2537 est presque terminé et attend actuellement un audit.
La 90e réunion a fixé la date limite pour le lancement de la mise à niveau Berlin en juillet. La réunion a également discuté de la diversité des clients, principalement en rapport avec la situation dominante de Geth, certains développeurs ayant suggéré de geler la mise en œuvre actuelle des EIP pour réduire les coûts de développement des autres clients. Lors de la 91e réunion, des développeurs ont proposé d'utiliser une solution modulaire pour réduire les coûts de développement afin d'augmenter la diversité des clients.
La 92e réunion a confirmé que l'EIP-2537 est nécessaire pour la mise à niveau Berlin.
Lors de la 96e réunion, Celo ayant intégré simultanément l'EIP-2537 et l'EIP-2539 dans son hard fork, Matter Labs espérait également inclure l'EIP-2539 dans les tests de YOLO v2 et dans la mise à niveau de Berlin. Cependant, les développeurs de Geth s'y sont opposés, estimant que l'EIP-2537 n'avait pas encore été complètement testé dans Geth. En fin de compte, la réunion a décidé de ne pas ajouter l'EIP-2696 à la mise à niveau de Berlin, et de laisser cela pour une discussion future.
La 99ème réunion a 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 consommé trop de temps des développeurs principaux, ce qui a entravé le développement d'autres EIP pour la mise à niveau Berlin. Un facteur secondaire est que la Fondation Ethereum a proposé l'EVM384 comme alternative à l'EIP-2537, offrant une solution de calcul de courbes elliptiques plus générale. Cependant, les développeurs principaux ont exprimé des préoccupations concernant les problèmes de sécurité.
Voici le parcours précoce de l'EIP-2537. Nous pouvons voir que l'EIP-2537 était initialement l'un des EIP les plus importants de la mise à niveau Berlin, mais qu'il a finalement été abandonné en raison de problèmes d'implémentation. En avril 2021, Ethereum a complété la mise à niveau Berlin, les EIP clés comme l'EIP-2565 n'étant en réalité pas complexes à mettre en œuvre, la mise à niveau semblait un peu mince, c'est précisément parce que l'EIP-2537, qui était le plus complexe, a été éliminé.
Développement futur
Comme nous le savons tous, chaque mise à niveau d'Ethereum comporte une proposition clé. La mise à niveau de Londres après Berlin a introduit la proposition de frais de transaction la plus importante de l'histoire d'Ethereum, l'EIP-1559. Pour l'ancienne proposition clé EIP-2537, il est difficile d'intégrer des mises à niveau ultérieures.
La mise à niveau de Londres après Berlin est en cours, les développeurs envisagent d'ajouter l'EIP-2537 dans l'issue #369. La 109e réunion des développeurs principaux a synchronisé l'état de développement de l'EIP-2537, et une discussion sur l'utilisation du gaz a été déclenchée en raison de l'utilisation d'autres bibliothèques. Un développeur a proposé de remplacer l'EIP-2537 par l'EVM384. Cependant, lors de la 111e réunion en avril 2021, l'EIP-2537 a été retiré de la mise à niveau de Londres en raison de sa complexité. La principale raison est que la mise en œuvre de la norme EIP-2537 a changé de bibliothèque de dépendance, ce qui pourrait entraîner des variations de tarification du gaz, et différentes implémentations clients nécessitent beaucoup de temps pour réévaluer la consommation de gaz.
En juin 2021, l'issue #343 a officiellement proposé d'inclure l'EIP-2537 dans la mise à niveau de Shanghai. Cependant, après la mise à niveau de Londres, The Merge a occupé une grande partie du temps des développeurs, et les développeurs de la couche d'exécution ont dû écrire une quantité considérable de code pour mettre en œuvre la mise à niveau PoS. En septembre 2022, après l'achèvement de The Merge, les développeurs de la couche d'exécution ont enfin eu l'opportunité de continuer à discuter des objectifs de la mise à niveau de Shanghai.
En novembre 2022, lors de la 150e réunion des développeurs principaux, il a été brièvement discuté de l'opportunité d'inclure l'EIP-2537 dans Shanghai, mais les développeurs ont estimé qu'il fallait le reporter, le cœur de Shanghai étant de soutenir les retraits PoS. Finalement, l'EIP-2537 n'a pas été inclus dans la mise à niveau Shanghai centrée sur les retraits.
Malheureusement, la mise à niveau de Cancun n'a pas encore discuté de l'EIP-2537, car l'accent de Cancun est mis sur le soutien de l'EIP-4844, qui fournit des blobs pour la couche 2 d'Ethereum afin d'utiliser Ethereum comme couche de disponibilité des données.
Ce n'est qu'à la 181e réunion des développeurs principaux en février 2024 que les développeurs ont discuté de l'inclusion de l'EIP-2537 dans la mise à niveau de Pectra. À ce moment-là, les développeurs estimaient que la mise en œuvre de l'EIP-2537 n'était plus un problème, seules certaines questions de tarification de la consommation de gaz devaient être résolues.
Lors de la 202e réunion du 19 décembre 2024, les développeurs de Nethermind ont finalement finalisé le modèle de tarification de l'EIP-2537. Il est à noter qu'à ce moment-là, Matter Labs, l'initiateur initial de l'EIP-2537, s'était essentiellement retiré des discussions. La 203e réunion de janvier 2025 a discuté de la re-tarification du BLS precompile, le développeur de Geth, Jared Wasinger, a proposé d'augmenter le coût en gaz de 20 %, soutenu par les tests de référence de l'équipe Besu.
Résumé
EIP-2537 a traversé un long et tortueux processus depuis sa proposition jusqu'à son adoption finale :