Dernière recherche de Vitalik : Comment résoudre les risques provoqués par un grand nombre de doubles gages dans Ethereum ?

原文标题：《Modifications du protocole et du pool de jalonnement qui pourraient améliorer la décentralisation et réduire les frais généraux de consensus》

Auteur : Vitalik Buterin

Compilé par : bayemon.eth, ChainCatcher

*Un merci spécial à Mike Neuder, Justin Drake et autres pour leurs commentaires et critiques. Voir également : les articles précédents de Mike Neuder, Dankrad Feist et arixon.eth sur des sujets similaires. *

On peut dire que l’état de développement actuel d’Ethereum inclut un grand nombre de jalonnement à deux niveaux (jalonnement à deux niveaux).Le jalonnement à deux niveaux mentionné ici fait référence au modèle de jalonnement avec deux types de participants.

1. Opérateur de nœud : exploitez des nœuds et utilisez leur propre réputation ou un certain montant de leur propre capital comme garantie.
2. Agent Délégant : Les agents promettent un certain montant d’Ethereum, il n’y a pas de montant minimum et il n’y a pas de restrictions supplémentaires sur les autres méthodes de participation autres que la garantie.

Ce double jalonnement émergent est généré par une forte participation à des pools de jalonnement qui fournissent de la liquidité pour les jetons de jalonnement (LST). (Rocket Pool et Lido sont dans ce mode).

Cependant, le double engagement actuel présente deux défauts :

1. Risque de centralisation des opérateurs de nœuds : Le mécanisme de sélection actuel des opérateurs de nœuds dans tous les pools de jalonnement est encore trop centralisé.
2. Fardeau de consensus inutile : chaque époque d’Ethereum L1 doit vérifier environ 800 000 signatures, ce qui représente une charge énorme pour un seul emplacement. De plus, étant donné que les pools de jalonnement de liquidité nécessitent plus de fonds, le réseau lui-même ne profite pas pleinement de cette charge. Par conséquent, si le réseau Ethereum peut parvenir à une décentralisation et une sécurité raisonnables sans exiger que chaque partie prenante signe en fonction de la période, alors la communauté peut adopter une telle solution, réduisant ainsi efficacement le nombre de signatures par période.

Cet article décrira une solution aux deux problèmes ci-dessus, ** en supposant d’abord que la majeure partie du capital est détenue par ceux qui ne veulent pas gérer personnellement les nœuds de jalonnement dans leur forme actuelle, signer les informations sur chaque emplacement, verrouiller le dépôt et réaffectez-le au fur et à mesure que les fonds sont réduits. Dans ce cas, quel rôle ces personnes peuvent-elles jouer pour continuer à apporter une contribution significative à la décentralisation et à la sécurité du réseau ? **

**Comment fonctionne actuellement la double garantie ? **

Actuellement, les deux pools de staking les plus populaires sont Lido et RocketPool. En ce qui concerne Lido, les deux parties participantes sont :

1. Opérateur de nœud : Voté par Lido DAO, ce qui signifie qu’il est effectivement élu par les détenteurs de LDO. Lorsque quelqu’un dépose de l’ETH dans le système de contrat intelligent du Lido, stETH sera créé, l’opérateur de nœud peut le mettre en gage pool (mais comme le certificat de retrait est lié à l’adresse du contrat intelligent, l’opérateur ne peut pas retirer d’argent à volonté)
2. Agent : Lorsque quelqu’un dépose de l’ETH dans le système de contrat intelligent Lido, stETH sera généré et l’opérateur du nœud pourra l’utiliser comme gage (mais comme le bon de retrait est lié à l’adresse du contrat intelligent, l’opérateur ne peut pas retirer d’argent à volonté)

Pour Rocket Pool, ce sont :

1. Opérateur de nœud : N’importe qui peut devenir opérateur de nœud en soumettant 8 ETH et un certain nombre de jetons RPL.
2. Agent : Lorsque quelqu’un dépose de l’ETH dans le système de contrat intelligent Rocket Pool, rETH sera généré et l’opérateur du nœud pourra l’utiliser comme gage (également parce que le bon de retrait est lié à l’adresse du contrat intelligent, le l’opérateur ne peut pas se retirer à volonté).

Rôle d’agent

Dans ces systèmes (ou dans les nouveaux systèmes rendus possibles par de futurs changements potentiels de protocole), une question clé à se poser est la suivante : **Quel est l’intérêt d’avoir un agent du point de vue du protocole ? **

Afin de comprendre l’importance profonde de ce problème, réfléchissons d’abord aux changements de protocole mentionnés dans l’article, qui limiteront la pénalité à 2ETH. Rocket Pool réduira également le montant de la participation des opérateurs de nœuds à 2ETH et la part de marché de Rocket Pool. augmentera à 100 %/(pour les parties prenantes et les détenteurs d’ETH, à mesure que rETH deviendra sans risque, presque tous les détenteurs d’ETH deviendront détenteurs de rETH ou opérateurs de nœuds).

Supposons un retour de 3 % pour les détenteurs de rETH (y compris les récompenses dans le protocole et les frais de priorité + MEV) et un retour de 4 % pour les opérateurs de nœuds. Nous supposons également que l’offre totale d’ETH est de 100 millions.

Les résultats du calcul sont les suivants. Pour éviter les calculs d’intérêts composés, nous calculerons les rendements quotidiennement :

Désormais, en supposant que Rocket Pool n’existe pas, le dépôt minimum par joueur tombe à 2 ETH, la liquidité totale est plafonnée à 6,25 millions d’ETH et le taux de retour de l’opérateur de nœud tombe à 1 %. Calculons à nouveau :

Considérez les deux scénarios du point de vue du coût de l’attaque. Dans le premier cas, l’attaquant ne s’enregistrera pas en tant qu’agent car l’agent n’a essentiellement aucun droit de retirer de l’argent, cela n’a donc aucun sens. Par conséquent, ils mettront en gage tous leurs ETH et deviendront des opérateurs de nœuds. Pour atteindre 1/3 du montant total misé, il leur faudrait miser 2,08 millions d’Ethereum (ce qui, pour être honnête, reste un chiffre assez important). Dans le second cas, l’attaquant n’aurait qu’à miser des fonds pour atteindre le montant total misé. pool de jalonnement Pour 1/3 du montant total, ils doivent encore investir 2,08 millions d’Ethereum.

** Du point de vue de l’économie du jalonnement et du coût de l’attaque, le résultat final des deux cas est exactement le même. ** La part de l’offre totale d’ETH détenue par les opérateurs de nœuds augmente de 0,00256 % chaque jour, et la part de l’offre totale d’ETH détenue par les opérateurs non-nœuds diminue de 0,00017 % chaque jour. Le coût de l’attaque est de 2,08 millions d’ETH. ** Par conséquent, dans ce modèle, l’agent semble être devenu une machine de Rube Goldberg dénuée de sens, et la communauté rationnelle est même encline à supprimer les intermédiaires, à réduire considérablement les récompenses de mise et à limiter le montant total des ETH mis en jeu à 6,25 millions d’individus. **

Bien entendu, cet article ne préconise pas de réduire la récompense de mise de 4 fois et de limiter le montant total de la mise à 6,25 millions. Au contraire, l’objectif de cet article est qu’un attribut clé d’un système de staking qui fonctionne bien est que les agents doivent assumer des responsabilités importantes dans l’ensemble du système**. De plus, cela n’aurait pas d’importance si les agents étaient motivés en grande partie par la pression de la communauté et par l’altruisme pour prendre les bonnes mesures ; après tout, c’est ce qui incite les solutions de jalonnement décentralisées et de haute sécurité qui constituent aujourd’hui une force majeure.

Les responsabilités des agents

Si les agents pouvaient jouer un rôle significatif dans le système de jalonnement, quel pourrait être ce rôle ?

Je pense qu’il y a deux catégories de réponses :

• **Sélection des agents : **Les agents peuvent choisir à quels opérateurs de nœuds confier leurs participations. Le « poids » des opérateurs de nœuds dans le mécanisme de consensus est proportionnel à la participation totale qui leur est confiée. Actuellement, le mécanisme de sélection des agents est encore limité, c’est-à-dire que les détenteurs de rETH ou de stETH peuvent retirer leur ETH et passer à un autre pool, mais la disponibilité réelle de la sélection des agents pourrait être considérablement améliorée.
• Participation au mécanisme de consensus : Les délégués peuvent choisir de jouer un certain rôle dans le mécanisme de consensus. La responsabilité est « plus légère » qu’une souscription complète, et il n’y aura pas de longue période de sortie ni de réduction des risques, mais elle peut toujours jouer un rôle Vérifie et équilibre le rôle des opérateurs de nœuds.

Améliorer la sélection des agents

Il existe trois façons d’augmenter le pouvoir de choix de votre représentant :

1. Outils de vote améliorés dans le pool
2. Augmenter la concurrence entre les pools
3. Corriger les droits de représentation

Actuellement, voter dans le pool n’est pas vraiment pratique : dans Rocket Pool, n’importe qui peut devenir opérateur de nœud, et dans Lido, le vote est décidé par les détenteurs de LDO, et non par les détenteurs d’ETH. Lido a présenté une proposition de double gouvernance LDO + stETH. Ils peuvent activer un mécanisme de protection qui empêche de nouveaux votes et ainsi empêcher l’ajout ou la suppression d’opérateurs de nœuds. Cela donne en quelque sorte la parole aux détenteurs de stETH. Ce pouvoir est néanmoins limité et peut être plus puissant.

La concurrence entre pools existe déjà aujourd’hui, mais elle est relativement faible. Le principal défi est que les jetons de staking des petits pools de staking sont moins liquides, plus difficiles à gagner en confiance et moins pris en charge par les applications.

**Nous pouvons améliorer les deux premiers problèmes en limitant le montant de la pénalité à un montant plus petit, comme 2 ou 4 ETH. ** L’ETH restant peut ensuite être déposé et retiré instantanément en toute sécurité, ce qui permet aux rachats bidirectionnels de rester valables pour les pools de mise plus petits. Nous pouvons améliorer le troisième problème en créant un contrat d’émission totale pour gérer le LST (similaire aux contrats ERC-4337 et ERC-6900 utilisés pour les portefeuilles) afin que nous puissions garantir que tous les jetons mis en jeu émis via ce contrat sont tous en sécurité.

Actuellement, l’accord ne prévoit aucun pouvoir représentatif solide, mais une telle situation semble probable à l’avenir. Cela impliquera une logique similaire à l’idée ci-dessus, mais mise en œuvre au niveau du protocole. Consultez cet article sur les avantages et les inconvénients de la solidification des choses.

Ces idées constituent des améliorations par rapport au statu quo, mais les avantages qu’elles offrent sont limités**. Il y a des problèmes avec la gouvernance du vote symbolique, et en fin de compte, toute forme de sélection de proxy non incitée n’est qu’une forme de vote symbolique ; cela a toujours été mon principal reproche à l’égard de la preuve de participation déléguée. **Il est donc également utile d’envisager des moyens de parvenir à une participation consensuelle plus forte.

Participation consensuelle

Même en mettant de côté les problèmes actuels liés au jalonnement de liquidité, les méthodes actuelles de jalonnement indépendant présentent des limites. En supposant que la finalité à emplacement unique soit utilisée, chaque emplacement peut idéalement gérer environ 100 000 à 1 000 000 de signatures BLS. Même si nous utilisons des SNARK récursifs pour agréger les signatures, chaque signature doit se voir attribuer un champ de bits d’un participant pour la traçabilité. **Si Ethereum devient un réseau à l’échelle mondiale, les champs de bits de stockage entièrement décentralisés ne suffiront pas : 16 Mo dans chaque emplacement ne peuvent prendre en charge qu’environ 64 millions de jalonneurs.

De ce point de vue, il est utile de diviser le jalonnement en niveaux réductibles de complexité plus élevée et en niveaux de complexité inférieure, où chaque créneau sera actif mais ne pourra compter que 10 000 participants. Les couches de complexité inférieure ne sont appelées qu’occasionnellement à participer. Les couches de complexité inférieure pourraient être totalement exemptées de réductions, ou les participants pourraient avoir au hasard la possibilité de déposer dans quelques créneaux horaires et devenir la cible de réductions.

En pratique, cela peut être réalisé en augmentant le plafond de solde du validateur, puis en augmentant le seuil de solde (par exemple, 2048 ETH) pour déterminer quels validateurs existants passent à des niveaux de complexité plus élevés ou plus faibles.

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

1. Pour chaque créneau, 10 000 petits joueurs seront sélectionnés au hasard et pourront signer ce qu’ils pensent être représentatif du créneau. Exécutez la règle de sélection de fork LMD GHOST en utilisant de petits jalonneurs comme entrée. S’il existe un désaccord entre la sélection de fork pilotée par les petits acteurs et la sélection de fork pilotée par les opérateurs de nœuds, le client de l’utilisateur n’acceptera aucun bloc comme confirmation finale et affichera une erreur. Cela oblige la communauté à intervenir pour résoudre la situation.
2. Les agents peuvent envoyer des transactions annonçant au réseau qu’ils sont en ligne et prêts à servir de petits joueurs pour l’heure suivante. Le calcul du message (bloc ou preuve) envoyé par le nœud nécessite à la fois que le nœud et un agent sélectionné au hasard signent les informations de confirmation du nœud**.
3. Les agents peuvent envoyer des transactions annonçant au réseau qu’ils sont en ligne et prêts à servir de petits joueurs pour l’heure suivante. À chaque époque, 10 agents aléatoires sont sélectionnés comme fournisseurs de listes d’inclusion, et 10 000 agents supplémentaires sont sélectionnés comme électeurs. Ceux-ci sont sélectionnés avant les k-slots et reçoivent une fenêtre de k-slot pour publier un message en chaîne confirmant leur présence en ligne. Chaque fournisseur de liste d’inclusion sélectionnée confirmée peut publier une liste d’inclusion à moins que, pour chaque liste d’inclusion, soit une transaction incluse dans cette liste d’inclusion, soit un vote d’un électorat général sélectionné indique que la liste d’inclusion n’est pas disponible, sinon le blocage sera considéré comme invalide. .

Ce que ces petits nœuds de jalonnement ont en commun, c’est qu’ils n’ont pas besoin de participer activement à chaque créneau, ni même n’ont besoin que de nœuds légers pour terminer tout le travail. Par conséquent, le déploiement d’un nœud nécessite uniquement la vérification de la couche de consensus, ce que les opérateurs de nœuds peuvent réaliser via des applications ou des plug-ins de navigateur, qui sont pour la plupart passifs et n’imposent aucune surcharge de calcul, aucune exigence matérielle ou aucun savoir-faire technique. nécessitent une technologie avancée comme ZK-EVM.

Ces « petits acteurs » ont également un objectif commun : empêcher la révision des transactions par la majorité de 51 % des opérateurs de nœuds. **Les premier et deuxième types peuvent également empêcher la majorité des personnes de participer à la restauration finale. La troisième concerne plus directement la censure, mais elle est plus sensible aux choix des opérateurs de nœuds majoritaires.

Ces idées sont écrites du point de vue d’une solution de double jalonnement implémentée dans le protocole, mais elles peuvent également être mises en œuvre en tant que fonctionnalité des pools de jalonnement. Voici quelques idées de mise en œuvre spécifiques :

1. Du point de vue du protocole, chaque vérificateur peut définir deux clés de gage : une clé de gage continue P et une adresse Ethereum liée qui peut être appelée, et générer une clé de gage rapide Q. Le suivi des informations de signature du nœud pour la sélection de fork est représenté par P et les informations signées sont représentées par Q. Si les résultats de stockage PQ sont incohérents, la finalisation d’un bloc ne sera acceptée et le pool de liquidité sera responsable de la sélection aléatoire. représentants.
2. Le protocole peut rester largement inchangé, mais la clé publique du validateur pour cette période sera définie sur P+Q. Notez que pour les réductions, deux messages réductibles peuvent avoir des touches Q différentes, mais ils auront la même touche P ; la conception de la réduction doit gérer ce cas.
3. La clé Q ne peut être utilisée dans le protocole que pour signer et vérifier les listes d’inclusion dans les blocs. Dans ce cas, Q peut être un contrat intelligent plutôt qu’une clé unique, de sorte que le pool de jalonnement peut l’utiliser pour mettre en œuvre une logique de vote plus complexe, en acceptant une liste inclusive d’un fournisseur sélectionné au hasard ou suffisamment. Indique que la liste contenante n’est pas disponible pour les votes .

en conclusion

S’il est mis en œuvre correctement, l’ajustement fin de la conception de la preuve de participation peut résoudre deux problèmes d’un seul coup :

1. Offrir une opportunité à ceux qui n’ont pas les ressources ou la capacité de mener aujourd’hui une preuve de participation indépendante de participer à la preuve de participation, conservant ainsi plus de pouvoir entre leurs mains : y compris (i) le pouvoir de choisir les nœuds à prendre en charge * *et (ii) participer activement au consensus d’une manière plus légère mais toujours significative que l’exploitation complète d’un nœud de preuve de participation. Tous les participants ne choisiront pas l’une ou les deux de ces options, mais tout participant qui choisit l’une ou les deux de ces options connaîtra une amélioration significative par rapport au statu quo.
2. Réduire le nombre de signatures que la couche de consensus Ethereum doit traiter dans chaque emplacement, même dans un régime de finalité à emplacement unique, à un nombre plus petit, environ 10 000. Cela contribuera également à la décentralisation, permettant à chacun d’exécuter plus facilement des nœuds de validation.

Pour ces solutions, les solutions au problème peuvent être trouvées à différents niveaux d’abstraction : autorisations accordées aux utilisateurs dans les protocoles de preuve de participation, sélection de l’utilisateur entre les protocoles de preuve de participation et établissement au sein des protocoles. Ce choix doit être soigneusement réfléchi, et il est souvent préférable de choisir une configuration minimale viable pour minimiser la complexité du protocole et l’ampleur des changements apportés à l’économie du protocole, tout en atteignant les objectifs souhaités.