Le restaking dans EigenLayer : AVS, opérateurs et second niveau de slashing
Le restaking est une extension volontaire des règles du staking : un ETH déjà staké (ou un LST) est en plus délégué dans EigenLayer afin qu’un même collatéral assure la sécurité de plusieurs services.
L’erreur principale consiste à réduire le restaking à un simple “supplément de rendement”. Dans le modèle EigenLayer, il ne s’ajoute pas seulement une source de paiements, mais aussi un niveau distinct de sanctions : les conditions de slashing ne sont pas définies uniquement par Ethereum, mais également par des services externes.
EigenLayer relie le stake Ethereum à des services externes via des AVS : le service rémunère les opérateurs pour l’exécution des règles et obtient un mécanisme de sanctions (slashing) comme garantie cryptoéconomique.
En une phrase : le restaking dans EigenLayer consiste à connecter un ETH déjà staké (ou un LST) à des services externes (AVS) via des opérateurs, afin que le collatéral devienne slashable selon leurs règles.
Mécanique minimale : le restaker délègue son collatéral à un opérateur → l’opérateur sert l’AVS choisi → l’AVS verse une rémunération → en cas de violation des règles, l’AVS initie un slashing selon une politique définie à l’avance.
Les sections suivantes détaillent les rôles de restaker / operator / AVS, l’architecture de connexion du collatéral (native ETH et LST), les sources de paiement (versements des AVS) et les sources de risque (politique de slashing des AVS, choix de l’opérateur, défaillances corrélées).
Le restaking : transforme l’ETH en collatéral “réutilisable” : un même stake garantit la sécurité d’Ethereum et des AVS choisis, tandis que le coût des paiements réside dans les règles de slashing des AVS et dans la dépendance aux opérateurs.
Contenu actualisé → accent renforcé sur l’architecture d’EigenLayer (AVS/opérateurs) et sur le second niveau de slashing.
- Chevauchements clarifiés → la question “qu’est-ce que le restaking ?” a été déplacée vers l’angle “marché de la responsabilité / prix de l’erreur”.
- Scénarios RSFi précisés → la décote des LRT est liée au risque AVS et aux événements corrélés.
Comment fonctionne le protocole EigenLayer dans l’écosystème Ethereum
EigenLayer est un protocole de smart contracts sur Ethereum qui permet de rendre un ETH déjà staké (ou un LST) slashable (soumis à pénalité) selon les règles de services externes (AVS) via une délégation à des opérateurs.
Flux de base : le collatéral est connecté à EigenLayer → délégué à un opérateur → l’opérateur sert les AVS choisis → les AVS rémunèrent le bon fonctionnement → en cas de violation des règles des AVS, une pénalité (slashing) est appliquée au collatéral alloué.
Les rôles dans EigenLayer : restaker / operator / AVS
| Rôle | Ce qui est fourni | Ce qui est exécuté | Où le risque apparaît |
|---|---|---|---|
| Restaker | Collatéral (ETH/LST) délégué à un opérateur | Choix de l’opérateur et de l’ensemble d’AVS à soutenir | Slashing selon les règles des AVS + dépendance au comportement de l’opérateur |
| Operator | Infrastructure et déploiement de la stack AVS | Signatures/proofs/disponibilité selon les exigences des AVS | Pénalités en cas de violation des règles des AVS ; erreur opérationnelle |
| AVS | Règles de validation et politique de slashing/récompenses | Vérification de la correction des actions des opérateurs (selon sa propre logique) | Erreurs de conception des règles, bugs dans les contrats/la vérification |
Connexion du collatéral : native ETH et LST
- Native ETH : le validateur lie les retraits à une adresse EigenPod, afin que le stake soit pris en compte par EigenLayer et puisse relever des règles des AVS.
- LST : les LST sont déposés dans les stratégies d’EigenLayer puis délégués à un opérateur sans lancer de nœud propre.
Le slashing dans le restaking : règles des AVS et collatéral alloué
- Les conditions sont définies par l’AVS : les violations sont formulées au niveau du service (par exemple, signatures incorrectes, non-exécution des tâches, non-respect des exigences de disponibilité).
- La pénalité est liée au collatéral alloué : la sanction s’applique à la partie du stake délégué qui participe au service de l’AVS concerné selon ses règles.
Filtre pratique de risque : le profil de risque est déterminé par l’ensemble des AVS servis par l’opérateur, leur politique de slashing et la capacité de l’opérateur à servir cet ensemble sans perte d’uptime ni de qualité d’exécution.
EigenLayer relie le stake délégué et les services externes via des opérateurs : l’AVS rémunère l’exécution des règles, et leur violation peut conduire au slashing du collatéral alloué.
Exemples d’utilisation d’EigenLayer et du restaking en pratique
Les AVS (Actively Validated Services) utilisent le restaking comme mécanisme de responsabilité : l’opérateur est rémunéré pour exécuter les règles du service, et leur violation peut entraîner le slashing du collatéral alloué sur Ethereum.
Modèle AVS : le service définit une obligation → définit une vérification (comment la violation est constatée) → définit une pénalité (volume et conditions) → l’opérateur répond avec le collatéral délégué.
Data Availability (EigenDA et analogues)
Les services DA répondent à une question essentielle de l’écosystème rollup : les données nécessaires à la vérification de l’état et à la reconstitution de l’historique sont-elles disponibles ?
- Ce que l’opérateur s’engage à faire : conserver des fragments de données (chunks — parties d’un jeu de données) et les restituer selon les règles du protocole dans des fenêtres temporelles définies.
- Ce qui constitue une violation : indisponibilité des données, refus de les fournir, confirmation de disponibilité sans restitution effective.
- Pourquoi le restaking est utile ici : la disponibilité des données devient une obligation sanctionnable, et non une simple promesse du fournisseur.
- Ce que le marché obtient : une couche DA évoluant séparément de la L1, réduisant la charge sur Ethereum sans stockage “de confiance”.
Le restaking transforme la DA en
Oracles et services de données
Dans les oracles, la valeur du restaking réside dans le “prix de l’erreur” : des données incorrectes déclenchent des liquidations et modifient les paramètres de risque, d’où la nécessité d’une sanction économique en cas de falsification du flux.
- Ce que l’opérateur s’engage à faire : publier des données correctes (par exemple un prix) selon un format, une fréquence et des sources convenus.
- Ce qui constitue une violation : falsification volontaire, manipulation coordonnée, retard systématique des mises à jour (stale data — données “obsolètes”).
- Pourquoi le restaking est utile ici : une attaque contre les données doit coûter plus cher que le gain potentiel, sinon les incitations se brisent.
- Comment la responsabilité est généralement “intégrée” : l’AVS définit les règles de participation et de pénalité ; le poids/les quotas peuvent tenir compte du stake délégué, mais le risque est déterminé par les conditions de slashing du service concerné.
Le restaking augmente le
Restaked rollups et composants L2
Une partie de l’infrastructure L2 peut être externalisée vers des AVS et liée à une responsabilité sanctionnable des opérateurs, au lieu de construire sa propre “économie de validateurs” (un ensemble séparé de participants et d’incitations de sécurité).
- Ce que l’opérateur s’engage à faire : exécuter les règles du composant L2 (ordre des actions, publications, vérifications convenues) dans les conditions définies.
- Ce qui constitue une violation : affirmations contradictoires sur l’état, censure, refus de service, violation des garanties protocolaires du service.
- Pourquoi le restaking est utile ici : la responsabilité sanctionnable réduit la dépendance à la “bonne foi” d’un ensemble limité d’opérateurs.
- Ce que le marché obtient : un lancement rapide des services et moins d’incitations à créer un token séparé uniquement pour la sécurité.
Un composant L2 peut obtenir une
Calculs et résultats vérifiables
Dans les AVS de calcul, la tâche est formulée comme un contrat sur le résultat : le paiement est versé pour une exécution conforme au protocole, tandis que le sabotage devient un risque sanctionnable.
- Ce que l’opérateur s’engage à faire : exécuter un calcul/une procédure et fournir une preuve du résultat selon les règles du service.
- Ce qui constitue une violation : falsification du résultat, non-exécution, non-conformité au format de vérification/de preuve.
- Pourquoi le restaking est utile ici : “l’honnêteté de l’exécution” est déplacée de la confiance envers le fournisseur vers une responsabilité économique.
- Ce que le marché obtient : une infrastructure de calcul avec un prix de l’erreur maîtrisable et des obligations sanctionnables pour les participants.
Le restaking transforme la qualité d’exécution en
Catégories d’AVS : ponts et messagers cross-chain (bridged vs native stablecoins), modules ZK (vérification de preuves à divulgation nulle), réseaux DePIN (infrastructure physique décentralisée) et services de coordination, où il est important de fixer la responsabilité économique des opérateurs en cas de violation des règles.
Critère d’application : le restaking est utilisé lorsqu’un prix élevé de l’erreur est nécessaire : l’AVS rémunère l’exécution des règles ; la violation des règles rend le stake alloué des opérateurs sanctionnable.
Le restaking comme marché de la responsabilité : security budget et prix de l’erreur
Dans EigenLayer, les paiements n’apparaissent pas “pour le simple fait de staker”, mais pour l’acceptation d’obligations supplémentaires : l’AVS achète une exécution correcte sanctionnable, tandis que le risque est déterminé par la politique de slashing et la complexité opérationnelle.
Cadre court : le security budget correspond à “combien coûte une attaque ou un sabotage”. Le restaking augmente le budget de sécurité non par des promesses, mais par le lien “règle vérifiable → déclencheur formel de violation → pénalité sur le collatéral alloué”.
-
L’AVS achète de la responsabilité, pas de la “liquidité”.
- Sens de l’échange : le service paie pour l’exécution des exigences (signatures, disponibilité, résultats corrects), et la violation se transforme en dommage mesurable via le slashing.
- Ce qui est fixé : le “prix de l’erreur” est défini par les règles de l’AVS, et non par la réputation du fournisseur.
-
Le restaking corrige la faiblesse initiale des nouveaux protocoles.
- Problème : un ensemble propre de validateurs est faible au démarrage, de sorte que le coût d’une attaque reste souvent bas.
- Effet pratique : le service accède à un pool plus important de stake délégué sans émettre un token distinct “pour la sécurité”.
-
Le revenu est le paiement du risque et de la complexité d’exécution.
- Source des paiements : versements des AVS aux opérateurs (en tenant compte des commissions et des exigences).
- Prix des paiements : la probabilité de slashing augmente avec le nombre d’AVS, la complexité de la stack et les corrélations d’infrastructure.
Règle du marché : le restaking est un marché de sécurité partagée où le “coût” est défini par la politique de slashing, les caps de dommages et la qualité de l’exécution opérationnelle, et non par des pourcentages de vitrine.
EigenLayer monétise la sécurité comme un service : l’AVS paie pour les règles et les garanties sanctionnables, tandis que le stake reçoit un flux de paiements supplémentaire accompagné d’un niveau additionnel de slashing.
Les avantages du restaking EigenLayer pour les validateurs et les détenteurs d’ETH
Le restaking ajoute au staking ETH un second niveau de responsabilité : les paiements proviennent des AVS, tandis que le risque est défini par leurs règles de slashing et par la qualité des opérateurs.
Logique des avantages : des paiements supplémentaires n’apparaissent que là où le stake accepte une responsabilité supplémentaire. Dans le restaking, cette responsabilité est définie par la politique de slashing des AVS concernés et par la qualité d’exécution des opérateurs.
Avantages du restaking : source des paiements et prix du risque
-
Paiements au-dessus du staking de base
Source : rémunération des AVS pour le service des règles du protocole (via l’opérateur et sa commission).
Prix : slashing selon les règles des AVS et dépendance à la fiabilité opérationnelle de l’opérateur.
-
Diversification des flux de paiement
Source : ensemble d’AVS chez l’opérateur (modèles de paiement différents et exigences différentes).
Prix : croisement des risques : une défaillance d’opérateur peut affecter plusieurs AVS simultanément.
-
Participation sans nœud propre via LST/LRT
Source : constructions liquides (LST) et surcouches (LRT), combinant les récompenses de base et les paiements des AVS dans un même actif.
Prix : niveaux de risque supplémentaires : smart contracts, depeg/décote, liquidité de sortie, conditions du protocole LRT.
-
Flexibilité dans la répartition de la responsabilité
Source : la délégation à un opérateur et le choix des AVS déterminent quelle partie du stake relève de quelles règles.
Prix : la limitation du risque ne fonctionne qu’à travers des limites formelles et l’architecture des stratégies, et non par l’intention.
-
Demande pour le stake ETH comme “service de sécurité”
Source : les AVS achètent la sécurité sur le marché du stake Ethereum au lieu d’émettre un token pour les validateurs.
Prix : la sécurité devient un marché concurrentiel : les conditions de paiement, les ensembles d’AVS et les exigences des opérateurs évoluent.
Exemple (sans chiffres) : la récompense de base du staking Ethereum reste en place, et un paiement supplémentaire peut s’ajouter depuis un ou plusieurs AVS. Le résultat dépend de deux paramètres : (1) le montant des paiements AVS ; (2) le profil de risque — politique de slashing et probabilité d’erreurs opérationnelles chez l’opérateur choisi.
Le restaking augmente l’efficacité du capital (un collatéral soutient plusieurs circuits de paiements et de responsabilité) grâce aux paiements des AVS, mais élargit le niveau de slashing et fait de la gestion du risque une partie obligatoire du modèle.
Les risques du restaking : slashing, erreurs corrélées et pression sur Ethereum
Les paiements des AVS rémunèrent une responsabilité supplémentaire : aux règles de slashing d’Ethereum s’ajoutent les pénalités des services externes, tandis que les défaillances corrélées augmentent la probabilité de scénarios en cascade.
Deux niveaux de pénalité : Ethereum définit le slashing pour le consensus L1, tandis que le restaking ajoute un slashing selon les règles des AVS. Le risque est défini par la politique de slashing des AVS et par la fiabilité opérationnelle de l’opérateur.
Slashing selon les règles des AVS
L’opérateur accepte des obligations formelles envers chaque AVS, et la violation des règles entraîne une pénalité sur le collatéral alloué.
- Déclencheurs : downtime, signatures incorrectes, traitement erroné des données, actions contradictoires, incompatibilité après mise à jour du client.
- Amplitude des dommages : définie par la politique de l’AVS (conditions, limites, niveaux de violation) et par le volume de stake effectivement mobilisé pour cet AVS.
- Limitateurs : limites d’exposition par AVS, répartition entre opérateurs, refus des AVS avec une politique de slashing floue ou une complexité opérationnelle élevée.
Observation : plus un opérateur sert d’AVS, plus il existe de points de défaillance indépendants, et plus la probabilité d’une pénalité augmente en cas d’incident ordinaire.
Événements corrélés et pénalités de masse
Une cause commune peut toucher simultanément de nombreux opérateurs, y compris des participants honnêtes.
- Déclencheurs : bug dans la logique AVS, configuration contestable, règles ambiguës, mise à jour synchronisée erronée chez de nombreux opérateurs.
- Amplitude des dommages : des pertes simultanées provoquent des pertes collectives et renforcent la sortie du stake hors du service ou du protocole.
- Limitateurs : caps sur la pénalité maximale, limites de part du stake dans un même AVS, vérification indépendante, mécanismes d’assurance ou de compensation (s’ils existent dans le design du marché).
Observation : un bug commun ou une configuration contestable d’un AVS peut déclencher des pertes de masse en un seul instant.
Affaiblissement de la discipline du stake en cas de forte perte hors L1
Une forte pénalité au niveau d’un AVS peut réduire brutalement la “mise” économique du validateur, affaiblissant le rôle disciplinaire du collatéral.
- Déclencheurs : slashing profond dans un AVS ou série de pénalités dans plusieurs services en cas de problème opérationnel commun.
- Amplitude des dommages : la réduction du collatéral diminue le “coût de l’erreur” pour le participant et accroît son inclination à prendre des décisions risquées.
- Limitateurs : localisation des cas contestés dans la couche de restaking, limitation de la profondeur des pénalités, procédures de résolution des conflits au niveau du service, et non au niveau du consensus Ethereum.
Observation : il est critique de maintenir les cas de slashing contestés et subjectifs à l’intérieur de la couche de restaking.
Concentration autour d’un AVS majeur et pression systémique
L’augmentation de la part des validateurs dépendant d’un seul AVS accroît la probabilité qu’un conflit local devienne systémique.
- Déclencheurs : pénalité contestée, défaillance critique ou mise à jour conflictuelle dans un AVS dominant.
- Amplitude des dommages : une part importante des opérateurs et du stake délégué est touchée, ce qui complique une résolution “silencieuse” du conflit.
- Limitateurs : diversification par AVS, limitations de concentration, procédures de résolution des conflits au niveau du service ou de la couche de restaking, et non au niveau d’Ethereum.
Observation : une forte concentration autour d’un AVS rend plus difficile l’isolation des conflits sans effet systémique.
Le restaking ajoute des risques absents du staking ETH de base : AVS-slashing, défaillances corrélées et situations conflictuelles autour des règles. La réduction de l’exposition repose généralement sur des limites de part du stake, une répartition entre opérateurs et une révision régulière de l’ensemble des AVS et de leur politique de slashing. Une pénalité peut annuler entièrement les profits accumulés.
Condition de robustesse : le restaking renforce les risques du staking ETH via l’AVS-slashing et les événements d’infrastructure corrélés. Sans limites d’exposition et sans compréhension de la politique de slashing, le modèle devient plus vite une source de pertes qu’un flux de paiements stable.
Restaking, LST, délégation et LRT : frontières des termes et points de risque
Le restaking ajoute au stake un second niveau de règles — le slashing selon la politique des AVS. Le LST répond au besoin de liquidité du stake. La délégation détermine l’exécutant. Le LRT agrège des stratégies de restaking dans un seul token et transfère le risque AVS dans le prix.
Frontière des termes : LST = représentation tokenisée du stake ; délégation = choix de l’opérateur/validateur ; restaking = connexion du stake à des AVS avec politique de slashing distincte ; LRT = surcouche agrégeant des stratégies de restaking dans un seul token.
| Instrument | Ce qui est fixé | D’où viennent les paiements | Ce qui devient un risque |
|---|---|---|---|
| Délégation | Qui exécute les règles du réseau | Récompenses du consensus L1 | Défaillances opérationnelles de l’exécutant dans les règles de la L1 |
| LST | Part du stake via un token liquide | Récompenses de staking + mécanique du protocole LST | Risques de smart contracts, décote/depeg, liquidité de sortie |
| Restaking | Le collatéral devient slashable selon les règles des AVS | Paiement des AVS (via les opérateurs) | AVS-slashing, défaillances corrélées, dépendance à l’ensemble des AVS de l’opérateur |
| LRT | Ensemble de stratégies (LST + restaking) dans un seul token | Récompenses de staking + paiements des AVS | Héritage de l’AVS-slashing, risques de stratégie/de contrats, décote comme prix du risque AVS |
Construction pratique : la chaîne “staking → LST → restaking → LRT” ajoute des niveaux : d’abord la liquidité (LST), puis la responsabilité AVS (restaking), puis l’agrégation des stratégies (LRT). Chaque niveau supplémentaire ajoute ses propres règles et ses propres points de défaillance.
Répartition des rôles : la délégation choisit l’exécutant, le LST apporte la liquidité, le restaking ajoute un second niveau de slashing selon les règles des AVS, et le LRT transfère le profil de risque AVS dans le prix du token.
Le restaking dans la DeFi : RSFi, LRT et transfert du risque AVS dans le prix du collatéral
Le restaking crée la base de la RSFi (restaking finance) : produits LRT, stratégies de rendement et schémas d’assurance contre le slashing, mais sa caractéristique clé reste le transfert du risque AVS et des corrélations d’opérateurs dans le prix des LRT et la qualité du collatéral.
Canal clé de transmission du risque : dans la RSFi, l’état du restaking se manifeste par le prix du LRT. La décote du LRT par rapport à l’ETH reflète non seulement la liquidité de sortie, mais aussi la réévaluation de la probabilité d’AVS-slashing et d’événements d’infrastructure corrélés ; dans le lending, cela se traduit le plus souvent par une hausse du LTV effectif et par le déclenchement de liquidations.
-
Le LRT tokenise un “portefeuille d’obligations”.
- Mécanique : les récompenses de staking de base sont complétées par les paiements des AVS, et la stratégie est tokenisée sous forme de LRT.
- Composition du risque : AVS-slashing, risque opérateur, défaillances corrélées parmi l’ensemble des AVS, risque contractuel et risque stratégique de l’emballage.
-
Le LRT comme collatéral renforce l’interconnexion des scénarios systémiques.
- Scénario : le LRT est utilisé dans le lending, les pools ou les dérivés et reste lié au risque de restaking.
- Conséquence : un même stake économique participe simultanément aux circuits d’Ethereum, des AVS et des positions DeFi.
-
La décote du LRT accélère les liquidations via la qualité du collatéral.
- Déclencheurs : anticipation de slashing, hausse de l’incertitude opérationnelle chez les opérateurs, concentration autour d’un AVS majeur, mises à jour contestées ou incidents dans un AVS.
- Transmission vers la DeFi : la décote dégrade le collatéral, augmente le LTV effectif et accélère les liquidations dans les protocoles liés.
-
L’assurance contre le slashing devient une couche de design distincte.
- Mécanique : une partie des paiements AVS est dirigée vers un pool d’assurance ou une réserve de compensation.
- Structure : les couches conservatrices reçoivent moins de paiements, mais disposent d’une priorité de compensation ; les couches agressives acceptent un risque plus élevé.
Pourquoi cela peut devenir un risque systémique : le prix des LRT influence simultanément les collatéraux dans de nombreux protocoles. Lors d’une réévaluation du risque AVS, la décote des LRT détériore la qualité du collatéral et accélère les liquidations, renforçant les ventes en cascade.
Exemple de scénario : ETH → LST → restaking → LRT → utilisation du LRT comme collatéral pour emprunter des stablecoins. Dans cette chaîne, un même stake assure simultanément Ethereum, sert les AVS et soutient une position de crédit, de sorte que la décote du LRT accélère le risque de liquidation.
Source des cascades : la RSFi s’articule autour des LRT et des paiements AVS, tandis que le principal canal des effets systémiques réside dans le transfert des anticipations d’AVS-slashing et de défaillances corrélées dans le prix du collatéral et la liquidité de sortie.
L’avenir du restaking et les modèles de sécurité partagée
Le restaking évolue vers un format de “sécurité partagée” : les projets se connectent à une couche de responsabilité de marché (paiement pour des règles et des pénalités), au lieu de construire leur propre économie de validateurs.
Grand carrefour de croissance : l’ampleur du restaking est déterminée par les standards d’intégration, le design du slashing et les procédures de localisation des incidents, et non seulement par le nombre de nouveaux AVS.
| Ce qui change | Pourquoi c’est nécessaire | Ce que cela réduit |
|---|---|---|
| Standardisation des interfaces AVS et des profils de risque | Comparabilité des conditions et baisse du “coût d’intégration” de la sécurité | Fragmentation des intégrations et erreurs dues à des implémentations uniques |
| Rigueur formelle (audits, vérification, post-mortems) | Accès au stake important réservé aux modules matures | Risque de bugs critiques et de “boîtes noires” sans explication |
| Slashing conçu comme de l’ingénierie (caps, gradations, déclencheurs clairs) | Prix de l’erreur contrôlable et prévisibilité des dommages | Pénalités de masse dues à des événements rares ou contestés |
| Procédures d’incident (resolvers, arbitrage, compensations) | Localisation des conflits à l’intérieur de la couche de restaking | Transfert des litiges et de la pression vers la couche de base Ethereum |
Ce qui deviendra la “norme de marché” pour les opérateurs de sécurité :
- Portefeuille d’AVS et limites d’exposition. Ensemble de services et limites formelles sur la part du stake sous chaque politique de slashing.
- Des processus plutôt que des promesses. Règles de mise à jour, monitoring, réaction, tests et journalisation des incidents.
- Transparence et réputation. Historique des défaillances et du slashing, rapports publics, règles claires pour gérer les conflits et les compensations (si elles sont prévues).
- Contrôle des corrélations. Prise en compte des composants communs de la stack et des risques d’“un bug pour tous” lors de mises à jour massives.
Phase de transition : les premiers grands scénarios de stress sont presque inévitables (bugs, pénalités contestées, défaillances corrélées). La résilience du modèle dépend des caps de dommages, de procédures d’analyse transparentes et de mécanismes de localisation des conflits au niveau du restaking, et non au niveau du consensus Ethereum.
Direction : si la standardisation réussit, la sécurité peut devenir un service d’infrastructure avec garanties cryptoéconomiques, où les “conditions de responsabilité” se lisent aussi clairement que les tarifs et les SLA dans les services d’infrastructure classiques.
Facteur de succès : l’avenir du restaking dépend de l’ingénierie de la responsabilité : standardisation des AVS, slashing prévisible et procédures de localisation des incidents sans cascades systémiques.
FAQ sur le restaking et le protocole EigenLayer
Réponses courtes aux questions fréquentes : qu’est-ce que le restaking et un AVS, 32 ETH sont-ils nécessaires, d’où viennent les paiements et où apparaît exactement le risque de slashing.
Qu’est-ce que le restaking, en termes simples ?
Qu’est-ce qu’un AVS dans le contexte d’EigenLayer ?
Faut-il disposer de 32 ETH pour participer au restaking ?
Quel revenu le restaking peut-il générer ?
Quelle est la différence entre le restaking et le liquid staking (LST) ?
Une perte de capital à cause du restaking est-elle possible ?
Le restaking risque-t-il d’affaiblir la sécurité d’Ethereum lui-même ?
Synthèse finale : restaking, LST, délégation et LRT
Le restaking ajoute au staking ETH un second niveau de responsabilité : le stake devient slashable selon les règles des AVS. Cela crée un marché de sécurité partagée et des paiements pour des tâches d’infrastructure, mais élargit aussi le niveau de risque pour le stake et pour les chaînes DeFi autour des LRT.
Synthèse en une ligne : EigenLayer relie le stake ETH à des services externes et transforme les obligations des opérateurs envers les AVS en responsabilité sanctionnable via le slashing du collatéral alloué.
Là où apparaît l’utilité (ce que le marché achète) :
- La sécurité comme service. Les AVS obtiennent une protection fondée sur le stake Ethereum sans lancer leur propre économie de validateurs.
- Lancement rapide d’infrastructure. Les protocoles se branchent sur une couche de responsabilité existante au lieu de créer un “token pour les validateurs”.
- Nouveaux primitives pour la DeFi. Les produits LRT et RSFi tokenisent les paiements et la responsabilité, mais avec eux, les risques sont eux aussi tokenisés.
Là où apparaît le risque (ce qui devient le prix des paiements) :
- AVS-slashing. En plus des règles d’Ethereum apparaissent des politiques de slashing distinctes pour chaque service.
- Défaillances corrélées. Des composants communs de la stack et des mises à jour de masse peuvent entraîner des violations synchrones chez de nombreux opérateurs.
- Cascades via le prix du LRT. La décote du LRT dégrade la qualité du collatéral et accélère les liquidations dans les protocoles de crédit.
Essence du modèle : le restaking sur EigenLayer n’est pas un “supplément de pourcentage”, mais un modèle de responsabilité élargie. Sa robustesse repose sur des limites d’exposition, une diversification entre opérateurs et AVS, et une préparation au slashing et aux défaillances corrélées.
Condition de standardisation : le restaking s’imposera comme standard d’infrastructure si les incidents sont localisés à l’intérieur de la couche de restaking (caps de dommages, procédures d’examen, réserves/compensations), et si le risque est évalué avec la même rigueur que les smart contracts et les collatéraux dans la DeFi.