EIP-2537: Le long chemin des instructions précompilées BLS12-381 d'Ethereum
EIP-2537 est une instruction précompilée EVM confirmée pour être ajoutée dans la dernière mise à niveau de bifurcation de 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é 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 intégrée dans 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é l'EIP-196 et l'EIP-197, ajoutant le support du calcul de la courbe alt_bn128 à l'EVM. Ces propositions ont été officiellement adoptées lors de la mise à niveau de Byzantium en octobre 2017, permettant le calcul de couplage dans le domaine de la courbe au sein de l'EVM, ce qui permet à la vérification des preuves ZK-Snarks d'être effectuée à l'intérieur de l'EVM.
Avec le développement de la cryptographie, l'équipe 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 de blockchain ont commencé à utiliser la courbe BLS12-381 en remplacement de 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 plan original EIP-1011. Il s'est avéré que la mise à niveau ETH2 ultérieure a effectivement adopté la courbe BLS12-381.
Avec le développement d'ETH2, les appels à l'introduction de BLS12-381 dans la couche d'exécution d'ETH sont de plus en plus forts. En février 2020, des chercheurs ont proposé l'EIP-2537, espérant que cette proposition puisse être testée avec le testnet ETH2. L'auteur de l'EIP-2537, Alex Stokes, a appelé à l'inclusion de l'EIP-2537 dans le hard fork de Berlin.
Il convient de noter que l'auteur de l'EIP-2537 est également le cofondateur de Matter Labs, le développeur de ZKSync.
Les rebondissements de la mise à niveau de Berlin
Avant d'introduire le contenu suivant, nous devons d'abord comprendre l'EIP-1962. C'est la première proposition concernant le précompilé de paires de courbes elliptiques, proposée par Matter Labs en avril 2019, qui prend en charge trois courbes : BLS12, BN et MNT4/6.
Le plan EIP-1962 vise à ajouter en une seule fois 10 instructions précompilées pour traiter différentes courbes. Cependant, cette proposition est trop complexe, ce qui rend son implémentation difficile pour les développeurs. De plus, en raison de sa grande généralisation, il est également compliqué pour les ingénieurs en contrats intelligents de l'appeler. Cependant, Matter Labs a déjà terminé le développement de l'algorithme de courbe elliptique et propose 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é en février 2020 plusieurs EIP qui décomposent l'EIP-1962, dont certaines héritent de son interface. Ces EIP incluent :
EIP-2537 : Fournir un support BLS12-381
EIP-2539 : Fournir un support BLS12-377
PR#2541: Fournir le support de la courbe BLS12-377 (Zexe), mais n'a pas reçu 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 des EIP-1962 et EIP-2537 sont d'implémenter la vérification des signatures BLS sur la couche de consensus dans le réseau principal. À l'époque, ETH2 concevait un contrat de dépôt, et comme la couche d'exécution n'avait pas d'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 des erreurs étaient détectées, cela pourrait entraîner une perte de fonds pour l'utilisateur.
Dans ce contexte, les développeurs principaux souhaitent introduire la précompilation BLS12-381 pour réaliser la vérification des signatures dans le contrat de dépôt, afin d'éviter une perte potentielle des fonds ETH2 des utilisateurs. C'est la raison pour laquelle de nombreux développeurs s'intéressaient à l'EIP-1962 et à l'EIP-2537 à l'époque.
Après la proposition de l'EIP-2537, Vitalik a immédiatement souligné une série de problèmes, principalement axés sur le contenu de la documentation de l'EIP. Les auteurs de l'EIP ont ensuite 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 EIP sont très efficaces pour les preuves SNARK récursives et qu'à long terme, cela ne nuira pas à Ethereum. La réunion a confirmé le statut prioritaire de l'EIP-2537, tous les clients s'accordant à le mettre en œuvre dès que possible et prévoyant de terminer le développement avant la mise à niveau de Berlin.
Par la suite, 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 préliminaire de mise à niveau de Berlin. La réunion d'avril a officiellement intégré l'EIP-2537 dans la mise à niveau du hard fork Berlin, établissant un calendrier de mise en œuvre en avril et de tests en mai-juin, et l'a classé comme une priorité maximale.
Ensuite, l'EIP-2537 est entré dans une phase importante de développement et de test, et a été discuté lors des près de 20 réunions de développeurs principaux qui ont suivi.
Lors de la 85ème réunion, les développeurs ont discuté du problème de l'encodage ABI de l'EIP-2537. Le client Besu a déclaré avoir fondamentalement mis en œuvre la fonctionnalité, mais du côté de Geth, personne n'a encore entrepris de travaux connexes.
Lors de la 86ème réunion, Geth a indiqué avoir terminé une partie du travail, mais qu'il restait encore beaucoup de travail à faire.
La 87e réunion a principalement discuté des 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 la mise en œuvre de l'EIP-2537, mais qu'ils ne pouvaient pas déterminer sa sécurité et son efficacité, ne pouvant juger que par des tests de flou simples. Les développeurs de Geth estiment qu'il sera impossible de terminer le développement de l'EIP-2537 avant le délai prévu à Berlin.
La réunion a décidé d'augmenter les tests de la testnet YOLO spécifiquement pour tester l'EIP-2537. À ce stade, l'importance de l'EIP-2537 a considérablement diminué, les développeurs de Geth pensent que cet EIP risque fort de ne pas être inclus dans la mise à niveau Berlin.
Lors de la 88ème réunion, les développeurs de Geth ont découvert que la mise en œuvre de l'EIP-2537 dans le PR présentait une série de problèmes qui nécessitaient des tests et des corrections supplémentaires. Il existe deux mises en œuvre de l'EIP-2537 dans le système Geth, l'une contenant une optimisation en assembleur, l'autre entièrement écrite en Go. Certaines personnes ont suggéré d'utiliser directement la version Go pour réduire la difficulté de l'examen 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, soupçonnant que cela soit causé par la signature BLS, mais les développeurs de l'EIP-2537 ont nié cela. La bonne nouvelle est que le contrat de dépôt basé sur l'EIP-2537 est essentiellement terminé et attend maintenant un audit.
La 90ème réunion a fixé la date de lancement de la mise à niveau Berlin en juillet. La réunion a également discuté de la domination de Geth, avec une proposition de geler la mise en œuvre actuelle de l'EIP afin de réduire les coûts de développement des autres clients.
La 92ème réunion confirme toujours que l'EIP-2537 est l'EIP nécessaire pour la mise à niveau Berlin.
Lors de la 96e réunion, Matter Labs espérait 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. La décision finale a été de ne pas ajouter 2696 dans la mise à niveau de Berlin.
La 99ème réunion a décidé de retirer l'EIP-2537 du testnet YOLO v3 et de la mise à niveau Berlin, principalement parce qu'il a consommé trop de temps des développeurs principaux, impactant le développement d'autres EIP. Un facteur secondaire est que la fondation Ethereum a proposé l'EVM384 comme solution de remplacement.
En avril 2021, Ethereum a achevé la mise à niveau Berlin, dont la mise en œuvre réelle des EIP-2565 et autres éléments principaux n'est pas complexe, rendant la mise à niveau plutôt maigre. Cela est dû au fait que l'EIP-2537, qui est le plus complexe, a été éliminé.
Développement futur
La mise à niveau de Berlin de l'upgrade de London a introduit EIP-1559. Pour EIP-2537, qui était autrefois une proposition clé, il est difficile d'inclure cela dans les futures mises à niveau.
La mise à niveau de Londres est en cours, les développeurs ont envisagé d'ajouter l'EIP-2537. La 109e réunion a synchronisé l'état de développement de l'EIP-2537 et a discuté des problèmes d'utilisation du gas, certains ont proposé de remplacer l'EIP-2537 par l'EVM384. Cependant, lors de la 111e réunion, l'EIP-2537 a été retiré de la mise à niveau de Londres en raison de sa complexité. En effet, la mise en œuvre de la norme EIP-2537 a changé la bibliothèque de dépendance, ce qui pourrait entraîner des variations dans le prix du gas, et chaque client doit réévaluer la consommation de gas.
En juin 2021, il a été officiellement proposé d'inclure EIP-2537 dans la mise à niveau de Shanghai. Mais la mise à niveau Merge a occupé beaucoup de temps des développeurs. Ce n'est qu'après l'achèvement de Merge en septembre 2022 que les développeurs de la couche d'exécution ont eu l'occasion de poursuivre la discussion sur les objectifs de la mise à niveau de Shanghai.
En novembre 2022, la 150ème réunion a brièvement discuté de l'opportunité d'inclure l'EIP-2537 dans la mise à niveau de Shanghai, mais a jugé qu'il fallait reporter cette décision. Le cœur de la mise à niveau de Shanghai est de soutenir les retraits PoS. Finalement, l'EIP-2537 n'a pas été inclus dans la mise à niveau de Shanghai, qui est centrée sur la fonctionnalité de retrait.
Cancun n'a jamais discuté de l'EIP-2537, car son cœur est de soutenir l'EIP-4844, fournissant une couche de disponibilité des données Blob pour la couche 2.
En février 2024, lors de la 181e réunion, il a été discuté de l'intégration de l'EIP-2537 dans la mise à niveau de Pectra, considérant que sa réalisation n'est plus un problème, seul le prix de la consommation de gas pose problème.
Le 19 décembre 2024, lors de la 202ème réunion, les développeurs de Nethermind ont déterminé le modèle de tarification de l'EIP-2537. Le proposeur initial, Matter Labs, était presque retiré de la discussion à ce moment-là. La 203ème réunion de janvier 2025 a discuté de la re-tarification de la précompilation BLS, les développeurs de Geth suggérant d'augmenter le coût en gaz de 20%, soutenu par les tests de référence de l'équipe Besu.
Résumé
L'évolution de l'EIP-2537 peut être résumée comme suit :
Février 2020 : Proposition officielle de l'EIP-1962 et séparation de l'EIP-2537
Avril-Octobre 2020 : Plusieurs discussions sur les problèmes de mise en œuvre, finalement abandonné en raison de l'impossibilité de mise en œuvre lors de la mise à niveau de Berlin.
Mars-Avril 2021 : Discussion sur le problème des coûts de gas, abandonné lors de la mise à niveau de Londres en raison de sa complexité.
Novembre 2022 : discussion sur l'intégration de la mise à niveau Shanghai, sans résultat.
Février 2024 : considère que la réalisation ne pose pas de problème, mais qu'il subsiste un problème de coût du gaz, pouvant être inclus dans la mise à niveau de Pectra.
Décembre 2024 - Janvier 2025 : Discussion sur le modèle de coûts spécifique, résolution formelle du problème des coûts.
L'intégration des EIP dans les mises à jour d'Ethereum dépend non seulement des efforts internes, mais aussi du processus historique. Chaque mise à jour a un thème, l'EIP-2537 a été au cœur de la mise à jour Berlin, mais a été abandonné en raison de sa complexité. Par la suite, Ethereum s'est concentré sur le PoS, et les EIP purement d'exécution n'ont pas été pris en compte, ce qui a conduit à un long refus de l'EIP-2537. Ce n'est que récemment que les développeurs ont de nouveau porté attention et résolu les problèmes laissés en suspens.
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.
19 J'aime
Récompense
19
5
Reposter
Partager
Commentaire
0/400
UncleLiquidation
· Il y a 22h
Cinq ans pour démarrer, le rythme de développement d'Ethereum est vraiment lent.
Voir l'originalRépondre0
Anon32942
· Il y a 22h
J'ai attendu cinq ans pour jouer, récemment j'ai fait un petit écart de prix.
Voir l'originalRépondre0
GasWrangler
· Il y a 22h
il leur a en fait fallu 5 ans pour optimiser quelque chose d'aussi trivial mathématiquement... smh face à l'inefficacité de layer1
Voir l'originalRépondre0
SchrodingerProfit
· Il y a 22h
Cinq ans ? C'est trop lent, n'est-ce pas ? Le cœur de V叔 est en souffrance.
Voir l'originalRépondre0
SelfStaking
· Il y a 22h
Pourquoi cette mise à jour prend-elle autant de temps ?
La directive de précompilation BLS d'Ethereum EIP-2537 a été adoptée après 5 ans.
EIP-2537: Le long chemin des instructions précompilées BLS12-381 d'Ethereum
EIP-2537 est une instruction précompilée EVM confirmée pour être ajoutée dans la dernière mise à niveau de bifurcation de 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é 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 intégrée dans 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é l'EIP-196 et l'EIP-197, ajoutant le support du calcul de la courbe alt_bn128 à l'EVM. Ces propositions ont été officiellement adoptées lors de la mise à niveau de Byzantium en octobre 2017, permettant le calcul de couplage dans le domaine de la courbe au sein de l'EVM, ce qui permet à la vérification des preuves ZK-Snarks d'être effectuée à l'intérieur de l'EVM.
Avec le développement de la cryptographie, l'équipe 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 de blockchain ont commencé à utiliser la courbe BLS12-381 en remplacement de 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 plan original EIP-1011. Il s'est avéré que la mise à niveau ETH2 ultérieure a effectivement adopté la courbe BLS12-381.
Avec le développement d'ETH2, les appels à l'introduction de BLS12-381 dans la couche d'exécution d'ETH sont de plus en plus forts. En février 2020, des chercheurs ont proposé l'EIP-2537, espérant que cette proposition puisse être testée avec le testnet ETH2. L'auteur de l'EIP-2537, Alex Stokes, a appelé à l'inclusion de l'EIP-2537 dans le hard fork de Berlin.
Il convient de noter que l'auteur de l'EIP-2537 est également le cofondateur de Matter Labs, le développeur de ZKSync.
Les rebondissements de la mise à niveau de Berlin
Avant d'introduire le contenu suivant, nous devons d'abord comprendre l'EIP-1962. C'est la première proposition concernant le précompilé de paires de courbes elliptiques, proposée par Matter Labs en avril 2019, qui prend en charge trois courbes : BLS12, BN et MNT4/6.
Le plan EIP-1962 vise à ajouter en une seule fois 10 instructions précompilées pour traiter différentes courbes. Cependant, cette proposition est trop complexe, ce qui rend son implémentation difficile pour les développeurs. De plus, en raison de sa grande généralisation, il est également compliqué pour les ingénieurs en contrats intelligents de l'appeler. Cependant, Matter Labs a déjà terminé le développement de l'algorithme de courbe elliptique et propose 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é en février 2020 plusieurs EIP qui décomposent l'EIP-1962, dont certaines héritent de son interface. Ces EIP incluent :
Parmi eux, l'EIP-2537 est le plus important, car la couche de consensus utilise également la courbe BLS12-381. Les objectifs principaux des EIP-1962 et EIP-2537 sont d'implémenter la vérification des signatures BLS sur la couche de consensus dans le réseau principal. À l'époque, ETH2 concevait un contrat de dépôt, et comme la couche d'exécution n'avait pas d'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 des erreurs étaient détectées, cela pourrait entraîner une perte de fonds pour l'utilisateur.
Dans ce contexte, les développeurs principaux souhaitent introduire la précompilation BLS12-381 pour réaliser la vérification des signatures dans le contrat de dépôt, afin d'éviter une perte potentielle des fonds ETH2 des utilisateurs. C'est la raison pour laquelle de nombreux développeurs s'intéressaient à l'EIP-1962 et à l'EIP-2537 à l'époque.
Après la proposition de l'EIP-2537, Vitalik a immédiatement souligné une série de problèmes, principalement axés sur le contenu de la documentation de l'EIP. Les auteurs de l'EIP ont ensuite 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 EIP sont très efficaces pour les preuves SNARK récursives et qu'à long terme, cela ne nuira pas à Ethereum. La réunion a confirmé le statut prioritaire de l'EIP-2537, tous les clients s'accordant à le mettre en œuvre dès que possible et prévoyant de terminer le développement avant la mise à niveau de Berlin.
Par la suite, 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 préliminaire de mise à niveau de Berlin. La réunion d'avril a officiellement intégré l'EIP-2537 dans la mise à niveau du hard fork Berlin, établissant un calendrier de mise en œuvre en avril et de tests en mai-juin, et l'a classé comme une priorité maximale.
Ensuite, l'EIP-2537 est entré dans une phase importante de développement et de test, et a été discuté lors des près de 20 réunions de développeurs principaux qui ont suivi.
Lors de la 85ème réunion, les développeurs ont discuté du problème de l'encodage ABI de l'EIP-2537. Le client Besu a déclaré avoir fondamentalement mis en œuvre la fonctionnalité, mais du côté de Geth, personne n'a encore entrepris de travaux connexes.
Lors de la 86ème réunion, Geth a indiqué avoir terminé une partie du travail, mais qu'il restait encore beaucoup de travail à faire.
La 87e réunion a principalement discuté des 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 la mise en œuvre de l'EIP-2537, mais qu'ils ne pouvaient pas déterminer sa sécurité et son efficacité, ne pouvant juger que par des tests de flou simples. Les développeurs de Geth estiment qu'il sera impossible de terminer le développement de l'EIP-2537 avant le délai prévu à Berlin.
La réunion a décidé d'augmenter les tests de la testnet YOLO spécifiquement pour tester l'EIP-2537. À ce stade, l'importance de l'EIP-2537 a considérablement diminué, les développeurs de Geth pensent que cet EIP risque fort de ne pas être inclus dans la mise à niveau Berlin.
Lors de la 88ème réunion, les développeurs de Geth ont découvert que la mise en œuvre de l'EIP-2537 dans le PR présentait une série de problèmes qui nécessitaient des tests et des corrections supplémentaires. Il existe deux mises en œuvre de l'EIP-2537 dans le système Geth, l'une contenant une optimisation en assembleur, l'autre entièrement écrite en Go. Certaines personnes ont suggéré d'utiliser directement la version Go pour réduire la difficulté de l'examen 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, soupçonnant que cela soit causé par la signature BLS, mais les développeurs de l'EIP-2537 ont nié cela. La bonne nouvelle est que le contrat de dépôt basé sur l'EIP-2537 est essentiellement terminé et attend maintenant un audit.
La 90ème réunion a fixé la date de lancement de la mise à niveau Berlin en juillet. La réunion a également discuté de la domination de Geth, avec une proposition de geler la mise en œuvre actuelle de l'EIP afin de réduire les coûts de développement des autres clients.
La 92ème réunion confirme toujours que l'EIP-2537 est l'EIP nécessaire pour la mise à niveau Berlin.
Lors de la 96e réunion, Matter Labs espérait 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. La décision finale a été de ne pas ajouter 2696 dans la mise à niveau de Berlin.
La 99ème réunion a décidé de retirer l'EIP-2537 du testnet YOLO v3 et de la mise à niveau Berlin, principalement parce qu'il a consommé trop de temps des développeurs principaux, impactant le développement d'autres EIP. Un facteur secondaire est que la fondation Ethereum a proposé l'EVM384 comme solution de remplacement.
En avril 2021, Ethereum a achevé la mise à niveau Berlin, dont la mise en œuvre réelle des EIP-2565 et autres éléments principaux n'est pas complexe, rendant la mise à niveau plutôt maigre. Cela est dû au fait que l'EIP-2537, qui est le plus complexe, a été éliminé.
Développement futur
La mise à niveau de Berlin de l'upgrade de London a introduit EIP-1559. Pour EIP-2537, qui était autrefois une proposition clé, il est difficile d'inclure cela dans les futures mises à niveau.
La mise à niveau de Londres est en cours, les développeurs ont envisagé d'ajouter l'EIP-2537. La 109e réunion a synchronisé l'état de développement de l'EIP-2537 et a discuté des problèmes d'utilisation du gas, certains ont proposé de remplacer l'EIP-2537 par l'EVM384. Cependant, lors de la 111e réunion, l'EIP-2537 a été retiré de la mise à niveau de Londres en raison de sa complexité. En effet, la mise en œuvre de la norme EIP-2537 a changé la bibliothèque de dépendance, ce qui pourrait entraîner des variations dans le prix du gas, et chaque client doit réévaluer la consommation de gas.
En juin 2021, il a été officiellement proposé d'inclure EIP-2537 dans la mise à niveau de Shanghai. Mais la mise à niveau Merge a occupé beaucoup de temps des développeurs. Ce n'est qu'après l'achèvement de Merge en septembre 2022 que les développeurs de la couche d'exécution ont eu l'occasion de poursuivre la discussion sur les objectifs de la mise à niveau de Shanghai.
En novembre 2022, la 150ème réunion a brièvement discuté de l'opportunité d'inclure l'EIP-2537 dans la mise à niveau de Shanghai, mais a jugé qu'il fallait reporter cette décision. Le cœur de la mise à niveau de Shanghai est de soutenir les retraits PoS. Finalement, l'EIP-2537 n'a pas été inclus dans la mise à niveau de Shanghai, qui est centrée sur la fonctionnalité de retrait.
Cancun n'a jamais discuté de l'EIP-2537, car son cœur est de soutenir l'EIP-4844, fournissant une couche de disponibilité des données Blob pour la couche 2.
En février 2024, lors de la 181e réunion, il a été discuté de l'intégration de l'EIP-2537 dans la mise à niveau de Pectra, considérant que sa réalisation n'est plus un problème, seul le prix de la consommation de gas pose problème.
Le 19 décembre 2024, lors de la 202ème réunion, les développeurs de Nethermind ont déterminé le modèle de tarification de l'EIP-2537. Le proposeur initial, Matter Labs, était presque retiré de la discussion à ce moment-là. La 203ème réunion de janvier 2025 a discuté de la re-tarification de la précompilation BLS, les développeurs de Geth suggérant d'augmenter le coût en gaz de 20%, soutenu par les tests de référence de l'équipe Besu.
Résumé
L'évolution de l'EIP-2537 peut être résumée comme suit :
L'intégration des EIP dans les mises à jour d'Ethereum dépend non seulement des efforts internes, mais aussi du processus historique. Chaque mise à jour a un thème, l'EIP-2537 a été au cœur de la mise à jour Berlin, mais a été abandonné en raison de sa complexité. Par la suite, Ethereum s'est concentré sur le PoS, et les EIP purement d'exécution n'ont pas été pris en compte, ce qui a conduit à un long refus de l'EIP-2537. Ce n'est que récemment que les développeurs ont de nouveau porté attention et résolu les problèmes laissés en suspens.