EIP-2537 est une instruction pré-assemblée EVM qui a été confirmée pour être ajoutée lors de la dernière mise à niveau du fork de Pectra. Cette instruction ajoute plusieurs fonctionnalités de calcul sur la courbe BLS12-381 pour l'EVM, telles que 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 l'intégration dans la mise à niveau d'Ethereum qu'en 2025. Cet article présente principalement l'historique de la gouvernance d'EIP-2537 et examine pourquoi il a fallu 5 ans pour inclure cette proposition dans la mise à niveau.
Contexte de la proposition
En janvier 2017, Vitalik Buterin a présenté pour la première fois l'algorithme de pairage et la courbe alt_bn128 lors de la conférence Exploring Elliptic Curve Pairings. Puis, en février 2017, Vitalik Buterin et Christian Reitwiessner ont proposé les propositions EIP-196 et EIP-197, qui consistent à ajouter le 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 d'autres termes, alt_bn128 a réalisé pour la première fois le calcul de paires sur le domaine de courbe à 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é plus élevée et de meilleures performances. Un nombre considérable de protocoles de blockchain ont ensuite utilisé la courbe BLS12-381 et abandonné la courbe alt_bn128.
En mai 2018, Justin Drake a publié l’article Pragmatic signature aggregation with BLS in ethresear, indiquant que les futures mises à niveau de PoS et de shard sur Ethereum pourraient utiliser l’algorithme multisig BLS basé sur la courbe « BLS12-381 ». À l’époque, les chercheurs d’Ethereum voulaient utiliser EIP-1011 pour résoudre le problème de la couche de consensus, mais le schéma EIP-1011 pouvait accueillir jusqu’à 900 validateurs, de sorte qu’une énorme taille de mise de 1 500 ETH a été fixée pour chaque validateur. Avec l’introduction du système multisig du BLS, l’EIP-1011 s’est retiré de la scène de l’histoire. Il s’avère que les mises à niveau ultérieures de l’ETH2 ont également fini par utiliser la courbe « BLS12-381 ».
Avec le développement d'ETH2, le BLS12-381 utilisé par ETH2 commence à ê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 pourrait être testée conjointement sur le réseau de test ETH2. L'auteur de l'EIP-2537, Alex Stokes, appelle dans l'article What eth2 needs from eth1 over the next six months à inclure l'EIP-2537 dans la hard fork de Berlin.
Il est intéressant de noter que l'auteur de l'EIP-2537 est également le cofondateur de Matter Labs, dont le produit le plus célèbre est ZKSync.
Berlin turbulences
Avant de présenter le contenu suivant, nous devons d'abord introduire l'EIP-1962. L'EIP-1962 est la première proposition concernant l'assemblage préliminaire de paires de domaines de courbes elliptiques, proposée par Matter Labs en avril 2019. Cette proposition prend en charge trois courbes, à savoir :
BLS12
BN
MNT4/6 (Ate pairing)
L’EIP est prêt à ajouter 10 instructions de préassemblage à la fois pour traiter différentes courbes. Cependant, après la naissance de la proposition, un nombre important de développeurs se sont interrogés sur le fait que la proposition était trop complexe à mettre en œuvre pour les développeurs. Dans le même temps, en raison de la forte généralisation des EIP1962, il est également très difficile pour les ingénieurs de contrats intelligents d’appeler. Bien sûr, en tant qu’initiateur de l’EIP-1962, Matter Labs a essentiellement achevé le développement de l’algorithme de courbe elliptique et a fourni une implémentation de référence Rust/Go/C++.
Pour résoudre le problème de l'EIP-1962, Matter Labs a proposé plusieurs EIP en février 2020, en scindant l'EIP-1962. Ces EIP héritent 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
La PR#2541 fournit le support de la courbe BLS12-377 (Zexe ), mais notez que cette proposition n'a finalement pas obtenu 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 vérification des signatures BLS sur la couche de consensus dans le réseau principal. À l'époque, ETH2 développait la conception des contrats de dépôt pour la couche de consensus. Lors de la conception initiale des contrats de dépôt, comme l'algorithme de vérification BLS n'était pas inclus dans la couche d'exécution, le contrat de dépôt ne vérifiait pas les signatures. La signature BLS spécifique serait vérifiée 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 le pré-assemblage BLS12-381 pour réaliser la vérification des signatures dans le contrat de dépôt, afin d'éviter la possibilité de perte 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 EIP-2537 a été proposé pour la première fois, Vitalik a immédiatement identifié une série de problèmes liés à EIP.
Ces questions se concentraient uniquement sur le contenu de la documentation EIP, auquel les auteurs de l'EIP ont ensuite répondu et discuté. Par la suite, le 6 mars 2020, lors de la réunion Ethereum Core Devs Meeting #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 étaient très efficaces pour les preuves SNARK récursives et qu'à long terme, cela ne nuirait pas à Ethereum. En outre, la réunion a également confirmé la priorité de l'EIP-2537, tous les clients s'accordant à 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 d'Ethereum Core #83, l'EIP-2537 a encore été le premier projet discuté. Cette réunion a confirmé que l'EIP-2537 remplace l'EIP-1962 pour devenir la proposition BLS centrale et faire partie de la liste préliminaire des EIP pour la mise à niveau de Berlin (, à savoir l'Éligibilité à l'Inclusion (EFI)).
Lors de la réunion des développeurs principaux d'Ethereum #84 en avril 2020, il a été officiellement 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 convient de noter que lors de cette discussion, l'EIP-2537 a été classé comme une priorité maximale.
Par la suite, l'EIP-2537 est entré dans une phase de développement et de test intensive, et lors des près de 20 réunions des développeurs principaux qui ont suivi, chaque réunion a essentiellement impliqué une discussion sur l'EIP-2537. Ensuite, nous pouvons examiner les questions concernant l'EIP-2537 qui ont été discutées à chaque réunion.
Lors de la réunion des développeurs principaux d'Ethereum #85, Danno et Axic ont discuté des problèmes de codage ABI de l'EIP-2537. Ensuite, les développeurs principaux ont synchronisé l'état actuel des mises en œuvre, où, en raison du fait que le proposant de l'EIP-2537, Matter Labs, avait déjà essentiellement terminé la mise en œuvre de la version Rust, le client Besu a déclaré avoir essentiellement mis en œuvre les fonctionnalités de l'EIP-2537. Cependant, du côté de Geth, il a été indiqué qu'aucune personne ne travaillait actuellement sur la mise en œuvre 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 la mise en œuvre de l'EIP-2537, où Geth a indiqué avoir terminé une partie du travail, mais qu'il reste encore beaucoup à faire.
Lors de la réunion des développeurs d'Ethereum Core #87, le contenu le plus crucial de cette réunion de développeurs est la question de l'implémentation de l'EIP-2537. Les développeurs de Geth ont indiqué qu'il existe actuellement une PR de 16000 lignes pour l'implémentation de l'EIP-2537, mais les développeurs de Geth ne peuvent pas déterminer si la PR est une implémentation sûre et efficace de l'EIP-2537, donc les développeurs ne peuvent que juger l'état du code par le biais de tests flous très simples.
Les développeurs de Geth ont 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 de la mainnet en juillet." Cela signifie que Geth ne pourra probablement 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 réseau de test 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 un contexte, à savoir que l'implémentation PR de l'EIP-2537 de Geth 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 le texte 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 déclaré que le contrat de dépôt qui n'utilise pas l'EIP-2537 avait déjà été audité. Par conséquent, certains développeurs ont proposé 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 estiment déjà que cet EIP a de fortes chances de ne pas être mis en œuvre avant la mise à niveau de Berlin. Il semble que le refus de l'EIP-2537 par la mise à niveau de Berlin soit désormais inévitable.
Lors de la réunion des développeurs principaux d'Ethereum #88, les développeurs de Geth ont découvert une série de problèmes dans la PR d'implémentation de l'EIP-2537, et ils ont indiqué qu'une phase de tests et de corrections supplémentaires était nécessaire. À ce moment-là, il existait 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.
#89内In la réunion des développeurs Ethereum Core, un problème plus grave s’est produit, avec quelques problèmes avec le test YOLO, que les développeurs soupçonnaient d’être causé par la signature BLS, mais les développeurs EIP2537 l’ont réfuté, arguant que le problème du réseau de test 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 essentiellement développé et que le contrat est en attente d’audit contractuel.
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 approche 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 a été confirmé comme étant le EIP nécessaire pour la mise à niveau Berlin.
Lors de la réunion des développeurs principaux d'Ethereum #96, il a été noté que Celo a intégré à la fois l'EIP-2537 et l'EIP-2539 dans sa mise à niveau de hard fork de réseau. Ainsi, Matter Labs souhaite également tester l'EIP-2539, proposé simultanément avec l'EIP-2537, sur le testnet YOLO v2 et l'inclure dans la mise à niveau Berlin. Cependant, les développeurs de Geth s'y opposent, estimant que l'EIP-2537 n'a pas encore été complètement testé en interne dans Geth. La décision finale de la réunion a été de ne pas ajouter le 2696 à la mise à niveau Berlin et de laisser cela pour de futures discussions.
Lors de la réunion des développeurs principaux d'Ethereum #99, il a été décidé de retirer l'EIP-2537 du réseau de test 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 dans 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 de courbes elliptiques plus générale. Cependant, les développeurs principaux ont exprimé des inquiétudes concernant les problèmes de sécurité lors des discussions de la réunion.
Le contenu ci-dessus décrit le parcours précoce de l'EIP-2537. Nous pouvons voir que l'EIP-2537 était l'un des EIP les plus importants lors de la mise à niveau de Berlin, mais en raison de problèmes de mise en œuvre, il a finalement été abandonné. Enfin, en avril 2021, Ethereum a terminé la mise à niveau de Berlin. Les EIP comme l'EIP-2565, qui faisaient partie des éléments centraux de cette mise à niveau, ne sont en réalité pas très complexes. Il semble que la mise à niveau de Berlin soit un peu mince, car l'EIP-2537, qui est le plus complexe, a été écarté de la mise à niveau de Berlin.
Suivi du développement
Comme tout le monde le sait, 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 de transaction la plus importante de l'histoire d'Ethereum, EIP-1559. En ce qui concerne l'EIP-2537, qui était auparavant une proposition clé, il est difficile d'intégrer cette proposition dans les mises à niveau suivantes.
Dans la mise à niveau post-Berlin Londres, les développeurs ont synchronisé le développement actuel de l’EIP-2537 dans l’issues#369曾考虑在 London 升级中增加 EIP-2537。在Ethereum Core Devs Meeting #109, et à ce moment-là, ont introduit une discussion sur l’utilisation du gaz pour l’EIP-2537 en raison de l’utilisation d’autres bibliothèques pour implémenter l’EIP-2537. Dans le même temps, certains développeurs ont proposé de remplacer EIP-2537 par EVM384. Cependant, #111内 la réunion des développeurs d’Ethereum Core en avril 2021, EIP-2537 a été retiré de la mise à niveau de Londres en raison de sa complexité. La complexité fondamentale réside dans le remplacement des bibliothèques dépendantes par la mise en œuvre de la norme EIP-2537, ce qui entraîne des changements possibles dans la tarification du gaz et un temps considérable pour les différentes implémentations clientes pour réévaluer la consommation de gaz.
En juin 2021, la proposition d'inclure l'EIP-2537 dans la mise à niveau de Shanghai a été formellement soumise dans issues#343. Cependant, il convient de noter qu'après la mise à niveau de Londres, la mise à niveau Pairs, également appelée The Merge, a occupé une grande partie du temps des développeurs. Les développeurs de la couche d'exécution devaient écrire beaucoup de code pour réaliser 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 de Shanghai.
En novembre 2022, lors de la réunion des développeurs principaux d'Ethereum #150, il a été brièvement discuté de l'inclusion de l'EIP-2537 dans la mise à niveau de Shanghai, mais les développeurs ont estimé que l'EIP-2537 devait être reporté, la mise à niveau de Shanghai se concentrant sur le soutien aux retraits PoS. Finalement, l'EIP-2537 n'a pas été inclus dans la mise à niveau de Shanghai, qui se concentrait sur la fonctionnalité de retrait.
Ce qui est encore plus tragique, c'est que la mise à niveau de Cancun n'a jamais discuté de l'EIP-2537, car le cœur de la mise à niveau de Cancun est le soutien des nœuds de la couche d'exécution à l'EIP-4844. L'EIP-4844 fournit des Blob pour la couche 2 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, seules quelques questions restaient concernant la tarification de la consommation de Gaz.
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. Jared Wasinger, développeur de Geth, a proposé d'augmenter le coût du gaz de 20 %, avec le soutien des tests de référence de l'équipe Besu.
résumé
| Date | Événement |
| --- | --- |
| Février 2020 | Proposition officielle de la division EIP-1962 EIP-2537 |
| Avril 2020 - Octobre 2020 | Plusieurs réunions de développeurs ont discuté des problèmes de mise en œuvre de l'EIP-2537, qui a finalement été abandonné lors de la mise à niveau Berlin en raison de son impossibilité de mise en œuvre |
| Mars 2021 - Avril 2021 | Réunion des développeurs discutant du problème des coûts de gaz de l'EIP-2537, finalement abandonné lors de la mise à niveau de Londres en raison de sa complexité |
| Novembre 2022 | La réunion des développeurs discute de l'inclusion de la mise à niveau Shanghai, sans succès |
| Février 2024 | Les développeurs estiment qu'il n'y a pas de problème d'implémentation avec l'EIP-2537, mais qu'il existe encore des problèmes de coût en gas, et pensent qu'il pourrait être inclus dans la mise à niveau Pectra |
| Décembre 2024 - Janvier 2025 | Réunion des développeurs pour discuter du modèle de calcul des coûts spécifique, résolution officielle du problème de coût de l'EIP-2537 |
On peut voir que l’inclusion de l’EIP dans la mise à niveau d’Ethereum, « bien sûr, dépend de l’auto-lutte, mais 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
Auteur : shew
Aperçu
EIP-2537 est une instruction pré-assemblée EVM qui a été confirmée pour être ajoutée lors de la dernière mise à niveau du fork de Pectra. Cette instruction ajoute plusieurs fonctionnalités de calcul sur la courbe BLS12-381 pour l'EVM, telles que 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 l'intégration dans la mise à niveau d'Ethereum qu'en 2025. Cet article présente principalement l'historique de la gouvernance d'EIP-2537 et examine pourquoi il a fallu 5 ans pour inclure cette proposition dans la mise à niveau.
Contexte de la proposition
En janvier 2017, Vitalik Buterin a présenté pour la première fois l'algorithme de pairage et la courbe
alt_bn128lors de la conférence Exploring Elliptic Curve Pairings. Puis, en février 2017, Vitalik Buterin et Christian Reitwiessner ont proposé les propositions EIP-196 et EIP-197, qui consistent à ajouter le support de calcul de la courbealt_bn128à l'EVM.Lors de la mise à niveau de Byzantium en octobre 2017, la courbe
alt_bn128a été officiellement intégrée. En d'autres termes,alt_bn128a réalisé pour la première fois le calcul de paires sur le domaine de courbe à 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-381dans BLS12-381: New zk-SNARK Elliptic Curve Construction. Par rapport àalt_bn128,BLS12-381offre une sécurité plus élevée et de meilleures performances. Un nombre considérable de protocoles de blockchain ont ensuite utilisé la courbeBLS12-381et abandonné la courbealt_bn128.En mai 2018, Justin Drake a publié l’article Pragmatic signature aggregation with BLS in ethresear, indiquant que les futures mises à niveau de PoS et de shard sur Ethereum pourraient utiliser l’algorithme multisig BLS basé sur la courbe « BLS12-381 ». À l’époque, les chercheurs d’Ethereum voulaient utiliser EIP-1011 pour résoudre le problème de la couche de consensus, mais le schéma EIP-1011 pouvait accueillir jusqu’à 900 validateurs, de sorte qu’une énorme taille de mise de 1 500 ETH a été fixée pour chaque validateur. Avec l’introduction du système multisig du BLS, l’EIP-1011 s’est retiré de la scène de l’histoire. Il s’avère que les mises à niveau ultérieures de l’ETH2 ont également fini par utiliser la courbe « BLS12-381 ».
Avec le développement d'ETH2, le
BLS12-381utilisé par ETH2 commence à ê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 pourrait être testée conjointement sur le réseau de test ETH2. L'auteur de l'EIP-2537, Alex Stokes, appelle dans l'article What eth2 needs from eth1 over the next six months à inclure l'EIP-2537 dans la hard fork de Berlin.Il est intéressant de noter que l'auteur de l'EIP-2537 est également le cofondateur de Matter Labs, dont le produit le plus célèbre est ZKSync.
Berlin turbulences
Avant de présenter le contenu suivant, nous devons d'abord introduire l'EIP-1962. L'EIP-1962 est la première proposition concernant l'assemblage préliminaire de paires de domaines de courbes elliptiques, proposée par Matter Labs en avril 2019. Cette proposition prend en charge trois courbes, à savoir :
L’EIP est prêt à ajouter 10 instructions de préassemblage à la fois pour traiter différentes courbes. Cependant, après la naissance de la proposition, un nombre important de développeurs se sont interrogés sur le fait que la proposition était trop complexe à mettre en œuvre pour les développeurs. Dans le même temps, en raison de la forte généralisation des EIP1962, il est également très difficile pour les ingénieurs de contrats intelligents d’appeler. Bien sûr, en tant qu’initiateur de l’EIP-1962, Matter Labs a essentiellement achevé le développement de l’algorithme de courbe elliptique et a fourni une implémentation de référence Rust/Go/C++.
Pour résoudre le problème de l'EIP-1962, Matter Labs a proposé plusieurs EIP en février 2020, en scindant l'EIP-1962. Ces EIP héritent 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 vérification des signatures BLS sur la couche de consensus dans le réseau principal. À l'époque, ETH2 développait la conception des contrats de dépôt pour la couche de consensus. Lors de la conception initiale des contrats de dépôt, comme l'algorithme de vérification BLS n'était pas inclus dans la couche d'exécution, le contrat de dépôt ne vérifiait pas les signatures. La signature BLS spécifique serait vérifiée 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 le pré-assemblage BLS12-381 pour réaliser la vérification des signatures dans le contrat de dépôt, afin d'éviter la possibilité de perte 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 EIP-2537 a été proposé pour la première fois, Vitalik a immédiatement identifié une série de problèmes liés à EIP.
Ces questions se concentraient uniquement sur le contenu de la documentation EIP, auquel les auteurs de l'EIP ont ensuite répondu et discuté. Par la suite, le 6 mars 2020, lors de la réunion Ethereum Core Devs Meeting #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 étaient très efficaces pour les preuves SNARK récursives et qu'à long terme, cela ne nuirait pas à Ethereum. En outre, la réunion a également confirmé la priorité de l'EIP-2537, tous les clients s'accordant à 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 d'Ethereum Core #83, l'EIP-2537 a encore été le premier projet discuté. Cette réunion a confirmé que l'EIP-2537 remplace l'EIP-1962 pour devenir la proposition BLS centrale et faire partie de la liste préliminaire des EIP pour la mise à niveau de Berlin (, à savoir l'Éligibilité à l'Inclusion (EFI)).
Lors de la réunion des développeurs principaux d'Ethereum #84 en avril 2020, il a été officiellement 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 convient de noter que lors de cette discussion, l'EIP-2537 a été classé comme une priorité maximale.
Par la suite, l'EIP-2537 est entré dans une phase de développement et de test intensive, et lors des près de 20 réunions des développeurs principaux qui ont suivi, chaque réunion a essentiellement impliqué une discussion sur l'EIP-2537. Ensuite, nous pouvons examiner les questions concernant l'EIP-2537 qui ont été discutées à chaque réunion.
Lors de la réunion des développeurs principaux d'Ethereum #85, Danno et Axic ont discuté des problèmes de codage ABI de l'EIP-2537. Ensuite, les développeurs principaux ont synchronisé l'état actuel des mises en œuvre, où, en raison du fait que le proposant de l'EIP-2537, Matter Labs, avait déjà essentiellement terminé la mise en œuvre de la version Rust, le client Besu a déclaré avoir essentiellement mis en œuvre les fonctionnalités de l'EIP-2537. Cependant, du côté de Geth, il a été indiqué qu'aucune personne ne travaillait actuellement sur la mise en œuvre 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 la mise en œuvre de l'EIP-2537, où Geth a indiqué avoir terminé une partie du travail, mais qu'il reste encore beaucoup à faire.
Lors de la réunion des développeurs d'Ethereum Core #87, le contenu le plus crucial de cette réunion de développeurs est la question de l'implémentation de l'EIP-2537. Les développeurs de Geth ont indiqué qu'il existe actuellement une PR de 16000 lignes pour l'implémentation de l'EIP-2537, mais les développeurs de Geth ne peuvent pas déterminer si la PR est une implémentation sûre et efficace de l'EIP-2537, donc les développeurs ne peuvent que juger l'état du code par le biais de tests flous très simples.
Les développeurs de Geth ont 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 de la mainnet en juillet." Cela signifie que Geth ne pourra probablement 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 réseau de test 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 un contexte, à savoir que l'implémentation PR de l'EIP-2537 de Geth 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 le texte 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 déclaré que le contrat de dépôt qui n'utilise pas l'EIP-2537 avait déjà été audité. Par conséquent, certains développeurs ont proposé 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 estiment déjà que cet EIP a de fortes chances de ne pas être mis en œuvre avant la mise à niveau de Berlin. Il semble que le refus de l'EIP-2537 par la mise à niveau de Berlin soit désormais inévitable.
Lors de la réunion des développeurs principaux d'Ethereum #88, les développeurs de Geth ont découvert une série de problèmes dans la PR d'implémentation de l'EIP-2537, et ils ont indiqué qu'une phase de tests et de corrections supplémentaires était nécessaire. À ce moment-là, il existait 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.
#89内In la réunion des développeurs Ethereum Core, un problème plus grave s’est produit, avec quelques problèmes avec le test YOLO, que les développeurs soupçonnaient d’être causé par la signature BLS, mais les développeurs EIP2537 l’ont réfuté, arguant que le problème du réseau de test 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 essentiellement développé et que le contrat est en attente d’audit contractuel.
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 approche 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 a été confirmé comme étant le EIP nécessaire pour la mise à niveau Berlin.
Lors de la réunion des développeurs principaux d'Ethereum #96, il a été noté que Celo a intégré à la fois l'EIP-2537 et l'EIP-2539 dans sa mise à niveau de hard fork de réseau. Ainsi, Matter Labs souhaite également tester l'EIP-2539, proposé simultanément avec l'EIP-2537, sur le testnet YOLO v2 et l'inclure dans la mise à niveau Berlin. Cependant, les développeurs de Geth s'y opposent, estimant que l'EIP-2537 n'a pas encore été complètement testé en interne dans Geth. La décision finale de la réunion a été de ne pas ajouter le 2696 à la mise à niveau Berlin et de laisser cela pour de futures discussions.
Lors de la réunion des développeurs principaux d'Ethereum #99, il a été décidé de retirer l'EIP-2537 du réseau de test 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 dans 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 de courbes elliptiques plus générale. Cependant, les développeurs principaux ont exprimé des inquiétudes concernant les problèmes de sécurité lors des discussions de la réunion.
Le contenu ci-dessus décrit le parcours précoce de l'EIP-2537. Nous pouvons voir que l'EIP-2537 était l'un des EIP les plus importants lors de la mise à niveau de Berlin, mais en raison de problèmes de mise en œuvre, il a finalement été abandonné. Enfin, en avril 2021, Ethereum a terminé la mise à niveau de Berlin. Les EIP comme l'EIP-2565, qui faisaient partie des éléments centraux de cette mise à niveau, ne sont en réalité pas très complexes. Il semble que la mise à niveau de Berlin soit un peu mince, car l'EIP-2537, qui est le plus complexe, a été écarté de la mise à niveau de Berlin.
Suivi du développement
Comme tout le monde le sait, 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 de transaction la plus importante de l'histoire d'Ethereum, EIP-1559. En ce qui concerne l'EIP-2537, qui était auparavant une proposition clé, il est difficile d'intégrer cette proposition dans les mises à niveau suivantes.
Dans la mise à niveau post-Berlin Londres, les développeurs ont synchronisé le développement actuel de l’EIP-2537 dans l’issues#369曾考虑在 London 升级中增加 EIP-2537。在Ethereum Core Devs Meeting #109, et à ce moment-là, ont introduit une discussion sur l’utilisation du gaz pour l’EIP-2537 en raison de l’utilisation d’autres bibliothèques pour implémenter l’EIP-2537. Dans le même temps, certains développeurs ont proposé de remplacer EIP-2537 par EVM384. Cependant, #111内 la réunion des développeurs d’Ethereum Core en avril 2021, EIP-2537 a été retiré de la mise à niveau de Londres en raison de sa complexité. La complexité fondamentale réside dans le remplacement des bibliothèques dépendantes par la mise en œuvre de la norme EIP-2537, ce qui entraîne des changements possibles dans la tarification du gaz et un temps considérable pour les différentes implémentations clientes pour réévaluer la consommation de gaz.
En juin 2021, la proposition d'inclure l'EIP-2537 dans la mise à niveau de Shanghai a été formellement soumise dans issues#343. Cependant, il convient de noter qu'après la mise à niveau de Londres, la mise à niveau Pairs, également appelée The Merge, a occupé une grande partie du temps des développeurs. Les développeurs de la couche d'exécution devaient écrire beaucoup de code pour réaliser 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 de Shanghai.
En novembre 2022, lors de la réunion des développeurs principaux d'Ethereum #150, il a été brièvement discuté de l'inclusion de l'EIP-2537 dans la mise à niveau de Shanghai, mais les développeurs ont estimé que l'EIP-2537 devait être reporté, la mise à niveau de Shanghai se concentrant sur le soutien aux retraits PoS. Finalement, l'EIP-2537 n'a pas été inclus dans la mise à niveau de Shanghai, qui se concentrait sur la fonctionnalité de retrait.
Ce qui est encore plus tragique, c'est que la mise à niveau de Cancun n'a jamais discuté de l'EIP-2537, car le cœur de la mise à niveau de Cancun est le soutien des nœuds de la couche d'exécution à l'EIP-4844. L'EIP-4844 fournit des Blob pour la couche 2 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, seules quelques questions restaient concernant la tarification de la consommation de Gaz.
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. Jared Wasinger, développeur de Geth, a proposé d'augmenter le coût du gaz de 20 %, avec le soutien des tests de référence de l'équipe Besu.
résumé
| Date | Événement | | --- | --- | | Février 2020 | Proposition officielle de la division EIP-1962 EIP-2537 | | Avril 2020 - Octobre 2020 | Plusieurs réunions de développeurs ont discuté des problèmes de mise en œuvre de l'EIP-2537, qui a finalement été abandonné lors de la mise à niveau Berlin en raison de son impossibilité de mise en œuvre | | Mars 2021 - Avril 2021 | Réunion des développeurs discutant du problème des coûts de gaz de l'EIP-2537, finalement abandonné lors de la mise à niveau de Londres en raison de sa complexité | | Novembre 2022 | La réunion des développeurs discute de l'inclusion de la mise à niveau Shanghai, sans succès | | Février 2024 | Les développeurs estiment qu'il n'y a pas de problème d'implémentation avec l'EIP-2537, mais qu'il existe encore des problèmes de coût en gas, et pensent qu'il pourrait être inclus dans la mise à niveau Pectra | | Décembre 2024 - Janvier 2025 | Réunion des développeurs pour discuter du modèle de calcul des coûts spécifique, résolution officielle du problème de coût de l'EIP-2537 |
On peut voir que l’inclusion de l’EIP dans la mise à niveau d’Ethereum, « bien sûr, dépend de l’auto-lutte, mais 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.