Dernière recherche de Vitalik : comment les protocoles LSDFi et la liquidité doivent-ils évoluer pour améliorer la décentralisation et réduire la surcharge de consensus ?

Cet article se concentre principalement sur deux défis majeurs auxquels sont confrontés les protocoles LSDFi et les pools de liquidité actuels : le risque de centralisation des opérateurs de nœuds et la charge de consensus inutile.

Auteur :Vitalik Buterin

Traduction : bayemon.eth, ChainCatcher

Le développement actuel d’Ethereum comprend une grande part de staking à deux niveaux (two-tiered staking), c’est-à-dire un modèle de staking impliquant deux types de participants.

• Opérateur de nœud (Node Operator) : exploite un nœud et met en jeu une certaine quantité de capital propre en garantie, soutenu par sa réputation
• Délégant (Delegator) : les délégants misent une certaine quantité d’Ethereum, sans montant minimum, et il n’y a pas de restrictions supplémentaires sur d’autres formes de participation en dehors de la garantie

Ce nouveau modèle de staking à deux niveaux est généré par les pools de staking qui fournissent massivement des tokens de staking liquides (LST). (Rocket Pool et Lido suivent ce modèle).

Cependant, le staking à deux niveaux actuel présente deux défauts :

• Risque de centralisation des opérateurs de nœuds : dans tous les pools de staking actuels, le mécanisme de sélection des opérateurs de nœuds reste excessivement centralisé
• Charge de consensus inutile : Ethereum L1 doit valider environ 800 000 signatures à chaque Epoch, ce qui représente une charge énorme pour un seul slot. De plus, comme les pools de staking liquides nécessitent beaucoup de capital, le réseau lui-même ne bénéficie pas pleinement de cette charge. Ainsi, si le réseau Ethereum pouvait atteindre une décentralisation et une sécurité raisonnables sans que chaque staker doive signer à chaque période, la communauté pourrait adopter ce type de solution, réduisant ainsi efficacement le nombre de signatures par période.

Cet article décrit des solutions à ces deux problèmes. Supposons d’abord que la majorité du capital soit détenue par ceux qui ne souhaitent pas gérer eux-mêmes des nœuds de staking sous la forme actuelle, signer à chaque slot, verrouiller des dépôts et les redistribuer aux pénalisés. Dans ce cas, quel rôle ces personnes pourraient-elles jouer pour contribuer de manière significative à la décentralisation et à la sécurité du réseau ?

Comment fonctionne actuellement le staking à deux niveaux ?

Actuellement, les deux pools de staking les plus populaires sont Lido et RocketPool. Pour Lido, les deux parties impliquées sont :

• Opérateurs de nœuds : élus par le Lido DAO, ce qui signifie en réalité qu’ils sont choisis par les détenteurs de LDO. Lorsqu’un utilisateur dépose de l’ETH dans le système de smart contracts de Lido, du stETH est créé, que les opérateurs de nœuds peuvent déposer dans le pool de staking (mais comme les certificats de retrait sont liés à l’adresse du smart contract, les opérateurs ne peuvent pas retirer librement).
• Délégants : lorsqu’un utilisateur dépose de l’ETH dans le système de smart contracts de Lido, du stETH est généré, que les opérateurs de nœuds peuvent utiliser comme staking (mais, là encore, les opérateurs ne peuvent pas retirer librement en raison de la liaison des certificats de retrait à l’adresse du smart contract).

Pour Rocket Pool :

• Opérateurs de nœuds : tout le monde peut devenir opérateur de nœud en déposant 8 ETH et une certaine quantité de tokens RPL.
• Délégants : lorsqu’un utilisateur dépose de l’ETH dans le système de smart contracts de Rocket Pool, du rETH est généré, que les opérateurs de nœuds peuvent utiliser comme staking (là encore, les opérateurs ne peuvent pas retirer librement en raison de la liaison des certificats de retrait à l’adresse du smart contract).

Le rôle du délégant

Dans ces systèmes (ou dans de nouveaux systèmes activés par de futurs changements de protocole), une question clé doit être posée : du point de vue du protocole, quel est l’intérêt d’avoir des délégants ?

Pour comprendre la profondeur de cette question, réfléchissons d’abord à la modification du protocole mentionnée dans le post, à savoir limiter la pénalité de slashing à 2 ETH. Rocket Pool réduirait également le montant de staking des opérateurs de nœuds à 2 ETH, et la part de marché de Rocket Pool augmenterait à 100 % (pour les stakers et détenteurs d’ETH, à mesure que rETH devient sans risque, presque tous les détenteurs d’ETH deviendraient détenteurs de rETH ou opérateurs de nœuds).

Supposons que le rendement pour les détenteurs de rETH soit de 3 % (y compris les récompenses internes au protocole et les frais de priorité + MEV), et que le rendement pour les opérateurs de nœuds soit de 4 %. Supposons également que l’offre totale d’ETH soit de 100 millions.

Le calcul est le suivant. Pour éviter les calculs d’intérêts composés, nous calculerons les rendements sur une base quotidienne :

Supposons maintenant que Rocket Pool n’existe pas, que le dépôt minimum pour chaque staker soit réduit à 2 ETH, que le plafond de liquidité totale soit de 6,25 millions d’ETH, et que le rendement pour les opérateurs de nœuds tombe à 1 %. Calculons à nouveau :

Considérons maintenant le coût d’une attaque dans ces deux scénarios. Dans le premier cas, un attaquant ne s’enregistrera pas comme délégant, car les délégants n’ont en réalité aucun droit de retrait, donc cela n’a pas de sens. Il utiliserait donc tout son ETH pour staker et devenir opérateur de nœud. Pour atteindre 1/3 du total staké, il lui faudrait déposer 2,08 millions d’ETH (ce qui reste un chiffre considérable). Dans le second cas, l’attaquant n’a qu’à déposer des fonds, et pour atteindre 1/3 du total du pool de staking, il lui faudrait également déposer 2,08 millions d’ETH.

Du point de vue de l’économie du staking et du coût d’attaque, le résultat final est exactement le même dans les deux cas. La part de l’offre totale d’ETH détenue par les opérateurs de nœuds augmente de 0,00256 % par jour, tandis que celle détenue par les non-opérateurs de nœuds diminue de 0,00017 % par jour. Le coût d’attaque est de 2,08 millions d’ETH. Ainsi, dans ce modèle, le délégant semble être une machine de type Rube Goldberg sans utilité, et une communauté rationnelle serait même encline à supprimer l’intermédiaire, à réduire considérablement les récompenses de staking et à limiter le total d’ETH staké à 6,25 millions.

Bien entendu, cet article ne préconise pas de réduire les récompenses de staking par 4 ni de fixer le plafond du staking à 6,25 millions. Au contraire, l’idée est qu’un système de staking bien conçu devrait posséder une caractéristique clé : les délégants doivent assumer une responsabilité importante dans l’ensemble du système. De plus, si les délégants agissent correctement principalement sous la pression de la communauté et par altruisme, cela n’est pas un problème ; après tout, c’est la principale force qui pousse aujourd’hui à la mise en œuvre de solutions de staking décentralisées et hautement sécurisées.

Les responsabilités du délégant

Si les délégants peuvent jouer un rôle significatif dans le système de staking, quel pourrait être ce rôle ?

Je pense qu’il existe deux types de réponses :

• Choix du délégant : le délégant peut choisir à quels opérateurs de nœuds il délègue ses intérêts. Le « poids » d’un opérateur de nœud dans le mécanisme de consensus est proportionnel au total staké qui lui est délégué. Actuellement, le mécanisme de choix du délégant reste limité, c’est-à-dire que les détenteurs de rETH ou de stETH peuvent retirer leur ETH et passer à un autre pool, mais la praticité réelle du choix du délégant pourrait être grandement améliorée.
• Participation au consensus : les délégants peuvent choisir de jouer un certain rôle dans le mécanisme de consensus, avec une responsabilité plus légère que le staking complet, sans longue période de sortie ni risque de slashing, mais pouvant tout de même servir de contrepoids aux opérateurs de nœuds.

Renforcer le pouvoir de choix des délégants

Il existe trois façons de renforcer le pouvoir de choix des délégants :

• Améliorer les outils de vote au sein des pools
• Augmenter la concurrence entre pools
• Fixer le pouvoir de représentation

Actuellement, le vote au sein des pools n’est pas vraiment pratique : dans Rocket Pool, tout le monde peut devenir opérateur de nœud, dans Lido, le vote est décidé par les détenteurs de LDO, et non par les détenteurs d’ETH. Lido a proposé une gouvernance double LDO + stETH, permettant d’activer un mécanisme de protection pour bloquer de nouveaux votes, empêchant ainsi l’ajout ou la suppression d’opérateurs de nœuds, ce qui donne une certaine voix aux détenteurs de stETH. Néanmoins, ce pouvoir reste limité et pourrait être renforcé.

La concurrence inter-pools existe déjà aujourd’hui, mais elle reste relativement faible. Le principal défi est que les tokens de staking des petits pools ont une liquidité plus faible, sont plus difficiles à faire confiance et sont moins soutenus par les applications.

Nous pouvons améliorer les deux premiers problèmes en limitant le montant des pénalités à une petite quantité, par exemple 2 ou 4 ETH. Ensuite, le reste de l’ETH peut être déposé et retiré en toute sécurité, permettant ainsi l’échange bidirectionnel même pour les petits pools de staking. Nous pouvons améliorer le troisième problème en créant un smart contract d’émission globale, pour gérer les LST (similaire à ERC-4337 et ERC-6900 pour les wallets), garantissant que tout token de staking émis via ce contrat est sécurisé.

À l’heure actuelle, il n’existe pas encore de pouvoir de représentation fixé dans le protocole, mais ce type de situation pourrait exister à l’avenir. Cela impliquerait une logique similaire aux idées ci-dessus, mais mise en œuvre au niveau du protocole. Pour les avantages et inconvénients de la fixation, voir cet article.

Toutes ces idées sont des améliorations par rapport à la situation actuelle, mais les avantages qu’elles peuvent offrir restent limités. La gouvernance par vote de tokens pose problème, et toute forme de choix de délégant non incitatif n’est qu’une forme de vote par token ; c’est la principale critique que j’ai à l’égard du proof-of-stake délégué. Il est donc également utile d’envisager des formes de participation au consensus plus puissantes.

Participation au consensus

Même sans tenir compte des problèmes actuels du staking liquide, la méthode de staking indépendant actuelle présente également des limites. Supposons l’utilisation de la finalité single-slot, idéalement chaque slot pourrait traiter environ 100 000 à 1 000 000 de signatures BLS. Même en utilisant des SNARKs récursifs pour agréger les signatures, pour la traçabilité, chaque signature doit être associée à un champ de bits de participant. Si Ethereum devient un réseau à l’échelle mondiale, même le stockage totalement décentralisé des champs de bits ne suffit pas : 16 Mo par slot ne permettent de supporter qu’environ 64 millions de stakers.

Dans cette optique, il est intéressant de diviser le staking en une couche à complexité élevée, soumise au slashing, et une couche à complexité plus faible. La couche à complexité élevée serait active à chaque slot, mais ne compterait que 10 000 participants, tandis que la couche à complexité plus faible n’interviendrait qu’occasionnellement. Cette dernière pourrait être totalement exempte de slashing, ou bien les participants pourraient être choisis au hasard pour déposer et être sujets au slashing sur quelques slots.

En pratique, cela peut se faire en augmentant le plafond de solde des validateurs, puis en augmentant le seuil de solde (par exemple, 2048 ETH) pour déterminer quels validateurs existants accèdent à la couche à complexité élevée ou faible.

Voici quelques suggestions sur la façon dont ces petits rôles de staking pourraient fonctionner :

• À chaque slot, 10 000 petits stakers sont choisis au hasard pour signer ce qu’ils estiment représenter le contenu du slot. Utiliser ces petits stakers comme entrée pour exécuter la règle de sélection de fork LMD GHOST. Si la sélection de fork menée par les petits stakers et celle menée par les opérateurs de nœuds divergent, le client utilisateur n’accepte aucun bloc comme finalisé et affiche une erreur. Cela oblige la communauté à intervenir pour résoudre la situation.
• Les délégants peuvent envoyer une transaction pour annoncer au réseau qu’ils sont en ligne et prêts à servir de petits stakers pour l’heure suivante. Les messages envoyés par les nœuds (blocs ou attestations) nécessitent la signature du nœud et d’un délégant choisi au hasard pour valider l’attestation du nœud.
• Les délégants peuvent envoyer une transaction pour annoncer au réseau qu’ils sont en ligne et prêts à servir de petits stakers pour l’heure suivante. À chaque période, 10 délégants sont choisis au hasard comme fournisseurs de listes d’inclusion (inclusion list provider), et 10 000 autres comme électeurs. Ces délégants sont choisis avant le slot k et disposent d’une fenêtre de k slots pour publier sur la chaîne un message confirmant leur présence en ligne. Chaque fournisseur de liste d’inclusion confirmé peut publier une liste d’inclusion ; pour chaque liste, il faut soit inclure les transactions de la liste, soit inclure le vote d’un électeur choisi au hasard indiquant que la liste n’est pas disponible, sinon le bloc est considéré comme invalide.

Ces petits nœuds de staking ont en commun de ne pas avoir à participer activement à chaque slot, et même un light node suffit pour tout faire. Ainsi, le déploiement d’un nœud ne nécessite que la validation de la couche de consensus, et les opérateurs de nœuds peuvent utiliser des applications ou des extensions de navigateur, qui sont pour la plupart passives, avec des exigences minimales en termes de calcul, de matériel ou de compétences techniques, sans même avoir besoin de technologies avancées comme ZK-EVM.

Ces « petits rôles » partagent également un objectif commun : empêcher une majorité de 51 % d’opérateurs de nœuds de censurer les transactions. Les deux premiers modèles permettent également d’empêcher la majorité de restaurer la finalité. Le troisième se concentre plus directement sur la censure, mais il est plus vulnérable au choix de la majorité des opérateurs de nœuds.

Ces idées sont rédigées dans la perspective de la mise en œuvre de solutions de staking à deux niveaux dans le protocole, mais elles peuvent aussi être mises en œuvre comme fonctionnalités des pools de staking. Voici quelques idées concrètes de mise en œuvre :

1. Du point de vue du protocole, chaque validateur peut définir deux clés de staking : une clé de staking continue P, ainsi qu’une adresse Ethereum liée pouvant être appelée, et produire une clé de staking rapide Q. Les informations de signature de sélection de fork du nœud sont suivies par P, les informations de signature par Q ; si les résultats stockés par PQ sont incohérents, aucun bloc n’est accepté comme finalisé, et le pool de liquidité est responsable de la sélection aléatoire des représentants.
2. Le protocole peut rester globalement inchangé, mais la clé publique du validateur pour la période sera définie comme P+Q. À noter que pour le slashing, deux messages sujets au slashing peuvent avoir des clés Q différentes, mais la même clé P ; la conception du slashing doit gérer ce cas.
3. La clé Q ne peut être utilisée dans le protocole que pour signer et valider les listes d’inclusion dans les blocs. Dans ce cas, Q peut être un smart contract plutôt qu’une clé unique, permettant ainsi aux pools de staking de mettre en œuvre une logique de vote plus complexe, acceptant les listes d’inclusion de fournisseurs choisis au hasard ou suffisamment de votes indiquant l’indisponibilité de la liste.

Conclusion

Si elles sont correctement mises en œuvre, des ajustements subtils à la conception du proof-of-stake peuvent résoudre deux problèmes à la fois :

• Offrir à ceux qui n’ont pas aujourd’hui les ressources ou la capacité de faire du proof-of-stake indépendant la possibilité de participer au proof-of-stake, leur permettant ainsi de conserver plus de pouvoir : (i) choisir quels nœuds soutenir et (ii) participer activement au consensus d’une manière plus légère mais néanmoins significative que l’exploitation complète d’un nœud de proof-of-stake. Tous les participants ne choisiront pas l’une ou l’autre option, mais tout participant qui en choisit une ou les deux bénéficiera d’une amélioration significative par rapport à la situation actuelle.
• Réduire le nombre de signatures que la couche de consensus d’Ethereum doit traiter à chaque slot, même dans un système de finalité single-slot, pour le ramener à un nombre plus faible, autour de 10 000. Cela favorisera également la décentralisation, facilitant l’exploitation d’un nœud de validation pour tous.

Pour ces solutions, il est possible de trouver des moyens de résoudre les problèmes à différents niveaux d’abstraction : les droits accordés aux utilisateurs dans le protocole de proof-of-stake, le choix des utilisateurs entre différents protocoles de proof-of-stake, et la mise en place dans le protocole. Ce choix doit être soigneusement réfléchi, et il est généralement préférable d’opter pour la mise en place minimale viable, afin de minimiser la complexité du protocole et l’impact sur l’économie du protocole, tout en atteignant les objectifs souhaités.

Remerciements particuliers à Mike Neuder, Justin Drake et d’autres pour leurs retours et leur relecture. Voir également : les articles précédents de Mike Neuder, Dankrad Feist et arixon.eth sur des sujets similaires.