Transmettre le titre original ' Réflexions sur la gouvernance d’Ethereum après la saga 3074'

Résumé : L’article est une déclaration de Derek Chiang, le PDG de ZeroDev, en réponse à la proposition de V d’EIP-7702 pour équilibrer les contradictions entre ERC-4337 et EIP-3074. Écrit du point de vue d’un fondateur de projet au sein de l’écosystème AA, il met objectivement en évidence le modèle de gouvernance actuel d’Ethereum et ses points faibles. Derek souligne succinctement :

L’un des conflits de gouvernance d’Ethereum réside dans les divergences entre la feuille de route déterminée par les chercheurs et les perspectives des équipes de développement des clients comme Geth. Vitalik, agissant dans un rôle semblable à celui d’un directeur technique, devient finalement le facteur décisif.

Après avoir affirmé le rôle de Vitalik, Derek décrit les améliorations qu’Ethereum devrait apporter à son modèle de gouvernance, offrant des informations précieuses aux communautés Ethereum et Bitcoin.

SMS:

Si vous n’étiez pas familier avec les événements entourant l’abstraction de compte (AA) d’Ethereum auparavant, voici un bref récapitulatif : il y a plusieurs semaines, la proposition EIP-3074 a été approuvée par les principaux développeurs d’Ethereum pour être incluse dans le prochain hard fork, « Pectra ». Cette proposition introduit deux nouveaux opcodes dans la machine virtuelle Ethereum (EVM), permettant aux comptes externes (EOA) Ethereum d’avoir une expérience AA presque native. Depuis lors, de nombreux membres de la communauté ERC-4337, en particulier ses partisans, se sont fermement opposés à l’EIP-3074, invoquant des inquiétudes concernant les risques de sécurité potentiels et son incompatibilité avec la feuille de route AA d’Ethereum. Dans la feuille de route précédente d’Ethereum, ERC-4337 et des propositions similaires comme 7560 (également connu sous le nom de « nativeAA ») étaient centraux. Au début du mois de mai, Vitalik a proposé l’EIP-7702 comme alternative à l’EIP-3074, trouvant un équilibre entre 4337 et 3074, offrant une expérience AA aux utilisateurs de l’EOA tout en maintenant la compatibilité avec l’ERC-4337 dans une certaine mesure, ainsi que la compatibilité avec la « solution AA finale » 7560. Actuellement, les principaux développeurs d’Ethereum examinent les implications de l’EIP-7702, et les discussions préliminaires et le sentiment de la communauté indiquent que l’EIP-7702 est susceptible de remplacer l’EIP-3074 mentionné précédemment. Je suis très satisfait de ce résultat : les utilisateurs d’EOA pourront bientôt découvrir divers produits de l’écosystème ERC-4337 et profiter de la plupart des avantages de l’AA. Cependant, je ne peux m’empêcher de penser qu’il aurait pu y avoir une meilleure façon d’obtenir ces résultats, comme beaucoup l’ont souligné ces dernières semaines. Je crois qu’avec un meilleur processus de gouvernance, nous aurions pu économiser beaucoup d’énergie et atteindre le résultat souhaité plus rapidement. Dans cet article, j’aimerais :

• Identifier ce qui n’a pas fonctionné dans le processus de gouvernance
• Proposer un modèle de réflexion pour la gouvernance d’Ethereum
• Proposer des suggestions d’amélioration pour éviter des accidents de gouvernance similaires à l’avenir

Conclusion et réflexion sur l’incident de l’EIP-3074

L’histoire mentionnée ci-dessus a laissé beaucoup de gens mécontents pour plusieurs raisons : EIP-3074 a mis plusieurs années à être approuvé. Après l’approbation de 3074, les développeurs principaux d’Ethereum ont fait face à une forte opposition de la communauté 4337. D’autre part, les auteurs de l’ERC-4337 ont exprimé à plusieurs reprises leurs inquiétudes concernant l’EIP-3074 à l’équipe principale d’Ethereum, mais en vain. Ethereum prévoit maintenant d’annuler l’approbation de 3074 et de la remplacer par un autre EIP (7702). Il n’y a rien de mal en soi à un point quelconque du processus mentionné ci-dessus :

• Il est normal que les discussions sur un EIP prennent plusieurs années.
• Il est normal qu’un EIP approuvé soit rejeté par la suite.
• Si de nouveaux problèmes sont découverts, l’approbation d’un EIP peut être révoquée après approbation.

Cependant, les choses auraient pu être plus fluides. Imaginons que les choses se soient développées comme ça : pendant la discussion sur 3074, la communauté 4337 s’est activement engagée avec les développeurs principaux d’Ethereum. Si cette prémisse est vraie, il n’y a que deux résultats possibles :

• Après avoir pris en compte les commentaires de la communauté 4337, la proposition 3074 est approuvée (et éventuellement modifiée). Dans ce cas, la communauté 4337 accepterait 3074, et l’équipe principale d’Ethereum n’aurait pas besoin de révoquer 3074.
• Alternativement, 3074 n’est jamais approuvé, mais la communauté 4337 et l’équipe principale d’Ethereum proposent conjointement une solution qui satisfait tout le monde, similaire à 7702. Les voix de chacun sont entendues, et il n’y a pas de renversement spectaculaire. Cela aurait été idéal, alors pourquoi cela ne s’est-il pas produit ?

Qu’est-ce qui n’a pas fonctionné ?

En regardant en arrière sur l’ensemble du processus, les deux parties de l’événement se blâment mutuellement. Les développeurs principaux d’Ethereum (ainsi que les auteurs de l’EIP-3074) pensent que c’est la faute des « partisans de 4337 » parce qu’ils n’ont pas participé activement au processus de discussion de tous les développeurs principaux (ACD). Dans ce processus, les EIP doivent subir de longues délibérations et finalement être acceptés et mis en œuvre par des équipes de développement client Ethereum comme Geth. Certains soutiennent que pendant la période où l’EIP-3074 était à l’étude, les « partisans de 4337 » auraient pu participer et exprimer leurs opinions, au lieu de le critiquer après qu’il ait déjà été approuvé. Après tout, l’ensemble du processus d’ACD est transparent, les réunions sont ouvertes à tous et des personnes comme Tim Beiko publient régulièrement des tweets de résumé après chaque réunion d’ACD. Alors, si les « partisans de 4337 » se souciaient tant du sujet, pourquoi n’ont-ils pas participé activement et rapidement aux réunions pertinentes ?

D’autre part, les membres principaux de 4337 indiquent qu’ils ont participé aux réunions de l’ACD et s’opposent autant que possible à 3074, mais les développeurs principaux d’Ethereum n’écoutent pas. Quant aux membres de la communauté 4337, beaucoup se sont sentis pris au dépourvu – beaucoup pensaient que 3074 était déjà mort, et certains ne savaient même pas que 3074 était susceptible d’être approuvé. Beaucoup soulignent que l’ensemble du processus des réunions ACD est opaque et n’est pas convivial pour ceux qui sont « sérieux » dans la communauté Ethereum mais ne peuvent pas suivre les mises à jour ACD en temps réel. Certains pensent également que l’ACD devrait rechercher activement les commentaires des parties prenantes (ici en référence à la communauté 4337).

Cependant, je pense qu’aucune des deux parties n’a mis le doigt sur le problème. Il y a des problèmes plus profonds derrière cela, et si nous ne nous attaquons pas ou au moins ne reconnaissons pas ce problème, nous continuerons à tomber dans des accidents de gouvernance, suivis d’accusations contradictoires des deux côtés, qui n’ont finalement aucun sens.

La cause profonde des accidents de gouvernance : la feuille de route

Contrairement à la croyance populaire, la cause profonde des accidents de gouvernance réside dans le fait qu’ACD n’est pas la seule autorité de gouvernance pour les mises à jour du protocole Ethereum ; elle a été remplacée par une autre autorité de gouvernance. Le problème ici est que, bien qu’elle ait plus d’influence qu’ACD sur les questions fondamentales d’Ethereum (telles que l’AA et l’évolutivité), cette autre autorité de gouvernance est rarement reconnue. Dans cet article, j’appellerai ce type de pouvoir la « feuille de route ». Comme je le soulignerai ci-dessous, l’ensemble de l’événement d’échec de gouvernance « 3074-4337-7702 » est un cas où le pouvoir de la feuille de route existante d’Ethereum l’emporte sur le pouvoir ACD. Si nous parlons de gouvernance, lorsque nous remarquons qu’une force intangible submerge une force tangible, nous devrions être extrêmement préoccupés car les choses intangibles sont souvent difficiles à expliquer et ne peuvent pas être facilement remarquées par beaucoup de gens, elles doivent donc être exposées.

Qu’est-ce qu’une feuille de route ?

N’importe qui dans la communauté Ethereum doit avoir souvent entendu le terme « feuille de route », que ce soit dans la « feuille de route ETH2.0 » ou dans le contexte de la « feuille de route AA » liée à cet événement.

Pour illustrer mon propos, imaginons une scène lors d’une réunion ACD où les développeurs principaux discutent de la façon de faire évoluer Ethereum :

• Bob : Je soutiens l’EIP-1234, qui propose d’augmenter la vitesse des blocs de 10 fois, d’augmenter la taille des blocs de 10 fois et de réduire les frais de 100 fois.
• Autres développeurs principaux : ... Vous avez perdu la tête ?

Réfléchissons à cela. Pourquoi l’équipe principale d’Ethereum rejetterait-elle ce que propose Bob ? Il suggère simplement une façon apparemment raisonnable de se développer, ce que de nombreuses chaînes publiques comme Solana, Aptos, Sui et d’autres ont fait, atteignant un TPS élevé. La raison en est que cette EIP-1234 fictive contredit la feuille de route de mise à l’échelle « centrée sur le rollup » d’Ethereum. Cette feuille de route souligne que, pour la décentralisation, les utilisateurs ordinaires doivent être en mesure d’exécuter des nœuds à faible coût. Par conséquent, il est peu probable que l’EIP-1234 fictif soit accepté car il augmenterait considérablement le coût d’exécution des nœuds Ethereum. Je veux utiliser cet exemple pour illustrer que les développeurs principaux participant au processus de gouvernance de l’ACD et décidant des mises à jour du protocole sont guidés par une force de niveau supérieur, que j’appelle la « feuille de route ». Actuellement, autour de la feuille de route d’Ethereum, il y a des « feuilles de route de mise à l’échelle », des « feuilles de route AA », des « feuilles de route MEV », etc. Ils forment collectivement la feuille de route globale d’Ethereum, et les développeurs principaux doivent prendre des décisions sur cette base.

Lorsque les points de vue des développeurs principaux ne correspondent pas à la feuille de route

Étant donné que la feuille de route ne fait pas partie intégrante du processus de gouvernance d’Ethereum, il n’y a souvent aucune garantie que l’équipe principale y adhérera. De plus, il n’y a pas de processus formel pour « approuver » la feuille de route, donc toutes les feuilles de route n’ont pas le même niveau d'« orthodoxie ». Les chercheurs à l’origine de la feuille de route d’Ethereum doivent travailler dur pour promouvoir leur feuille de route auprès des développeurs principaux et de la communauté afin d’obtenir l’orthodoxie et le soutien de l’équipe de développement d’Ethereum. En ce qui concerne les AA et l’abstraction des comptes, Vitalik lui-même a plaidé à plusieurs reprises pour la feuille de route AA centrée sur 4337, mais dans l’ensemble, c’est principalement l’équipe derrière 4337, en particulier Yoav et Dror, qui plaide pour la feuille de route AA centrée sur 4337 sur les forums et dans les réunions ACD.

Cependant, malgré ces efforts, certains développeurs principaux d’Ethereum s’opposent encore fermement à la feuille de route AA centrée sur 4337. Ils pensent que 7560 (la version native de 4337 qui sera implémentée par les clients Ethereum à l’avenir) est trop complexe et n’est pas la seule solution viable pour la « fin de partie AA ». En fin de compte, l’ACD a décidé d’approuver la proposition 3074, malgré l’opposition de l’équipe 4337, qui pensait que 3074 fracturerait l’ensemble de l’écosystème AA. Après l’approbation de 3074, l’ensemble de la communauté 4337 a réagi vivement, obligeant les développeurs principaux d’Ethereum à se réengager dans les discussions sur 3074. La discussion a ensuite abouti à une impasse, les auteurs de 4337 et 3074 ne parvenant pas à se persuader mutuellement. Vitalik a proposé l’EIP-7702 comme alternative à la 3074 à la dernière minute, ce qui s’adapte explicitement à la « fin de partie AA » centrée sur la 4337, résolvant ainsi le conflit et alignant le résultat final sur la feuille de route de l’AA.

Le rôle de Vitalik : le directeur technique de facto d’Ethereum

Bien que Vitalik s’identifie comme un chercheur, l’histoire ci-dessus indique clairement que Vitalik détient des pouvoirs de gouvernance distincts des autres chercheurs. La question se pose donc : quel rôle joue Vitalik dans la gouvernance d’Ethereum ? Personnellement, je pense qu’il n’est peut-être pas inapproprié de considérer Vitalik comme le CTO de facto d’une très grande entreprise (soit dit en passant, en supposant Ethereum comme une « entreprise » sans PDG pour s’aligner sur la réalité). Si vous avez déjà travaillé dans une entreprise technologique de plus de 50 employés, vous savez que le CTO ne peut pas être impliqué dans toutes les décisions techniques. Au fur et à mesure que l’entreprise se développe, les processus de prise de décision pour diverses solutions techniques deviennent inévitablement décentralisés - généralement, chaque domaine du produit/de l’activité de l’entreprise dispose d’une équipe dédiée, qui a souvent l’autonomie nécessaire pour décider des détails de la solution. De plus, le CTO peut ne pas être le meilleur expert dans tous les domaines (ou sur aucun d’entre eux). Il peut y avoir des ingénieurs au sein de l’entreprise qui sont meilleurs dans des domaines spécifiques que le CTO, donc dans les discussions sur les détails techniques des solutions, ce sont souvent les ingénieurs individuels qui prennent les décisions finales. Cependant, le CTO définit la vision technique de l’entreprise. L’exécution de la vision est laissée aux développeurs. Bien que ce ne soit pas une analogie parfaite, je pense qu’elle résume raisonnablement le rôle de Vitalik dans l’écosystème Ethereum. Vitalik ne participe pas à toutes les décisions techniques – il ne le pourrait peut-être pas. Il n’est pas non plus le meilleur expert dans tous les domaines. Mais il a une influence écrasante dans l’établissement de la feuille de route de toutes les solutions Ethereum cruciales (mise à l’échelle, AA, POS...), non seulement en raison de son expertise technique, mais aussi parce qu’il est le juge ultime de savoir si la feuille de route s’aligne sur la vision d’Ethereum (sa vision).

Tout produit réussi commence par une vision

Si considérer Vitalik comme CTO d’Ethereum n’est pas assez controversé, voici la partie la plus controversée : nous devrions adopter Vitalik comme CTO. En tant que fondateur d’une startup, je pense que chaque produit réussi doit avoir une vision cohérente à long terme – oui, Ethereum est aussi un « produit » car il résout de vrais problèmes pour de vrais utilisateurs. Une vision cohérente doit être élaborée par quelques personnes, comme les fondateurs d’une startup, et généralement, il n’y a qu’un seul fondateur. La beauté d’Ethereum est que, bien qu’il s’agisse d’un système extrêmement complexe avec autant de composants, tous ces composants s’assemblent de manière transparente pour former un ordinateur décentralisé qui fonctionne bien, réglant des milliards de dollars de transactions chaque jour. Nous sommes arrivés jusqu’ici non pas grâce aux plans de conception d’un comité, mais parce que Vitalik, avec sa prévoyance et sa perspicacité, a activement fourni un leadership, nous permettant de construire l’Ethereum cohérent et gracieux d’aujourd’hui. Ethereum est l’idée proposée par Vitalik en 2015, et elle le reste. Bien sûr, il ne s’agit pas de diminuer les contributions d’autres chercheurs et ingénieurs - ils ont fait l’essentiel des réalisations d’Ethereum aujourd’hui. Cependant, ce n’est pas contradictoire, car Ethereum est la réalisation de la vision de Vitalik, des magnitudes plus grandes que la vision de n’importe qui d’autre. Honnêtement, pouvez-vous vous plaindre de cela ? Lorsque vous êtes attiré par l’ouverture, la résistance à la censure et la vitesse d’innovation de l’écosystème Ethereum, vous êtes-vous déjà plaint que cela découlait de la vision de Vitalik ? Peut-être ne vous êtes-vous pas plaint parce que vous n’y avez pas pensé de cette façon, mais maintenant que vous l’êtes, cela vous dérange-t-il ?

Comment aborder la décentralisation ?

Mais vous pourriez vous demander, qu’en est-il de la décentralisation ? Si une personne détient un pouvoir aussi écrasant sur Ethereum, comment pouvons-nous dis-le qu’il est décentralisé ? Pour répondre à cette question, nous devons revisiter l’article classique de Vitalik sur la signification de la décentralisation. Les principales conclusions de l’article sont que la décentralisation se décline en trois types :

• Décentralisation architecturale : combien de nœuds peuvent tomber en panne avant que le système ne s’arrête de fonctionner ?
• Décentralisation logique : les différents sous-systèmes du système peuvent-ils se développer indépendamment tout en travaillant ensemble de manière cohérente ?
• Décentralisation politique : En fin de compte, combien d’individus ou d’organisations contrôlent le système ?

Selon ces définitions, Ethereum est clairement décentralisé sur le plan architectural, et on pourrait dire qu’il est logiquement décentralisé parce que ses composants manquent d’un couplage fort (par exemple, entre la couche de consensus et la couche d’exécution). En ce qui concerne la décentralisation politique, la bonne nouvelle est qu’aucun individu ou organisation ne peut fermer Ethereum, pas même Vitalik. Cependant, certains pourraient dire que le niveau de décentralisation politique d’Ethereum n’est pas aussi élevé qu’on l’imaginait, car Vitalik joue un rôle important dans l’élaboration de la vision et de la feuille de route d’Ethereum.

Cependant, je pense que si nous voulons qu’Ethereum continue à innover, nous devons accepter Vitalik comme CTO de facto, même si cela signifie sacrifier une partie de la décentralisation politique. Si Ethereum devait devenir aussi « stagnant » que Bitcoin, une blockchain presque immuable, alors Vitalik pourrait aussi bien prendre sa retraite. Mais avant d’atteindre cette dernière étape, il est crucial d’avoir une autorité respectée par toutes les parties, quelqu’un de confiance pour prendre des décisions techniques basées non seulement sur la supériorité des solutions techniques proposées, mais aussi sur la conformité de ces décisions avec la vision d’Ethereum.

Sans quelqu’un comme Vitalik, seuls deux résultats sont probables, illustrés de manière frappante par l’histoire autour de l’EIP-3074 :

Le processus de gouvernance d’Ethereum pourrait tomber dans une impasse sans fin, avec des parties en conflit qui ne veulent pas faire de compromis et personne ne progresse, comme l’a démontré l’impasse dans le débat sur la loi 3074 avant l’intervention de Vitalik.

Ou Ethereum pourrait devenir un « Frankenstein » incohérent en termes de conception, avec 3074 et 4337 ne cédant peut-être pas l’un à l’autre, ce qui entraînerait finalement la rupture complète de l’écosystème AA en deux espaces parallèles incompatibles.

Le rôle de la communauté

Après les considérations ci-dessus, nous sommes presque en train d’esquisser un état d’esprit complet de gouvernance d’Ethereum, mais il y a une omission évidente dans notre discussion jusqu’à présent : la communauté. Si Vitalik définit la vision d’Ethereum, que les chercheurs définissent la feuille de route et que les développeurs principaux mettent en œuvre la feuille de route, alors quel rôle joue la communauté ? Il ne reste sûrement pas inactif, n’est-ce pas ? Heureusement, la communauté joue le rôle le plus crucial. La raison en est qu’avant d’avoir une vision, il y a des valeurs. Nous nous rassemblons en tant que communauté parce que nous nous rallions autour de certaines valeurs, et la vision de Vitalik doit finalement s’aligner sur ces valeurs pour conserver le soutien de la communauté. Tout le monde dans la communauté Ethereum pense qu’avoir un ordinateur décentralisé accessible à tous, non censuré et neutre en matière de confiance est bénéfique pour le monde. Nous défendons et affirmons ces valeurs chaque jour à travers le travail que nous effectuons sur Ethereum, légitimant ainsi la vision, la feuille de route et le code définis par Vitalik, les chercheurs et les développeurs principaux.

Le modèle VVRC de la gouvernance Ethereum

Par conséquent, voici l’état d’esprit complet de la gouvernance d’Ethereum, abrégé en VVRC :

• V==Valeurs==Communauté ;
• V==Vision==Vitalik ;
• R== Feuille de route ==Chercheurs ;
• C==Client==Développeur principal ;

Ensemble, ils jouent les rôles suivants :

• La communauté se rallie autour de valeurs spécifiques.
• Vitalik articule une vision cohérente avec ces valeurs.
• Les chercheurs formulent une feuille de route basée sur la vision.
• Les développeurs principaux implémentent les clients en fonction de la feuille de route.

Bien sûr, la réalité est beaucoup plus complexe que ce qu’un simple modèle peut capturer. Les développeurs principaux d’Ethereum sont les seuls à pouvoir vraiment « voter » sur n’importe quelle proposition en modifiant le code client. Vitalik et d’autres chercheurs servent de conseillers, et parfois leurs opinions ne sont pas acceptées par les développeurs principaux, ce qui est précisément la raison pour laquelle EIP-3074 a été approuvé. Néanmoins, je pense que le modèle VVRC capture raisonnablement le mode opérationnel de la gouvernance d’Ethereum dans des circonstances normales, et nous devons « déboguer » ce processus pour éviter que des accidents comme EIP-3074 ne se reproduisent.

Comment améliorer le modèle de gouvernance d’Ethereum

Maintenant que nous avons un modèle mental du fonctionnement du processus de gouvernance d’Ethereum, voici quelques idées pour améliorer les processus de gouvernance :

La visibilité de l’avancement des discussions sur les PIE en cours d’examen doit être accrue. L’ensemble de la communauté ne devrait pas être « surpris » par l’acceptation d’un PIE, et des approbations inattendues comme l’EIP-3074 ne devraient pas se reproduire. Le « statut » actuel des EIP sur le site Web du PIE ne reflète pas leur statut dans le processus de DAA. C’est pourquoi il est toujours dit que l’EIP-3074 est « en cours d’examen », bien que les principaux développeurs aient voté pour l’approuver, sans aucune indication qu’il ait jamais été envisagé pour approbation dès le départ. Idéalement, lorsqu’un EIP est sur le point d’être accepté, la Fondation Ethereum devrait faire une annonce publique définitive sur les médias sociaux pour sensibiliser la communauté.

Parfois, les développeurs principaux peuvent sous-estimer l’impact de certains PEI sur les projets et les utilisateurs en aval, comme ce fut le cas pour les collectivités 3074 et 4337. En raison du temps limité des réunions de l’ACD et de la nécessité d’une coordination entre les fuseaux horaires, seul le « personnel concerné » peut souvent prendre la parole lors des réunions. Néanmoins, il serait logique d’allouer occasionnellement du temps de parole aux membres de la communauté pour commenter l’impact de certaines propositions du PIE sur les projets en aval après leur approbation. Si les chercheurs estiment que leurs opinions n’ont pas été acceptées par les développeurs principaux, comme ce fut le cas avec 4337, ils peuvent inviter les membres de la communauté à renforcer leurs arguments.

Il est crucial que les développeurs et les chercheurs reconnaissent mutuellement que, malgré les différences de pouvoir, ils font tous deux partie de l’autorité de gouvernance d’Ethereum. Les développeurs principaux ont le pouvoir de modifier et de mettre à jour les clients Ethereum, ce qui est le seul moyen d’apporter des modifications au protocole lui-même et de « voter ». Les chercheurs bénéficient généralement d’un plus grand soutien du public pour les changements et les interprétations de la feuille de route, grâce à leurs discussions actives et à la rédaction de leurs idées.

Lorsque ces deux forces s’affrontent, les développeurs principaux peuvent avoir tendance à renverser directement les opinions des chercheurs, comme ce fut le cas avec l’équipe 4337. Cependant, un tel renversement peut conduire à un conflit, car l’instabilité survient lorsque les deux forces s’affrontent, comme en témoignent les événements dramatiques qui ont suivi l’approbation de l’EIP-3074.

De même, face à la résistance, les chercheurs peuvent avoir tendance à abandonner la collaboration avec les développeurs principaux. À mon avis, c’est aussi l’une des raisons de la création du processus RIP et pourquoi l’AA natif (7560) est maintenant principalement promu comme RIP plutôt qu’EIP.

Bien que l’expérimentation de mises à jour de protocole sur la L2 qui sont controversées pour la L1 ait ses avantages, nous ne pouvons pas considérer le RIP comme un substitut à la participation au processus de gouvernance de l’EIP. Les chercheurs doivent continuer à collaborer avec les développeurs principaux jusqu’à ce que les valeurs des deux parties s’alignent pleinement sur la feuille de route.

Conclusion

L’incident 3074/7702 a révélé le véritable fonctionnement de la gouvernance d’Ethereum : outre le pouvoir de gouvernance explicite piloté par les processus EIP/ACD des développeurs principaux, il existe également un pouvoir de gouvernance implicite piloté par la feuille de route poussée par les chercheurs. Lorsque ces pouvoirs ne sont pas alignés, nous assistons à des impasses et à des aiguillons, et une autre force – Vitalik – peut avoir besoin d’intervenir d’une manière ou d’une autre pour perturber l’équilibre.

Ensuite, nous proposons que Vitalik représente une force unique, à savoir la « vision » d’Ethereum, qui constitue la base de la légitimité de toute feuille de route. Nous comparons Vitalik à un directeur technique d’une grande entreprise et reconnaissons que son rôle de pseudo-directeur technique est nécessaire pour qu’Ethereum maintienne son rythme d’innovation, empêchant Ethereum de se transformer en un « Frankenstein » - comme un monstre rafistolé.

Enfin, nous présentons le modèle VVRC, décrivant le modèle de gouvernance Ethereum : Valeurs (Communauté) ⇒ Vision (Vitalik) ⇒ Feuille de route (Chercheurs) ⇒ Client (Développeurs principaux). Ensuite, nous proposons diverses méthodes pour « déboguer » les « défauts » de ce modèle.

La gouvernance d’Ethereum est une « machine à fabriquer des machines » : pour qu’Ethereum fonctionne correctement, nous devons le gouverner correctement.

Démenti:

1. Cet article est réimprimé à partir de [极客 Web3]. Transmettre le titre original « Réflexions sur la gouvernance d’Ethereum après la saga 3074 ». Tous les droits d’auteur appartiennent à l’auteur original [Derek Chiang, PDG de ZeroDev]. S’il y a des objections à cette réimpression, veuillez contacter l’équipe Gate Learn , et ils s’en occuperont rapidement.
2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l’auteur et ne constituent aucun conseil en investissement.
3. 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, distribuer ou plagier les articles traduits.