Que se passe-t-il sur le marché du restaking ? Retour sur les erreurs et les succès deux ans après la conception d’EigenLayer

Rétrospective approfondie sur le parcours du restaking d’EigenLayer : les écueils rencontrés, les réussites d’EigenDA, tout cela pave la voie vers la nouvelle direction EigenCloud. Cet article est rédigé par Kydo, responsable de la narration EigenCloud, compilé, traduit et édité par Saoirse de Foresight News.

(Contexte préalable : Rapport de 10 000 mots — Comprendre en profondeur le leader du restaking EigenLayer) (Complément d’information : Qu’est-ce que le produit phare d’EigenLayer, le protocole de restaking EigenDA ?)

De temps à autre, des amis m’envoient des tweets moqueurs sur le restaking, mais ces railleries passent toujours à côté du sujet. J’ai donc décidé d’écrire moi-même un article de réflexion, façon « coup de gueule ».

Peut-être pensez-vous que je suis trop impliqué pour rester objectif ; ou trop fier pour admettre « nous nous sommes trompés ». Vous vous dites sans doute que même si tout le monde considère que « le restaking a échoué », je rédigerais un plaidoyer sans jamais employer le mot « échec ».

Ces opinions sont compréhensibles, et souvent fondées.

Mais cet article vise simplement à présenter objectivement les faits : ce qui s’est 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 auront une portée générale et offriront quelques pistes aux développeurs d’autres écosystèmes.

Après plus de deux ans à intégrer tous les principaux AVS (services de validation autonomes) sur EigenLayer et à concevoir EigenCloud, je souhaite faire un bilan honnête : où nous nous sommes trompés, où nous avons eu raison, et quelle sera la prochaine étape.

Qu’est-ce que le restaking ?

Le fait que je doive encore expliquer « qu’est-ce que le restaking » aujourd’hui prouve qu’au moment où le sujet était central dans l’industrie, nous n’avons pas su le clarifier. Voilà la « leçon n°0 » : se concentrer sur un récit principal et le répéter sans relâche.

L’objectif de l’équipe Eigen a toujours été « simple à dire, difficile à faire » : augmenter la vérifiabilité des calculs off-chain pour permettre la construction d’applications on-chain plus sûres.

Les AVS sont notre première tentative marquée dans cette direction.

Les AVS (services de validation autonomes) sont des réseaux Proof of Stake (PoS) composés d’opérateurs décentralisés qui exécutent des tâches hors chaîne. Leurs comportements sont surveillés et, en cas d’infraction, leur capital staké fait l’objet de pénalités. Or, pour qu’un « mécanisme de sanction » fonctionne, il faut du « capital staké » en garantie.

C’est là que réside la valeur du restaking : inutile pour chaque AVS de bâtir son propre système de sécurité à partir de zéro, le restaking permet de réutiliser l’ETH déjà staké pour sécuriser simultanément plusieurs AVS. Cela réduit non seulement le coût du capital, mais accélère aussi le lancement de l’écosystème.

On peut donc résumer le cadre conceptuel du restaking ainsi :

• AVS : la « couche service », qui porte les nouveaux systèmes de sécurité cryptoeconomiques PoS ;
• Restaking : la « couche capital », qui réutilise le capital staké existant pour sécuriser ces systèmes.

Je pense toujours que ce concept est brillant, mais la réalité a été bien moins idéale que sur le schéma — beaucoup de choses n’ont pas eu le succès escompté.

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

1. Nous avons choisi le mauvais marché : trop de niche

Nous ne voulions pas de « n’importe quel calcul vérifiable », mais nous étions obsédés par le fait que le système soit, dès le premier jour, décentralisé, basé sur la sanction et totalement sécurisé par l’économie cryptographique.

Nous espérions que les AVS deviennent des « services d’infrastructure » — comme les développeurs créent du SaaS, n’importe qui pourrait bâtir un AVS.

Ce positionnement, certes princépié, a toutefois considérablement réduit le cercle des développeurs potentiels.

Au final, nous avons fait face à un marché « de petite taille, à progression lente et à seuil élevé » : peu d’utilisateurs potentiels, des coûts de déploiement élevés et des cycles d’adoption longs pour les deux parties (équipe et développeurs). Que ce soit l’infrastructure EigenLayer, les outils de développement ou chaque AVS, il faut des mois, voire des années, pour tout construire.

Près de trois ans plus tard : seuls deux AVS majeurs sont 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 avions imaginé que les équipes voudraient, dès le premier jour, sécurité cryptoeconomique et opérateurs décentralisés, mais la réalité du marché voulait des solutions « plus progressives et orientées application ».

2. Limité par l’environnement réglementaire, nous avons été forcés au silence

Lorsque nous avons lancé le projet, c’était l’apogée de l’ère Gary Gensler (président de la SEC américaine, connu pour sa sévérité envers la cryptosphère). Plusieurs sociétés de staking faisaient alors l’objet d’enquêtes et de poursuites.

En tant que projet de restaking, la moindre de nos paroles en public pouvait être interprétée comme une « promesse d’investissement » ou une « publicité sur les rendements », voire entraîner une assignation.

Cette brume réglementaire a conditionné notre communication : nous ne pouvions pas nous exprimer librement. Même submergés par les critiques, lâchés par des partenaires ou attaqués dans les médias, nous ne pouvions pas rétablir la vérité en temps réel.

Nous ne pouvions même pas dire simplement « ce n’est pas comme ça que ça se passe » — il fallait d’abord peser le risque juridique.

Résultat : nous avons lancé des tokens verrouillés sans réelle communication. Avec le recul, c’était risqué.

Si vous avez eu l’impression que l’équipe Eigen était évasive ou anormalement silencieuse sur certains sujets, c’est probablement à cause de cet environnement réglementaire — un simple tweet mal formulé pouvait engendrer de lourds risques.

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

La notoriété initiale d’Eigen reposait en grande partie sur Sreeram (membre clé de l’équipe) — son énergie, son optimisme et sa croyance que les systèmes comme les hommes peuvent s’améliorer, ont généré beaucoup de sympathie.

Des milliards de capital staké ont renforcé cette confiance.

Mais notre communication conjointe avec les premiers AVS n’a pas été à la hauteur de cette « stature de marque ». Nombre de ces premiers AVS, très bruyants, ne poursuivaient que les tendances du secteur ; ils n’étaient ni « les plus techniques » ni « les plus intègres » comme exemples d’AVS.

Peu à peu, « EigenLayer » s’est retrouvé associé à « la dernière mode du liquidity mining ou des airdrops ». Les doutes, la lassitude et même le rejet que nous subissons aujourd’hui trouvent souvent leur origine à cette époque.

Si c’était à refaire, j’aurais préféré commencer avec « moins, mais de meilleurs AVS », être plus sélectif dans l’octroi du label de marque et accepter un lancement « plus lent et moins bruyant ».

4. Une recherche excessive de « minimisation de la confiance » a mené à une conception technique redondante

Nous avons tenté de bâtir un « système de sanction universel parfait » — généraliste, flexible, couvrant tous les scénarios de sanction pour réaliser une « confiance minimale ».

En pratique, cela a ralenti notre itération produit et nécessité d’innombrables explications sur un mécanisme que « la plupart n’étaient pas prêts à comprendre ». Même aujourd’hui, nous devons régulièrement vulgariser le système de sanction lancé il y a près d’un an.

Avec le recul, un chemin plus raisonnable aurait été : lancer d’abord une version simple du mécanisme de sanction, laisser chaque AVS expérimenter un modèle plus ciblé, puis augmenter progressivement la complexité du système. Or, nous avons mis la « conception complexe » en avant, et avons payé le prix sur la « rapidité » et la « clarté »…