EIP-2537: Un long parcours de 2020 à 2025

EIP-2537 est une instruction précompilée EVM ajoutée lors de la dernière mise à niveau du fork Pectra d'Ethereum. Cette instruction ajoute diverses fonctionnalités de calcul pour la courbe BLS12-381 à l'EVM, telles que le calcul de paires sur le domaine de la courbe.

EIP-2537 a été proposé pour la première fois en 2020 et n'a été confirmé pour être inclus dans la mise à niveau d'Ethereum qu'en 2025. Cet article présentera le parcours de gouvernance d'EIP-2537 et explorera pourquoi cette proposition a finalement été adoptée après 5 ans.

Contexte de la proposition

En janvier 2017, Vitalik Buterin a introduit pour la première fois l'algorithme de couplage et la courbe alt_bn128 dans un article. Puis en février, Vitalik et Christian Reitwiessner ont proposé l'EIP-196 et l'EIP-197, suggérant d'ajouter le support du calcul de la courbe alt_bn128 à l'EVM.

La mise à niveau Byzantium d'octobre 2017 a officiellement intégré la courbe alt_bn128, permettant le calcul des paires de courbes dans l'EVM, ce qui permet la vérification des preuves ZK-Snarks d'être effectuée à l'intérieur de l'EVM.

Mais avec le développement de la cryptographie, en novembre 2017, l'équipe zcash a proposé la courbe BLS12-381, qui offre une sécurité supérieure et de meilleures performances par rapport à alt_bn128. De nombreux protocoles blockchain ont ensuite adopté la courbe BLS12-381 en remplacement d'alt_bn128.

En mai 2018, Justin Drake a publié un article indiquant que les futures mises à niveau PoS et de sharding d'Ethereum pourraient utiliser l'algorithme de signature multi-signature BLS basé sur BLS12-381. Cela a jeté les bases de la mise à niveau ETH2 ultérieure.

Avec le développement d'ETH2, la demande d'introduire BLS12-381 dans la couche d'exécution se fait de plus en plus entendre. En février 2020, des chercheurs ont proposé l'EIP-2537, espérant le tester avec le réseau de test ETH2. L'auteur de l'EIP-2537, Alex Stokes, a appelé à son inclusion dans le hard fork Berlin.

Il convient de mentionner 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 agité

Avant d'introduire le contenu suivant, il est nécessaire de comprendre l'EIP-1962. Il s'agit de la première proposition de précompilation pour les paires de domaines de courbes elliptiques proposée par Matter Labs en avril 2019, qui prend en charge trois types de courbes : BLS12, BN et MNT4/6.

Le plan EIP-1962 vise à ajouter 10 instructions précompilées pour traiter différentes courbes en une seule fois. Cependant, de nombreux développeurs estiment que c'est trop complexe à mettre en œuvre et peu convivial pour les ingénieurs en contrats intelligents. Cependant, Matter Labs a terminé le développement de l'algorithme et fournit des références multilingues.

Pour résoudre le problème EIP-1962, Matter Labs a proposé plusieurs solutions de découpage EIP en février 2020 :

• EIP-2537 fournit un support pour BLS12-381
• EIP-2539 fournit un support pour BLS12-377
• PR#2541 fournit un support pour la courbe BLS12-377(Zexe), mais n'a pas obtenu de numéro EIP.

Parmi eux, l'EIP-2537 est le plus important, car la couche de consensus utilise également la courbe BLS12-381. Les objectifs principaux de l'EIP-1962 et de l'EIP-2537 sont tous deux de réaliser la vérification des signatures BLS sur le réseau principal.

À l'époque, ETH2 était en train de développer un contrat de dépôt. En raison de l'absence de validation BLS au niveau d'exécution, le contrat de dépôt dans la conception originale ne vérifiait pas les signatures, mais était validé par le niveau de consensus. Si cela était incorrect, le dépôt échouait, entraînant une perte de fonds.

Ainsi, les développeurs principaux souhaitent introduire le précompilé BLS12-381 pour vérifier les signatures dans le contrat de dépôt afin d'éviter les risques financiers. C'est également la raison pour laquelle les développeurs se sont intéressés à 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 du document. L'auteur a ensuite répondu et discuté.

La réunion des développeurs principaux du 6 mars 2020 a discuté de l'EIP-2537. Vitalik a estimé qu'il est très efficace pour les preuves SNARK récursives et qu'à long terme, cela ne nuira pas à Ethereum. La réunion a confirmé la priorité de l'EIP-2537, tous les clients ont convenu de le mettre en œuvre dès que possible et de terminer le développement avant la mise à niveau de Berlin.

Ensuite, l'EIP-2537 est devenu une tâche de haute priorité. La réunion du 20 mars a de nouveau discuté en priorité de cette proposition, confirmant qu'elle remplace l'EIP-1962 en tant que proposition BLS principale et qu'elle est incluse dans la liste préliminaire de mise à niveau de Berlin.

La réunion d'avril 84 a officiellement intégré l'EIP-2537 dans le hard fork Berlin, établissant un calendrier pour sa mise en œuvre en avril et des tests en mai-juin. L'EIP-2537 a été classé comme une priorité absolue.

Depuis lors, l'EIP-2537 est entré dans une phase de développement et de test intensifs, et presque chaque réunion des développeurs principaux, qui a eu lieu près de 20 fois par la suite, a comporté des discussions pertinentes.

La réunion 85 a discuté des problèmes d'encodage ABI. Étant donné que Matter Labs a essentiellement terminé l'implémentation en Rust, le client Besu a déclaré avoir essentiellement mis en œuvre la fonctionnalité EIP-2537, mais Geth a déclaré qu'il n'avait pas encore commencé les travaux d'implémentation.

La réunion 86 a de nouveau synchronisé la situation de mise en œuvre de chaque nœud. Geth a déclaré avoir terminé une partie du travail mais qu'il reste encore de nombreuses tâches à accomplir.

Le contenu central de la réunion 87 concerne les problèmes de mise en œuvre de l'EIP-2537. Les développeurs de Geth ont indiqué qu'il existe un PR de 16000 lignes pour mettre en œuvre l'EIP-2537, mais il est impossible de déterminer s'il est sûr et efficace, et il ne peut être évalué que par des tests de flou simples. Geth pense qu'il est très probable qu'il ne pourra pas terminer le développement connexe avant la date prévue à Berlin.

Hudson Jameson a proposé de trouver des ingénieurs en cryptographie pour aider à la révision des PR de Geth et a suggéré de tester la sécurité sur le réseau de test. L'équipe ETH2 pourrait également participer aux tests.

Il convient de noter que la PR de mise en œuvre de l'EIP-2537 de Geth utilise de manière intensive du code assembleur pour garantir l'efficacité, ce qui rend la lecture et la compréhension difficiles. Alex Vlasov a suggéré de supprimer les optimisations d'assembleur complexes afin de réduire la difficulté de la révision.

Bien que l'un des objectifs principaux de l'EIP-2537 soit d'assister le contrat de dépôt ETH2, les développeurs du contrat de dépôt présents à cette réunion ont déclaré qu'ils n'utiliseraient pas la version de l'EIP-2537 qui a été auditée, et certains développeurs ont suggéré de ne pas lancer de nouvelle version utilisant l'EIP-2537.

La dernière réunion a décidé d'augmenter le test du réseau YOLO spécifiquement pour tester l'EIP-2537. À ce moment-là, il est clair qu'avec l'achèvement du contrat de dépôt, l'importance de l'EIP-2537 a considérablement diminué, et les développeurs de Geth estiment qu'il est très probable qu'il ne soit pas réalisé avant la mise à niveau de Berlin. Il semble que l'EIP-2537 ne soit pas inclus dans Berlin.

Lors de la réunion 88, les développeurs de Geth ont découvert que l'implémentation de la PR EIP-2537 présente une série de problèmes, indiquant qu'il est nécessaire de procéder à des tests supplémentaires pour les corriger. À ce moment-là, Geth avait deux versions d'implémentation, l'une contenant des optimisations d'assemblage et l'autre entièrement écrite en Go. Certains ont suggéré d'utiliser directement la version Go pour réduire la difficulté de la révision du code.

La réunion 89 a rencontré des problèmes plus graves, le réseau de test YOLO a présenté des anomalies, soupçonnant que cela soit dû à la signature BLS, mais les développeurs de l'EIP-2537 ont réfuté cela. La bonne nouvelle est que le contrat de dépôt basé sur l'EIP-2537 est presque terminé, il attend maintenant l'audit.

La réunion 90 a fixé le délai de lancement de la mise à niveau Berlin en juillet. La réunion a également discuté de la diversité des clients, certains ont proposé de geler l'implémentation actuelle de l'EIP pour réduire les coûts de développement d'autres clients. La réunion 91 a même suggéré d'utiliser une solution modulaire pour accroître la diversité des clients.

La réunion 92 a de nouveau confirmé que l'EIP-2537 est l'EIP nécessaire pour la mise à niveau de Berlin.

La réunion 96 a discuté de la possibilité d'inclure l'EIP-2539 dans le test de Berlin, car Celo a déjà intégré l'EIP-2537 et l'EIP-2539 dans sa mise à niveau réseau. Cependant, les développeurs de Geth s'y sont opposés, estimant que l'EIP-2537 n'était pas encore complètement testé. La décision finale a été de ne pas ajouter l'EIP-2696 à Berlin.

La réunion 99 a décidé de retirer l'EIP-2537 du réseau de test YOLO v3 et de la mise à niveau Berlin, la principale raison étant qu'il a consommé trop de temps des développeurs, impactant le développement d'autres EIP. Un facteur secondaire est que la fondation Ethereum a proposé l'EVM384 comme alternative. Cependant, les développeurs expriment des préoccupations quant à sa sécurité.

Voici le parcours précoce de l'EIP-2537. C'était l'un des EIP les plus importants de la mise à niveau Berlin, mais a finalement été abandonné en raison de problèmes de mise en œuvre. En avril 2021, Ethereum a terminé la mise à niveau Berlin, avec des EIP centraux tels que l'EIP-2565 dont la mise en œuvre était relativement simple, paraissant un peu maigre, justement parce que l'EIP-2537, le plus complexe, a été écarté.

Développements futurs

Comme tout le monde le sait, chaque mise à niveau d'Ethereum s'accompagne de propositions clés, comme Londres après Berlin qui a introduit l'EIP-1559. En ce qui concerne l'EIP-2537, qui était une proposition clé, il est difficile de l'intégrer dans les mises à niveau suivantes.

Lors de la mise à niveau de Londres, les développeurs avaient envisagé d'ajouter l'EIP-2537. La réunion 109 a synchronisé son état de développement, car l'utilisation de la nouvelle bibliothèque a suscité des discussions sur le gaz. Certaines personnes ont proposé de remplacer par l'EVM384. Cependant, la réunion 111 a décidé de le retirer de la mise à niveau de Londres en raison de sa complexité, principalement à cause du changement de bibliothèque entraînant des variations dans la tarification du gaz, ce qui nécessite une réévaluation.

En juin 2021, il a été officiellement proposé d'intégrer l'EIP-2537 dans la mise à niveau de Shanghai. Cependant, après Londres, The Merge a occupé beaucoup de temps des développeurs. Ce n'est qu'en septembre 2022, après l'achèvement de The Merge, que les développeurs de la couche d'exécution ont eu l'occasion de continuer à discuter des objectifs de Shanghai.

La réunion de novembre 2022 a brièvement discuté de l'inclusion de Shanghai, mais les développeurs ont estimé qu'il fallait retarder, le cœur de Shanghai étant de soutenir les retraits PoS. Finalement, l'EIP-2537 n'a pas été inclus dans la mise à niveau de Shanghai axée sur les retraits.

Pire encore, la mise à niveau de Cancun n'a toujours pas discuté de l'EIP-2537, car son cœur est de soutenir l'EIP-4844, afin de fournir la disponibilité des données Blob pour la couche 2.

Enfin, lors de la réunion 181 de février 2024, la mise à niveau de Pectra a inclus l'EIP-2537, les développeurs estiment que la mise en œuvre n'est plus un problème, il n'y a qu'un problème de tarification du gaz.

La réunion du 19 décembre 2024, 202, les développeurs de Nethermind ont finalement finalisé le modèle de tarification EIP-2537. L'auteur de la proposition originale, Matter Labs, a presque quitté la discussion à ce moment-là. La réunion 203 de janvier 2025 a discuté de la re-tarification, les développeurs de Geth ont suggéré d'augmenter les coûts de gaz de 20 %, ce qui a été soutenu par l'équipe de Besu.

Résumé

EIP-2537 a mis 5 ans à être adopté depuis sa proposition. Il était au cœur de la mise à niveau Berlin, mais a été abandonné en raison de sa difficulté de mise en œuvre. Par la suite, Ethereum est entré dans l'histoire du PoS, et les EIP complexes de la couche d'exécution pure n'ont pas été pris en compte, tandis qu'un grand nombre d'EIP liés au PoS sont devenus des objectifs centraux, ce qui a conduit à ce qu'EIP-2537 ne soit pas accepté pendant longtemps. Ce n'est qu'en 2025, avec la résolution des principaux problèmes techniques, qu'EIP-2537 a enfin la possibilité d'être réalisé lors de la mise à niveau Pectra.

Ce parcours montre que l'intégration des EIP dans les mises à niveau d'Ethereum dépend non seulement de leur valeur technique, mais aussi des phases de développement et des priorités globales d'Ethereum. Chaque mise à niveau a son propre thème, et seules les EIP qui répondent aux besoins actuels et qui sont techniquement matures peuvent finalement être adoptées.