Un grand merci à Anders Elowsson pour les discussions initiales qui ont incité à cette série de publications et pour ses nombreux commentaires utiles sur le texte. Merci également à Caspar Schwarz-Schilling, Julian Ma, Thomas Thiery, Davide Crapis, Mike Neuder, Drew Van der Werff, Kydo et à de nombreux autres pour les discussions et les commentaires sur le texte. Photo de couverture par @pawel_czerwinski?utm_content=creditCopyText&utm_medium=referral&utm_source=unsplash">Pawel Czerwinski on Unsplash.

Staking, re-staking, liquid staking, liquid re-staking, re-staked liquid staking tokens, node operators and capital providers… Nous avons observé depuis le lancement de Beacon Chain en décembre 2020 une collection de mécanismes et de constructions de plus en plus variée, à partir du mécanisme de staking propre au protocole.

Dans les discussions au sein de notre équipe, nous avons ressenti le besoin d'un langage précis nous permettant d'éliminer les ambiguïtés concernant l'architecture de ces mécanismes. Nous espérons souligner l'existence de points de contrôle et de désalignements d'incitations grâce à l'utilisation de la notation et des bilans, car les nuances comptent beaucoup pour mettre en évidence correctement les opportunités et les risques. L'exercice a été principalement réalisé pour notre propre compréhension, mais en le parcourant, nous avons estimé qu'il offrait un moyen utile d'agrégation d'une collection de faits disparates et de discussions en une approche cohérente et systématique.

Dans ce post et les deux suivants, nous présentons ces constructions ainsi que des études de cas. Nous ne visons pas une revue exhaustive de tout le matériel produit par toutes les brillantes équipes travaillant sur ces mécanismes, et nous prévoyons que notre sémantique soit mise à jour au besoin chaque fois que de nouveaux faits révèlent des lacunes ou des erreurs dans nos modèles.

1. Partie 1: Liquéfaction
2. Partie 2: Re-staking
3. Partie 3: Ensembles de construction avancés pour les 16 ans et plus

La série actuelle de publications ne tire pas non plus de conclusions concernant l'optimalité ou l'utilisation de ces constructions, au-delà de fournir des définitions et un contexte pour leur existence. Les prochaines publications aborderont ces questions et offriront des propriétés de ces mécanismes, telles que leur utilité pour diverses classes de stakers et leur économie dans un contexte plus large.

Allons-y !

Actif

Le « type » le plus élémentaire de notre sémantique est celui d’un actif. Un actif peut être des jetons natifs d’une blockchain décentralisée, comme l’ETH, des jetons enracinés sur une blockchain comme les ERC-20 ou les NFT, ou des actifs construits à partir d’autres actifs, comme le sont les produits dérivés.

Bilans comptables

Dans ce qui suit, nous illustrons nos constructions avec des bilans montrant la création et le transfert d'actifs entre plusieurs parties impliquées. Nous fournissons toujours les bilans dans le même format :

1. La première ligne représente l'état "pré-état", indiquant quels actifs sont actuellement détenus par chaque partie.
2. La dernière ligne représente l'état final, indiquant quels actifs sont détenus par chaque partie après la conclusion de toutes les opérations.
3. Les lignes intermédiaires représentent des opérations, avec une nouvelle ligne indiquant simplement un nouvel ensemble d'opérations, séparé des autres dans le but de l'exposition.

Nous utilisons deux opérations de base de manière répétée, qui méritent d'être détaillées ici :

1. Transfert d'actifs : la partie A transfère simplement quelques actifs à la partie B.

1. Émission de reçu : Nous représentons souvent des situations où la Partie A reçoit une créance de la Partie B, permettant ainsi à la Partie A de récupérer certains actifs de la Partie B. Le reçu devient alors une responsabilité pour la Partie B et un actif pour la Partie A. Dans l'exemple suivant, la Partie A transfère un actif à la Partie B et reçoit une créance de la Partie B.

Nous n'utilisons pas les bilans de manière très orthodoxe, étant plus inspirés du Économie de la monnaie et de la banquecours ainsi que Daniel H. Neilson’sBientôt séparénewsletter (tout en précisant à titre indicatif que nous ne sommes probablement pas aussi rigoureux que l'un ou l'autre). Cependant, nous pensons que cet ensemble minimal d'opérations est suffisant pour fournir l'intuition nécessaire.

Staking de protocole

Staker solo

La première opération de base consiste à placer de l'ETH en jeu dans le protocole Ethereum Proof-of-Stake. Dans le cas le plus simple, un détenteur d'ETH place directement son ETH dans le protocole, recevant un solde « virtuel » de soETH (le « so » signifie opérateur solo). Nous représentons la relation avec les bilans suivants, qui sont lus ligne par ligne à travers les différentes parties :

Le staker solo est responsable des opérations de leur validateur correspondant. Cela signifie que si le staker solo remplit correctement ses obligations de consensus, le protocole Ethereum crédite son solde de soETH avec du soETH nouvellement émis. En revanche, lorsque le staker solo reçoit des pénalités ou est slashé, le protocole débite son solde soETH. Lorsque le staker solo souhaite retirer son solde soETH et obtenir de l'ETH, le retrait est traité 1:1, c'est-à-dire que pour x unités de soETH sur le solde du consensus du validateur, le staker solo reçoit x ETH en retour (dans le cas d'un retrait complet).

Notez que nous ne représentons pas les récompenses de la "couche d'exécution", par exemple, les frais de priorité et les MEV. Ces récompenses s'ajoutent simplement au modèle présenté ci-dessus et constituent un simple transfert d'ETH des parties sur la couche d'exécution au staker solo assurant les fonctions de producteur de blocs.

Utiliser un fournisseur de services de Staking (SSP)

Une relation plus complexe est en jeu lorsqu'un fournisseur de services de jalonnement (SSP) intermédie la relation entre le détenteur qui souhaite miser ("délégué") et le protocole Ethereum. Dans ce cas, le détenteur d'ETH fournit d'abord au SSP de l'ETH native dans le but qu'elle soit misée. Le SSP mise l'ETH et se voit accorder le contrôle sur l'actif "soETH" fonctionnant au niveau de validation. Il confère à un délégué un actif virtuel noETH (le "no" signifie opérateur de nœud), contre lequel son ETH misé est échangeable.

Notre utilisation du mot “remboursable” introduit déjà une certaine incertitude ici. Comme nous l'avons vu ci-dessus, le protocole Ethereum permet au staker solo de retirer son solde soETH contre de l'ETH à parité. Est-ce également vrai pour le staker déléguant son ETH au SSP en échange de noETH ? En général, ce n'est pas le cas. Premièrement, 1 noETH pourrait rembourser moins de 1 soETH, en cas de réduction. Deuxièmement, comme la plupart des SSP fournissent leur service moyennant des frais, 1 noETH rembourse une fraction du soETH crédité sur le compte du SSP en excès de son principal en jeu. Un bilan plus précis séparerait le principal du rendement, par exemple :

Ici, nous « décomposons » l'actif soETH entre le principal pETH et le rendement yETH. pETH est échangé contre au plus 32 ETH, sauf en cas de réduction. yETH échange les récompenses de la couche de consensus et de la couche d'exécution obtenues par le SSP. Le SSP fournit des réclamations correspondantes au délégué, no.pETH et no.yETH. Le délégué peut toujours recevoir son principal en totalité, y compris les réductions, de sorte qu'un taux de change 1:1 existe entre no.pETH et pETH. Cependant, le SSP prélève des frais, de sorte que le taux de change entre no.yETH et yETH est inférieur à 1 (1 no.yETH échange moins de 1 yETH). La décomposition de l'actif peut être utile à certains endroits, mais elle introduit également une complexité supplémentaire qui n'est pas critique pour les sections suivantes, nous continuons donc à utiliser soETH et noETH pour représenter l'ensemble de la réclamation.

Une autre considération est de savoir si le pool SSP regroupe ou non les ETH de ses déposants.

1. Pas de mise en commun : Un SSP ouvre plusieurs pools parallèles, un pour chaque déposant. Supposons que les déposants A et B fournissent leur ETH au SSP, qui ouvre les validateurs A et B, un pour chaque déposant. Supposons ensuite que le validateur A soit sanctionné pour la moitié de son dépôt, tandis que le validateur B ne le soit pas. Dans ce cas, le déposant A peut retirer son ETH mis en jeu au taux de 1:0.5 (1 part de noETH rachète 0.5 parts d'ETH mis en jeu), tandis que le déposant B peut retirer son ETH au taux de 1:1 (modulo frais). Il est donc incorrect de parler d'un seul noETH, car en pratique il existe noETH-A et noETH-B qui représentent des réclamations différentes.
2. Mise en commun : Le protocole Ethereum exige que des unités de 32 ETH soient mises en jeu, ce qui signifie que si les déposants A et B souhaitent miser uniquement 16 ETH chacun, ils ne pourraient pas le faire avec la construction détaillée dans le point précédent. Dans ce cas, ils mettraient en commun leurs ETH sous un SSP, qui socialiserait ensuite leurs récompenses et pertes, induisant le même taux de retrait pour les deux déposants. Il est alors bien formé de parler d'un seul noETH, puisque la valeur de la réclamation est partagée par les deux déposants, proportionnellement au montant qu'ils ont déposé.

Liquefaction

Nos déposants détiennent désormais un actif virtuel que nous avons appelé noETH. Cet actif virtuel est une réclamation qui représente des parts du montant actuel mis en jeu par le SSP sous le protocole Ethereum. Bien que cela semble déjà être une version liquide de la position ETH en jeu, nous tenons à souligner qu'une étape supplémentaire est nécessaire pour y parvenir : la liquéfaction par l'émission d'un jeton représentant la réclamation des actifs noETH. La position noETH est rendue liquide, alias fongible et cessible. Nous écrivons cette opération avec l'opérande L., de sorte que l'actif L.noETH est une abstraction par exemple, de stETH ou de cbETH, ou de tout autre actif connu sous le nom de jeton de validation liquide "LST".

Pour rendre cela apparent, nous décomposons les fonctions du SSP en tant que rassemblement de protocoles de mise en jeu par des délégants, et les opérateurs de nœuds fournissant les services de validation pour le SSP. Nous obtenons ensuite les bilans suivants :

Lorsque le SSP n'est qu'un intermédiaire entre certains opérateurs de nœuds et le délégué, l'étape consistant à obtenir L.noETH à partir de noETH est presque invisible compte tenu de la nature des blockchains, où l'actif comptable noETH, enregistré comme une entrée de grand livre, se révèle être l'actif liquide L.noETH lui-même, programmable et prêt à être composé. En d'autres termes, si nous avons déjà un jeton représentant un certain noETH en tant qu'entrée de blockchain, noETH et L.noETH sont indiscernables. Nous souhaitons néanmoins souligner la différence, car il existe des cas où les délégués n'ont pas accès à une représentation liquide (du point de vue de la blockchain) de leur actif en jeu. Par exemple, par le passé, les déposants ayant misé leur ETH avec Coinbase n'ont pas reçu de la part de Coinbase l'actif liquide cbETH. Dans ce cas, les déposants avaient droit à une réclamation virtuelle représentant une ligne dans les entrées de grand livre interne de la base de données de Coinbase, qui n'étaient pas enregistrées sur une blockchain.

Rôles du SSP

Dans de nombreux cas, le SSP, vu comme un protocole, n'est pas qu'un simple wrapper, un contrat on-chain recevant de l'ETH et imprimant L.noETH en échange. La fonction principale du SSP est d'intermédier la relation entre un mandant (le délégant) et des agents (opérateurs de nœuds). Si le mandant n'a pas confiance que les agents lui fourniront un rendement adéquat tout en protégeant les actifs du mandant, ce dernier ne déléguera pas ses actifs aux opérateurs de nœuds pour les mettre en jeu en son nom. Comment les SSP fournissent-ils de bonnes garanties ?

1. Le premier composant consiste à inciter les opérateurs de nœuds à bien performer. Les opérateurs de nœuds reçoivent plus de récompenses du protocole Ethereum plus ils effectuent bien leurs services de validation. Les incitations sont facilement alignées en permettant aux opérateurs de nœuds de partager les profits qu'ils créent pour leurs délégants, via des frais.
2. Le deuxième composant consiste à dissuader les parties malveillantes de devenir des opérateurs de nœuds. Nous pourrions supposer que dans le pire des cas, ces parties malveillantes sont intrinsèquement motivées à attaquer le protocole Ethereum et à provoquer un événement de slashing important au coût minimum pour eux-mêmes. Deux approches existent ici. Nous pourrions exiger des opérateurs de mettre quelque chose en jeu, de sorte que ces attaques soient aussi coûteuses que possible pour les opérateurs. Nous pourrions également contraindre les opérateurs de nœuds, en les empêchant d'effectuer unilatéralement des actions pouvant entraîner des sanctions.

Des pools comme Lido traitent le deuxième problème en sélectionnant un ensemble d'opérateurs de nœuds, de sorte que les performances soient garanties par le protocole et le DAO de Lido. Leurs opérateurs n'ont pas d'ETH en jeu, mais @mikeneuder/magnitude-et-direction">systèmes externes de mise en œuvre (des plus souples tels que "la réputation en jeu" aux plus durs tels que les retraits déclenchés par la couche d'exécution comme discuté dans le deuxième post) sont destinés à garantir leur bon comportement.

Something-at-stake pour dissuader les opérateurs malveillants

Pendant ce temps, des constructions telles que Rocket Pool encouragent la validation honnête par des opérateurs de nœuds qui ne sont ni vérifiés ni employés par une organisation, contribuant de manière permissionless. L'opérateur de nœud ouvre un Minipool, en contribuant d'abord leur propre mise, soit 8 soit 16 ETH. Le protocole complète ensuite la mise du nœud opérateur avec la mise reçue des délégants. Par conséquent, le rendement de l'opérateur de Minipool sur sa propre mise augmente avec sa performance.

Notez que l'opérateur doit également fournir une certaine quantité de RPL, le jeton de Rocket Pool, proportionnelle à la quantité de mise qu'il a dû emprunter dans le pool d'ETH délégué pour renflouer son propre Minipool. Nous ne montrons pas cela dans les bilans suivants, et nous mettons en évidence certains actifs du même type avec des couleurs différentes, pour illustrer leur provenance (l'ETH vert appartient au délégant, l'ETH violet appartient à l'opérateur).

Plus le collatéral déposé par l'opérateur est faible, plus le risque d'attaque par effet de levier augmente, où l'opérateur a besoin d'une petite quantité de fonds pour contrôler une quantité beaucoup plus grande de parts sur le réseau Ethereum Proof-of-Stake (PoS). Pour Lido, le risque d'attaque par effet de levier est infini si l'on considère uniquement les actifs sur chaîne mis en jeu par les opérateurs, mais évidemment moins que infini si l'on considère leur réputation, leurs contrats et les flux de trésorerie futurs attendus issus d'une validation honnête. Pour les opérateurs de Rocket Pool, par exemple, ceux qui ouvrent des Minipools collatéralisés en 8 ETH, le facteur de levier est de 4x, car 8 ETH leur permet de contrôler 32 ETH de parts sur le protocole Ethereum PoS. Pouvons-nous demander un collatéral plus faible aux opérateurs?

Contrainte des opérateurs de nœuds

Un moyen de réduire davantage les risques de validation malveillante consiste à engager de manière crédible les opérateurs de nœuds à des actions spécifiques, par exemple les engager à ne jamais produire de messages pouvant être utilisés pour les pénaliser. Plus facile à dire qu'à faire !

Ici, les technologies de validateur distribué (DVT) peuvent aider, en garantissant que tous les messages de l'opérateur sont vérifiés et approuvés par un quorum de nœuds avant d'être publiés sur le réseau avec une signature valide. Diva, un protocole de staking, intègre DVT pour encadrer les actions de l'opérateur. L'opérateur doit mettre en jeu un certain montant de divETH (LST de Diva), soit un montant équivalent à 1 ETH pour obtenir une part de clé. Un ensemble de 16 parts de clé forme un quorum de nœuds DVT, ainsi qu'un seul validateur virtuel, comme illustré ci-dessous. Nous omettons le protocole Ethereum, qui délivre simplement la réclamation soETH à la dernière étape et reçoit l'ETH collecté des délégants et des opérateurs (l'ETH vert appartient au délégant, tandis que l'ETH violet et jaune est fourni par les opérateurs). Nous montrons également seulement deux opérateurs au lieu de 16.

Le calcul du facteur de levier pour Diva n'est pas si simple. Contribuer à 1 équivalent en ETH au validateur virtuel ne vous permet pas de "gagner" le contrôle d'un montant d'ETH actuellement en jeu, car les actions conjointes de plus de 2/3 du quorum décident des messages du validateur virtuel. Notez cependant que le protocole permet au propriétaire d'un seul ETH de devenir un opérateur et de recevoir une réclamation noETH, échangeant le rendement obtenu à partir de la validation Ethereum PoS.

Au-delà du facteur de levier, une autre mesure est pertinente ici : le ratio entre le montant des LST en circulation et le montant de l'enjeu de l'opérateur, ou facteur de garantie. Un ratio élevé implique qu'une plus petite quantité de l'enjeu de l'opérateur est garantie pour valider au nom d'une plus grande quantité de l'enjeu du délégataire. Pour Rocket Pool, les Minipools 8 ETH ont un facteur de garantie égal à 3x, car 8 ETH garantissent 24 rETH au total. Pendant ce temps, le facteur de garantie d'un validateur virtuel Diva est de 1x, puisque 16 parts clés (16 ETH) garantissent 16 divETH. Un facteur de garantie élevé « libère de l'espace » pour plus d'enjeu à déléguer. Diva doit alors recruter plus d'enjeu d'opérateur par unité d'enjeu délégué pour offrir ses services. En revanche, permettre aux opérateurs qui garantissent un seul ETH élargit l'ensemble des opérateurs éligibles à ceux ayant un capital plus faible.

Validation en solo de Liquid

De ce qui précède, nous avons appris que les détenteurs d'un LST exigent que les opérateurs qui valident en leur nom fassent du bon travail. Cette garantie est soit fournie par des contrats externes dans le cas des protocoles de type Lido, soit en obligeant l'opérateur à mettre en jeu son propre capital ainsi que celui de leurs délégants. Cette dernière option nécessite un modèle théorique de jeu solide pour garantir que le capital mis en jeu par l'opérateur n'est pas si faible qu'il permette des attaques bon marché et détruise finalement la valeur du LST pour leurs détenteurs.

Nous posons maintenant une question distincte. Le déléguant obtient L.noETH en mettant en commun la mise et en réglant les réclamations via un protocole émettant une représentation liquide du montant délégué, modulo les récompenses, les pénalités et les frais. Un déléguant peut-il obtenir L.soETH? En d'autres termes, un seul validateur solo pourrait-il émettre une position liquide à partir de sa position de validation?

Le problème ici est que les détenteurs de l'actif L.soETH doivent avoir confiance que la valeur de leur réclamation ne sera pas détruite par une action malveillante du staker solo, par exemple, se faire pénaliser. Nous avons déjà vu une approche, via DVTs, pour restreindre les actions de l'opérateur pendant la validation.

Une approche différente du DVT consiste à lier les actions du staker solo de telle sorte que leur propre risque de pénalité soit réduit par la construction matérielle. Liquid solo validation” par Justin Drake utilise SGX pour garantir que la clé de signature du validateur ne signe jamais un message pouvant entraîner une sanction. SGX permet à un logiciel pré-engagé de fonctionner sans altération, bien que des précautions habituelles concernant sa sécurité existent, qui dépassent le cadre de cet article. Le staker solo fournit l'ensemble du capital (32 ETH), mais est capable de créer un LST représentant sa propre validation et de “libérer” son capital du protocole Ethereum, pour être réutilisé, par exemple, comme garantie pour d'autres applications.

Détails ligne par ligne :

1. Le périphérique SGX génère une clé privée, une clé publique et une attestation prouvant l'engagement à un morceau de code empêchant le staker solo d'effectuer des actions pouvant entraîner des sanctions avec sa clé de signature privée.
2. Les clés d'attestation et publiques sont fournies au staker solo.
3. Le valideur solo enregistre ceux-ci avec le contrat LST déployé on-chain, qui est responsable de la création de l'actif de validation solo liquide. Le valideur solo fournit également au contrat de l'ETH, leur mise.
4. L'ETH est transféré du contrat LST au contrat de dépôt, et un actif de mise en jeu soETH est retourné au contrat LST, qui filtre maintenant la sortie du validateur du protocole PoS. Le contrat LST émet l'actif L.soETH, qui est une représentation liquide de l'ETH mis en jeu par le parieur.

L'actif L.soETH est fongible avec ceux émis par d'autres stakers solo utilisant la même procédure. Par construction, le staker solo liquide ne peut que émettre 31 L.soETH sur les 32 ETH mis en jeu. Le 1 ETH supplémentaire est utilisé comme garantie pour rembourser les parties qui liquident sans permission la position lorsque le solde du staker solo passe sous les 32 ETH, et pour tenir compte de la garantie gelée pendant que le validateur est en file d'attente après une sortie. Cela garantit que 1 L.soETH est toujours adossé à 1 ETH.

Quelles sont les utilisations de l'actif L.soETH?

1. Le validateur solo émettant du L.soETH pourrait utiliser cet actif L.soETH comme garantie pour d'autres services. Ces services pourraient considérer que c'est une "bonne garantie", car le seul moyen pour le validateur solo de dégrader sa qualité est de se déconnecter et d'encourir des pénalités (sans être réduit à néant). Cependant, de par sa conception, le validateur solo est exclu dès que son solde en soETH dévie ne serait-ce que d'un centième d'ETH de son solde initial de 32 ETH.
2. Le staker en solo pourrait également vendre l'actif L.soETH à d'autres détenteurs, recevant les recettes. L'actif L.soETH devrait être un actif productif en soi, comme décrit par Justin dans lesETH productif vs non productif” section de son post, où l'actif L.soETH devient une revendication non seulement sur le principal en jeu, mais aussi sur les récompenses gagnées sur le stake, par exemple, les récompenses de consensus et les MEV (il y a des difficultés à internaliser le MEV de manière minimisée par la confiance).
   1. Notez que la vente de l'actif L.soETH ne donne pas à l'investisseur solo un levier supplémentaire pour lancer une attaque sur Ethereum. Le levier est obtenu en mettant en jeu une petite somme de fonds et en contrôlant une plus grande somme dans le protocole PoS. Cependant, le dispositif SGX empêche l'investisseur de commettre des actions pouvant entraîner une sanction.

Conclusion de la liquéfaction

Le tableau suivant résume les 4 études de cas discutées ci-dessus :

La liquéfaction est un moyen pour un staker d'extraire plus de ``jus'' de sa garantie en jeu. Dans le post suivant, nous discuterons du re-Staking en tant qu'alternative connexe pour créer plus d'actifs à partir de sa mise.

Avertissement：

1. Cet article est repris de [miroir], Tous les droits d'auteur appartiennent à l'auteur original [Le prix de l'agence]. Si vous avez des objections à cette réimpression, veuillez contacter le Porte Apprendreéquipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.