Restaking et EigenLayer promettent d’étendre la sécurité blockchain, mais ce mécanisme ajoute aussi des dépendances qui peuvent amplifier des risques de cascade.
Le sujet attire, car il touche au cœur de l’architecture d’Ethereum et de plusieurs protocoles de staking. L’enjeu n’est pas seulement le rendement affiché. Il concerne aussi le rejeu des tokens, la décentralisation, l’interopérabilité entre services, et la manière dont des vulnérabilités en chaîne peuvent se propager.
Comment fonctionne le Restaking avec EigenLayer
Le Restaking consiste à réutiliser une même base de sécurité, issue du staking d’ETH, pour sécuriser d’autres services. EigenLayer a popularisé ce modèle sur Ethereum en permettant à des validateurs ou à des détenteurs de liquid staking tokens d’étendre leur exposition à des systèmes externes.
Le principe est technique, mais l’idée centrale reste simple. Une ressource déjà engagée pour la validation peut être affectée à d’autres couches applicatives, souvent appelées AVS, pour Actively Validated Services. Cela crée une forme de mutualisation de la sécurité cryptographique, avec un coût d’entrée théoriquement plus faible pour les nouveaux protocoles.
Ce schéma séduit, car il réduit le besoin de bâtir une sécurité native dès le départ. Un protocole émergent peut ainsi s’appuyer sur une base économique déjà constituée. En contrepartie, il dépend d’une infrastructure commune, donc d’un risque partagé.
Le rejeu des tokens dans l’architecture du restaking
Le rejeu des tokens ne signifie pas qu’un même jeton est dupliqué. Il signifie qu’un capital déjà immobilisé sert à garantir plusieurs engagements à la fois. Cette superposition peut accroître l’efficacité du capital, mais elle multiplie aussi les conditions de défaillance.
Un validateur exposé à plusieurs services peut subir des pénalités si l’un des systèmes connaît un incident. Selon la documentation technique d’EigenLayer consultable via ses publications publiques, le cadre repose sur des règles de délégation, d’opérateurs et de slashing encore sensibles à la qualité des implémentations. Le point clé tient donc moins à la promesse qu’à l’enchaînement des responsabilités techniques.
Pourquoi la sécurité blockchain peut gagner en portée, puis perdre en robustesse
La promesse initiale est nette. Avec EigenLayer, des services comme des oracles, des ponts, des couches de disponibilité de données ou des réseaux d’inférence peuvent louer une sécurité économique issue d’Ethereum. Cette logique peut améliorer l’interopérabilité et accélérer le lancement de nouveaux protocoles.
Cette extension de la sécurité blockchain n’est pourtant pas gratuite. Selon l’AMF, qui rappelle régulièrement les risques élevés liés aux crypto-actifs, l’innovation technique ne réduit ni la volatilité ni le risque opérationnel. Dans ce cadre, la mutualisation de la sécurité peut aussi mutualiser les dommages.
Le sujet rappelle des épisodes déjà observés dans la finance traditionnelle. Quand plusieurs acteurs reposent sur une même garantie ou une même chambre de compensation, l’efficacité augmente, mais la concentration devient plus sensible. Dans les réseaux décentralisés, la question devient alors celle-ci : jusqu’où la mutualisation reste-t-elle compatible avec la décentralisation ?
Les points de fragilité à surveiller dans les protocoles de staking
Les protocoles de staking reposent sur des couches logicielles, des opérateurs, des règles de délivation et parfois des tokens intermédiaires. Chaque couche peut introduire une erreur de code, un problème d’incitation, ou une mauvaise gouvernance. Le risque n’est donc pas univoque.
Les principaux foyers de fragilité sont les suivants :
- Risque de slashing étendu à plusieurs services, avec perte potentielle sur le capital engagé.
- Risque de smart contract, lié à un bug, une mauvaise mise à jour ou une faille d’audit non détectée.
- Risque de centralisation, si quelques opérateurs dominent la validation ou la délégation.
- Risque de liquidité, surtout quand un jeton représentatif du staking s’échange avec une décote en période de stress.
- Risque réglementaire, car le cadre MiCA dans l’Union européenne n’efface pas les obligations locales ni les restrictions sur certains services.
Pris séparément, ces risques sont déjà connus. Combinés dans un système de restaking, ils peuvent se renforcer mutuellement. C’est là que la notion de vulnérabilités en chaîne prend un sens concret.
Risques de cascade : comment une défaillance locale peut contaminer l’ensemble
Les risques de cascade apparaissent quand plusieurs protocoles partagent les mêmes garanties économiques ou les mêmes opérateurs. Une panne sur un service secondaire peut alors produire des effets disproportionnés. La difficulté vient du fait que la source du choc n’est pas toujours la plus grosse brique du système.
Un scénario souvent évoqué par les chercheurs en sécurité porte sur un AVS mal conçu. Si ce service déclenche à tort des pénalités, ou si ses règles de validation sont ambiguës, les opérateurs peuvent subir des pertes, réduire leur activité, puis affecter d’autres services connectés. Le mécanisme ne ressemble pas à un simple bug isolé. Il ressemble à une transmission de stress.
Tableau des promesses techniques et des vulnérabilités en chaîne
Le tableau ci-dessous résume la logique du modèle. Il montre aussi pourquoi l’analyse doit dépasser le seul argument du rendement ou de l’innovation.
| Dimension | Promesse technique | Risque associé | Point de vigilance |
|---|---|---|---|
| Sécurité mutualisée | Réutiliser l’ETH staké pour plusieurs services | Risques de cascade en cas de défaillance d’un AVS | Règles de slashing, gouvernance et audits |
| Interopérabilité | Connecter des services spécialisés à une base commune | Propagation plus rapide des erreurs | Segmentation des responsabilités techniques |
| Efficacité du capital | Rejeu des tokens et moindre coût de sécurité initiale | Sur-exposition économique d’un même collatéral | Limites d’engagement et transparence des expositions |
| Décentralisation | Ouverture théorique à plusieurs opérateurs | Concentration chez quelques validateurs majeurs | Répartition réelle du pouvoir de validation |
| Sécurité cryptographique | Appui sur une couche éprouvée comme Ethereum | Confiance excessive dans des briques annexes moins robustes | Qualité du code, supervision et procédures d’urgence |
Le risque systémique ne vient donc pas seulement de la taille d’un protocole. Il vient de sa place dans le graphe des dépendances. Plus ce graphe se densifie, plus la surveillance doit porter sur les liaisons.
Décentralisation, régulation et limites du modèle EigenLayer
La décentralisation reste un argument central des réseaux publics. Pourtant, un empilement de services autour d’une même couche de sécurité peut recréer des concentrations de pouvoir. Si quelques opérateurs captent l’essentiel des délégations, la robustesse théorique se heurte à une réalité plus étroite.
Le cadre réglementaire ajoute un autre niveau de lecture. Dans l’Union européenne, le règlement MiCA encadre une partie des services sur crypto-actifs, mais il ne valide pas la solidité technique d’un protocole. L’AMF rappelle par ailleurs que les crypto-actifs exposent à une perte totale du capital, à des dysfonctionnements de plateforme et à des risques opérationnels élevés. Pour les prestataires, la question du statut PSAN reste également centrale en France pour certains services sur actifs numériques.
Finance to the Top a documenté l’évolution de ces débats, car ils dépassent le seul cas d’EigenLayer. Ils posent une question de structure. Quand la sécurité devient un marché interconnecté, il faut mesurer non seulement la résistance de chaque protocole, mais aussi celle des liens entre eux.
Cet article a une vocation informative et ne constitue pas un conseil en investissement.