Vitalik et Yoav a gentiment relu cet article, mais les opinions sont les miennes.

Si vous n’avez pas suivi le drame des AA, voici un bref récapitulatif :

• Il y a plusieurs semaines, EIP-3074, une proposition qui apporterait de nombreux avantages d’AA aux utilisateurs d’EOA, a été approuvée par les développeurs principaux pour entrer dans « Pectra », le prochain hard fork d’Ethereum.
• Depuis lors, de nombreux membres de la communauté ERC-4337, en particulier les auteurs du 4337 eux-mêmes, ont été fortement repoussés le 3074, au motif de @yoav/3074-implications">centralisation et son incompatibilité avec le @yoav/AA-roadmap-May-2024">AA roadmap, qui est centrée autour de 4337 et de son cousin 7560 (alias « native AA »).
• La semaine dernière, Vitalik a proposé EIP-7702 comme alternative à 3074. Il atteint principalement le même objectif - apportant de nombreux avantages de l’AA aux utilisateurs d’EOA - mais d’une manière plus compatible avec 4337 aujourd’hui, et compatible avec la « fin de partie AA » qu’est 7560.
• À l’heure actuelle, les développeurs principaux délibèrent sur EIP-7702, mais les discussions préliminaires et les sentiments de la communauté suggèrent que EIP-7702 remplacera très probablement EIP-3074 dans Pectra.

Personnellement, j’ai été très satisfait du résultat : les utilisateurs d’EOA pourront bientôt profiter de la plupart des avantages de l’AA, en utilisant l’outillage et l’infrastructure conçus pour l’ERC-4337.

Et pourtant, je ne peux m’empêcher de penser que la manière dont nous sommes parvenus à ce résultat était loin d’être optimale, un point de vue que beaucoup avaient exprimé au cours des dernières semaines. J’ai l’impression qu’avec un meilleur processus, nous aurions pu collectivement économiser énormément d’énergie et de maux de tête, et arriver au résultat souhaité beaucoup plus tôt.

Dans cet article de blog, je souhaite :

• Identifiez ce qui n’a pas fonctionné dans le processus.
• Proposer un modèle mental pour penser à la gouvernance d’Ethereum.
• Suggérez des améliorations pour éviter des défaillances de gouvernance similaires à l’avenir.

Pourquoi le processus a rendu les gens malheureux

Toute cette saga a rendu beaucoup de gens malheureux pour plusieurs raisons :

• Il a fallu des années pour que le projet de loi 3074 soit approuvé.
• Ce n’est qu’après l’approbation de la version 3074 que les développeurs principaux ont reçu une tonne de réactions négatives de la part de la communauté 4337.
  • Les auteurs de 4337 eux-mêmes, d’autre part, avaient exprimé à plusieurs reprises leurs préoccupations concernant 3074 aux développeurs principaux, en vain.
• Maintenant, nous sommes sur la bonne voie pour annuler l’approbation 3074 et le remplacer par un autre EIP (7702).

Maintenant, il n’y a rien de mal en soi avec tout ce qui précède :

• Il n’y a pas de mal à ce qu’une discussion prenne des années.
• Il est normal qu’un EIP reçoive des refoulements après son approbation.
• Vous pouvez annuler l’approbation d’un EIP une fois qu’il a été approuvé, si de nouveaux problèmes sont identifiés.

Cependant, nous pouvons probablement convenir que les choses auraient pu se passer plus facilement. Imaginez si c’est comme ça que ça s’est passé :

• La communauté 4337 a activement engagé les développeurs principaux alors qu’ils débattaient de 3074. Désormais, un seul des deux résultats suivants est possible :
  • Soit 3074 a été approuvé (et éventuellement modifié) après avoir pris en compte les commentaires de la communauté 4337, auquel cas la communauté 4337 aurait été d’accord avec 3074 et nous n’aurions pas inversé 3074.
  • Ou bien, 3074 n’a jamais été approuvé, mais la communauté 4337 et les développeurs principaux ont travaillé ensemble sur une proposition qui satisfait tout le monde, à la 7702.

La voix de chacun est entendue, et il n’y a pas de renversements spectaculaires. Cela aurait été bien, alors pourquoi cela ne s’est-il pas produit ?

le processus All Core Devs (ACD), où les EIP sont délibérés pendant un temps long avant d’être finalement acceptés par les équipes clientes, et donc implémentés dans le protocole. À n’importe quel moment au cours de cette délibération, l’argument est que les « 4337 personnes » auraient pu venir et exprimer leurs préoccupations, au lieu d’attendre que la résolution 3074 ait déjà été approuvée. Après tout, le processus de l’ACD est bien documenté, les réunions sont ouvertes à tous, et il y a des gens comme Tim Beiko qui tweetent activement des résumés après chaque réunion de l’ACD. Donc, si les 4337 personnes se souciaient tant de cette question, pourquoi n’ont-elles pas pris le temps de s’engager ? De l’autre côté, l’équipe AA (4337 auteurs) a souligné qu’ils avaient assisté à des réunions de l’ACD et qu’ils avaient repoussé 3074 chaque fois qu’ils le pouvaient, mais les développeurs principaux n’ont pas écouté. En ce qui concerne la communauté 4337, ils se sont surtout sentis pris au dépourvu – la plupart des gens avaient l’impression que 3074 était mort, et n’étaient même pas au courant que 3074 était activement envisagé pour l’inclusion. De nombreuses personnes ont également estimé que le processus de l’ACD était trop opaque et peu convivial pour les participations de personnes qui ont de « vrais emplois » et qui n’avaient pas les moyens de suivre toutes les mises à jour de l’ACD. Certains ont également estimé qu’il devrait être de la responsabilité de l’ACD de solliciter activement les commentaires des parties prenantes concernées, dans ce cas-ci la communauté 4337. Je suis d’avis, cependant, que les deux parties ont raté la cible. Il y a un problème beaucoup plus profond à l’œuvre, et tant que nous n’aurons pas résolu le problème ou, à tout le moins, que nous ne le reconnaîtrons pas, nous continuerons à nous heurter à des échecs de gouvernance suivis de pointages du doigt improductifs. La cause première

La véritable cause de l’échec de la gouvernance était que, contrairement aux croyances populaires, l’ACD n’est PAS le seul pouvoir de gouvernance pour protocole mises à jour, et dans ce cas, il a été remplacé par un autre pouvoir de gouvernance.

Problème, l’autre pouvoir de gouvernance est rarement reconnu, malgré le fait qu’il a une influence encore plus grande que l’ACD sur les questions les plus importantes d’Ethereum, telles que l’AA et la mise à l’échelle.

Dans cet article, je vais appeler ce pouvoir des « feuilles de route ».

Toute cette saga 3074/7702, comme je le soutiendrai, n’est ni plus ni moins qu’un exemple de la puissance des feuilles de route écrasant la puissance de l’ACD. Et si nous parlons de gouvernance, alors chaque fois que nous remarquons qu’une puissance invisible submerge une puissance visible, nous devrions être très inquiets, car ce qui est invisible n’a pas de comptes à rendre, et doit donc être mis en lumière.

@yoav/AA-roadmap-May-2024">la feuille de route AA ».

Étant donné que les feuilles de route ne font pas partie intégrante de la gouvernance, il n’y a aucune garantie que les développeurs principaux soient alignés sur elles. En particulier, comme il n’existe pas de processus formel pour « approuver » une feuille de route, toutes les feuilles de route ne sont pas perçues comme ayant la même légitimité. C’est aux chercheurs derrière les feuilles de route de défendre avec diligence leurs feuilles de route auprès des développeurs principaux et de la communauté au sens large, dans l’ordre de gagner en légitimité et donc d’obtenir l’adhésion des développeurs principaux.

Dans le cas d’AA, Vitalik lui-même a fait pression pour une feuille de route AA centrée sur 4337 à @vbuterin/compte_abstraction_roadmap">multiple , mais dans l’ensemble, c’est surtout l’équipe 4337, notamment Yoav et Dror, qui défend la feuille de route AA centrée sur 4337 lors de conférences, de forums en ligne et de réunions ACD.

Cependant, malgré ces efforts, il y a eu de fortes oppositions de la part de certains développeurs principaux contre la feuille de route AA centrée sur 4337. Ils ont estimé que 7560, la version native de 4337 que les clients devraient éventuellement mettre en œuvre, est trop complexe et n’est pas le seul candidat viable pour la « fin de partie AA ». Finalement, l’ACD a décidé d’approuver 3074 malgré les objections de l’équipe 4337 selon lesquelles il fragmenterait l’écosystème AA en créant une pile technologique AA alternative et @yoav/3074-implications">moins décentralisée

Cependant, une fois que la version 3074 a été approuvée, il y a eu une forte réaction de l’ensemble de la communauté 4337, ce qui a forcé les développeurs principaux à se réengager dans le débat sur la version 3074. Le débat est devenu une impasse où ni les 4337 auteurs ni les 3074 auteurs n’ont pu se convaincre les uns les autres, jusqu’à ce que Vitalik arrive à la onzième heure et propose EIP-7702 comme une alternative à 3074 qui est explicitement compatible avec la « fin de partie AA » centrée sur 4337, poussant ainsi le conflit en faveur de la feuille de route AA.

Le rôle de Vitalik

Même si Vitalik se comporte comme un chercheur, cette saga montre clairement que Vitalik apporte un pouvoir de gouvernance qualitativement différent de celui des autres chercheurs. Cela soulève donc la question : quel rôle joue Vitalik dans la gouvernance d’Ethereum ?

Personnellement, je trouve utile de considérer Vitalik comme le CTO d’une très, très grande entreprise.

(Pour les besoins de cette analogie, il n’y a pas de PDG dans cette entreprise, soit dit en passant.)

Si vous avez travaillé dans une entreprise technologique de plus de 50 personnes, vous savez que le CTO ne peut pas être impliqué dans toutes les décisions techniques. À une certaine échelle, les décisions techniques deviennent nécessairement décentralisées – il y a généralement une sous-équipe pour chaque domaine du produit de l’entreprise, et la sous-équipe est généralement libre de prendre ses propres décisions concernant des détails de mise en œuvre spécifiques.

En outre, le CTO n’est pas nécessairement le plus grand expert dans tous les domaines (ou n’importe quel domaine). Il pourrait très bien y avoir des ingénieurs dans une entreprise qui sont meilleurs que le CTO dans des domaines spécifiques. Par conséquent, en matière de débats techniques, ce sont souvent les ingénieurs qui prennent les décisions finales.

Le CTO, quant à lui, définit la vision technique de l’entreprise. L’exécution de la vision est laissée aux développeurs.

Bien qu’il ne s’agisse pas d’une analogie parfaite, je pense qu’elle rend raisonnablement compte du rôle de Vitalik dans l’écosystème. Vitalik n’est pas impliqué dans toutes les décisions techniques, il ne peut pas l’être. Il n’est pas non plus le meilleur expert dans tous les domaines. Mais il a une influence écrasante sur l’établissement des feuilles de route pour tous les aspects critiques d’Ethereum (mise à l’échelle, AA, Proof-of-Stake...), non seulement en raison de son expertise technique, mais aussi parce qu’il est le juge ultime pour savoir si une feuille de route est cohérente avec la vision d’Ethereum – sa vision.

Chaque produit réussi commence par une vision

Si mon point de vue selon lequel Vitalik est le CTO de Ethereum n’est pas assez controversé pour vous, voici la partie la plus controversée : nous devrions adopter Vitalik comme CTO.

C’est mon opinion en tant que fondateur de startup que derrière chaque produit réussi – et oui, Ethereum est un « produit » dans le sens où il résout de vrais problèmes pour de vraies personnes – il doit y avoir une vision cohérente. Et une vision cohérente doit nécessairement être définie par un petit nombre de personnes, comme les fondateurs d’une startup, et souvent un seul fondateur.

La beauté d’Ethereum est que, bien qu’il s’agisse d’un système si complexe avec tant de pièces mobiles, les pièces s’emboîtent magnifiquement dans un ordinateur décentralisé fonctionnel qui déplace des milliards de dollars de valeur chaque jour. Et la façon dont nous en sommes arrivés là n’a pas été le fruit d’une conception par des comités. C’est précisément grâce au leadership actif de Vitalik à travers sa vision que nous sommes en mesure d’arriver à un produit cohérent et beau qu’est Ethereum aujourd’hui. Ethereum était une idée originale de Vitalik en 2015, et il le reste aujourd’hui.

Il ne s’agit pas, bien sûr, de minimiser les contributions d’autres chercheurs et ingénieurs, qui méritent la plupart des crédits pour avoir amené Ethereum là où il est aujourd’hui. Cependant, ce n’est pas incompatible avec le fait qu’Ethereum est une réalisation de la vision de Vitalik, des ordres de grandeur plus que celle de quiconque.

Et honnêtement, pouvez-vous vous plaindre ? Lorsque vous avez été attiré dans l’écosystème Ethereum par son ouverture, sa résistance à la censure et son rythme d’innovation, vous êtes-vous plaint que cela ait commencé avec la vision de Vitalik ? Peut-être que vous ne l’avez pas fait parce que vous n’y pensiez pas de cette façon – mais maintenant que vous le faites, cela vous dérange-t-il vraiment ?

@VitalikButerin/the-meaning-of-decentralization-a0c92b76a274">cet article classique sur la signification de la décentralisation, écrit par, cough cough, Vitalik. L’idée clé de l’article est qu’il existe trois types de décentralisation : Décentralisation architecturale : combien de nœuds peuvent être compromis avant que le système ne cesse de fonctionner ?Décentralisation logique : les sous-systèmes du système peuvent-ils évoluer de manière indépendante tout en maintenant le fonctionnement du système ? Ou doivent-ils être étroitement coordonnés ?Décentralisation politique : combien de personnes ou d’organisations contrôlent finalement ce système ? Compte tenu de ces définitions, Ethereum est clairement décentralisé sur le plan architectural, et il est probablement juste de dire qu’il est également logiquement décentralisé, étant donné l’absence de couplage fort entre ses différents composants (par exemple, consensus vs exécution). En termes de décentralisation politique, la bonne nouvelle est qu’aucun individu ou organisation ne peut fermer Ethereum, pas même Vitalik. Cependant, on pourrait soutenir qu’Ethereum n’est pas aussi décentralisé politiquement qu’on pourrait le penser, étant donné le rôle prépondérant que joue Vitalik dans la définition de sa vision et donc dans la définition de ses feuilles de route. Cependant, je suis d’avis que si nous voulons qu’Ethereum continue d’innover, nous devons adopter Vitalik comme le CTO de facto, même si cela signifie sacrifier une partie de la décentralisation politique. Si Ethereum « s’ossifie » un jour dans une blockchain presque immuable comme Bitcoin, alors Vitalik pourrait prendre sa retraite. Mais avant d’atteindre cette fin de partie, il est essentiel qu’il y ait une autorité que toutes les parties respectent, à qui l’on fait confiance pour porter des jugements sur les décisions techniques non seulement sur la base des mérites techniques, mais aussi sur leur cohérence avec la vision d’Ethereum. Sans un personnage comme Vitalik, il n’y a que deux issues possibles, toutes deux illustrées de manière vivante par cette saga 3074 : La gouvernance d’Ethereum pourrait se dissoudre dans des impasses sans fin où aucune des parties n’est prête à faire de compromis et personne ne pourrait faire de progrès, comme le montre la façon dont le débat 3074 était dans l’impasse jusqu’à l’arrivée de Vitalik.Ou, Ethereum pourrait finir par devenir un monstre Frankenstein de conceptions incohérentes, comme l’indique à quel point nous étions proches d’avoir 3074 et 4337 servant de deux piles AA parallèles qui sont largement incompatibles. Le rôle de la communauté

Nous sommes très proches d’avoir un modèle mental complet de Ethereum gouvernance, mais il y a une omission flagrante dans notre discussion jusqu’à présent : la communauté.

Si Vitalik définit la vision, qui sont suivies de feuilles de route définies par les chercheurs, qui sont à leur tour mises en œuvre par les développeurs principaux, quel rôle joue la communauté ? Sûrement pas rien ??

Heureusement, la communauté joue le rôle le plus important de tous. La raison en est qu’avant même qu’il y ait une vision, il y a des valeurs. Nous nous sommes tous rassemblés en tant que communauté parce que nous nous sommes ralliés autour de certaines valeurs, avec lesquelles la vision de Vitalik doit être cohérente, sinon elle perdrait la communauté.

Peut-être était-ce votre éducation. C’est peut-être quelque chose qui s’est passé dans votre dernier emploi. Mais à un moment ou à un autre, nous tous, dans la communauté Ethereum, avons décidé qu’il serait bon pour le monde d’avoir un ordinateur décentralisé qui soit accessible à tous, qui ne puisse pas être censuré, qui soit crédiblement neutre. Nous affirmons et affirmons ces valeurs tous les jours avec le travail que nous faisons en plus de Ethereum, et ce faisant, nous fournissons à la vision, aux feuilles de route et au code produits par Vitalik, les chercheurs et les développeurs principaux.

Le modèle VVRC de gouvernance Ethereum

Voici donc un modèle mental complet pour la gouvernance de Ethereum, que j’appelle les valeurs ⇒ vision ⇒ les feuilles de route ⇒ le modèle clients, ou VVRC pour short :

• V == Valeurs == Communauté
• V == Vision == Vitalik
• R == Feuilles de route == Chercheurs
• C == Clients == Développeurs principaux

Ensemble, ils fonctionnent comme suit :

• La communauté se mobilise autour de certaines valeurs.
• Vitalik articule une vision cohérente avec ces valeurs.
• Les chercheurs élaborent des feuilles de route conformes à la vision.
• Les développeurs principaux implémentent les clients en fonction des feuilles de route.

Mal dessiné par le nouveau GPT-4o.
Il a refusé de dessiner le mot « Vitalik » en raison de la « politique de contenu ».

Bien sûr, la réalité est bien plus désordonnée que ce que n’importe quel modèle simple peut capturer. Par exemple, les développeurs de base sont en réalité les seules personnes qui peuvent « voter » sur toutes les décisions, en vertu de la mise en œuvre des clients. Vitalik et d’autres chercheurs n’ont qu’un rôle consultatif, et parfois leur contribution n’est pas acceptée par les développeurs principaux, c’est pourquoi 3074 a été approuvé.

Cela dit, je pense que le modèle VVRC capture raisonnablement le fonctionnement de la gouvernance Ethereum dans le cas heureux, et c’est à nous de « déboguer » le processus afin qu’il n’échoue pas comme il l’a fait avec 3074.

Comment pouvons-nous améliorer la gouvernance Ethereum

Maintenant que nous avons un modèle mental sur la façon dont la gouvernance Ethereum devrait fonctionner, voici quelques idées pour améliorer le processus de gouvernance afin que nous puissions éviter le genre de coup du lapin que nous avons connu avec 3074/7702.

• Il doit y avoir plus de visibilité pour les EIP dont l’inclusion est activement envisagée. La communauté dans son ensemble ne devrait jamais être « prise par surprise » qu’un EIP soit accepté, ce qui a été le cas avec 3074.
  • Contrairement à ce à quoi on pourrait s’attendre, le « statut » d’un EIP sur le site EIPs ne reflète pas son statut dans le processus ACD. C’est pourquoi il est toujours dit que 3074 est en « Révision » même si les développeurs principaux avaient déjà voté pour l’approuver, et il y avait encore moins d’indications qu’il ait jamais été envisagé pour l’inclusion en premier lieu.
  • Idéalement, EF indiquerait haut et fort sur les médias sociaux quand un EIP est sur le point d’être accepté, afin d’accroître la sensibilisation de la communauté.
• Parfois, les développeurs principaux peuvent sous-estimer l’impact d’un EIP particulier sur les projets et les utilisateurs en aval, ce qui est le cas avec 3074 et la communauté 4337. Étant donné que les réunions de l’ACD sont limitées dans le temps et doivent être coordonnées à travers les fuseaux horaires, il est compréhensible que l’accent soit mis sur le fait que seules les « personnes concernées » doivent prendre la parole lors des réunions. Cela dit, il pourrait être judicieux d’allouer un peu de temps, de temps en temps, aux membres de la communauté pour commenter l’impact en aval de certaines propositions EIP.
  • Si les chercheurs ont l’impression que leurs commentaires ne sont pas pris en compte par les développeurs principaux, comme ce fut le cas avec l’équipe 4337, ils pourraient faire participer les membres de la communauté à l’appel pour renforcer leur argumentaire.
• Il est essentiel qu’il y ait une reconnaissance mutuelle entre les développeurs principaux et les chercheurs qu’ils sont tous deux des puissances de gouvernance, bien qu’avec des forces différentes. Le « pouvoir client » des développeurs de base est le seul pouvoir qui peut réellement « voter » en vertu de l’implémentation des clients. Le « pouvoir de feuille de route » des chercheurs bénéficie généralement d’un plus grand support public grâce aux chercheurs qui parlent et écrivent activement sur leurs feuilles de route.
  • Lorsque les deux pouvoirs sont en désaccord, il peut être tentant pour les développeurs principaux de simplement passer outre les chercheurs, par exemple lorsque les développeurs principaux ont passé outre les objections de l’équipe 4337. Cependant, le fait de passer outre en tant que tel peut entraîner un coup du lapin puisque les pouvoirs sont instables lorsqu’ils sont en conflit, comme le montre le drame qui s’ensuit après l’approbation de 3074.
  • De même, lorsqu’ils sont confrontés à des résistance, il peut être tentant pour les chercheurs d’abandonner simplement l’engagement avec les développeurs de base, ce qui est l’une des raisons pour lesquelles le processus RIP a été créé et pourquoi l’AA natif (7560) est maintenant principalement poussé comme un RIP, et non comme un EIP. Bien qu’il y ait de réels avantages à aider les L2 à expérimenter des mises à jour de protocoles trop controversées pour L1, nous ne pouvons pas considérer les RIP comme un substitut à l’engagement dans le processus de gouvernance des EIP. Les chercheurs doivent continuer à s’engager avec les développeurs principaux jusqu’à ce qu’ils soient pleinement alignés sur les feuilles de route.

Conclusion

La saga 3074/7702 met en lumière le fonctionnement réel de la gouvernance Ethereum – qu’en plus du pouvoir de gouvernance explicite qu’est le processus EIP/ACD piloté par les développeurs principaux, il y a aussi le pouvoir de gouvernance implicite des feuilles de route pilotées par les chercheurs. Lorsque ces pouvoirs sont désalignés, nous assistons à des embouteillages et à des coups de fouet cervicaux, et il pourrait falloir un autre pouvoir – Vitalik – pour faire pencher la balance d’un côté ou de l’autre.

Nous faisons ensuite valoir que Vitalik représente un pouvoir distinct qui est la « vision » d’Ethereum, qui est la base de la légitimité de toute feuille de route. Nous comparons Vitalik au CTO d’une grande entreprise et reconnaissons que son rôle de pseudo-CTO est nécessaire pour qu’Ethereum puisse maintenir son rythme d’innovation, sans dégénérer en un système Frankenstein de conceptions incohérentes.

Enfin, nous présentons un modèle mental pour penser Ethereum gouvernance en tant que VVRC : valeurs (communauté) ⇒ vision (Vitalik) ⇒ feuilles de route (chercheurs) ⇒ clients (core devs). Nous suggérons ensuite différentes façons de corriger les « bugs » qui font parfois dévier le processus de ce modèle dans la pratique.

Ethereum gouvernance est « la machine qui construit la machine » — pour bien Ethereum, nous devons avoir une bonne gouvernance. En tant que tel, 3074 a fourni une étude de cas inestimable pour les cas où la gouvernance a mal tourné, et j’espère que j’ai pu en tirer des leçons utiles afin que nous puissions améliorer la gouvernance d’Ethereum pour l’avenir.

zerodev]. Tous les droits d’auteur appartiennent à l’auteur original [derek]. S’il y a des objections à cette réimpression, veuillez contacter l’équipe Gate Learn, et ils la traiteront rapidement.

Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l’auteur et ne constituent pas un conseil en investissement.

Les traductions de l’article dans d’autres langues sont effectuées par l’équipe de Gate Learn. Sauf mention contraire, il est interdit de copier, de distribuer ou de plagier les articles traduits.