Cet article présente principalement l'historique de la gouvernance de l'EIP-2537, en explorant pourquoi cette proposition n'a été intégrée à la mise à niveau qu'après 5 ans.
Rédaction : shew
Aperçu
EIP-2537 est une instruction de pré-assemblage EVM qui a été déterminée pour être ajoutée dans la dernière mise à niveau de fork de Pectra. Cette instruction ajoute diverses fonctionnalités de calcul pour la courbe BLS12-381 à l'EVM, telles que le calcul de paires dans 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ésente principalement l'historique de la gouvernance de l'EIP-2537 et explore pourquoi il a fallu 5 ans pour que cette proposition soit 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 dans Exploring Elliptic Curve Pairings. Ensuite, en février 2017, Vitalik Buterin et Christian Reitwiessner ont proposé les EIP-196 et EIP-197, dont le contenu était d'ajouter un support de calcul de la courbe alt_bn128 à l'EVM.
Lors de la mise à niveau de Byzantium en octobre 2017, la courbe alt_bn128 a été officiellement intégrée. En termes simples, alt_bn128 a réalisé pour la première fois le calcul de paires de domaines de courbes à l'intérieur de l'EVM, ce qui permet la vérification des preuves ZK-Snarks au sein de l'EVM.
Mais avec le développement de la cryptographie, en novembre 2017, l'équipe de développement de zcash a présenté pour la première fois la courbe BLS12-381 dans BLS12-381: New zk-SNARK Elliptic Curve Construction. Par rapport à alt_bn128, BLS12-381 offre une sécurité supérieure et de meilleures performances. Un nombre considérable de protocoles de blockchain ont depuis utilisé la courbe BLS12-381 et abandonné la courbe alt_bn128.
En mai 2018, Justin Drake a publié un article sur ethresear intitulé "Pragmatic signature aggregation with BLS", soulignant que les futures mises à niveau PoS et sharding d'Ethereum pouvaient utiliser l'algorithme de multi-signature BLS basé sur la courbe BLS12-381. À l'époque, les chercheurs d'Ethereum espéraient utiliser l'EIP-1011 pour résoudre les problèmes de la couche de consensus, mais le plan EIP-1011 ne pouvait accueillir que 900 validateurs, établissant ainsi une énorme taille de mise de 1500 ETH pour chaque validateur. Avec la proposition du plan de multi-signature BLS, l'EIP-1011 a quitté la scène historique. Il s'est avéré que la mise à niveau ETH2 ultérieure a également finalement utilisé la courbe BLS12-381.
Avec le développement d'ETH2, le BLS12-381 utilisé par ETH2 a commencé à être appelé dans la couche d'exécution ETH. En février 2020, certains chercheurs ont proposé l'EIP-2537, espérant que cette proposition puisse être testée conjointement sur le réseau de test ETH2. L'auteur de l'EIP-2537, Alex Stokes, a appelé à l'inclusion de l'EIP-2537 dans le hard fork de Berlin dans son article "What eth2 needs from eth1 over the next six months".
Il est intéressant de noter que l'auteur de l'EIP-2537 est également l'un des cofondateurs de Matter Labs, dont le produit le plus célèbre est ZKSync.
Berlin bouleversement
Avant d'introduire le contenu suivant, nous devons d'abord présenter l'EIP-1962. L'EIP-1962 est la première proposition sur la pré-assemblage de paires de domaines de courbes elliptiques proposée par Matter Labs en avril 2019, et cette proposition prend en charge trois courbes, à savoir :
BLS12
BN
MNT4/6 (Ate pairing)
Cette EIP prévoit d'ajouter une fois pour toutes 10 instructions précompilées pour traiter différentes courbes. Cependant, après la naissance de cette proposition, un nombre considérable de développeurs a remis en question la complexité de la proposition, la rendant difficile à réaliser pour les développeurs. De plus, en raison de la grande généralisation de l'EIP1962, l'appel est également très compliqué pour les ingénieurs en contrats intelligents. Bien sûr, en tant que proposeur de l'EIP-1962, Matter Labs a en fait déjà terminé le travail de développement de l'algorithme de courbe elliptique et a fourni des implémentations de référence en Rust / Go / C++.
Pour résoudre le problème de l'EIP-1962, Matter Labs a proposé en février 2020 plusieurs EIP divisés de l'EIP-1962, ces EIP héritent tous en partie de l'interface de l'EIP-1962. Ces EIP incluent :
EIP-2537 fournit un support pour BLS12-381
EIP-2539 fournit un support pour BLS12-377
PR#2541 fournit le support de la courbe BLS12-377 (Zexe ), mais notez que cette proposition n'a finalement pas reçu de numéro EIP et ne peut pas être trouvée sur le site officiel de la documentation EIP.
Parmi ces EIP, le plus important est 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 validation des signatures BLS de la couche de consensus sur le réseau principal. À l'époque, ETH2 était en train de développer la conception des contrats de dépôt de la couche de consensus. Lors de la conception initiale des contrats de dépôt, comme l'algorithme de validation BLS n'était pas inclus dans la couche d'exécution, 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 (pour les nouveaux validateurs), le dépôt échouerait et l'ETH déposé par l'utilisateur serait perdu.
Dans ce contexte, les développeurs principaux souhaitent introduire une pré-assemblage BLS12-381 pour implémenter la vérification des signatures dans le contrat de dépôt, afin d'éviter les pertes potentielles de fonds ETH2 pour les 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é introduit pour la première fois, Vitalik a immédiatement identifié un certain nombre de problèmes avec l’EIP :
Ces questions se concentraient uniquement sur le contenu du document EIP, auquel l'auteur de l'EIP a ensuite répondu et discuté. Par la suite, le 6 mars 2020, lors de la réunion des développeurs principaux d'Ethereum #82, les développeurs principaux d'Ethereum ont discuté de l'EIP-2537. Lors de cette réunion, 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. De plus, la réunion a confirmé la priorité de l'EIP-2537, tous les clients étant d'accord pour mettre en œuvre l'EIP-2537 dès que possible et prévoyant de terminer tout le développement avant la mise à niveau de Berlin.
Ensuite, l'EIP-2537 est devenu une tâche de haute priorité. Le 20 mars 2020, lors de la réunion des développeurs principaux d'Ethereum #83, l'EIP-2537 a de nouveau été le premier sujet discuté. Cette réunion a confirmé que l'EIP-2537 remplace l'EIP-1962 en tant que proposition BLS principale et devient la liste préliminaire des EIP pour la mise à niveau de Berlin ( soit l'Éligibilité pour Inclusion (EFI)).
Lors de la réunion des développeurs principaux d'Ethereum #84 en avril 2020, il a été décidé d'inclure l'EIP-2537 dans la mise à niveau du hard fork Berlin, et un calendrier a été établi pour la mise en œuvre en avril et les tests en mai-juin. Il est à noter que lors de cette discussion, l'EIP-2537 a été classé comme une priorité maximale.
Ensuite, l'EIP-2537 est entré dans une phase de développement et de test intense, où chaque réunion des développeurs principaux, au cours des près de 20 réunions suivantes, a essentiellement impliqué des discussions sur l'EIP-2537. Passons maintenant en revue les questions concernant l'EIP-2537 qui ont été abordées lors de chaque réunion.
Lors de la réunion Ethereum Core Devs #85, Danno et Axic ont discuté de l’encodage ABI pour EIP-2537. Par la suite, les développeurs principaux ont synchronisé l’implémentation actuelle, dans laquelle le client Besu a déclaré que la fonctionnalité de l’EIP-2537 était essentiellement implémentée en raison du fait que Matter Labs, le proposant de l’EIP-2537, avait déjà terminé l’implémentation de la version Rust, mais Geth a déclaré que personne ne travaillait actuellement sur l’implémentation de l’EIP-2537.
Lors de la réunion des développeurs principaux d'Ethereum #86, différentes implémentations de nœuds Ethereum ont à nouveau synchronisé l'état d'avancement de l'EIP-2537, où Geth a indiqué avoir terminé une partie du travail, mais qu'il reste encore beaucoup de travail à accomplir.
!
Lors de la réunion des développeurs d'Ethereum Core #87, le sujet central de cette réunion était la question de la mise en œuvre de l'EIP-2537. Les développeurs de Geth ont indiqué qu'il existait actuellement une PR de 16000 lignes pour la mise en œuvre de l'EIP-2537, mais qu'ils ne pouvaient pas déterminer si cette PR était une mise en œuvre sûre et efficace de l'EIP-2537. Par conséquent, les développeurs ne pouvaient que juger de l'état du code à l'aide de tests flous simples et brutaux.
Le développeur de Geth a déclaré : « Donc, ma réaction instinctive est qu'il n'y a aucune chance que Geth soit prêt avec les opérations de courbe BLS pour le lancement du mainnet en juillet. », c'est-à-dire que Geth a de fortes chances de ne pas terminer le développement lié à l'EIP-2537 avant la date prévue de Berlin.
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 le testnet pour tester la sécurité de l'implémentation de l'EIP-2537. Comme l'équipe de développement d'ETH2 est également en train de mettre en œuvre la vérification des signatures BLS, l'équipe d'ETH2 peut donc participer aux tests.
Ici, nous devons ajouter une connaissance de base, à savoir que l'implémentation de Geth de l'EIP-2537 utilise beaucoup de code d'assemblage pour garantir l'efficacité, et cette partie du code d'assemblage est très difficile à lire et à comprendre. C'est pourquoi Alex Vlasov a suggéré de supprimer les optimisations d'assemblage complexes à l'intérieur du PR pour réduire la difficulté de révision.
Nous avons déjà présenté dans l'article précédent que l'un des objectifs principaux de l'EIP-2537 est d'assister le contrat de dépôt ETH2. Cependant, lors de cette réunion, les développeurs du contrat de dépôt ont indiqué que le contrat de dépôt qui n'utilise pas l'EIP-2537 a déjà été audité. Par conséquent, certains développeurs ont suggéré qu'il vaudrait mieux ne pas lancer un contrat de dépôt utilisant l'EIP-2537.
À la fin, la réunion a décidé d'ajouter le réseau de test YOLO, dont le cœur est de tester l'EIP-2537. En fait, lors de cette réunion, nous pouvons voir que l'importance de l'EIP-2537 a considérablement diminué avec l'achèvement du contrat de dépôt, tandis que les développeurs de Geth pensent déjà que cet EIP a de fortes chances de ne pas être réalisé avant la mise à niveau de Berlin. Il semble que le refus de l'EIP-2537 par la mise à niveau de Berlin soit devenu inévitable.
Lors de la réunion des développeurs principaux d'Ethereum #88, les développeurs de Geth ont découvert qu'il y avait une série de problèmes dans la PR d'implémentation de l'EIP-2537, et ils ont indiqué qu'il fallait encore des tests et des corrections supplémentaires. À ce moment-là, il y avait deux implémentations de l'EIP-2537 dans le système Geth, l'une contenant des optimisations en assembleur, tandis que l'autre était entièrement écrite en langage Go. Un développeur a proposé d'utiliser directement la version écrite en Go pour réduire la difficulté de la révision du code.
Lors de la réunion des développeurs principaux d'Ethereum #89, un problème plus grave est survenu, des problèmes ont été détectés lors du test YOLO, et les développeurs soupçonnent que cela est dû à la signature BLS, mais les développeurs de l'EIP2537 ont contesté cela, affirmant que le problème du testnet n'était pas causé par la signature BLS. La bonne nouvelle pour l'EIP-2537 est que le contrat de dépôt basé sur l'EIP-2537 est presque terminé, et ce contrat attend actuellement un audit.
Lors de la réunion des développeurs principaux d'Ethereum #90 内，这次会议锁定了 7 月份上线 Berlin 升级的 DDL。当然，这次会议另一个有趣的论点是客户端多样性问题，在此次会议中，开发者主要讨论了 Geth 占据主导地位的情况，并且有开发者提议冻结当前 EIP 实现来降低其他客户端的开发成本。更加有趣的是，在 #91, un développeur a proposé d'utiliser une solution modulaire pour réduire les coûts de développement afin d'augmenter la diversité des clients. Si le lecteur est intéressé par la diversité des clients Ethereum, il peut consulter les comptes rendus de ces deux réunions.
Lors de la réunion des développeurs principaux d'Ethereum #92, le 2537 est toujours confirmé comme l'EIP nécessaire pour la mise à niveau Berlin.
Lors de la réunion des développeurs principaux d'Ethereum #96, Celo a intégré EIP-2537 et EIP-2539 dans sa mise à niveau de hard fork. Par conséquent, Matter Labs souhaite également tester EIP-2539, qui a été proposé en même temps qu'EIP-2537, sur le testnet YOLO v2 et l'inclure dans la mise à niveau de Berlin. Cependant, les développeurs de Geth s'y opposent, arguant qu'EIP-2537 n'a pas encore été complètement testé en interne dans Geth. En fin de compte, la réunion a décidé de ne pas ajouter 2696 à la mise à niveau de Berlin, laissant cela pour une discussion future.
Lors de la réunion des développeurs principaux d'Ethereum #99, il a été décidé de retirer l'EIP-2537 du testnet YOLO v3 et de la mise à niveau Berlin. La raison principale est que l'EIP-2537 a fait perdre trop de temps aux 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 remplacement de l'EIP-2537, l'EVM 384 offrant une solution de calcul sur courbes elliptiques plus générale. Cependant, les développeurs principaux ont exprimé des inquiétudes concernant les problèmes de sécurité lors de la discussion de la réunion.
Le contenu ci-dessus retrace les débuts de l'EIP-2537. Nous pouvons voir que l'EIP-2537 était l'un des EIP les plus importants de la mise à niveau Berlin, mais en raison de problèmes de mise en œuvre, il a finalement été abandonné. Enfin, en avril 2021, Ethereum a achevé la mise à niveau Berlin, et les EIP tels que l'EIP-2565, qui sont au cœur de cette mise à niveau, ne sont pas particulièrement complexes. Il semble que la mise à niveau Berlin soit légèrement mince, car l'EIP-2537, qui était le plus complexe, a été exclu de la mise à niveau Berlin.
Développement ultérieur
Il est bien connu que chaque mise à niveau d'Ethereum s'accompagne d'une proposition clé, comme la mise à niveau de Berlin suivie de la mise à niveau de Londres qui a introduit la proposition de frais la plus importante de l'histoire d'Ethereum, EIP-1559. En ce qui concerne EIP-2537, qui était autrefois une proposition clé, il est difficile d'inclure cette proposition dans les mises à niveau ultérieures.
Dans la mise à niveau de Londres après Berlin, les développeurs ont synchronisé l'état actuel du développement de l'EIP-2537 dans issues#369 曾考虑在 London 升级中增加 EIP-2537。在 Ethereum Core Devs Meeting #109. À ce moment-là, en raison de l'utilisation d'autres bibliothèques pour l'implémentation de l'EIP-2537, une discussion sur l'utilisation du gaz pour l'EIP-2537 a été introduite. Par ailleurs, certains développeurs ont proposé de remplacer l'EIP-2537 par l'EVM384. Cependant, lors de la réunion des développeurs principaux d'Ethereum #111 en avril 2021, l'EIP-2537 a été retiré de la mise à niveau de Londres en raison de sa complexité. La complexité principale réside dans le fait que l'implémentation standard de l'EIP-2537 a remplacé les bibliothèques de dépendance, ce qui peut entraîner des variations dans la tarification du gaz, et les différentes implémentations des clients doivent prendre un temps considérable pour réévaluer la consommation de gaz.
En juin 2021, la proposition d'intégrer l'EIP-2537 dans la mise à niveau Shanghai a été officiellement soumise dans issues#343. Cependant, il convient de noter qu'après la mise à niveau London, la mise à niveau Pairs, également connue sous le nom de The Merge, a occupé une grande partie du temps des développeurs, et les développeurs de la couche d'exécution devaient écrire une quantité considérable de code pour mettre en œuvre la mise à niveau PoS. En septembre 2022, la mise à niveau Pairs a été achevée, et les développeurs de la couche d'exécution ont enfin eu l'occasion de continuer à discuter de certains objectifs de la mise à niveau Shanghai.
En novembre 2022, la réunion des développeurs principaux d'Ethereum #150 a brièvement discuté de l'inclusion de l'EIP-2537 dans la mise à niveau Shanghai, mais les développeurs ont estimé que l'EIP-2537 devait être reporté, la priorité de la mise à niveau Shanghai étant de supporter les retraits PoS. Finalement, l'EIP-2537 n'a pas été inclus dans la mise à niveau Shanghai, qui se concentre sur la fonction de retrait.
Plus tragique encore, la mise à niveau Cancun n'a jamais discuté de l'EIP-2537, car le cœur de la mise à niveau Cancun est le support des nœuds de la couche d'exécution pour l'EIP-4844. L'EIP-4844 fournit des Blob pour la deuxième couche d'Ethereum afin de faciliter l'utilisation d'Ethereum comme couche de disponibilité des données.
Enfin, lors de la réunion des développeurs principaux d'Ethereum #181 en février 2024, les développeurs ont discuté de l'inclusion de l'EIP-2537 dans la mise à niveau Pectra, et à ce moment-là, les développeurs estimaient que la mise en œuvre de l'EIP-2537 n'était plus un problème, seulement quelques problèmes concernant la tarification de la consommation de Gas.
Lors de la réunion des développeurs principaux d'Ethereum du 19 décembre 2024, #202 内，Nethermind 开发者最终确定了 EIP-2537 的定价模型。是的，作为 EIP-2537 的最初提案者 Matter Labs 此时已经近乎退出了讨论。在随后的，2025 年 1 月的 Ethereum Core Devs Meeting #203, les développeurs ont discuté de la revalorisation de la précompilation BLS. Le développeur de Geth, Jared Wasinger, a proposé d'augmenter le coût du gaz de 20 %, ce qui a été soutenu par les tests de référence de l'équipe Besu.
Résumé
On peut voir que l’inclusion de l’EIP dans la mise à niveau d’Ethereum, « bien sûr, dépend de la lutte personnelle, mais elle prend également en compte l’itinéraire historique ». Chaque mise à niveau d’Ethereum a son propre thème, tout comme l’EIP-2537 était autrefois l’EIP la plus importante pour la mise à niveau de Berlin, mais a été abandonnée en raison de sa difficulté et de sa complexité de mise en œuvre. Par la suite, Ethereum est entré dans le processus historique du PoS, et les EIP complexes d’exécution uniquement n’ont pas été pris au sérieux, tandis qu’un grand nombre d’EIP d’exécution liés au PoS ont été considérés comme des cibles de mise à niveau de base, ce qui a conduit à ce que l’EIP-2537 ne soit pas accepté pendant longtemps.
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
Observation de la gouvernance d'Ethereum : parcours de pré-assemblage de l'EIP-2537｜GCC Research
Rédaction : shew
Aperçu
EIP-2537 est une instruction de pré-assemblage EVM qui a été déterminée pour être ajoutée dans la dernière mise à niveau de fork de Pectra. Cette instruction ajoute diverses fonctionnalités de calcul pour la courbe BLS12-381 à l'EVM, telles que le calcul de paires dans 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ésente principalement l'historique de la gouvernance de l'EIP-2537 et explore pourquoi il a fallu 5 ans pour que cette proposition soit 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 dans Exploring Elliptic Curve Pairings. Ensuite, en février 2017, Vitalik Buterin et Christian Reitwiessner ont proposé les EIP-196 et EIP-197, dont le contenu était d'ajouter un support de calcul de la courbe alt_bn128 à l'EVM.
Lors de la mise à niveau de Byzantium en octobre 2017, la courbe alt_bn128 a été officiellement intégrée. En termes simples, alt_bn128 a réalisé pour la première fois le calcul de paires de domaines de courbes à l'intérieur de l'EVM, ce qui permet la vérification des preuves ZK-Snarks au sein de l'EVM.
Mais avec le développement de la cryptographie, en novembre 2017, l'équipe de développement de zcash a présenté pour la première fois la courbe BLS12-381 dans BLS12-381: New zk-SNARK Elliptic Curve Construction. Par rapport à alt_bn128, BLS12-381 offre une sécurité supérieure et de meilleures performances. Un nombre considérable de protocoles de blockchain ont depuis utilisé la courbe BLS12-381 et abandonné la courbe alt_bn128.
En mai 2018, Justin Drake a publié un article sur ethresear intitulé "Pragmatic signature aggregation with BLS", soulignant que les futures mises à niveau PoS et sharding d'Ethereum pouvaient utiliser l'algorithme de multi-signature BLS basé sur la courbe BLS12-381. À l'époque, les chercheurs d'Ethereum espéraient utiliser l'EIP-1011 pour résoudre les problèmes de la couche de consensus, mais le plan EIP-1011 ne pouvait accueillir que 900 validateurs, établissant ainsi une énorme taille de mise de 1500 ETH pour chaque validateur. Avec la proposition du plan de multi-signature BLS, l'EIP-1011 a quitté la scène historique. Il s'est avéré que la mise à niveau ETH2 ultérieure a également finalement utilisé la courbe BLS12-381.
Avec le développement d'ETH2, le BLS12-381 utilisé par ETH2 a commencé à être appelé dans la couche d'exécution ETH. En février 2020, certains chercheurs ont proposé l'EIP-2537, espérant que cette proposition puisse être testée conjointement sur le réseau de test ETH2. L'auteur de l'EIP-2537, Alex Stokes, a appelé à l'inclusion de l'EIP-2537 dans le hard fork de Berlin dans son article "What eth2 needs from eth1 over the next six months".
Il est intéressant de noter que l'auteur de l'EIP-2537 est également l'un des cofondateurs de Matter Labs, dont le produit le plus célèbre est ZKSync.
Berlin bouleversement
Avant d'introduire le contenu suivant, nous devons d'abord présenter l'EIP-1962. L'EIP-1962 est la première proposition sur la pré-assemblage de paires de domaines de courbes elliptiques proposée par Matter Labs en avril 2019, et cette proposition prend en charge trois courbes, à savoir :
Cette EIP prévoit d'ajouter une fois pour toutes 10 instructions précompilées pour traiter différentes courbes. Cependant, après la naissance de cette proposition, un nombre considérable de développeurs a remis en question la complexité de la proposition, la rendant difficile à réaliser pour les développeurs. De plus, en raison de la grande généralisation de l'EIP1962, l'appel est également très compliqué pour les ingénieurs en contrats intelligents. Bien sûr, en tant que proposeur de l'EIP-1962, Matter Labs a en fait déjà terminé le travail de développement de l'algorithme de courbe elliptique et a fourni des implémentations de référence en Rust / Go / C++.
Pour résoudre le problème de l'EIP-1962, Matter Labs a proposé en février 2020 plusieurs EIP divisés de l'EIP-1962, ces EIP héritent tous en partie de l'interface de l'EIP-1962. Ces EIP incluent :
Parmi ces EIP, le plus important est 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 validation des signatures BLS de la couche de consensus sur le réseau principal. À l'époque, ETH2 était en train de développer la conception des contrats de dépôt de la couche de consensus. Lors de la conception initiale des contrats de dépôt, comme l'algorithme de validation BLS n'était pas inclus dans la couche d'exécution, 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 (pour les nouveaux validateurs), le dépôt échouerait et l'ETH déposé par l'utilisateur serait perdu.
Dans ce contexte, les développeurs principaux souhaitent introduire une pré-assemblage BLS12-381 pour implémenter la vérification des signatures dans le contrat de dépôt, afin d'éviter les pertes potentielles de fonds ETH2 pour les 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é introduit pour la première fois, Vitalik a immédiatement identifié un certain nombre de problèmes avec l’EIP :
Ces questions se concentraient uniquement sur le contenu du document EIP, auquel l'auteur de l'EIP a ensuite répondu et discuté. Par la suite, le 6 mars 2020, lors de la réunion des développeurs principaux d'Ethereum #82, les développeurs principaux d'Ethereum ont discuté de l'EIP-2537. Lors de cette réunion, 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. De plus, la réunion a confirmé la priorité de l'EIP-2537, tous les clients étant d'accord pour mettre en œuvre l'EIP-2537 dès que possible et prévoyant de terminer tout le développement avant la mise à niveau de Berlin.
Ensuite, l'EIP-2537 est devenu une tâche de haute priorité. Le 20 mars 2020, lors de la réunion des développeurs principaux d'Ethereum #83, l'EIP-2537 a de nouveau été le premier sujet discuté. Cette réunion a confirmé que l'EIP-2537 remplace l'EIP-1962 en tant que proposition BLS principale et devient la liste préliminaire des EIP pour la mise à niveau de Berlin ( soit l'Éligibilité pour Inclusion (EFI)).
Lors de la réunion des développeurs principaux d'Ethereum #84 en avril 2020, il a été décidé d'inclure l'EIP-2537 dans la mise à niveau du hard fork Berlin, et un calendrier a été établi pour la mise en œuvre en avril et les tests en mai-juin. Il est à noter que lors de cette discussion, l'EIP-2537 a été classé comme une priorité maximale.
Ensuite, l'EIP-2537 est entré dans une phase de développement et de test intense, où chaque réunion des développeurs principaux, au cours des près de 20 réunions suivantes, a essentiellement impliqué des discussions sur l'EIP-2537. Passons maintenant en revue les questions concernant l'EIP-2537 qui ont été abordées lors de chaque réunion.
Lors de la réunion Ethereum Core Devs #85, Danno et Axic ont discuté de l’encodage ABI pour EIP-2537. Par la suite, les développeurs principaux ont synchronisé l’implémentation actuelle, dans laquelle le client Besu a déclaré que la fonctionnalité de l’EIP-2537 était essentiellement implémentée en raison du fait que Matter Labs, le proposant de l’EIP-2537, avait déjà terminé l’implémentation de la version Rust, mais Geth a déclaré que personne ne travaillait actuellement sur l’implémentation de l’EIP-2537.
Lors de la réunion des développeurs principaux d'Ethereum #86, différentes implémentations de nœuds Ethereum ont à nouveau synchronisé l'état d'avancement de l'EIP-2537, où Geth a indiqué avoir terminé une partie du travail, mais qu'il reste encore beaucoup de travail à accomplir.
!
Lors de la réunion des développeurs d'Ethereum Core #87, le sujet central de cette réunion était la question de la mise en œuvre de l'EIP-2537. Les développeurs de Geth ont indiqué qu'il existait actuellement une PR de 16000 lignes pour la mise en œuvre de l'EIP-2537, mais qu'ils ne pouvaient pas déterminer si cette PR était une mise en œuvre sûre et efficace de l'EIP-2537. Par conséquent, les développeurs ne pouvaient que juger de l'état du code à l'aide de tests flous simples et brutaux.
Le développeur de Geth a déclaré : « Donc, ma réaction instinctive est qu'il n'y a aucune chance que Geth soit prêt avec les opérations de courbe BLS pour le lancement du mainnet en juillet. », c'est-à-dire que Geth a de fortes chances de ne pas terminer le développement lié à l'EIP-2537 avant la date prévue de Berlin.
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 le testnet pour tester la sécurité de l'implémentation de l'EIP-2537. Comme l'équipe de développement d'ETH2 est également en train de mettre en œuvre la vérification des signatures BLS, l'équipe d'ETH2 peut donc participer aux tests.
Ici, nous devons ajouter une connaissance de base, à savoir que l'implémentation de Geth de l'EIP-2537 utilise beaucoup de code d'assemblage pour garantir l'efficacité, et cette partie du code d'assemblage est très difficile à lire et à comprendre. C'est pourquoi Alex Vlasov a suggéré de supprimer les optimisations d'assemblage complexes à l'intérieur du PR pour réduire la difficulté de révision.
Nous avons déjà présenté dans l'article précédent que l'un des objectifs principaux de l'EIP-2537 est d'assister le contrat de dépôt ETH2. Cependant, lors de cette réunion, les développeurs du contrat de dépôt ont indiqué que le contrat de dépôt qui n'utilise pas l'EIP-2537 a déjà été audité. Par conséquent, certains développeurs ont suggéré qu'il vaudrait mieux ne pas lancer un contrat de dépôt utilisant l'EIP-2537.
À la fin, la réunion a décidé d'ajouter le réseau de test YOLO, dont le cœur est de tester l'EIP-2537. En fait, lors de cette réunion, nous pouvons voir que l'importance de l'EIP-2537 a considérablement diminué avec l'achèvement du contrat de dépôt, tandis que les développeurs de Geth pensent déjà que cet EIP a de fortes chances de ne pas être réalisé avant la mise à niveau de Berlin. Il semble que le refus de l'EIP-2537 par la mise à niveau de Berlin soit devenu inévitable.
Lors de la réunion des développeurs principaux d'Ethereum #88, les développeurs de Geth ont découvert qu'il y avait une série de problèmes dans la PR d'implémentation de l'EIP-2537, et ils ont indiqué qu'il fallait encore des tests et des corrections supplémentaires. À ce moment-là, il y avait deux implémentations de l'EIP-2537 dans le système Geth, l'une contenant des optimisations en assembleur, tandis que l'autre était entièrement écrite en langage Go. Un développeur a proposé d'utiliser directement la version écrite en Go pour réduire la difficulté de la révision du code.
Lors de la réunion des développeurs principaux d'Ethereum #89, un problème plus grave est survenu, des problèmes ont été détectés lors du test YOLO, et les développeurs soupçonnent que cela est dû à la signature BLS, mais les développeurs de l'EIP2537 ont contesté cela, affirmant que le problème du testnet n'était pas causé par la signature BLS. La bonne nouvelle pour l'EIP-2537 est que le contrat de dépôt basé sur l'EIP-2537 est presque terminé, et ce contrat attend actuellement un audit.
Lors de la réunion des développeurs principaux d'Ethereum #90 内，这次会议锁定了 7 月份上线 Berlin 升级的 DDL。当然，这次会议另一个有趣的论点是客户端多样性问题，在此次会议中，开发者主要讨论了 Geth 占据主导地位的情况，并且有开发者提议冻结当前 EIP 实现来降低其他客户端的开发成本。更加有趣的是，在 #91, un développeur a proposé d'utiliser une solution modulaire pour réduire les coûts de développement afin d'augmenter la diversité des clients. Si le lecteur est intéressé par la diversité des clients Ethereum, il peut consulter les comptes rendus de ces deux réunions.
Lors de la réunion des développeurs principaux d'Ethereum #92, le 2537 est toujours confirmé comme l'EIP nécessaire pour la mise à niveau Berlin.
Lors de la réunion des développeurs principaux d'Ethereum #96, Celo a intégré EIP-2537 et EIP-2539 dans sa mise à niveau de hard fork. Par conséquent, Matter Labs souhaite également tester EIP-2539, qui a été proposé en même temps qu'EIP-2537, sur le testnet YOLO v2 et l'inclure dans la mise à niveau de Berlin. Cependant, les développeurs de Geth s'y opposent, arguant qu'EIP-2537 n'a pas encore été complètement testé en interne dans Geth. En fin de compte, la réunion a décidé de ne pas ajouter 2696 à la mise à niveau de Berlin, laissant cela pour une discussion future.
Lors de la réunion des développeurs principaux d'Ethereum #99, il a été décidé de retirer l'EIP-2537 du testnet YOLO v3 et de la mise à niveau Berlin. La raison principale est que l'EIP-2537 a fait perdre trop de temps aux 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 remplacement de l'EIP-2537, l'EVM 384 offrant une solution de calcul sur courbes elliptiques plus générale. Cependant, les développeurs principaux ont exprimé des inquiétudes concernant les problèmes de sécurité lors de la discussion de la réunion.
Le contenu ci-dessus retrace les débuts de l'EIP-2537. Nous pouvons voir que l'EIP-2537 était l'un des EIP les plus importants de la mise à niveau Berlin, mais en raison de problèmes de mise en œuvre, il a finalement été abandonné. Enfin, en avril 2021, Ethereum a achevé la mise à niveau Berlin, et les EIP tels que l'EIP-2565, qui sont au cœur de cette mise à niveau, ne sont pas particulièrement complexes. Il semble que la mise à niveau Berlin soit légèrement mince, car l'EIP-2537, qui était le plus complexe, a été exclu de la mise à niveau Berlin.
Développement ultérieur
Il est bien connu que chaque mise à niveau d'Ethereum s'accompagne d'une proposition clé, comme la mise à niveau de Berlin suivie de la mise à niveau de Londres qui a introduit la proposition de frais la plus importante de l'histoire d'Ethereum, EIP-1559. En ce qui concerne EIP-2537, qui était autrefois une proposition clé, il est difficile d'inclure cette proposition dans les mises à niveau ultérieures.
Dans la mise à niveau de Londres après Berlin, les développeurs ont synchronisé l'état actuel du développement de l'EIP-2537 dans issues#369 曾考虑在 London 升级中增加 EIP-2537。在 Ethereum Core Devs Meeting #109. À ce moment-là, en raison de l'utilisation d'autres bibliothèques pour l'implémentation de l'EIP-2537, une discussion sur l'utilisation du gaz pour l'EIP-2537 a été introduite. Par ailleurs, certains développeurs ont proposé de remplacer l'EIP-2537 par l'EVM384. Cependant, lors de la réunion des développeurs principaux d'Ethereum #111 en avril 2021, l'EIP-2537 a été retiré de la mise à niveau de Londres en raison de sa complexité. La complexité principale réside dans le fait que l'implémentation standard de l'EIP-2537 a remplacé les bibliothèques de dépendance, ce qui peut entraîner des variations dans la tarification du gaz, et les différentes implémentations des clients doivent prendre un temps considérable pour réévaluer la consommation de gaz.
En juin 2021, la proposition d'intégrer l'EIP-2537 dans la mise à niveau Shanghai a été officiellement soumise dans issues#343. Cependant, il convient de noter qu'après la mise à niveau London, la mise à niveau Pairs, également connue sous le nom de The Merge, a occupé une grande partie du temps des développeurs, et les développeurs de la couche d'exécution devaient écrire une quantité considérable de code pour mettre en œuvre la mise à niveau PoS. En septembre 2022, la mise à niveau Pairs a été achevée, et les développeurs de la couche d'exécution ont enfin eu l'occasion de continuer à discuter de certains objectifs de la mise à niveau Shanghai.
En novembre 2022, la réunion des développeurs principaux d'Ethereum #150 a brièvement discuté de l'inclusion de l'EIP-2537 dans la mise à niveau Shanghai, mais les développeurs ont estimé que l'EIP-2537 devait être reporté, la priorité de la mise à niveau Shanghai étant de supporter les retraits PoS. Finalement, l'EIP-2537 n'a pas été inclus dans la mise à niveau Shanghai, qui se concentre sur la fonction de retrait.
Plus tragique encore, la mise à niveau Cancun n'a jamais discuté de l'EIP-2537, car le cœur de la mise à niveau Cancun est le support des nœuds de la couche d'exécution pour l'EIP-4844. L'EIP-4844 fournit des Blob pour la deuxième couche d'Ethereum afin de faciliter l'utilisation d'Ethereum comme couche de disponibilité des données.
Enfin, lors de la réunion des développeurs principaux d'Ethereum #181 en février 2024, les développeurs ont discuté de l'inclusion de l'EIP-2537 dans la mise à niveau Pectra, et à ce moment-là, les développeurs estimaient que la mise en œuvre de l'EIP-2537 n'était plus un problème, seulement quelques problèmes concernant la tarification de la consommation de Gas.
Lors de la réunion des développeurs principaux d'Ethereum du 19 décembre 2024, #202 内，Nethermind 开发者最终确定了 EIP-2537 的定价模型。是的，作为 EIP-2537 的最初提案者 Matter Labs 此时已经近乎退出了讨论。在随后的，2025 年 1 月的 Ethereum Core Devs Meeting #203, les développeurs ont discuté de la revalorisation de la précompilation BLS. Le développeur de Geth, Jared Wasinger, a proposé d'augmenter le coût du gaz de 20 %, ce qui a été soutenu par les tests de référence de l'équipe Besu.
Résumé
On peut voir que l’inclusion de l’EIP dans la mise à niveau d’Ethereum, « bien sûr, dépend de la lutte personnelle, mais elle prend également en compte l’itinéraire historique ». Chaque mise à niveau d’Ethereum a son propre thème, tout comme l’EIP-2537 était autrefois l’EIP la plus importante pour la mise à niveau de Berlin, mais a été abandonnée en raison de sa difficulté et de sa complexité de mise en œuvre. Par la suite, Ethereum est entré dans le processus historique du PoS, et les EIP complexes d’exécution uniquement n’ont pas été pris au sérieux, tandis qu’un grand nombre d’EIP d’exécution liés au PoS ont été considérés comme des cibles de mise à niveau de base, ce qui a conduit à ce que l’EIP-2537 ne soit pas accepté pendant longtemps.