Technical Background of Balancer V2 Composable Stable Pools Sfondi tecnici di Balancer V2 Composable Stable Pools di : Pool Structure and How It Works I Composable Stable Pools sono costruiti sulla matematica ispirata al modello StableSwap di Curve. What is a Composable Stable Pool? Questi pool sono progettati per consentire agli asset con valori quasi identici, come USDC e DAI, o stETH e ETH, di scambiarsi con un minimo slittamento. **What makes them “composable”?
\ The pool’s LP token (BPT) is a standard ERC-20 token that can be reused across the ecosystem, for example, in other pools or as collateral. This allows liquidity to be seamlessly composed throughout the system. **How it works
\ A Composable Stable Pool can hold multiple tokens, and its invariant DDD is calculated using the following polynomial equation: Nel suo equilibrio polli (ispirati da Curve), gli swap sono calcolati mantenendo un (D) quanto più costante possibile. Quando si verifica uno swap, i saldi dei token si spostano in un nuovo stato che mantiene questo invariante. Hai deciso di ottenere il del token che stai risolvendo, dato che (D) rimane fisso. stable invariant quadratic new balance (x) Termini 
 
 
 
 
 
 
 (x): il nuovo saldo (post-swap) del token per il quale si sta risolvendo. (S): la somma dei saldi degli altri token (escluso (x)). (P): il prodotto dei saldi degli altri token (escluso (x)). (D): il pool invariante (diretto a rimanere costante in tutto lo swap). (A): il parametro di amplificazione (flatta la curva → scorrimento più basso per le attività ugualmente valorizzate). (n): il numero di token nel pool. Intuizione: comprimiamo “tutti gli altri token” in due aggregati, (S) e (P). . quadratic in (x) Perché il quadratico? Dopo aver isolato il nuovo saldo del token sconosciuto e aver piegato il resto in (S) e (P), la condizione invariante si riduce a un polinomiale di secondo grado in (x). Risolverlo Scegli la radice che è e L’altra radice è tipicamente negativa o insensata. Which root? positive economically valid Un semplice esempio Setup (2 tokens, large A → very low slippage) 
 
 
 
 
 Saldi iniziali interni (scalati): token0 = 1.000.000; token1 = 1.000.000 Numero di token: n = 2 Amplificazione: A = 1000 Con grande A, D ≈ 2.000.000 Action 
 
 Si aggiungono 10.000 unità di token0 (EXACT_IN). Quadratic to solve x^2 + (S - D/(A*n^n) - D)*x - D^(n+1)/(A*n^(2n)*P) = 0 Dove è: di , e è il saldo post-swap di token1. S = 1,010,000 P = 1,010,000 x Solution x ≈ 990,999.546 Amount out amountOut = 1,000,000 - 990,999.546 ≈ 9,000.454 Interpretation 
 
 
 Inserisci 10.000 di token0 e riceverai ~9,000.45 di token1 → basso scorrimento con grande A. Tutti i matematici utilizzano unità interne a 18 decimali; le implementazioni arrotondano per la sicurezza. Dove viene utilizzato (alto livello) 
 
 
 EXACT_IN: si aumenta il token di input; risolvere per il nuovo saldo del contra-token (x); la differenza dal suo vecchio saldo è l'importo fuori. EXACT_OUT: si mira a un determinato importo ricevuto; risolvere per il necessario (x) (e quindi l'ingresso richiesto). Questo percorso è più numericamente sensibile (root-finding + rounding). Note pratiche 
 
 
 All balances are handled internally at   (scaled); calculations typically   to be pool-safe. 18 decimals round down Un più grande (A) rende la curva più costante-sum-like (piccola scivolatura per coppie stabili); un più piccolo (A) è più vicino al comportamento di prodotto costante. 
 
 TL;DR: Questa equazione è il quadrato del cavallo di lavoro che, sotto un invariante fisso (D), ti dà il nuovo saldo token (x) dopo uno swap. I coefficienti codificano "il resto del pool" attraverso (S) e (P), mentre (A) e (n) stabiliscono la forma / piattaforma della curva stabile. Questa equazione è la che, sotto un invariante fisso (D), ti dà la I coefficienti codificano “il resto del pool” tramite (S) e (P), mentre (A) e (n) stabiliscono la forma/piattaforma della curva stabile. TL;DR: workhorse quadratic new token balance (x) La piscina fornisce a tra le banconote, catturate da un . balance relationship invariant D Quando si scambia, un saldo sale, un altro scende e il pool trova un Ecco come emerge il prezzo. new balance that keeps D as constant as possible Il pool utilizza fattori di scalazione per normalizzare i token a 18 decimali. Operazione Upscale regola i bilanci alla precisione interna e utilizza arrotondamento verso il basso. Swap Types 
 
 
 EXACT_IN (GIVEN_IN): Importo di input fisso, calcolare l'uscita. EXACT_OUT (GIVEN_OUT): Importo di uscita fisso, calcolare l'ingresso. Vault e BatchSwapBalancer Vault gestisce tutte le operazioni. BatchSwap combina più swaps in una singola transazione e utilizza il "deferred settlement" come i flashloans. 1 - Analisi di sfruttamento 1.1 The Attack On November 3, 2025, at around 7:40 AM UTC, specific Balancer v2 stable pools were targeted with a sophisticated attack that resulted in a cumulative loss of $120+ million across Balancer and its forks. The attack leveraged several circumstances: 
 
 
 
 
 La maggior parte dei pool mirati sono stati esempi del contratto ComposableStablePool. un pool speciale progettato per gli asset che si aspettano di scambiare costantemente a quasi parità o a un tasso di cambio noto. La funzionalità batchSwap del contratto Balancer Vault consente agli swap transitori di avvenire prima della necessità di liquidare le delte in sospeso. L'attacco era redditizio in scenari di bassa liquidità. L'attaccante doveva preparare grandi swap in modo che i saldi dei pool potessero essere portati a bassa liquidità di uno o l'altro token. Il modo più utilizzato per ottenere questo era quello di scambiare token LP per token pool, lasciando il pool in uno stato di bassa liquidità. Tutto quanto sopra è semplicemente necessario, ma non circostanze conclusive, con l'unica circostanza necessaria per questo accadere è la causa principale del problema, un comportamento di arrotondamento nella funzione _upscale. Il vettore di attacco è stato introdotto per la prima volta il 16 luglio 2021, quando MetaStablePool ha superato il La stessa modifica è stata successivamente applicata il 1 settembre 2021, per i pool lineari a commit 4e9e70a e il 20 settembre 2021, a commit f450760 per StablePhantomPool, successivamente rinominato ComposableStablePool. _scalingFactors Nella descrizione del problema qui sotto, spieghiamo perché l'introduzione di questo override era al centro dell'attacco. 1.2 La questione La funzione batchSwap del contratto Vault è il punto di ingresso per questo attacco. L'attaccante ha creato una chiamata a esso, mirando le istanze di ComposableStablePool. La logica pertinente nel contratto Vault che porta all'interazione di ComposableStablePool è definita da questo flusso: batchSwaps → chiama internamente _swapWithPools → che chiama internamente un pool per ogni swap a _swapWithPool → _processGeneralPoolSwapRequest → chiama finalmente onSwap sul ComposableStablePool. Una volta atterrato in ComposableStablePool, l'esecuzione continua all'interno del gancio onSwap, dove accadono due cose: 
 
 
 The call to   function. _scalingFactors La consegna a _swapGivenOut come definito nell'esempio di transazione fornito sopra. Si noti che l'attaccante potrebbe aver deciso di prendere il modello _swapGivenIn, ma le entrate fornite nella transazione di attacco mostrano chiaramente la scelta. Questa funzione chiamerà la funzione _upscale. Diamo un'occhiata a queste due funzioni. Scalare i fattori function _scalingFactors() internal view virtual override returns(uint256[] memory) {
    uint256 totalTokens = _getTotalTokens();
    uint256[] memory scalingFactors = new uint256[](totalTokens);

    for (uint256 i = 0; i < totalTokens; ++i) {
        scalingFactors[i] = _getScalingFactor(i).mulDown(_getTokenRate(i));
    }

    return scalingFactors;
}
 Questa funzione fa due cose: 
 
 
 Scala qualsiasi importo a un numero fisso di decimali come suggerito dalla funzione _getScalingFactor e ciò che restituisce. Esso fattori nel tasso di cambio token moltiplicandolo per il fattore di scalazione e dividendo per 1e18. - ascensore function _upscale(uint256 amount, uint256 scalingFactor) pure returns (uint256) {
    /* Upscale rounding wouldn't necessarily always go in the same direction: 
in a   swap for example the balance of token in should be 
rounded up, and that of token out rounded down. This
is the only place where we round in the same direction for all amounts, 
as the impact of this rounding is expected to be minimal. */

    return FixedPoint.mulDown(amount, scalingFactor);
}
 Questo esegue semplicemente una moltiplicazione della quantità con il suo fattore di scalabilità, dividendo per 1e18 alla fine. Il problema sta in due fatti: 
 
 
 Queste funzioni rotolano sempre verso il basso (mulDown) indipendentemente dalla direzione dello swap. If amounts are orders of magnitude less than scalingFactors ones, the precision loss becomes non-negligible. In the attacker transaction, a typical value of amount and scaling factor is: amount: "17"scalingFactor: "1058132408689971699" Se si calcola Noi otteniamo , ma dal momento che Solidity trunca decimali, questo diventa che si traduce in a In quella La funzione. amount * scalingFactor / 1e18 17.98 17 0% net change _upscale Considera una quantità di (un token con 18 decimali). il risultato è Per rappresentare a - che riflette correttamente il tasso. 17,000000000000000000 17.988250950000000000 5.8% increase Allo stesso modo, per un token con (come la maggior parte delle stablecoins hanno), utilizzando una quantità di donazioni che corrisponde quasi allo stesso . 6 decimals 17,000000 17.988250 5.8% positive change La truncazione è massimizzata facendo il più grande possibile, quindi il prodotto perde la massima precisione quando diviso per 1e18. amount*scalingFactor mod 1e18 Ad esempio, nella tabella qui sotto, somma=17 e somma=50 producono entrambi una perdita assoluta arrotondata di circa 0,90. Tuttavia, l'errore come percentuale dell'importo differisce significativamente, e la percentuale di aumento perduto diverge ancora di più, poiché la stessa perdita assoluta è molto più grande rispetto a 17 che a 50. esempi Esempi di errore di arrotondamento del pavimento quando si scala per un fattore di 1.058132408689971699 
 
 
 
 
 
 
 
 
 
 
 
 amount 
 upscale 
 error 
 %error 
 %increase lost 
 
 
 
 
 
 
 17 
 17 
 0.98 
 5.76% 
 100% 
 
 
 
 
 
 
 50 
 52 
 0.90 
 1.80% 
 17% 
 
 
 
 
 
 
 ... 
 ... 
 ... 
 ... 
 ... 17 17 0.98 Il 5,76% Il 100% 50 52 0.90 Il 1,80% Il 17% ... di ... di ... di ... di ... di Il La funzione utilizzerà successivamente questi valori arrotondati per calcolare l'importo dovuto dall'attaccante al pool dopo lo swap. Questo valore viene deflatato artificialmente, rendendo lo swap più economico. Sono complessi, e giustificano anche perché questo può essere raggiunto in pool dove stati di bassa liquidità possono essere ottenuti a volontà. Questo è dovuto a un controllo invariante che assicura la convergenza in una certa misura. _swapGivenOut _swapGivenOut In definitiva, con un numero elevato di iterazioni, i delti dopo il batchSwap sono gonfiati, credendo all'attaccante la maggior parte dei fondi nel pool. Inoltre, c'è un'osservazione pertinente da fare sulle doctrine in linea _upscale: /* Upscale rounding wouldn't necessarily always go in the same direction: in a swap for example the balance of token in should be rounded up, and that of token out rounded down. This is the only place where we round in the same direction for all amounts, as the impact of this rounding is expected to be minimal. */
 Una versione precedente di questo commento aveva una nota aggiuntiva: /* …as the impact of this rounding is expected to be minimal (and there's no rounding error unless `_scalingFactor()` is overriden). */
 Questo è importante perché la Introdotto in e successivamente rinominato a Eseguire esattamente il Il ritorno discusso sopra. StablePhantomPool September 20, 2021 ComposableStablePool _scalingFactor In precedenti versioni di , il  function only accounted for differences in token decimals. In the newer implementation, however, it also incorporates the  segnare un cambiamento fondamentale. StablePool _scalingFactor exchange rate Come sottolineato nel funzione, il codice è evoluto dall'utilizzo di (per esempio ) to  Questo cambiamento, pur funzionalmente necessario, introduce il potenziale Con loro, una nuova . _upscale unitary scaling factors 1e12 non-unitary exchange rates rounding errors attack vector Mentre consentire l'errore di arrotondamento era la causa principale, sfruttarlo richiedeva sfruttamento di meccaniche di protocollo aggiuntive e passaggi di attacco specifici. Il batchSwap di Balancer consente saldi interni transitori che sono net-settolati solo alla fine del batch.Grazie a questo, l'attaccante ha effettivamente "prestato" BPT all'interno di un batch per manipolare il pool senza dover terminare la transazione che detiene BPT. Un BPT (Balancer Pool Token) è un ERC-20 che rappresenta una quota proporzionale di un pool di Balancer. In alcuni progetti di pool, tra cui i ComposableStablePools mirati, il BPT può anche apparire come un asset di pool ed essere negoziabile / scambiabile. La prima fase ha spinto i saldi dei token del pool (ad esempio, WETH / osETH) a livelli molto bassi (quasi 100k) scambiando ripetutamente BPT per token1 e BPT per token2. L'obiettivo è massimizzare la parte frazionaria scartata in aritmetica del pavimento, cioè massimizzare la quantità * scalingFactor mod 1e18 in modo che il prodotto perda la massima precisione possibile quando diviso per 1e18. L'exploit viene eseguito ripetendo tripleti di swap: 
 
 
 
 Prime: spostare il pool in uno stato in cui si verificherà la troncazione nella successiva operazione. Nella schermata qui sotto, uno scambio di WETH a osETH Exploit: eseguire lo swap che realizza la perdita di arrotondamento. Nella screenshot, uno swap di 17 WETH per osETH. Reset: ripristinare gli equilibri in modo che il triplet possa essere riprodotto. Nella schermata è lo scambio di osETH a WETH. Come mostrato nella traccia qui sotto, lo swap critico utilizza spesso un importo=17 contro un saldo di cassa di 18.Puoi vedere i 17 importi ripetuti nel secondo swap di ogni triplet. Avanzare le migliori pratiche di sicurezza: lezioni per l'industria Questo incidente ha suscitato un dibattito sull'efficacia delle revisioni di sicurezza dei contratti intelligenti, con alcuni commentatori che si chiedono se forniscono valore.Mentre questo sentimento può essere comprensibile nel momento della frustrazione, non riconosce perché le revisioni di sicurezza sono diventate una migliore prassi del settore e l'enorme impatto che la pratica di revisione di sicurezza ha avuto sulla mitigazione del rischio e sulla protezione degli utenti nel corso dell'ultimo decennio. Le aziende di sicurezza prevengono collettivamente centinaia di potenziali sfruttamenti ogni anno. OpenZeppelin da solo ha identificato oltre 700 vulnerabilità critiche e di alta gravità prima di raggiungere la produzione in tutti i nostri audit. Questi disastri prevenuti non fanno titoli, ma rappresentano miliardi di utenti protetti e innumerevoli utenti salvati dalle perdite. La vera lezione non è che le revisioni siano inefficaci – è che le pratiche di audit del settore non hanno ancora catturato quanto velocemente si evolvono i protocolli complessi che assicurano un valore significativo. Poiché le revisioni sono spesso mirate come revisioni isolate piuttosto che impegni continui, il contesto può essere perso man mano che si evolvono le basi di codice. 2.1 Stabilire la sicurezza continua come standard del settore Dal momento che abbiamo pionierato la pratica dell'audit dei contratti intelligenti nel 2016, abbiamo visto come i risultati di sicurezza più riusciti provengano da partnership di sicurezza in corso che coprono intere basi di codice di protocolli e tutte le loro modifiche nel tempo, piuttosto che revisioni di codice ad hoc di importanti aggiornamenti, che sono spesso limitati in portata a solo quei cambiamenti. Quando i ricercatori di sicurezza lavorano continuamente con i protocolli, sviluppano una profonda familiarità con l'architettura del protocollo, i processi di ingegneria e il motivo per cui sono state prese determinate decisioni di progettazione. Sebbene il codebase Balancer v2 sia stato rivisto da quattro società di audit indipendenti, ciascuna si è impegnata a concentrarsi su diversi ambiti del protocollo.L'impegno di più revisori aiuta a ridurre la probabilità di mancanza di vulnerabilità, ma il mantenimento di almeno un partner di sicurezza a lungo termine fornisce una comprensione più profonda e continua di come il codebase si evolve e come i nuovi cambiamenti interagiscono con la logica esistente. 2.2 Creazione di migliori quadri di sicurezza Attraverso il nostro decennio di esperienza, OpenZeppelin ha lavorato costantemente per stabilire e elevare gli standard di sicurezza in tutto il settore. I contratti OpenZeppelin sono diventati lo standard di fatto per la costruzione di contratti intelligenti sicuri, attualmente alimentando oltre $ 30 trilioni di valore totale trasferito in tutto l'ecosistema. Proprio come questi contratti hanno messo le basi per lo sviluppo sicuro, abbiamo lavorato attivamente sugli sforzi per stabilire standard più robusti per la valutazione della sicurezza e la protezione del protocollo continuo. Oltre alle relazioni a lungo termine con i nostri clienti, stiamo lavorando attivamente per modellare questi standard sia a livello industriale che regolamentare. ad esempio, OpenZeppelin contribuisce agli organismi che stabiliscono gli standard del settore, come il Consiglio per gli Standard di Sicurezza Blockchain, l'Enterprise Ethereum Alliance e l'International Standards Organization (ISO), per garantire che le migliori pratiche di sicurezza che il nostro team e la comunità hanno aiutato a pionieri siano disponibili per l'intero settore. In particolare, OpenZeppelin ha collaborato con il Dipartimento del Tesoro degli Stati Uniti, la Securities and Exchange Commission degli Stati Uniti, la Financial Conduct Authority del Regno Unito e l'ACPR francese e l'AMF per quanto riguarda i vantaggi di condurre audit di sicurezza completi su base regolare. Inoltre, abbiamo esplorato il potenziale per creare un'organizzazione di autoregolamentazione dedicata simile agli auditori in altri settori che riteniamo possano aiutare a formalizzare gli standard e le metodologie di audit di sicurezza per la tecnologia blockchain, impostare requisiti di qualità ed etica per gli auditori e gestire l'accreditamento per certificare auditori qualificati, che potrebbe migliorare i risultati di sicurezza e aumentare la fiducia dei consumatori. 2.3 Rafforzare l'ecosistema di sicurezza Blockchain insieme Ogni incidente di sicurezza fornisce preziose informazioni che guidano il miglioramento in tutto il nostro settore.L'esplorazione di Balancer v2 rafforza che, man mano che i protocolli diventano più preziosi e sofisticati, diventa fondamentale per i team di protocolli investire nella sicurezza in corso, nonché per l'audit delle aziende per costruire framework che lo supportano.

This story contains new, firsthand information uncovered by the writer.

2022 - HackerNoon Contributor of the Year - Bots

2022 - HackerNoon Contributor of the Year - Solidity

Nominated for 2022 - HackerNoon Contributor of the Year - Solidity

Nominated for 2022 - HackerNoon Contributor of the Year - Bots

Questo audio è prodotto nella lingua originale della storia!

Balancer V2 sfruttamento spiegato: all'interno del contratto intelligente rounding errore che costa $ 120M

About Author

COMMENTI

CARTELLINI

QUESTO ARTICOLO È STATO PRESENTATO IN

Related Stories

OpenAI Has Everything Under Control 😎

Coding with Latenode's AI + JavaScript Assistant: A Low-Code Platform for Simplified Development

HackerNoon - A User Experience Analysis: Part 2

Link-To-Earn Incentive Model: A Blueprint For Mass Adoption?

OpenAI Has Everything Under Control 😎

Coding with Latenode's AI + JavaScript Assistant: A Low-Code Platform for Simplified Development

HackerNoon - A User Experience Analysis: Part 2

Link-To-Earn Incentive Model: A Blueprint For Mass Adoption?

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps