« HComment un solde de jetons augmente-t-il chaque bloc sans transaction ? «
C’est la question qui m’a conduit à une profonde dissection des contrats intelligents de l’AAVE et m’a amené au point de… eh bien… de me sentir un peu stupide. Cela va être une explication technique de la façon dont AAVE fonctionne sous le capot pour vous donner des soldes de jetons LP mis à jour en direct, et comment cela pourrait tout aussi facilement être utilisé de manière malveillante ou non sécurisée. À la fin, vous devriez savoir comment implémenter en toute sécurité la même fonctionnalité dans vos contrats ERC-20.
J’écris ceci, non pas comme un guide étape par étape pour les développeurs qui n’aiment pas réinventer la roue (bien que cela puisse aussi être cela), mais comme un coup de chapeau littéraire à l’incroyable ingénierie de l’équipe AAVE . Je ne suis en aucun cas associé à eux, bien que j’aie interagi avec leurs contrats dans mon propre travail. Leur jeton LP de mise à jour en direct (alias: aToken) offre une expérience utilisateur fluide, pratique et agréable. Qui n’aime pas voir le solde de son compte augmenter sous ses yeux ?
À ce stade, je devrais faire une pause pour clarifier : je ne suis pas sûr de l’origine de cette structure de jeton de calcul de rendement. Je l’ai découvert pour la première fois dans la collection de contrats de l’AAVE, bien que l’idée ait pu être empruntée à un autre. Veuillez laisser un commentaire si tel est le cas, afin que le crédit puisse être attribué de manière appropriée.
Introduction terminée. Commencer la plongée :
Nous commencerons peut-être par les deux fonctions les plus appelées dans le dictionnaire des développeurs dApp : balanceOf() et totalSupply(). L’AAVE explique ici que ces fonctions sont appelées pour renvoyer respectivement « … le nombre de jetons détenus… » et « … le nombre de jetons existants… ». Aucun choc pour ceux d’entre nous qui y sont habitués, et les docs ne montrent aucune anomalie.
Si l’aToken de l’AAVE renvoie un nombre qui s’incrémente continuellement chaque fois que balanceOf() est appelé, qui paie le gaz ? Quelque chose ne va pas (jeu de mots).
Pour mieux comprendre, voici un extrait du contrat aToken actuel de l’AAVE (v2) via GitHub :
À première vue, nous examinons la même fonction balanceOf(), avec la même utilisation qu’auparavant. À y regarder de plus près, il se passe beaucoup plus de choses ici. Je soulignerai d’abord l’utilisation de la méthode « override() ». Cela empêche le contrat d’utiliser la logique standard ERC20 balanceOf() et, à la place, exécute cette fonction lorsqu’elle est appelée.
« OK cool. La logique est différente bien que l’appel de fonction soit le même. Comment renvoie-t-il une valeur dynamique sans consommer de gaz ? »
Peut-être que la question précédente était un mensonge. C’est la question qui m’a vraiment creusé la tête : comment un appel de fonction, qui est en lecture seule, peut-il renvoyer une valeur différente à chaque bloc ? Pour répondre à cette question, nous devons d’abord comprendre le système d’indexation de l’AAVE pour le calcul des taux d’intérêt prêt/emprunt (APY et API, en conséquence).
Cet « Indice de liquidité » est recalculé chaque fois qu’un pool est mis à jour, que ce soit avec un nouveau dépôt de liquidité, un remboursement de prêt ou une liquidation de collatéral. Fonctionnellement, cela est en fait calculé en tenant compte du temps. Après tout, APY et API sont annuel calculs. Les détails de ceci sortent du cadre de cette analyse, mais pour être complet, sachez simplement que le temps est un autre facteur qui maintient l’indice en croissance en plus des transactions.
Ainsi, l’indice de liquidité est une représentation vivante et respirante de la relation des prêteurs et des emprunteurs de l’AAVE avec leurs réserves de liquidités relatives. Pour comprendre comment l’indice de liquidité est utilisé pour calculer les soldes aToken, nous devons comprendre la fonction scaledBalanceOf() du contrat aToken, que l’AAVE explique ici : https://docs.aave.com/developers/the-core-protocol/ tokens#scaledbalanceof
En résumé, lorsqu’un dépôt est effectué, il est stocké en tant que « Scaled Balance » de l’utilisateur, c’est-à-dire en tant que représentation à la fois de la valeur déposée et du marché du pool AAVE au moment du dépôt. Comme je ne suis pas du genre à faire de l’algèbre avancée, je vais le décomposer à mon rythme :
Montant du dépôt / Indice de liquidité actuel = Solde échelonné
Alors maintenant que nous avons la valeur réelle stockée dans les contrats de l’AAVE pour le solde d’un utilisateur, comment trouver le solde actuel à un moment donné ? Inversez simplement la formule :
Solde échelonné * Indice de liquidité actuel = un solde symbolique
Étant donné que l’indice de liquidité ne fait qu’augmenter, le solde aToken du compte ne peut jamais baisser sans un retrait. Cela rend l’ensemble du système d’indexation unidirectionnel, et par conséquent, plus simple et plus sécurisé.
« Explication du calcul sans gaz, s’il vous plaît ! »
Maintenant que toutes les pièces sont ici, rassemblons-les. Comme vous l’avez peut-être remarqué lors de l’instantané de la fonction balanceOf() du contrat aToken, la portée de la fonction est limitée à « vue » (comme devraient l’être les fonctions de vérification de l’équilibre). Parfois, j’oublie que, simplement parce qu’une fonction est limitée à la lecture seule, elle peut toujours calculer une arithmétique complexe, en effectuant des appels croisés si nécessaire, tant qu’elle n’est pas utilisée pour mettre à jour l’état. Eh bien, c’est ce qui se passe.
Pour obtenir le solde le plus récent, le contrat aToken doit calculer le courant Indice de liquidité à multiplier par « super.balanceOf » (référence au soldeOf() du contrat IncentivizedERC20 sous-jacent), qui est également le solde échelonné. Une fois l’index retourné (encore une fois, via un calcul en lecture seule), sans le stocker, le solde actuel du compte peut être récupéré.
Et voilà; Comment AAVE a piraté notre compréhension des jetons ERC-20 pour créer quelque chose d’incroyable !
« Quels sont les risques de sécurité possibles liés au contournement des fonctions ? »
Maintenant que nous savons comment c’est fait, nous pouvons voir comment cela peut être utilisé non seulement pour rendre les interactions ERC20 plus conviviales, mais aussi les dangers d’assumer la sécurité de toute fonction nommée balanceOf(), transfer(), ou tout autre la norme. Inspectez toujours l’intégrité du contrat au lieu de passer aveuglément un appel web3.
Un autre problème possible est algorithmique – et si le contrat d’AAVE générait plus de jetons pour un utilisateur qu’il n’en était réellement dû ? En utilisant ce modèle, nous avons besoin que tous les facteurs affectant les soldes des utilisateurs soient inclus dans le calcul de l’indice de liquidité. C’est pourquoi des tests exhaustifs doivent toujours être effectués avant qu’un contrat ne soit rendu public.
Rejoignez Coinmonks Telegram Channel et Youtube Channel pour en savoir plus sur le trading et l’investissement crypto
