Tests de propriété généralisés pour les coffres-forts ERC4626

À mesure que DeFi grandit et mûrit, l'infrastructure évolutive et la composabilité sont au cœur des préoccupations des développeurs. Demandes de commentaires Ethereum (ou ERC) - boîtes à outils standardisées pour créer des applications basées sur Ethereum, telles que la norme de jeton largement utilisée ERC20 - jouent le rôle essentiel de fournir des directives cohérentes aux développeurs pour contribuer à l'écosystème sans partir de zéro. Plus tôt cette année, norme de coffre-fort à jetons ERC4626 a été créé pour encourager la compatibilité croisée entre les jetons porteurs de rendement. La standardisation des détails des implémentations peut également résoudre des problèmes urgents de composabilité, ce qui facilite l'intégration des protocoles et, en fin de compte, moins sujet aux erreurs.

Plusieurs projets DeFi ont déjà adopté la norme, cherchant à augmenter la composabilité de leurs coffres-forts, et nous prévoyons une adoption plus large dans tout l'écosystème. L'adaptation des coffres-forts existants provoque cependant des difficultés de croissance; de manière critique, certaines erreurs de mise en œuvre peuvent exposer de nouvelles cibles à l'attaque. Même de petites erreurs (aussi petites qu'une mauvaise interprétation de l'interface standard) peuvent avoir des conséquences importantes sur la sécurité et l'expérience utilisateur, soulignant la nécessité de davantage d'outils et de mesures de sécurité, en particulier dans un écosystème DeFi plus composable. 

Heureusement, les erreurs simples peuvent avoir des solutions relativement simples si elles sont détectées bien avant qu'elles ne soient exploitées (et idéalement avant même qu'elles ne soient déployées). À cette fin, nous avons publié Tests de propriété ERC4626 pour le fuzzing et l'exécution symbolique afin d'aider les constructeurs de coffres-forts à détecter les violations standard susceptibles de rompre les intégrations ou d'entraîner des vulnérabilités sur toute la ligne. Dans cet article, nous expliquons le problème de motivation, passons en revue notre approche et concluons avec quelques conseils pratiques.

Tout d'abord un petit rappel sur la norme ERC4626

Finalisé en mars, ERC4626 est la norme pour les coffres-forts tokenisés. Il a été introduit afin d'étendre le ERC20 standard (actuellement la base de centaines de jetons), encouragez la standardisation dans les coffres porteurs de rendement et assurez la composabilité des applications et des protocoles (par exemple, les agrégateurs de rendement) qui doivent interagir avec eux. Cela signifie que toute application construite sur un coffre-fort ERC4626 peut être facilement étendue pour fonctionner avec n'importe quel autre coffre-fort ERC4626. 

Les coffres à jetons permettent aux utilisateurs de déposer librement des actifs dans des actions de coffre-fort, puis de racheter ces actions pour retirer le principal et les intérêts du coffre-fort. Ces actions de coffre-fort sont des jetons ERC20 et peuvent donc être facilement échangées ou utilisées comme garantie pour emprunter d'autres actifs. Par exemple, les utilisateurs peuvent déposer leurs actifs dans des coffres Yearn pour créer des jetons yVault, qui peuvent ensuite être échangés sur Uniswap, jalonnés pour un rendement supplémentaire ou utilisés comme garantie pour les protocoles de prêt.

La logique commerciale pour générer et distribuer le rendement (et déterminer le prix de l'action) peut varier selon les implémentations. Afin de couvrir autant de coffres-forts que possible (dans le but de les rendre interopérables plutôt qu'identiques), la norme ERC4626 se concentre sur la description de l'interface utilisateur, laissant la plupart des détails de mise en œuvre non spécifiés. Cela permet des variations dans la logique métier tant que le coffre répond aux exigences spécifiques de l'interface et encourage interopérabilité entre de nombreux types d'applications et types de coffres-forts ERC4626.

Au fur et à mesure que de nouveaux coffres sont créés, nous nous attendons à les voir implémentés conformément à la norme ERC4626 dès le départ ; mais nous sommes actuellement dans une phase quelque peu transitoire, où les développeurs qui cherchent à tirer parti d'une plus grande composabilité devront mettre à jour les coffres-forts, les applications et les protocoles existants pour se conformer à la norme. Et à mesure qu'ils se modernisent, ils font face à un certain nombre de complexités et de défis. 

Les défis de la conformité aux normes (et les pièges de la non-conformité)

Suivre une nouvelle norme n'est pas toujours simple. Chaque coffre-fort ERC4626 doit fidèlement (et exactement) mettre en œuvre les exigences de la norme telles que décrites. Sinon, l'intégration des voûtes ERC4626 devient de plus en plus complexe pour tenir compte des différentes variations. Cette complexité rend les intégrations intrinsèquement sujettes aux erreurs ; et parce qu'ils ne sont pas suffisamment à l'épreuve du temps, ils peuvent entraîner des vulnérabilités de sécurité au fil du temps.

Les jetons ERC20 non standard (par exemple, Tether USD) nécessitent que de nombreux systèmes DeFi utilisent une bibliothèque supplémentaire (telle que SafeERC20) lors de l'exécution de transferts de jetons pour gérer en toute sécurité des comportements divergents (par exemple, ne rien renvoyer lorsqu'un transfert réussit au lieu de retourner true). Cela signifie que tout système interagissant avec ces jetons pourrait devenir vulnérable si le système n'est pas conçu pour gérer correctement les cas de "retours manquants". Ces scénarios peuvent potentiellement introduire un écueil de sécurité commun et augmenter les coûts globaux de développement et de maintenance (en tenant compte de la logique et des dépendances supplémentaires nécessaires pour atténuer les problèmes). La conformité à la norme est donc essentielle non seulement pour les implémentations individuelles, mais également pour la sécurité de l'ensemble de l'écosystème. Une vulnérabilité dans un seul système ou une dépendance peut entraîner des problèmes généralisés.

Idéalement, les normes seraient formellement spécifiées sans ambiguïté (par exemple, spécification formelle de l'ERC20), et chaque implémentation pourrait être formellement vérifiée par rapport à la spécification standard. En pratique, cependant, cela n'est pas facile à réaliser en peu de temps, en raison du coût et des efforts requis de la part de la communauté.

Présentation des propriétés ERC4626 exécutables pour identifier les problèmes de conformité 

Alors que nous travaillons vers un état idéal (chaque coffre-fort formellement vérifié par rapport à des spécifications formelles rigoureuses), nous avons écrit la norme ERC4626 propriétés pour détecter les divergences dans les détails subtils et faciles à manquer des exigences de la norme.  

Les développeurs Vault peuvent exécuter les tests pour détecter les violations potentielles des normes dans leurs implémentations avant le déploiement. Et les intégrateurs de coffres-forts peuvent vérifier si les coffres-forts donnés respectent la norme avant de les intégrer dans leur système. Les propriétés peuvent également être testées par rapport aux coffres-forts en direct déjà déployés sur le réseau principal, via des tests de fork du réseau principal. Tester les coffres en direct peut être utile, en particulier lorsque les coffres ont été déployés ou mis à niveau récemment, pour s'assurer que tous les paramètres système ont été définis correctement. 

Nous avons choisi des tests basés sur les propriétés - écrits en Foundry et prêts à être exécutés par son fuzzer - afin de rendre les propriétés exécutables (et donc testables). À l'avenir, ils pourront également être exécutés par des outils d'exécution symbolique ou de vérification de modèle pour vérifier formellement que le coffre-fort donné satisfait aux propriétés pour toutes les entrées et conditions possibles.

Nous avons écrit les propriétés pour qu'elles soient suffisamment générales pour être appliquées à un large éventail de coffres qui implémentent une logique métier différente. Nous n'avons utilisé que des fonctions d'interface publiques pour les rendre indépendantes des détails d'implémentation. (Cependant, en raison de cette restriction, certaines exigences standard faisant référence à des données internes spécifiques à la mise en œuvre ont été omises des propriétés.)

Par exemple, la propriété suivante correspond à l'une des exigences de la convertToShares() fonction, "NE DOIT PAS montrer de variations en fonction de l'appelant.” Compte tenu des deux adresses de compte et du montant, il fait appeler chacun des comptes convertToShares() avec le même montant et s'assure que les deux valeurs de retour sont égales. Cette propriété est indépendante des détails de mise en œuvre de convertToShares(), qui varie selon les coffres et doit être satisfait par tous les coffres qui implémentent ERC4626. Cette propriété peut être exécutée en fournissant des valeurs d'entrée spécifiques (pour les tests unitaires), de nombreuses entrées aléatoires (pour les tests fuzz) ou des valeurs symboliques (pour l'exécution symbolique et la vérification formelle). Il peut également être exécuté localement ou sur un fork du réseau principal (pour les tests d'intégration).

Cas d'utilisation : propriétés qui testent les erreurs d'arrondi

Les erreurs d'arrondi, par exemple, sont une classe importante de bogues (apparemment mineurs) qui peuvent avoir des implications sur les séries. La logique comptable sous-jacente de l'ERC4626, par exemple le calcul du nombre d'actions à frapper ou du montant des actifs à retirer, est mise en œuvre à l'aide de l'arithmétique à virgule fixe — les erreurs d'arrondi sont inévitables. Pour sécurité, cependant, la norme spécifie explicitement la direction d'arrondi préférée pour chaque fonction d'interface, tout en laissant les limites d'erreur non spécifiées et dépendantes de l'implémentation. Plus précisément, le deposit() ainsi que les redeem() les fonctions doivent retourner un sous-approximation de la valeur exacte, tandis que mint() ainsi que les withdraw() les fonctions doivent retourner un plus de -approximation. Par exemple, si le cours actuel de l'action (c'est-à-dire le montant des actifs par action) est de 2, alors deposit() avec 3 poids d'actifs ne devrait frapper que jusqu'à 1 poids d'actions (c'est-à-dire, floor(3/2)), tandis que withdraw() avec 3 wei d'actifs devrait brûler au moins 2 wei d'actions (c'est-à-dire, ceil(3/2)).

Nous avons écrit les propriétés liées à l'arrondi pour qu'elles soient indépendantes de la logique comptable sous-jacente en la traitant comme une boîte noire. Plus précisément, nous les avons formulées comme des propriétés dites « aller-retour », qui décrivent la relation entre deux fonctions opposées. Par exemple, la propriété suivante précise que le retrait d'actifs qui viennent d'être entiercés par la frappe de N actions doit brûler au moins N actions. En d'autres termes, personne ne peut réaliser un profit gratuit en convertissant des actifs et des actions de coffre-fort dans les deux sens en frappant et en retirant à plusieurs reprises.

En effet, nous avons constaté que plusieurs coffres-forts ERC4626 sur le réseau principal ne satisfaisaient pas à la propriété ci-dessus en raison d'erreurs d'arrondi. Cela signifie que n'importe qui pourrait gagner, par exemple, quelques satoshi BTC (1 satoshi ~= 0.02 cent au moment de la rédaction) simplement (et à plusieurs reprises) en frappant et en retirant, en vidant lentement le coffre-fort. Cela peut en fait générer des bénéfices sur les chaînes qui bénéficient de frais d'essence très bas (par exemple, Fantom), ou si le prix de l'actif devient suffisamment élevé à l'avenir.

Tester la norme ERC4626 dans la nature

Nous avons testé nos propriétés contre environ 100 coffres ERC4626 sur le réseau principal et avons trouvé de nombreux coffres qui ne respectaient pas les exigences standard, principalement en raison des erreurs d'arrondi (par exemple, en utilisant l'arrondi du sol là où le plafond est souhaité, comme nous l'avons décrit). Plus précisément, certains coffres-forts n'ont pas frappé le nombre exact d'actions demandé par le mint() fonction, bien que la norme exige explicitement this. Certains d'entre eux ont également émis une incohérence Deposit événement où les données enregistrées sont différentes de ce qui a été réellement frappé. A notre grande surprise, certaines voûtes n'ont jamais été frappées sur place ; au lieu de cela, ils placent simplement les demandes de menthe dans une file d'attente et les traitent plus tard dans un lot en tant que transaction distincte.

Bien que ces comportements divergents ne soient pas exploitables en soi, ils peuvent devenir vulnérables lorsqu'ils sont intégrés dans d'autres systèmes qui n'attendent que les comportements standards. Ces problèmes rendront l'intégration du coffre-fort beaucoup plus difficile, neutralisant potentiellement les efforts en cours et motivant la normalisation.

Utilisation de nos tests de propriétés et d'autres étapes concrètes vers la conformité aux normes

Suivre la norme avec précision peut empêcher les comportements divergents (idéalement avant qu'ils ne soient déployés). Nous espérons que nos propriétés vous aideront, ainsi que quelques éléments d'action supplémentaires. Pour ceux qui développent et/ou intègrent des coffres-forts ERC4626 :

• Nous vous recommandons fortement de gérer notre propriété tests contre vos voûtes. Ils trouveront rapidement les problèmes s'il y a des violations manifestes de la norme.
• Nous suggérons également de revoir notre propriétés pour vérifier votre compréhension des exigences de la norme et ajuster votre mise en œuvre en cas de divergence involontaire.
• Si votre coffre-fort doit s'écarter de la norme, nous vous recommandons de documenter clairement les comportements non standard, afin que d'autres puissent gérer correctement ces écarts lors de l'intégration à votre coffre-fort. Veuillez noter que cela doit être considéré comme un dernier recours.

***
Les coffres-forts ERC4626 ont le potentiel de devenir un élément de base important pour DeFi dans un avenir prévisible – et, pour des raisons de composabilité, il est important que les coffres-forts nouveaux et existants suivent la norme. De nouvelles implémentations suivront la norme, il n'y a donc pas de meilleur moment que le présent pour standardiser les coffres existants. 

Alors que nous travaillons vers un état idéal (où différents coffres sont uniformément composables), les tests de propriété ERC4626 peuvent être exécutés pour détecter plus facilement les violations standard dans les implémentations de coffre. Les tests de propriété (avec documentation et exemples) sont tous accessibles au public dans notre Github dépôt. Vos commentaires et contributions sont les bienvenus !

***
Les opinions exprimées ici sont celles du personnel individuel d'AH Capital Management, LLC (« a16z ») cité et ne sont pas les opinions d'a16z ou de ses sociétés affiliées. Certaines informations contenues ici ont été obtenues de sources tierces, y compris de sociétés de portefeuille de fonds gérés par a16z. Bien qu'elles proviennent de sources considérées comme fiables, a16z n'a pas vérifié ces informations de manière indépendante et ne fait aucune déclaration quant à l'exactitude actuelle ou durable des informations ou à leur pertinence dans une situation donnée. De plus, ce contenu peut inclure des publicités de tiers ; a16z n'a pas examiné ces publicités et n'approuve aucun contenu publicitaire qu'elles contiennent.

Ce contenu est fourni à titre informatif uniquement et ne doit pas être considéré comme un conseil juridique, commercial, d'investissement ou fiscal. Vous devriez consulter vos propres conseillers sur ces questions. Les références à des titres ou à des actifs numériques sont uniquement à des fins d'illustration et ne constituent pas une recommandation d'investissement ou une offre de fournir des services de conseil en investissement. En outre, ce contenu n'est ni destiné ni destiné à être utilisé par des investisseurs ou des investisseurs potentiels, et ne peut en aucun cas être invoqué pour prendre une décision d'investir dans un fonds géré par a16z. (Une offre d'investissement dans un fonds a16z ne sera faite que par le mémorandum de placement privé, le contrat de souscription et toute autre documentation pertinente de ce fonds et doit être lu dans son intégralité.) Tous les investissements ou sociétés de portefeuille mentionnés, référencés ou décrits ne sont pas représentatifs de tous les investissements dans des véhicules gérés par a16z, et rien ne garantit que les investissements seront rentables ou que d'autres investissements réalisés à l'avenir auront des caractéristiques ou des résultats similaires. Une liste des investissements effectués par des fonds gérés par Andreessen Horowitz (à l'exclusion des investissements pour lesquels l'émetteur n'a pas autorisé a16z à divulguer publiquement ainsi que des investissements non annoncés dans des actifs numériques cotés en bourse) est disponible sur https://a16z.com/investments /.

Les tableaux et graphiques fournis ici sont uniquement à des fins d'information et ne doivent pas être utilisés pour prendre une décision d'investissement. Les performances passées ne représentent pas les résultats futurs. Le contenu ne parle qu'à la date indiquée. Toutes les projections, estimations, prévisions, objectifs, perspectives et/ou opinions exprimées dans ces documents sont susceptibles d'être modifiées sans préavis et peuvent différer ou être contraires aux opinions exprimées par d'autres. Veuillez consulter https://a16z.com/disclosures pour des informations importantes supplémentaires