Vitalik : Plan à court et moyen terme pour améliorer l'accessibilité sans autorisation et la décentralisation d'Ethereum
TechFlow SélectionTechFlow Sélection
Vitalik : Plan à court et moyen terme pour améliorer l'accessibilité sans autorisation et la décentralisation d'Ethereum
La couche L1 d'Ethereum peut et devrait certainement devenir une couche de base robuste pour les projets de couche 2 adoptant une approche de très grande échelle.
Dédié à des analyses Web3 approfondiesArticle rédigé par : Vitalik Buterin
Traduction : Dengtong, Jinse Finance
J'écris cet article lors de la dernière journée du rassemblement des développeurs d'Ethereum à Nairobi, au Kenya. Nous avons accompli d'importants progrès dans l'implémentation et la résolution des détails techniques liés aux futures améliorations majeures d'Ethereum, notamment PeerDAS, la transition vers les arbres de Verkle, et les approches décentralisées pour le stockage de l'historique dans le cadre de l'EIP 4444. De mon point de vue, la vitesse de développement d'Ethereum ainsi que notre capacité à livrer des fonctionnalités importantes et ambitieuses s'améliorent continuellement, offrant une expérience nettement meilleure aux opérateurs de nœuds et aux utilisateurs (sur L1 comme sur L2).
Les équipes clientes Ethereum collaborent pour livrer le devnet Pectra
Face à cette croissance technique, une question cruciale se pose : avançons-nous vers les bons objectifs ? Récemment, Peter Szilagyi, un développeur principal historique de Geth, a publié une série de tweets exprimant son mécontentement, ce qui nous pousse à réfléchir à cette question :
Ces préoccupations sont légitimes. Elles reflètent celles partagées par de nombreux membres de la communauté Ethereum. Personnellement, j'ai souvent été inquiet à propos de ces problèmes. Toutefois, je ne pense pas que la situation soit aussi désespérée que le suggèrent les tweets de Peter. En réalité, plusieurs problèmes sont déjà en cours d'être résolus grâce à des fonctionnalités protocolaires existantes, et beaucoup d'autres peuvent être corrigés par des ajustements très réalistes de la feuille de route actuelle.
Pour comprendre concrètement ce que cela signifie, examinons un par un les trois exemples fournis par Peter. Ces questions soulèvent des préoccupations largement partagées, et il est essentiel d'y répondre.
MEV et dépendance aux constructeurs
Auparavant, les blocs Ethereum étaient créés par des mineurs utilisant des algorithmes relativement simples. Les utilisateurs envoyaient leurs transactions via un réseau pair-à-pair public appelé « mempool » (ou « txpool »). Les mineurs surveillaient ce mempool, acceptaient les transactions valides accompagnées de frais, et les incluaient dans les blocs. S'il n'y avait pas assez d'espace, ils privilégiaient les transactions offrant les frais les plus élevés.
Ce système était extrêmement simple et favorable à la décentralisation : en tant que mineur, en exécutant simplement le logiciel par défaut, vous pouviez obtenir les mêmes revenus par bloc qu'une grande mine hautement spécialisée. Cependant, vers 2020, certains ont commencé à exploiter ce que l'on appelle la valeur extractible par les mineurs (MEV) — des revenus accessibles uniquement via des stratégies complexes comprenant les dynamiques internes des protocoles DeFi.
Prenons l'exemple d'un DEX comme Uniswap. Supposons qu'à l'instant T, le taux USD/ETH soit de 3000 dollars sur les exchanges centralisés et sur Uniswap. À l'instant T+11, le taux monte à 3005 dollars sur les exchanges centralisés, mais aucun nouveau bloc Ethereum n'a encore été produit. À T+12, c'est chose faite. Celui qui crée ce bloc peut alors insérer en première transaction une série d'achats sur Uniswap, acquérant tout l'ETH disponible entre 3000 et 3004 dollars. Ce gain supplémentaire constitue du MEV. Des cas similaires existent dans d'autres applications. Le document Flash Boys 2.0, publié en 2019, détaille précisément ces phénomènes.
Graphique du papier Flash Boys 2.0 illustrant les revenus potentiels générés par diverses méthodes.
Le problème est que cela brise l'équité originelle du minage (ou, après 2022, de la proposition de blocs) : désormais, les grands acteurs disposant de meilleures capacités pour optimiser ces algorithmes d'extraction obtiennent de meilleurs rendements par bloc.
Depuis lors, deux stratégies s'affrontent, que je nomme minimisation du MEV et isolement du MEV. La minimisation du MEV prend deux formes : (i) développer activement des alternatives sans MEV à Uniswap (comme Cowswap), et (ii) concevoir des technologies intégrées au protocole, telles que le mempool chiffré, qui réduisent l'information accessible aux producteurs de blocs, limitant ainsi leurs gains. En particulier, un mempool chiffré empêcherait des attaques comme le sandwiching, où une transaction est placée avant et après celle d’un utilisateur afin de profiter économiquement de lui (« front-running »).
L’isolement du MEV consiste à accepter l’existence du MEV, mais à limiter son impact sur la centralisation du staking en divisant le marché en deux rôles : les validateurs prouvent et proposent les blocs, tandis que la sélection du contenu du bloc est gérée par un mécanisme d’enchères. Les petits stakeurs n’ont plus besoin d’optimiser eux-mêmes les arbitrages DeFi ; ils rejoignent simplement le protocole d’enchères et acceptent la meilleure offre. On parle alors de séparation Proposer / Builder (PBS). Cette approche a des précédents dans d’autres secteurs : par exemple, la restauration reste décentralisée en partie parce qu’elle délègue certaines fonctions très centralisables (comme la chaîne d’approvisionnement) à des fournisseurs concentrés. Jusqu’à présent, PBS a réussi à maintenir une égalité entre petits et grands validateurs, du moins en ce qui concerne le MEV. Toutefois, il pose un autre problème : la tâche de choisir quelles transactions inclure devient plus centralisée.
Mon avis a toujours été que la minimisation du MEV est souhaitable, et que nous devrions la poursuivre (j’utilise personnellement souvent Cowswap !) — bien que le mempool chiffré présente de nombreux défis. Mais même avec ces efforts, la minimisation du MEV pourrait ne pas suffire ; le MEV ne tombera probablement jamais à zéro, ni même près de zéro. Nous avons donc également besoin d’une forme d’isolement du MEV. Cela pose une question intéressante : comment rendre cette « boîte d’isolement » aussi petite que possible ? Comment donner aux builders le moins de pouvoir possible, tout en leur permettant d’exercer leur rôle d’optimisation des arbitrages et autres formes de capture de MEV ?
Si les builders ont le pouvoir d’exclure complètement certaines transactions des blocs, des abus deviennent faciles. Imaginons que vous possédiez une position de dette collatéralisée (CDP) dans un protocole DeFi, soutenue par un actif dont le prix chute rapidement. Vous souhaitez ajouter du collatéral ou fermer votre CDP. Un builder malveillant pourrait conspirer pour refuser d’inclure votre transaction, retardant ainsi son traitement jusqu’à ce que le prix baisse suffisamment pour provoquer une liquidation forcée. Dans ce cas, vous devriez payer une grosse pénalité, dont une grande part irait au builder. Comment alors empêcher les builders d’exclure des transactions et de perpétrer de telles attaques ?
C’est ici que les listes d’inclusion entrent en jeu.
Source : ethresear.ch
Les listes d’inclusion permettent au proposant de bloc (c’est-à-dire le stakeholder) de définir les transactions devant impérativement figurer dans le bloc. Les builders peuvent toujours réordonner ou insérer leurs propres transactions, mais ils doivent inclure celles du proposant. Finalement, on a modifié les listes d’inclusion pour qu’elles s’appliquent au prochain bloc plutôt qu’au bloc courant. Dans tous les cas, elles retirent aux builders le pouvoir d’exclure totalement des transactions.
Le MEV est un problème complexe ; même cette description passe sous silence de nombreuses subtilités importantes. Comme on dit : « Vous pourriez ne pas chercher le MEV, mais le MEV, lui, vous cherche ». Les chercheurs Ethereum travaillent depuis longtemps de manière cohérente sur l’objectif de « minimiser la boîte d’isolement », en réduisant autant que possible les dommages que les builders pourraient causer (par exemple, en excluant ou retardant des transactions pour attaquer des applications spécifiques).
Cela dit, je pense que nous pouvons aller plus loin. Historiquement, les listes d’inclusion ont souvent été perçues comme une « fonctionnalité de secours » : normalement, on n’y pense pas, mais elles offrent une voie de repli si un builder malveillant commence à faire des choses extrêmes. Cette attitude se reflète dans les décisions de conception actuelles : dans l’EIP en cours, la limite de gaz pour les listes d’inclusion est d’environ 2,1 millions. Mais nous pourrions opérer un changement philosophique dans notre vision des listes d’inclusion : considérer la liste d’inclusion comme le bloc principal, et le rôle du builder comme une fonction secondaire ajoutant quelques transactions pour capturer du MEV. Et si les builders avaient seulement une limite de 2,1 millions de gaz ?
Je trouve cette idée — vraiment pousser la boîte d’isolement au minimum — très intéressante, et je suis favorable à ce changement de direction. Cela marque une rupture avec la « philosophie de l’ère 2021 » : à cette époque, nous étions plus enclins à penser que, puisque nous avons maintenant des builders, nous pouvons « surcharger » leurs fonctions pour mieux servir les utilisateurs, par exemple en supportant le marché des frais ERC-4337. Dans cette nouvelle philosophie, la partie validation des transactions ERC-4337 doit être intégrée au protocole. Heureusement, l’équipe ERC-4337 semble de plus en plus favorable à cette évolution.
En résumé : la réflexion autour du MEV revient à redonner du pouvoir aux producteurs de blocs, notamment en leur permettant d’assurer directement l’inclusion des transactions des utilisateurs. Les propositions d’abstraction de compte reviennent aussi vers l’élimination de la dépendance aux relais centralisés, voire aux bundlers. Pourtant, on peut raisonnablement argumenter que nous n’allons pas assez loin, et je pense que la pression pour aller plus loin dans cette direction est très bienvenue.
Staking liquide
Aujourd’hui, les stakers individuels représentent une petite fraction du total du staking Ethereum, et la majorité est réalisée par divers fournisseurs — certains opérateurs centralisés, d’autres des DAO comme Lido ou RocketPool.
J’ai mené mes propres recherches — sondages, enquêtes, conversations en face à face — en posant la question : « Pourquoi ne faites-vous pas du staking individuel aujourd’hui ? ». Pour moi, un écosystème solide de staking individuel est le résultat souhaité pour le staking Ethereum, et l’un des meilleurs aspects d’Ethereum est que nous tentons réellement de le soutenir, plutôt que de céder simplement à la délégation. Pourtant, nous sommes loin de cet objectif. Mes sondages révèlent des tendances claires :
La grande majorité de ceux qui ne font pas de staking individuel citent comme raison principale le seuil minimal de 32 ETH.
Parmi ceux qui donnent d'autres raisons, le défi technique de lancer et maintenir un nœud validateur arrive en tête.
La perte de liquidité immédiate de l’ETH, les risques de sécurité liés à une clé privée « chaude », et l’incapacité de participer simultanément aux protocoles DeFi sont des problèmes importants mais moindres.
Sondage Farcaster sur les raisons principales du non-staking individuel.
La recherche sur le staking doit résoudre deux questions clés :
Comment résoudre ces préoccupations ?
Même si des solutions existent pour la plupart des problèmes, comment garantir malgré tout la stabilité et la robustesse du protocole face aux attaques, si la majorité continue de déléguer ?
De nombreux projets de recherche et développement en cours visent justement à résoudre ces problèmes :
Les arbres de Verkle combinés à l’EIP-4444 permettent aux nœuds de staking de fonctionner avec très peu d’espace disque. Ils permettent aussi une synchronisation quasi instantanée, simplifiant grandement l’installation et les changements d’implémentation. Ils rendent aussi les clients légers d’Ethereum plus viables en réduisant la bande passante nécessaire pour fournir des preuves d’accès à l’état.
Des recherches (comme ces propositions) explorent des moyens de supporter un ensemble plus grand de validateurs (permettant ainsi des seuils de staking plus bas), tout en réduisant la charge pour les nœuds de consensus. Ces idées pourraient être intégrées dans le cadre de la finalité par slot unique. Cela renforcerait aussi la sécurité des clients légers, car ils pourraient vérifier l’intégralité des signatures plutôt que de dépendre d’un comité de synchronisation.
Les optimisations continues des clients Ethereum réduisent constamment le coût et la difficulté d’exécuter un nœud validateur.
Les recherches sur les plafonds de pénalités pourraient atténuer les craintes liées aux clés privées, et permettre aux stakers d’utiliser leur ETH mis en staking dans des protocoles DeFi (s’ils le souhaitent).
Les identifiants de retrait 0x01 permettent aux stakers de définir une adresse ETH comme destination des retraits. Cela rend les pools de staking décentralisés plus viables, leur offrant un avantage sur les pools centralisés.
Nous pouvons encore faire davantage. Théoriquement, permettre aux validateurs de retirer plus rapidement : même si l’ensemble des validateurs change de quelques pourcents à chaque finalisation (une fois par période), Casper FFG reste sécurisé. Ainsi, en y travaillant, nous pourrions fortement raccourcir la durée. Si nous voulons réduire drastiquement le dépôt minimal, nous pouvons prendre des décisions difficiles et faire des compromis ailleurs. Par exemple, multiplier par quatre le temps de finalisation permettrait de diviser par quatre le dépôt minimal. La finalité par slot unique résoudra plus tard ce problème en allant au-delà du modèle « chaque staker participe à chaque époque ».
Une autre dimension importante concerne l’économie du staking. Une question clé : voulons-nous que le staking devienne une activité de niche, ou voulons-nous que tout le monde, ou presque, stakke la totalité de ses ETH ? Si tout le monde stakait, quelle responsabilité chacun devrait-il assumer ? Si les gens délèguent simplement par paresse, cela pourrait mener à la centralisation. Il existe ici des questions philosophiques profondes. Une mauvaise réponse pourrait entraîner Ethereum vers la centralisation, « recréant par des étapes supplémentaires le système financier traditionnel » ; une bonne réponse pourrait créer un brillant exemple d’écosystème réussi, avec une base large et diversifiée de stakers indépendants et des pools hautement décentralisés. Ces questions touchent au cœur économique et aux valeurs d’Ethereum, nécessitant donc une participation plus large.
Exigences matérielles des nœuds
Nombre des enjeux clés de la décentralisation d’Ethereum se ramènent finalement à une question qui définit les blockchains depuis dix ans : comment rendre l’exécution d’un nœud aussi facile que possible, et comment y parvenir ?
Aujourd’hui, exécuter un nœud est difficile. La plupart des gens ne le font pas. Sur mon ordinateur portable, utilisé pour écrire cet article, j’ai un nœud reth occupant 2,1 To — déjà le résultat d’un travail héroïque d’ingénierie logicielle et d’optimisation. J’ai dû acheter un disque dur externe de 4 To juste pour le stocker. Nous voulons tous que l’exécution d’un nœud devienne plus facile. Dans mon monde idéal, les gens pourraient exécuter un nœud sur leur téléphone.
Comme mentionné ci-dessus, l’EIP-4444 et les arbres de Verkle sont deux technologies clés pour atteindre cet objectif. Une fois implémentées, les exigences matérielles des nœuds pourraient chuter à moins de cent gigaoctets, voire tendre vers zéro si on supprime totalement la responsabilité de stockage historique (peut-être uniquement pour les nœuds non validateurs). Un ZK-EVM de type 1 éliminerait le besoin d’exécuter soi-même les calculs EVM, car on pourrait simplement vérifier des preuves de leur exactitude. Dans mon monde idéal, toutes ces technologies seraient combinées, et même les portefeuilles navigateur Ethereum (comme MetaMask ou Rabby) intégreraient un nœud interne capable de vérifier ces preuves, d’échantillonner la disponibilité des données, et de s’assurer que la chaîne est correcte.
Cette vision est souvent appelée « The Verge ».
Tout cela est bien connu, même par ceux qui s’inquiètent de la taille des nœuds Ethereum. Pourtant, une préoccupation majeure subsiste : si nous déchargeons les nœuds de la responsabilité de maintenir l’état et de fournir des preuves, cela ne crée-t-il pas un vecteur de centralisation ? Même s’ils ne peuvent pas tricher en fournissant des données invalides, une dépendance excessive ne va-t-elle pas à l’encontre des principes d’Ethereum ?
Une version récente de cette inquiétude concerne l’EIP-4444 : si les nœuds Ethereum standards n’ont plus à stocker l’historique ancien, qui le fera ? Une réponse fréquente est que suffisamment de grands acteurs (explorateurs de blocs, exchanges, couches 2) auront intérêt à conserver ces données, et comparé aux 100 pétaoctets archivés par Wayback Machine, la chaîne Ethereum est minuscule. Croire que des données historiques pourraient réellement être perdues semble absurde.
Mais cet argument repose sur un petit nombre d’acteurs puissants. Dans ma classification des modèles de confiance, c’est une hypothèse « 1 parmi N », avec N très petit. Cela comporte des risques de queue. Une solution serait de stocker l’historique ancien dans un réseau pair-à-pair, où chaque nœud ne conserve qu’une petite partie des données. Un tel réseau offrirait une réplication suffisante pour la robustesse : chaque donnée aurait des milliers de copies, et à l’avenir, on pourrait utiliser des codes d’effacement (en pratique, en plaçant l’historique dans des blobs à la EIP-4844, qui incorporent déjà des codes d’effacement) pour renforcer encore la stabilité.
Les blobs contiennent des codes d’effacement internes et entre blobs. La méthode la plus simple pour un stockage hyper stable de tout l’historique d’Ethereum consisterait probablement à placer les blocs beacon et execution dans des blobs. Source : codex.storage
Longtemps, ce travail a été marginalisé. Le réseau Portal existe, mais n’a pas reçu l’attention proportionnelle à son importance future dans Ethereum. Heureusement, un élan grandit aujourd’hui pour investir davantage dans une version minimaliste du réseau Portal, centrée sur le stockage distribué et l’accessibilité historique. Nous devrions capitaliser sur cela, et travailler ensemble pour implémenter rapidement l’EIP-4444, accompagné d’un solide réseau pair-à-pair décentralisé pour stocker et récupérer l’historique ancien.
Pour l’état et le ZK-EVM, cette approche distribuée est plus difficile. Pour construire un bloc efficace, il faut posséder l’état complet. Dans ce cas, je penche personnellement pour une approche pragmatique : définir et maintenir un niveau d’exigence matérielle pour un « nœud complet », supérieur certes au coût (idéalement en baisse constante) d’un simple nœud de vérification, mais suffisamment bas pour rester accessible aux passionnés. Nous comptons sur l’hypothèse « 1 parmi N », en veillant à ce que N soit suffisamment grand.
La génération des preuves ZK-EVM pourrait être la partie la plus délicate : un générateur de preuves ZK-EVM en temps réel pourrait exiger un matériel plus puissant qu’un nœud archive, même avec des avancées comme Binius et des limites multidimensionnelles du gaz. Nous pourrions travailler sur un réseau de preuve distribué, où chaque nœud calcule, par exemple, 1 % de la preuve d’exécution d’un bloc, et le producteur de bloc agrège ensuite cent preuves. Les arbres d’agrégation de preuves pourraient aider davantage. Mais si cela ne fonctionne pas bien, un autre compromis serait d’accepter des exigences matérielles plus élevées pour les preuves, tout en garantissant que le « nœud complet » puisse valider directement un bloc Ethereum (sans preuve) assez vite pour participer efficacement au réseau.
Conclusion
Je pense que l’ère 2021 de la pensée Ethereum s’est effectivement habituée à transférer des responsabilités à quelques grands acteurs, dès lors qu’un mécanisme de marché ou un système de preuves à connaissance nulle oblige ces acteurs centralisés à agir honnêtement. De tels systèmes fonctionnent généralement bien en conditions normales, mais connaissent des effondrements catastrophiques dans les pires scénarios.
Dans le même temps, je tiens à souligner que les propositions actuelles pour le protocole Ethereum s’écartent fortement de ce modèle, et prennent beaucoup plus au sérieux les besoins d’un réseau véritablement décentralisé. Les idées autour des nœuds sans état, l’atténuation du MEV, la finalité par slot unique et concepts similaires vont clairement dans ce sens. Il y a un an, on envisageait sérieusement l’échantillonnage de disponibilité des données via des relais semi-centralisés. Cette année, nous n’avons plus besoin de cela : PeerDAS a progressé de manière surprenante.
Mais sur les trois grandes questions que j’ai abordées, ainsi que sur bien d’autres, nous pouvons encore faire beaucoup pour aller plus loin. Helios a fait d’énormes progrès vers un « vrai client léger » pour Ethereum. Maintenant, nous devons intégrer cela par défaut dans les portefeuilles Ethereum, demander aux fournisseurs RPC de fournir des preuves et leurs résultats pour vérification, et étendre la technologie des clients légers aux protocoles de couche 2. Si Ethereum s’étend via une feuille de route centrée sur les rollups, alors les couches 2 doivent bénéficier des mêmes garanties de sécurité et de décentralisation que la couche 1. Dans un monde centré sur les rollups, bien d’autres choses méritent une attention accrue ; les ponts inter-L2 décentralisés et efficaces en sont un exemple parmi d’autres. De nombreuses dApps récupèrent des logs via des protocoles centralisés car le balayage natif des logs Ethereum est devenu trop lent. Nous pouvons améliorer cela via un sous-protocole décentralisé spécialisé ; voici une suggestion que j’ai faite à ce sujet.
Il existe un nombre quasi infini de projets blockchain ciblant le marché du « nous serons ultra-rapides, nous penserons à la décentralisation plus tard ». Je pense qu’Ethereum ne devrait pas rejoindre ce peloton. La couche L1 d’Ethereum peut et doit devenir une base solide pour des projets L2 adoptant des approches massivement évoluées, utilisant Ethereum comme pilier de décentralisation et de sécurité. Même une approche centrée sur les L2 exige que la L1 soit suffisamment évolutive pour traiter un grand volume d’opérations. Mais nous devrions profondément respecter ce qui rend Ethereum unique, et continuer à protéger et améliorer ces caractéristiques à mesure qu’Ethereum s’agrandit.
Remerciements particuliers à Dankrad Feist, Caspar Schwarz-Schilling et Francesco pour leurs retours rapides et leurs relectures.
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
@VitalikButerin
