Technical Background of Balancer V2 Composable Stable Pools Bases Técnicas de Piscinas Estables Balancer V2 Composable : de Pool Structure and How It Works Los Pools Estables Composables se basan en las matemáticas inspiradas en el modelo StableSwap de Curve. What is a Composable Stable Pool? Estos grupos están diseñados para permitir que los activos con valores casi idénticos, como USDC y DAI, o stETH y ETH, se negocien con un deslizamiento mínimo. **What makes them “composable”?
\ The pool’s LP token (BPT) is a standard ERC-20 token that can be reused across the ecosystem, for example, in other pools or as collateral. This allows liquidity to be seamlessly composed throughout the system. **How it works
\ A Composable Stable Pool can hold multiple tokens, and its invariant DDD is calculated using the following polynomial equation: En el equilibrio puertos (inspirados por Curve), los swaps se calculan manteniendo un (D) tan constante como sea posible.Cuando se produce un swap, los saldos de token se mueven a un nuevo estado que preserva esta invariante. Usted decide obtener el del token que está resolviendo, dado que (D) permanece fijo. stable invariant quadratic new balance (x) Termos 
 
 
 
 
 
 
 (x): el nuevo saldo (post-swap) del token que está resolviendo. (S): la suma de los saldos de los otros tokens (excluyendo (x)). (P): el producto de los saldos de los otros tokens (excluyendo (x)). (D): el pool invariante (dirigido a permanecer constante en todo el swap). (A): el parámetro de amplificación (flattens la curva → menor deslizamiento para activos de igual valor). (n): el número de tokens en el pool. Intuición: comprimimos “todos los otros tokens” en dos agregados, (S) y (P). . quadratic in (x) ¿Por qué el cuadrado? Después de aislar el nuevo saldo del token desconocido y doblar el resto en (S) y (P), la condición invariante se reduce a un polinomial de segundo grado en (x). resolverlo Seleccione la raíz que y (Dentro de los intervalos de equilibrio factibles).La otra raíz es típicamente negativa o insensata. Which root? positive economically valid Un ejemplo sencillo Setup (2 tokens, large A → very low slippage) 
 
 
 
 
 Saldo inicial interno (escalado): token0 = 1.000.000; token1 = 1.000.000 Number of tokens: n = 2 Amplificación: A = 1000 Con gran A, D ≈ 2.000.000 Action 
 
 Añade 10.000 unidades de token0 (EXACT_IN). Quadratic to solve x^2 + (S - D/(A*n^n) - D)*x - D^(n+1)/(A*n^(2n)*P) = 0 Dónde es: , de , y es el saldo post-swap de token1. S = 1,010,000 P = 1,010,000 x Solution x ≈ 990,999.546 Amount out amountOut = 1,000,000 - 990,999.546 ≈ 9,000.454 Interpretation 
 
 
 Pone 10.000 de token0 y recibe ~9,000.45 de token1 → bajo deslizamiento con gran A. Todas las matemáticas utilizan unidades internas de 18 decimales; implementaciones redondas para la seguridad. Dónde se utiliza (nivel alto) 
 
 
 EXACT_IN: aumenta el token de entrada; resuelve el nuevo saldo del contra-token (x); la diferencia de su antiguo saldo es el importe. EXACT_OUT: se dirige a una cantidad específica recibida; se resuelve para el necesario (x) (y por lo tanto la entrada requerida). Notas prácticas 
 
 
 Todos los saldos se manejan internamente a 18 decimales (escalados); los cálculos suelen redondearse para ser seguros. Un mayor (A) hace que la curva sea más constante-sum-like (tiny slipage para pares estables); un menor (A) es más cercano al comportamiento de producto constante. 
 
 TL;DR: Esta ecuación es el cuadrado del caballo de trabajo que, bajo un invariante fijo (D), le da el nuevo saldo de token (x) después de un swap. Los coeficientes codifican "el resto del pool" a través de (S) y (P), mientras que (A) y (n) establecen la forma / planitud de la curva estable. Esta ecuación es la que, bajo un invariante fijo (D), te da la Los coeficientes codifican “el resto del pool” a través de (S) y (P), mientras que (A) y (n) establecen la forma/planura de la curva estable. TL;DR: workhorse quadratic new token balance (x) La pólvora impone a entre las balanzas de token, capturadas por un . balance relationship invariant D Cuando intercambias, un saldo sube, otro desciende y el pool encuentra una Así es como surge el precio. new balance that keeps D as constant as possible El pool utiliza factores de escala para normalizar los tokens a 18 decimales.Operación Upscale ajusta los saldos a la precisión interna y utiliza el redondeo hacia abajo. Swap Types 
 
 
 EXACT_IN (GIVEN_IN): cantidad de entrada fija, calcular la salida. EXACT_OUT (GIVEN_OUT): cantidad de salida fija, calcular la entrada. Vault y BatchSwapBalancer Vault gestiona todas las operaciones. BatchSwap combina múltiples swaps en una transacción y utiliza "deferred settlement" como flashloans.BPTs actúan como tokens normales, bypassando el límite de suministro de min pool para bajar la liquidez muy bajo. 1 Análisis de explotación 1.1 El ataque El 3 de noviembre de 2025, alrededor de las 7:40 UTC, pools estables específicos de Balancer v2 fueron atacados con un ataque sofisticado que resultó en una pérdida acumulativa de más de $ 120 millones en Balancer y sus forcas. The attack leveraged several circumstances: 
 
 
 
 
 La mayoría de los grupos de interés fueron ejemplos del contrato ComposableStablePool.Un grupo especial diseñado para activos que se espera que intercambien consistentemente a paridad cercana o a un tipo de cambio conocido. La funcionalidad batchSwap del contrato Balancer Vault permite que los swaps transitorios ocurran antes de la necesidad de liquidar las deltas pendentes. El ataque fue rentable en escenarios de baja liquidez.El atacante tuvo que preparar grandes swaps para que los saldos de las piscinas pudieran ser llevados a la baja liquidez de uno u otro token.La forma más utilizada de lograr esto era intercambiar tokens LP por tokens pool, dejando el pool en un estado de baja liquidez. Todo lo anterior es simplemente necesario, pero no circunstancias concluyentes, con la única circunstancia necesaria para que esto suceda siendo la causa raíz del problema, un comportamiento de redondeo en la función _upscale. El vector de ataque fue introducido por primera vez el 16 de julio de 2021, cuando MetaStablePool superó el La misma modificación se aplicó más tarde el 1 de septiembre de 2021, para los pooles lineales en commit 4e9e70a y el 20 de septiembre de 2021, en commit f450760 para StablePhantomPool, más tarde renombrado ComposableStablePool. _scalingFactors En la descripción del problema a continuación, explicamos por qué la introducción de esta sobrecarga fue el núcleo del ataque. 1.2 El tema La función batchSwap del contrato Vault es el punto de entrada para este ataque. El atacante creó una llamada a él, apuntando a instancias de ComposableStablePool. La lógica relevante en el contrato Vault que lleva a la interacción de ComposableStablePool se define por este flujo: batchSwaps → llama internamente a _swapWithPools → que llama internamente a un pool para cada swap en _swapWithPool → _processGeneralPoolSwapRequest → finalmente llama a onSwap en el ComposableStablePool. Una vez aterrizado en ComposableStablePool, la ejecución continúa dentro del gancho onSwap, donde suceden dos cosas: 
 
 
 La llamada a la función _scalingFactors. La entrega a _swapGivenOut como se define en la transacción de ejemplo proporcionada anteriormente. Tenga en cuenta que el atacante puede haber decidido tomar el patrón _swapGivenIn, pero las entradas proporcionadas en la transacción de ataque muestran claramente la elección. Veamos estas dos funciones. Factores escalares function _scalingFactors() internal view virtual override returns(uint256[] memory) {
    uint256 totalTokens = _getTotalTokens();
    uint256[] memory scalingFactors = new uint256[](totalTokens);

    for (uint256 i = 0; i < totalTokens; ++i) {
        scalingFactors[i] = _getScalingFactor(i).mulDown(_getTokenRate(i));
    }

    return scalingFactors;
}
 Esta función hace dos cosas: 
 
 
 Escala cualquier cantidad a un número fijo de decimales como lo sugiere la función _getScalingFactor y lo que devuelve. Factores en la tasa de cambio de token al multiplicarla por el factor de escala y dividirla por 1e18. _upscale function _upscale(uint256 amount, uint256 scalingFactor) pure returns (uint256) {
    /* Upscale rounding wouldn't necessarily always go in the same direction: 
in a   swap for example the balance of token in should be 
rounded up, and that of token out rounded down. This
is the only place where we round in the same direction for all amounts, 
as the impact of this rounding is expected to be minimal. */

    return FixedPoint.mulDown(amount, scalingFactor);
}
 Esto sólo realiza una multiplicación de la cantidad por su factor de escala, dividiendo por 1e18 al final. El problema reside en dos hechos: 
 
 
 Estas funciones siempre redondean (mulDown) independientemente de la dirección del swap. Si las cantidades son órdenes de magnitud menor que las de ScalingFactors, la pérdida de precisión se vuelve insignificante. En la transacción del atacante, un valor típico de la cantidad y el factor de escalado es: cantidad: "17"escaladoFactor: "1058132408689971699" Si se calcula Nosotros obtenemos , pero dado que Solidity trunca decimales, esto se convierte en , resulting in a  En la Funcionamiento . amount * scalingFactor / 1e18 17.98 17 0% net change _upscale Considera una cantidad de (un token con 18 decimales).El resultado es Representando a que refleja correctamente la tasa. 17,000000000000000000 17.988250950000000000 5.8% increase De igual manera, para una tarjeta con (como la mayoría de los stablecoins tienen), utilizando una cantidad de Donaciones que corresponde aproximadamente al mismo . 6 decimals 17,000000 17.988250 5.8% positive change La truncción se maximiza haciendo tan grande como sea posible, por lo que el producto pierde la máxima precisión cuando se divide por 1e18. amount*scalingFactor mod 1e18 Por ejemplo, en la tabla siguiente, cantidad=17 y cantidad=50 ambos producen una pérdida de redondeo absoluta de alrededor de 0,90. sin embargo, el error como porcentaje de la cantidad varía significativamente, y el porcentaje de aumento perdido diverge aún más, ya que la misma pérdida absoluta es mucho mayor en relación a 17 que a 50. Ejemplos Ejemplos de error de redondeo del piso al escalar por un factor de 1.058132408689971699 
 
 
 
 
 
 
 
 
 
 
 
 amount 
 upscale 
 error 
 %error 
 %increase lost 
 
 
 
 
 
 
 17 
 17 
 0.98 
 5.76% 
 100% 
 
 
 
 
 
 
 50 
 52 
 0.90 
 1.80% 
 17% 
 
 
 
 
 
 
 ... 
 ... 
 ... 
 ... 
 ... 17 17 0.98 El 5,76% El 100% 50 52 0.90 El 1.80% El 17% ... ... ... ... ... El La función más tarde utilizará estos valores redondeados para calcular la cantidad que el atacante debe al pool después del swap. Este valor se deflaciona artificialmente, haciendo el swap más barato. son complejas, y también justifican por qué esto se puede lograr en los grupos donde los estados de baja liquidez se pueden obtener a voluntad. Esto se debe a un control invariante que asegura la convergencia en cierta medida. _swapGivenOut _swapGivenOut En última instancia, con un alto número de iteraciones, las deltas después del batchSwap se hinchan, lo que atribuye al atacante la mayoría de los fondos en el pool. Además, hay una observación pertinente que se debe hacer sobre las doctrinas en línea de _upscale: /* Upscale rounding wouldn't necessarily always go in the same direction: in a swap for example the balance of token in should be rounded up, and that of token out rounded down. This is the only place where we round in the same direction for all amounts, as the impact of this rounding is expected to be minimal. */
 Una versión anterior de este comentario tenía una nota adicional: /* …as the impact of this rounding is expected to be minimal (and there's no rounding error unless `_scalingFactor()` is overriden). */
 Esto es importante porque el Introducido en Más tarde se renombró a Se aplica exactamente la sobrecarga discutida anteriormente. StablePhantomPool September 20, 2021 ComposableStablePool _scalingFactor En versiones anteriores de , el La función sólo contaba con diferencias en decimales de token. En la implementación más reciente, sin embargo, también incorpora la marcando un cambio fundamental. StablePool _scalingFactor exchange rate Como se señala en la de la función, el código evolucionó del uso de (por ejemplo, a) Dos Este cambio, aunque funcionalmente necesario, introduce el potencial Y con ellos, una nueva . _upscale unitary scaling factors 1e12 non-unitary exchange rates rounding errors attack vector Mientras que permitir el error de redondeo era la causa raíz, explotarlo requería aprovechar la mecánica de protocolos adicionales y pasos de ataque específicos. Balancer’s batchSwap permite saldos internos transitorios que solo se liquidan en el final del lote.Gracias a esto, el atacante “prestó prestado” BPT dentro de un lote para manipular el pool sin tener que terminar la transacción que mantiene BPT. Un BPT (Balancer Pool Token) es un ERC-20 que representa una cuota proporcional de un pool Balancer. En algunos diseños de pool, incluyendo los ComposableStablePools dirigidos, el BPT también puede aparecer como un activo de pool y ser negociable/swappable. La primera fase empujó los saldos de token de pool (por ejemplo, WETH / osETH) a niveles muy bajos (alrededor de 100k) al intercambiar repetidamente BPT por token1 y BPT por token2. El objetivo es maximizar la parte fraccional descartada en aritmética del suelo, es decir, maximizar la cantidad*escaladoFactor mod 1e18 para que el producto pierda la mayor precisión posible cuando se divide por 1e18. El exploit se ejecuta en tripletes repetidos de swaps: 
 
 
 
 Prime: mover el pool a un estado en el que ocurrirá la truncción en la siguiente operación. En la captura de pantalla de abajo, un intercambio de WETH a osETH Exploit: realizar el swap que realiza la pérdida de redondeo. En la captura de pantalla, un swap de 17 WETH para osETH. Reset: restablece los equilibrios para que el triple pueda ser reproducido. En la captura de pantalla es el intercambio de osETH a WETH. Como se muestra en el rastro a continuación, el swap crítico a menudo utiliza un importe=17 contra un saldo de caja de 18. Avanzar las mejores prácticas de seguridad: lecciones para la industria Este incidente ha despertado un debate sobre la eficacia de las auditorías de seguridad de contratos inteligentes, con algunos comentaristas cuestionando si proporcionan valor.Aunque este sentimiento puede ser comprensible en el momento de la frustración, no reconoce por qué las auditorías de seguridad se han convertido en una mejor práctica de la industria y el enorme impacto que la práctica de auditoría de seguridad ha tenido en mitigar el riesgo y proteger a los usuarios durante la última década. Las empresas de seguridad prevenen colectivamente cientos de explosiones potenciales cada año.Solo OpenZeppelin ha identificado más de 700 vulnerabilidades críticas y de alta gravedad antes de alcanzar la producción en todas nuestras auditorías.Estos desastres prevenidos no hacen títulos, pero representan miles de millones de usuarios protegidos y innumerables usuarios salvados de pérdidas.Las auditorías de seguridad de alta calidad también ayudan a los equipos de desarrollo a mejorar su postura de seguridad a lo largo del ciclo de vida del desarrollo, lo que resulta en una reducción exponencial en la probabilidad de que se introduzcan errores adicionales en las aplicaciones de blockchain. La verdadera lección no es que las auditorías sean ineficaces, sino que las prácticas de auditoría de la industria aún no se han adaptado a la rapidez con la que evolucionan los protocolos complejos que aseguran un valor significativo.Debido a que las auditorías a menudo se abarcan como revisiones aisladas en lugar de compromisos continuos, el contexto puede perderse a medida que evolucionan las bases de código. 2.1 Establecimiento de la seguridad continua como estándar de la industria Desde el inicio de la práctica de la auditoría de contratos inteligentes en 2016, hemos visto cómo los resultados de seguridad más exitosos provienen de asociaciones de seguridad en curso que cubren bases de código enteras de protocolos y todos sus cambios a lo largo del tiempo, en lugar de revisiones de código ad hoc de actualizaciones importantes, que a menudo se limitan en alcance a sólo esos cambios. Cuando los investigadores de seguridad trabajan continuamente con los protocolos, desarrollan una profunda familiaridad con la arquitectura del protocolo, los procesos de ingeniería y por qué se tomaron decisiones de diseño específicas. Aunque la base de código Balancer v2 fue revisada por cuatro firmas de auditoría independientes, cada empresa se comprometió a centrarse en diferentes ámbitos del protocolo.La participación de varios auditores ayuda a reducir la posibilidad de que faltan vulnerabilidades, pero mantener al menos un socio de seguridad a largo plazo proporciona una comprensión más profunda y continua de cómo evoluciona la base de código y cómo los nuevos cambios interactúan con la lógica existente. 2.2 Construir mejores marcos de seguridad A través de nuestra década de experiencia, OpenZeppelin ha trabajado constantemente para establecer y elevar los estándares de seguridad en toda la industria. Los contratos de OpenZeppelin se han convertido en el estándar de facto para la construcción de contratos inteligentes seguros, actualmente alimentando más de $ 30 billones en valor total transferido a través del ecosistema. Al igual que estos contratos establecieron las bases para el desarrollo seguro, hemos estado trabajando activamente en los esfuerzos para establecer estándares más robustos para la evaluación de la seguridad y la protección de protocolos continuos. Además de las relaciones a largo plazo con nuestros clientes, estamos trabajando activamente para dar forma a estos estándares tanto en la industria como en los niveles regulatorios.Por ejemplo, OpenZeppelin contribuye a los organismos que establecen estándares de la industria, como el Consejo de Estándares de Seguridad de Blockchain, la Alianza Ethereum de Empresas y la Organización Internacional de Estándares (ISO), para garantizar que las mejores prácticas de seguridad que nuestro equipo y la comunidad han ayudado a pioneros estén disponibles para toda la industria. En particular, OpenZeppelin se ha comprometido con el Departamento del Tesoro de los Estados Unidos, la Comisión de Valores y Bolsa de los Estados Unidos, la Autoridad de Conducta Financiera del Reino Unido, y el ACPR francés y la AMF en relación con los beneficios de llevar a cabo auditorías de seguridad completas en una base regular. Además, hemos explorado el potencial de crear una organización de autorregulación dedicada similar a los auditores en otros campos que creemos que podrían ayudar a formalizar las normas y metodologías de auditoría de seguridad para la tecnología blockchain, establecer requisitos de calidad y ética para auditores, y gestionar la acreditación para certificar auditores cualificados, lo que podría mejorar los resultados de seguridad y aumentar la confianza del consumidor. 2.3 Fortalecer el ecosistema de seguridad de Blockchain juntos El aprovechamiento de Balancer v2 refuerza que a medida que los protocolos se vuelven más valiosos y sofisticados, es crucial para que los equipos de protocolos inviertan en la seguridad continua, así como para que las empresas auditen para construir marcos que la apoyan.

This story contains new, firsthand information uncovered by the writer.

2022 - HackerNoon Contributor of the Year - Bots

2022 - HackerNoon Contributor of the Year - Solidity

Nominated for 2022 - HackerNoon Contributor of the Year - Solidity

Nominated for 2022 - HackerNoon Contributor of the Year - Bots

Este audio es producido en el idioma original de la historia!

Balancer V2 Exploit Explicado: Dentro del Smart Contract Rounding Error que cuesta $ 120M

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

Liberando el poder de la IA. Una revisión sistemática de técnicas de vanguardia: resumen e introducción

Cómo mejorar su flujo de trabajo 10 veces: 17 aplicaciones esenciales

Telegram: el puente de Crypto Island hacia el continente

La guía completa para una migración exitosa a la nube: estrategias y mejores prácticas

Liberando el poder de la IA. Una revisión sistemática de técnicas de vanguardia: resumen e introducción

Cómo mejorar su flujo de trabajo 10 veces: 17 aplicaciones esenciales

Telegram: el puente de Crypto Island hacia el continente

La guía completa para una migración exitosa a la nube: estrategias y mejores prácticas

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps