Aave Labs esclareceu que sua proposta de atualização de segurança V3.8 preservará as liquidações por empréstimos rápidos. A resposta de 23 de outubro aborda como uma proteção contra reentrância interagiria com integrações existentes.
TL;DR: O guard proposto pela Aave V3.8 exclui pontos de entrada de flash-loans. A aprovação da governança e auditorias de segurança permanecem pendentes.
A proposta, postada em 21 de outubro, adiciona um mecanismo de proteção às operações do Pool. Esses mecanismos restringem a capacidade de um retorno externo de entrar novamente em funções protegidas do contrato antes que uma chamada anterior seja concluída. Aave Labs afirma que flashLoan() e flashLoanSimple() seriam excluídos, permitindo que seus retornos continuem invocando ações do Pool, incluindo liquidações.
Por que a retorno é importante
Um contrato inteligente que recebe um flash loan precisa de tempo dentro da transação para fazer algo com os ativos emprestados. O guia do desenvolvedor da Aave descreve uma sequência na qual o Pool transfere os ativos, chama o contrato receptor e depois verifica as condições de liquidação.
Para um empréstimo relâmpago simples, o receptor deve disponibilizar a quantia emprestada mais a taxa exigida para reembolso. Se a transação não puder atender às suas condições, ela é revertida. A interface mais ampla de empréstimo relâmpago pode abranger múltiplos ativos e, sob condições permitidas, abrir uma posição de dívida garantida por colateral.
Essas mecânicas explicam por que o escopo de um guard importa. Uma integração de liquidação pode precisar tomar emprestado um ativo, pagar uma posição insustentável e concluir o restante da sua transação antes do assentamento. Bloquear todas as interações subsequentes do Pool indiscriminadamente interferiria nessa sequência.
A questão de design importante é quais rotas de retorno ao protocolo são intencionais. Um limite de segurança útil deve considerar os padrões de transação nos quais as integrações dependem, incluindo chamadas que ocorrem após os ativos terem deixado o Pool, mas antes da recompensa ser verificada.
Um Bloqueio de Comprimento de Transação
A implementação proposta utiliza o armazenamento transitório introduzido por meio do Ethereum’s EIP-1153. Esse armazenamento permanece disponível durante uma transação e é descartado quando a transação termina. Ele pode, portanto, transportar o estado de bloqueio temporário para rastrear se uma operação protegida já está em execução.
A especificação identifica travas de reentrância como um caso de uso e explica por que o armazenamento transitório pode custar menos do que gravar o estado temporário no armazenamento permanente. Para um protocolo DeFi amplamente utilizado, a questão de design inclui o custo imposto às transações comuns, bem como a proteção adicionada pela proteção.
O caminho proposto pela Aave inclui feedback, votação no Snapshot, revisão de segurança e uma proposta de melhoria na cadeia. A Certora e outros revisores devem avaliar as variações antes dessa etapa final.
Para integradores na Ethereum e outras redes afetadas, a esclarecimento fornece um ponto de compatibilidade concreto para verificação em relação ao código final. A implementação revisada deve preservar a sequência de transações pretendida enquanto impõe o novo limite. Uma declaração de intenção de design é útil durante esse trabalho; o comportamento implantado dependerá da governança de implementação que for finalmente aceita.
Escrito pela Redação e editado por Samuel Rae.