L'évolution du protocole Ethereum à travers la rétrogradation : la stratégie de simplification de Vitalik Buterin

Le 18 janvier, Vitalik Buterin a publié un message sur la plateforme X dans lequel il a présenté un problème central du protocole Ethereum. Il affirme que, même avec une conception techniquement excellente, une complexité excessive peut empêcher le respect des principes fondamentaux de fiabilité, d’autonomie et de sécurité. Cette déclaration, rapportée par PANews, soulève des questions importantes sur l’orientation future du développement d’Ethereum.

La complexité du protocole Ethereum : pourquoi la simplification est-elle nécessaire ?

Vitalik Buterin a souligné que la “non-fidélité”, “l’omission de tests” et “l’autonomie” sont trois caractéristiques essentielles du protocole. Cependant, Ethereum se trouve actuellement dans une situation où il est difficile de respecter ces principes fondamentaux.

Avec des centaines de milliers de nœuds opérant, un taux de tolérance aux pannes byzantines atteignant 49 %, et tous les nœuds vérifiant via des technologies cryptographiques résistantes à l’informatique quantique comme PeerD and Stark, le problème réside dans la complexité. Si la structure est composée de dizaines de milliers de lignes de code mêlées à des techniques cryptographiques de niveau doctorat, elle finira par échouer lors des tests de fiabilité.

Une dépendance à un petit groupe d’experts pour les utilisateurs menace la véritable nature d’un système sans confiance (trustless). La problématique du “test de mobilité”, où la qualité doit être maintenue même si l’équipe de développement principale change, est également soulevée. Même les meilleurs développeurs ne peuvent pas maîtriser et gérer une structure excessivement complexe.

Le cercle vicieux de la sur-augmentation du protocole : ajout vs modification

Le problème fondamental du développement d’Ethereum réside dans le processus d’ajout de fonctionnalités. En cherchant à répondre rapidement à de nouvelles exigences, le protocole devient de plus en plus complexe, intégrant de nouvelles interactions ou des techniques cryptographiques avancées comme dépendances essentielles.

À court terme, cela favorise l’expansion des fonctionnalités, mais à long terme, cela compromet l’autonomie et empêche la construction d’une véritable architecture décentralisée pouvant durer des siècles. La principale difficulté réside dans le fait que, par crainte de briser la compatibilité descendante, il y a beaucoup plus d’ajouts que de modifications dans le code. Inévitablement, avec le temps, le protocole devient surchargé.

Trois stratégies de collecte des déchets (garbage collection)

Vitalik a proposé que pour résoudre ce problème, le processus de développement d’Ethereum doit impérativement intégrer une fonction claire de “simplification” ou de “collecte des déchets” (garbage collection).

Les trois critères de simplification :

Premièrement, réduire au minimum le nombre total de lignes de code du protocole. Deuxièmement, éliminer les dépendances inutiles sur des composants techniques fondamentalement complexes. Troisièmement, ajouter davantage de propriétés immuables pour clarifier les attributs clés sur lesquels repose la confiance dans le protocole.

Par exemple, l’EIP-6780 a considérablement simplifié le développement client en supprimant la fonction d’autodestruction et en limitant le nombre maximum de slots de stockage modifiables par bloc à N.

La collecte des déchets peut se faire de deux manières :

Une approche partielle consiste à repenser de manière concise et logique les fonctionnalités existantes. Un exemple d’approche à grande échelle est la migration complète du mécanisme de preuve de travail (PoW) vers la preuve d’enjeu (PoS), comme lors de la mise à niveau “The Merge”.

Gestion de la compatibilité avec les anciennes versions par rétrogradation

Une approche encore plus innovante est la “compatibilité descendante à la manière de Rosetta”. Elle consiste à supprimer dans le cœur du protocole des fonctionnalités complexes mais peu utilisées, puis à les rétrograder dans des contrats intelligents. Cela évite aux nouveaux développeurs de devoir gérer ces fonctionnalités eux-mêmes.

Par exemple, après une mise à niveau complète avec l’abstraction native des comptes (Account Abstraction), il n’est plus nécessaire de considérer tous les types de transactions existants comme des fonctionnalités essentielles. Les codes précompilés existants peuvent être rétrogradés en code EVM ou RISC-V, et à terme, la machine virtuelle elle-même pourrait passer d’EVM à RISC-V.

L’essence de cette stratégie de rétrogradation est de supprimer la complexité tout en maintenant la compatibilité avec les fonctionnalités existantes. L’objectif ultime est que les développeurs de clients n’aient plus besoin de traiter le code hérité des anciennes versions d’Ethereum.

Recommandations pour la durabilité à long terme d’Ethereum

La déclaration de Vitalik Buterin cette semaine dépasse une simple remarque technique ; elle soulève une question cruciale pour l’avenir d’Ethereum. Il faut ralentir le rythme des changements à long terme et éviter que la complexité inutile n’entrave le développement du protocole.

Grâce à une véritable rétrogradation et à une collecte des déchets, Ethereum peut évoluer vers un protocole plus simple, transparent et fiable. Cela peut également être considéré comme une tentative d’intégrer la valeur de l’immuabilité et de la simplicité, que Bitcoin cherche à préserver. La manière dont la simplification et la rétrogradation seront intégrées dans la feuille de route d’Ethereum jouera un rôle clé dans la réalisation d’une véritable décentralisation et autonomie de la blockchain.