EigenLayer : La révolution de la confiance apportée par le restaking via des intergiciels
TechFlow SélectionTechFlow Sélection
EigenLayer : La révolution de la confiance apportée par le restaking via des intergiciels
EigenLayer devrait finaliser son lancement sur la mainnet au début de l'année prochaine et introduire son produit phare, EigenDA.
Dédié à des analyses Web3 approfondies
En novembre dernier, nous avions présenté EigenLayer dans cet article intitulé « EigenLayer : étendre la confiance de niveau Ethereum aux middlewares ». Depuis près d’un an, EigenLayer a publié son livre blanc, levé 50 millions de dollars lors d’un tour de financement de série A, et lancé la première phase de son réseau principal. Pendant cette période, la communauté Ethereum a largement débattu autour d’EigenLayer et de ses cas d’usage. Cet article vise à suivre et synthétiser ces discussions.
Contexte
Dans l’écosystème Ethereum, certains services intermédiaires (comme les oracles) ne reposent pas entièrement sur une logique on-chain, et ne peuvent donc pas directement bénéficier du consensus et de la sécurité d’Ethereum. Ils doivent ainsi recréer leur propre réseau de confiance. L’approche classique consiste à ce que le projet opère initialement en centralisé, puis introduise un mécanisme d’incitation par jeton pour attirer des participants et progressivement atteindre la décentralisation.
Cette méthode comporte au moins deux difficultés. Premièrement, l’introduction d’incitations implique des coûts supplémentaires : le coût d’opportunité pour les participants qui achètent des jetons et effectuent un stake, ainsi que le coût opérationnel supporté par le projet pour maintenir la valeur du jeton. Deuxièmement, même après avoir engagé ces coûts et construit un réseau décentralisé, la sécurité et la pérennité de ce dernier restent incertaines. Pour les jeunes projets, ces deux points sont particulièrement problématiques.
L’idée d’EigenLayer est de permettre aux validateurs existants d’Ethereum de procéder à un nouveau stake (restaking), afin de fournir une sécurité économique à ces services intermédiaires (Active Validated Services, AVS). Si ces acteurs du restaking agissent honnêtement, ils reçoivent une récompense ; s’ils se comportent malicieusement, leur mise initiale sur Ethereum peut être confisquée.
Les avantages sont doubles. D’une part, les projets n’ont plus besoin de construire eux-mêmes un nouveau réseau de confiance, mais peuvent l’externaliser aux validateurs Ethereum, réduisant ainsi significativement leurs coûts financiers. D’autre part, l’ensemble des validateurs Ethereum offre une sécurité économique très robuste, garantissant un haut niveau de sécurité. Du point de vue des validateurs Ethereum, le restaking leur apporte des revenus supplémentaires, avec un risque global maîtrisable tant qu’ils n’ont aucune intention malveillante.
Le fondateur d’EigenLayer, Sreeram, a évoqué à plusieurs reprises sur Twitter et dans des podcasts trois cas d’usage et modèles de confiance proposés par EigenLayer :
-
Confiance économique : réutilisation de l’exposition au stake d’Ethereum. Un stake impliquant un jeton de plus grande valeur assure une sécurité économique plus solide — sujet déjà discuté ci-dessus.
-
Confiance décentralisée : certains services (par exemple le partage secret) peuvent comporter des actions malveillantes impossibles à attribuer, rendant inopérant le mécanisme de slashing. Il faut alors un groupe suffisamment décentralisé et indépendant pour accomplir certaines tâches, afin de prévenir les risques de collusion.
-
Engagement du validateur Ethereum : les producteurs de blocs s’engagent de manière fiable, en mettant en jeu leur mise. Nous donnerons plus bas des exemples concrets.
Acteurs du système
EigenLayer fonctionne comme un marché ouvert reliant trois types d’acteurs principaux.
-
Restakers : ceux qui possèdent une exposition au stake Ethereum peuvent participer au restaking en transférant leurs informations de retrait vers EigenLayer, ou simplement en déposant des stETH ou autres LST. S’ils ne peuvent pas exécuter eux-mêmes un nœud AVS, ils peuvent déléguer leur exposition à un opérateur.
-
Opérateurs : ils acceptent la délégation des restakers et exécutent les nœuds AVS. Ils choisissent librement lesquels AVS servir. Une fois qu’ils fournissent un service à un AVS, ils doivent respecter les règles de slashing définies par celui-ci.
-
AVS : en tant que demandeurs/utilisateurs, ils paient les restakers pour bénéficier de leur sécurité économique.
Avec ces concepts de base en tête, examinons maintenant les cas d’usage concrets d’EigenLayer.
EigenDA
EigenDA est le produit phare lancé par EigenLayer, inspiré de la solution de scalabilité Danksharding d’Ethereum. L’échantillonnage de disponibilité des données (Data Availability Sampling, DAS) est également utilisé par des projets comme Celestia ou Avail. Ce chapitre présente rapidement le DAS, puis examine la mise en œuvre et les innovations d’EigenDA.
-
DAS
Comme étape préalable à Danksharding, EIP-4844 introduit la « transaction portant un blob », chaque transaction transportant environ 125 Ko de données supplémentaires. Dans le contexte du scaling via le sharding des données, ces données supplémentaires alourdissent davantage la charge des nœuds. Existe-t-il une méthode permettant aux nœuds de télécharger seulement une petite partie des données tout en vérifiant que toutes les données sont disponibles ?
La solution DAS consiste à faire effectuer plusieurs échantillonnages aléatoires à un nœud sur une petite fraction des données. Chaque échantillonnage réussi augmente le degré de confiance du nœud quant à la disponibilité des données. Dès qu’un certain niveau prédéfini est atteint, on considère que les données sont disponibles. Toutefois, un attaquant pourrait encore cacher une petite partie des données — il nous faut donc un mécanisme de tolérance aux pannes.
DAS utilise le codage d’effacement (Erasure Coding). L’idée centrale est de diviser les données en plusieurs blocs, puis de les encoder pour générer des blocs redondants supplémentaires. Ces blocs contiennent des informations partielles des blocs d’origine, permettant de reconstruire les blocs perdus ou corrompus à partir des blocs redondants. Ainsi, le codage d’effacement apporte redondance et fiabilité au DAS.
Par ailleurs, il faut s’assurer que les blocs redondants ont été correctement encodés, car des blocs incorrects ne permettraient pas de restaurer les données initiales. Danksharding adopte pour cela les engagements KZG (Kate-Zaverucha-Goldberg). Un engagement KZG est une méthode permettant de vérifier des polynômes, prouvant que la valeur du polynôme en un point donné correspond bien à une valeur spécifiée.
Le prouveur choisit un polynôme p(x), calcule l’engagement pour chaque bloc de données (C1, C2, ..., Cm), puis publie ces engagements avec les données. Pour vérifier l’encodage, le vérificateur sélectionne aléatoirement t points x1, x2, ..., xt, et demande au prouveur d’ouvrir les engagements en ces points : p(x1), p(x2), ..., p(xt). Grâce à l’interpolation de Lagrange, le vérificateur reconstruit le polynôme p(x). Il peut alors recalculer les engagements C1', C2', ..., Cm' à partir de p(x) et des données, et vérifier qu’ils correspondent aux engagements publiés C1, C2, ..., Cm.
En résumé, grâce aux engagements KZG, le vérificateur peut valider la correction complète de l’encodage en ne consultant qu’une petite fraction des points. On obtient ainsi un DAS complet.
-
Méthode
EigenLayer s’inspire du DAS et l’applique à EigenDA.
1. Tout d’abord, les nœuds EigenDA s’enregistrent et effectuent un restaking dans le contrat EigenLayer.
2. Ensuite, le séquenceur, après avoir reçu les données, les découpe en blocs, génère des blocs redondants via le codage d’effacement, et calcule les engagements KZG correspondant à chaque bloc. Le séquenceur publie ensuite un à un les engagements KZG dans le contrat EigenDA comme preuve.
3. Puis, le séquenceur distribue chaque bloc de données accompagné de son engagement KZG à chaque nœud EigenDA. Les nœuds comparent l’engagement KZG reçu avec celui publié dans le contrat EigenDA. S’il correspond, ils stockent le bloc et signent.
4. Enfin, le séquenceur collecte ces signatures, crée une signature agrégée et la publie dans le contrat EigenDA, où elle est vérifiée. Une fois la vérification réussie, le processus est terminé.
Dans ce processus, les nœuds EigenDA attestent simplement par signature qu’ils ont stocké les blocs. Il faut toutefois garantir qu’ils ne mentent pas. EigenDA utilise pour cela la Preuve de Garde (Proof of Custody).
Le principe de la Preuve de Garde consiste à insérer une « bombe » dans les données : si un nœud la signe, il sera puni. Pour l’implémenter, il faut concevoir : une valeur secrète permettant de distinguer les différents nœuds DA afin d’éviter la tricherie ; et une fonction spécifique au nœud DA, prenant comme entrées les données DA et la valeur secrète, produisant comme sortie la présence ou non d’une bombe. Si un nœud ne stocke pas intégralement les données requises, il ne peut pas calculer cette fonction. Dankrad a partagé plus de détails sur ce sujet dans un billet de blog.
Si un nœud paresseux est détecté, n’importe qui peut soumettre une preuve au contrat EigenDA, qui la vérifie. En cas de succès, le nœud paresseux est puni.
En termes de matériel, calculer l’engagement KZG pour 32 Mo de données en 1 seconde nécessite environ 32 à 64 cœurs CPU, mais cette exigence concerne uniquement le séquenceur, sans impact sur les nœuds EigenDA. Sur le testnet d’EigenDA, 100 nœuds ont atteint un débit de 15 Mo/s, tandis que la bande passante de téléchargement requise par nœud était de seulement 0,3 Mo/s (bien inférieure aux exigences d’un validateur Ethereum).
En somme, EigenDA parvient à dissocier disponibilité des données et consensus. La diffusion des blocs n’est plus limitée par les goulots d’étranglement du protocole de consensus ou du débit du réseau P2P. En effet, EigenDA profite du consensus d’Ethereum : publication des engagements KZG et des signatures agrégées par le séquenceur, vérification des signatures par contrat intelligent, et punition des nœuds malveillants — le tout se déroulant sur Ethereum, qui assure le consensus. Ainsi, aucun nouveau réseau de confiance n’a besoin d’être construit.
-
Problèmes du DAS
Actuellement, le DAS présente lui-même certaines limitations techniques. Il faut supposer qu’un adversaire malveillant utilisera tous les moyens possibles pour tromper les nœuds légers, en les amenant à accepter de fausses données. Sreeram a exposé cela dans un tweet.
Pour qu’un nœud unique ait une probabilité suffisamment élevée de juger les données disponibles, les conditions suivantes doivent être remplies :
-
Échantillonnage aléatoire : chaque nœud doit choisir aléatoirement et indépendamment un ensemble d’échantillons, sans que l’adversaire sache quels échantillons ont été demandés. Ainsi, l’attaquant ne peut pas adapter sa stratégie pour tromper le nœud.
-
Échantillonnage concurrent : le DAS doit être effectué simultanément par plusieurs nœuds, empêchant l’attaquant de distinguer les échantillons d’un nœud des autres.
-
Échantillonnage IP privé : chaque requête de bloc de données doit utiliser une IP anonyme. Sinon, l’adversaire pourrait identifier les nœuds échantillonneurs et choisir de ne fournir que les parties déjà interrogées, omettant le reste.
On peut satisfaire aux conditions de simultanéité et d’aléa en faisant participer plusieurs nœuds légers, mais il n’existe actuellement pas de bonne solution pour l’anonymat IP. Des vecteurs d’attaque contre le DAS subsistent donc, offrant aujourd’hui des garanties relativement faibles. Ces problèmes font toujours l’objet de recherches actives.
EigenLayer & MEV
Lors du sommet MEVconomics, Sreeram a parlé des applications d’EigenLayer dans la pile MEV. Autour des primitives cryptoeconomiques de stake et de slashing, les proposants peuvent implémenter quatre fonctionnalités, correspondant au troisième cas d’usage mentionné précédemment — l’engagement des validateurs.
Activation déclenchée par événement
Des protocoles comme Gelato peuvent réagir à des événements blockchain spécifiques : surveiller continuellement la chaîne, et dès qu’un événement se produit, déclencher des actions prédéfinies, généralement réalisées par des écouteurs/exécuteurs tiers.
On les appelle « tiers » car il n’y a aucun lien entre ces écouteurs/exécuteurs et les proposants qui traitent réellement l’espace bloc. Supposons qu’un écouteur/exécuteur déclenche une transaction, mais que celle-ci ne soit pas incluse dans un bloc (pour une raison quelconque) par le proposant — ce manquement ne peut pas être attribué, et donc aucune garantie économique déterministe ne peut être fournie.
Si cette tâche est assurée par un proposant participant au restaking, il peut s’engager de manière fiable à exécuter l’action. Si la transaction n’est finalement pas incluse dans le bloc, le proposant est puni. Cela offre une garantie bien plus forte que celle d’un exécuteur tiers.
Dans des applications pratiques (comme les protocoles de prêt), fixer un taux de sur-collatéralisation vise notamment à couvrir les fluctuations de prix sur une certaine durée. Cela est lié à la fenêtre temporelle avant liquidation : un taux de sur-collatéralisation plus élevé signifie une période de grâce plus longue. Si la majorité des transactions utilisent une réaction déclenchée par événement, avec une garantie forte du proposant, la volatilité du taux de sur-collatéralisation pourrait être limitée à quelques intervalles de blocs, réduisant ainsi le taux requis et améliorant l’efficacité du capital.
Enchères partielles d’espace bloc
Dans la conception actuelle de MEV-Boost, le proposant externalise entièrement l’espace bloc aux bâtisseurs (builders), recevant passivement et proposant l’ensemble du bloc soumis. Comparés aux proposants, beaucoup plus nombreux, les builders sont très peu nombreux, pouvant se coordonner pour censurer ou rançonner certaines transactions — car le proposant ne peut pas inclure lui-même des transactions dans MEV-Boost.
EigenLayer propose MEV-Boost++, une mise à niveau de MEV-Boost, introduisant une partie « Proposer-part » dans le bloc, où le proposant peut inclure des transactions arbitraires. Le proposant peut aussi construire un bloc alternatif B-alt, qu’il proposera si le relais ne libère pas le Builder_part. Cette flexibilité assure à la fois la résistance à la censure et résout les problèmes d’activité du relais.
Ceci va dans le même sens que la conception protocolaire — ePBS avec sa crList — visant à garantir que les nombreux proposants puissent participer à la composition du bloc, assurant ainsi la résistance à la censure.
Chiffrement seuil
Dans les solutions MEV basées sur le chiffrement seuil, un groupe de nœuds distribués gère les clés de chiffrement/déchiffrement. Les utilisateurs chiffrant leurs transactions, celles-ci ne seront déchiffrées et exécutées qu’après inclusion dans un bloc.
Toutefois, le chiffrement seuil repose sur l’hypothèse d’une majorité honnête. Si la majorité des nœuds est malveillante, les transactions déchiffrées pourraient ne pas être incluses dans le bloc. Un proposant ayant fait un restaking peut s’engager de manière fiable à inclure la transaction déchiffrée. S’il ne l’inclut pas, il sera puni. Bien sûr, si la majorité malveillante ne libère pas la clé de déchiffrement, le proposant peut proposer un bloc vide.
Enchères à long terme d’espace bloc
Les enchères à long terme d’espace bloc permettent aux acheteurs de réserver à l’avance l’espace bloc futur d’un validateur. Un validateur participant au restaking peut s’engager de manière fiable : s’il n’inclut pas la transaction de l’acheteur à l’échéance, il sera puni. Cette garantie d’accès à l’espace bloc a des cas pratiques utiles. Par exemple, les oracles doivent publier des prix régulièrement ; Arbitrum publie ses données L2 sur Ethereum L1 toutes les 1-3 minutes, Optimism toutes les 30 secondes à 1 minute, etc.
PEPC
Revenons maintenant à PEPC (Protocol-enforced Proposer Commitment), récemment largement discuté dans la communauté Ethereum. PEPC est en réalité une généralisation ou extension d’ePBS.
Analysons cette chaîne logique étape par étape.
-
Premièrement, prenons l’exemple de PBS hors-protocole MEV-Boost. Actuellement, MEV-Boost repose sur le mécanisme de slashing au niveau du protocole Ethereum : si un proposant signe deux en-têtes de bloc différents à la même hauteur, il est puni. Comme le proposant doit signer l’en-tête soumis par le relais, cela lie l’en-tête au proposant, donnant au relais une raison de croire que le bloc du builder sera proposé. Sinon, le proposant doit renoncer au slot ou proposer un bloc différent (ce qui entraîne un slashing). Ici, l’engagement du proposant est garanti par la sécurité économique du stake/slashing.
-
De façon similaire, un principe clé de la conception d’ePBS est la « safety de publication du builder honnête » : garantir qu’un bloc publié par un builder honnête sera proposé. ePBS, étant un PBS intégré au protocole, sera inclus dans la couche de consensus d’Ethereum, bénéficiant d’une garantie protocolaire.
-
PEPC est une extension d’ePBS. ePBS garantit que « le bloc du builder sera proposé ». En étendant cela à des enchères partielles, parallèles ou futures d’espace bloc, on permet aux proposants de faire davantage de choses — et le protocole garantit que ces engagements soient correctement exécutés.
Il existe une relation subtile entre PEPC et EigenLayer. On remarque aisément que les cas d’usage de PEPC ressemblent fortement à ceux d’EigenLayer concernant les producteurs de blocs. Toutefois, une différence majeure existe : un proposant participant au restaking pourrait théoriquement violer son engagement, bien qu’il subisse une sanction économique ; tandis que PEPC met l’accent sur le « Protocol-enforced », c’est-à-dire une imposition au niveau du protocole : si l’engagement n’est pas tenu, le bloc est invalide.
(PS : de façon approximative, on observe facilement qu’EigenDA ressemble à Danksharding, et MEV-Boost++ à ePBS — ces deux services sont comme des versions « opt-in » des conceptions protocolaires, des solutions plus rapides à déployer que les mises à jour protocolaires, alignées sur les évolutions futures d’Ethereum, et renforçant l’alignement avec Ethereum via le restaking.)
Ne pas surcharger le consensus d’Ethereum ?
Il y a plusieurs mois, l’article de Vitalik « Don’t Overload Ethereum Consensus » a été perçu par beaucoup comme une critique du Restaking. L’auteur pense qu’il s’agit plutôt d’un rappel ou d’un avertissement destiné à préserver le consensus social, centré sur le consensus social, et non une condamnation du restaking.
Au début d’Ethereum, l’attaque contre The DAO avait suscité de vives controverses, la communauté débattant intensément sur une éventuelle bifurcation dure. Aujourd’hui, l’écosystème Ethereum, incluant les Rollups, héberge déjà de nombreuses applications importantes. Il est donc crucial d’éviter des divisions profondes au sein de la communauté et de maintenir une cohérence du consensus social.
Hermione crée un layer 2 réussi et affirme que, parce que son layer 2 est le plus grand, il est intrinsèquement le plus sécurisé : en cas de bug entraînant un vol de fonds, les pertes seraient si importantes que la communauté n’aurait d’autre choix que de procéder à un fork pour récupérer les fonds des utilisateurs. Risque élevé.
Ce passage illustre parfaitement le propos. Aujourd’hui, la TVL totale des L2 dépasse les centaines de milliards de dollars. En cas de problème, les enjeux seraient immenses. Si la communauté devait proposer un fork dur et un rollback d’état, cela provoquerait une controverse majeure. Si vous et moi avions une somme importante dessus, que choisirions-nous — récupérer cet argent ou respecter l’inaltéabilité de la blockchain ? Le message de Vitalik est clair : les projets construits sur Ethereum doivent bien gérer leurs risques, sans chercher à mobiliser le consensus social d’Ethereum, ni lier étroitement leur survie au réseau Ethereum.
Revenons à EigenLayer : la gestion des risques passe par le fait que les AVS doivent définir des règles de slashing objectives, vérifiables on-chain et attribuables, afin d’éviter les désaccords. Par exemple : double signature sur Ethereum ; signature par un nœud léger dans un pont cross-chain sur un bloc invalide d’une autre chaîne ; ou encore la preuve de garde d’EigenDA mentionnée plus haut. Tous ces cas relèvent de règles de slashing claires.
Conclusion
EigenLayer prévoit de finaliser son lancement sur le réseau principal au début de l’année prochaine, avec le déploiement de son produit phare EigenDA. De nombreux projets d’infrastructure ont déjà annoncé leur collaboration avec EigenLayer. Nous avons discuté d’EigenDA, du MEV et de PEPC, et de nombreux débats passionnants continuent autour de ces différents cas d’usage. Le restaking devient l’une des grandes narrations dominantes du marché. Nous continuerons à suivre l’évolution d’EigenLayer et à partager nos analyses !
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
IOSG Ventures
