Ceci est la suite de la discussion initiale sur la double gouvernance 18. Le fil de discussion en lien contient un contexte important, nous vous invitons donc à le lire si vous avez le temps.

Depuis que la dernière version du mécanisme a été proposée dans ce post 5, les contributeurs au protocole travaillant sur la DG ont effectué plusieurs itérations pour intégrer les commentaires reçus et rendre le mécanisme plus simple, moins fragile et plus efficace.

Avant de vous présenter la version actualisée, permettez-moi d'exposer le problème que nous essayons de résoudre et de retracer brièvement la chaîne de raisonnement qui nous a conduits à la solution proposée.

Le problème

Actuellement, le code du protocole Lido et ses paramètres sont contrôlés par la DAO Lido via le vote de jetons LDO. Le protocole prélève une commission de 5 % sur les récompenses de staking et la dirige vers la trésorerie de la DAO (5 % supplémentaires étant distribués aux opérateurs de nœuds participant au protocole).

Bien que les détenteurs de LDO soient généralement motivés pour maintenir le bien-être du protocole, puisque cela se reflète dans le prix du jeton LDO, cela ne signifie pas nécessairement que les détenteurs de LDO représentent efficacement les utilisateurs du protocole. Imaginez par exemple que les détenteurs de LDO décident collectivement d'augmenter les frais de protocole : si cette décision peut avoir un effet positif sur le bien-être immédiat des détenteurs de LDO, elle va clairement à l'encontre des intérêts d'au moins une partie des utilisateurs du protocole.

Ce problème peut être généralisé en tant que problème principal-agent (PAP) entre le DAO (l'agent) et les utilisateurs du protocole (le principal). Le problème est dû au fait que les détenteurs de LDO n'ont pas exactement les mêmes incitations que les utilisateurs.

De plus, comme le souligne Vitalik dans son essai Moving beyond coin voting 9, le PAP est exacerbé par le fait que l'intérêt économique dans les revenus du protocole peut être dissocié du pouvoir de gouvernance : il est possible de fausser les incitations des détenteurs de jetons DAO en les corrompant ou en empruntant le jeton de vote DAO sur le marché libre pour essayer d'obtenir suffisamment de pouvoir de vote afin d'imposer un changement qui va à l'encontre des intérêts de la DAO et des utilisateurs du protocole.

La présence du PAP n'est pas très importante, mais on peut faire valoir que, si les utilisateurs se rendent compte que l'agent actuel ne les représente pas suffisamment bien, ils peuvent toujours quitter le protocole et choisir un autre agent mieux aligné sur leurs intérêts ou même décider de supprimer complètement l'agent par le biais d'un solo-staking.

Il s'agit d'un mécanisme très important, généralement connu sous le nom de vote par correspondance. En théorie, il devrait protéger les utilisateurs des effets négatifs d'un désalignement des incitations entre eux et la DAO ou d'une attaque contre la DAO. Toutefois, dans la pratique et dans le cas spécifique de l'Ethereum liquid staking, l'efficacité du vote au pied est limitée en raison d'un certain nombre de facteurs en jeu.

Le premier facteur est la spécificité du fonctionnement du PoS d'Ethereum. Pour retirer l'ETH d'un validateur, il faut attendre que le validateur soit complètement sorti, et toutes les sorties de validateurs Ethereum sont traitées par une file d'attente unique avec un débit limité. Cela signifie que le temps nécessaire pour quitter le protocole dépend de facteurs externes hors protocole et peut varier de plusieurs ordres de grandeur. Ceci implique que l'imposition d'un timelock statique sur les décisions de la DAO ne peut pas garantir qu'un utilisateur ait suffisamment de temps pour quitter le protocole avant que la DAO n'applique un changement qui n'est pas dans l'intérêt de l'utilisateur.

Le deuxième facteur est qu'une grande partie des utilisateurs choisissent le liquid staking parce qu'ils souhaitent redéployer le capital mis en jeu vers d'autres formes d'activités économiques, ce qui explique que les jetons de liquid staking (LST) soient largement utilisés dans le DeFi, y compris dans les protocoles qui nécessitent un délai supplémentaire pour se retirer (par exemple, le protocole de l'échange d'informations sur les fonds d'investissement). les marchés de prêts). Cela ajoute une dépendance externe supplémentaire qui peut empêcher les utilisateurs de quitter le protocole dans un délai prédéfini.

Le troisième facteur découle de l'asymétrie d'information entre la majorité passive et la minorité active instruite des utilisateurs : l'évaluation correcte de tous les risques associés à une décision de gouvernance particulière, y compris les risques extrêmes, nécessite des connaissances que la plupart des utilisateurs ne possèdent pas. La communication des effets négatifs potentiels d'une décision de la DAO via la couche sociale prend plus de temps, ce qui réduit la probabilité que la majorité passive quitte le protocole avant que la décision ne devienne exécutable.

La Lido DAO a établi un certain nombre de protocoles de gouvernance pour réduire l'asymétrie d'information (par exemple, le cadre GOOSE, le groupe de sous-gouvernance des opérateurs de nœuds, le cadre LIP, l'engagement pour le nombre minimum d'audits de tout changement de code du réseau principal), mais ils sont tous des accords de couche sociale entre les détenteurs actuels de LDO et ne peuvent donc pas protéger contre une attaque externe sur la DAO.

Vers la solution

La solution ultime au problème est la minimisation de la gouvernance et, à terme, l'ossification du code et des paramètres du protocole. Il n'y a pas de risque de gouvernance si rien n'est gouverné.

Les contributeurs au protocole considèrent qu'il est nécessaire de réduire progressivement le champ d'application de la gouvernance dans les années à venir. Cependant, jusqu'à ce que la spécification Ethereum s'ossifie, l'évolutivité du code ne peut être réduite que jusqu'à un certain point (par ex. voir EIP-7002 5, EIP-7251 6). En outre, tout code immuable doit faire l'objet d'une vérification formelle au niveau du bytecode afin d'exclure la possibilité qu'un bogue du compilateur produise une vulnérabilité non corrigible.

Il y a aussi la couche de fongibilité du protocole qui sert de moteur d'évaluation du risque et de la récompense et distribue l'ETH entre différents sous-ensembles de validateurs de manière à équilibrer le rendement et les risques de l'ensemble de validateurs qui en résulte. Les risques comprennent les risques de fuite que l'ensemble de validateurs crée pour le réseau Ethereum, par exemple la censurabilité et les risques de coupure corrélés. Des recherches sont en cours (voir le rapport 6 pour la dernière itération) pour déterminer si ces risques peuvent être estimés par le protocole à l'aide d'un gadget oracle sans confiance apportant les informations requises sur la chaîne, mais il s'agit d'un travail de longue haleine et on ne sait pas encore très bien comment le résultat souhaité peut être obtenu dans la pratique. Jusqu'à ce que le protocole soit doté d'un tel mécanisme sans confiance, il doit y avoir une certaine gouvernance au niveau de la couche de fongibilité.

Un autre domaine de recherche potentiel consiste à trouver des moyens d'introduire un consentement explicite pour les nouvelles versions de codes et de jeux de paramètres pour les détenteurs de stETH et les intégrations. Il n'est pas encore certain que cela puisse se faire sans briser la fongibilité des LST et la fragmentation de la liquidité qui en résulte, ce qui, étant donné que la liquidité est l'un des principaux facteurs qui poussent les utilisateurs vers les LST, détruirait la compétitivité du protocole par rapport à d'autres fournisseurs de liquidités décentralisés et centralisés. Il s'agit néanmoins d'une piste de recherche intéressante.

Maintenant que nous avons établi que le protocole devra s'accommoder d'une certaine forme de gouvernance, au moins à moyen terme, voyons comment nous pouvons minimiser <a href="https://notes.ethereum.org/@mikeneuder/magnitude-et-direction"> la risques que cette gouvernance crée 1.

Double gouvernance

Comme nous l'avons souligné dans la première section, le problème général peut être décomposé en deux parties : 1) la présence de PAP et 2) l'efficacité limitée du vote au pied. L'idéal serait donc d'introduire un mécanisme qui améliore à la fois l'alignement entre la DAO et les utilisateurs du protocole et l'efficacité du vote à pied.

C'est là que nous arrivons à la conception de la double gouvernance proposée. Il vise à apporter les améliorations suivantes :

1. Donner aux stakers un moyen de signaler de manière crédible leur désaccord avec la DAO et l'engagement de quitter le protocole si la DAO ne coopère pas à la résolution du conflit d'incitations.
2. Fournir un dispositif de négociation entre les stakers et la DAO.
3. Introduire un délai dynamique étendu sur les décisions de la DAO qui peut être déclenché par une minorité active de stakers et prolongé au fur et à mesure que d'autres stakers participent.
4. Améliorer l'efficacité du vote au pied en permettant aux stakers de quitter le protocole sans être soumis à de nouvelles décisions de la DAO.

Vous trouverez dans cette note un aperçu de la conception du mécanisme proposé et quelques idées pour la recherche future sur la minimisation du risque de gouvernance : <a href="https://hackmd.io/@skozin/r17mlW2la"" > https://hackmd.io/@skozin/r17mlW2la 37.

Il convient de noter que les stakers ne sont pas la seule catégorie d'utilisateurs du protocole ; il existe également des opérateurs de nœuds. Une direction potentielle de recherche future consiste à chercher des moyens d'améliorer également l'efficacité du vote au pied par les opérateurs de nœuds, par exemple. permettre à un sous-ensemble de stakers et d'opérateurs de nœuds de coordonner un protocole et un fork DAO en redirigeant les identifiants de retrait des validateurs vers un nouveau contrat (non pris en charge actuellement par la couche de consensus).

Une autre direction de recherche future est l'exploration de la gouvernance sans jeton et hybride 2.

Prochaines étapes

À partir de là, plusieurs étapes doivent être franchies avant que la conception ne soit finalisée, ce qui aboutira à une proposition d'amélioration du Lido plus formelle qui sera soumise au vote du DAO et au document de décision sur l'architecture (ADR) qui lui est associé :

1. Évaluer la robustesse du mécanisme proposé par le biais d'un scénario et d'une modélisation des attaques.
2. Évaluer la praticité du mécanisme par le prototypage du code.
3. Recueillir les réactions de la communauté.

Ce fil a pour but d'accomplir le point 3 pendant que les contributeurs au protocole travaillent sur les points 1 et 2 (les deux étant actuellement en cours), donc tout retour d'information est très apprécié !

Il est important de souligner que, bien que la double gouvernance soit (à mon avis) une étape importante dans la réduction des risques de gouvernance du protocole, elle n'est en aucun cas l'étape finale. Certaines des idées d'améliorations supplémentaires peuvent être trouvées dans le document sur la conception du mécanisme dont le lien figure ci-dessus, et j'invite toutes les personnes intéressées à discuter de ces améliorations et de toute autre amélioration potentielle en postant un sujet sur ce forum.

Clause de non-responsabilité：

1. Cet article est repris de[lido]. Tous les droits d'auteur appartiennent à l'auteur original[skozin]. Si vous avez des objections à cette réimpression, veuillez contacter l'équipe de Gate Learn, qui s'en chargera rapidement.
2. Clause de non-responsabilité : Les points de vue et les opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent pas un conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe de Gate Learn. Sauf mention contraire, il est interdit de copier, distribuer ou plagier les articles traduits.