Qu'est-ce qui se passe avec le restaking ?

Rédigé par : Kydo, Responsable du narratif chez EigenCloud

Traduit par : Saoirse, Foresight News

De temps en temps, des amis m’envoient des tweets moqueurs sur le restaking, mais ces moqueries passent toujours à côté de l’essentiel. J’ai donc décidé d’écrire moi-même un article à tonalité réflexive, une sorte de “coup de gueule”.

Vous pourriez penser que je suis trop impliqué pour rester objectif ; ou que je suis trop fier pour admettre “nous nous sommes trompés”. Vous pourriez croire que, même si tout le monde considère que “le restaking a échoué”, je continuerais à écrire de longues justifications sans jamais prononcer le mot “échec”.

Toutes ces opinions sont compréhensibles, et beaucoup sont fondées.

Mais cet article a simplement pour but de présenter les faits de manière objective : ce qui s’est réellement passé, ce qui a été réalisé, ce qui ne l’a pas été, et les leçons que nous en avons tirées.

J’espère que les expériences partagées ici seront universelles et pourront servir de référence aux développeurs d’autres écosystèmes.

Après avoir intégré tous les principaux AVS (Services de Vérification Autonomes) sur EigenLayer et conçu EigenCloud depuis plus de deux ans, je souhaite faire un bilan en toute transparence : où avons-nous échoué, où avons-nous réussi, et quelle est la voie à suivre.

Qu’est-ce que le restaking (re-mise) au juste ?

Le simple fait que je doive encore expliquer “ce qu’est le restaking” montre qu’au moment où le sujet était au centre de l’attention, nous n’avons pas su bien le présenter. Voilà la “leçon numéro 0” : se concentrer sur un narratif central et le transmettre inlassablement.

L’objectif de l’équipe Eigen a toujours été “simple à dire, difficile à faire” : permettre de construire des applications on-chain de façon plus sûre grâce à une meilleure vérifiabilité du calcul off-chain.

L’AVS est notre première tentative claire dans ce sens.

Les AVS (Services de Vérification Autonomes) sont des réseaux Proof-of-Stake (PoS) dans lesquels un ensemble d’opérateurs décentralisés exécutent des tâches off-chain. Leurs comportements sont surveillés et, en cas d’infraction, leur capital mis en jeu peut être pénalisé. Pour que ce “mécanisme de sanction” fonctionne, il faut du “capital en staking” pour soutenir le tout.

C’est là que réside la valeur du restaking : au lieu que chaque AVS ait à bâtir sa propre sécurité à partir de zéro, le restaking permet de réutiliser l’ETH déjà staké pour sécuriser plusieurs AVS. Cela réduit les coûts en capital et accélère le lancement de l’écosystème.

Le cadre conceptuel du restaking peut donc se résumer ainsi :

AVS : la “couche service”, support de nouveaux systèmes de sécurité cryptoeconomique en PoS ; Restaking : la “couche capital”, qui apporte la sécurité par la réutilisation d’actifs déjà stakés pour ces systèmes.

Je considère toujours que cette idée est brillante, mais la réalité n’a pas été aussi idyllique que sur le schéma — de nombreux aspects n’ont pas répondu aux attentes.

Ce qui n’a pas été à la hauteur des attentes

1. Nous avons mal choisi notre marché : trop de niche

Nous ne voulions pas n’importe quel “calcul vérifiable”, mais étions obsédés par l’idée de systèmes “dès le premier jour décentralisés, basés sur la sanction, et totalement sécurisés cryptoeconomiquement”.

Nous voulions que l’AVS devienne un “service d’infrastructure”, comme le SaaS (Software as a Service), où n’importe qui pourrait en construire un.

Ce positionnement, bien que noble, a considérablement réduit la base potentielle de développeurs.

Résultat : le marché ciblé était “petit, lent, à forte barrière d’entrée” : peu d’utilisateurs potentiels, coûts élevés, cycles longs tant pour l’équipe que pour les développeurs. Qu’il s’agisse de l’infrastructure d’EigenLayer, des outils de développement ou de chaque AVS, il fallait des mois, parfois des années, pour bâtir le tout.

Presque trois ans plus tard : seuls deux AVS majeurs sont aujourd’hui en production — DIN (Decentralized Infrastructure Network) d’Infura et EigenZero de LayerZero. Un tel “taux d’adoption” est loin d’être “large”.

Pour être honnête, nous imaginions des cas où “des équipes voudraient, dès le premier jour, disposer d’une sécurité cryptoeconomique et d’opérateurs décentralisés”, mais la demande réelle était pour des solutions “plus progressives, centrées sur l’application”.

2. Sous la pression réglementaire, nous avons été contraints au silence

Au lancement du projet, nous étions à l’apogée de “l’ère Gary Gensler” (note : Gary Gensler est le président de la SEC américaine, connu pour sa sévérité envers l’industrie crypto). Plusieurs entreprises de staking faisaient l’objet d’enquêtes et de poursuites.

En tant que projet de “restaking”, chaque mot prononcé publiquement pouvait être interprété comme une “promesse d’investissement”, une “publicité de rendement”, voire nous valoir une assignation.

Cette incertitude réglementaire a dicté notre façon de communiquer : impossible de s’exprimer librement, même sous le feu de critiques massives, de partenaires qui nous lâchaient ou de campagnes de désinformation, nous ne pouvions pas clarifier en temps réel.

Nous ne pouvions même pas dire simplement “ce n’est pas comme ça que ça s’est passé” — il fallait d’abord évaluer le risque légal.

Au final, en l’absence de communication suffisante, nous avons lancé un token verrouillé. Avec le recul, c’était risqué.

Si vous avez eu l’impression que “l’équipe Eigen fuyait certaines questions ou restait anormalement silencieuse”, c’est probablement à cause de cet environnement réglementaire — un simple tweet mal tourné pouvait entraîner des conséquences majeures.

3. Les premiers AVS ont dilué la valeur de la marque

La notoriété initiale d’Eigen reposait beaucoup sur Sreeram (membre clé de l’équipe) — son énergie, son optimisme, sa conviction dans le progrès des systèmes et des individus, tout cela a suscité une forte sympathie.

Des milliards en staking ont encore renforcé cette confiance.

Mais notre co-promotion des premiers AVS n’a pas été à la hauteur de cette “aura de marque”. Beaucoup de ces AVS faisaient du bruit tout en surfant sur les tendances, sans être ni “les plus techniques”, ni “les plus éthiques”.

Peu à peu, “EigenLayer” a été assimilé à la “dernière mode du yield farming et des airdrops”. Les doutes, la lassitude et même le rejet actuel trouvent en grande partie leur origine à cette époque.

Si c’était à refaire, j’aimerais commencer avec “moins d’AVS, mais de meilleure qualité”, être plus exigeant sur les partenaires à qui accorder notre caution, et accepter un lancement “plus lent, moins hype”.

4. Une recherche excessive de “trust minimization” a mené à des excès de conception

Nous avons voulu bâtir un “système de sanction universel parfait” — général, flexible, couvrant tous les scénarios pour minimiser la confiance.

Mais à l’usage, cela a ralenti notre développement et nécessité d’innombrables explications d’un mécanisme “encore trop complexe pour la majorité”. Même aujourd’hui, notre système de sanction lancé il y a près d’un an nécessite toujours de la pédagogie.

Avec le recul, le chemin le plus raisonnable aurait été : sortir d’abord une sanction simple, laisser chaque AVS expérimenter un modèle ciblé, puis complexifier graduellement. Mais nous avons mis la “complexité” en avant, au détriment de la vitesse et de la clarté.

Ce que nous avons vraiment réussi

Il est trop facile d’étiqueter une initiative comme “échec” ; ce serait hâtif.

Dans le chapitre du “restaking”, de nombreuses choses ont été très bien faites, et ces acquis sont essentiels pour la suite.

1. Nous avons prouvé que nous pouvions gagner dans des marchés ultra-concurrentiels

Nous privilégions le “win-win”, mais n’avons pas peur de la compétition — une fois engagés, nous visons la pole position.

Dans le restaking, Paradigm et Lido ont uni leurs forces pour soutenir nos rivaux directs. À l’époque, la TVL d’EigenLayer n’atteignait pas 1 milliard.

Nos concurrents avaient l’avantage du narratif, des réseaux, du capital et de la confiance implicite. Beaucoup me disaient “leur duo est imbattable, ils vont vous écraser”. Mais la réalité fut autre : aujourd’hui, nous détenons 95% de la part de marché du restaking et attirons 100% des développeurs de premier plan.

Dans la “Data Availability (DA)”, nous sommes partis plus tard, avec une équipe plus réduite et moins de fonds, tandis que les leaders avaient déjà l’avantage du terrain et du marketing. Pourtant, selon tous les indicateurs clés, EigenDA (la solution DA d’Eigen) détient aujourd’hui une grande part du marché — et cette part va encore croître de façon exponentielle avec le lancement complet de notre plus grand partenaire.

Ces deux marchés étaient féroces, et nous avons émergé.

2. EigenDA est devenu un produit mature “changeant la donne”

Le lancement d’EigenDA sur l’infrastructure EigenLayer fut une énorme surprise.

C’est devenu la pierre angulaire d’EigenCloud, et a offert à Ethereum ce dont il avait besoin : une solution DA à très grande échelle. Grâce à elle, les Rollups peuvent rester rapides sans avoir à quitter l’écosystème Ethereum pour une nouvelle blockchain.

MegaETH a été lancé parce que l’équipe croyait que Sreeram pouvait les aider à franchir le cap DA ; Mantle, lors de sa proposition à BitDAO pour bâtir un L2, était motivé par la même confiance.

EigenDA est aussi devenu un “bouclier défensif” pour Ethereum : avec une solution DA native à haut débit, il est plus difficile pour les blockchains externes de “capter l’attention via le narratif Ethereum tout en siphonnant la valeur de l’écosystème”.

3. Nous avons favorisé l’émergence du marché du pré-confirmation

L’un des sujets centraux d’EigenLayer au départ était : comment débloquer la pré-confirmation pour Ethereum via EigenLayer.

Depuis, le pré-confirmation a reçu beaucoup d’attention via le réseau Base, mais reste difficile à implémenter.

Pour faire avancer l’écosystème, nous avons co-lancé Commit-Boost — une initiative visant à résoudre le “lock-in effect” des clients pré-confirmation et à créer une plateforme neutre où chacun peut innover via l’engagement des validateurs.

Aujourd’hui, des milliards de dollars transitent par Commit-Boost, plus de 35% des validateurs sont connectés à ce programme. Ce taux augmentera encore avec le lancement imminent des principaux services de pré-confirmation.

C’est crucial pour la “résilience” de l’écosystème Ethereum, et cela pose les bases pour une innovation continue sur ce marché.

4. Nous avons toujours garanti la sécurité des actifs

Depuis des années, nous assurons la sécurité de dizaines de milliards de dollars.

Cela peut sembler banal, voire “ennuyeux” — mais vu le nombre d’infrastructures crypto qui ont “implosé” sous diverses formes, cette “banalité” se révèle précieuse. Pour éviter les risques, nous avons bâti un système opérationnel solide, recruté une équipe sécurité de classe mondiale et intégré une “pensée adverse” dans notre culture.

Cette culture est essentielle pour toute activité impliquant des fonds utilisateurs, de l’IA ou des systèmes réels, et “ne se rattrape pas après coup” — il faut poser les bases dès le début.

5. Nous avons empêché Lido de dépasser durablement 33% du staking

L’un des effets sous-estimés du restaking : une grande quantité d’ETH est allée vers les fournisseurs LRT, évitant que Lido ne dépasse durablement 33% du staking.

C’est essentiel pour l’“équilibre social” d’Ethereum. Si Lido avait franchi ce seuil sans alternative crédible, des conflits majeurs de gouvernance auraient éclaté.

Restaking et LRT n’ont pas “magiquement réalisé la décentralisation totale”, mais ils ont inversé la tendance à la concentration du staking — un accomplissement loin d’être négligeable.

6. Nous avons clarifié “où est la vraie frontière”

Le plus grand “gain” a été idéologique : nous avons validé l’idée que “le monde a besoin de plus de systèmes vérifiables”, mais aussi compris que “le chemin choisi n’était pas le bon”.

La bonne voie n’est pas de “démarrer avec une sécurité cryptoeconomique universelle, créer une couche d’opérateurs totalement décentralisée dès le premier jour, puis attendre que toutes les activités s’y connectent”.

Ce qui accélère vraiment la “frontière”, c’est d’offrir aux développeurs des outils directs pour rendre leurs applications vérifiables, avec les bons primitives de vérification. Il faut “coller aux besoins des développeurs”, et non exiger d’eux qu’ils deviennent “architectes de protocoles” d’entrée de jeu.

Nous avons donc commencé à bâtir des services internes modulaires — EigenCompute (calcul vérifiable) et EigenAI (IA vérifiable). Là où d’autres équipes doivent lever des centaines de millions de dollars et travailler des années, nous pouvons livrer en quelques mois.

La suite

Face à tout cela — timing, succès, échecs, “cicatrices” de marque — comment réagir ?

Voici un aperçu de nos prochaines étapes et de la logique derrière :

1. Faire du token EIGEN le cœur du système

À l’avenir, tout EigenCloud et les produits qui l’entourent seront centrés sur le token EIGEN.

Le rôle du token EIGEN :

Pilier de la sécurité économique d’EigenCloud ; Actif garant des risques supportés par la plateforme ; Outil central de capture de valeur couvrant tous les flux de frais et activités économiques de la plateforme.

Au départ, beaucoup se sont interrogés sur la “valeur capturable” du token EIGEN versus “le mécanisme réel” — cela a semé la confusion. À la prochaine étape, nous comblerons cet écart par une conception concrète et des systèmes effectifs. Plus de détails à venir.

2. Permettre aux développeurs de créer des “applications vérifiables”, pas seulement des AVS

Notre thèse centrale reste : améliorer la vérifiabilité du calcul off-chain pour bâtir des applications on-chain plus sûres. Mais les outils pour y arriver ne seront plus uniques.

Parfois, ce sera la sécurité cryptoeconomique ; parfois, la preuve ZK, le TEE (environnement d’exécution de confiance), ou des solutions hybrides. L’essentiel n’est pas de “vénérer une technologie”, mais que la “vérifiabilité” devienne une primitive standard, accessible directement aux développeurs.

Notre ambition est de réduire l’écart entre :

“J’ai une application” et “J’ai une application que mes utilisateurs, partenaires ou régulateurs peuvent vérifier”.

À l’heure actuelle, la combinaison “cryptoeconomie + TEE” est le meilleur choix — elle maximise “programmabilité développeur” (ce qu’ils peuvent construire) et “sécurité” (pas juste théorique, mais concrètement applicable).

À l’avenir, lorsque les ZK proofs et autres mécanismes seront mûrs et répondront aux besoins des développeurs, nous les intégrerons à EigenCloud.

3. Investir en profondeur dans l’IA

La plus grande révolution du calcul mondial aujourd’hui, c’est l’IA — en particulier les agents intelligents (AI Agents). La crypto ne peut s’en abstraire.

Les agents IA sont essentiellement des “modèles linguistiques enveloppés d’outils, agissant dans un environnement donné”.

Aujourd’hui, non seulement les modèles sont des “boîtes noires”, mais la logique opérationnelle des agents IA l’est aussi — d’où des attaques où “il faut faire confiance au développeur”.

Mais si ces agents IA deviennent “vérifiables”, la confiance envers le développeur devient inutile.

Trois conditions sont nécessaires : l’inférence du LLM (modèle de langage) doit être vérifiable ; l’environnement d’exécution doit l’être aussi ; et la couche donnée (stockage, récupération, compréhension de contexte) également.

EigenCloud est conçu pour ces cas d’usage :

EigenAI : service d’inférence LLM déterministe et vérifiable ; EigenCompute : environnement d’exécution vérifiable ; EigenDA : stockage et récupération de données vérifiables.

Nous croyons que “l’agent IA vérifiable” sera l’un des cas d’usage les plus compétitifs pour notre “cloud vérifiable” — nous avons donc formé une équipe dédiée pour ce domaine.

4. Refonder le narratif “staking et rendement”

Pour obtenir un rendement réel, il faut assumer un risque réel.

Nous explorons des cas d’usage plus larges du staking, pour que le capital staké serve à couvrir :

Le risque des smart contracts ; Les risques liés à différents types de calcul ; Tout risque pouvant être clairement décrit et évalué.

Les rendements futurs refléteront réellement le “risque transparent et compréhensible assumé”, et non la simple poursuite du “yield farming à la mode”.

Cette logique sera naturellement intégrée dans les usages du token EIGEN, son champ de cautionnement et ses flux de valeur.

En conclusion

Le restaking n’est pas devenu la “couche universelle” que j’espérais (et d’autres aussi), mais il n’a pas disparu. Au fil du temps, il est devenu ce que sont la plupart des “produits de première génération” :

Un chapitre important, des leçons apprises dans la douleur, et une infrastructure désormais au service d’activités plus larges.

Nous continuons à maintenir les activités liées au restaking et à leur accorder de l’importance — mais nous ne voulons plus être limités par notre narratif initial.

Si vous êtes membre de la communauté, développeur d’AVS ou encore investisseur associant Eigen à “ce projet de restaking”, j’espère que cet article vous aura aidé à mieux comprendre “ce qui s’est passé” et “où nous allons”.

Nous entrons aujourd’hui dans un champ à “TAM (marché adressable total) bien plus vaste” : d’un côté le cloud, de l’autre les besoins directs des développeurs applicatifs. Nous explorons aussi la “piste IA encore sous-développée”, avec notre niveau d’exécution habituel.

L’équipe reste ultra-motivée, et je suis impatient de prouver à tous les sceptiques — nous en sommes capables.

Je n’ai jamais été aussi optimiste sur Eigen, je continue d’accumuler du EIGEN, et je compte bien poursuivre.

Nous ne faisons que commencer.