*Transférer le titre original : Sémantique du Staking 3 : Constructions Avancées

Un grand merci à Anders Elowsson pour les discussions initiales qui ont incité à ces séries de publications et pour ses nombreux commentaires utiles sur le texte. Merci également aux nombreux évaluateurs que j'ai trop dérangés avec cela, et qui ont fourni des commentaires sur les publications précédentes ou sur des parties de celle-ci. Photo par @william_priess?utm_content=creditCopyText&utm_medium=referral&utm_source=unsplash">William Priess on Unsplash.

Nous avons maintenant disposé les pièces qui composent notre jeu actuel de Lego d'actifs. Il est temps de les assembler et de voir ce que nous pouvons obtenir !

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

L.[noETH]: Re-staking SSP natif ("LRTs")

La première construction considère un SSP restakant le stake actuellement sous son contrôle. Dans ce cas, les opérateurs de noeuds du SSP définissent leurs adresses de retrait vers un EigenPod, ce qui les lie aux engagements pris avec AVS. Cela conduit à la création d'un actif, L.[noETH], représentant une créance sur un collatéral de protocole Ethereum restaké. Dans ce qui suit, nous décrivons la création de cet actif, que nous pourrions d'abord appeler L.avs.[noETH] pour souligner que l'actif incarne également une créance sur les revenus reçus de certains AVS. Cependant, nous pouvons raccourcir la notation simplement en L.[noETH] lorsque l'AVS (ou l'ensemble d'AVS) contracté(s) par les opérateurs est clair.

Dans le cas décrit ci-dessus, il y a une transformation transparente de la L.noETH détenue par le staker en L.[noETH], en supposant que le SSP ne garde pas secrètes les recettes reçues de ses activités de re-staking pour lui-même. Étant donné que tout est écrit on-chain, il serait très facile de détecter si un SSP a re-staké l'ETH sous sa garde tout en conservant le rendement reçu d'AVS pour lui-même, tant que le SSP révèle de manière transparente quels validateurs il exploite. On peut imaginer un scénario où le SSP conclut un accord hors chaîne avec certains AVS, auquel cas la séquence décrite ci-dessus ressemble davantage à :

Comme on peut le voir sur les bilans, [noETH] (misenjeu du nœud restaké) soutient essentiellement maintenant L.noETH (misenjeu du nœud liquide). D'un point de vue distributionnel, c'est un problème que le capital mis en jeu par les stakers dans le SSP génère des rendements alors que les stakers eux-mêmes ne sont pas rémunérés pour cela, mais au moins L.noETH est entièrement soutenu par [noETH] dans le cas idéal. C'est beaucoup plus problématique lorsque [noETH] soutient entièrement L.noETH, par exemple, si le SSP a commis quelque chose de slashable selon un AVS auquel ils ont souscrit, auquel cas la valeur de [noETH] ne correspond plus à la valeur (attendue par les stakers) de L.noETH.

[L.noETH]: "LST re-stakés"

Depuis sa création, EigenLayer a permis à un détenteur de LST de déposer ses LST et de les mettre en jeu sous un pod EigenLayer (notez que nous utilisons LST pour désigner L.noETH, dans le but de tirer parti de l'intuition préexistante). Bien que cela semble équivalent à la construction détaillée ci-dessus, les subtilités sont révélées par la vue du bilan :

La notation indique clairement qu'il y a une différence entre le LST "re-staked" que nous obtenons ici, [L.noETH], et la position de restaking native liquide SSP L.[noETH]. Mais quelle est exactement cette différence? Le moyen le plus facile de le comprendre, à notre avis, est de déballer comment le service AVS est fourni et qui est finalement responsable de la fourniture du service.

Commençons par [L.noETH]. Un jeton représentant une réclamation sur certains ETH mis en jeu est une fois de plus mis en jeu ("re-misé en jeu", entre guillemets car tandis que les ETH sous-jacents à LST sont en effet remis en jeu, le LST lui-même est mis en jeu pour la première fois). Le fait de mettre en jeu le LST chez EigenLayer n'oblige pas le SSP émettant le LST à fournir des services pour AVS choisis par le détenteur de LST. En effet, voyez ci-dessus que le bilan du SSP est pratiquement inchangé, car il ignore que ses jetons sont mis en jeu sous EigenLayer. Alors, à qui le mis en jeu de LST concerne-t-il?

Nous avons discuté de ce qui suit dans notre deuxième publication :

En bref, l'AVS demande une garantie pour offrir un service, par exemple, un AVS affirme de manière crédible qu'une attaque contre l'AVS entraînera la perte d'une fraction de la garantie actuellement détenue par l'AVS. L'AVS est donc considéré ici comme un protocole engageant des opérateurs pour un service. Nous dissocions ensuite deux façons dont les re-stakeurs peuvent interagir avec l'AVS :

1. Les re-stakers en tant qu'opérateurs AVS : L'AVS incarne un protocole qui recherche des opérateurs pour fonctionner, et les opérateurs de nœuds qui re-stakent leur soETH deviennent eux-mêmes des opérateurs pour le protocole AVS.
2. Re-stakers en tant que fournisseurs de capital pour un opérateur AVS : Dans ce cas, un opérateur AVS accepte les actifs (re-)stakés pour accomplir leur fonction d'opérateur au nom des délégants fournissant le capital. Le re-staker délègue ensuite ses actifs re-stakés à l'opérateur AVS, qui accomplit une fonction au nom du re-staker.

Les "re-stakers" de LST sont probablement de simples fournisseurs de capitaux. Une partie de la raison de détenir le LST est d'accéder au rendement de Staking sans effectuer le travail coûteux de validation pour le service Ethereum Proof-of-Stake. Un détenteur de LST qui mise son LST sur certains AVS n'est pas nécessairement censé exécuter des opérations potentiellement complexes et être lui-même l'opérateur de l'AVS.

Représentons les relations dans les bilans suivants, en omettant le protocole Ethereum et le SSP faute de place. Après avoir reçu le LST du déposant, EigenLayer fournit au déposant sa réclamation [L.noETH]. Le LST est ensuite transféré d'EigenLayer à l'opérateur AVS, qui le dépose dans cet exemple sous la chaîne Y.

1. Le "re-staker" de LST place son LST dans son EigenPod.
2. LST "re-staker" re-stakes, recevant l'actif [L.noETH]. L'actif re-misé est délégué à l'opérateur AVS, pour agir au nom du "re-staker" LST.
3. L'opérateur AVS place l'actif restaké [L.noETH] sous la chaîne Y. L'opérateur AVS reçoit la réclamation pour les actifs verrouillés et reçus lors de la validation de la chaîne Y, c'est-à-dire, soY.[L.noETH].
4. L'opérateur AVS retourne une réclamation à cet actif restitué, noY.[L.noETH] au "re-staker" LST.

OK, ce nom soY. est un peu long. Par soY, nous entendons que l'actif en jeu sous Secured Chain Y est dans une relation de "solo-staking" avec Chain Y, c'est-à-dire que l'opérateur AVS mettant [L.noETH] en jeu sous Chain Y agit comme un opérateur solo du point de vue de Chain Y. Ce que nous observons alors, c'est que l'actif détenu par le détenteur de LST "re-staking", noY.[L.noETH], est une créance sur soY.[L.noETH], qui peut augmenter de valeur à mesure que Secured Chain Y récompense les services de validation de l'opérateur AVS. L'opérateur AVS transmet ensuite ce rendement (moins les frais pour couvrir ses coûts d'exploitation) aux détenteurs de noY.[L.noETH].

Remarquez que l'actif soY a changé d'emplacement entre cette série de bilans et la section précédente. Alors que le SSP assumait le rôle de validateur pour Secured Chain Y, devenant lui-même l'opérateur AVS, un nouvel opérateur AVS est désormais responsable des services de validation sous la configuration "re-staked" LST.

Du point de vue des flux de trésorerie, dans un environnement concurrentiel avec des frais marginaux, le staker ne devrait voir aucune différence entre le staking de son LST avec une partie de l’AVS prenant en charge les services de validation, et la détention d’un LST basé sur des garanties remises en jeu par le SSP. Pourtant, la propriété de l’actif soY dénote une centralisation accrue du rôle SSP dans le second cas, qui assume désormais des fonctions d’opérateur de nœud pour deux domaines. La présence de deux entités logiquement distinctes dans le cas du « re-staking » du LST (le SSP fournissant le LST, et l’AVS effectuant les services de validation) peut être une plus grande force pour la décentralisation (voir le prochain billet d’Anders sur le sujet).

[ETH]: "ETH" réinvesti

Il s'agit peut-être d'un cas plus simple dérivé de la construction d'un LST « re-staked » comme détaillé dans la section précédente. Au lieu de « re-staker » un LST, un détenteur d'ETH pourrait simplement placer son ETH dans un EigenPod, et l'utiliser comme garantie pour une variété de services, y compris la sécurisation de domaines extérieurs. Dans ce cas :

1. L'ETH "re-staker" place son ETH dans son EigenPod, recevant l'actif [ETH]*.
2. Le "re-staker" ETH re-stake, recevant l'actif [ETH]. L'actif re-staké est délégué à l'opérateur AVS, pour agir au nom du "re-staker" ETH.
3. L'opérateur AVS place l'actif re-staké [ETH] sous la chaîne Y. L'opérateur AVS reçoit la réclamation pour les actifs bloqués et reçus lors de la validation de la chaîne Y, c'est-à-dire soY.[ETH].
4. L'opérateur AVS renvoie une réclamation à cet actif restaké, noY. [ETH] à l'ETH « re-staker ».

Supposons qu'un actif restaké unique [ETH] soit émis à partir de l'EigenPod, c'est-à-dire que l'ETH est utilisé pour sécuriser uniquement un seul AVS. Supposons que cet AVS soit le protocole Ethereum lui-même. Alors nous observons que la situation décrite ici et celle décrite dans Protocole de Stakingsont isomorphes. En effet, si la chaîne Y était le protocole Ethereum PoS, nous décririons simplement ici l'acte de s'engager à sécuriser la chaîne Ethereum avec ses actifs ETH.

L.[soETH]? Liquid solo re-staking

Ce cas semble bien formé selon notre sémantique, mais pose des problèmes similaires au cas de participation liquide solo de L.soETH. Dans cette construction, un validateur solo restake son soETH avec quelques AVS. Les AVS tentent ensuite de créer une position fongible à partir du service de validation soutenu par le collatéral restaké du validateur solo. Cette position fongible peut être proposée de nouveau au validateur solo, de sorte que, de manière identique au cas où le validateur solo ne souhaite pas que sa mise soit "verrouillée" dans un pool sans représentation liquide, sa position [soETH] peut être utilisée comme collatéral ou vendue ailleurs sous la forme de L.[soETH].

Pourtant, sans garanties sur le comportement du staker solo, le risque moral entrera en jeu une fois de plus, où le staker solo ne supporte plus pleinement le risque de ses actions. En Validation en solo Liquid, nous avons discuté de deux cas d'utilisation pour une représentation liquide de la position du staker solo :

1. Le staker solo pourrait réutiliser le L.soETH pour garantir des applications DeFi.
2. Le staker solo pourrait vendre l'actif L.soETH.

Dans l'un ou l'autre cas, il est important que les détenteurs de l'actif L.soETH croient qu'ils détiennent un actif de valeur. La valeur est garantie par des opérateurs de nœuds de confiance ou des opérateurs de nœuds incitatifs dans les cas respectifs de Lido et Rocket Pool, par exemple, et en s'engageant à utiliser un appareil SGX empêchant le staker solo d'effectuer des actions pouvant être sanctionnées dans le cas de validation solo liquide. Pour obtenir la même garantie pour les actifs L.[soETH], un staker solo pourrait s'engager à utiliser un SGX qui empêche le validateur d'effectuer des actions pouvant être sanctionnées également sur l'AVS pour lequel il s'est inscrit. Le contrat LST qui a émis l'actif L.soETH pourrait également incarner le rôle de l'EigenPod, enregistrant les engagements pris par le staker avec l'AVS.

Dans ce qui suit, le staker solo se lie à un appareil SGX qui doit être impliqué chaque fois que le staker solo souhaite produire un message signé pour ses devoirs de validation sur la chaîne Y.

1. Le dispositif 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 punissables avec sa clé de signature privée.
2. Les clés d'attestation et publiques sont fournies au staker solo.
3. Le staker solo enregistre ceux-ci avec le contrat LST déployé on-chain, qui est responsable de la frappe de l'actif liquide de validation solo. Le staker solo fournit également au contrat de l'ETH, sa mise.
4. L'ETH est transféré du contrat LST au contrat de dépôt, et un actif de mise en jeu appelé soETH est retourné au contrat LST, qui filtre maintenant la sortie du validateur du protocole PoS.
5. Le contrat LST crée un nouvel actif restaké [soETH] à partir de l'ETH mis en jeu qu'il possède, s'engageant à une chaîne de sécurisation AVS Y. Le contrat LST reçoit ensuite la revendication soY.[soETH] de la chaîne Y.
6. Le contrat LST génère l'actif L.soETH, qui est une représentation liquide de l'ETH mis en jeu par le validateur.

L.[L.noETH]: Panier liquide de AVS

Ici, un agrégateur recevant des LSTs (L.noETH) de divers détenteurs crée une position fongible avec tous ces actifs une fois qu'ils sont "re-stakés" dans divers AVS. Ce cas est assez similaire à celui décrit dans la section précédente sur les actifs [L.noETH], et va simplement plus loin en rendant à nouveau disponibles les LSTs mis en commun et "re-stakés" sous forme de jeton. Il s'agit également d'un mouvement similaire à celui décrit dans le passage entre noETH et L.noETH, détaillé dans Liquefaction.

En désignant cette construction avec des bilans, cela ressemble en effet aux LST "Re-staked", avec le rôle supplémentaire de l'agrégateur LST intermédiant la relation entre EigenLayer et le "re-staker" LST.

1. Le détenteur de LST donne son LST à un agrégateur, qui le verrouille dans son EigenPod.
2. L'agrégateur émet un actif reposé à partir de la LST, [L.noETH], via leur EigenPod. L'actif reposé est donné à la chaîne Y, où un opérateur AVS exécute des fonctions de validation au nom de l'agrégateur. L'opérateur AVS reçoit l'actif de mise en jeu de la chaîne Y, soY.[L.noETH], et émet un reçu pour l'agrégateur LST, noY.[L.noETH].
3. L'agrégateur émet une position liquide L.noY.[L.noETH] au détenteur de LST, ce qui signifie que cette position est une représentation liquide de l'agrégateur sécurisant Y et transmettant le rendement au détenteur de LST (moins les frais et les pénalités potentielles).

Les choses se compliquent lorsque l'agrégateur LST décide d'opter pour un nouveau AVS, sécurisant la chaîne Z. Nous écrivons ensuite L.[L.noETH] pour indiquer que l'agrégateur a liquidé une position composée d'un ensemble d'actifs de re-staking, de sorte que L.[L.noETH] = L.noY.[L.noETH] dans le cas spécial où l'agrégateur n'a liquidé que l'actif restaké sécurisant la chaîne Y.

1. Le détenteur de LST donne son LST à un agrégateur, qui le verrouille dans son EigenPod.
2. L'agrégateur émet un actif restaké à partir du LST, [L.noETH], via leur EigenPod. L'actif restaké est donné à la chaîne Y, où un opérateur AVS exécute des tâches de validation au nom de l'agrégateur. L'opérateur AVS reçoit l'actif de mise en jeu de la chaîne Y, soY.[L.noETH].
3. L'agrégateur émet un actif restaké à partir du LST, [L.noETH], via leur EigenPod. L'actif restaké est donné à la chaîne Z, où un opérateur AVS exécute des tâches de validation au nom de l'agrégateur. L'opérateur AVS reçoit l'actif de mise en jeu de la chaîne Z, soZ.[L.noETH].
4. L'agrégateur reçoit des demandes de l'opérateur pour les actifs en jeu sur les chaînes Y et Z, noY et noZ. [L.noETH]. Sur la base de ces actifs, l'agrégateur émet une position liquide L. [L.noETH] au détenteur de LST, indiquant que cette position est une représentation liquide des engagements de l'agrégateur envers divers AVS, transférant le rendement total au détenteur de LST (moins les frais et les pénalités éventuelles).

Ces paniers de constructions AVS peuvent être rentables pour les re-stakers, car le risque de gérer un portefeuille d'engagements dynamiques à plusieurs AVS est abstrait pour le re-staker. La diversification du portefeuille peut également permettre une réduction du risque systémique, tant que la gestion du portefeuille est transparente.

Conclusion

Il semble alors qu'au-delà d'un certain point, les opérations deviennent isomorphes les unes aux autres, il n'est donc pas nécessaire de continuer à empiler les Legos d'actifs. Le point important est de rester clair sur la partie qui détient finalement le contrôle des actifs soutenant divers services, y compris les mécanismes de consensus. Nous espérons que le déballage des relations parfois complexes entre toutes les parties impliquées concentre notre attention sur les bons points.

Disclaimer：

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, copier, distribuer ou plagier les articles traduits est interdit.