ERC-4626 — Le nouveau standard pour les vaults DeFi tokenisées
TechFlow SélectionTechFlow Sélection
ERC-4626 — Le nouveau standard pour les vaults DeFi tokenisées
ERC-4626 est une norme qui améliore les spécifications techniques des vaults générant des rendements, en fournissant une API standard pour les vaults de rendement représentant des parts d'un unique jeton ERC-20 sous-jacent.
Dédié à des analyses Web3 approfondiesRédaction : Sina Pilehchiha
Traduction : TechFlow
TLDR : ERC-4626 est une norme pour les vaults tokenisés.
Avant l'introduction de l'ERC-4626, chaque vault possédait ses propres spécifications et détails d'implémentation. Cela rendait l'intégration difficile, sujette aux erreurs et gourmande en ressources.
L'ERC-4626 cherche à résoudre ce problème via une spécification standardisée afin de réduire la charge d'intégration et de créer des modèles d'implémentation plus cohérents et robustes, à l'image de l'ERC-20.
Qu'est-ce que l'ERC-4626 ?
L'ERC-4626 est une norme qui améliore les paramètres techniques des vaults générant des rendements. Elle fournit une API standardisée pour les vaults à rendement représentant des parts d'un unique jeton sous-jacent ERC-20.
Les vaults tokenisés sont devenus un modèle extrêmement courant dans la DeFi. De nombreux dApps tels que les agrégateurs de rendements, les marchés de prêt ou les dérivés de mise utilisent et dépendent largement des vaults tokenisés. Parmi les exemples figurent Yearn et Balancer. En tant qu'agrégateur de rendement, le vault Yearn permet aux utilisateurs de déposer des actifs numériques et de percevoir des revenus. Balancer, quant à lui, est un gestionnaire automatisé de portefeuilles et fournisseur de liquidités dont la logique métier repose fondamentalement sur un vault. Ces vaults gèrent des jetons dans divers pools, tout en séparant la gestion des jetons de la logique propre au pool.
Les protocoles renforcent leur liquidité et leur flexibilité en tokenisant leurs vaults. Les vaults tokenisés peuvent être facilement échangés et utilisés comme actifs sur les plateformes DeFi. En outre, ils permettent de créer des produits financiers diversifiés et interconnectés. Ce paradigme, souvent appelé « Lego monétaire », est largement plébiscité par l'industrie.
Toutefois, une composable sans adaptation ou standardisation adéquate pose des défis. Non seulement cela rend difficile pour les développeurs le respect de standards industriels comme l'ERC-20, mais cela peut également induire en confusion les nouveaux venus. Sans adaptation ou standardisation appropriée, il devient ardu d'examiner les nouvelles modifications et de valider les détails d'implémentation lors des intégrations.
C’est précisément ce problème que l’ERC-4626 vise à résoudre, en simplifiant les intégrations et en permettant aux acteurs DeFi d’adopter finalement une norme unifiée, plus sûre et robuste pour les vaults. Cela réduit en retour la surface d’attaque potentielle des protocoles, tout en facilitant l’intégration de jetons entre plusieurs protocoles.
Quels problèmes de sécurité l'ERC-4626 peut-il prévenir ?
En fournissant une norme unifiée, l'ERC-4626 accélère la construction d'intégrations inter-protocoles. Une norme familière et homogène est également plus facile à comprendre pour les développeurs, réduisant ainsi les risques d'erreurs de codage. Cela contribue à prévenir les problèmes de composable. La standardisation évite aussi la duplication des efforts, car la communauté n’a besoin de concevoir un vault qu’une seule fois, plutôt que de le faire individuellement pour chaque protocole. Comme ces conceptions comportent fréquemment des erreurs, cela permet d’éviter de reproduire des défauts structurels déjà connus mais répandus.
Nous allons ici présenter deux études de cas afin d'illustrer les types de problèmes que l'ERC-4626 peut aider à prévenir.
L'incident Rari Capital
Rari Capital s'est fait voler environ 11 millions de dollars de jetons, soit 60 % de toutes les fonds des utilisateurs du pool Ethereum de Rari Capital.
Globalement, l'attaque contre Rari Capital résultait d'une implémentation inter-protocole non sécurisée. Son pool Ethereum plaçait de l'ETH dans le contrat de jeton ibETH d'Alpha Finance comme stratégie de rendement. Cette stratégie spécifique suivait la valeur du taux de change ibETH/ETH via certaines fonctions contractuelles (comme ibETH.totalETH / ibETH.totalSupply), pouvant produire des résultats erronés dans ce scénario d'attaque. Par exemple, lors de l'appel de la fonction ibETH.work(), la valeur de la dette pouvait être artificiellement gonflée.
L'attaquant n'avait qu'à appeler successivement les fonctions deposit et withdraw du contrat RariFundManager pour vider complètement le Rari Fund Manager. Ces fonctions doivent récupérer le solde du pool afin de calculer le nombre de jetons REPT à distribuer à l'appelant, ou le montant d'ETH à verser, opération qui invoque la fonction getBalance du pool Alpha, puis le contrat ibETH et sa fonction totalETH. Rari ignorait la possibilité de manipuler cette fonction.
Le contrat ibETH dispose d'une autre fonction : ibETH.work. Cette fonction peut appeler n'importe quel contrat spécifié par l'utilisateur, rendant ainsi les fonctions deposit et withdraw de Rari réentrantes et susceptibles d'être appelées plusieurs fois.
La fonction work est payable, ce qui signifie qu’un utilisateur peut contrôler via cette fonction la quantité d’ETH dans le contrat ibETH, modifiant ainsi la valeur retournée par la fonction totalETH. Pire encore, work permet également d’appeler n’importe quel autre contrat, tel que RariFundManager.
Grâce à cette fonction, l’attaquant pouvait envoyer à nouveau de l’ETH, augmenter le montant totalETH dans le contrat ibETH, tout en appelant simultanément la fonction withdraw du contrat RariFundManager pour retirer davantage d’actifs.
Cet incident met en lumière les risques considérables liés à l’intégration insuffisante et aux conceptions incompatibles dans les contrats DeFi. Il souligne combien une norme comme ERC-4626 pourrait prévenir de telles attaques en ajoutant des couches essentielles de sécurité et de prévisibilité, favorisant ainsi un comportement uniforme et une meilleure compréhension mutuelle.
L'incident Cream Finance
Cream Finance a subi une attaque sophistiquée exploitant deux faiblesses fondamentales de la plateforme : un oracle hybride manipulable et une offre illimitée de jetons. L’élément clé de l’attaque consistait à manipuler l’oracle hybride, affectant ainsi la valeur perçue du jeton yUSD. Lorsque l’attaquant a envoyé une grande quantité de jetons Yearn 4-Curve au vault yUSD, il a modifié le taux de change rapporté par le vault, impactant par conséquent la valeur perçue du yUSD par l’oracle.
La principale leçon à tirer est qu’un oracle de prix solide et inviolable est crucial pour la stabilité des protocoles DeFi. Un oracle basé sur un prix moyen pondéré dans le temps (TWAP) pourrait aider à prévenir de telles attaques, car il est plus résistant aux manipulations brutales de prix.
Ces problèmes, ainsi que d'autres schémas de conception fragiles, peuvent être atténués grâce à une adoption prudente et rigoureuse de l'ERC-4626.
Risques de sécurité potentiels dans l'ERC-4626
L'utilisation de nouveaux protocoles implique toujours des compromis. Pour les vaults tokenisés, leur intégration dans des contrats intelligents peut poser des problèmes potentiels nécessitant une attention particulière.
Gestion des jetons feeOnTransfer
Si un vault vise à supporter les jetons feeOnTransfer, vérifiez que les montants et parts dans le vault restent dans les plages attendues lors du transfert d'actifs.
Utilisation appropriée de la variable decimals
Bien que les fonctions convertTo ne devraient pas avoir besoin de la variable decimals du vault EIP-4626, il est fortement recommandé, lorsque possible, d'imiter le nombre de décimales du jeton sous-jacent. Cette pratique aide à éliminer les sources potentielles de confusion et simplifie l'intégration pour divers fronts et utilisateurs hors chaîne.
Arrondis
Conformément à la spécification, les concepteurs de vaults doivent être conscients qu'il faut appliquer des directions d'arrondi spécifiques et opposées dans différentes méthodes variables et de consultation, car il est plus sûr, lors des calculs, de privilégier le vault plutôt que ses utilisateurs :
-
S’il calcule le nombre de parts à émettre à un utilisateur en échange d’un certain montant de jetons sous-jacents, ou s’il transfère à un utilisateur un montant donné de jetons sous-jacents correspondant à des parts spécifiques, l’arrondi doit être effectué vers le bas.
-
S’il calcule combien de parts un utilisateur doit fournir pour obtenir un certain montant de jetons sous-jacents, ou combien de jetons sous-jacents un utilisateur doit fournir pour obtenir un certain nombre de parts, l’arrondi doit être effectué vers le haut.
Le cas où la direction d'arrondi est ambiguë concerne la fonction convertTo. Afin d'assurer une cohérence entre toutes les implémentations de vaults EIP-4626, il est précisé que ces fonctions doivent toujours arrondir vers le bas. Les intégrateurs peuvent imiter eux-mêmes une version arrondie vers le haut, par exemple en ajoutant un wei au résultat.
La quantité d'actifs sous-jacents qu'un utilisateur reçoit en rachetant ses parts dans le vault (previewRedeem) peut différer fortement de la quantité nécessaire pour frapper le même nombre de parts (previewMint). Ces différences peuvent être minimes (par exemple dues à des erreurs d'arrondi) ou importantes (si le vault applique des frais de retrait ou de dépôt). Les intégrateurs doivent donc utiliser la fonction d'aperçu la plus adaptée à leur cas d'usage et ne jamais supposer qu'elles sont interchangeables.
Remplacement des fonctions principales
Pour implémenter ou étendre des fonctionnalités, il est conseillé d'utiliser des crochets existants plutôt que de modifier les fonctions principales. Cette approche permet un suivi plus simple, facilitant les tests et audits du code.
Parts nulles
La spécification initiale de l'ERC-4626 ne précise pas comment gérer le cas extrême où aucun part n’existe dans le vault, ni si le vault doit continuer à fonctionner normalement ou annuler les transactions. Cela pourrait constituer une source de confusion et d'erreur.
Le vault comme oracle de prix
Concernant les risques d'attaque par manipulation de prix via les oracles, les valeurs retournées par les méthodes preview doivent être aussi proches que possible de la réalité. Elles peuvent donc être manipulées en modifiant les conditions sur la blockchain et ne sont pas toujours sûres à utiliser comme oracle de prix. La spécification ERC-4626 autorise des méthodes convert et totalAssets imprécises, permettant ainsi de concevoir des oracles de prix robustes. Par exemple, lors de la conversion entre actifs et parts, l'utilisation d'un prix moyen pondéré dans le temps (TWAP) pour implémenter la méthode convert est une bonne pratique.
Problèmes d'implémentation spécifique
Avant toute intégration supplémentaire, les intégrateurs doivent examiner l'implémentation de tout vault tokenisé, car il peut exister des implémentations malveillantes qui semblent conformes à l'interface mais dont les fonctions principales reposent sur des spécifications entièrement différentes.
Accès direct par une adresse externe (EOA)
Si un vault est destiné à être utilisé directement par une adresse externe (EOA), son implémentation doit inclure des fonctionnalités capables de gérer les pertes de glissement ou les limites inattendues de dépôt/retrait. Contrairement aux contrats intelligents, une EOA ne dispose pas de mécanisme de protection contre les échecs transactionnels ; si les fonctions principales ne garantissent pas une sortie exacte, elle ne peut pas annuler la transaction.
Extension des vaults
À mesure que de plus en plus d’acteurs adoptent la norme ERC-4626, nous assisterons à davantage d’extensions mises en œuvre pour cette norme. Par exemple, Superform a développé une extension expérimentale Multi-vault permettant différents calculs au sein d’un même contrat de vault. Naturellement, plus une implémentation s’écarte de la norme initiale, plus elle risque d’introduire de nouvelles vulnérabilités. Développeurs et auditeurs devront choisir selon leur cas d’usage le meilleur compromis entre fonctionnalités et risques.
Il convient de noter que ce ne sont pas les petites ajouts individuels par protocole qui causent des catastrophes, mais bien leur cumul lorsqu’ils sont intégrés ensemble.
Les vecteurs d'attaque potentiels mentionnés ci-dessus constituent certains des points fréquemment discutés autour de la norme ERC-4626. Avec une adoption croissante, nous explorerons sans aucun doute davantage de cas d'usage et de scénarios d'intégration appropriés aux vaults ERC-4626.
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
zellic
