Vitalik Buterin lance une nouvelle mise en garde sur l’avenir d’Ethereum

Dans un fil de discussion de grande envergure qui a rapidement fait le tour de la communauté des développeurs Ethereum, Vitalik Buterin a plaidé cette semaine en faveur de ce qu’il appelle un pilier de la décentralisation « sous-estimé » : la simplicité du protocole. En publiant sur X, Buterin a soutenu que la résilience à long terme des blockchains comme Ethereum dépend moins de cryptographies exotiques ou de chiffres massifs de décentralisation, et plus de la capacité du protocole à rester suffisamment petit pour que des développeurs et chercheurs ordinaires puissent l’inspecter, le comprendre et le réimplémenter de manière significative.

Le point de Buterin est direct mais simple. Même si un réseau dispose de centaines de milliers de nœuds, d’une tolérance aux fautes byzantines de 49 % et d’outils de vérification de pointe, il ne parvient toujours pas à être véritablement « sans confiance », à passer le « test de la marche » ou à être réellement souverain si ces garanties ne peuvent être expliquées que par une petite élite d’experts. « Si le protocole est un chaos indigeste de centaines de milliers de lignes de code et de cinq formes de cryptographie de niveau doctorat », a-t-il écrit, « ce protocole échoue finalement à tous les trois tests. » En résumé, la complexité crée de nouvelles formes de centralisation.

La simplicité est une caractéristique de sécurité

Les implications de cette observation sont à la fois pratiques et philosophiques. Buterin a averti que des fonctionnalités accumulées et des ajouts cryptographiques ciblés peuvent offrir des bénéfices à court terme tout en minant la capacité du système à survivre des décennies. Lorsque les équipes de clients se dissolvent ou lorsque de nouveaux contributeurs tentent de prendre en charge la maintenance, une base de code tentaculaire devient un obstacle. Même des participants très techniques ne peuvent raisonnablement pas auditer le système, sa prétention à être « à vous » en est affaiblie.

Buterin a défini une « simplification » en trois points. Premièrement, réduire au minimum le nombre total de lignes de code. Un protocole qui pourrait, en principe, tenir sur une seule page, ou au moins quelques pages, est intrinsèquement plus facile à analyser. Deuxièmement, éviter les dépendances inutiles à des primitives techniques fondamentalement exotiques.

Une sécurité qui peut être réduite à un petit ensemble d’hypothèses, idéalement une seule fonction de hachage, est préférable à un patchwork qui mélange hachages, réseaux de lattices et isogénies, cette dernière étant, selon lui, un territoire « que personne ne comprend » même pour les spécialistes qui l’ont construite. Troisièmement, augmenter le nombre d’invariants : des propriétés clairement énoncées et strictement appliquées qui simplifient le développement des clients. Il a cité des EIPs récentes, telles que la suppression de l’autodestruction et les plafonds de gaz par transaction, comme exemples de mesures ayant ajouté des invariants utiles et réduit la complexité pour les implémenteurs.

Le fil dépasse l’incitation pour esquisser des voies concrètes. Buterin a plaidé pour une « collecte des déchets » continue dans le développement du protocole : des étapes délibérées pour épurer ou déclasser des fonctionnalités complexes, peu utilisées ou pouvant vivre en toute sécurité en dehors du code client obligatoire. Cela pourrait être fait par étapes, comme les réformes récentes du coût du gaz qu’il a mentionnées, visant à remplacer des chiffres arbitraires par des modèles de coût liés à la consommation de ressources, ou lors d’une refonte plus globale. Il a noté que la transition du proof-of-work au proof-of-stake était elle-même une grande opération de nettoyage et a suggéré que le consensus Lean pourrait offrir une autre opportunité de « corriger un grand nombre d’erreurs en même temps ».

Une autre idée qu’il a évoquée est une sorte de compatibilité rétroactive à la style Rosetta. Plutôt que d’obliger chaque client à implémenter chaque particularité ancienne de la chaîne, il propose de rétrograder les fonctionnalités rares mais complexes en couches de contrats intelligents optionnels. Selon ce modèle, l’abstraction native des comptes pourrait permettre de gérer les anciens types de transactions au niveau des contrats intelligents, tandis que les précompiles hérités pourraient être reprogrammés en contrats ou migrés vers une VM plus simple comme RISC-V à long terme. Les développeurs préoccupés par le support de l’héritage pourraient faire tourner d’anciens clients dans des conteneurs, tandis que les nouveaux clients resteraient plus légers.

Une feuille de route pour l’avenir d’Ethereum

Ce qui ressort du fil de Buterin, c’est un appel à un changement culturel autant qu’à un changement technique. Il a exhorté la communauté à cesser de juger les propositions uniquement en fonction de leur taille par rapport au protocole existant, une mentalité qui tend à favoriser les modifications additives pour des raisons de compatibilité descendante. Au lieu de cela, il a demandé que le processus inclue une fonction explicite de simplification : un effort discipliné et continu pour soustraire autant que pour ajouter.

L’image accompagnant de nombreux reposts du fil, trois moteurs de fusée complexes alignés côte à côte, chacun un exemple de tubes, câbles et détails ingénierie, a été largement partagée comme une métaphore. À l’image d’un système de fusée, un protocole avec de nombreuses pièces en interaction peut être fragile : plus il y a de pièces mobiles et de composants spécialisés, plus il y a de façons pour que quelque chose tourne mal. Le message de Buterin est, en effet, que la meilleure hyperstructure à long terme est celle dont le noyau peut tenir sur une page et être remis à un nouveau venu.

Pour un protocole qui aspire à transcender les régimes politiques et les modes technologiques, ces nouveaux venus comptent. « Ces quinze premières années », a-t-il écrit, en référence au cycle de vie d’Ethereum jusqu’à présent, « doivent en partie être considérées comme une adolescence », une période d’expérimentation créative. Le défi, selon lui, est de conserver les expériences utiles tout en empêchant que celles sans valeur ne deviennent un encombrement permanent.

Le fil a déjà suscité un débat animé. Certains développeurs avertissent que la simplicité doit être équilibrée avec la nécessité de primitives puissantes et de flexibilité, tandis que d’autres voient un besoin urgent de la sorte de pruning systématique que Buterin prône. Si rien d’autre, la conversation marque un consensus croissant selon lequel la décentralisation ne se mesure pas uniquement par le nombre de nœuds ou par des cloches et sifflets cryptographiques, mais par la facilité avec laquelle le système reste accessible à ceux qui construisent, maintiennent, finissent par s’en aller, puis y reviennent pour le comprendre.