Sur l'influence de Vitalik et des différentes feuilles de route sur le processus de gouvernance d'Ethereum
TechFlow SélectionTechFlow Sélection
Sur l'influence de Vitalik et des différentes feuilles de route sur le processus de gouvernance d'Ethereum
La feuille de route technique est une force centrale négligée dans la gouvernance d'Ethereum, et le rôle de Vitalik correspond davantage à celui d'un directeur technique (CTO).
Dédié à des analyses Web3 approfondiesRédaction : Derek Chiang, PDG de ZeroDev
Traduction : Faust, Geek web3
Résumé : Cet article présente les réflexions de Derek Chiang, PDG de ZeroDev, suite à la proposition par Vitalik Buterin de l’EIP-7702 visant à concilier ERC-4337 et EIP-3074. À travers le prisme d’un fondateur actif dans l’écosystème AA (comptes abstraits), il expose objectivement les problèmes actuels du modèle de gouvernance d’Ethereum. Il met en lumière un point crucial :
L’une des contradictions fondamentales dans la gouvernance d’Ethereum provient du désaccord entre la feuille de route définie par les chercheurs et l’avis des équipes de développement des clients comme Geth, avec Vitalik qui agit alors comme arbitre ultime, jouant un rôle similaire à celui d’un directeur technique (CTO).
Après avoir salué le rôle de Vitalik, Derek propose des améliorations au modèle de gouvernance d’Ethereum, offrant ainsi des enseignements précieux tant pour la communauté Ethereum que pour celle de Bitcoin.
Texte principal : Si vous n’êtes pas familier avec les événements récents liés à l’AA (abstraction des comptes) sur Ethereum, voici un bref rappel :
Il y a quelques semaines, la proposition EIP-3074 a été approuvée par les principaux développeurs d’Ethereum et devrait être intégrée lors de la prochaine bifurcation dure « Pectra ». Cette proposition ajoute deux nouveaux opcodes à l’EVM, permettant aux comptes EOA d’Ethereum de bénéficier d’une expérience quasi-native d’AA.
Depuis, de nombreux membres de la communauté ERC-4337, notamment ses initiateurs, s’opposent fortement à l’EIP-3074, arguant qu’il introduit de graves risques de sécurité et est incompatible avec la feuille de route AA d’Ethereum. Dans cette feuille de route, c’est clairement ERC-4337 et des propositions similaires comme 7560 (surnommé « nativeAA ») qui sont au centre.
Début mai, Vitalik a proposé l’EIP-7702 comme alternative à l’EIP-3074, trouvant un compromis entre 4337 et 3074 : il permet aux utilisateurs EOA de profiter de fonctionnalités AA tout en étant davantage compatible avec ERC-4337 et conforme à la solution finale prévue, l’EIP-7560.
Actuellement, les développeurs principaux d’Ethereum examinent sérieusement l’EIP-7702. Les discussions initiales et le sentiment général indiquent que l’EIP-7702 remplacera probablement l’EIP-3074 mentionné précédemment.
Personnellement, je suis très satisfait de ce résultat : les utilisateurs EOA pourront bientôt accéder aux produits de l’écosystème ERC-4337 et profiter pleinement des avantages de l’AA. Toutefois, je ne peux m’empêcher de penser que nous aurions pu atteindre ce résultat plus efficacement. Beaucoup ont souligné ces dernières semaines que nous aurions pu économiser beaucoup d’efforts et aboutir plus rapidement avec un meilleur processus de gouvernance.
Dans cet article, je souhaite :
-
Identifier où le processus de gouvernance a dysfonctionné
-
Proposer un modèle mental pour comprendre la gouvernance d’Ethereum
-
Suggérer des améliorations pour éviter de futures crises de gouvernance
Résumé et analyse de l’affaire EIP-3074
L’histoire racontée ci-dessus a déçu de nombreuses personnes pour les raisons suivantes :
L’EIP-3074 a mis plusieurs années à être approuvé. C’est seulement après son approbation que les développeurs principaux ont reçu une opposition forte de la part de la communauté 4337.
D’un autre côté, les auteurs d’ERC-4337 ont exprimé à plusieurs reprises leurs inquiétudes concernant l’EIP-3074 auprès de l’équipe principale d’Ethereum, sans succès. Aujourd’hui, Ethereum envisage d’annuler l’approbation de l’EIP-3074 et de le remplacer par un autre EIP (7702).
Aucun de ces éléments n’est intrinsèquement erroné :
-
Des discussions autour d’un EIP peuvent durer plusieurs années – cela est normal.
-
Qu’un EIP soit finalement rejeté après approbation est également possible.
-
Si de nouveaux problèmes sont découverts, une approbation peut être révoquée même après validation.
Cependant, les choses auraient pu se passer plus harmonieusement. Imaginons le scénario suivant :
Pendant les discussions sur l’EIP-3074, la communauté 4337 interagit activement avec les développeurs principaux. Deux issues possibles :
-
Après prise en compte des retours de la communauté 4337, l’EIP-3074 est approuvé (peut-être modifié). La communauté accepte alors la décision, et aucune annulation n’est nécessaire.
-
Ou bien, l’EIP-3074 n’est jamais approuvé, mais la communauté 4337 et les développeurs principaux co-construisent ensemble une proposition satisfaisante pour tous, comme ce fut le cas avec l’EIP-7702.
Toutes les voix auraient été entendues, sans revirement spectaculaire. Ce serait idéal – alors pourquoi cela ne s’est-il pas produit ?
Où est le problème ?
En repassant en revue les événements, chaque partie accuse l’autre.
Les développeurs principaux (ainsi que les auteurs de l’EIP-3074) considèrent que c’est la faute des « partisans de 4337 », qui n’ont pas participé activement au processus de discussion des développeurs principaux (ACD), durant lequel les EIP sont longuement examinés avant d’être adoptés et implémentés par des clients comme Geth.
On leur fait remarquer que pendant l’examen de l’EIP-3074, les « partisans de 4337 » auraient pu intervenir pour faire entendre leur voix, plutôt que d’intervenir trop tard après l’approbation. Le processus ACD est entièrement documenté, ouvert à tous, et des synthèses sont régulièrement publiées par des figures comme TimBeiko. Alors, si les partisans de 4337 tenaient tant à ce sujet, pourquoi n’ont-ils pas participé activement et en temps voulu ?
D’un autre côté, les membres clés de 4337 affirment qu’ils assistaient aux réunions ACD et s’opposaient autant que possible à l’EIP-3074, mais que leurs avis étaient ignorés. Quant à la communauté 4337, elle a été largement prise au dépourvu – beaucoup pensaient que l’EIP-3074 était mort, ignorant même qu’il était sur le point d’être approuvé.
Beaucoup soulignent que le processus ACD manque de transparence, rendant difficile pour les contributeurs actifs mais moins connectés l’accès à l’information. Certains pensent aussi que l’ACD devrait systématiquement consulter les parties prenantes (ici, la communauté 4337) en amont.
Pourtant, je pense que ni l’une ni l’autre partie ne touche le cœur du problème. Une question plus profonde demeure. Tant que nous ne la reconnaîtrons pas ou ne la résoudrons pas, nous continuerons à subir des crises de gouvernance, chacun s’accusant mutuellement, sans avancer.
Cause fondamentale des incidents de gouvernance : la feuille de route
Contrairement à une idée reçue, la source des incidents de gouvernance n’est pas que l’ACD soit la seule autorité en matière de mise à jour du protocole. En réalité, elle est supplantée par une autre forme de pouvoir. Le problème, c’est que ce second pouvoir exerce une influence encore plus grande que l’ACD sur les sujets centraux (comme l’AA ou l’évolutivité), sans être officiellement reconnu.
Dans cet article, j’appelle cette force la « feuille de route ».
Comme je vais le montrer, l’échec de gouvernance autour des EIP 3074, 4337 et 7702 illustre parfaitement comment le pouvoir de la « feuille de route » a dominé celui de l’ACD. Quand on parle de gouvernance, on doit s’inquiéter lorsque des forces invisibles surpassent des structures formelles, car elles sont difficiles à expliquer, peu visibles, et doivent donc être exposées.
Qu’est-ce qu’une feuille de route ?
Tout membre de la communauté Ethereum a déjà rencontré le terme « feuille de route », par exemple dans « feuille de route centrée sur les rollups », « feuille de route ETH2.0 » ou, lié à cet incident, « feuille de route AA ».
Pour illustrer mon propos, imaginons une réunion ACD où les développeurs discutent de l’évolutivité d’Ethereum :
-
Un développeur Bob : Je soutiens l’EIP-1234, qui propose de multiplier par 10 la vitesse de création des blocs, par 10 la taille des blocs, et de diviser par 100 les frais.
-
Autres développeurs : … Tu es fou ?
Pourquoi l’équipe principale rejette-t-elle cette suggestion ? Elle semble techniquement viable, et des blockchains comme Solana, Aptos ou Sui l’ont adoptée avec succès.
La raison est que cet EIP fictif contredit la feuille de route d’Ethereum « centrée sur les rollups », qui stipule que la décentralisation exige que tout utilisateur puisse exécuter un nœud à bas coût. L’EIP-1234 hypothétique serait donc inacceptable car il augmenterait drastiquement le coût d’exécution d’un nœud Ethereum.
Cet exemple montre que les développeurs participant à l’ACD sont guidés par une force supérieure que j’appelle la « feuille de route ». Ces feuilles de route (évolutivité, AA, MEV, etc.) forment ensemble la vision globale d’Ethereum, que les développeurs doivent suivre pour prendre leurs décisions.
Quand les développeurs s’opposent à la feuille de route
Puisque la feuille de route n’est pas une composante formelle du processus de gouvernance, rien ne garantit que l’équipe principale la respecte. Il n’existe pas de procédure officielle pour « approuver » une feuille de route, donc toutes les feuilles de route n’ont pas la même légitimité. Les chercheurs doivent convaincre activement les développeurs et la communauté pour que leur feuille de route acquière une reconnaissance suffisante.
Concernant l’AA, Vitalik lui-même a souvent plaidé pour une feuille de route centrée sur 4337, mais surtout, c’est l’équipe derrière 4337, notamment Yoav et Dror, qui a défendu cette vision dans les forums et réunions ACD.
Malgré ces efforts, certains développeurs principaux d’Ethereum restent hostiles à une feuille de route centrée sur 4337. Ils jugent que 7560 (version native future de 4337) est trop complexe et ne constitue pas la seule solution viable pour l’AA. Finalement, l’ACD a décidé d’approuver l’EIP-3074, malgré l’opposition de l’équipe 4337, qui craint une fragmentation de l’écosystème AA.
Après l’approbation de l’EIP-3074, toute la communauté 4337 a réagi vivement, forçant les développeurs principaux à rouvrir le débat. Celui-ci s’est enlisé, ni l’équipe 4337 ni celle de 3074 ne parvenant à convaincre l’autre. Vitalik est alors intervenu in extremis avec l’EIP-7702, une alternative compatible avec la « fin de partie » AA centrée sur 4337, permettant de résoudre le conflit et de réaligner le résultat avec la feuille de route.
Le rôle de Vitalik : CTO de facto d’Ethereum
Bien que Vitalik se considère chercheur, l’histoire ci-dessus montre clairement qu’il détient un pouvoir de gouvernance différent et supérieur à celui des autres chercheurs. D’où la question : quel rôle joue Vitalik dans la gouvernance d’Ethereum ?
Personnellement, je pense qu’il est raisonnable de voir en Vitalik le CTO d’une très grande entreprise (précisons que, pour coller à la réalité, cette « entreprise » Ethereum n’a pas de PDG).
Si vous avez travaillé dans une entreprise tech de plus de 50 employés, vous savez que le CTO ne peut pas décider de chaque détail technique. À une certaine échelle, les décisions techniques doivent être décentralisées – chaque domaine a son équipe spécialisée, libre de choisir les détails.
De plus, le CTO n’est pas forcément l’expert absolu sur tous les sujets. Des ingénieurs peuvent être plus compétents que lui dans certains domaines. Ainsi, les décisions techniques sont souvent prises par les experts de terrain.
Cependant, le CTO définit la vision technique. Son exécution est confiée aux développeurs.
Ce parallèle n’est pas parfait, mais il résume assez bien le rôle de Vitalik dans l’écosystème Ethereum. Il ne participe pas à chaque décision technique – il ne le pourrait pas. Il n’est pas non plus expert en tout. Mais il exerce une influence prépondérante sur la feuille de route des grandes innovations (évolutivité, AA, PoS…), non seulement grâce à son expertise, mais aussi parce qu’il incarne le juge ultime de la conformité avec la vision d’Ethereum – sa vision.
Tout produit réussi commence par une vision
Si le fait de voir en Vitalik un CTO ne suffisait pas à susciter la controverse, voici la partie la plus polémique : nous devrions accepter que Vitalik occupe ce rôle de CTO.
En tant que fondateur de startup, je crois fermement qu’un produit réussi repose sur une vision cohérente à long terme – oui, Ethereum est un « produit », car il résout des problèmes concrets pour de vrais utilisateurs. Une telle vision doit être portée par peu de personnes, souvent un seul fondateur.
La beauté d’Ethereum réside dans le fait que, malgré sa complexité et ses nombreux composants, ceux-ci s’assemblent parfaitement en un ordinateur décentralisé performant, traitant quotidiennement des milliards de dollars de transactions.
Nous sommes arrivés là non par des comités de conception, mais grâce au leadership visionnaire de Vitalik, qui a permis de construire un système aussi cohérent et élégant. Ethereum reste fidèle à l’idée originale de Vitalik en 2015.
Bien sûr, cela ne diminue en rien la contribution cruciale des autres chercheurs et ingénieurs. Pourtant, Ethereum reste avant tout la réalisation de la vision de Vitalik, d’une ampleur incomparable avec celles des autres.
Franchement, pouvez-vous vraiment vous plaindre ? Quand vous êtes attiré par l’ouverture, la résistance à la censure et la rapidité d’innovation de l’écosystème Ethereum, critiquez-vous le fait que tout parte de la vision de Vitalik ? Peut-être que non, car vous n’y aviez jamais pensé – maintenant si, mais est-ce vraiment un problème ?
Et la décentralisation dans tout ça ?
Mais, direz-vous, qu’en est-il de la décentralisation ? Si une seule personne détient un tel pouvoir, comment pouvons-nous parler de décentralisation ?
Pour répondre, rappelons-nous cet article classique de Vitalik sur les trois types de décentralisation :
-
Décentralisation architecturale : Combien de nœuds doivent tomber en panne pour que le système s’arrête ?
-
Décentralisation logique : Les sous-systèmes peuvent-ils évoluer indépendamment sans compromettre le système global, ou doivent-ils être fortement coordonnés ?
-
Décentralisation politique : Combien de personnes ou d’organisations contrôlent le système ?
Selon ces critères, Ethereum est clairement décentralisé architecturalement, et probablement aussi logiquement, grâce à la faible couplage entre ses composants (couche de consensus vs couche d’exécution).
Sur le plan politique, le bon côté est qu’aucune entité ne peut arrêter Ethereum, pas même Vitalik. Pourtant, on peut considérer que la décentralisation politique est moindre qu’imaginé, car Vitalik joue un rôle central dans la définition de la vision et de la feuille de route.
Cependant, je pense que si nous voulons qu’Ethereum continue à innover, nous devons accepter que Vitalik joue le rôle de CTO de facto, même au prix d’un certain sacrifice en décentralisation politique.
Si Ethereum devenait aussi rigide que Bitcoin, presque immuable, alors oui, Vitalik pourrait prendre sa retraite. Mais jusqu’à ce stade final, il est essentiel d’avoir une autorité reconnue, fiable, capable de trancher les décisions techniques non seulement selon leur qualité technique, mais aussi selon leur alignement avec la vision d’Ethereum.
Sans une figure comme Vitalik, deux scénarios seulement sont possibles, illustrés par l’affaire 3074 :
-
La gouvernance pourrait stagner dans un conflit permanent, aucune partie ne cédant, et aucun progrès n’étant possible – exactement ce qui s’est produit avant l’intervention de Vitalik.
-
Ou bien, Ethereum deviendrait un « Frankenstein » technologique incohérent. Comme redouté, 3074 et 4337 pourraient coexister, divisant l’écosystème AA en deux mondes incompatibles.
Le rôle de la communauté
Après cette réflexion, nous avons presque complété notre modèle de gouvernance d’Ethereum, mais une pièce manque encore : la communauté.
Si Vitalik définit la vision, les chercheurs la feuille de route, et les développeurs l’implémentent, quel est le rôle de la communauté ? Elle ne peut pas être passive ?
Heureusement, la communauté joue le rôle le plus important. Car avant la vision, il y a les valeurs. Nous formons une communauté parce que nous partageons certaines valeurs. La vision de Vitalik doit rester alignée avec ces valeurs, sinon elle perdra le soutien communautaire.
Tout le monde dans la communauté Ethereum croit qu’un ordinateur décentralisé, accessible, inviolable et neutre est bénéfique pour le monde. Chaque jour, par nos actions sur Ethereum, nous affirmons ces valeurs, et c’est ainsi que nous donnons légitimité à la vision, à la feuille de route et au code proposés par Vitalik, les chercheurs et les développeurs.
Le modèle VVRC de gouvernance d’Ethereum
Voici donc le modèle complet de gouvernance d’Ethereum : Valeurs ⇒ Vision ⇒ Feuille de route ⇒ Client, ou VVRC :
-
V == Valeurs == Communauté ;
-
V == Vision == Vitalik ;
-
R == Feuille de route == Chercheurs ;
-
C == Client == Développeurs principaux ;
Ils interagissent ainsi :
-
La communauté s’unifie autour de certaines valeurs.
-
Vitalik exprime une vision cohérente avec ces valeurs.
-
Les chercheurs conçoivent une feuille de route à partir de cette vision.
-
Les développeurs implémentent les clients selon cette feuille de route.
Bien sûr, la réalité est plus complexe que tout modèle simple. En effet, seuls les développeurs principaux peuvent véritablement « voter » sur une proposition via des modifications du code client. Vitalik et les chercheurs n’ont qu’un rôle consultatif, et leurs avis peuvent être ignorés – c’est ce qui s’est produit avec l’approbation de l’EIP-3074.
Néanmoins, je pense que le modèle VVRC reflète fidèlement le fonctionnement habituel de la gouvernance d’Ethereum, et que nous devons « débugger » ce processus pour éviter de futurs accidents comme celui de l’EIP-3074.
Comment améliorer la gouvernance d’Ethereum
Maintenant que nous avons un modèle mental du fonctionnement de la gouvernance d’Ethereum, voici quelques suggestions pour l’améliorer :
-
Améliorer la visibilité de l’avancement des discussions sur les EIP en cours d’examen. La communauté ne devrait jamais être surprise par l’approbation d’un EIP. Des situations comme celle de l’EIP-3074 ne doivent plus se reproduire.
Actuellement, l’état d’un EIP sur le site officiel ne reflète pas son statut réel dans le processus ACD. Par exemple, l’EIP-3074 est toujours marqué comme « en révision », bien qu’il ait été approuvé, sans indication claire qu’il était sérieusement envisagé.
Idéalement, la Fondation Ethereum devrait annoncer publiquement et clairement sur les réseaux sociaux quand un EIP est sur le point d’être adopté, afin d’accroître la sensibilisation communautaire.
-
Parfois, les développeurs sous-estiment l’impact d’un EIP sur les projets et utilisateurs en aval, comme avec 3074 et 4337. En raison des contraintes temporelles et horaires des réunions ACD, seules les parties « directement concernées » prennent la parole.
Cela justifie d’allouer ponctuellement du temps de parole à des membres de la communauté pour commenter l’impact potentiel d’un EIP sur l’écosystème.
Si les chercheurs sentent que leurs opinions sont ignorées, comme dans le cas de 4337, ils peuvent mobiliser la communauté pour renforcer leur position.
-
Il est crucial que développeurs et chercheurs reconnaissent mutuellement leur rôle dans la gouvernance, malgré leurs différences de pouvoir. Les développeurs détiennent le droit exclusif de modifier les clients, ce qui équivaut à un « vote » direct sur le protocole. Les chercheurs, quant à eux, influencent fortement l’opinion publique grâce à leurs publications et discours sur la feuille de route.
Lorsque ces deux forces entrent en conflit, les développeurs ont tendance à ignorer les chercheurs, comme avec l’EIP-3074. Mais cela crée des tensions, car le système devient instable – ce que l’approbation de 3074 a démontré.
Inversement, face à la résistance, les chercheurs peuvent être tentés d’abandonner la collaboration, ce qui explique peut-être la création du processus RIP, et pourquoi l’AA natif (7560) est désormais promu via RIP plutôt que par EIP.
Bien qu’il soit utile de tester sur L2 des mises à jour controversées pour L1, nous ne devons pas voir le RIP comme un substitut au processus EIP. Les chercheurs doivent continuer à collaborer avec les développeurs jusqu’à ce que leurs visions soient pleinement alignées.
Conclusion
L’affaire 3074/7702 révèle le fonctionnement réel de la gouvernance d’Ethereum : au
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@godrealmx
