[Thread in inglese] Analisi approfondita dell'attacco a Balancer V2: meccanismo della vulnerabilità, fasi dell'attacco e lezioni apprese

Chainfeeds Guida alla lettura:

L'attaccante ha deliberatamente impostato i parametri, inclusi il numero di iterazioni e l'importo di input, per massimizzare l'effetto della perdita di precisione.

Fonte dell'articolo:

Autore dell'articolo:

BlockSec

Opinione:

BlockSec: Il 3 novembre 2025, la Composable Stable Pool di Balancer V2, insieme a diversi progetti on-chain basati sul suo fork, è stata vittima di un attacco coordinato cross-chain, causando una perdita totale superiore a 125 milioni di dollari. BlockSec ha emesso un avviso tempestivo e successivamente ha pubblicato un'analisi preliminare. Si è trattato di un attacco altamente complesso. Le nostre indagini mostrano che la causa principale deriva dalla perdita di precisione nei calcoli dell'invariante, che ha permesso la manipolazione dei prezzi tramite questa perdita di precisione, influenzando così il prezzo del BPT (Balancer Pool Token). L'attaccante ha sfruttato un'unica operazione batchSwap per trarre profitto da specifiche stable pool. Il componente interessato è la Composable Stable Pool di Balancer V2. Questo tipo di pool è progettato per asset che si prevede mantengano un rapporto di cambio vicino a 1:1, consentendo grandi operazioni con uno slippage minimo e migliorando notevolmente l'efficienza del capitale tra asset simili o correlati. Ogni pool ha il proprio BPT, il cui prezzo può essere approssimato dalla formula: Prezzo BPT = D / totalSupply, dove D è l'invariante nella matematica delle stable pool, rappresentando il valore totale virtuale del pool. Dalla formula si può vedere che, se D viene matematicamente ridotto (anche se i fondi reali non vengono persi), il prezzo del BPT apparirà più basso. Balancer V2 offre la funzione batchSwap(), che consente swap multi-hop all'interno del Vault, con due modalità in SwapRequest: GIVEN_IN e GIVEN_OUT. In modalità GIVEN_OUT, il chiamante specifica l'importo di output desiderato e il pool calcola l'importo di input necessario. Nelle stable pool, quando si calcola l'importo di input necessario (amountIn), è necessario risolvere un'equazione polinomiale secondo la formula dell'invariante; questi calcoli vengono eseguiti tramite Upscaling e Downscaling. In teoria, le due operazioni sono opposte, ma nell'implementazione reale presentano arrotondamenti in direzioni diverse: l'upscaling utilizza solo l'arrotondamento per difetto (mulDown), mentre il downscaling può arrotondare sia per eccesso che per difetto (divUp/divDown). Questa incoerenza ha lasciato spazio all'attacco. La radice della vulnerabilità risiede nell'uso dell'arrotondamento per difetto durante l'upscaling di swapRequest.amount in BaseGeneralPool._swapGivenOut(). Il valore arrotondato per difetto viene utilizzato come amountOut nell'input di _onSwapGivenOut(), portando a un amountIn finale inferiore a quello realmente necessario, violando il principio secondo cui l'arrotondamento dovrebbe sempre favorire il protocollo. Per pool come (wstETH/rETH/cbETH), l'attaccante può scambiare una quantità minore di un asset per ottenere una quantità maggiore di un altro asset, riducendo l'invariante D e quindi abbassando il prezzo del BPT. L'attaccante ha eseguito un attacco in due fasi. Nella prima fase, la logica principale dell'attacco viene completata in una singola transazione, ma senza realizzare immediatamente un profitto; nella seconda fase, il profitto viene prelevato tramite una transazione separata. La prima fase si divide in calcolo dei parametri e batch swap. Prendendo come esempio una transazione di attacco sulla chain Arbitrum (TX: 0x7da32e…55773), l'attaccante ottiene prima i parametri del pool, inclusi scaling factors, A (coefficiente di amplificazione), tasso BPT, swap fee, ecc., quindi calcola trickAmt e simula tramite un contratto ausiliario. L'attaccante combina calcoli offline e simulazioni on-chain per regolare con precisione i parametri dello swap successivo, inclusi il numero di iterazioni e i valori di input/output per ciascuna iterazione. Ogni iterazione esegue tre swap: nel primo step, la quantità di token target viene portata a trickAmt + 1; nel secondo step, si continua a swappare il token target, attivando l'arrotondamento per difetto di _upscale(); nel terzo step, si effettua uno swap inverso, riportando il saldo del pool a un valore troncato "rimuovendo le ultime due cifre decimali", ad esempio 324.816 → 320.000. In alcuni casi, poiché la matematica di StableSwap utilizza il metodo di Newton-Raphson, il calcolo può fallire, quindi l'attaccante ha preparato due fallback, riprovando con 9/10 del valore originale. Dopo l'attacco, poiché alcune meccaniche di Balancer non potevano essere sospese, l'impatto dell'attacco è stato amplificato e sono seguiti attacchi imitativi su più chain, portando la perdita totale a oltre 125 milioni di dollari. Questo evento ha evidenziato quattro problemi chiave nei protocolli decentralizzati: meccanismi di arrotondamento incoerenti, tecniche di attacco in continua evoluzione, impossibilità di sospendere il protocollo che amplifica le perdite, e mancanza di monitoraggio in tempo reale dello stato di inizializzazione e operatività. L'upscaling consente solo l'arrotondamento per difetto, mentre il downscaling consente entrambi i tipi di arrotondamento; questa asimmetria, con parametri estremi, può accumulare una perdita di precisione sfruttabile. L'arrotondamento, che dovrebbe sempre favorire il protocollo, in questo caso ha danneggiato gli interessi del protocollo stesso. L'attaccante ha utilizzato una tecnica in due fasi: nella prima fase esegue l'attacco senza profitto apparente, nella seconda fase effettua il prelievo separatamente, eludendo i modelli di monitoraggio on-chain. Ogni passaggio dell'attacco combina simulazioni off-chain e on-chain; il contratto ausiliario ha persino riutilizzato l'implementazione StableMath di Balancer, mantenendo anche i messaggi di errore identici. Dopo l'attacco, sono seguiti attacchi su più chain e molti progetti fork sono stati colpiti, dimostrando che, finché la matematica delle stable pool e la logica di arrotondamento sono coerenti, la vulnerabilità può propagarsi nell'ecosistema. L'evento dimostra che i protocolli DeFi necessitano di calcoli matematici più precisi, una verifica più rigorosa degli arrotondamenti e meccanismi di simulazione anti-path sospetti, oltre alla capacità di sospensione d'emergenza in caso di anomalie. [L'articolo originale è in inglese]