Aave Labs a précisé que sa mise à jour de sécurité proposée V3.8 préserverait les liquidations de flash-loans. La réponse du 23 octobre explique comment un garde de réentrance interagirait avec les intégrations existantes.
TL;DR : Le dispositif V3.8 proposé par Aave exclut les points d'entrée des flash-loans. L'approbation par la gouvernance et les audits de sécurité restent en attente.
La proposition, publiée le 21 octobre, ajoute une protection aux opérations du Pool. Ces protections limitent la capacité d'un rappel externe à réentrer dans les fonctions protégées du contrat avant la fin d'un appel précédent. Aave Labs indique que flashLoan() et flashLoanSimple() seraient exclus, permettant à leurs rappels de continuer à invoquer des actions du Pool, y compris des liquidations.
Pourquoi la rappel est important
Un contrat intelligent recevant un flash loan a besoin de temps au sein de la transaction pour effectuer une action avec les actifs empruntés. Le guide du développeur d'Aave décrit une séquence dans laquelle le Pool transfère les actifs, appelle le contrat récepteur, puis vérifie les conditions de règlement.
Pour un prêt flash simple, le récepteur doit mettre à disposition le montant emprunté ainsi que les frais requis pour le remboursement. Si la transaction ne peut pas remplir ses conditions, elle est annulée. L'interface plus large des prêts flash peut couvrir plusieurs actifs et, dans les conditions autorisées, ouvrir une position de dette garantie par des collatéraux.
Ces mécanismes expliquent pourquoi la portée d'un gardien est importante. Une intégration de liquidation peut devoir emprunter un actif, rembourser une position non saine et terminer le reste de sa transaction avant le règlement. Bloquer indistinctement chaque interaction ultérieure avec le Pool perturberait cette séquence.
La question de conception importante est de déterminer quelles routes de retour vers le protocole sont intentionnelles. Une limite de sécurité utile doit prendre en compte les schémas de transaction sur lesquels les intégrations reposent, y compris les appels effectués après que les actifs ont quitté le Pool mais avant que le remboursement ne soit vérifié.
Un verrou de longueur de transaction
La mise en œuvre proposée utilise le stockage temporaire introduit via Ethereum’s EIP-1153. Ce stockage reste disponible pendant une transaction et est supprimé à la fin de celle-ci. Il peut donc transporter un état de verrouillage temporaire pour suivre si une opération protégée est déjà en cours.
La spécification identifie les verrous de réentrance comme un cas d'utilisation et explique pourquoi le stockage temporaire peut coûter moins cher que l'écriture de l'état temporaire dans un stockage permanent. Pour un protocole DeFi largement utilisé, la question de conception inclut le coût imposé aux transactions ordinaires ainsi que la protection apportée par le dispositif de protection.
Le chemin proposé par Aave inclut des commentaires, un vote Snapshot, un examen de sécurité et une proposition d'amélioration sur chaîne. Certora et d'autres réviseurs sont attendus pour évaluer les modifications avant cette dernière étape.
Pour les intégrateurs sur Ethereum et autres réseaux concernés, cette clarification fournit un point de compatibilité concret à vérifier par rapport au code final. L'implémentation examinée doit préserver la séquence de transactions prévue tout en appliquant la nouvelle limite. Une déclaration d'intention de conception est utile pendant ce travail ; le comportement déployé dépendra de la gouvernance d'implémentation finalement acceptée.
Rédigé par le service rédactionnel et édité par Samuel Rae.