Análise técnica: Balancer sofre roubo de 120 milhões de dólares, onde estava a vulnerabilidade?

Título original: 《Análise Técnica da Vulnerabilidade de $120M Roubados da Balancer》
Fonte original: ExVul Security

Introdução

Em 3 de novembro de 2025, o protocolo Balancer sofreu um ataque hacker em várias blockchains, incluindo Arbitrum e Ethereum, resultando em uma perda de ativos de 120 milhões de dólares. O núcleo do ataque foi uma vulnerabilidade dupla envolvendo perda de precisão e manipulação do valor invariante (Invariant).

A infraestrutura da Chainlink mantém há muito tempo o mais alto padrão no setor Web3, tornando-se assim a escolha natural para a X Layer, que busca fornecer ferramentas de nível institucional para desenvolvedores.

O problema chave deste ataque reside na lógica do protocolo ao lidar com transações de pequeno valor. Quando um usuário realiza uma troca de baixo valor, o protocolo chama a função _upscaleArray, que utiliza mulDown para arredondar valores para baixo. Se o saldo e o valor de entrada da transação estiverem simultaneamente em um limite específico de arredondamento (por exemplo, na faixa de 8-9 wei), ocorre um erro relativo de precisão significativo.

O erro de precisão é transmitido para o cálculo do valor invariante D do protocolo, fazendo com que o valor de D seja anormalmente reduzido. A variação de D impacta diretamente o preço do BPT (Balancer Pool Token) no protocolo Balancer. O hacker explorou esse preço artificialmente baixo do BPT, realizando arbitragem por meio de uma rota de transação previamente planejada, resultando em uma grande perda de ativos.

Transação de exploração da vulnerabilidade (Tx):

Transação de transferência de ativos (Tx):

Análise Técnica

Ponto de Entrada do Ataque

O ponto de entrada do ataque foi o contrato Balancer: Vault, com a função de entrada batchSwap, que internamente chama onSwap para realizar a troca de tokens.

A partir dos parâmetros e restrições da função, podemos obter algumas informações:

1. O atacante precisa chamar essa função por meio do Vault, não podendo chamá-la diretamente.

2. Dentro da função, _scalingFactors() é chamado para obter fatores de escala para a operação de escalonamento.

3. As operações de escalonamento estão concentradas em _swapGivenIn ou _swapGivenOut.

Análise do Modo de Ataque

Mecanismo de Cálculo do Preço do BPT

No modelo de pool estável do Balancer, o preço do BPT é uma referência importante, determinando quanto BPT o usuário recebe e quanto de ativos cada BPT representa.

No cálculo de trocas do pool:

A parte que serve como referência do preço do BPT é o valor invariante D, ou seja, para manipular o preço do BPT é necessário manipular D. Abaixo, analisamos o processo de cálculo de D:

No código acima, o cálculo de D depende do array balances já escalonado. Ou seja, é necessário haver uma operação que altere a precisão desses balances, levando a um erro no cálculo de D.

Raiz da Perda de Precisão

Operação de escalonamento:

Como mostrado acima, ao usar _upscaleArray, se o saldo for muito pequeno (como 8-9 wei), o arredondamento para baixo do mulDown causa uma perda de precisão significativa.

Detalhamento do Processo de Ataque

Fase 1: Ajuste para o Limite de Arredondamento

Fase 2: Disparo da Perda de Precisão (Vulnerabilidade Central)

Fase 3: Lucro com o Preço do BPT Artificialmente Baixo

Como mostrado acima, o atacante executa múltiplas trocas em uma única transação usando o Batch Swap:

1. Primeira troca: BPT → cbETH (ajuste de saldo)

2. Segunda troca: wstETH (8) → cbETH (disparo da perda de precisão)

3. Terceira troca: ativo subjacente → BPT (lucro)

Todas essas trocas ocorrem na mesma transação batch swap, compartilhando o mesmo estado de saldo, mas cada troca chama _upscaleArray para modificar o array balances.

Ausência de Mecanismo de Callback

O fluxo principal é iniciado pelo Vault, mas como isso leva ao acúmulo da perda de precisão? A resposta está no mecanismo de transmissão do array balances.

Analisando o código acima, embora o Vault crie um novo array currentBalances a cada chamada de onSwap, no Batch Swap:

1. Após a primeira troca, o saldo é atualizado (mas devido à perda de precisão, o valor atualizado pode estar incorreto)

2. A segunda troca é calculada com base no resultado da primeira

3. A perda de precisão se acumula, levando a uma redução significativa do valor invariante D

Questão Chave:

Resumo

O ataque ao Balancer pode ser resumido nas seguintes causas:

1. Função de escalonamento usa arredondamento para baixo: _upscaleArray utiliza mulDown para escalonar, e quando o saldo é muito pequeno (como 8-9 wei), ocorre uma perda relativa de precisão significativa.

2. Cálculo do valor invariante é sensível à precisão: O cálculo do valor invariante D depende do array balances escalonado, e a perda de precisão é transmitida diretamente para o cálculo de D, reduzindo seu valor.

3. Falta de verificação da variação do valor invariante: Durante as trocas, não há verificação se a variação de D está dentro de um intervalo razoável, permitindo que o atacante explore repetidamente a perda de precisão para reduzir o preço do BPT.

4. Acúmulo de perda de precisão em Batch Swap: Em uma mesma batch swap, a perda de precisão de múltiplas trocas se acumula, resultando em grandes perdas financeiras.

Esses dois problemas — perda de precisão e falta de verificação — combinados com o design cuidadoso das condições de fronteira pelo atacante, resultaram nesta perda.