Después de una vulnerabilidad en noviembre en los Pools Estables Composables, el equipo de Balancer v3 utilizó el incidente para revisar sus defensas y fortalecer la seguridad a nivel de protocolo.
De la vulnerabilidad del 3 de noviembre a un modelo de seguridad proactivo
El 3 de noviembre, una vulnerabilidad afectó a los Pools Estables Composables en V2, lo que llevó a Balancer a actuar de manera decisiva. V3 permaneció completamente intacto, sin embargo, el equipo vio una oportunidad para reforzar su modelo de seguridad y preparar el protocolo contra clases enteras de ataques.
La vulnerabilidad en CSP expuso un vector de ataque que había existido durante más de cuatro años antes de que alguien lo detectara. Además, debilidades similares fueron explotadas posteriormente en otros protocolos, demostrando que el patrón había pasado mayormente desapercibido en toda la industria y obligando a repensar las suposiciones defensivas.
La seguridad tradicional tiende a ser reactiva: encontrar un error, corregirlo y seguir adelante. Sin embargo, este enfoque deja vulnerabilidades desconocidas sin abordar, incluyendo vectores de ataque que pueden permanecer ocultos durante otros cuatro años hasta que sean descubiertos por adversarios.
Diseñando V3 para eliminar clases enteras de vulnerabilidades
El equipo concluyó que la mejor respuesta era eliminar categorías enteras de posibles exploits restringiendo el protocolo a casos de uso legítimos y económicamente relevantes. Si una operación específica no tiene una razón sólida para existir, no debería ser posible en la cadena.
La arquitectura de V3 ya refleja esta filosofía. Su arquitectura centrada en bóvedas (vault) centraliza los saldos de tokens, la contabilidad de tarifas y la gestión de BPT en un sistema único, altamente auditado. Sin embargo, estas decisiones también eliminan muchas superficies potenciales de ataque que podrían ser explotadas por actores hostiles.
Gracias a este diseño, la vulnerabilidad específica de redondeo que permitió la vulnerabilidad del 3 de noviembre no existe en V3. El resultado es claro: ninguna pool de V3 se vio afectada por el incidente, a pesar de la gravedad del ataque en la infraestructura de V2.
Fortaleciendo Balancer V3 mediante una reevaluación profunda de seguridad
Incluso con ese historial limpio, el equipo fue más allá. En colaboración con Certora, Balancer encargó una reevaluación exhaustiva de muchos contratos inteligentes de V3, con el objetivo de detectar y eliminar cualquier posible vector de ataque antes de que pudiera ser utilizado por actores maliciosos.
La auditoría de seguridad de V3 realizada por Certora no reportó vulnerabilidades en los contratos examinados. Además, los resultados destacaron cómo la arquitectura simplificada, que traslada la complejidad de los pools individuales a la bóveda, produce un protocolo más seguro por diseño.
Para los lectores interesados en matices técnicos y métodos formales, los hallazgos completos están disponibles en el informe completo de Certora sobre la reevaluación de seguridad. Sin embargo, el resultado principal es claro: las decisiones arquitectónicas están validadas por una revisión externa rigurosa.
Nuevas salvaguardas para pools ponderados
Más allá de la auditoría exitosa, Balancer implementó protecciones adicionales en pools ponderados y estables. Estas protecciones limitan aún más el comportamiento del protocolo a escenarios económicos válidos y ayudan a neutralizar patrones de ataque conocidos a nivel de pool.
En los pools ponderados de V3, se introdujeron dos salvaguardas específicas para eliminar casos de uso maliciosos o patológicos. Juntas, refuerzan el objetivo central de limitar las operaciones a condiciones de intercambio realistas y significativas.
Límites mínimos de saldo de tokens
La primera medida es un sistema de saldos mínimos de tokens que se aplica de manera consistente en toda la gama de configuraciones de decimales de tokens. Dado que alcanzar saldos extremadamente bajos generalmente requiere intercambios muy grandes, este mecanismo limita indirectamente el tamaño máximo efectivo de las operaciones.
Como resultado, la actividad en los pools se restringe a un rango económicamente relevante. Además, las operaciones que de otro modo llevarían los saldos a extremos poco realistas ya no están permitidas, cerrando escenarios que podrían usarse para manipular cálculos o activar errores en casos límite.
Redondeo mejorado de saldos en la bóveda
La segunda salvaguarda es un redondeo mejorado de los saldos dentro de la bóveda y la matemática de pools. En el modelo anterior, ciertas operaciones de liquidez en la bóveda pasaban una dirección de redondeo requerida a los pools cuando se necesitaba un comportamiento específico.
En V3, los pools siempre realizan el redondeo correctamente. En particular, la lógica de redondeo de amountIn para intercambios ExactOut ha sido corregida en comparación con V2. Además, Balancer ahora redondea hacia arriba el saldo de tokenIn durante cálculos internos, llevando el redondeo correcto aún más hacia resultados conservadores y seguros.
Límites en pools estables y la relación máxima de desequilibrio
Los pools estables de V3 también obtuvieron una restricción adicional diseñada para reflejar cómo deberían comportarse estos mercados en la práctica. Esta salvaguarda se centra en prevenir desequilibrios extremos que han caracterizado intentos de explotación en el pasado.
La nueva relación máxima de desequilibrio impone un límite rígido de 10,000:1 entre los saldos de los tokens más grande y más pequeño en un pool estable. Aunque estos pools están destinados a mantenerse cerca de un equilibrio 1:1, este límite generoso bloquea estados extremos que se han visto en ataques conocidos.
La idea principal es mantener los pools estables en una zona operativa que siga siendo económicamente significativa. No hay una razón válida para operar un pool con ratios cercanos a esos extremos, por lo que el protocolo ahora prohíbe esas configuraciones, reforzando límites sensatos para pools estables.
Reevaluando intercambios flash y escenarios imposibles
Una comprensión clave que influyó en estas decisiones de diseño fue que los intercambios flash son fundamentalmente diferentes de los préstamos flash. Aunque ambos mecanismos ofrecen acceso temporal a activos, los préstamos flash están limitados por la liquidez disponible en la cadena.
Los intercambios flash, en cambio, están limitados principalmente por el almacenamiento, que teóricamente puede alcanzar 1e128 tokens, mucho más allá del suministro circulante o total de cualquier activo. Además, esta discrepancia abre la posibilidad de abuso cuando los protocolos no reconocen cuán poco realistas son esas cifras.
No hay justificación legítima para tomar prestados más tokens de los que alguna vez existirán. Tal movimiento es un error del usuario o un ataque directo, no un caso de uso válido. Balancer v3 ahora previene estos escenarios imposibles mediante sus nuevas salvaguardas.
Estableciendo un estándar más alto para la seguridad de AMM
El exploit del 3 de noviembre dejó lecciones duras pero valiosas para todo el ecosistema DeFi. La respuesta de Balancer demuestra un compromiso de aprender de los incidentes, incluso cuando no afectan directamente a la última versión del protocolo.
Al adoptar una postura preventiva en lugar de reactiva, el proyecto busca establecer un nuevo estándar en seguridad de AMM, integrando robustez en la arquitectura para bloquear amenazas antes de que se materialicen completamente.
La seguridad de Balancer va más allá del diseño de contratos inteligentes. En colaboración con Hypernative, los nuevos pools incorporan capacidades extendidas de pausa, respaldadas por monitoreo 24/7, permitiendo respuestas rápidas ante amenazas en la cadena y avanzando hacia un modelo de protección activa en lugar de la inmutabilidad rígida.
Despliegue, documentación y el camino por delante
Las nuevas fábricas de pools ponderados y estables, incluyendo pools Stable Surge con límites ampliados, ya están en funcionamiento en todas las redes soportadas por V3. Además, los desarrolladores pueden revisar las especificaciones técnicas y ejemplos en la documentación oficial de balancer v3 y en repositorios relacionados.
La misión de Balancer sigue siendo acelerar la innovación en DeFi ofreciendo infraestructura segura y lista para producción para aplicaciones de liquidez. Los proyectos eligen el protocolo como base para diseñar nuevos tipos de pools y construir dApps financieras avanzadas sobre infraestructura auditada y robusta.
En resumen, la combinación de decisiones arquitectónicas, auditorías externas, nuevas salvaguardas y monitoreo en tiempo real refleja una mentalidad de seguridad ante todo. La evolución de V3 demuestra cómo un solo exploit puede impulsar al ecosistema hacia creadores de mercado automatizados más fuertes y resilientes.
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
Cómo Balancer V3 convierte una vulnerabilidad crítica en un nuevo estándar para la seguridad de los AMM
Después de una vulnerabilidad en noviembre en los Pools Estables Composables, el equipo de Balancer v3 utilizó el incidente para revisar sus defensas y fortalecer la seguridad a nivel de protocolo.
De la vulnerabilidad del 3 de noviembre a un modelo de seguridad proactivo
El 3 de noviembre, una vulnerabilidad afectó a los Pools Estables Composables en V2, lo que llevó a Balancer a actuar de manera decisiva. V3 permaneció completamente intacto, sin embargo, el equipo vio una oportunidad para reforzar su modelo de seguridad y preparar el protocolo contra clases enteras de ataques.
La vulnerabilidad en CSP expuso un vector de ataque que había existido durante más de cuatro años antes de que alguien lo detectara. Además, debilidades similares fueron explotadas posteriormente en otros protocolos, demostrando que el patrón había pasado mayormente desapercibido en toda la industria y obligando a repensar las suposiciones defensivas.
La seguridad tradicional tiende a ser reactiva: encontrar un error, corregirlo y seguir adelante. Sin embargo, este enfoque deja vulnerabilidades desconocidas sin abordar, incluyendo vectores de ataque que pueden permanecer ocultos durante otros cuatro años hasta que sean descubiertos por adversarios.
Diseñando V3 para eliminar clases enteras de vulnerabilidades
El equipo concluyó que la mejor respuesta era eliminar categorías enteras de posibles exploits restringiendo el protocolo a casos de uso legítimos y económicamente relevantes. Si una operación específica no tiene una razón sólida para existir, no debería ser posible en la cadena.
La arquitectura de V3 ya refleja esta filosofía. Su arquitectura centrada en bóvedas (vault) centraliza los saldos de tokens, la contabilidad de tarifas y la gestión de BPT en un sistema único, altamente auditado. Sin embargo, estas decisiones también eliminan muchas superficies potenciales de ataque que podrían ser explotadas por actores hostiles.
Gracias a este diseño, la vulnerabilidad específica de redondeo que permitió la vulnerabilidad del 3 de noviembre no existe en V3. El resultado es claro: ninguna pool de V3 se vio afectada por el incidente, a pesar de la gravedad del ataque en la infraestructura de V2.
Fortaleciendo Balancer V3 mediante una reevaluación profunda de seguridad
Incluso con ese historial limpio, el equipo fue más allá. En colaboración con Certora, Balancer encargó una reevaluación exhaustiva de muchos contratos inteligentes de V3, con el objetivo de detectar y eliminar cualquier posible vector de ataque antes de que pudiera ser utilizado por actores maliciosos.
La auditoría de seguridad de V3 realizada por Certora no reportó vulnerabilidades en los contratos examinados. Además, los resultados destacaron cómo la arquitectura simplificada, que traslada la complejidad de los pools individuales a la bóveda, produce un protocolo más seguro por diseño.
Para los lectores interesados en matices técnicos y métodos formales, los hallazgos completos están disponibles en el informe completo de Certora sobre la reevaluación de seguridad. Sin embargo, el resultado principal es claro: las decisiones arquitectónicas están validadas por una revisión externa rigurosa.
Nuevas salvaguardas para pools ponderados
Más allá de la auditoría exitosa, Balancer implementó protecciones adicionales en pools ponderados y estables. Estas protecciones limitan aún más el comportamiento del protocolo a escenarios económicos válidos y ayudan a neutralizar patrones de ataque conocidos a nivel de pool.
En los pools ponderados de V3, se introdujeron dos salvaguardas específicas para eliminar casos de uso maliciosos o patológicos. Juntas, refuerzan el objetivo central de limitar las operaciones a condiciones de intercambio realistas y significativas.
Límites mínimos de saldo de tokens
La primera medida es un sistema de saldos mínimos de tokens que se aplica de manera consistente en toda la gama de configuraciones de decimales de tokens. Dado que alcanzar saldos extremadamente bajos generalmente requiere intercambios muy grandes, este mecanismo limita indirectamente el tamaño máximo efectivo de las operaciones.
Como resultado, la actividad en los pools se restringe a un rango económicamente relevante. Además, las operaciones que de otro modo llevarían los saldos a extremos poco realistas ya no están permitidas, cerrando escenarios que podrían usarse para manipular cálculos o activar errores en casos límite.
Redondeo mejorado de saldos en la bóveda
La segunda salvaguarda es un redondeo mejorado de los saldos dentro de la bóveda y la matemática de pools. En el modelo anterior, ciertas operaciones de liquidez en la bóveda pasaban una dirección de redondeo requerida a los pools cuando se necesitaba un comportamiento específico.
En V3, los pools siempre realizan el redondeo correctamente. En particular, la lógica de redondeo de amountIn para intercambios ExactOut ha sido corregida en comparación con V2. Además, Balancer ahora redondea hacia arriba el saldo de tokenIn durante cálculos internos, llevando el redondeo correcto aún más hacia resultados conservadores y seguros.
Límites en pools estables y la relación máxima de desequilibrio
Los pools estables de V3 también obtuvieron una restricción adicional diseñada para reflejar cómo deberían comportarse estos mercados en la práctica. Esta salvaguarda se centra en prevenir desequilibrios extremos que han caracterizado intentos de explotación en el pasado.
La nueva relación máxima de desequilibrio impone un límite rígido de 10,000:1 entre los saldos de los tokens más grande y más pequeño en un pool estable. Aunque estos pools están destinados a mantenerse cerca de un equilibrio 1:1, este límite generoso bloquea estados extremos que se han visto en ataques conocidos.
La idea principal es mantener los pools estables en una zona operativa que siga siendo económicamente significativa. No hay una razón válida para operar un pool con ratios cercanos a esos extremos, por lo que el protocolo ahora prohíbe esas configuraciones, reforzando límites sensatos para pools estables.
Reevaluando intercambios flash y escenarios imposibles
Una comprensión clave que influyó en estas decisiones de diseño fue que los intercambios flash son fundamentalmente diferentes de los préstamos flash. Aunque ambos mecanismos ofrecen acceso temporal a activos, los préstamos flash están limitados por la liquidez disponible en la cadena.
Los intercambios flash, en cambio, están limitados principalmente por el almacenamiento, que teóricamente puede alcanzar 1e128 tokens, mucho más allá del suministro circulante o total de cualquier activo. Además, esta discrepancia abre la posibilidad de abuso cuando los protocolos no reconocen cuán poco realistas son esas cifras.
No hay justificación legítima para tomar prestados más tokens de los que alguna vez existirán. Tal movimiento es un error del usuario o un ataque directo, no un caso de uso válido. Balancer v3 ahora previene estos escenarios imposibles mediante sus nuevas salvaguardas.
Estableciendo un estándar más alto para la seguridad de AMM
El exploit del 3 de noviembre dejó lecciones duras pero valiosas para todo el ecosistema DeFi. La respuesta de Balancer demuestra un compromiso de aprender de los incidentes, incluso cuando no afectan directamente a la última versión del protocolo.
Al adoptar una postura preventiva en lugar de reactiva, el proyecto busca establecer un nuevo estándar en seguridad de AMM, integrando robustez en la arquitectura para bloquear amenazas antes de que se materialicen completamente.
La seguridad de Balancer va más allá del diseño de contratos inteligentes. En colaboración con Hypernative, los nuevos pools incorporan capacidades extendidas de pausa, respaldadas por monitoreo 24/7, permitiendo respuestas rápidas ante amenazas en la cadena y avanzando hacia un modelo de protección activa en lugar de la inmutabilidad rígida.
Despliegue, documentación y el camino por delante
Las nuevas fábricas de pools ponderados y estables, incluyendo pools Stable Surge con límites ampliados, ya están en funcionamiento en todas las redes soportadas por V3. Además, los desarrolladores pueden revisar las especificaciones técnicas y ejemplos en la documentación oficial de balancer v3 y en repositorios relacionados.
La misión de Balancer sigue siendo acelerar la innovación en DeFi ofreciendo infraestructura segura y lista para producción para aplicaciones de liquidez. Los proyectos eligen el protocolo como base para diseñar nuevos tipos de pools y construir dApps financieras avanzadas sobre infraestructura auditada y robusta.
En resumen, la combinación de decisiones arquitectónicas, auditorías externas, nuevas salvaguardas y monitoreo en tiempo real refleja una mentalidad de seguridad ante todo. La evolución de V3 demuestra cómo un solo exploit puede impulsar al ecosistema hacia creadores de mercado automatizados más fuertes y resilientes.