EIP-2537: Réflexion sur le processus de gouvernance d'Ethereum
EIP-2537 est une instruction précompilée EVM qui a été déterminée pour être ajoutée lors de la dernière mise à niveau de bifurcation Pectra d'Ethereum. Cette instruction ajoute plusieurs fonctionnalités de calcul de la courbe BLS12-381 à l'EVM, y compris 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 l'historique de la gouvernance d'EIP-2537 et explorera 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 un article. Par la suite, 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 de Byzantium en octobre 2017 a officiellement intégré la courbe alt_bn128, réalisant le calcul de couplage de domaine de courbe à l'intérieur de l'EVM, permettant ainsi la vérification des preuves ZK-Snarks d'être effectuée au sein de l'EVM.
En novembre 2017, l'équipe de zcash a proposé la courbe BLS12-381, qui offre une sécurité et des performances supérieures par rapport à alt_bn128. De nombreux protocoles blockchain ont ensuite adopté la courbe BLS12-381. 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 multi-signature BLS basé sur BLS12-381.
Avec le développement d'Ethereum 2, la demande d'introduire BLS12-381 dans la couche d'exécution d'Ethereum monte. En février 2020, des chercheurs ont proposé l'EIP-2537, espérant le tester en synchronisation avec le réseau de test d'Ethereum 2. 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 l'un des cofondateurs de l'équipe de développement ZKSync, Matter Labs.
Les turbulences de la mise à niveau de Berlin
Avant de discuter de l'EIP-2537, il est nécessaire de comprendre l'EIP-1962. Il s'agit de la première proposition de précompilation pour l'appariement de courbes elliptiques, proposée par Matter Labs en avril 2019, qui prend en charge trois courbes : BLS12, BN et MNT4/6, avec l'intention d'ajouter 10 instructions précompilées en une seule fois. Cependant, cette proposition a été jugée trop complexe pour être mise en œuvre.
Pour résoudre le problème EIP-1962, Matter Labs a proposé en février 2020 plusieurs solutions de découpage des EIP, dont la plus importante est l'EIP-2537, qui fournit un support pour BLS12-381. À l'époque, ETH2 était en train de développer un contrat de dépôt, et l'introduction de la précompilation BLS12-381 permettrait de vérifier les signatures dans le contrat de dépôt, évitant ainsi le risque de perte de fonds pour les utilisateurs.
Lorsque l'EIP-2537 a été proposé pour la première fois, Vitalik a souligné certains problèmes. Par la suite, lors de la réunion des développeurs principaux du 6 mars, Vitalik a estimé que l'EIP-2537 est très efficace 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 ont convenu de le mettre en œuvre dès que possible et prévoient de terminer le développement avant la mise à niveau de Berlin.
Lors des réunions suivantes, l'EIP-2537 a remplacé l'EIP-1962 en tant que proposition BLS centrale et a été inclus dans la liste préliminaire de mise à niveau de Berlin. La réunion d'avril a officiellement intégré l'EIP-2537 dans le hard fork de Berlin et a établi le calendrier de mise en œuvre.
Par la suite, l'EIP-2537 est entré dans une phase de développement et de test intensifs, avec des discussions pertinentes lors d'environ 20 réunions de développeurs principaux. Les principaux sujets de discussion portaient sur le codage ABI, l'avancement de la mise en œuvre, la sécurité, etc.
Cependant, avec l'avancement du développement, les problèmes d'EIP-2537 se font progressivement sentir. L'équipe Geth a déclaré qu'il était difficile de terminer le développement dans les délais prévus, tandis que le contrat de dépôt a été terminé dans une version ne utilisant pas EIP-2537. L'importance d'EIP-2537 a donc diminué.
Lors des réunions suivantes, les problèmes de mise en œuvre et de test de l'EIP-2537 persistent. Finalement, lors de la 99e réunion des développeurs principaux, il a été décidé de retirer l'EIP-2537 de la mise à niveau Berlin, principalement parce que cela a consommé trop de ressources de développement, affectant les progrès des autres EIP.
Développement ultérieur
Lors de la mise à niveau de Londres après la mise à niveau de Berlin, les développeurs avaient envisagé d'inclure l'EIP-2537, mais cela a été abandonné à nouveau en raison de sa complexité. La mise à niveau de Shanghai n'a également pas inclus l'EIP-2537, car l'accent était mis sur la mise en œuvre des fonctionnalités de retrait PoS.
La mise à niveau de Cancun n'a pas non plus discuté de l'EIP-2537, car l'accent est mis sur le soutien à l'EIP-4844.
Jusqu'en février 2024, les développeurs ont de nouveau discuté de l'inclusion de l'EIP-2537 dans la mise à niveau Pectra. À ce moment-là, la mise en œuvre de l'EIP-2537 n'était plus un problème majeur, il ne restait que quelques problèmes de tarification de la consommation de gaz.
De décembre 2024 à janvier 2025, la conférence des développeurs a finalisé le modèle de tarification de l'EIP-2537, résolvant ainsi le problème des coûts. Matter Labs, en tant que premier proposeur, s'est déjà retiré des discussions à ce stade.
Résumé
Le parcours de l'EIP-2537 reflète la complexité du processus de gouvernance d'Ethereum. Passant d'un contenu considéré comme une mise à niveau essentielle à plusieurs reprises mis de côté en raison de la difficulté et de la complexité de sa mise en œuvre, jusqu'à finalement être intégré dans la mise à niveau, l'EIP-2537 a traversé un long processus. Ce parcours met en lumière les considérations et les compromis d'Ethereum en matière de développement technologique, de consensus atteint et de choix de priorités.
Chaque mise à niveau d'Ethereum a un thème et un objectif spécifiques. L'inclusion d'un EIP dépend non seulement de sa valeur intrinsèque, mais aussi de l'étape de développement actuelle d'Ethereum et des priorités. Le parcours de l'EIP-2537 montre la flexibilité de la gouvernance d'Ethereum, ainsi que l'attitude prudente de la communauté face aux défis techniques.
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.
5 J'aime
Récompense
5
3
Reposter
Partager
Commentaire
0/400
FortuneTeller42
· Il y a 20h
Ah, cinq ans, ce n'est pas encore le bon moment pour monter.
Voir l'originalRépondre0
InscriptionGriller
· Il y a 20h
Avec une telle intensité de compétition, cela fait cinq ans que nous faisons réchauffer un plat froid.
Voir l'originalRépondre0
SchrodingerAirdrop
· Il y a 20h
Après cinq ans de travail acharné, Vitalik Buterin continue de persévérer.
EIP-2537 : Cinq ans de gouvernance – Un aperçu des décisions de mise à niveau d'Ethereum
EIP-2537: Réflexion sur le processus de gouvernance d'Ethereum
EIP-2537 est une instruction précompilée EVM qui a été déterminée pour être ajoutée lors de la dernière mise à niveau de bifurcation Pectra d'Ethereum. Cette instruction ajoute plusieurs fonctionnalités de calcul de la courbe BLS12-381 à l'EVM, y compris 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 l'historique de la gouvernance d'EIP-2537 et explorera 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 un article. Par la suite, 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 de Byzantium en octobre 2017 a officiellement intégré la courbe alt_bn128, réalisant le calcul de couplage de domaine de courbe à l'intérieur de l'EVM, permettant ainsi la vérification des preuves ZK-Snarks d'être effectuée au sein de l'EVM.
En novembre 2017, l'équipe de zcash a proposé la courbe BLS12-381, qui offre une sécurité et des performances supérieures par rapport à alt_bn128. De nombreux protocoles blockchain ont ensuite adopté la courbe BLS12-381. 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 multi-signature BLS basé sur BLS12-381.
Avec le développement d'Ethereum 2, la demande d'introduire BLS12-381 dans la couche d'exécution d'Ethereum monte. En février 2020, des chercheurs ont proposé l'EIP-2537, espérant le tester en synchronisation avec le réseau de test d'Ethereum 2. 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 l'un des cofondateurs de l'équipe de développement ZKSync, Matter Labs.
Les turbulences de la mise à niveau de Berlin
Avant de discuter de l'EIP-2537, il est nécessaire de comprendre l'EIP-1962. Il s'agit de la première proposition de précompilation pour l'appariement de courbes elliptiques, proposée par Matter Labs en avril 2019, qui prend en charge trois courbes : BLS12, BN et MNT4/6, avec l'intention d'ajouter 10 instructions précompilées en une seule fois. Cependant, cette proposition a été jugée trop complexe pour être mise en œuvre.
Pour résoudre le problème EIP-1962, Matter Labs a proposé en février 2020 plusieurs solutions de découpage des EIP, dont la plus importante est l'EIP-2537, qui fournit un support pour BLS12-381. À l'époque, ETH2 était en train de développer un contrat de dépôt, et l'introduction de la précompilation BLS12-381 permettrait de vérifier les signatures dans le contrat de dépôt, évitant ainsi le risque de perte de fonds pour les utilisateurs.
Lorsque l'EIP-2537 a été proposé pour la première fois, Vitalik a souligné certains problèmes. Par la suite, lors de la réunion des développeurs principaux du 6 mars, Vitalik a estimé que l'EIP-2537 est très efficace 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 ont convenu de le mettre en œuvre dès que possible et prévoient de terminer le développement avant la mise à niveau de Berlin.
Lors des réunions suivantes, l'EIP-2537 a remplacé l'EIP-1962 en tant que proposition BLS centrale et a été inclus dans la liste préliminaire de mise à niveau de Berlin. La réunion d'avril a officiellement intégré l'EIP-2537 dans le hard fork de Berlin et a établi le calendrier de mise en œuvre.
Par la suite, l'EIP-2537 est entré dans une phase de développement et de test intensifs, avec des discussions pertinentes lors d'environ 20 réunions de développeurs principaux. Les principaux sujets de discussion portaient sur le codage ABI, l'avancement de la mise en œuvre, la sécurité, etc.
Cependant, avec l'avancement du développement, les problèmes d'EIP-2537 se font progressivement sentir. L'équipe Geth a déclaré qu'il était difficile de terminer le développement dans les délais prévus, tandis que le contrat de dépôt a été terminé dans une version ne utilisant pas EIP-2537. L'importance d'EIP-2537 a donc diminué.
Lors des réunions suivantes, les problèmes de mise en œuvre et de test de l'EIP-2537 persistent. Finalement, lors de la 99e réunion des développeurs principaux, il a été décidé de retirer l'EIP-2537 de la mise à niveau Berlin, principalement parce que cela a consommé trop de ressources de développement, affectant les progrès des autres EIP.
Développement ultérieur
Lors de la mise à niveau de Londres après la mise à niveau de Berlin, les développeurs avaient envisagé d'inclure l'EIP-2537, mais cela a été abandonné à nouveau en raison de sa complexité. La mise à niveau de Shanghai n'a également pas inclus l'EIP-2537, car l'accent était mis sur la mise en œuvre des fonctionnalités de retrait PoS.
La mise à niveau de Cancun n'a pas non plus discuté de l'EIP-2537, car l'accent est mis sur le soutien à l'EIP-4844.
Jusqu'en février 2024, les développeurs ont de nouveau discuté de l'inclusion de l'EIP-2537 dans la mise à niveau Pectra. À ce moment-là, la mise en œuvre de l'EIP-2537 n'était plus un problème majeur, il ne restait que quelques problèmes de tarification de la consommation de gaz.
De décembre 2024 à janvier 2025, la conférence des développeurs a finalisé le modèle de tarification de l'EIP-2537, résolvant ainsi le problème des coûts. Matter Labs, en tant que premier proposeur, s'est déjà retiré des discussions à ce stade.
Résumé
Le parcours de l'EIP-2537 reflète la complexité du processus de gouvernance d'Ethereum. Passant d'un contenu considéré comme une mise à niveau essentielle à plusieurs reprises mis de côté en raison de la difficulté et de la complexité de sa mise en œuvre, jusqu'à finalement être intégré dans la mise à niveau, l'EIP-2537 a traversé un long processus. Ce parcours met en lumière les considérations et les compromis d'Ethereum en matière de développement technologique, de consensus atteint et de choix de priorités.
Chaque mise à niveau d'Ethereum a un thème et un objectif spécifiques. L'inclusion d'un EIP dépend non seulement de sa valeur intrinsèque, mais aussi de l'étape de développement actuelle d'Ethereum et des priorités. Le parcours de l'EIP-2537 montre la flexibilité de la gouvernance d'Ethereum, ainsi que l'attitude prudente de la communauté face aux défis techniques.