Aave Labs ha presentado una propuesta para actualizar su protocolo de préstamos descentralizados a la versión 3.8, un cambio orientado a reforzar la seguridad en 16 redes blockchain. Publicada el 21 de octubre, la propuesta se centra en prevenir riesgos contables relacionados con la reentrancia, manteniendo la eficiencia de las transacciones.

De ser adoptada, la actualización introduciría salvaguardas adicionales para las operaciones del Pool de Aave, protegiendo el protocolo contra exploits teóricos de contratos inteligentes. La implementación, sin embargo, sigue sujeta a auditorías de seguridad, comentarios de la comunidad y la aprobación formal de gobernanza.

El Guardián de Reentrancia en el Centro

La propuesta de actualización V3.8 de Aave introduce un guardián de reentrancia diseñado para proteger la contabilidad del Pool durante callbacks externos. La reentrancia ocurre cuando un contrato inteligente interactúa repetidamente con otro contrato antes de que finalice una operación anterior, lo que puede generar inconsistencias contables. La reentrancia es una de las clases de vulnerabilidades más conocidas en el desarrollo de contratos inteligentes, y las protecciones explícitas contra ella se han convertido en una práctica estándar en la ingeniería DeFi, especialmente en protocolos que custodian depósitos de usuarios directamente en sus contratos.

Para implementar la protección, Aave Labs planea utilizar la tecnología de almacenamiento transitorio introducida a través de la Ethereum Improvement Proposal EIP-1153. Este mecanismo permite el almacenamiento temporal de datos durante las transacciones, ayudando a los desarrolladores a añadir salvaguardas de seguridad sin aumentar significativamente los costos de gas.

Según la propuesta de gobernanza, los cambios representan una mejora de seguridad limitada en lugar de un rediseño importante del protocolo. El documento no identifica ningún exploit activo ni vulnerabilidad confirmada que requiera una intervención de emergencia.

El Despliegue Abarca 16 Redes

Aave Labs tiene la intención de desplegar la V3.8 en las instancias activas del protocolo en 16 redes blockchain compatibles. Estas incluyen Ethereum, Avalanche, BNB Chain, Arbitrum, Base, Polygon, Optimism, Linea, Gnosis, Celo, Mantle, Monad, Plasma, X Layer y MegaETH, junto con despliegues adicionales basados en Ethereum.

Las instancias Core y Lido de Ethereum están incluidas en el despliegue propuesto. Sin embargo, los mercados inactivos con activos congelados, así como aquellos cuy límites de préstamo o suministro han sido reducidos a cero, quedarán fuera del alcance de la actualización.

La amplia estrategia de despliegue refleja el enfoque de Aave en mantener estándares de seguridad consistentes en su infraestructura de préstamos multichain, de modo que los depositantes y prestatarios en redes más pequeñas reciban las mismas protecciones básicas que los de Ethereum. Protecciones contables más sólidas podrían reducir los riesgos potenciales de contratos inteligentes a medida que se expande la actividad de préstamos descentralizados.

Auditorías y Votación de Gobernanza Son los Próximos Pasos

Antes de la implementación, la V3.8 de Aave será sometida a revisiones de seguridad que involucran a Certora y auditores independientes adicionales. Estas evaluaciones examinarán los cambios propuestos antes de que los desarrolladores presenten la actualización final para una decisión de gobernanza on-chain.

La propuesta se encuentra actualmente en la etapa de Aave Request for Final Comments, lo que permite a los miembros de la comunidad evaluar sus detalles técnicos. Los comentarios positivos llevarían la iniciativa a una votación en Snapshot, seguida de una Aave Improvement Proposal formal una vez concluidas las auditorías. Según el modelo de gobernanza de Aave, la aprobación final recae en los tenedores de tokens de la comunidad en lugar del equipo proponente, lo que otorga a la comunidad múltiples puntos de control antes de que cualquier cambio en el código entre en vigor.

Aave Labs no ha anunciado una fecha de despliegue confirmada. En última instancia, la implementación de la actualización depende de revisiones de seguridad exitosas y de la aprobación de la gobernanza, lo que hace que el próximo proceso de evaluación sea crítico para su lanzamiento.