Réflexion sur la gouvernance d'Ethereum : pourquoi tout le monde est-il mécontent concernant l'incident de l'EIP-3074 ?
TechFlow SélectionTechFlow Sélection
Réflexion sur la gouvernance d'Ethereum : pourquoi tout le monde est-il mécontent concernant l'incident de l'EIP-3074 ?
L'événement relatif aux EIP-3074/EIP-7702 d'Ethereum a révélé la complexité de sa structure de gouvernance : outre les processus formels de gouvernance, les feuilles de route informelles proposées par les chercheurs exercent également une grande influence.
Dédié à des analyses Web3 approfondiesRédaction : Bu Lu Shuo
Cet article présente mes réflexions sur l'incident récent concernant l'EIP-3047. Je remercie Vitalik et Yoav pour leur relecture du contenu.
Si vous n'êtes pas au courant de cet événement, voici un bref rappel :
Il y a peu, la proposition EIP-3074 a reçu le feu vert des développeurs principaux (core developers) et devait être intégrée lors de la prochaine bifurcation d’Ethereum, Pectra. Cette proposition visait à permettre aux utilisateurs ordinaires de comptes Ethereum (EOA) de bénéficier des avantages de l'abstraction de compte (Account Abstraction, souvent abrégé AA).
Cependant, la communauté ERC-4337, notamment les auteurs de cette proposition, s'est fermement opposée à l'EIP-3074, arguant principalement que ce dernier pourrait accroître les risques de centralisation et qu’il est incompatible avec la feuille de route de l’abstraction de compte d’Ethereum, dont le cœur est constitué par l’EIP-4337 et son proche parent, l’EIP-7560 (aussi appelé « comptes abstraits natifs »).
La semaine dernière, Vitalik a proposé l’EIP-7702 comme alternative à l’EIP-3074. Ce nouveau projet vise également à offrir aux utilisateurs EOA les bénéfices de l’abstraction de compte, mais il est conçu pour mieux s’aligner sur la norme actuelle EIP-4337 et assurer une transition fluide vers sa forme finale — l’EIP-7560.
Nota bene : ERC-4337 et ERC-7560 sont deux propositions liées à l’abstraction de compte dans l’écosystème Ethereum, visant à améliorer la gestion des comptes et les interactions utilisateur, tout en renforçant l’expérience et la sécurité.
ERC-4337 permet aux utilisateurs de gérer leurs comptes via un contrat proxy, réduisant ainsi la complexité et les risques lors des interactions avec les DApps. ERC-7560, quant à lui, cherche à intégrer directement dans la couche fondamentale d’Ethereum les concepts portés par ERC-4337, afin que tous les comptes soient naturellement dotés de capacités d’abstraction, assurant une intégration plus profonde et des optimisations accrues.
ERC-4337 constitue une étape clé vers ERC-7560 ; ensemble, elles forment le pilier central de la feuille de route de l’abstraction de compte d’Ethereum.
Actuellement, l'équipe des développeurs principaux examine l’EIP-7702. Des signes précoces et des retours communautaires indiquent que l’EIP-7702 remplacera probablement l’EIP-3074 lors de la bifurcation Pectra.
Sur le fond, je suis très satisfait de ce résultat : les utilisateurs EOA pourront bientôt bénéficier de la majorité des avantages de l’abstraction de compte grâce aux outils et infrastructures développés pour ERC-4337.
Pourtant, le chemin parcouru jusqu’à ce point me laisse un goût amer. Il me semble loin d’être optimal, une impression partagée par beaucoup ces derniers temps. Je suis convaincu qu’avec un processus mieux structuré, nous aurions pu réduire les tensions et atteindre un consensus plus rapidement.
Dans cet article, j’ai l’intention de :
-
analyser les problèmes apparus durant le processus,
-
proposer un cadre de pensée pour comprendre la gouvernance d’Ethereum,
-
explorer comment améliorer les choses pour éviter de revivre de tels incidents à l’avenir.
Pourquoi tant de mécontentement ?
Cet épisode a suscité un fort mécontentement chez de nombreuses personnes, pour plusieurs raisons :
-
Un processus interminable : l’EIP-3074 a mis des années avant d’obtenir finalement le feu vert.
-
Des retours tardifs : les développeurs principaux n’ont largement entendu les objections venant de la communauté ERC-4337 qu’après l’approbation de l’EIP-3074.
-
Des alertes ignorées : malgré plusieurs mises en garde formulées par les auteurs d’ERC-4337 auprès des développeurs principaux, leurs inquiétudes ont été largement ignorées.
-
Un changement de cap : nous sommes désormais confrontés à l’annulation de l’EIP-3074 au profit de l’EIP-7702.
Objectivement, chacune de ces étapes, prise isolément, n’est pas nécessairement incorrecte :
-
Des discussions longues sont légitimes.
-
Rencontrer une opposition après approbation est normal.
-
Ajuster ou annuler une décision face à de nouveaux éléments est logique.
Néanmoins, nous pouvons sans doute convenir que ce processus aurait pu être plus fluide. Imaginons plutôt ce qui aurait pu se passer :
Durant les discussions sur l’EIP-3074 par les développeurs principaux, la communauté ERC-4337 aurait activement participé. Deux scénarios possibles alors :
-
Soit l’EIP-3074 était approuvé après avoir pris en compte les retours de la communauté ERC-4337 (peut-être modifié), ce qui aurait conduit cette dernière à soutenir la proposition, évitant ainsi de devoir revenir dessus.
-
Soit l’EIP-3074 n’était jamais approuvé, mais les développeurs principaux et la communauté ERC-4337 collaboraient pour avancer une proposition consensuelle, comme cela a été le cas avec l’EIP-7702.
Chaque voix aurait été entendue, sans rebondissements dramatiques. C’eût été un dénouement idéal — mais pourquoi ne s’est-il pas produit ?
Où est le problème ?
En repassant en revue le processus, les deux camps s’accusent mutuellement.
Les développeurs principaux (y compris les auteurs de l’EIP-3074) estiment que si l’équipe ERC-4337 s’était davantage impliquée dans le processus des All Core Devs (ACD), ce problème n’aurait pas eu lieu.
Ce processus exige de longues discussions publiques, suivies de l’adoption par les équipes clientes puis intégration au protocole. Selon eux, l’équipe ERC-4337 aurait pu intervenir à tout moment pour exprimer ses préoccupations, plutôt que d’attendre que l’EIP-3074 soit approuvé. Après tout, le processus ACD est transparent, ouvert, et des personnes comme Tim Beiko résument chaque réunion sur Twitter. Si l’équipe ERC-4337 tenait vraiment à cette question, pourquoi n’a-t-elle pas investi du temps pour participer ?
Inversement, l’équipe d’abstraction de compte (les auteurs d’ERC-4337) affirme avoir participé aux réunions ACD et avoir régulièrement exprimé son opposition à l’EIP-3074, sans que cela soit pris en compte. En outre, nombreux étaient ceux au sein de la communauté ERC-4337 à croire que l’EIP-3074 avait été abandonné, voire ignoraient qu’il était encore envisagé.
Certains soulignent aussi que le processus ACD est trop complexe pour des personnes ayant un emploi à plein temps, incapables de suivre chaque mise à jour. D’autres pensent que solliciter activement les avis des parties prenantes clés (comme la communauté ERC-4337) devrait être la responsabilité des développeurs principaux.
À mon sens, aucun camp n’a pleinement identifié le véritable problème. Une question plus profonde est en jeu : à moins de la reconnaître et de l’affronter, nous continuerons à connaître des échecs de gouvernance et à tomber dans des querelles stériles.
Le vrai problème
L’échec de gouvernance réside dans une mauvaise compréhension généralisée du rôle des All Core Devs. Ce groupe n’est pas la seule force décisionnelle dans les mises à jour du protocole. Dans ce cas précis, une autre force de gouvernance a en réalité surpassé les All Core Devs et joué un rôle décisif.
Le problème est que cette force cruciale, bien qu’influent sur des questions majeures comme l’abstraction de compte ou la scalabilité, est rarement reconnue officiellement.
J’appellerai ici cette force « la feuille de route ».
En bref, l’affaire EIP-3074 → EIP-7702 illustre parfaitement comment la « feuille de route » a supplanté la décision formelle des All Core Devs.
Du point de vue de la gouvernance, quand une force invisible prend le pas sur une force visible, il faut s’en alarmer : l’invisible échappe à la supervision. Il est donc essentiel d’exposer et d’examiner cette influence cachée.
Qu’est-ce qu’une feuille de route ?
Dans l’univers Ethereum, le terme « feuille de route » est familier : la feuille de route centrée sur les Rollups, celle d’ETH 2.0, ou encore celle de l’abstraction de compte, au cœur de notre discussion.
Imaginons une réunion des All Core Devs où l’on discute de l’extension du réseau :
Le développeur Bob propose : « Je soutiens l’EIP-1234, qui prévoit de multiplier par 10 la fréquence des blocs, par 10 leur taille, et de diviser par 100 les frais de transaction. »
Les autres répondent : « Tu es sérieux ? »
Réfléchissons : pourquoi cette proposition est-elle immédiatement rejetée ? Elle représente une solution efficace de scalabilité, adoptée avec succès par d'autres blockchains comme Solana.
La raison est qu’elle contredit la feuille de route d’Ethereum centrée sur les Rollups. Cette feuille de route insiste sur le fait que, pour préserver la décentralisation, il doit rester facile pour les utilisateurs ordinaires de faire tourner un nœud. La proposition de Bob rendrait cette tâche nettement plus difficile, donc elle est écartée.
Cet exemple montre que les développeurs principaux participant aux réunions ACD suivent en réalité un principe supérieur : la feuille de route. Il existe diverses feuilles de route (scalabilité, abstraction de compte, MEV, etc.), qui ensemble forment la vision globale d’Ethereum et guident les décisions techniques.
Quand les développeurs principaux divergent de la feuille de route
Comme la feuille de route n’appartient pas au processus formel de gouvernance, les développeurs principaux ne sont pas toujours alignés avec elle. Surtout, aucune procédure officielle n’« approuve » une feuille de route, donc toutes ne jouissent pas du même niveau de reconnaissance. Les concepteurs doivent donc travailler activement à promouvoir leur feuille de route auprès des développeurs principaux et de la communauté pour obtenir leur soutien.
Par exemple, bien que Vitalik ait souvent défendu une feuille de route centrée sur l’EIP-4337, c’est surtout l’équipe EIP-4337 — Yoav et Dror en particulier — qui a activement plaidé pour cette vision lors des réunions, forums en ligne et sessions ACD.
Malgré cela, certains développeurs principaux s’opposaient à cette feuille de route, jugeant l’EIP-7560 (version native d’EIP-4337, devant être implémentée par les clients) trop complexe, et estimant qu’il n’était pas la seule voie vers l’abstraction de compte. Finalement, malgré l’opposition de l’équipe EIP-4337 — qui craignait une fragmentation de l’écosystème par l’introduction d’une technologie concurrente plus centralisée — les All Core Devs ont approuvé l’EIP-3074.
Mais après cette approbation, l’opposition massive de toute la communauté EIP-4337 a poussé les développeurs principaux à réexaminer l’EIP-3074. Face à l’impasse, Vitalik a proposé l’EIP-7702 comme alternative, explicitement alignée avec la feuille de route EIP-4337, ramenant ainsi le processus dans le bon sens.
Le rôle de Vitalik
Bien que Vitalik se considère comme chercheur, cet incident révèle son rôle singulier dans la gouvernance d’Ethereum. Cela soulève la question : quel est exactement son rôle ?
On peut imaginer Vitalik comme le directeur technique (CTO) d’une grande entreprise.
Si vous avez travaillé dans une entreprise tech de plus de 50 personnes, vous savez que le CTO ne peut pas décider de chaque détail technique. À mesure que l’entreprise grandit, les décisions se décentralisent, et les équipes spécialisées prennent en charge leurs propres domaines.
De plus, le CTO n’est pas forcément l’expert absolu dans tous les domaines. Il peut y avoir des ingénieurs meilleurs que lui sur certains sujets. Ainsi, dans les débats techniques, ce sont souvent les ingénieurs qui tranchent.
Mais le CTO fixe la vision technique générale, tandis que les développeurs en assurent l’exécution.
Cette analogie n’est pas parfaite, mais elle décrit assez fidèlement le rôle de Vitalik dans l’écosystème Ethereum.
Vitalik ne participe pas à chaque décision technique — il ne le pourrait pas, et n’est pas non plus le meilleur expert partout. Mais il exerce une influence majeure sur les feuilles de route des aspects clés d’Ethereum (scalabilité, abstraction de compte, preuve d’enjeu, etc.), non seulement grâce à ses compétences techniques, mais aussi parce qu’il peut juger si une feuille de route correspond à la vision d’Ethereum — qui est, en fin de compte, sa propre vision.
La vision, moteur de tout produit réussi
En tant qu’entrepreneur, je crois que derrière tout produit réussi se trouve une vision claire. Et cette vision est presque toujours portée par quelques individus, souvent l’équipe fondatrice, parfois un seul fondateur clé.
Le charme d’Ethereum réside dans le fait qu’un système aussi complexe et multi-niveaux fonctionne harmonieusement comme un ordinateur décentralisé traitant chaque jour des flux colossaux. Ce n’est pas le fruit d’un comité, mais de la vision incarnée par Vitalik. Depuis 2015, Ethereum est l’expression intellectuelle de Vitalik.
Cela ne diminue en rien la contribution des autres chercheurs et ingénieurs, qui ont accompli un travail remarquable. Mais on ne peut nier qu’Ethereum est l’incarnation extrême de la vision de Vitalik, dépassant de loin l’influence de toute autre personne.
Posez-vous honnêtement la question : quand vous avez rejoint Ethereum pour son ouverture, sa résistance à la censure et sa vitalité innovante, vous souciiez-vous que tout cela provienne de l’idée originelle de Vitalik ?
Peut-être pas auparavant. Mais maintenant que vous le savez, cela vous importe-t-il vraiment ?
Ethereum est né d’une vision claire, et continue de croître en la réalisant — c’est là sa magie.
Et la décentralisation dans tout ça ?
Vous vous demandez peut-être : si une seule personne exerce une telle influence sur Ethereum, comment peut-on dire qu’il est décentralisé ?
Pour répondre, rappelons un article classique de Vitalik sur les multiples sens de la décentralisation. L’essentiel est que celle-ci comporte trois dimensions :
Décentralisation architecturale : combien de nœuds doivent tomber pour que le système s’arrête ?
Décentralisation logique : les composants peuvent-ils évoluer indépendamment sans compromettre le système ?
Décentralisation politique : combien de personnes ou entités contrôlent le système ?
Ethereum est indéniablement décentralisé sur les plans architectural et logique, car il repose sur de nombreux nœuds distribués et ses composants (mécanisme de consensus, couche d’exécution, etc.) peuvent évoluer relativement indépendamment.
Concernant la décentralisation politique, la bonne nouvelle est qu’aucune entité unique ne peut arrêter Ethereum, pas même Vitalik. Mais il est vrai que son rôle central dans la fixation de la vision et des feuilles de route implique un certain compromis sur ce plan.
Je pense que, pour continuer à innover, nous devons accepter que Vitalik joue de facto le rôle de CTO, même si cela réduit légèrement la décentralisation politique. Tant qu’Ethereum n’aura pas atteint la stabilité de Bitcoin, il aura besoin d’une autorité respectée capable de veiller à ce que les décisions techniques servent la vision à long terme.
Sans un tel rôle, Ethereum risquerait deux scénarios, dont l’affaire EIP-3074 est un exemple vivant :
-
Impasse décisionnelle : les parties refusent de compromis, le projet stagne — comme lors du blocage autour de l’EIP-3074, levé uniquement par l’intervention de Vitalik.
-
Conception désordonnée : le système devient un assemblage incohérent, comme cela faillit arriver avec l’existence parallèle et incompatible de l’EIP-3074 et de l’EIP-4337.
Ainsi, pendant qu’Ethereum continue d’évoluer rapidement, le leadership de Vitalik est crucial pour maintenir un écosystème à la fois décentralisé et orienté.
L’importance de la communauté
Nous avons presque complété notre cadre de compréhension de la gouvernance d’Ethereum, mais un élément clé manque encore : le rôle de la communauté.
Si Vitalik fixe la vision, les chercheurs en tirent les feuilles de route, et les développeurs principaux mettent en œuvre, quel est le rôle de la communauté ? Elle n’est certainement pas insignifiante ?
En réalité, la communauté joue le rôle le plus fondamental. Car avant même la vision, il existe quelque chose de plus profond : les valeurs. Nous formons une communauté parce que nous partageons certaines valeurs, qui constituent la base de la vision de Vitalik. Sans cette adéquation, la communauté disparaîtrait.
Influencés par nos parcours ou expériences, chacun d’entre nous a réalisé à un moment donné la valeur mondiale d’un ordinateur universel, inviolable et véritablement décentralisé. Chaque jour, notre travail sur Ethereum met en pratique ces valeurs. Par nos actions, nous donnons vie et légitimité à la vision, aux feuilles de route et au code proposés par Vitalik, les chercheurs et les développeurs.
Modèle simplifié de la gouvernance Ethereum : le cadre VVRC
Imaginons la gouvernance d’Ethereum comme une machine bien conçue, résumée en quatre composants clés : Valeurs (Values), Vision, Feuilles de route (Roadmaps) et Clients, soit le modèle VVRC.
-
Valeurs (Values) : tout commence par un ensemble de principes et croyances partagés au sein de la communauté Ethereum.
-
Vision (Vision) : Vitalik, en tant que fondateur, traduit ces valeurs en une vision du futur d’Ethereum.
-
Feuilles de route (Roadmaps) : à partir de cette vision claire, les équipes de recherche définissent les étapes concrètes pour y parvenir, concevant des chemins techniques progressifs.
-
Clients (Clients) : enfin, les développeurs principaux implémentent ces feuilles de route en code, en maintenant les logiciels clients pour transformer les plans en réalité utilisable.
Ce processus semble fluide, mais la réalité est plus complexe. Par exemple, les développeurs principaux détiennent le pouvoir décisionnel final, car ils contrôlent l’implémentation logicielle. Vitalik et les chercheurs font surtout des recommandations, qui peuvent parfois être ignorées — comme dans le cas de l’EIP-3074.
Globalement, le modèle VVRC aide à comprendre comment la gouvernance d’Ethereum devrait fonctionner idéalement, tout en rappelant qu’il faut continuellement ajuster et améliorer ce processus pour éviter de revivre des crises comme celle de l’EIP-3074.
Comment améliorer la gouvernance d’Ethereum
Pour optimiser la gouvernance d’Ethereum et éviter de reproduire l’incident EIP-3074/EIP-7702, voici quelques pistes d’amélioration :
Améliorer la transparence des EIP : rendre plus visibles aux communautés les EIP en cours d’examen, pour éviter les surprises comme celle de l’approbation soudaine de l’EIP-3074. En effet, l’état affiché sur le site EIPs ne reflète pas toujours l’avancement réel dans les réunions ACD. Même après accord des développeurs, l’EIP-3074 restait marqué « en revue ». On pourrait utiliser les canaux sociaux de la Fondation Ethereum pour annoncer à l’avance les EIP susceptibles d’être adoptés.
Renforcer la participation communautaire : instaurer des créneaux spécifiques lors des réunions ACD pour que les membres de la communauté discutent de l’impact d’un EIP sur leurs projets. Cela éviterait des effets collatéraux imprévus comme celui subi par la communauté EIP-4337. En outre, si des chercheurs sentent que leurs retours sont ignorés — comme l’équipe EIP-4337 — ils devraient inviter des représentants communautaires pour renforcer leur position.
Compréhension mutuelle et dialogue continu : les développeurs principaux et les chercheurs doivent reconnaître qu’ils sont tous deux des forces de gouvernance, avec des rôles différents. Les développeurs détiennent le « pouvoir d’exécution » via l’implémentation client, comparable à un « droit de vote ». Les chercheurs, en diffusant activement leurs feuilles de route, gagnent un « pouvoir d’influence » soutenu par la communauté.
Quand leurs avis divergent, les développeurs ont tendance à rejeter directement les idées des chercheurs, comme cela a été le cas avec l’équipe EIP-4337. Mais cela provoque des réactions violentes, car l’équilibre du pouvoir est rompu — l’exemple de l’EIP-3074 en témoigne.
Inversement, face à la résistance, les chercheurs peuvent choisir de se retirer de la collaboration, ce qui explique en partie la création du processus RIP (Rollup Improvement Proposal) et le fait que l’abstraction native (EIP-7560) soit surtout portée via RIP plutôt que par l’EIP traditionnel.
Bien que le RIP soit utile pour expérimenter sur la couche 2 des mises à jour difficiles à intégrer en L1, il ne peut pas remplacer la participation au processus EIP. Les chercheurs doivent persévérer dans le dialogue avec les développeurs principaux jusqu’à ce que la feuille de route soit consensuelle.
Grâce à ces mesures, on peut améliorer la transparence, renforcer l’engagement communautaire et favoriser une coopération efficace entre développeurs et chercheurs, réduisant ainsi les risques de crise future.
Conclusion
L’affaire EIP-3074/EIP-7702 révèle la complexité de la gouvernance d’Ethereum : au-delà des processus formels pilotés par les développeurs principaux et les propositions EIP, les feuilles de route informelles issues de la recherche exercent une influence majeure. Quand ces deux forces sont désalignées, cela peut entraîner blocage ou volte-face brutale. Dans ces moments, le rôle de Vitalik devient crucial : il agit comme un guide spirituel, capable de réconcilier les parties grâce à sa vision d’ensemble.
Nous avons simplifié la gouvernance d’Ethereum en un modèle : les valeurs de la communauté → la vision de Vitalik → les feuilles de route des chercheurs → la mise en œuvre par les développeurs (modèle VVRC). Cette chaîne montre comment les idées générales se transforment progressivement en réalités techniques.
Pour améliorer l’efficacité de la gouvernance, il faut corriger les écarts entre ce modèle idéal et la réalité opérationnelle. Après tout, une bonne gouvernance est le moteur essentiel du progrès d’Ethereum. L’incident EIP-3074, en exposant des faiblesses, nous offre une occasion d’apprendre et d’évoluer, garantissant une meilleure résilience face aux défis futurs et assurant la santé durable du projet.
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
@imTokenOfficial
