[Thread em inglês] Análise aprofundada do ataque ao Balancer V2: mecanismo da vulnerabilidade, etapas do ataque e lições aprendidas

Chainfeeds Introdução:

O atacante definiu intencionalmente parâmetros, incluindo o número de iterações e o valor de entrada, para maximizar o efeito da perda de precisão.

Fonte do artigo:

Autor do artigo:

BlockSec

Opinião:

BlockSec: Em 3 de novembro de 2025, o Composable Stable Pool do Balancer V2, assim como vários projetos on-chain baseados em seu Fork, sofreram um ataque coordenado cross-chain, resultando em uma perda total superior a 125 milhões de dólares. A BlockSec emitiu um alerta imediatamente e, em seguida, publicou uma análise preliminar. Este foi um ataque altamente complexo. Nossa investigação mostrou que a causa raiz veio da perda de precisão nos cálculos do invariante, que foi explorada para manipulação de preços, afetando assim o preço do BPT (Balancer Pool Token). O atacante lucrou com pools estáveis específicos por meio de uma única operação batchSwap. O componente afetado foi o Composable Stable Pool do Balancer V2. Esse tipo de pool é projetado para ativos que devem manter uma taxa de câmbio próxima de 1:1, permitindo grandes negociações com mínimo slippage e aumentando significativamente a eficiência de capital para ativos correlacionados ou similares. Cada pool possui seu próprio BPT, cujo preço pode ser aproximadamente expresso como: Preço do BPT = D / totalSupply, onde D é o invariante da matemática estável, representando o valor total virtual do pool. Pela fórmula, se D for matematicamente reduzido (mesmo que os fundos reais não sejam perdidos), o preço do BPT será menor. O Balancer V2 oferece a função batchSwap(), que permite múltiplos swaps dentro do Vault, com dois modos no SwapRequest: GIVEN_IN e GIVEN_OUT. No modo GIVEN_OUT, o chamador especifica o valor de saída desejado, e o pool calcula o valor de entrada necessário. Nos pools estáveis, ao calcular o amountIn necessário, é preciso resolver uma equação polinomial baseada na fórmula do invariante, e esses cálculos passam por Upscaling e Downscaling. Em teoria, são operações opostas, mas na implementação real há arredondamentos em direções diferentes: o upscaling usa apenas arredondamento para baixo (mulDown), enquanto o downscaling pode arredondar para cima ou para baixo (divUp/divDown). Essa inconsistência abriu espaço para o ataque. A raiz da vulnerabilidade está no uso de arredondamento para baixo ao fazer Upscaling de swapRequest.amount em BaseGeneralPool._swapGivenOut(). O valor arredondado para baixo é usado como amountOut na entrada de _onSwapGivenOut(), fazendo com que o amountIn calculado seja menor do que o realmente necessário, violando o princípio de que o arredondamento deve sempre favorecer o protocolo. Para pools como (wstETH/rETH/cbETH), o atacante pode trocar uma quantidade menor de um ativo por uma quantidade maior de outro, reduzindo o invariante D e, assim, pressionando o preço do BPT para baixo. O atacante executou o ataque em duas fases. Na primeira fase, a lógica central do ataque é realizada em uma única transação, mas sem lucro imediato; na segunda fase, o lucro é retirado em uma transação separada. A primeira fase se divide em cálculo de parâmetros e batch swap. Tomando como exemplo a transação de ataque na rede Arbitrum (TX: 0x7da32e…55773), o atacante primeiro obtém os parâmetros do pool, incluindo scaling factors, A (fator de amplificação), taxa de câmbio do BPT, swap fee, etc., depois calcula o trickAmt e simula por meio de um contrato auxiliar. O atacante ajusta com precisão os parâmetros do swap seguinte, incluindo o número de iterações e os valores de entrada e saída de cada vez, combinando cálculos offline e simulações on-chain. Em cada iteração, são realizados três swaps: no primeiro, a quantidade do token alvo é elevada para trickAmt + 1; no segundo, continua-se a swapar o token alvo, ativando o arredondamento para baixo do _upscale(); no terceiro, faz-se um swap reverso, truncando o saldo do pool para baixo, removendo as duas casas decimais mais altas antes de trocar de volta. Por exemplo, 324.816 → 320.000. Em alguns casos, devido ao uso do método de Newton–Raphson para resolver a matemática do StableSwap, pode haver falha, e o atacante preparou dois fallbacks, tentando novamente com 9/10 do valor original. Após o ataque, como alguns mecanismos do Balancer não puderam ser pausados, o impacto foi ampliado, levando a ataques imitativos em várias redes, com perdas totais superiores a 125 milhões de dólares. O incidente expôs quatro questões críticas em protocolos descentralizados: mecanismos de arredondamento inconsistentes, evolução constante das técnicas dos atacantes, incapacidade de pausar o protocolo ampliando as perdas, e falta de monitoramento em tempo real do estado de inicialização e operação. O upscaling só permite arredondamento para baixo, enquanto o downscaling permite ambos os sentidos, e essa assimetria pode acumular perdas de precisão exploráveis sob parâmetros extremos. O arredondamento, que deveria sempre favorecer o protocolo, neste caso prejudicou seus interesses. O atacante usou uma abordagem em duas fases: primeiro executa o ataque sem lucro aparente, depois retira o lucro separadamente, evitando modelos de monitoramento on-chain. Cada etapa do ataque combinou simulações off-chain e on-chain, com contratos auxiliares até reutilizando a implementação StableMath do Balancer, mantendo até as mensagens de erro idênticas. Após o ataque, houve réplicas em múltiplas redes e muitos projetos Fork também foram afetados, mostrando que, enquanto a matemática estável e a lógica de arredondamento forem iguais, a vulnerabilidade pode se espalhar pelo ecossistema. O evento mostra que protocolos DeFi precisam de cálculos matemáticos de maior precisão, validação mais rigorosa de arredondamento, mecanismos de simulação de caminhos suspeitos e capacidade de pausa de emergência em situações anormais. [O texto original está em inglês]