Explication de la gouvernance du cœur d'Ethereum

Une présentation de Nixo Rokish de la Fondation Ethereum à ETHBoulder, expliquant la gouvernance du protocole de base d'Ethereum, comment les hard forks sont coordonnés, les idées fausses courantes sur qui contrôle Ethereum, et comment participer au processus de gouvernance.

Cette transcription est une copie accessible de la transcription vidéo originale (opens in a new tab) publiée par EthBoulder. Elle a été légèrement modifiée pour en faciliter la lecture.

Introduction (0:12)

Merci à mes six amis qui sont venus. Très bien. Je vous parle aujourd'hui de la gouvernance de base d'Ethereum. Je m'appelle Nixo. Je dirige l'équipe de support du protocole à la Fondation Ethereum (FE). Parmi tous nos mandats, l'un d'eux est de rendre le processus de gouvernance plus clair et plus facile à naviguer pour tous ceux qui participent à ces choses, car Ethereum inclut bien plus que ses seuls développeurs principaux.

Voici donc un aperçu de la présentation. Nous allons parler de ce qu'est la gouvernance de base. Nous allons aborder les idées fausses et la façon dont la gouvernance d'Ethereum fonctionne actuellement. Nous verrons comment elle se compare à d'autres systèmes de gouvernance décentralisée, pourquoi les constructeurs devraient s'y intéresser, et les moyens concrets d'y participer.

Alors, qu'est-ce que la gouvernance du protocole de base ? Je gère un nœud. Cela signifie que j'ai du matériel, un ordinateur chez moi où j'exécute le logiciel Ethereum. Lorsque j'ai configuré ce logiciel Ethereum, j'ai dû choisir les clients qui allaient exécuter ce logiciel. Ethereum est assez unique dans le sens où il possède plusieurs clients pour assurer la diversité des clients. L'intérêt est que si un client tombe en panne, s'il y a un bug dans un client, l'ensemble du réseau ne tombe pas en panne. Il existe d'autres chaînes de blocs qui ont d'autres clients. Cependant, Ethereum est la seule qui soit configurée de manière à nous protéger réellement contre les bugs. Donc, si vous prenez Solana par exemple, Solana a un autre client, je crois qu'il s'appelle GTO, mais il n'a que 20 à 21 % d'adoption. Donc, si le client majoritaire tombe en panne, la chaîne tombe en panne. Et nous avons vu d'autres réseaux tomber en panne. C'est pourquoi Ethereum est la chaîne de blocs la plus résiliente et la plus sécurisée.

La question est donc de savoir comment intégrer des changements dans Ethereum alors qu'il faut se coordonner avec autant de clients différents. Tout d'abord, nous allons faire la différence entre un hard fork et un soft fork. Un soft fork ne nécessite pas la même coordination qu'un hard fork. Ethereum fonctionne principalement avec des hard forks. Un hard fork, c'est en gros tous les clients qui construisent une nouvelle version d'Ethereum et décident à un moment préconfiguré de lancer cette nouvelle version d'Ethereum. C'est toujours Ethereum, mais avec de nouvelles fonctionnalités. Il a des fonctionnalités différentes. Et tous les opérateurs de nœuds comme moi qui gèrent des nœuds à la maison ou les opérateurs professionnels doivent adhérer à cette nouvelle version d'Ethereum. Ils doivent mettre à niveau leur nœud ou mettre à jour leurs nœuds pour inclure ce nouveau logiciel.

Alors, comment décident-ils des fonctionnalités à intégrer dans ces hard forks ? Ils doivent s'entendre sur les priorités pour allouer leur temps et leurs ressources, car ils disposent d'un temps et de ressources limités à y consacrer. Ils donnent la priorité à des éléments tels que les failles de sécurité ou les correctifs de sécurité, ou encore l'expérience utilisateur (UX) — s'il y a une autre chaîne de blocs qui nous fait concurrence, nous devons devenir compétitifs par rapport à ces autres chaînes de blocs. L'une des choses qu'ils vérifient, c'est que toute fonctionnalité intégrée doit être compatible de manière ascendante avec les éléments potentiels à venir sur la feuille de route.

L'année dernière, il s'est passé quelque chose de très controversé. Vous en avez peut-être entendu parler. Cela s'appelait EOF. C'est l'EVM Object Format. Il s'agissait d'un ensemble de fonctionnalités qui devaient être intégrées dans le hard fork Fusaka — Pectra, Fusaka, je crois les deux — mais cela a été divisé. Et l'un des nombreux éléments déclencheurs qui a fait que cela a été retiré de ce fork, c'est que Vitalik a publié un article sur la possibilité pour Ethereum d'adopter RISC-V. Beaucoup de personnes qui ont lu cela se sont dit : d'accord, si nous adoptons RISC-V, les fonctionnalités que nous envisageons dans EOF sont natives avec RISC-V. Alors pourquoi ajouterions-nous cette complexité au protocole ? Pourquoi consacrerions-nous toutes ces ressources de développeurs de clients à cette chose ? Ce serait inutile si nous finissions par passer à RISC-V.

C'était donc en quelque sorte la goutte d'eau qui a fait déborder le vase pour EOF et cela a fini par être retiré du fork. Une autre chose qu'ils doivent prendre en compte, c'est que cela doit être écrit et rigoureusement testé dans six langages différents, car ces clients sont écrits dans six langages différents. C'est donc une très grande matrice de test avec laquelle ils doivent travailler. Et à cause de cela, chaque petit choix de conception fait l'objet de débats sans aucune autorité pour résoudre les désaccords. La question qui se pose alors est de savoir qui décide — ce qui est le cœur de la gouvernance.

Idées fausses (5:23)

Cela nous amène donc aux idées fausses et nous allons en aborder quelques-unes. La première est que Vitalik décide de ce qui entre dans le protocole Ethereum. Une extension de cela est que la Fondation Ethereum contrôle tout. Et une troisième est que tout se passe en coulisses — des initiés, des vétérans (OGs) qui prennent ces décisions.

Donc la première : Vitalik décide. J'ai juste sélectionné un sous-ensemble d'EIP stagnantes rédigées par Vitalik. Ce que cela signifie, c'est que Vitalik s'est assis, a écrit une proposition et a dit : je veux que ces choses soient intégrées à Ethereum, et personne n'était d'accord — ces choses sont juste restées là. Il n'a pas réussi à les faire intégrer au protocole. Donc, tout ce qu'il propose n'est pas automatiquement inclus.

Une extension de cela est que la Fondation Ethereum contrôle tout. Je vais prendre un exemple précis d'un moment qui, je pense, contredit cela. En 2024, on a beaucoup parlé de la limite de gaz. Et la raison en est qu'en 2022, pendant La Fusion, nous avons augmenté la limite de gaz à 30 millions. C'est le calcul maximum autorisé dans un bloc. Et puis nous n'y avons plus vraiment touché pendant un moment parce que ce n'était pas vraiment un goulot d'étranglement qui faisait dire aux gens : « C'est pour ça que je ne passe pas à Ethereum » ou « Cela limite mon cas d'utilisation actuel d'Ethereum ».

Et fin 2023, début 2024, il y avait ce récit selon lequel Solana arrivait. Qu'il allait tailler des croupières à Ethereum. Les gens se demandaient donc ce qu'Ethereum pouvait faire pour accélérer. Et l'une des idées était d'augmenter cette métrique de gaz. À l'époque, la FE et les développeurs de clients se disaient plutôt : « Nous avons d'autres chats à fouetter. Merci quand même. » Mais ces deux personnes, Eric Connor et Mariano Conti, sont arrivées et ont dit : « Non, nous augmentons la limite de gaz. » La limite de gaz est un paramètre contrôlé par les validateurs. Ils pouvaient donc simplement commencer à parler aux validateurs, aux opérateurs professionnels, et leur dire : « Hé, augmentez votre limite de gaz. »

Et à un moment donné, il y a eu suffisamment d'adoption pour que la FE et les clients se disent : « Oh, nous devons prêter attention à cela. Nous devons nous assurer que ce qu'ils font est sûr et que la valeur à laquelle ils finissent par l'augmenter sera une chose sûre pour le réseau. » Ils ont donc dû réallouer leurs ressources. Nethermind a mis au point ce cadre de test. La FE a fait beaucoup de travail à Berlin. Tous les développeurs de clients ont évalué cela. Et j'aime bien ça parce que ça a forcé la main de la FE pour décider de ce qui était prioritaire.

Et j'aime bien ce tweet stupide que j'ai capturé ici parce que c'est un média aléatoire qui qualifie Eric Connor et Mariano Conti de développeurs principaux (core devs). Ce ne sont pas des développeurs principaux. Eric Connor était un staker et un membre de la communauté. Mariano Conti était un ancien développeur d'applications MakerDAO. Mais ils ont simplement été appelés développeurs principaux parce le développement d'Ethereum est vraiment en dehors du monde du fonctionnement des logiciels traditionnels, alors ils ont vu un paramètre de base être modifié et se sont dit : « Oh, ce doivent être des développeurs principaux. » Ce n'était pas le cas. C'est donc juste un exemple de membres de la communauté qui arrivent et disent que nous voulons voir ce changement et qui le concrétisent.

Tout se passe en coulisses, entre initiés, vétérans — je comprends un peu mieux pourquoi c'est une idée fausse, car en gros, vous venez à ces appels de gouvernance, il y a une centaine de personnes dans ces appels. On a l'impression qu'ils sont tous très à l'aise avec ce qui se passe. Vous êtes perdu. Vous n'avez aucune idée de la façon dont ces décisions sont prises. Vous vous dites : « C'est à mon tour de parler ? » Et on a l'impression que les gens écoutent les 10 mêmes personnes pour prendre ces décisions.

Méritocratie et statistiques de participation (10:18)

Mais la vérité est que le développement d'Ethereum est plus une méritocratie que ce que j'ai jamais vu dans la plupart des développements de logiciels. Toutes ces personnes sur cette capture d'écran — c'est l'une des trois de cet appel ACD aléatoire que j'ai décidé de capturer — aucune de ces personnes n'a été nommée pour être ici. Tout le monde est juste en quelque sorte les personnes qui se sont présentées. Ce sont les développeurs qui ont passé beaucoup de temps avec ce protocole. Ce sont ceux que les gens ont reconnus comme étant des développeurs talentueux dans cet espace, prenant constamment de bonnes décisions, et personne ici n'est nommé pour y être.

Je n'ai donc rejoint la FE qu'il y a un peu plus d'un an. J'ai récupéré ces statistiques. Elles ne remontent qu'à mars 2025. Donc moins d'un an. La moyenne des participants aux appels All Core Devs — ce sont les appels de gouvernance — est de 98. Il y a donc en moyenne 98 personnes dans ces appels. Le nombre maximum de participants à un appel depuis lors a été de 153. Je crois que c'était le jour où nous décidions de la date du réseau principal pour Pectra. Et le nombre total de participants uniques est de 567 rien qu'au cours de la dernière année. J'aime beaucoup cette métrique car elle montre bien que ce ne sont pas les 100 mêmes personnes qui participent à ces appels à chaque fois. Ces développeurs d'applications, ces chercheurs, quelqu'un entend parler d'une fonctionnalité en cours de discussion, ils se présentent pour exprimer leur opposition ou leur soutien, puis ils ne viennent plus à un autre appel.

Comment fonctionne le processus de gouvernance (11:52)

C'est donc une diapositive un peu aride, mais je pense qu'il est important de la parcourir — c'est ainsi que fonctionne actuellement la gouvernance d'Ethereum. Ainsi, lorsqu'un de ces forks est en cours de discussion, la première chose qui se passe est que les gens, pendant cette fenêtre de temps allouée, peuvent soumettre leur proposition phare. La proposition phare est la fonctionnalité majeure autour de laquelle nous voulons que les gens se rallient pour ce fork. Il peut s'agir d'un membre de la communauté, d'un chercheur, d'un développeur principal — vraiment n'importe qui qui soumet l'une de ces propositions phares. Ensuite, la fenêtre se ferme et lors des appels de gouvernance, nous discutons en quelque sorte de celles qui ont du sens. Les gens présentent leurs arguments, débattent et il y a un consensus sur celle que nous devrions choisir pour ce fork à venir.

Ensuite, ils choisissent les fonctionnalités mineures. Donc les choses plus petites qui n'ont pas vraiment besoin d'être ces fonctionnalités majeures qui dirigent le fork. Et tout au long de cette période, nous avons des devnets spécifiques aux fonctionnalités. Un devnet est comme un réseau de test — un réseau de test privé pour que les développeurs testent ces fonctionnalités et s'assurent qu'elles fonctionnent réellement sur Ethereum. Et puis il y a à un moment donné un gel des fonctionnalités. Nous avons donc discuté des fonctionnalités majeures, nous avons discuté des fonctionnalités mineures, nous avons exécuté ces devnets spécifiques aux fonctionnalités qui sont généralement les têtes d'affiche du fork. Et c'est un gel des fonctionnalités avec un astérisque, car à ce stade, nous avons décidé de ne plus ajouter de fonctionnalités à ce fork. Nous allons exécuter toutes les fonctionnalités ensemble, nous assurer que tout va bien, nous assurer que rien ne va casser. Mais si quelque chose commence à ralentir les choses, si le fork est retardé, s'il est trop complexe, des éléments peuvent encore être retirés à ce stade.

Donc, après un certain nombre de devnets — il peut y en avoir deux, il peut y en avoir 10 — les clients décident tous à un moment donné que c'est stable. Nous avons confiance en ce qui se passe en ce moment. Nous sommes en bonne position. Commençons à réfléchir à la mise en ligne de tout cela sur le réseau principal Ethereum. Ils publient les versions des clients, puis il y a une période de 30 jours pendant laquelle l'équipe de sécurité de la FE lance un programme de primes aux bugs (bug bounty). Ils contractent des audits de sécurité. Et puis, à la fin de cette période de 30 jours, nous lançons le fork sur les réseaux de test. Ce sont des réseaux de test dont vous avez peut-être entendu parler — comme Holesky. C'est là que les développeurs d'applications peuvent tester leurs créations avant que le fork ne soit mis en ligne. Et ceux-ci durent généralement un minimum de 14 jours chacun, juste pour s'assurer que tout va bien. Nous ne nous attendons pas à de gros problèmes car cela est passé par des devnets spécifiques aux fonctionnalités et des devnets généralisés auparavant, mais historiquement, cela a cassé certains de ces réseaux de test. C'est donc en quelque sorte le dernier appel pour trouver et écraser tous ces bugs.

Et puis, une fois que le réseau de test sans permission est stable, la date du réseau principal est choisie. Ensuite, il y a un délai de 30 jours. Ce délai de 30 jours existe parce que les L2 et les protocoles l'ont demandé afin de se préparer pour le fork. C'est donc un minimum de 30 jours, puis le fork a lieu.

Structure des appels et coordination (15:01)

Pendant tout ce temps, il y a des séries d'appels principaux qui ont lieu. Ce sont tous des appels publics diffusés en direct sur YouTube. Les principaux sont ACDE et ACDC. Le E correspond à la couche d'exécution — ce sont des choses comme les transactions, les déploiements de contrats intelligents, la gestion de la mempool. ACDC correspond à la couche de consensus — ce sont donc des choses liées aux validateurs comme la gestion des validateurs, la réduction (slashing). Et ils s'alternent les jeudis. Il y a donc un ACD chaque jeudi, l'un d'eux est ACDE, puis le suivant est ACDC, et ainsi de suite.

Les appels ACDE et ACDC se concentrent sur le fork que nous sommes en train de réaliser et sur les forks que nous envisageons pour l'avenir. Les appels ACDT sont plus pointus et rentrent dans les détails. Ce sont les clients qui parlent de bugs qu'ils n'arrivent pas à contourner ou de détails d'implémentation qui doivent être résolus concernant le fork sur lequel ils travaillent actuellement. En ce moment, le prochain fork qui aura lieu est Glamsterdam. Ces appels ACDT sont donc dominés par des conversations sur l'ePBS et les listes d'accès au niveau du bloc, qui sont les éléments qui seront intégrés à Glamsterdam. Et ce sont des appels hautement techniques.

Et puis il y a les appels en petits groupes (breakout calls). Les appels en petits groupes, ce sont des membres de la communauté, des chercheurs, des développeurs qui disent : « Hé, j'ai une fonctionnalité que je veux intégrer à Ethereum dans deux forks. » Ils organisent donc ces appels hebdomadaires, mensuels ou bimensuels au cours desquels ils discutent des détails de l'implémentation, modifient et itèrent sur les spécifications, et répondent généralement à toutes les questions que les gens se posent, à toutes les inconnues connues pour s'assurer que c'est dans la meilleure position possible pour être inclus dans le fork dans deux forks. Et ceux-ci peuvent être programmés quand l'animateur le décide.

Un processus en évolution (15:29)

Il y a donc une chose que je veux faire comprendre à tout le monde, c'est que ce processus est tout sauf statique. Ce processus que je viens de vous décrire est en place depuis moins d'un an. Ethereum est en ligne depuis 10 ans. Mais il change constamment et la raison pour laquelle il change constamment est que personne n'est aux commandes. Et ce processus évolue en quelque sorte pour trouver la façon la plus efficace de fonctionner. Et je dis efficace, mais la réputation de la gouvernance d'Ethereum est d'être vraiment stagnante, difficile à faire passer, confuse — et c'est parce que quand vous avez 100 à 500 personnes qui prennent des décisions, je suis honnêtement impressionné que cela fonctionne tout court.

Tim a donc publié un article en avril 2025 intitulé « Reconfiguring All Core Devs » qui a fini par être la proposition sur la façon dont les choses fonctionnent actuellement. Et la raison en est qu'avant cela, nous avions en quelque sorte ce récit cohérent sur ce sur quoi nous devrions nous concentrer dans Ethereum. Il y a eu La Fusion, qui a été une entreprise colossale. Tout le monde était très enthousiaste. La plupart des gens étaient très enthousiastes. Les mineurs ne l'étaient pas. Et puis, à la suite de La Fusion, il y a eu les retraits. Nous ne voulions donc pas que les gens aient leurs ETH bloqués dans un contrat et que ce FUD (peur, incertitude et doute) laisse penser qu'ils ne pourraient jamais récupérer leurs ETH. Nous devions donc livrer cela le plus rapidement possible. Et puis il y a eu le proto-danksharding, puis Pectra est arrivé et Pectra était en quelque sorte cet amalgame de différentes EIP sans rapport les unes avec les autres et n'avait pas vraiment de récit cohérent. Et c'est devenu tellement énorme parce que les gens y fourraient un peu tout à cause du manque de cohésion, que cela a dû être divisé en deux forks différents parce que les équipes de test se disaient : « La portée est beaucoup trop grande. Nous ne pouvons pas tester tout cela. »

L'impulsion de Tim pour faire cela était donc : d'accord, nous devons trouver un moyen de garder ces forks aussi ciblés et cohérents que possible. Et la tête d'affiche était en quelque sorte la réponse à cela. Le but était de livrer d'une manière qui donne la priorité au fait que tout le monde sache de quoi parlait le fork, afin qu'ils n'aient pas à y fourrer 25 EIP différentes.

L'autre capture d'écran en haut montre donc Tim proposant des définitions pour les étapes d'inclusion de ces EIP. Et ce que je veux souligner avec cela, c'est qu'on entend parfois des gens dire que ce processus est trop bureaucratique. Mais ce qui se passe réellement, c'est que les gens arrivent dans ce processus de gouvernance et se disent : « Comment puis-je faire accepter une EIP ? » et les gens qui sont là depuis 10 ans répondent : « Tu le fais, c'est tout. » Et les gens se disent : « C'est horrible. » Donc, ce que font ces choses, c'est qu'elles décrivent ce qui se passe pour faciliter la participation des personnes extérieures à ce processus, car si vous venez juste ici et que vous vous dites : « J'ai une EIP, je me fiche de la gouvernance d'Ethereum, je veux juste que cette EIP soit acceptée » — vous voulez une rubrique, vous voulez une liste de contrôle, vous voulez un guide étape par étape très clair sur la façon de faire accepter cette EIP. Donc, la plupart de ces choses visent davantage à décrire le fonctionnement du processus qu'à créer des règles bureaucratiques que les gens doivent suivre pour rendre difficile l'acceptation des EIP.

La troisième chose, ce sont les commits au fil du temps sur Forkcast. Forkcast est un produit de mon équipe, de Wolfram Mark, un gars de mon équipe qui a créé cela au milieu de l'année dernière lorsque mon équipe dans son itération actuelle a été formée. Et c'est devenu une ressource tellement canonique que les gens utilisent pour interagir avec un fork, pour voir ce qui entre dans un fork et comment cela les affecte. Toutes ces choses ont moins de deux ans. Donc, le point que je veux faire valoir, c'est que ce processus change beaucoup. Il n'est pas du tout statique. Ce n'est pas une bureaucratie figée où il est difficile de mettre un pied dans la porte.

Systèmes de gouvernance comparables (20:21)

Je voulais donc aborder rapidement les systèmes de gouvernance décentralisée les plus similaires que je puisse voir à la gouvernance d'Ethereum. Et le point que j'essaie de faire valoir ici, c'est que c'est durable — même s'il est incroyable que 100 à 500 personnes puissent prendre des décisions, c'est durable dans le monde réel. Nous voyons des exemples où cela fonctionne.

L'IETF est l'Internet Engineering Task Force. C'est l'organisme de normalisation géré par des bénévoles qui a créé TCP/IP, HTTP. C'est l'organisation qui est la plus responsable du fait que nous ayons l'internet libre aujourd'hui. Le noyau Linux — c'est le cœur du système d'exploitation Linux. C'est donc un logiciel open source qui alimente les serveurs internet, les téléphones Android, les superordinateurs. La différence là-bas, c'est qu'ils ont une sorte de modèle de dictateur bienveillant avec Linus Torvalds. Mais même dans ce cas, ils ont plus de 17 000 contributeurs, ce qui est époustouflant.

Ce à quoi cela ne ressemble pas : d'autres chaînes de blocs qui ont un vote par jeton onchain. Ethereum évite spécifiquement toute sorte de mécanisme de vote car, à mon avis, cela conduit à des possibilités de capture et cela élimine en quelque sorte l'incitation à faire des choses une méritocratie où les gens font simplement confiance aux personnes qui écrivent le meilleur code. Et puis il y a les L2. Ils ont des multi-signatures. Ils ont des conseils de sécurité. Ce sont plutôt des postes nommés qui prennent ces décisions. Et cela a ses compromis. C'est plus centralisé. Mais ça va plus vite.

Pourquoi les constructeurs s'y intéressent (22:38)

Alors pourquoi les constructeurs se soucient-ils de la gouvernance ? Parce que les constructeurs sont littéralement ceux pour qui Ethereum a été créé. Ethereum n'est pas créé pour les développeurs principaux. Il n'est pas créé pour les validateurs. Parfois, ces personnes s'y trompent. Les développeurs principaux et les validateurs d'Ethereum servent Ethereum, qui sert les constructeurs et les utilisateurs.

Et tout le monde a eu ce moment avec une IA où vous rentrez beaucoup trop dans les détails et elle essaie de réparer cette petite chose et elle ne parvient pas à prendre du recul et à regarder l'objectif global du projet. Et les développeurs principaux peuvent être comme ça lorsqu'ils essaient de perfectionner le processus de développement de base. Et il est très crucial dans ce cas que les constructeurs interviennent, car le développement de base est tellement chronophage qu'ils ne construisent pas non plus sur Ethereum la plupart du temps. Ils sont très impliqués dans le développement de base. Cela prend tout leur temps. Les constructeurs d'applications doivent donc vraiment faire un effort pour venir et dire : « Hé, nous avons besoin de ça. C'est crucial pour Ethereum. » Juste pour s'assurer que la perspective est là et qu'ils ne se retrouvent pas cantonnés à travailler uniquement pour les développeurs principaux.

Comment participer (24:40)

Alors, comment participer ou faire accepter votre fonctionnalité ? C'est un conseil un peu générique, mais je pense que c'est le meilleur. Exprimez-vous haut et fort sur vos points de douleur. Allez sur Twitter, écrivez des articles de blog, identifiez des solutions à vos points de douleur. Spéculez sur les choses qui pourraient vous aider. Si vous trouvez d'autres personnes qui ont ces mêmes points de douleur, vous pouvez généralement trouver une EIP qui existe pour résoudre ce point de douleur ou demander à quelqu'un de vous aider à écrire une EIP qui le fait.

Une chose que j'aime dans les logiciels open source, c'est que les entreprises bien capitalisées allouent généralement leur temps de développement et leurs ressources à la maintenance des outils open source qu'elles utilisent. Et cela finit par être un tas d'entreprises différentes qui collaborent à la maintenance de cette chose, et c'est aussi comme ça que cela peut fonctionner dans Ethereum. Donc, si vous avez identifié un point de douleur, vous pouvez trouver un développeur de Base qui a un point de douleur similaire, et Base est une organisation bien capitalisée, ils seraient donc probablement prêts à allouer des ressources pour livrer une fonctionnalité ou piloter une fonctionnalité à travers un hard fork d'Ethereum.

Je vais juste vous laisser quelques ressources. Forkcast.org — c'est là que vous pouvez aller voir ce qui entre dans un fork, comment cela affecte certaines parties prenantes. Donc, si vous êtes un développeur d'applications, il y a une section pour les développeurs d'applications. Si vous êtes un développeur de portefeuille, un développeur de client de la couche de consensus, il y a des sections sur la façon dont tout cela vous affecte. YouTube est l'endroit où toutes ces vidéos d'appels sont téléchargées. Elles sont également intégrées à la page forkcast.org/calls où il y a des résumés, des attributions d'intervenants, il est donc plus facile de naviguer dans ces appels. Le répertoire des EIP, le forum Ethereum Magicians où vous pouvez aller parler à d'autres personnes de solutions potentielles ou d'EIP que vous souhaitez écrire. Et très bientôt, mon équipe aura un site de support du protocole. Il a l'air génial. Il n'est pas prêt à être partagé. Mon e-mail est également là — nixo@ethereum.org (opens email client). C'est tout.