Nouvel article de Vitalik : Les futurs possibles d'Ethereum, the Merge
TechFlow SélectionTechFlow Sélection
Nouvel article de Vitalik : Les futurs possibles d'Ethereum, the Merge
La démocratisation du staking, des confirmations de transactions plus rapides, la résistance aux attaques quantiques... À quoi ressemblera l'avenir d'Ethereum ?
Dédié à des analyses Web3 approfondiesRédaction : Vitalik Buterin
Traduction : Alex Liu, Foresight News
Merci particulièrement à Justin Drake, Hsiao-wei Wang, @antonttc, Anders Elowsson et Francesco pour leurs retours et relectures.
Initialement, « the Merge » désignait l'événement le plus important de l'histoire du protocole Ethereum depuis son lancement : la transition tant attendue et difficilement acquise du proof-of-work (PoW) au proof-of-stake (PoS). Aujourd'hui, Ethereum fonctionne comme un système PoS stable depuis presque deux ans, et ce PoS s'est révélé excellent en termes de stabilité, de performance et de prévention des risques de centralisation. Toutefois, il reste plusieurs domaines importants du PoS nécessitant des améliorations.
Ma feuille de route 2023 les divise en deux grandes catégories : d'une part, améliorer les fonctionnalités techniques telles que la stabilité, la performance et l'accessibilité aux petits validateurs, et d'autre part, mettre en œuvre des changements économiques destinés à atténuer les risques de centralisation. La première catégorie a récupéré le nom « the Merge », tandis que la seconde fait désormais partie de « the Scourge ».
Cet article se concentre sur la composante « Merge » : quelles sont les pistes d'amélioration possibles dans la conception technique du proof-of-stake, et comment y parvenir ?
Il ne s'agit pas ici d'une liste exhaustive de toutes les évolutions envisageables pour le PoS, mais plutôt d'un inventaire des idées actuellement étudiées activement.
Finalité en un seul slot et démocratisation du staking
Quel problème cherchons-nous à résoudre ?
Aujourd'hui, la finalité d'un bloc requiert 2 à 3 epochs (environ 15 minutes), et il faut déposer 32 ETH pour devenir validateur. Cette configuration initiale constituait un compromis visant à concilier trois objectifs :
-
Maximiser le nombre de validateurs pouvant participer au staking (ce qui implique de minimiser le seuil minimal requis en ETH)
-
Réduire au minimum le temps nécessaire pour atteindre la finalité
-
Réduire au minimum la charge opérationnelle pour les nœuds, notamment le coût de téléchargement, vérification et rebroadcast de toutes les signatures des validateurs
Ces trois objectifs sont contradictoires : pour garantir une finalité économique (c’est-à-dire qu’un attaquant devrait brûler une grande quantité d’ETH pour inverser un bloc finalisé), chaque validateur doit signer deux messages lors de chaque processus de finalité. Par conséquent, si vous avez beaucoup de validateurs, soit cela prend beaucoup de temps pour traiter toutes les signatures, soit vous avez besoin de nœuds extrêmement puissants pour tout traiter simultanément.
Notez que tout ceci repose sur un objectif fondamental d’Ethereum : garantir qu’une attaque réussie coûte très cher à l’attaquant. C’est précisément ce que signifie le terme « finalité économique ». Sans cet objectif, nous pourrions résoudre le problème en sélectionnant aléatoirement un comité pour finaliser chaque bloc. Certaines blockchains qui n’essaient pas d’atteindre la finalité économique, comme Algorand, font généralement ainsi. Mais cette approche pose un problème : si un attaquant contrôle 51 % des validateurs, il peut mener une attaque à très faible coût (inverser la finalité, exercer de la censure ou retarder la finalité) en utilisant uniquement une fraction de ses nœuds. Les membres du comité peuvent certes être détectés comme participants à l’attaque et sanctionnés, que ce soit via slashing ou via un fork doux coordonné socialement. Cela signifie que l’attaquant peut répéter ses attaques indéfiniment, perdant à chaque fois seulement une petite partie de sa mise. Par conséquent, si nous voulons une finalité économique, l’approche simple basée sur des comités ne fonctionne pas, et il semble effectivement nécessaire que tous les validateurs participent.
Nous souhaiterions idéalement préserver la finalité économique tout en améliorant deux aspects actuels :
-
Finaliser les blocs en un seul slot (idéalement, en maintenant voire en réduisant la durée actuelle de 12 secondes), plutôt que 15 minutes
-
Permettre aux validateurs de participer avec seulement 1 ETH (au lieu de 32 ETH)
Le premier objectif poursuit deux buts, que l’on peut tous deux interpréter comme « rapprocher les caractéristiques d’Ethereum de celles des blockchains L1 performantes (mais plus centralisées) ».
Premièrement, cela garantit que tous les utilisateurs d’Ethereum bénéficient réellement du niveau de sécurité accru offert par le mécanisme de finalité. Actuellement, la plupart des utilisateurs n’y parviennent pas car ils refusent d’attendre 15 minutes ; avec une finalité en un seul slot, les utilisateurs voient leur transaction confirmée presque immédiatement après validation. Deuxièmement, cela simplifie les protocoles et les infrastructures environnantes, car les utilisateurs et applications n’ont plus à craindre la possibilité d’un réorganisme (sauf dans des cas rares comme les inactivity leaks).
Le deuxième objectif découle du désir de soutenir les validateurs individuels (« solo stakers »). Des sondages répétés montrent que le principal obstacle empêchant davantage de personnes de staker individuellement est le seuil minimum de 32 ETH. Le ramener à 1 ETH résoudrait ce problème, et d’autres facteurs deviendraient alors dominants.
Un défi existe actuellement : l’accélération de la finalité et la démocratisation du staking entrent en conflit avec l’objectif de minimisation de la charge opérationnelle. En réalité, c’est exactement pourquoi nous n’avons pas commencé avec une finalité en un seul slot. Heureusement, des recherches récentes proposent plusieurs voies pour surmonter ce problème.
Qu’est-ce que c’est et comment ça marche ?
La finalité en un seul slot consiste à utiliser un algorithme de consensus capable de finaliser un bloc en un seul slot. Ce n’est pas en soi un objectif difficile : de nombreux algorithmes, comme Tendermint, le font déjà. Une exigence spécifique à Ethereum est la prise en charge des inactivity leaks, propriété non supportée par Tendermint, qui permet à la chaîne de continuer et de se remettre même si plus d’un tiers des validateurs sont hors ligne. Heureusement, ce point est désormais résolu : des propositions existent pour adapter le consensus à la Tendermint afin d’intégrer les inactivity leaks.
La proposition principale pour la finalité en un seul slot
La partie plus difficile consiste à rendre compatible la finalité en un seul slot avec un très grand nombre de validateurs sans entraîner une charge excessive pour les opérateurs de nœuds. À cet effet, plusieurs solutions prometteuses sont étudiées :
-
Option 1 : Force brute — Développer de meilleurs protocoles d’agrégation de signatures, potentiellement utilisant des ZK-SNARK, permettant de gérer efficacement des millions de signatures par slot.
Horn, l’une des propositions pour un meilleur protocole d’agrégation
Option 2 : Comités Orbit — Un nouveau mécanisme permettant à un comité moyen sélectionné aléatoirement de finaliser la chaîne, tout en conservant la propriété essentielle du coût élevé pour un attaquant.
On peut voir Orbit SSF comme définissant un continuum entre deux extrêmes : x=0 (comités à la manière d’Algorand, sans finalité économique) et x=1 (l’état actuel d’Ethereum), avec des points intermédiaires où « Ethereum conserve une finalité économique suffisante pour rester très sécurisée, tout en n’exigeant qu’un échantillon modéré de validateurs aléatoires par slot, offrant ainsi des gains d’efficacité ».
Orbit exploite l’hétérogénéité existante dans les tailles de dépôts des validateurs afin d’obtenir autant de finalité économique que possible, tout en attribuant un rôle adapté aux petits validateurs. De plus, Orbit utilise un roulement lent des comités pour assurer une forte superposition entre les quorums adjacents, préservant ainsi la finalité économique même lors des transitions de comité.
-
Option 3 : Staking à deux niveaux — Un mécanisme avec deux types de stakers, l’un avec un dépôt élevé, l’autre avec un dépôt faible. Seul le niveau supérieur participerait directement à la finalité économique. Diverses propositions existent concernant les droits et responsabilités du niveau inférieur (voir par exemple le post sur le Rainbow staking). Idées communes :
-
Le droit de déléguer son staking à un staker de niveau supérieur
-
Quelques petits stakers aléatoires doivent valider et finaliser chaque bloc
-
Le droit de générer des listes d’inclusion (inclusion lists)
Liens avec les recherches existantes ?
-
Paths toward single slot finality (2022) : https://notes.ethereum.org/@vbuterin/single_slot_finality Chemins vers la finalité en un seul slot
-
A concrete proposal for a single slot finality protocol for Ethereum (2023) : https://eprint.iacr.org/2023/280 Proposition concrète pour un protocole de finalité en un seul slot pour Ethereum
-
Orbit SSF : https://ethresear.ch/t/orbit-ssf-solo-staking-friendly-validator-set-management-for-ssf/19928
-
Further analysis on Orbit-style mechanisms : https://ethresear.ch/t/vorbit-ssf-with-circular-and-spiral-finality-validator-selection-and-distribution/20464 Analyse complémentaire sur les mécanismes de type Orbit
-
Horn, signature aggregation protocol (2022) : https://ethresear.ch/t/horn-collecting-signatures-for-faster-finality/14219 Horn, protocole d’agrégation de signatures (2022)
-
Signature merging for large-scale consensus (2023) : https://ethresear.ch/t/signature-merging-for-large-scale-consensus/17386?u=asn Fusion de signatures pour un consensus à grande échelle (2023)
-
Signature aggregation protocol proposed by Khovratovich et al : https://hackmd.io/@7dpNYqjKQGeYC7wMlPxHtQ/BykM3ggu0#/ Protocole d’agrégation de signatures proposé par Khovratovich et al.
-
STARK-based signature aggregation (2022) : https://hackmd.io/@vbuterin/stark_aggregation Agrégation de signatures basée sur STARK (2022)
-
Rainbow staking : https://ethresear.ch/t/unbundling-staking-towards-rainbow-staking/18683 Rainbow staking
Quoi encore à faire, et quels compromis ?
Quatre grandes voies sont possibles (ou une combinaison mixte) :
-
Garder l’état actuel
-
SSF par force brute
-
Orbit SSF
-
SSF avec staking à deux niveaux
(1) signifie ne rien changer, mais cela maintient les défauts actuels en matière de sécurité perçue et de centralisation du staking.
(2) résout le problème par la technologie avancée. Cela exige d’agréger rapidement (en 5-10 secondes) un très grand nombre de signatures (plus d’un million). On peut y voir une stratégie consistant à minimiser la complexité du système en acceptant celle de l’encapsulation.
(3) évite les technologies complexes en repensant ingénieusement les hypothèses du protocole : on assouplit la condition de « finalité économique » pour viser un coût élevé pour l’attaquant, même si ce coût est inférieur de 10 fois à aujourd’hui (ex : 2,5 milliards USD au lieu de 25). Beaucoup pensent que la finalité économique actuelle d’Ethereum est bien supérieure au nécessaire, et que les principaux risques sont ailleurs, donc ce compromis pourrait être acceptable.
Le travail principal consiste à prouver la sécurité d’Orbit, à formaliser pleinement le mécanisme puis à l’implémenter. De plus, l’EIP-7251 (augmentation du solde effectif maximal) permet une consolidation volontaire des soldes, réduisant immédiatement la charge réseau et servant de phase initiale avant Orbit.
(4) évite à la fois la subtilité conceptuelle et la technologie avancée, mais crée un système à deux niveaux exposé à des risques de centralisation. Ces risques dépendent fortement des droits accordés au niveau inférieur. Par exemple :
-
Si les petits stakers doivent déléguer leur pouvoir de validation à des stakers supérieurs, la délégation peut se centraliser, menant à deux couches fortement centralisées.
-
Si un échantillon aléatoire du niveau inférieur doit approuver chaque bloc, un attaquant peut bloquer la finalité avec peu d’ETH.
-
Si les petits stakers ne peuvent que produire des listes d’inclusion, la couche de validation pourrait rester centralisée, permettant à une attaque 51 % sur cette couche de censurer les listes.
Des combinaisons sont possibles, par exemple :
(1 + 2) : Ajouter Orbit sans finalité en un seul slot
(1 + 3) : Utiliser des techniques de force brute pour réduire la taille minimale du dépôt, sans finalité en un seul slot. La quantité d’agrégation nécessaire est 64 fois moindre qu’en pure option (3), rendant le problème plus facile.
(2 + 3) : Utiliser Orbit SSF avec des paramètres conservateurs (ex : comité de 128k validateurs au lieu de 8k ou 32k) et des techniques pour le rendre très efficace.
(1 + 4) : Ajouter le rainbow staking sans finalité en un seul slot
Comment interagit-il avec le reste de la feuille de route ?
Outre ses autres avantages, la finalité en un seul slot réduit aussi les risques liés à certains types d’attaques MEV multi-blocs. En outre, dans un monde à finalité en un seul slot, les designs séparant proposer et bâtisseur (proposer-builder separation), ainsi que les pipelines internes de production de blocs, doivent être repensés.
Le point faible des stratégies par force brute est qu’elles rendent la réduction du temps de slot plus difficile.
Élection secrète du leader unique (Single secret leader election)
Quel problème cherchons-nous à résoudre ?
Aujourd’hui, on connaît à l’avance quel validateur proposera le prochain bloc. Cela crée une faille de sécurité : un attaquant peut surveiller le réseau, identifier les adresses IP des validateurs, et lancer une attaque DoS contre chacun au moment où il doit proposer un bloc.
Qu’est-ce que c’est et comment ça marche ?
La meilleure solution contre les attaques DoS est de masquer l’identité du validateur qui produira le prochain bloc, jusqu’à ce que ce bloc soit effectivement généré. Notez que si on abandonne la contrainte « unique », cela devient facile : une solution consiste à autoriser n’importe qui à créer le bloc suivant, à condition que son randao reveal soit inférieur à 2^(256)/N. En moyenne, un seul validateur satisfait cette condition, mais parfois deux ou plus, ou aucun. Combiner « secret » et « unique » reste difficile.
Les protocoles d’élection secrète du leader unique créent un « ID aveugle » pour chaque validateur via des techniques cryptographiques, puis offrent à plusieurs proposants la possibilité de mélanger le pool d’IDs aveugles (à la manière d’un mixnet). Pendant chaque slot, un ID aveugle aléatoire est sélectionné. Seul le propriétaire de cet ID peut produire une preuve valide pour proposer le bloc, mais personne d’autre ne sait à quel validateur il correspond.
Liens avec les recherches existantes ?
-
Article de Dan Boneh (2020) : https://eprint.iacr.org/2020/025.pdf
-
Whisk (proposition concrète pour Ethereum, 2022) : https://ethresear.ch/t/whisk-a-practical-shuffle-based-ssle-protocol-for-ethereum/11763
-
Balise Single secret leader election sur ethresear.ch : https://ethresear.ch/tag/single-secret-leader-election
-
SSLE simplifié utilisant des signatures en anneau : https://ethresear.ch/t/simplified-ssle/12315
Quoi encore à faire, et quels compromis ?
Il reste surtout à trouver et implémenter un protocole assez simple pour être intégré facilement sur le réseau principal. Nous valorisons la simplicité d’Ethereum, et ne souhaitons pas augmenter la complexité. Les implémentations SSLE examinées ajoutent des centaines de lignes au code de spécification et introduisent de nouvelles hypothèses cryptographiques complexes. Trouver une implémentation SSLE résistante au quantique et suffisamment efficace reste un problème ouvert.
À terme, une fois que nous aurons introduit des mécanismes de preuves zero-knowledge générales dans le protocole Ethereum L1 (par exemple pour l’arbre d’état ou un ZK-EVM), la complexité supplémentaire apportée par SSLE deviendra négligeable.
Une autre option est d’abandonner SSLE et d’utiliser des mesures hors-protocole (par exemple au niveau P2P) pour atténuer les attaques DoS.
Comment interagit-il avec le reste de la feuille de route ?
Si nous ajoutons un mécanisme séparant proposer et bâtisseur (APS), comme les execution tickets, alors les blocs d’exécution (contenant les transactions Ethereum) n’auront plus besoin de SSLE, car nous pouvons compter sur des bâtisseurs spécialisés. Toutefois, nous tirerions toujours profit du SSLE pour les blocs de consensus (contenant des messages de protocole comme les attestations, voire des fragments de listes d’inclusion, etc.).
Confirmation plus rapide des transactions
Quel problème cherchons-nous à résoudre ?
Réduire le délai de confirmation des transactions Ethereum, par exemple de 12 à 4 secondes, serait précieux. Cela améliorerait l’expérience utilisateur sur L1 et les rollups, rendrait les protocoles DeFi plus efficaces, et faciliterait la décentralisation des L2 en permettant davantage d’applications L2 de fonctionner sur des rollups basés sur L1, réduisant ainsi le besoin pour les L2 de construire leurs propres systèmes de tri centralisés.
Qu’est-ce que c’est et comment ça marche ?
Réduire la durée du slot, par exemple à 8 secondes ou 4 secondes. Cela n’implique pas nécessairement une finalité en 4 secondes : la finalité nécessite trois tours de communication, donc on pourrait faire en sorte que chaque tour corresponde à un bloc distinct, obtenant ainsi une confirmation préliminaire dès 4 secondes.
Permettre aux proposants de publier des pré-confirmations pendant le slot. Dans l’extrême, un proposant pourrait ajouter immédiatement chaque transaction qu’il voit à son bloc et publier instantanément un message de pré-confirmation (« ma première transaction est 0x1234… », « ma deuxième est 0x5678… »). Deux pré-confirmations conflictuelles pourraient être traitées de deux manières : (i) slasher le proposant, ou (ii) utiliser un prover pour voter en faveur de la première apparue.
Liens avec les recherches existantes ?
-
Based preconfirmations : https://ethresear.ch/t/based-preconfirmations/17353
-
Protocol-enforced proposer commitments (PEPC) : https://ethresear.ch/t/unbundling-pbs-towards-protocol-enforced-proposer-commitments-pepc/13879
-
Staggered periods across parallel chains (idée datant de 2018 pour obtenir une faible latence) : https://ethresear.ch/t/staggered-periods/1793
Quoi encore à faire, et quels compromis ?
Il n’est pas clair si réduire la durée du slot est réalisable. Même aujourd’hui, de nombreux validateurs ont du mal à recevoir les attestations assez vite. Passer à 4 secondes risquerait de centraliser les validateurs, rendant leur participation hors des zones développées peu pratique à cause de la latence. Spécifiquement, un slot de 4 secondes exigerait de limiter la latence réseau (« delta ») à 2 secondes.
L’inconvénient des pré-confirmations par le proposant est qu’elles améliorent fortement le cas moyen, mais n’améliorent pas le pire cas : si le proposant courant fonctionne bien, une transaction est pré-confirmée en 0,5 seconde au lieu de 6 secondes en moyenne, mais s’il est hors ligne ou défaillant, il faut encore attendre 12 secondes pour le prochain slot.
De plus, la manière de rémunérer les pré-confirmations reste un problème ouvert. Le proposant a intérêt à garder son option ouverte le plus longtemps possible. Si les bâtisseurs signent la rapidité de la pré-confirmation, l’expéditeur pourrait percevoir des frais conditionnellement à une confirmation immédiate, mais cela ajoute une charge aux bâtisseurs et pourrait nuire à leur neutralité en tant que « tuyau stupide ».
D’un autre côté, si nous n’essayons pas cela et gardons la finalité à 12 secondes (ou plus), l’écosystème privilégiera davantage les mécanismes de pré-confirmation des L2, et les interactions entre L2 seront plus lentes.
Comment interagit-il avec le reste de la feuille de route ?
Les pré-confirmations basées sur le proposant dépendent en réalité d’un mécanisme APS comme les execution tickets. Sinon, la pression pour fournir des pré-confirmations en temps réel serait trop forte pour les validateurs standards.
La durée minimale possible du slot dépend aussi de la structure du slot, elle-même influencée par le type d’APS et les listes d’inclusion adoptés. Certaines structures incluent moins de tours, donc favorisent les slots courts, mais impliquent d’autres compromis.
Autres domaines de recherche
Récupération après attaque 51%
On suppose souvent que, si une attaque 51% survient (y compris des formes non prouvables cryptographiquement, comme la censure), la communauté s’unira pour mettre en œuvre un fork doux minoritaire, assurant la victoire des « bons » et punissant les mauvais via inactivity leak ou slashing. Toutefois, cette forte dépendance au niveau social est discutable. Nous pourrions tenter de réduire cette dépendance en automatisant autant que possible le processus de récupération.
Une automatisation complète est impossible, car cela reviendrait à un algorithme de consensus tolérant >50% de fautes, dont on connaît les limites mathématiques strictes. Mais une automatisation partielle est envisageable : par exemple, si un client observe une transaction suffisamment longtemps, il pourrait automatiquement refuser la chaîne finalisée, voire rejeter la tête du choix de fork. Un objectif clé est d’empêcher les attaquants de remporter une victoire rapide et propre.
Augmenter le seuil du quorum
Aujourd’hui, un bloc est finalisé si 67% des mises le soutiennent. Certains jugent cela trop agressif. Dans toute l’histoire d’Ethereum, une seule panne de finalité (très brève) s’est produite. Si ce seuil passait à 80%, le nombre accru de phases non finales serait relativement faible, mais Ethereum gagnerait en sécurité : notamment, de nombreux cas controversés entraîneraient un arrêt temporaire de la finalité. Cela semble bien plus sain que de voir « le mauvais camp » gagner immédiatement, que l’attaquant ou un client erroné soit en cause.
Cela répond aussi à la question : « Quel sens a le staking individuel ? ». Aujourd’hui, la majorité du staking passe par des pools, et les stakers individuels semblent peu susceptibles d’atteindre 51% du staking. Mais si nous travaillons à faire monter les stakers individuels jusqu’au seuil de blocage du quorum, notamment si celui-ci est à 80% (donc 21% suffisent pour bloquer), cela paraît réalisable. Tant que les stakers individuels refusent de soutenir une attaque 51% (que ce soit pour restaurer la finalité ou exercer la censure), une telle attaque n’aura pas de « victoire nette », et les stakers individuels auront un motif pour organiser un fork doux minoritaire.
Notez qu’il existe une interaction entre seuil de quorum et mécanisme Orbit : si nous utilisons Orbit, la signification de « 21% des mises » deviendra plus complexe, dépendant en partie de la distribution des validateurs.
Résistance quantique
Metaculus estime actuellement, malgré des marges d’erreur larges, que les ordinateurs quantiques pourraient commencer à casser la cryptographie dans les années 2030 :
Des experts en informatique quantique comme Scott Aaronson commencent également à prendre plus au sérieux la possibilité que les ordinateurs quantiques deviennent efficaces à moyen terme. Cela impacte toute la feuille de route Ethereum : chaque composant du protocole actuel reposant sur les courbes elliptiques devra être remplacé par une alternative basée sur le hachage ou résistante au quantique. Cela signifie notamment que nous ne pouvons plus supposer pouvoir indéfiniment compter sur les excellentes propriétés de l’agrégation BLS pour gérer les signatures d’un grand ensemble de validateurs. Cela justifie une approche conservatrice dans la conception des performances du PoS, et un développement plus proactif de solutions alternatives résistantes au quantique.
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
