Aave Labs ha aclarado que su propuesta de actualización de seguridad V3.8 preservaría las liquidaciones de préstamos flash. La respuesta del 23 de octubre aborda cómo una protección contra reentrancia interactuaría con las integraciones existentes.
TL;DR: La propuesta de V3.8 de Aave excluye los puntos de entrada de préstamos relámpago. La aprobación de la gobernanza y las auditorías de seguridad siguen pendientes.
La propuesta, publicada el 21 de octubre, añade una protección a las operaciones del Pool. Estas protecciones limitan la capacidad de una devolución de llamada externa para ingresar nuevamente a funciones protegidas del contrato antes de que una llamada anterior termine. Aave Labs dice que flashLoan() y flashLoanSimple() estarían excluidas, permitiendo que sus devoluciones de llamada sigan invocando acciones del Pool, incluyendo liquidaciones.
Por qué es importante la devolución de llamada
Un contrato inteligente que recibe un préstamo relámpago necesita tiempo dentro de la transacción para hacer algo con los activos prestados. La guía para desarrolladores de Aave describe una secuencia en la que la Pool transfiere los activos, llama al contrato receptor y luego verifica las condiciones de liquidación.
Para un préstamo relámpago simple, el receptor debe poner a disposición la cantidad prestada más la tarifa requerida para el reembolso. Si la transacción no puede cumplir sus condiciones, se revierte. La interfaz más amplia de préstamo relámpago puede cubrir múltiples activos y, bajo condiciones permitidas, abrir una posición de deuda respaldada por garantía.
Esas mecánicas explican por qué importa el alcance de un guardia. Una integración de liquidación puede necesitar tomar prestado un activo, devolver una posición no saludable y completar el resto de su transacción antes del asentamiento. Bloquear indiscriminadamente cada interacción posterior con el Pool interferiría con esa secuencia.
La pregunta de diseño importante es qué rutas de retorno al protocolo son intencionales. Un límite de seguridad útil debe tener en cuenta los patrones de transacción en los que dependen las integraciones, incluidas las llamadas que ocurren después de que los activos hayan salido del Pool pero antes de que se verifique el reembolso.
Un bloqueo por longitud de transacción
La implementación propuesta utiliza el almacenamiento transitorio introducido a través de Ethereum’s EIP-1153. Ese almacenamiento permanece disponible durante una transacción y se descarta cuando finaliza la transacción. Por lo tanto, puede transportar el estado de bloqueo temporal para rastrear si una operación protegida ya está en ejecución.
La especificación identifica los bloqueos de reentrada como un caso de uso y explica por qué el almacenamiento transitorio puede costar menos que escribir el estado temporal en el almacenamiento permanente. Para un protocolo DeFi de alto uso, la pregunta de diseño incluye el costo impuesto a las transacciones ordinarias así como la protección añadida por el guardia.
La propuesta de Aave incluye retroalimentación, una votación en Snapshot, una revisión de seguridad y una propuesta de mejora en cadena. Se espera que Certora y otros revisores evalúen los cambios antes de este paso final.
Para los integradores en Ethereum y otras redes afectadas, la aclaración proporciona un punto de compatibilidad concreto para verificar contra el código final. La implementación revisada debe preservar la secuencia de transacciones prevista mientras impone el nuevo límite. Una declaración de intención de diseño es útil durante ese trabajo; el comportamiento implementado dependerá finalmente de la gobernanza que acepte la implementación.
Escrito por el equipo de noticias y editado por Samuel Rae.