Principes de la répartition

Étant donné un actif X, nous désignons par [X] l'actif re-staké, c'est-à-dire un actif qui "boxe" X de sorte qu'une partie ou la totalité de X puisse être capturée par une partie donnée une condition arbitraire.

L'exemple de base introduit par EigenLayer est celui d'un validateur solo réinvestissant son ETH actuel mis en jeu. Pour ce faire, le validateur solo met à jour son adresse de retrait avec l'adresse d'un pod EigenLayerLes EigenPods sont des contrats intelligents qui suivent les services auxquels le staker solo s'est inscrit pour sécuriser avec sa mise. L'EigenPod devient finalement le propriétaire de l'actif soETH, tout en créditant le staker solo d'une représentation re-mise en jeu de son ETH misé.

La possession de l'actif soETH dans notre cadre signifie le "droit de premier refus" sur l'ETH retiré du protocole Ethereum, c'est-à-dire qu'il détient une revendication plus importante que tout autre participant de la chaîne. Lorsque le staker solo décide de retirer son ETH du protocole Ethereum, l'ETH retiré est filtré à travers le contrat EigenPod, vérifiant si le staker solo est autorisé à racheter la totalité du montant de soETH ou non (nous verrons plus tard quand cela pourrait ne pas être le cas). Avec nos bilans :

Nous rendons chaque étape explicite dans ce qui suit :

1. Le stakeur solo dépose son ETH sur le protocole Ethereum, recevant une position soETH virtuelle du protocole Ethereum.
2. Le staker solo dépose virtuellement son soETH à EigenLayer en définissant son adresse de retrait à l'adresse du pod EigenLayer. En échange, le staker solo reçoit une position virtuelle [soETH] d'EigenLayer, ce qui lui permet éventuellement d'exécuter les opérations dans le sens inverse.

Déséquilibres de solde

Nous pouvons déjà faire quelques observations intéressantes à partir des bilans ci-dessus. La première est que le protocole Ethereum n'a aucune conception de [soETH], puisque cela n'apparaît pas sur son propre bilan. Ce problème a été discuté dans “Démantèlement du PBS : Vers des engagements des proposants renforcés par protocole (PEPC)Un validateur sanctionné par EigenLayer conserve néanmoins un solde complet de mise en jeu dans le bilan du protocole Ethereum, ce qui peut entraîner un risque moral et des déséquilibres de récompense (un validateur réellement à moitié mis en jeu continue de percevoir l'intégralité des récompenses du protocole Ethereum). Nous détaillons le scénario de sanction dans les bilans suivants, en donnant des chiffres arbitraires pour illustrer le problème :

Ce problème est résolu dès que EigenLayer rapporte fidèlement le slashing d'EigenLayer d'un validateur au protocole Ethereum, rééquilibrant les feuilles. C'est possible avec EIP-7002: Exécution des sorties déclenchables de la couche d'exécution, même à un niveau grossier, puisque le déclencheur binaire se contente de sortir du validateur, mais le middleware EigenLayer ou l'EigenPod est toujours nécessaire pour déclencher le signal vers le protocole PoS d'Ethereum. Cette action est dans l'intérêt d'EigenLayer car une comptabilité appropriée profite aux services sécurisés via EigenLayer et augmente finalement la confiance des opérateurs et des re-stakers dans l'exécution fidèle de la plateforme.

Un déclencheur plus fin pourrait forcer un retrait partiel de l'équilibre du validateur du consensus Ethereum, sans sortir complètement le validateur. Cela est souhaitable pour les services EigenLayer qui souhaitent pénaliser les validateurs partiellement, sans déclencher de sortie. Notez que ni l'EIP-7002 ni les retraits partiels déclenchés par la couche d'exécution ne sont disponibles sur le réseau principal d'Ethereum aujourd'hui. Notez aussi que @mikeneuderMaxEB (suppression du plafond de 32 ETH sur le principal d'un seul validateur en jeu) se combinerait parfaitement avec des retraits partiels, éliminant ainsi un incitatif supplémentaire pour les validateurs de rester désagrégés (en faisant fonctionner de nombreux validateurs de 32 ETH au lieu d'un seul validateur de 2048 ETH, par exemple).

En l'absence de cette fonctionnalité de retrait partiel, il y a une incitation supplémentaire à maintenir la comptabilité d'EigenLayer séparée de la comptabilité du protocole Ethereum, ce qui, comme nous l'avons noté ci-dessus, peut introduire des désalignements. Dans ce qui suit, nous représentons un validateur sanctionné pour 8 ETH par EigenLayer, ce qui ne le retire pas de ses fonctions de consensus (le solde d'éjection est de 16 ETH) :

AVS affirme

On peut se demander où vont les 8 [soETH] dans l'exemple précédent. Cette décision est laissée à la discrétion des Services de Validation Active (SVA) alimentés par EigenLayer. Un SVA est un service exigeant une certaine mise en jeu en guise de garantie. La présence d'une mise en jeu permet au service de s'engager de manière crédible envers une certaine performance, car la mise en jeu peut être réduite si le service n'est pas correctement exécuté.

Le validateur de re-staking s'inscrit dans les AVSs via leur EigenPod. Lorsqu'ils le font, l'EigenPod crée de nouvelles réclamations qui sont offertes aux AVSs, représentant le collatéral actuellement détenu sous l'EigenPod. Nous devons maintenant faire la distinction entre deux types de réclamations :

1. AVS affirme : Nous utilisons [soETH] pour désigner ces revendications, en mettant en avant qu'elles sont dérivées de la valeur de l'actif entre crochets [ ].
2. Réclamation du re-staker : Nous utiliserons désormais [soETH]* pour mettre en avant la qualité particulière de cette réclamation, qui est rachetée par le re-staker uniquement après que toutes les réclamations AVS sont réglées. En d'autres termes, la réclamation du re-staker a la plus faible ancienneté, rachetant les actifs restants une fois que toutes les autres réclamations AVS sont réglées.

1. Le staker solo re-stake.
   1. Ainsi, l'ETH est placé sous le contrôle de l'EigenPod.
   2. [soETH]* est reçu par le re-staker solo, une demande pour leurs actifs re-stakés.
2. Le staker solo crée une nouvelle réclamation, [soETH] à partir de son EigenPod.
3. La réclamation est donnée en garantie à l'AVS.
   1. [soETH] is transferred to the AVS.
   2. Le re-staker reçoit le reçu avs.[soETH].

Une fois que le validateur agit contrairement aux objectifs de l'AVS (par exemple, déclencher une condition de réduction de l'AVS), l'AVS peut décider, par exemple, de brûler la réclamation du validateur pour ses ETH en jeu ou de conserver la mise en tant que revenu pour l'AVS. Nous illustrons cette deuxième option ci-dessous, en supposant que le protocole Ethereum crédite simplement 8 ETH à l'EigenPod comme retrait partiel suite au rapport de réduction de l'EigenLayer, après quoi EigenLayer le transfère à l'AVS:

1. Le AVS réduit le collatéral du re-staker solo.
   1. La garantie de l'AVS se compose de 32 [soETH]. Une fois la réduction signalée, l'AVS retire 8 [soETH] de la garantie et signale la réduction à l'EigenPod, qui diminue également ses passifs de 8 [soETH].
   2. Le AVS ne crédite plus 32 avs.[soETH] au re-staker solo, réduisant ainsi cette revendication de 8 avs.[soETH].
   3. Ayant été réduit par l'AVS, l'EigenPod diminue la revendication du re-staker solo de 8 [soETH]*.
2. L'EigenPod signale les réductions au protocole Ethereum, déclenchant le retrait de 8 ETH.
   1. La revendication des actifs en jeu dans le protocole Ethereum descend à 24 soETH.
   2. Un retrait partiel de 8 ETH est traité, et l'EigenPod reçoit les 8 ETH précédemment verrouillés dans le protocole Ethereum.
3. L'EigenPod transfère la pénalité de 8 ETH à l'AVS, qui est libre d'en disposer à sa guise.

Ré-staking

La fonctionnalité (et le risque) offerte par EigenLayer est la capacité pour un re-staker de continuer à entrer de nouveaux engagements qu'ils promettent d'honorer. En d'autres termes, après que la mise a été remise en jeu, la mise remise en jeu peut être remise en jeu à nouveau, et encore, et encore... Plus concrètement, le re-staker prend de nouveaux engagements en s'inscrivant à plus de services via leur EigenPod.

Pour parvenir à une pleine généralité, et en prévision des sections suivantes où des actifs autres que le soETH sont restakés, nous désignons par $X$ l'actif qui est restaké par le restakeur. Voyons comment le restaking multiple fonctionne :

Nous désignons par [X]p l'actif X restaké p fois. Pour l'instant, il s'agit d'une définition simple, mais nous allons suggérer certaines des propriétés de ces actifs après avoir détaillé les étapes de ces bilans. L'EigenPod est capable d'imprimer ces passifs à volonté, forgeant de nouveaux actifs chaque fois que le restakeur s'engage dans de nouveaux AVSs.

1. Le re-staker place l'actif X sous le contrôle de l'EigenPod. Cet acte est un engagement de la part du re-staker selon lequel s'ils ne parviennent pas à fournir les services pour lesquels ils se sont inscrits, une partie ou la totalité de l'actif X peut leur être retirée. La réclamation [X]* est reçue pour représenter cet engagement.
2. Nous détaillons ici le re-staker s'engageant à sécuriser la chaîne Y.
   1. Le re-staker obtient un premier actif re-staké [X]¹ en entrant dans la chaîne de sécurisation AVS Y.
   2. Le re-staker met en jeu [X]¹ sous chaîne Y, recevant ainsiY.[X]¹ (une réclamation pour leur mise + récompenses - pénalités). La chaîne Y doit "comprendre" qu'un actif re-staké sécurise actuellement son protocole, c'est-à-dire qu'elle doit être convaincue qu'il y a quelque chose en jeu pour quelqu'un.
3. Nous détaillons ici le re-staker s'engageant à sécuriser la chaîne Z.
   1. Le re-staker obtient un actif re-staked [X]² en entrant dans la chaîne de sécurisation AVS "Securing chain Z".
   2. Le re-staker mise [X]² sous la chaîne Z, recevant soZ.[X]² (une réclamation pour leur mise + récompenses - pénalités). La chaîne Z doit "comprendre" qu'un actif re-misé sécurise actuellement son protocole, c'est-à-dire qu'elle doit être convaincue qu'il y a quelque chose en jeu pour quelqu'un.

Sur la base des bilans ci-dessus, nous abordons maintenant quelques questions. Nous observons que la chaîne Y reçoit [X]¹, tandis que la chaîne Z reçoit [X]². Ces actifs sont-ils du même type, et pouvons-nous simplement dire qu'ils reçoivent tous les deux des actifs de type [X]?

La réponse serait non s'il y avait une hiérarchie des revendications AVS. Imaginez un scénario où le re-staker commet des infractions pouvant être sanctionnées sur les deux chaînes en même temps, et où les deux chaînes souhaitent réduire l'intégralité de la garantie. Nous pouvons alors envisager deux cas :

1. Cas 1 : Les AVSs, ici les mécanismes de consensus des chaînes Y et Z, brûlent simplement les jetons qui sont coupés, ce que font la plupart des protocoles PoS. Lorsque les jetons sont brûlés, la hiérarchie des demandes n'a pas vraiment d'importance : si les deux chaînes Y et Z voulaient couper à nouveau le re-staker pour 32 ETH, tout ce qu'ils accomplissent est de brûler le même collatéral deux fois.
   1. Note : Anders appelle cela du "spree-staking", re-staker plusieurs fois sans hiérarchie de réclamation 😊
2. Cas 2: Les AVS souhaitent recevoir les jetons qui sont en jeu, par exemple pour compenser une partie lésée. Un exemple ici est MEV-Boost+, l'opérateur AVS est le proposeur de bloc, qui s'engage à ne pas manipuler les contenus de blocs reçus en clair, et s'ils le font, ils s'engagent à compenser le constructeur et le relais pour le désordre. Dans ce cas, supposons que plusieurs AVS rachètent leurs revendications en même temps suite à des écarts parallèles par le même re-staker, et qu'il n'y a pas assez en jeu pour couvrir toutes les revendications. Alors la question de l'ancienneté des revendications ou de la distribution des paiements devient pertinente.

Dégroupage des SVA

Dans la section précédente, nous avons présenté les AVS, qui sont des services auxquels le validateur de restaking s'engage à fournir. L'engagement est sécurisé via EigenLayer, qui prend possession de l'enjeu du re-staker valideur et règle les réclamations faites par les AVS.

Mais qu'est-ce qu'un AVS exactement? Tout comme nous avons séparé ci-dessus les protocoles LST et les opérateurs LST, il est logique ici de discuter de ces deux rôles fonctionnels séparément et de leur attribuer des actifs et des revendications différents.

En bref, l'AVS exige 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 distinguons ensuite deux façons dont les re-stakers 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. Les re-stakeurs en tant que fournisseurs de capitaux pour un opérateur AVS : Dans ce cas, un opérateur AVS accepte les actifs (re-)stakés pour effectuer sa fonction d'opérateur au nom des délégants fournissant le capital. Le re-stakeur délègue ensuite ses actifs restakés à l'opérateur AVS, qui effectue une certaine fonction au nom du re-stakeur.

Dans les sections ci-dessus, nous avons identifié le re-staker de validation à la fois en tant que fournisseur de capital (leur propre mise est re-stakée) et en tant qu'opérateur AVS (on attend d'eux qu'ils fournissent un certain service). Cependant, nous pouvons envisager une construction différente, où le re-staker de validation n'opère pas eux-mêmes l'AVS, déléguant plutôt cette fonction à un opérateur. Cela pourrait permettre aux stakers solos de rivaliser en rendement avec les Fournisseurs de Services de Staking Intégrés (FSSI)/opérateurs. L'exemple suivant présente une situation où un seul opérateur AVS valide sur certaines chaînes Y et Z, au nom d'un re-staker. Nous faisons l'hypothèse que toutes les revendications AVS sont du même type [X] (pas de hiérarchie de revendications).

1. Le re-staker place l'actif X sous le contrôle de l'EigenPod. Cet acte est un engagement de la part du re-staker, indiquant que s'ils ne parviennent pas à fournir les services pour lesquels ils se sont inscrits, une partie ou la totalité de l'actif X peut leur être retirée. La réclamation [X]* est reçue pour représenter cet engagement.
2. Nous détaillons ici le re-staker s'engageant à sécuriser la chaîne Y, déléguant les fonctions de validation à l'opérateur AVS.
   1. Le re-staker obtient un actif re-staké [X] en entrant dans la chaîne de sécurisation AVS "Chaîne Y".
   2. Le re-staker donne l'actif re-staké [X] à un opérateur AVS, obtenant le “reçu” noY.[X].
   3. L'opérateur AVS mise [X] sous la chaîne Y, recevant ainsi soY.[X] (une réclamation pour leur mise + récompenses - pénalités). La chaîne Y doit « comprendre » qu'un actif restaké sécurise actuellement son protocole, c'est-à-dire, elle doit être convaincue qu'il y a quelque chose en jeu pour quelqu'un.
3. Nous détaillons ici le re-staker s'engageant à sécuriser la chaîne Z, déléguant les tâches de validation à l'opérateur AVS.
   1. Le re-staker obtient un actif re-staked [X] en entrant dans la chaîne de sécurisation AVS Y.
   2. Le re-staker donne l'actif re-staké [X] à un opérateur AVS, obtenant le “reçu” noZ.[X].
   3. L'opérateur AVS met en jeu [X] sous la chaîne Z, recevant ainsi soZ.[X] (une réclamation pour leur mise + récompenses - pénalités). La chaîne Z doit "comprendre" qu'un actif restaké sécurise actuellement son protocole, c'est-à-dire, elle doit être convaincue qu'il y a quelque chose en jeu pour quelqu'un.

Dans ce paradigme, nous retrouvons des constructions familières. Aucun actif n'est reçu par le re-staker, laissant déjà entrevoir la possibilité de liquider de telles positions. Nous discuterons de ces constructions avancées dans le prochain article, mais avant de le faire, mentionnons la recherche en cours sur le "PBS for AVS" comme une approche pour réduire la centralisation de l'opérateur.

Sous le Cadre de Délégation Optimiste (CDO)proposé par Drew Van der Werff (voir aussiLa récente conférence sur la cryptéconomie de 0xKydo à Columbia) Un re-staker peut externaliser l'exploitation des AVS auxquels il s'inscrit sur un marché ouvert de "co-processeurs". Les co-processeurs peuvent être identifiés par le rôle de "constructeur" du PBS, une entité spécialisée capable d'exécuter des opérations potentiellement intensives, inaccessibles aux entités non sophistiquées ou limitées en calcul, telles que les stakers individuels. Les co-processeurs soumettent des offres aux re-stakers, dans un mécanisme d'enchères de passation de marchés, permettant au re-staker de déterminer l'opérateur le plus rentable. Pour garantir davantage les performances, les co-processeurs sont des participants sous caution, s'exposant à la perte de leur caution s'ils soumettent une pièce de travail prouvablement invalide au cours de leurs opérations.

Avertissement：

1. Cet article est repris de [ miroir], Tous les droits d'auteur appartiennent à l'auteur original [le prix de l'agence]. Si des objections sont faites à cette réimpression, veuillez contacter le Portail Apprendrel'équipe et ils s'en occuperont rapidement.
2. Avis 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 interdite.