Análise preliminar do evento de ataque ao Balancer V2

No dia 3 de novembro, o protocolo Balancer V2 e seus projetos fork sofreram ataques em várias cadeias, resultando em perdas severas de mais de $120M. A BlockSec emitiu um alerta em tempo real [1] e forneceu uma conclusão de análise preliminar [2]. Este é um incidente de ataque altamente complexo. Nossa análise preliminar indica que a causa raiz está na manipulação de invariantes (invariant) pelos atacantes, distorcendo assim o cálculo do preço do BPT (Balancer Pool Token ) – que é o token LP da pool – permitindo que eles lucrassem através de uma operação batchSwap em algum pool estável (stable pool).

Conhecimentos de fundo

1. Escalonamento (scaling) e arredondamento (rounding)

Para unificar as casas decimais de diferentes tokens, o contrato Balancer irá:

• upscale: aumentar o saldo e o montante para uma precisão interna uniforme antes de realizar o cálculo;
• downscale：reduzir o resultado à precisão nativa, realizando um arredondamento direcionado (por exemplo, a entrada geralmente arredonda para cima, garantindo que o pool não perca; o caminho de saída frequentemente tem truncamento para baixo).

Conclusão: Dentro da mesma transação, a direção de arredondamento utilizada em diferentes etapas não é simétrica, e quando executada repetidamente em pequenos passos, pode resultar em um desvio sistemático pequeno.

2. D e o preço do BPT

O que foi afetado por este ataque é o Composable Stable Pool [3] do protocolo Balancer V2 e o protocolo fork. O Stable Pool é utilizado para ativos que se espera que mantenham uma taxa de câmbio próxima de 1:1 (ou que sejam trocados a uma taxa de câmbio conhecida), permitindo trocas grandes sem causar um impacto significativo nos preços, aumentando assim significativamente a eficiência do uso de capital entre ativos semelhantes ou relacionados.

• Este pool utiliza Stable Math (modelo StableSwap baseado em Curve), onde a invariante D representa o “valor total virtual” do pool.
• BPT (Pool do Token LP ) preço aproximado é:

A partir da fórmula acima, pode-se ver que, se conseguir fazer com que D diminua no balanço (mesmo que o capital não tenha realmente sido perdido), o preço do BPT poderá ser mais barato. O BPT representa a quota do Pool, e é utilizado para calcular quanto da Reserva do Pool se pode obter ao retirar a liquidez, portanto, se um atacante conseguir obter mais BPT, acabará por lucrar ao retirar a liquidez.

Análise de Ataque

Tomando como exemplo uma transação de ataque na Arbitrum, a operação batchSwap pode ser dividida em três fases:

Primeira fase: O atacante troca BPT por ativos subjacentes, a fim de ajustar com precisão o saldo de um dos tokens (cbETH) até o ponto crítico do limite de arredondamento (quantidade = 9). Este passo cria condições para a perda de precisão na próxima fase.

Fase dois: O atacante utiliza uma quantidade cuidadosamente construída (= 8) para trocar entre um outro ativo subjacente (wstETH) e cbETH. Devido ao arredondamento para baixo ao escalar a quantidade de tokens, o Δx calculado é ligeiramente menor (de 8.918 para 8), o que resulta em uma subestimação de Δy e faz com que a invariável D (proveniente do modelo StableSwap da Curve) diminua. Como o preço do BPT = D / totalSupply, o preço do BPT é artificialmente pressionado para baixo.

Terceira fase: O atacante irá reverter os ativos subjacentes de volta para BP, enquanto restabelece o equilíbrio na piscina, lucrando com o preço do BP que foi reduzido – obtendo mais BPT Token.

Por fim, o atacante utilizou outra transação lucrativa para retirar liquidez, aproveitando-se do BPT obtido para lucrar com outros ativos subjacentes no Pool, (cbETH e wstETH).

Transação de ataque:

Negociação lucrativa:

Referência:

[1]

[2]

[3]