Sur l'impact de Vitalik et des différentes feuilles de route sur le processus de gouvernance d'Ethereum

Article original de Derek Chiang, PDG de ZeroDev

Traduction originale : Faust, Geekweb3

Résumé : Cet article présente l'opinion du PDG de ZeroDev, Derek Chiang, sur la question après que Vitalik Buterin a proposé l'EIP-7702 pour équilibrer la contradiction entre l'ERC-4337 et l'EIP-3074. S'appuyant sur l'expérience personnelle d'un fondateur de projet dans l'écosystème AA, l'article souligne objectivement le modèle de gouvernance actuel et les points faibles d'Ethereum, et souligne :

L’un des différents conflits de gouvernance dans Ethereum est que la feuille de route déterminée par les chercheurs est en contradiction avec les points de vue des équipes de développement des clients telles que Geth, et Vitalik est devenu le décideur final dans une capacité similaire à celle de CTO.

Après avoir donné une évaluation positive du rôle de Vitalik, Derek a souligné les améliorations qu'Ethereum devrait apporter à son modèle de gouvernance, ce qui est d'une grande importance de référence pour la communauté Ethereum et la communauté Bitcoin.

Contenu : Si vous ne connaissez pas encore Ethereum AA (Account Abstraction), voici un bref aperçu :

Il y a quelques semaines, la proposition EIP-3074 a été approuvée par les développeurs principaux d'Ethereum et sera incluse dans le prochain hard fork Pectra. La proposition apportera deux nouveaux opcodes à l'EVM, offrant aux comptes EOA d'Ethereum une expérience AA quasi native.

Depuis lors, de nombreuses personnes de la communauté ERC-4337, en particulier les proposants de 4337, se sont fortement opposés à l'EIP-3074, invoquant des inquiétudes selon lesquelles la proposition entraînerait de nombreux risques de sécurité et serait incompatible avec la feuille de route AA d'Ethereum. Dans la feuille de route précédente d'Ethereum, il était clairement indiqué que l'ERC-4337 et la proposition similaire 7560 (également connue sous le nom de nativeAA) en étaient la pièce maîtresse.

Début mai, Vitalik a proposé l'EIP-7702 comme remplacement de l'EIP-3074, trouvant un équilibre entre le 4337 et le 3074 - il peut apporter l'expérience AA aux utilisateurs de l'EOA, mais d'une manière plus compatible avec l'ERC-4337 et compatible avec la solution finale AA 7560.

Actuellement, les développeurs du noyau Ethereum étudient l'EIP-7702. Les résultats des discussions préliminaires actuelles et le sentiment de la communauté indiquent que l'EIP-7702 est susceptible de remplacer l'EIP-3074 mentionné ci-dessus.

Personnellement, je suis très satisfait de ce résultat : les utilisateurs de l'EOA pourront bientôt découvrir différents produits au sein 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 existe de meilleurs moyens d'obtenir les résultats ci-dessus, comme de nombreuses personnes l'ont souligné ces dernières semaines. J'ai le sentiment que s'il y avait eu un meilleur processus de gouvernance, nous aurions pu économiser beaucoup d'énergie et atteindre les résultats souhaités plus rapidement.

Dans cet article, je souhaite :

• Identifier ce qui n’a pas fonctionné dans le processus de gouvernance

• Proposer un modèle mental pour réfléchir à la gouvernance d'Ethereum

• Fournir des suggestions d’amélioration pour éviter des incidents de gouvernance similaires à l’avenir

Résumé et réflexion sur l'incident EIP-3074

L'histoire mentionnée ci-dessus rend de nombreuses personnes malheureuses pour les raisons suivantes :

Il a fallu des années pour que l'EIP-3074 soit approuvé. Après que le 3074 ait finalement été approuvé, les développeurs du noyau Ethereum ont dû faire face à une forte opposition de la part 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 centrale d'Ethereum, mais en vain. Ethereum envisage désormais d'annuler l'approbation de l'EIP-3074 et de le remplacer par un autre EIP (7702).

Il n’y a rien de fondamentalement mauvais dans aucun des processus ci-dessus :

• Les discussions autour d’un PEI peuvent prendre plusieurs années, ce qui est normal.

• Il est normal qu’un EIP soit rejeté après avoir été approuvé.

• L’approbation peut être révoquée après l’approbation d’un EIP si de nouveaux problèmes sont découverts.

Mais les choses auraient pu se passer beaucoup mieux. Imaginons que les choses se soient passées ainsi :

Lors des discussions sur le 3074, la communauté 4337 a interagi activement 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 examiné les commentaires de la communauté 4337, la proposition 3074 est approuvée (et peut être modifiée), auquel cas la communauté 4337 acceptera la 3074 et l'équipe principale d'Ethereum n'aura pas à retirer la 3074.

• Ou peut-être que 3074 n'est jamais approuvé, mais la communauté 4337 et l'équipe principale d'Ethereum se réunissent pour élaborer une proposition qui satisfait tout le monde, tout comme 7702.

La voix de tous a été entendue et il n'y a pas eu de retournement de situation dramatique. Cela aurait été bien, alors pourquoi ne l'a-t-il pas été ?

Qu'est-ce qui s'est mal passé ?

En repensant à l’ensemble du processus, les deux parties se rejetaient la faute l’une sur l’autre.

Les développeurs du cœur d'Ethereum (et les auteurs de l'EIP-3074) pensent que c'est la faute des partisans de 4337 car ils n'ont pas participé activement au processus de discussion de tous les développeurs du cœur (ACD), dans lequel les EIP subissent de longues délibérations avant d'être acceptés et mis en œuvre par les équipes de développement client Ethereum telles que Geth.

Certains pensent que les partisans de la proposition 4337 auraient pu participer et exprimer leurs opinions lors de l’examen de la proposition 3074, plutôt que d’attendre que la proposition 3074 soit approuvée. Après tout, l’ensemble du processus de l’ACD est bien documenté, les réunions sont ouvertes à tous et des personnes comme Tim Beiko publient activement des tweets récapitulatifs après chaque réunion de l’ACD. Alors, si les partisans de la proposition 4337 se soucient tant de ce sujet, pourquoi ne participent-ils pas activement et rapidement aux réunions concernées ?

D’un autre côté, les membres principaux de 4337 ont souligné qu’ils avaient assisté aux réunions de l’ACD et s’étaient opposés autant que possible à 3074, mais les développeurs principaux d’Ethereum n’ont pas écouté. Quant aux membres de la communauté 4337, la plupart d’entre eux ont estimé que c’était soudain – beaucoup de gens pensaient que 3074 était déjà mort, et ils ne savaient même pas que 3074 était susceptible d’être approuvé.

De nombreuses personnes ont souligné que l'ensemble du processus de la réunion de l'ACD n'est pas transparent et n'est pas convivial pour ceux qui sont sérieux dans la communauté Ethereum mais qui ne peuvent pas suivre l'évolution des mises à jour de l'ACD en temps opportun. Certaines personnes pensent également que l'ACD devrait rechercher de manière proactive les commentaires des parties prenantes (ici en référence à la communauté 4337).

Cependant, je pense que les deux parties passent à côté de l’essentiel. Il y a un problème plus profond derrière tout cela, et si nous ne l’abordons pas ou au moins ne le reconnaissons pas, nous continuerons à avoir des accidents de gouvernance, les deux parties se rejetant la faute l’une sur l’autre, ce qui n’a aucun sens.

S’attaquer aux causes profondes des incidents : une feuille de route

Contrairement à la croyance populaire, la cause fondamentale de l'incident de gouvernance est que l'ACD n'est pas la seule source de pouvoir de gouvernance pour les mises à jour du protocole Ethereum, elle est remplacée par une autre source de pouvoir de gouvernance. Le problème ici est que bien que l'autre pouvoir de gouvernance ait une plus grande influence que l'ACD sur les problèmes fondamentaux d'Ethereum (tels que l'AA et l'évolutivité), il est rarement reconnu.

Dans cet article, j’appelle ce pouvoir une « feuille de route ».

Comme je le soulignerai ci-dessous, l’incident de défaillance de la gouvernance 3074-4337-7702 est un cas où la puissance de la feuille de route existante d’Ethereums supplante la puissance de l’ACD. Si nous parlons de gouvernance, lorsque nous remarquons qu’il existe une force invisible qui supplante la force visible, nous devrions être extrêmement inquiets à ce sujet, car les choses invisibles sont souvent difficiles à expliquer et ne peuvent pas être remarquées par trop de personnes, elles doivent donc être exposées.

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

Toute personne dans la communauté Ethereum doit avoir souvent vu le terme « feuille de route », par exemple dans la « feuille de route centrée sur le rollup », la « feuille de route ETH 2.0 », ou dans ce cas la « feuille de route AA ».

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

• Bob, un développeur principal : Je soutiens l'EIP-1234, qui propose d'augmenter la vitesse de production 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 : …êtes-vous fous ?

Réfléchissons-y. Pourquoi l'équipe principale d'Ethereum a-t-elle rejeté ce que Bob a dit ? Il a simplement proposé un moyen très raisonnable d'augmenter la capacité. Solana, Aptos, Sui et de nombreuses autres chaînes publiques l'ont fait et ont atteint un TPS élevé.

La raison est que cette EIP-1234 fictive viole la feuille de route d'expansion centrée sur le rollup d'Ethereum, qui souligne que pour la décentralisation, il est crucial que les utilisateurs ordinaires puissent exécuter des nœuds à faible coût. Par conséquent, l'EIP-1234 fictif ne peut pas être accepté car il augmentera considérablement le coût d'exécution des nœuds Ethereum.

Je voudrais utiliser cet exemple pour illustrer que les développeurs principaux qui participent au processus de gouvernance de l'ACD et décident des mises à jour du protocole sont guidés par une force de niveau supérieur, que j'appelle la feuille de route. Actuellement, il existe des feuilles de route de mise à l'échelle, des feuilles de route AA, des feuilles de route MEV, etc., qui constituent ensemble la feuille de route globale d'Ethereum, et les développeurs principaux doivent prendre des décisions en fonction de cela.

Lorsque les avis des développeurs principaux sont incompatibles avec 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 centrale s’y conformera. De plus, il n’existe pas de processus formel d’approbation des feuilles de route, de sorte que toutes les feuilles de route n’ont pas la même légitimité. Les chercheurs à l’origine de la feuille de route d’Ethereum doivent travailler dur pour promouvoir leurs feuilles de route auprès des développeurs principaux et de la communauté afin de gagner en légitimité et ainsi obtenir le soutien de l’équipe de développement principale d’Ethereum.

En ce qui concerne AA et l'abstraction des comptes, Vitalik lui-même a fait pression à plusieurs reprises pour une 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 ont plaidé en faveur d'une feuille de route AA centrée sur 4337 dans les forums et les réunions ACD.

Cependant, malgré ces efforts, certains développeurs du noyau Ethereum s'opposaient toujours fermement à la feuille de route AA centrée sur 4337. Ils pensaient que 7560 (la version native de 4337 qui sera implémentée par les clients Ethereum à l'avenir) était trop compliquée et n'était pas la seule solution viable pour la finalité AA. Au final, l'ACD a décidé d'approuver la proposition 3074, bien qu'elle ait été contestée par l'équipe 4337, qui pensait que 3074 diviserait l'ensemble de l'écosystème AA.

Après l'approbation du 3074, l'ensemble de la communauté 4337 a réagi avec force, forçant les développeurs du noyau Ethereum à se réengager dans la discussion sur le 3074. La discussion a alors atteint une impasse, ni l'auteur du 4337 ni l'auteur du 3074 n'ayant pu convaincre l'autre, et Vitalik a proposé EIP-7702 comme alternative au 3074 à la dernière minute, ce qui était explicitement compatible avec la fin de partie AA centrée sur le 4337, résolvant ainsi le conflit et faisant en sorte que le résultat final corresponde à la feuille de route AA.

Le rôle de Vitalik : le CTO de facto d'Ethereum

Bien que Vitalik se décrive comme un chercheur, l'histoire ci-dessus montre clairement que Vitalik a un pouvoir de gouvernance très différent de celui des autres chercheurs. La question est donc : quel rôle joue Vitalik dans la gouvernance d'Ethereum ?

Personnellement, je pense qu'il est probablement acceptable de considérer Vitalik comme le directeur technique d'une très, très grande entreprise (en supposant, soit dit en passant, que la « société » Ethereum n'a pas de PDG pour des raisons de contexte)

Si vous avez déjà travaillé dans une entreprise technologique de plus de 50 employés, vous savez qu'il est impossible pour le directeur technique d'être impliqué dans toutes les décisions techniques. Lorsqu'une entreprise atteint une certaine taille, le processus de prise de décision pour diverses solutions techniques doit être décentralisé. En général, chaque domaine du produit/de l'activité de l'entreprise dispose d'une équipe dédiée, et cette équipe est généralement libre de décider des détails de la solution.

De plus, le CTO n'est pas forcément le meilleur expert sur tous les sujets (ou sur aucun). Il peut y avoir dans l'entreprise des ingénieurs qui sont meilleurs que le CTO dans des domaines spécifiques, donc lorsque des détails techniques sont discutés, ce sont souvent les ingénieurs individuels qui prennent la décision finale.

Cependant, c'est le CTO qui définit la vision technique de l'entreprise. La mise en œuvre de cette 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, et il ne le peut pas. Il n'est pas un expert de haut niveau dans tous les domaines. Mais il a une influence écrasante sur la feuille de route de toutes les solutions clés d'Ethereum (mise à l'échelle, AA, POS...), non seulement en raison de son expertise technique, mais parce qu'il est le juge ultime de savoir si la feuille de route est conforme à la vision d'Ethereum (sa vision).

Chaque produit réussi commence par une vision

Si mon opinion selon laquelle Vitalik est le CTO d'Ethereum n'était pas assez controversée, voici la partie la plus controversée : nous devrions accepter Vitalik comme CTO.

En tant que fondateur de startup, je pense que tout produit à succès doit être soutenu par une vision cohérente à long terme. En effet, Ethereum est un produit car il résout de vrais problèmes pour de vrais utilisateurs. Et une vision cohérente doit être développée par un petit nombre de personnes, comme le fondateur d’une startup, et généralement par un seul fondateur.

La beauté d’Ethereum est que même s’il s’agit d’un système très complexe avec de nombreux composants, ces derniers s’assemblent parfaitement pour former un ordinateur décentralisé bien huilé qui règle des milliards de dollars de transactions chaque jour.

Nous sommes ici aujourd'hui non pas grâce à un projet de comité, mais grâce au leadership visionnaire de Vitalik, qui nous permet de construire l'Ethereum cohérent et beau qu'il est aujourd'hui. Ethereum était l'idée de Vitalik en 2015, et il l'est toujours aujourd'hui.

Bien entendu, cela ne veut pas dire que l'on doit négliger les contributions d'autres chercheurs et ingénieurs qui ont contribué en grande partie à faire d'Ethereum ce qu'il est aujourd'hui. Cependant, ce n'est pas une contradiction, car Ethereum est la réalisation de la vision de Vitalik, d'un ordre de grandeur supérieur à celle de n'importe qui d'autre.

Honnêtement, pouvez-vous vous plaindre de cela ? Bien que vous ayez été attiré par l'ouverture, la résistance à la censure et la rapidité d'innovation de l'écosystème Ethereum, vous en êtes-vous plaint à partir de la vision de Vitalik ? Peut-être que vous ne vous en êtes pas plaint parce que vous n'y avez pas pensé de cette façon - mais maintenant vous le faites, mais est-ce que le problème vous dérange vraiment ?

Comment résoudre la décentralisation ?

Mais, dites-vous, qu'en est-il de la décentralisation ? Si une seule personne a un pouvoir aussi écrasant sur Ethereum, comment peut-on dire qu'il est décentralisé ?

Pour répondre à cette question, il faut revenir à cet article classique sur la signification de la décentralisation, écrit par Vitalik. L’idée clé de l’article est qu’il existe trois types de décentralisation :

• Décentralisation architecturale : combien de nœuds doivent tomber en panne avant que le système cesse de fonctionner ?

• Décentralisation logique : les différents sous-systèmes du système peuvent-ils évoluer indépendamment tout en permettant au système global de fonctionner correctement, ou doivent-ils être étroitement coordonnés ?

• Décentralisation politique : combien de personnes ou d’organisations contrôlent en fin de compte le système ?

Sur la base de ces définitions, Ethereum est clairement décentralisé sur le plan architectural, et on peut dire qu'il est également décentralisé sur le plan logique en raison du manque de couplage fort entre ses composants (par exemple, la couche de consensus et la couche d'exécution).

En termes de décentralisation politique, la bonne nouvelle est qu’aucun individu ou organisation ne peut à lui seul fermer Ethereum, pas même Vitalik. Cependant, on pourrait affirmer qu’Ethereum n’est pas aussi décentralisé politiquement qu’on le pense, car Vitalik a joué un rôle majeur dans le développement de la vision et de la feuille de route d’Ethereum.

Cependant, je pense que si nous voulons qu’Ethereum continue d’innover, nous devons accepter Vitalik comme CTO de facto, même si cela signifie sacrifier une certaine décentralisation politique.

Si Ethereum se transforme réellement en une blockchain quasiment immuable comme Bitcoin, Vitalik pourrait bien se retirer. Mais avant d’atteindre cette étape finale, il est crucial de disposer d’une autorité respectée par toutes les parties, digne de confiance et capable de porter des jugements sur les décisions techniques en se basant non seulement sur la supériorité des solutions techniques proposées, mais aussi sur la cohérence de ces décisions avec la vision d’Ethereum.

Sans Vitalik, il n’y a que deux résultats possibles, et l’histoire entourant 3074 illustre parfaitement ces deux résultats :

• Le processus de gouvernance d'Ethereum peut se retrouver coincé dans une impasse sans fin, aucune des deux parties n'étant disposée à faire des compromis et personne n'étant capable de progresser, comme le démontre le débat 3074 qui a atteint une impasse avant l'intervention de Vitalik.

• Alternativement, Ethereum pourrait devenir un Frankenstein avec une conception incohérente. Les 3074 et 4337 susmentionnés pourraient ne pas céder l'un à l'autre, et finalement l'écosystème AA serait complètement divisé en deux espaces parallèles incompatibles.

Le rôle de la communauté

Après la réflexion ci-dessus, nous sommes sur le point d’esquisser un modèle de réflexion complet sur la gouvernance d’Ethereum, mais jusqu’à présent, il y a une omission flagrante dans notre discussion : la communauté.

Si Vitalik définit la vision d'Ethereum, les chercheurs définissent la feuille de route et les développeurs principaux mettent en œuvre la feuille de route, alors quel est le rôle de la communauté ? Ce n'est sûrement pas rien, n'est-ce pas ?

Heureusement, la communauté joue en réalité le rôle le plus important. La raison en est qu’avant d’avoir une vision, il y a d’abord les valeurs. Nous nous rassemblons en tant que communauté parce que nous nous unissons autour de certaines valeurs, et la vision de Vitalik doit en fin de compte s’aligner sur ces valeurs, sinon elle perdra le soutien de la communauté.

Nous sommes tous convaincus, au sein de la communauté Ethereum, qu'un ordinateur décentralisé, accessible à tous, résistant à la censure et digne 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, et ce faisant, nous donnons une légitimité à la vision, à la feuille de route et au code définis par Vitalik, les chercheurs et les développeurs principaux.

Modèle VVRC de gouvernance d'Ethereum

Voici donc le modèle mental complet de la gouvernance d'Ethereum, Valeurs ⇒ Vision ⇒ Feuille de route ⇒ Client, VVRC en abrégé :

• V==Valeurs==Communauté;

• V==Vision==Vitalik;

• R==Feuille de route==Chercheurs;

• C==Client==Développeurs principaux ;

Ensemble, ils remplissent les fonctions suivantes :

• Les communautés se rassemblent autour de certaines valeurs.

• Vitalik a exprimé une vision cohérente avec ces valeurs.

• Les chercheurs élaborent une feuille de route basée sur la vision.

• Les développeurs principaux implémentent le client conformément à la feuille de route.

Bien sûr, la réalité est bien plus complexe que ce que tout modèle simple peut saisir. En fait, les développeurs principaux d'Ethereum sont les seuls à pouvoir réellement voter sur toute proposition par le biais de modifications du code client. Vitalik et d'autres chercheurs ne jouent qu'un rôle consultatif, et parfois leurs avis ne sont pas acceptés par les développeurs principaux, c'est pourquoi l'EIP-3074 a été approuvé.

Cela étant dit, je pense que le modèle VVRC capture raisonnablement le fonctionnement du modèle de gouvernance d'Ethereum dans des circonstances normales, et nous devons « déboguer » le processus afin qu'il ne se reproduise plus comme EIP-3074.

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 l’améliorer.

• Il faut améliorer la visibilité des avancées des discussions sur les EIP à l'étude. L'ensemble de la communauté ne doit pas s'étonner de l'acceptation d'un EIP et l'approbation surprise de propositions comme la 3074 ne doit plus se reproduire.

Le statut actuel de l'EIP sur le site Web de l'EIP ne reflète pas son statut dans le processus ACD. C'est pourquoi il est toujours indiqué que le 3074 est en cours de révision, même si les développeurs principaux ont voté pour l'approuver et qu'il n'y a aucune indication qu'il ait même été envisagé pour approbation en premier lieu.

Idéalement, lorsqu'un EIP est sur le point d'être accepté, la Fondation Ethereum l'annoncerait haut et fort sur les réseaux sociaux pour sensibiliser 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 était le cas des communautés 3074 et 4337. Étant donné que les réunions ACD sont limitées dans le temps et doivent être coordonnées entre les fuseaux horaires, les réunions permettent souvent uniquement au « personnel concerné » de s’exprimer.

Cela étant dit, il serait logique d’allouer occasionnellement du temps de parole aux membres de la communauté pour qu’ils puissent commenter les impacts en aval de certaines propositions du PEI si elles étaient adoptées.

Si les chercheurs estiment que leurs opinions ne sont pas acceptées par les développeurs principaux, comme ce fut le cas avec 4337, ils peuvent impliquer les membres de la communauté pour renforcer leurs revendications.

• Il est essentiel que les développeurs et les chercheurs du noyau dur se reconnaissent mutuellement comme faisant partie du pouvoir de gouvernance d'Ethereum, malgré leurs différents niveaux de pouvoir. Le pouvoir des développeurs du noyau dur d'apporter des modifications et des mises à jour au client Ethereum est le seul pouvoir qui peut « voter » pour apporter des modifications au protocole lui-même. Le pouvoir des chercheurs d'apporter des modifications et des interprétations de la feuille de route bénéficie souvent d'un plus grand soutien public, grâce aux chercheurs qui parlent et écrivent activement sur leurs idées.

Lorsque ces deux forces entrent en conflit, les développeurs principaux peuvent être enclins à tout simplement passer outre les chercheurs, comme ce fut le cas lorsque les développeurs principaux ont passé outre les objections de l'équipe 4337. Cependant, un tel renversement peut conduire à un conflit, car les deux forces deviennent instables lorsqu'elles entrent en conflit, comme l'ont montré les événements dramatiques survenus après l'approbation de 3074.

De même, face à la résistance, les chercheurs peuvent être tentés d’abandonner la collaboration avec les développeurs principaux, ce qui, à mon avis, est l’une des raisons pour lesquelles le processus RIP a été créé et pourquoi l’AA natif (7560) est désormais promu principalement comme un RIP plutôt qu’un EIP.

Bien qu'il y ait de réels avantages à expérimenter des mises à jour de protocole sur L2 qui sont controversées pour L1, nous ne pouvons pas considérer les RIP comme un substitut à la participation au processus de gouvernance EIP. Les chercheurs doivent continuer à travailler avec les développeurs principaux jusqu'à ce que les valeurs des deux parties soient entièrement alignées sur la feuille de route.

en conclusion

L'incident 3074/7702 a révélé comment fonctionne réellement la gouvernance d'Ethereum : en plus du pouvoir de gouvernance explicite du processus EIP/ACD piloté par les développeurs principaux, il existe également le pouvoir de gouvernance implicite de la feuille de route pilotée par les chercheurs. Lorsque ces pouvoirs sont mal placés, nous assistons à des blocages et à des coups de fouet, et une autre force – Vitalik – peut être nécessaire pour rompre l'équilibre d'une manière ou d'une autre.

Nous proposons ensuite que Vitalik représente une force unique, la « vision » d’Ethereum, qui est fondamentale pour 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 maintienne le rythme de l’innovation, ce qui peut empêcher Ethereum de dégénérer en un monstre patchwork de type « Frankenstein ».

Enfin, nous avons proposé un modèle VVRC qui décrit le modèle de gouvernance d'Ethereum : Valeurs (communauté) ⇒ Vision (Vitalik) ⇒ Feuille de route (chercheurs) ⇒ Clients (développeurs principaux). Nous avons ensuite proposé différentes manières de corriger les bugs de ce modèle.

La gouvernance d’Ethereum est la machine qui fait la machine – pour qu’Ethereum fonctionne correctement, nous devons avoir une gouvernance raisonnable. Par conséquent, 3074 fournit un cas précieux d’accidents de gouvernance, et j’espère que la communauté Ethereum pourra en tirer des leçons utiles afin d’améliorer le futur processus de gouvernance d’Ethereum.

Lien d'origine

Cet article provient d'Internet : Sur l'impact de Vitalik et de diverses feuilles de route sur le processus de gouvernance d'Ethereum

En lien : Analyse macroéconomique de SignalPlus (20240506) : Les actifs à risque ont une chance de recommencer à grimper lentement

Pour la première fois cette année, les données sur l’emploi ont été inférieures aux attentes (sans augmentation surprise), avec une variation globale de l’emploi de +175 000 (la hausse moyenne précédente était d’environ 275 000), et le taux de chômage a également augmenté de manière inattendue de 3 83% à 3 87%. D’autres indicateurs du marché du travail à plus haute fréquence commencent également à montrer des signes de ralentissement, comme le récent rapport JOLTS qui montre un ratio plus faible d’offres d’emploi par rapport aux chômeurs, et des embauches et des démissions dans le secteur privé à des niveaux pluriannuels les plus bas. En outre, les tendances d’embauche dans les petites entreprises se sont considérablement affaiblies, les composantes de l’emploi de l’ISM et du PMI affichant toutes deux une faiblesse, et la part des entreprises de services et de fabrication embauchant tombant à des niveaux généralement observés en période de récession. Vendredi dernier, nous avons souligné que les données sur les salaires non agricoles étaient plus susceptibles de…