Vitalik : Quelles améliorations peuvent encore être apportées au PoS d'Ethereum et quelles sont les voies possibles d'amélioration ?

Cet article se concentrera sur la question de la « fusion » d’Ethereum : quels aspects de la conception technique de la preuve d’enjeu peuvent encore être améliorés, et quelles sont les voies pour réaliser ces améliorations ?

Auteur :Vitalik Buterin

Traduction : Deng Tong, Jinse Finance

Remerciements particuliers à Justin Drake, Hsiao-wei Wang, @antonttc et Francesco pour leurs retours et relectures.

À l'origine, la « fusion » désignait l'événement le plus important de l'histoire du protocole Ethereum depuis son lancement : la transition tant attendue et difficile du proof-of-work vers le proof-of-stake. Aujourd'hui, Ethereum fonctionne comme un système de preuve d’enjeu stable depuis près de deux ans, et ce proof-of-stake a démontré d’excellentes performances en matière de stabilité, de performance et d’évitement des risques de centralisation. Cependant, il existe encore des domaines importants à améliorer pour la preuve d’enjeu.

Ma feuille de route de 2023 la divise en plusieurs parties : améliorer les caractéristiques techniques, telles que la stabilité, la performance et l’accessibilité pour les petits validateurs, ainsi que des changements économiques pour répondre aux risques de centralisation. La première a hérité du titre de « fusion », tandis que la seconde est devenue une partie du « fléau ».

Cet article se concentrera sur la partie « fusion » : quels aspects de la conception technique de la preuve d’enjeu peuvent encore être améliorés, et quelles sont les voies pour réaliser ces améliorations ?

Il ne s’agit pas d’une liste exhaustive des améliorations possibles pour la preuve d’enjeu ; il s’agit plutôt d’une liste d’idées activement à l’étude.

Finalité à slot unique et démocratisation du staking

Quel problème essayons-nous de résoudre ?

Aujourd’hui, il faut 2 à 3 epochs (environ 15 minutes) pour finaliser un bloc, et il faut 32 ETH pour devenir validateur. Cela a été initialement conçu comme un compromis entre trois objectifs :

• Maximiser le nombre de validateurs pouvant participer au staking (ce qui implique directement de minimiser le montant minimum d’ETH requis pour staker)
• Minimiser le temps de finalisation
• Minimiser la charge opérationnelle des nœuds

Ces trois objectifs sont en conflit : pour obtenir la finalité économique (c’est-à-dire qu’un attaquant doit détruire une grande quantité d’ETH pour revenir sur un bloc finalisé), chaque validateur doit signer deux messages à chaque finalisation. Ainsi, si vous avez beaucoup de validateurs, il faut soit beaucoup de temps pour traiter toutes les signatures, soit des nœuds très puissants pour traiter toutes les signatures simultanément.

Notez que tout cela dépend d’un objectif clé d’Ethereum : garantir que même une attaque réussie coûte très cher à l’attaquant. C’est ce que signifie le terme « finalité économique ». Si nous n’avions pas cet objectif, nous pourrions finaliser chaque slot en sélectionnant aléatoirement un comité (comme le fait Algorand). Mais le problème de cette méthode est que si un attaquant contrôle effectivement 51 % des validateurs, il peut attaquer à très faible coût (revenir sur des blocs finalisés, censurer ou retarder la finalité) : seuls certains nœuds du comité peuvent être détectés comme ayant participé à l’attaque et être pénalisés, que ce soit par slashing ou soft fork minoritaire. Cela signifie que l’attaquant peut attaquer la chaîne à plusieurs reprises. Donc, si nous voulons la finalité économique, la méthode simple basée sur les comités ne fonctionne pas, et à première vue, nous avons effectivement besoin de la participation de l’ensemble des validateurs.

Idéalement, nous souhaitons conserver la finalité économique tout en améliorant la situation sur deux points :

• Finaliser les blocs en un seul slot (idéalement en maintenant ou en réduisant la durée actuelle de 12 secondes), au lieu de 15 minutes
• Permettre aux validateurs de staker avec 1 ETH (abaisser le minimum de 32 ETH à 1 ETH)

Le premier objectif est motivé par deux raisons, toutes deux assimilables à « aligner les propriétés d’Ethereum sur celles des chaînes L1 (plus centralisées) axées sur la performance ».

Premièrement, cela garantit que tous les utilisateurs d’Ethereum bénéficient d’un niveau de sécurité plus élevé grâce au mécanisme de finalité. Aujourd’hui, la plupart des utilisateurs ne bénéficient pas de cette garantie, car ils ne veulent pas attendre 15 minutes ; avec la finalité à slot unique, les utilisateurs peuvent voir la finalité de leur transaction presque immédiatement après la confirmation. Deuxièmement, si les utilisateurs et les applications n’ont pas à s’inquiéter de la possibilité de rollback de la chaîne (sauf dans de rares cas de leak d’inactivité), cela simplifie le protocole et l’infrastructure environnante.

Le deuxième objectif vise à soutenir les stakers individuels. Les sondages répétés montrent que le principal obstacle à l’augmentation du nombre de stakers individuels est le seuil minimum de 32 ETH. Abaisser ce seuil à 1 ETH résoudrait ce problème, à tel point que d’autres facteurs deviendraient les principales limites au staking individuel.

Il existe un défi : les objectifs de finalité plus rapide et de staking plus démocratique sont tous deux en conflit avec l’objectif de minimisation des coûts. En fait, c’est précisément la raison pour laquelle nous n’avons pas adopté la finalité à slot unique dès le départ. Cependant, des recherches récentes ont proposé des solutions potentielles à ce problème.

Qu’est-ce que c’est et comment cela fonctionne-t-il ?

La finalité à slot unique consiste à utiliser un algorithme de consensus qui finalise un bloc en un seul slot. Ce n’est pas en soi un objectif difficile à atteindre : de nombreux algorithmes (comme le consensus Tendermint) y parviennent déjà avec d’excellentes propriétés. Une propriété idéale propre à Ethereum, que Tendermint ne prend pas en charge, est le leak d’inactivité, qui permet à la chaîne de continuer à fonctionner et de se rétablir même si plus d’un tiers des validateurs sont hors ligne. Heureusement, ce souhait est déjà satisfait : il existe des propositions pour modifier le consensus de style Tendermint afin de s’adapter au leak d’inactivité.

Propositions majeures pour la finalité à slot unique

La partie la plus difficile du problème est de savoir comment faire fonctionner la finalité à slot unique avec un très grand nombre de validateurs, sans entraîner des coûts d’exploitation de nœuds extrêmement élevés. Pour cela, il existe plusieurs solutions principales :

Option 1 : La force brute — travailler à de meilleurs protocoles d’agrégation de signatures, éventuellement en utilisant des ZK-SNARKs, permettant effectivement de traiter les signatures de millions de validateurs par slot.

Horn, l’un des designs proposés pour de meilleurs protocoles d’agrégation.

Option 2 : Orbit Committee — un nouveau mécanisme permettant à un comité de taille moyenne, choisi aléatoirement, de finaliser la chaîne, tout en conservant les propriétés de coût d’attaque recherchées.

Une façon de penser à Orbit SSF est qu’il ouvre un espace de compromis allant de x=0 (comité à la Algorand, sans finalité économique) à x=1 (état actuel d’Ethereum), en créant des points intermédiaires où Ethereum conserve suffisamment de finalité économique pour une sécurité extrême, tout en bénéficiant de l’efficacité d’un échantillon aléatoire de validateurs de taille moyenne pour chaque période.

Orbit exploite l’hétérogénéité préexistante des dépôts des validateurs pour obtenir autant de finalité économique que possible, tout en donnant un rôle approprié aux petits validateurs. De plus, Orbit utilise une rotation lente des comités pour garantir un fort chevauchement entre les quorums successifs, assurant ainsi que sa finalité économique s’applique également aux frontières de rotation des comités.

Option 3 : Staking à deux niveaux — un mécanisme où les stakers sont divisés en deux catégories, l’une avec des exigences de dépôt élevées, l’autre avec des exigences plus faibles. Seule la catégorie à dépôt élevé participe directement à la finalité économique. Il existe diverses propositions concernant les droits et responsabilités exacts de la catégorie à dépôt faible (voir par exemple le post Rainbow Staking). Les idées courantes incluent :

• Le droit de déléguer sa mise à un staker de niveau supérieur
• Des stakers de niveau inférieur, choisis aléatoirement, doivent attester et finaliser chaque bloc
• Le droit de générer la liste d’inclusion

Quels liens avec la recherche existante ?

• Voies vers la finalité à slot unique (2022) :
• Propositions concrètes pour le protocole de finalité à slot unique d’Ethereum (2023) :
• Orbit SSF :
• Analyses supplémentaires des mécanismes de style Orbit :
• Horn, protocole d’agrégation de signatures (2022) :
• Fusion de signatures pour consensus à grande échelle (2023) :
• Protocole d’agrégation de signatures proposé par Khovratovich et al. :
• Agrégation de signatures basée sur STARK (2022) :
• Rainbow Staking :

Que reste-t-il à faire ? Quels sont les compromis ?

Il existe quatre grandes voies possibles (on peut aussi adopter une voie hybride) :

• Maintenir le statu quo
• Orbit SSF
• SSF par la force brute
• SSF avec staking à deux niveaux

(1) signifie ne rien changer, garder le staking tel quel, mais cela rendrait l’expérience de sécurité et la centralisation du staking sur Ethereum pires qu’elles ne le sont.

(2) évite la « haute technologie » et résout le problème en repensant intelligemment les hypothèses du protocole : on assouplit l’exigence de « finalité économique » pour exiger un coût d’attaque élevé, mais on accepte que ce coût puisse être 10 fois inférieur à aujourd’hui (par exemple, un coût d’attaque de 2.5 billions de dollars au lieu de 25 billions). Beaucoup pensent que la finalité économique d’Ethereum aujourd’hui est bien supérieure à ce qui est nécessaire, et que les principaux risques de sécurité sont ailleurs, donc ce compromis est acceptable.

Le principal travail consiste à vérifier que le mécanisme Orbit est sûr et possède les propriétés souhaitées, puis à le formaliser et à l’implémenter. De plus, l’EIP-7251 (augmentation du solde effectif maximal) permet la fusion volontaire des soldes des validateurs, ce qui réduit immédiatement la charge de validation de la chaîne et constitue une première étape efficace pour le déploiement d’Orbit.

(3) évite la réflexion intelligente, mais résout le problème par la haute technologie. Cela nécessite de collecter un grand nombre de signatures (plus d’un million) en un temps très court (5-10 secondes).

(4) évite la réflexion intelligente et la haute technologie, mais crée un système de staking à deux niveaux, qui comporte toujours des risques de centralisation. Le risque dépend largement des droits spécifiques accordés au niveau inférieur. Par exemple :

• Si les stakers de niveau inférieur doivent déléguer leur droit d’attestation à ceux du niveau supérieur, la délégation peut se centraliser, et on se retrouve avec deux niveaux de staking très concentrés.
• Si un échantillonnage aléatoire du niveau inférieur est requis pour approuver chaque bloc, un attaquant peut dépenser très peu d’ETH pour empêcher la finalité.
• Si les stakers de niveau inférieur ne peuvent que produire la liste d’inclusion, le niveau d’attestation peut rester centralisé, et une attaque à 51 % sur ce niveau peut censurer la liste elle-même.

On peut combiner plusieurs stratégies, par exemple :

• (1 + 2) : ajouter Orbit sans mettre en œuvre la finalité à slot unique.
• (1 + 3) : utiliser la force brute pour réduire le dépôt minimum sans finalité à slot unique. L’agrégation requise est 64 fois moindre que dans le cas (3) pur, donc le problème est plus facile.
• (2 + 3) : utiliser des paramètres conservateurs pour Orbit SSF (par exemple, un comité de 128k validateurs au lieu de 8k ou 32k), et la force brute pour le rendre ultra-efficace.
• (1 + 4) : ajouter Rainbow Staking sans finalité à slot unique.

Comment cela interagit-il avec les autres parties de la feuille de route ?

Outre d’autres avantages, la finalité à slot unique réduit le risque de certains types d’attaques MEV multi-blocs. De plus, dans un monde à finalité à slot unique, la séparation validateurs-proposeurs et d’autres pipelines de production de blocs au sein du protocole doivent être conçus différemment.

La faiblesse des stratégies de force brute est qu’elles rendent plus difficile la réduction du temps de slot.

Élection de leader secret unique

Quel problème essayons-nous de résoudre ?

Aujourd’hui, on sait à l’avance quel validateur proposera le prochain bloc. Cela crée une faille de sécurité : un attaquant peut surveiller le réseau, identifier quels validateurs correspondent à quelles adresses IP, et lancer une attaque DoS contre eux juste avant qu’ils ne proposent un bloc.

Qu’est-ce que c’est ? Comment cela fonctionne-t-il ?

La meilleure façon de résoudre le problème DoS est de cacher l’information sur le validateur qui générera le prochain bloc, au moins jusqu’à ce que le bloc soit effectivement généré. Notez que si l’on supprime l’exigence d’« unicité », c’est facile : une solution consiste à permettre à quiconque de créer le prochain bloc, mais en exigeant que le randao révélé soit inférieur à 2^256 / N. En moyenne, un seul validateur pourra satisfaire à cette exigence — mais parfois deux ou plus, parfois aucun. Combiner l’exigence de « secret » et d’« unicité » a toujours été un défi.

Le protocole d’élection de leader secret unique résout ce problème en utilisant des techniques cryptographiques pour créer un ID de validateur « aveugle » pour chaque validateur, puis en permettant à de nombreux proposeurs de remanier et de ré-aveugler le pool d’ID aveugles (similaire au fonctionnement des mixnets). À chaque slot, un ID aveugle est choisi aléatoirement. Seul le propriétaire de cet ID aveugle peut générer une preuve valide pour proposer un bloc, mais personne ne sait à quel validateur correspond cet ID aveugle.

Protocole Whisk SSLE

Quels liens avec la recherche existante ?

• Article de Dan Boneh (2020) :
• Whisk (proposition concrète pour Ethereum, 2022) :
• Tag « single secret leader election » sur ethresear.ch :
• SSLE simplifié utilisant des signatures en anneau :

Que reste-t-il à faire ? Quels sont les compromis ?

En pratique, il reste à trouver et implémenter un protocole suffisamment simple pour être facilement déployé sur le mainnet. Nous tenons beaucoup à ce qu’Ethereum reste un protocole relativement simple, et nous ne voulons pas ajouter de complexité supplémentaire. Les implémentations SSLE que nous avons vues ajoutent des centaines de lignes de code de spécification et introduisent de nouvelles hypothèses cryptographiques complexes. Trouver une implémentation SSLE suffisamment efficace et résistante aux ordinateurs quantiques reste une question ouverte.

Il se peut qu’au final, la « complexité marginale supplémentaire » du SSLE ne devienne suffisamment faible que si nous introduisons, pour d’autres raisons (par exemple arbres d’état, ZK-EVM), des mécanismes de preuve à connaissance nulle génériques sur le L1 du protocole Ethereum.

Une autre option est d’ignorer complètement le SSLE et de traiter le problème DoS par des mesures d’atténuation hors protocole (par exemple au niveau p2p).

Comment cela interagit-il avec les autres parties de la feuille de route ?

Si nous ajoutons un mécanisme de séparation validateurs-proposeurs (APS), comme les execution tickets, alors les blocs d’exécution (ceux qui contiennent les transactions Ethereum) n’auront pas besoin de SSLE, car on peut compter sur des constructeurs de blocs spécialisés. Mais pour les blocs de consensus (ceux qui contiennent les messages du protocole, comme les attestations, listes d’inclusion potentielles, etc.), nous bénéficierons toujours du SSLE.

Confirmation de transaction plus rapide

Quel problème essayons-nous de résoudre ?

Il serait bénéfique de réduire encore le temps de confirmation des transactions sur Ethereum, de 12 secondes à 4 secondes. Cela améliorerait considérablement l’expérience utilisateur sur L1 et les rollups, tout en rendant les protocoles defi plus efficaces. Cela faciliterait également la décentralisation des L2, car cela permettrait à de nombreuses applications L2 de fonctionner sur des rollups, réduisant ainsi le besoin pour les L2 de construire leur propre séquenceur décentralisé basé sur un comité.

Qu’est-ce que c’est ? Comment cela fonctionne-t-il ?

Il existe essentiellement deux techniques :

• Réduire la durée du slot, par exemple à 8 ou 4 secondes. Cela ne signifie pas nécessairement une finalité en 4 secondes : la finalité nécessite essentiellement trois tours de communication, donc chaque tour peut être un bloc distinct, et après 4 secondes, on obtient au moins une confirmation préliminaire.
• Permettre au proposeur de publier des pré-confirmations pendant le slot. Dans le cas extrême, le proposeur peut inclure en temps réel les transactions qu’il voit dans son bloc et publier immédiatement un message de pré-confirmation pour chaque transaction (« ma première transaction est 0×1234... », « ma deuxième transaction est 0×5678... »). Les cas où le proposeur publie deux confirmations conflictuelles peuvent être traités de deux façons : (i) en pénalisant le proposeur, ou (ii) en laissant les validateurs voter pour déterminer laquelle est arrivée en premier.

Quels liens avec la recherche existante ?

• Basé sur les pré-confirmations :
• Proposer l’engagement obligatoire du proposeur au niveau du protocole (PEPC) :
• Cycles entrelacés sur chaînes parallèles (idée de 2018 pour faible latence) :

Que reste-t-il à faire ? Quels sont les compromis ?

On ne sait pas encore si la réduction du temps de slot est pratique. Même aujourd’hui, de nombreux validateurs dans le monde ont du mal à obtenir les attestations assez rapidement. Tenter un slot de 4 secondes comporte le risque de concentrer le set de validateurs, et à cause de la latence, il serait irréaliste d’être validateur en dehors de quelques régions privilégiées.

La faiblesse de la méthode de pré-confirmation par le proposeur est qu’elle améliore considérablement le temps d’inclusion en moyenne, mais pas dans le pire des cas : si le proposeur actuel fonctionne bien, votre transaction sera pré-confirmée en 0,5 seconde au lieu d’être incluse en (en moyenne) 6 secondes, mais si le proposeur est hors ligne ou défaillant, il faudra toujours attendre 12 secondes pour le slot suivant et un nouveau proposeur.

De plus, il reste une question ouverte sur la façon d’inciter les pré-confirmations. Le proposeur a intérêt à maximiser son optionalité aussi longtemps que possible. Si les validateurs signent la rapidité de la pré-confirmation, l’expéditeur de la transaction peut offrir une partie des frais en échange d’une pré-confirmation immédiate, mais cela impose une charge supplémentaire aux validateurs et peut rendre plus difficile leur rôle de « tube muet » neutre.

D’un autre côté, si l’on ne tente pas cela et que le temps de finalité reste à 12 secondes (ou plus), l’écosystème accordera plus d’importance aux mécanismes de pré-confirmation développés par les L2, et les interactions inter-L2 prendront plus de temps.

Comment cela interagit-il avec les autres parties de la feuille de route ?

Les pré-confirmations par le proposeur reposent en fait sur la séparation validateurs-proposeurs (APS), comme les execution tickets. Sinon, la pression pour fournir des pré-confirmations en temps réel pourrait être trop forte pour les validateurs ordinaires.

Autres domaines de recherche

Récupération après une attaque à 51 %

On suppose généralement qu’en cas d’attaque à 51 % (y compris des attaques non prouvables cryptographiquement, comme la censure), la communauté s’unira pour mettre en œuvre un soft fork minoritaire, garantissant la victoire des « bons » et la fuite ou le slashing des « mauvais » pour inactivité. Cependant, on peut dire que cette dépendance excessive à la couche sociale est malsaine. Nous pouvons essayer de réduire cette dépendance et d’automatiser autant que possible le processus de récupération.

Une automatisation complète est impossible, car sinon cela constituerait un algorithme de consensus tolérant à plus de 50 %, et nous connaissons déjà les limites mathématiques (très strictes) de tels algorithmes. Mais on peut réaliser une automatisation partielle : par exemple, si un client constate qu’une transaction a été censurée assez longtemps, il peut automatiquement refuser d’accepter une chaîne comme finalisée, voire comme tête du fork choice. Un objectif clé est de garantir que les « mauvais » ne puissent pas gagner rapidement lors d’une attaque.

Augmentation du seuil de quorum

Aujourd’hui, un bloc est finalisé si 67 % des stakers le soutiennent. Certains estiment que c’est trop agressif. Dans toute l’histoire d’Ethereum, il n’y a eu qu’un seul (très bref) échec de finalité. Si ce pourcentage était porté à 80 %, le nombre de périodes de non-finalité augmenterait relativement peu, mais Ethereum gagnerait en sécurité : en particulier, de nombreux cas plus controversés entraîneraient un arrêt temporaire de la finalité. Cela semble plus sain que de voir le « mauvais camp » gagner immédiatement, que ce soit un attaquant ou un client bogué.

Cela répond aussi à la question « à quoi sert le staking individuel ? ». Aujourd’hui, la plupart des stakers passent par des pools, et il semble peu probable que les stakers individuels atteignent 51 % de l’ETH staké. Cependant, si l’on s’efforce d’atteindre une minorité de blocage, en particulier si la majorité est portée à 80 % (donc la minorité de blocage n’a besoin que de 21 %), cela semble réalisable. Tant que les stakers individuels ne participent pas à une attaque à 51 % (retour de finalité ou censure), une telle attaque ne pourra pas obtenir une « victoire nette », et les stakers individuels aideront activement à organiser un soft fork minoritaire.

Résistance quantique

Metaculus estime actuellement qu’il est probable, malgré une grande incertitude, que les ordinateurs quantiques commencent à 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 fonctionnent réellement à moyen terme. Cela affecte toute la feuille de route d’Ethereum : cela signifie que chaque partie du protocole Ethereum qui dépend actuellement des courbes elliptiques devra être remplacée par une alternative basée sur le hash ou autre résistance quantique. Cela signifie en particulier que nous ne pouvons pas supposer que nous pourrons toujours compter sur les excellentes propriétés d’agrégation BLS pour traiter les signatures de grands ensembles de validateurs. Cela justifie une certaine prudence dans les hypothèses de performance de la preuve d’enjeu, et motive le développement plus actif d’alternatives résistantes aux ordinateurs quantiques.