Technical Background of Balancer V2 Composable Stable Pools Tehnička pozadina Balancer V2 kompozitnih stabilnih bazena Uslovi : Pool Structure and How It Works Komposabilni stabilni bazeni su izgrađeni na matematici inspirisanoj modelom Curve StableSwap. What is a Composable Stable Pool? Ovi bazeni su dizajnirani tako da imovine s gotovo identičnim vrijednostima, kao što su USDC i DAI, ili stETH i ETH, mogu trgovati s minimalnim klizanjem. **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: U ravnoteži polovi (inspirirani krivuljom), razmjene se izračunavaju održavanjem (D) što je stalnije moguće. Kada se dogodi zamena, tokenske ravnoteže se kreću u novo stanje koje čuva ovu nepromjenjivu. Vi odlučite da dobijete od tokena za koji se rješavate, s obzirom na to da (D) ostaje fiksno. stable invariant quadratic new balance (x) Termini 
 
 
 
 
 
 
 (x): novi (post-swap) saldo tokena za koji se rešavate. (S): Suma ostataka drugih tokena (osim (x) ) (P): proizvod ostatka ostataka tokena (osim (x)). (D): bazni invariant (ciljan da ostane konstantan u svezi). (A): parametar pojačanja (plattens krivulju → niži klizanje za jednakovrijedne imovine). (n): broj žetona u bazenu. Intuicija: komprimiramo “sve druge žetone” u dva agregata, (S) i (P). . quadratic in (x) Zašto kvadrat? Nakon izolacije nove ravnoteže nepoznatog tokena i preklapanja ostatka u (S) i (P), invariantno stanje se smanjuje na polinom drugog stupnja u (x). Rešavanje Odaberite korijen koji je i Drugi koren je obično negativan ili besmislen. Which root? positive economically valid A Simple Example Setup (2 tokens, large A → very low slippage) 
 
 
 
 
 Interni (upskalirani) početni saldi: token0 = 1.000.000; token1 = 1.000.000 Broj tokena: n = 2 Amplifikacija: A = 1000 sa velikim A, D ≈ 2.000.000 Action 
 
 Dodajete 10.000 jedinica token0 (EXACT_IN). Quadratic to solve x^2 + (S - D/(A*n^n) - D)*x - D^(n+1)/(A*n^(2n)*P) = 0 gde je: U pitanju je i je token1 post-swap ravnoteža. 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 
 
 
 Stavite 10.000 od token0 i dobijate ~9,000.45 od token1 → nizak klizanje s velikim A. Sva matematika koristi 18-decimalne unutrašnje jedinice; implementacije okrugle prema dolje za sigurnost. Gde se koristi (visoki nivo) 
 
 
 EXACT_IN: povećavate ulazni token; riješite za novi saldo protivnog tokena (x); razlika od starog salda je iznos. EXACT_OUT: ciljate na određeni primljeni iznos; riješite za potreban (x) (a time i potrebni unos). Practical notes 
 
 
 Sve bilance se obrađuju interno na 18 decimalnih (skalanih); izračuni su obično zaokruženi da bi bili bezbedni. Veći (A) čini krivulju više konstantno-sum-like (mini klizanje za stabilne pare); manji (A) je bliže ponašanju konstantnog proizvoda. 
 
 TL;DR: Ova jednadžba je workhorse kvadratic koji, pod fiksnim invariantom (D), daje vam novi token balans (x) nakon zamjene. Koeficijenti kodiraju "ostatak bazena" preko (S) i (P), dok (A) i (n) postavljaju oblik / ravnost stabilne krivnje. Ova jednadžba je koji, pod fiksnom invariantom (D), daje vam Koeficijenti kodiraju "ostatak bazena" preko (S) i (P), dok (A) i (n) postavljaju oblik / ravnost stabilne krivulje. TL;DR: workhorse quadratic new token balance (x) Poljoprivredni sektor primjenjuje a između token balanse, uhvaćen od strane . balance relationship invariant D Kada zamijenite, jedna ravnoteža ide gore, druga ide dole, a bazen pronalazi Tako se pojavljuje cijena. new balance that keeps D as constant as possible Bazen koristi faktore skaliranja da normalizira žetone na 18 decimalnih. Operacija Upscale prilagođava ravnoteže na unutrašnju preciznost i koristi zaokruživanje. Swap Types 
 
 
 EXACT_IN (GIVEN_IN): Fiksni iznos unosa, izračunajte izlaz. EXACT_OUT (GIVEN_OUT): Fiksni iznos izlaza, izračunajte unos. Vault and BatchSwapBalancer Vault manages all operations. BatchSwap combines multiple swaps in one transaction and uses "deferred settlement" like flashloans. BPTs act like normal tokens, bypassing min pool supply limit to drop liquidity very low. 1. iskoristiti analizu 1.1 Napadači 3. studenog 2025. godine, oko 7:40 UTC, određeni stabilni bazeni Balancer v2 bili su ciljani sofisticiranim napadom koji je rezultirao kumulativnim gubitkom od 120 miliona dolara preko Balancer-a i njegovih forkova. The attack leveraged several circumstances: 
 
 
 
 
 Većina ciljanih bazena bili su slučajevi ugovora ComposableStablePool. specijalni bazeni dizajnirani za imovinu koja se očekuje da će se dosljedno razmjenjivati na bliskoj paritetu ili na poznatom tečaju. Funkcionalnost batchSwap ugovora Balancer Vault omogućuje da se prijelazne zamjene dogode prije potrebe za rješavanjem izostalih delta. Napad je bio profitabilan u scenarijima niske likvidnosti. Napadač je morao pripremiti velike razmjene tako da bi bilance bazena mogle biti dovedene do niske likvidnosti jednog ili drugog tokena. Sve gore navedeno su samo neophodne, ali ne i zaključne okolnosti, a jedina neophodna okolnost da se to dogodi je korijen uzroka problema, zaokruživanje ponašanja u funkciji _upscale. Vektor napada prvi put je uveden 16. jula 2021. godine, kada je MetaStablePool prevazišao Funkcija na kompromisu 059284e. Ista promjena je kasnije primijenjena 1. septembra 2021. za linearne bazene na kompromisu 4e9e70a i 20. septembra 2021. na kompromisu f450760 za StablePhantomPool, kasnije preimenovan ComposableStablePool. _scalingFactors U opisu problema ispod, objašnjavamo zašto je uvođenje ovog preklapanja bilo u središtu napada. 1.2 Pitanje Funkcija batchSwap Vault ugovora je ulazna tačka za ovaj napad. Napadač je napravio poziv na njega, ciljajući instance ComposableStablePool. Relevantna logika u Vault ugovoru koja dovodi do interakcije ComposableStablePool je definirana ovim tokom: batchSwaps → interno poziva _swapWithPools → koji interno poziva bazen za svaku zamenu na _swapWithPool → _processGeneralPoolSwapRequest → na kraju poziva naSwap na ComposableStablePool. Nakon što je sletio u ComposableStablePool, izvršenje se nastavlja unutar kucka onSwap, gde se dešavaju dvije stvari: 
 
 
 The call to   function. _scalingFactors Prijenos na _swapGivenOut kako je definirano u zgornjem primjeru transakcije. Imajte na umu da je napadač možda odlučio da uzme _swapGivenIn uzorak, ali podaci u transakciji napada jasno pokazuju izbor. Pogledajmo ove dvije funkcije. ScalingFaktori 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;
}
 Ova funkcija radi dvije stvari: 
 
 
 Širi bilo koji iznos do fiksnog broja decimalnih kao što predlaže funkcija _getScalingFactor i ono što vraća. Ona faktore u token razmeni troškova tako što će ga pomnožiti faktorom skaliranja i podijeliti 1e18. Uspon 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);
}
 Ovo samo izvodi množenje iznosa njegovim faktorom skala, deljenjem 1e18 na kraju. Problem leži u dvjema činjenicama: 
 
 
 Ove funkcije uvek zaokružuju (mulDown) nezavisno od smjera zamene. Ako su iznosi redovi veličine manji od faktorskih, gubitak preciznosti postaje nezamisliv. U transakciji napadača, tipična vrijednost iznosa i faktor skala je: iznos: "17"skalaFactor: "1058132408689971699" Ako izračunamo Mi dobijemo , ali budući da Solidity truncates decimals, to postaje Kao rezultat toga, a U ovom funkcije . amount * scalingFactor / 1e18 17.98 17 0% net change _upscale Razmislite o količini (žetona sa 18 decimalnih). rezultat je Zastupnik A – koji ispravno odražava stopu. 17,000000000000000000 17.988250950000000000 5.8% increase Isto tako, za token sa (kao što većina stablecoins imaju), koristeći količinu  yields  , koji još uvijek odgovara otprilike istom . 6 decimals 17,000000 17.988250 5.8% positive change Truncation se maksimizira stvaranjem što je moguće veće, tako da proizvod gubi maksimalnu preciznost kada se deli sa 1e18. amount*scalingFactor mod 1e18 Na primer, u tabeli ispod, iznos = 17 i iznos = 50 oba proizvode apsolutni zaobljeni gubitak od oko 0,90. Međutim, pogreška kao postotak iznosa značajno se razlikuje, a postotak povećanja izgubljenog razlikuje se još više, jer je isti apsolutni gubitak mnogo veći u odnosu na 17 nego na 50. Primeri Primjeri greške zaokruživanja poda pri skalanju faktorom od 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 5,76 odsto 100 odsto 50 52 0.90 1.80 odsto 17 odsto ... → ... → ... → ... → ... → Naši Funkcija će kasnije koristiti ove zaokružene vrednosti za izračunavanje iznosa koji napadač duguje bazenu nakon zamjene. Ova vrijednost je veštački deflatirana, čineći zamjenu jeftinijom.  are complex, and they also justify why this can be achieved in pools where low liquidity states can be obtained at will. This is due to an invariant check that ensures convergence to some degree. In high liquidity situations, big shifts in the balances would have failed due to the same invariant protection. _swapGivenOut _swapGivenOut Konačno, s velikim brojem iteracija, delte nakon batchSwap-a su napunjene, kreditirajući napadaču većinu sredstava u bazenu. Osim toga, postoji relevantno opažanje koje treba učiniti o _upscale in-line dokstringovima: /* 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. */
 Prethodna verzija ovog komentara imala je dodatnu bilješku: /* …as the impact of this rounding is expected to be minimal (and there's no rounding error unless `_scalingFactor()` is overriden). */
 To je važno jer je Uvođenje na Kasnije je preimenovan u primjenjuje se tačno na Gornje je raspravljalo. StablePhantomPool September 20, 2021 ComposableStablePool _scalingFactor U ranijim verzijama , o funkcija računala samo za razlike u token decimalima. U novijoj implementaciji, međutim, uključuje i Označava temeljnu promenu. StablePool _scalingFactor exchange rate Kao što je navedeno u  function’s comments, the code evolved from using  (Naravno da je, • 2 Ova promena, iako funkcionalno neophodna, uvodi potencijal Uz njih, novi . _upscale unitary scaling factors 1e12 non-unitary exchange rates rounding errors attack vector Iako je omogućavanje greške zaokretanja bio korijen uzrok, iskorištavanje je zahtijevalo iskorištavanje dodatnih mehanika protokola i specifičnih koraka napada. Zahvaljujući tome, napadač je efikasno "posudio" BPT unutar serije da manipuliše bazenom bez potrebe da okonča transakciju koja drži BPT. BPT (Balancer Pool Token) je ERC-20 koji predstavlja proporcionalni udio Balancer bazena. U nekim bazenskim dizajnom, uključujući ciljane ComposableStablePools, BPT se takođe može pojaviti kao sredstvo bazena i biti trgovanje / zamjenjivo. Prva faza je gurnula salde tokena bazena (npr. WETH / osETH) na vrlo niske nivoe (približno 100k) ponavljanjem zamjene BPT za token1 i BPT za token2. Cilj je da se maksimizira odbačeni frakcijski deo u podnoj aritmetici, tj. da se maksimizira količina*scalingFactor mod 1e18 tako da proizvod gubi što više preciznosti kada je podijeljen sa 1e18. Eksploit se izvodi ponavljajući triplete razmjena: 
 
 
 
 Prime: premestite bazen u stanje u kojem će se trunciranje dogoditi na sledećoj operaciji. U screenshot-u ispod, zamena WETH na osETH Iskoristite: izvršite zamjenu koja ostvaruje gubitak zaokretanja. U screenshot-u, zamena od 17 WETH za osETH. Reset: vratite ravnoteže tako da se triplet može ponovo igrati. U screenshot-u je zamjena osETH na WETH. Kao što je prikazano u nastavku ispod, kritična zamjena često koristi iznos=17 u odnosu na saldo kutije od 18. Možete vidjeti ponovljenih 17 iznosa u drugoj zamjeni svakog tripleta. Napredovanje sigurnosnih najboljih praksi: lekcije za industriju This incident has sparked debate about the effectiveness of smart contract security audits, with some commentators questioning whether they provide value. While this sentiment may be understandable in the moment of frustration, it fails to acknowledge why security audits have become an industry best practice and the tremendous impact the security audit practice has had on mitigating risk and protecting users over the past decade. Sigurnosne tvrtke kolektivno sprečavaju stotine potencijalnih eksploatacija svake godine. Samo OpenZeppelin je identificirao više od 700 kritičnih i ranjivosti visoke ozbiljnosti prije nego što su dostigle proizvodnju kroz sve naše revizije. Te sprečene katastrofe ne čine naslovnice, ali predstavljaju milijarde u zaštićenoj vrijednosti i bezbrojne korisnike spasene od gubitaka. Visokokvalitetne sigurnosne revizije takođe pomažu timovima za razvoj da poboljšaju svoj sigurnosni stav tokom životnog ciklusa razvoja, što rezultira eksponencijalnim smanjenjem vjerojatnosti daljnjih grešaka koje se uvode u aplikacije blockchain. Prava lekcija nije u tome da su revizije neučinkovite – to je u tome što revizijske prakse u industriji još nisu shvatile koliko se brzo razvijaju složeni protokoli koji osiguravaju značajnu vrednost. Budući da su revizije često obuhvaćene izoliranim pregledima, a ne kontinuiranim angažmanima, kontekst se može izgubiti kako se kode razvijaju. 2.1 Utvrđivanje kontinuirane sigurnosti kao industrijskog standarda Od pionira u praksi pametnog ugovora revizije u 2016, vidjeli smo kako najuspešniji sigurnosni rezultati dolaze iz kontinuiranih sigurnosnih partnerstva koje pokrivaju čitave protokola kod baze i sve njihove promene tijekom vremena, a ne ad hoc kod revizije velikih nadogradnji, koje su često ograničene u opsegu samo na te promene. Kada sigurnosni istraživači kontinuirano rade s protokolima, razvijaju duboko poznavanje arhitekture protokola, inženjerskih procesa i zašto su donesene određene odluke o dizajnu. Although the Balancer v2 codebase was reviewed by four independent audit firms, each firm was engaged to focus on different scopes of the protocol. Engaging multiple auditors helps reduce the chance of missing vulnerabilities, but maintaining at least one long-term security partner provides a deeper, continuous understanding of how the codebase evolves and how new changes interact with existing logic. 2.2 Izgradnja boljih sigurnosnih okvira Kroz naše desetljeće iskustva, OpenZeppelin je dosljedno radio na uspostavljanju i podizanju sigurnosnih standarda širom industrije. OpenZeppelin ugovori postali su de facto standard za izgradnju sigurnih pametnih ugovora, koji trenutno pokreću više od 30 trilijuna dolara ukupne vrijednosti prenesene širom ekosustava. Pored dugoročnih odnosa sa našim klijentima, aktivno radimo na oblikovanju tih standarda na industrijskoj i regulatornoj razini. Na primjer, OpenZeppelin doprinosi tijelima za postavljanje industrijskih standarda, kao što su Odbor za sigurnosne standarde Blockchain, Enterprise Ethereum Alliance i Međunarodna organizacija za standarde (ISO), kako bi se osiguralo da su sigurnosne najbolje prakse koje su naš tim i zajednica pomogli pionirima dostupne čitavoj industriji. Takođe sarađujemo sa regulatornim tijelima i tvorcima politika širom svijeta kako bismo osigurali da se najbolje prakse u vezi sa bezbednošću blokčeina promovišu u relevantnim regulatornim režimima. Posebno, OpenZeppelin je sarađivao sa Ministarstvom finansija SAD-a, Komisijom za vrijednosne papire i berzu SAD-a, Uredom za financijsko ponašanje Ujedinjenog Kraljevstva i francuskim ACPR i AMF-om u vezi s prednostima redovnog provođenja sveobuhvatnih bezbednosnih revizija. Pored toga, istražili smo potencijal za stvaranje posvećene samoregulatorne organizacije slične revizorima u drugim područjima za koje smatramo da bi mogle pomoći formalizovati standarde i metodologije bezbednos 2.3 Jačanje ekosustava Blockchain sigurnosti zajedno Svaki sigurnosni incident pruža dragocene uvidove koji pokreću poboljšanja u našoj industriji. Eksploit Balancer v2 pojačava da, kako protokoli postaju vrijedniji i sofisticiraniji, postaje ključno da timovi protokola ulažu u kontinuiranu sigurnost, kao i da revidiraju tvrtke kako bi izgradili okvire koji ga podržavaju.

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

Ovaj audio je proizveden na originalnom jeziku priče!

Balancer V2 eksploatacija objašnjena: Unutar pametnog ugovora okrugla greška koja košta 120 miliona dolara

About Author

KOMENTARI

HANG TAGS

OVAJ ČLANAK JE PREDSTAVLJEN U

Related Stories

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps