Risques de la réémission d'EigenLayer et meilleures pratiques
TechFlow SélectionTechFlow Sélection
Risques de la réémission d'EigenLayer et meilleures pratiques
Cet article aide les lecteurs à mieux maîtriser les risques correspondants tout en profitant des rendements.
Dédié à des analyses Web3 approfondiesAvec la montée en popularité du Restaking, de nombreux projets basés sur EigenLayer ont vu le jour. Le concept de Restaking vise à partager la confiance issue de la couche de mise en gage (staking) d'Etherum Beacon entre différents projets, en permettant aux utilisateurs de réutiliser leurs parts mises en jeu pour générer davantage de rendements, tout en offrant à ces projets une sécurité et une confiance équivalentes à celle de la couche de consensus ETH Beacon.
Afin d’aider les utilisateurs à mieux comprendre les risques d’interactions entre différents projets de Restaking, l’équipe de sécurité Cobo a mené une étude approfondie sur les principaux protocoles de Restaking disponibles sur le marché ainsi que sur les actifs LST dominants, en identifiant et synthétisant les risques associés, afin que chacun puisse bénéficier des rendements tout en maîtrisant au mieux les risques encourus.
-
Note : Les conclusions établies par l'équipe de sécurité Cobo sont basées sur des données disponibles avant 00h00 UTC le 5 février 2024.
Aperçu des Risques
Actuellement, la plupart des protocoles de Restaking disponibles sur le marché sont construits sur EigenLayer. Pour un utilisateur, participer au Restaking implique de s'exposer aux risques suivants :
Risque contractuel
-
La participation au Restaking nécessite aujourd'hui une interaction avec les contrats du projet. L’utilisateur supporte donc le risque qu’un contrat soit attaqué ;
-
Les fonds des projets construits sur EigenLayer finissent tous par être déposés dans les contrats du protocole EigenLayer. En cas d’attaque réussie contre les contrats EigenLayer, les fonds associés à ces projets seraient également perdus ;
-
EigenLayer propose deux types de Restaking : le Restaking en ETH natif et celui en LST. Dans le cas du Restaking en LST, les fonds sont directement stockés dans les contrats EigenLayer. En revanche, pour le Restaking en ETH natif, les fonds restent sur la Beacon Chain d’ETH. Cela signifie que les utilisateurs participant via LST pourraient subir des pertes dues à un risque contractuel sur EigenLayer ;
-
Les équipes projet disposent de permissions critiques pouvant, dans certains cas, leur permettre de détourner les fonds des utilisateurs.
Risque lié aux LST
-
Les jetons LST peuvent se désancrer ou voir leur valeur altérée suite à une mise à jour ou une attaque du contrat LST, entraînant des pertes pour les détenteurs.
Risque de retrait
-
À l’exception d’EigenLayer, les principaux protocoles de Restaking actuels ne prennent pas en charge le retrait des fonds. Si les équipes projet n’ajoutent pas cette fonctionnalité par mise à jour contractuelle, les utilisateurs ne pourront jamais récupérer leurs actifs directement, et devront passer par le marché secondaire pour obtenir de la liquidité.
Sur la base des risques listés ci-dessus, l’équipe de sécurité Cobo a réalisé une analyse systématique des principaux protocoles de Restaking disponibles actuellement, et a identifié plusieurs constats clés :
-
Faible niveau d’achèvement : la majorité des projets n’ont pas encore implémenté la logique de retrait ;
-
Risque centralisé : les actifs des utilisateurs sont finalement sous le contrôle d’un portefeuille multisignature. Les équipes projet conservent donc un certain potentiel de « Rug Pull » ;
-
Dans ce contexte, toute malversation interne ou perte des clés du multisig pourrait entraîner une perte d’actifs.
Pour rendre ces résultats plus accessibles, l’équipe de sécurité Cobo a organisé et classé les informations recueillies afin de faciliter leur consultation, comme indiqué ci-dessous :
Étant donné qu’EigenLayer constitue la base de tous ces projets, outre les éléments mentionnés dans le tableau, les points suivants doivent également être pris en compte par les utilisateurs :
-
Les contrats d’EigenLayer actuellement déployés sur le réseau principal n’ont pas encore intégré toutes les fonctionnalités décrites dans leur livre blanc (AVS, slash). La fonctionnalité de slash dispose uniquement d’une interface implémentée, sans logique complète opérationnelle. D’après le code du contrat, le mécanisme de slash est actuellement déclenché par le propriétaire (owner) du contrat StrategyManager (droit d’administration du projet), ce qui constitue une approche fortement centralisée ;
-
Lors d’un processus de Restaking en ETH natif via EigenLayer, l'utilisateur doit non seulement créer un contrat EigenPod pour gérer ses fonds, mais aussi exécuter son propre nœud Beacon chain, assumant ainsi le risque d’être soumis à un slash par la Beacon chain. Il est donc conseillé aux utilisateurs de choisir un fournisseur de service de nœud fiable. Par ailleurs, étant donné que les ETH sont conservés sur la Beacon chain, le retrait des fonds nécessite non seulement une action de l’utilisateur, mais aussi l’intervention du fournisseur de nœud pour extraire les fonds de la Beacon chain — autrement dit, le processus de sortie requiert l’accord des deux parties ;
-
Étant donné qu’EigenLayer n’a pas encore mis en œuvre de manière complète les mécanismes AVS et de slash, l’équipe de sécurité Cobo recommande vivement aux utilisateurs de ne pas activer la fonction « delegate » sur le protocole EigenLayer sans une compréhension approfondie des risques associés, faute de quoi ils pourraient subir des pertes financières.
En outre, après examen du code, certains projets présentent des vulnérabilités supplémentaires pouvant compromettre la sécurité des fonds des utilisateurs. Cobo a immédiatement contacté les équipes concernées dès la découverte de ces risques. Voici quelques points identifiés ainsi que les retours obtenus :
EigenPie
-
Tous les contrats du protocole sont actuellement mis à niveau, avec un droit de mise à niveau géré par un Safe Gnosis 3/6. Toutefois, pour les contrats de jetons MLRT (cbETH, ethX, ankrETH), le droit de mise à niveau appartient à une adresse EOA.
Cobo a contacté l'équipe Eigenpie avant publication. Le projet a confirmé qu'il transférerait dans les 24 heures le droit de mise à niveau de tous les contrats MLRT vers un portefeuille multisignature.
KelpDAO
-
Lors du dépôt, le calcul des parts (share) attribuées à l’utilisateur repose sur une estimation de la valeur du share, où le paramètre rsETHPrice doit être mis à jour manuellement via un oracle. À l’exception de stETH, les prix utilisés proviennent directement du prix « share » des contrats correspondants. Pour stETH, un taux de conversion fixe 1:1 est appliqué. Lorsque stETH est négocié à escompte sur le marché secondaire, cela crée un espace d’arbitrage pendant le dépôt.
KelpDAO a répondu le 5 février que le taux de conversion du contrat Lido est défini à 1 stETH = 1 ETH. Comme KelpDAO n’offre pas encore la fonctionnalité de retrait, les arbitragistes ne peuvent pas exploiter cette faille. Concernant ce problème, l’équipe prévoit d’ajouter un mécanisme de circuit-breaker lors du lancement du retrait, permettant de comparer le prix du marché de stETH à son prix contractuel, et d’appliquer des garde-fous en cas d’écart significatif.
Renzo
-
Le contrat OperatorDelegator a pour rôle de router les fonds du protocole vers EigenLayer selon différents ratios. Toutefois, lors de la configuration des OperatorDelegator, le protocole ne vérifie pas que la somme des ratios n’excède pas 100 %, ce qui peut conduire à des configurations erronées (ex. : OperatorDelegator-1 à 70 % et OperatorDelegator-2 à 70 %). Ce problème affecte principalement le retrait des fonds. Étant donné que la logique de retrait n’est pas encore complètement implémentée, il est impossible d’évaluer précisément l’impact sur le capital initial.
L’équipe Renzo a indiqué que dans ce cas particulier, les fonds seraient envoyés ou retirés depuis un mauvais contrat OperatorDelegator. Bien que ce problème technique puisse entraîner une répartition incorrecte des fonds entre opérateurs, il n’affecte ni le calcul de la valeur totale verrouillée (TVL) ni la sécurité des fonds. L’équipe Renzo prévoit de corriger ce défaut lors d’une future mise à jour contractuelle.
Outre les risques liés aux protocoles eux-mêmes, les risques associés aux LST dans le processus de Restaking ne doivent pas être négligés. L’équipe de sécurité Cobo a également mené une étude sur les principaux jetons LST du marché, dont les résultats sont présentés ci-dessous pour une meilleure lisibilité :
Comment réduire efficacement les risques liés au Restaking ?
Le Restaking est un concept émergent qui, tant au niveau contractuel que protocolaire, n’a pas encore été suffisamment éprouvé par le temps. Outre les risques listés ci-dessus, d’autres risques inconnus pourraient subsister. Existe-t-il alors un guide d’interaction relativement sûr permettant de réduire efficacement les risques durant le processus ?
Sur la base des conclusions actuelles, l’équipe de sécurité Cobo a élaboré un parcours d’interaction relativement sécurisé.
Allocation des fonds
Pour les utilisateurs investissant de gros montants, participer directement au Native ETH Restaking sur EigenLayer représente un choix judicieux. En effet, dans le cas du Restaking en ETH natif, les ETH déposés ne sont pas stockés dans les contrats EigenLayer, mais directement sur la Beacon Chain. Même dans le pire des cas (attaque contractuelle), les attaquants ne pourraient pas accéder immédiatement aux actifs des utilisateurs.
Pour ceux qui souhaitent également investir de grands montants mais veulent éviter les longs délais de retrait, l’utilisation de stETH comme actif de participation directement sur EigenLayer constitue une alternative plus sûre.
Pour les utilisateurs cherchant à générer des revenus supplémentaires, il est possible, en fonction de sa tolérance au risque, d’allouer une partie de ses fonds à des projets construits sur EigenLayer tels que Puffer, KelpDAO, Eigenpie ou Renzo. Toutefois, il convient de noter que ces projets n’ont pas encore implémenté la logique de retrait. Les participants doivent donc prendre en compte le risque de sortie et évaluer la liquidité des LRT correspondants sur le marché secondaire lors de leurs investissements.
Configuration de surveillance
Les projets listés ici disposent tous de la capacité de mise à jour contractuelle et de suspension. De plus, les multisigs projet peuvent exécuter des opérations sensibles. Pour les utilisateurs avancés, il est recommandé de configurer une surveillance contractuelle afin de détecter tout changement de contrat ou toute opération critique effectuée par l’équipe projet.
Par ailleurs, les équipes ou utilisateurs souhaitant investir des ETH dans ces projets peuvent utiliser Cobo Argus, un robot automatisé conditionnel pour portefeuilles Safe multisignatures, combiné à une configuration d’autorisation unique. Sur la base de l’évolution de la TVL du pool, des fluctuations du prix de l’ETH ou des mouvements de gros détenteurs (whales), il est possible de définir automatiquement des dépôts vers EigenLayer et divers protocoles de Restaking.
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
Cobo
