Analisi tecnica: Come è stato hackerato Balancer per 120 milioni di dollari?

Titolo originale dell'articolo: "Analisi tecnica della vulnerabilità dell'hack da 120M$ di Balancer"
Fonte originale: ExVul Security

Prefazione

Il 3 novembre 2025, il protocollo Balancer è stato attaccato su più chain, tra cui Arbitrum ed Ethereum, con una perdita di asset di 120 milioni di dollari. L'attacco è stato causato principalmente da una doppia vulnerabilità che ha coinvolto la perdita di precisione e la manipolazione dell'invariante.

L'infrastruttura di Chainlink mantiene da tempo i più alti standard nello spazio Web3, rendendola una scelta naturale per X Layer, che si dedica a fornire strumenti di livello istituzionale per gli sviluppatori.

Il problema chiave di questo attacco risiede nella logica del protocollo per la gestione delle piccole transazioni. Quando gli utenti effettuano scambi con piccoli importi, il protocollo richiama la funzione _upscaleArray, che utilizza mulDown per arrotondare i valori per difetto. Quando il saldo nella transazione e l'importo in ingresso raggiungono entrambi un limite di arrotondamento specifico (ad esempio, l'intervallo di 8-9 wei), si verifica un notevole errore di precisione relativa.

Questo errore di precisione viene propagato al calcolo del valore invariante D del protocollo, causando una riduzione anomala del valore D. La fluttuazione del valore D abbassa direttamente il prezzo del Balancer Pool Token (BPT) nel protocollo Balancer. L'hacker ha sfruttato questo prezzo BPT soppresso attraverso un percorso di trading premeditato per condurre arbitraggio, portando infine a una massiccia perdita di asset.

Transazione sfruttata:

https://etherscan.io/tx/0x6ed07db1a9fe5c0794d44cd36081d6a6df103fab868cdd75d581e3bd23bc9742

Transazione di trasferimento asset:

https://etherscan.io/tx/0xd155207261712c35fa3d472ed1e51bfcd816e616dd4f517fa5959836f5b48569

Analisi tecnica

Vettore di attacco

Il punto di ingresso dell'attacco è stato il contratto Balancer: Vault, con la funzione di ingresso corrispondente batchSwap, che internamente chiama onSwap per gli scambi di token.

Dal punto di vista dei parametri e delle restrizioni della funzione, si possono ottenere diverse informazioni:

1. L'attaccante deve chiamare questa funzione tramite il Vault e non può chiamarla direttamente.

2. La funzione chiamerà internamente _scalingFactors() per ottenere il fattore di scala per le operazioni di ridimensionamento.

3. L'operazione di ridimensionamento è concentrata in _swapGivenIn o _swapGivenOut.

Analisi del modello di attacco

Meccanismo di calcolo del prezzo BPT

Nel modello di pool stabile di Balancer, il prezzo BPT è un punto di riferimento cruciale che determina quanto BPT riceve un utente e quanto ogni BPT riceve in asset.

Nel calcolo dello scambio del pool:

Dove la parte che funge da ancora del prezzo BPT è un valore immutabile D, il che significa che controllare il prezzo BPT richiede il controllo di D. Analizziamo ulteriormente il processo di calcolo di D:

Nel codice sopra, il processo di calcolo di D dipende dall'array dei saldi scalati. Ciò significa che è necessaria un'operazione per modificare la precisione di questi saldi, portando a un calcolo errato di D.

Causa principale della perdita di precisione

Operazione di ridimensionamento:

Come mostrato sopra, quando si passa attraverso _upscaleArray, se il saldo è molto piccolo (ad esempio, 8-9 wei), l'arrotondamento per difetto in mulDown comporterà una significativa perdita di precisione.

Processo di attacco dettagliato

Fase 1: Regolazione al limite di arrotondamento

Fase 2: Attivazione della perdita di precisione (vulnerabilità principale)

Fase 3: Sfruttamento del prezzo BPT depresso per profitto

Sopra, l'attaccante utilizza Batch Swap per eseguire più scambi in una sola transazione:

1. Primo scambio: BPT → cbETH (regolazione del saldo)

2. Secondo scambio: wstETH (8) → cbETH (attivazione della perdita di precisione)

3. Terzo scambio: Asset sottostante → BPT (presa di profitto)

Tutti questi scambi avvengono nella stessa transazione di batch swap, condividendo lo stesso stato del saldo, ma ogni scambio chiama _upscaleArray per modificare l'array dei saldi.

Mancanza di meccanismo di callback

Il processo principale è avviato dal Vault. Come porta questo all'accumulo di perdita di precisione? La risposta risiede nel meccanismo di passaggio dell'array dei saldi.

Guardando il codice sopra, sebbene Vault crei un nuovo array currentBalances ogni volta che viene chiamato onSwap, in Batch Swap:

1. Dopo il primo swap, il saldo viene aggiornato (ma a causa della perdita di precisione, il valore aggiornato potrebbe essere impreciso)

2. Il secondo swap continua il calcolo basandosi sul risultato del primo swap

3. La perdita di precisione si accumula, causando infine una diminuzione significativa del valore invariante D

Problema chiave:

Riepilogo

L'attacco a Balancer può essere riassunto per i seguenti motivi:

1. La funzione di ridimensionamento utilizza l'arrotondamento per difetto: _upscaleArray utilizza mulDown per il ridimensionamento, il che comporta una significativa perdita di precisione relativa quando il saldo è molto piccolo (ad esempio, 8-9 wei).

2. Il calcolo del valore invariante è sensibile alla precisione: Il calcolo del valore invariante D si basa sull'array dei saldi scalati, e la perdita di precisione influisce direttamente sul calcolo di D, causandone la diminuzione.

3. Mancanza di convalida della variazione del valore invariante: Durante il processo di swap, non c'era alcuna convalida per garantire che la variazione del valore invariante D fosse entro un intervallo ragionevole, consentendo agli attaccanti di sfruttare ripetutamente la perdita di precisione per sopprimere il prezzo BPT.

4. Accumulo di perdita di precisione nei Batch Swaps: All'interno dello stesso batch swap, la perdita di precisione da più swap si accumula e porta infine a significative perdite finanziarie.

Questi due problemi — perdita di precisione e mancanza di convalida — combinati con l'attenta progettazione delle condizioni al contorno da parte dell'attaccante, hanno portato a questa perdita.

Questo articolo è un contributo e non rappresenta le opinioni di BlockBeats.