Technical Background of Balancer V2 Composable Stable Pools Podstawy techniczne Balancer V2 Composable Stable Pools • : Pool Structure and How It Works Kompozytowe stałe baseny są zbudowane na matematyce inspirowanej modelem StableSwap firmy Curve. What is a Composable Stable Pool? Te puli są zaprojektowane, aby umożliwić aktywom o prawie identycznych wartościach, takich jak USDC i DAI, lub stETH i ETH, handel z minimalnym ślizgiem. **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: W równowadze Pools (inspirowane przez Curve), swapy są obliczane przez zachowanie (D) tak stała, jak to możliwe.Kiedy następuje wymiana, saldo tokenów przenosi się do nowego stanu, który zachowuje tę zmienną. Ty decydujesz się na uzyskanie z tokenem, który rozliczasz, biorąc pod uwagę, że (D) pozostaje stały. stable invariant quadratic new balance (x) terminów 
 
 
 
 
 
 
 (x): nowy (post-swap) saldo tokena, który rozliczasz. (S): suma sald pozostałych tokenów (z wyłączeniem (x) ) (P): produkt pozostałych sald tokenów (z wyłączeniem (x) ) (D): niezmienny basen (celem jest utrzymanie stałej stawki w swapie). (A): parametr amplifikacji (wypłaca krzywiznę → niższy ślizg dla aktywów o tej samej wartości). (n): liczba tokenów w puli. Intuicja: kompresujemy „wszystkie inne tokeny” na dwa agregaty, (S) i (P). . quadratic in (x) Dlaczego kwadratowy? Po odizolowaniu nowej równowagi nieznanego tokena i złożeniu reszty na (S) i (P), warunek niezmienny zmniejsza się do polinomu drugiego stopnia w (x). Rozwiązywanie go Wybierz korzeń, który jest i (w ramach możliwych zakresów równowagi) Drugi korzeń jest zazwyczaj negatywny lub bezsensowny. Which root? positive economically valid prosty przykład Setup (2 tokens, large A → very low slippage) 
 
 
 
 
 Wewnętrzne (rozszerzone) salda początkowe: token0 = 1,000,000; token1 = 1,000,000 Liczba tokenów: n = 2 Amplifikacja: A = 1000 Z dużym A, D ≈ 2 000 000 Action 
 
 Dodaj 10 000 jednostek token0 (EXACT_IN). Quadratic to solve x^2 + (S - D/(A*n^n) - D)*x - D^(n+1)/(A*n^(2n)*P) = 0 gdzie : , , oraz Jest to bilans token1 po swapie. 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 
 
 
 Wkładasz 10 000 token0 i otrzymujesz ~9,000.45 token1 → niski spadek z dużym A. Cała matematyka wykorzystuje 18-dziesiętne jednostki wewnętrzne; implementacje zaokrąglone w celu zapewnienia bezpieczeństwa. Gdzie jest używany (wysoki poziom) 
 
 
 EXACT_IN: zwiększysz token wejściowy; rozwiąż nowy saldo (x); różnica od jego starego salda jest kwotą. EXACT_OUT: kierujesz się do określonej otrzymanej kwoty; rozwiązujesz dla potrzebnej (x) (a zatem wymaganej wartości wejścia). Practical notes 
 
 
 Wszystkie bilansy są obsługiwane wewnętrznie w 18 dziesiętnych (w skali); obliczenia są zazwyczaj zaokrąglone w dół, aby być bezpieczne. Większy (A) sprawia, że krzywa jest bardziej podobna do sumy stałej (mały ślizg dla stabilnych par); mniejszy (A) jest bliższy zachowaniu produktu stałego. 
 
 TL;DR: To równanie jest kwadratowym workhorse, który pod stałą zmienną (D) daje nową równowagę tokenową (x) po wymianie. TL;DR: To równanie jest kwadratowym workhorse, który pod stałą zmienną (D) daje nową równowagę tokenową (x) po wymianie. Półka narzuca a Wśród tych, którzy zostali złapani przez . balance relationship invariant D Kiedy wymieniasz, jeden saldo idzie w górę, drugi idzie w dół, a basen znajduje Tak powstaje cena. new balance that keeps D as constant as possible Basen wykorzystuje współczynniki skalowania, aby znormalizować tokeny do 18 decimalów. Operacja Upscale dostosowuje bilansy do wewnętrznej precyzji i wykorzystuje zaokrąglanie w dół. Swap Types 
 
 
 EXACT_IN (GIVEN_IN): Stała kwota wejścia, oblicz wyjście. EXACT_OUT (GIVEN_OUT): Stała kwota wyjścia, oblicz wejście. Vault i BatchSwapBalancer Vault zarządza wszystkimi operacjami. BatchSwap łączy wiele swapów w jednej transakcji i wykorzystuje "rozliczenia opóźnione" jak flashloans.BPT działają jak normalne tokeny, omijając limit podaży min pool, aby spuścić płynność bardzo nisko. 1) Analiza eksploatacji 1.1 Atak 3 listopada 2025 roku, około 7:40 UTC, określone stabilne puli Balancer v2 zostały ukierunkowane za pomocą zaawansowanego ataku, który spowodował łączną stratę ponad 120 milionów dolarów w Balancer i jego forkach. The attack leveraged several circumstances: 
 
 
 
 
 Większość docelowych puli była instancjami umowy ComposableStablePool. Specjalny puli zaprojektowany dla aktywów, które są albo oczekiwane, aby konsekwentnie wymieniać w pobliżu parytetu lub w znanym kursie walutowym. Funkcja batchSwap umowy Balancer Vault pozwala na przejściowe swapy przed koniecznością rozliczenia pozostałych delt. Atak był opłacalny w scenariuszach niskiej płynności. Napastnik musiał przygotować duże swapy, aby saldo poolów mogło zostać przyniesione do niskiej płynności jednego lub drugiego tokena. Najczęściej stosowanym sposobem osiągnięcia tego było wymiana tokenów LP na tokeny poolowe, pozostawiając pool w stanie niskiej płynności. Wszystkie powyższe są tylko koniecznymi, ale nie końcowymi okolicznościami, przy czym jedyną konieczną okolicznością, aby tak się stało, jest przyczyna problemu, zaokrąglone zachowanie w funkcji _upscale. Wektor ataku został wprowadzony po raz pierwszy 16 lipca 2021 roku, kiedy MetaStablePool przekroczył Ta sama zmiana została później zastosowana w dniu 1 września 2021 r. w przypadku puli liniowych w puli 4e9e70a i w dniu 20 września 2021 r. w puli f450760 w przypadku StablePhantomPool, później zmienionej na ComposableStablePool. _scalingFactors W poniższym opisu problemu wyjaśnimy, dlaczego wprowadzenie tego przełożenia było w centrum ataku. 1.2 Pytanie Funkcja batchSwap kontraktu Vault jest punktem wejścia do tego ataku. Atakujący wykonał do niego wezwanie, kierując się do instancji ComposableStablePool. Odpowiednia logika w kontrakcie Vault, która prowadzi do interakcji ComposableStablePool, jest zdefiniowana przez ten przepływ: batchSwaps → wewnętrznie nazywa _swapWithPools → co wewnętrznie nazywa pool dla każdego swapu w _swapWithPool → _processGeneralPoolSwapRequest → ostatecznie nazywa onSwap na ComposableStablePool. Po wylądowaniu w ComposableStablePool, wykonanie kontynuuje się w rowku onSwap, gdzie dzieją się dwie rzeczy: 
 
 
 Wywołanie funkcji _scalingFactors. Przekazanie do _swapGivenOut zgodnie z definicją w przykładowej transakcji podanej powyżej. Należy pamiętać, że atakujący może zdecydować się na pobranie wzorca _swapGivenIn, ale podane wejścia w transakcji ataku wyraźnie pokazują wybór. Przyjrzyjmy się tym dwóm funkcjom. Skala czynników 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;
}
 Ta funkcja wykonuje dwie rzeczy: 
 
 
 Skala dowolnej kwoty do stałej liczby dziesiętnych, jak sugeruje funkcja _getScalingFactor i co zwraca. Czynniki w kursie wymiany tokenów poprzez pomnożenie go przez współczynnik skalowania i dzielenie przez 1e18. - podniesienie 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);
}
 To po prostu wykonuje mnożenie kwoty przez jej współczynnik skalowania, dzieląc przez 1e18 na końcu. Problem polega na dwóch faktach: 
 
 
 Funkcje te są zawsze zaokrąglone w dół (mulDown) niezależnie od kierunku swapu. Jeśli kwoty są kolejnościami o wielkości mniejszej niż te skalująceFaktory, utrata dokładności staje się nieistotna. W transakcji atakującego typową wartością kwoty i współczynnika skalowania jest: kwota: "17" skalowanieFaktor: "1058132408689971699" Jeśli obliczymy A my otrzymujemy , ale ponieważ Solidity truncates dziesiętnych, to staje się W rezultacie do W tym i funkcji. amount * scalingFactor / 1e18 17.98 17 0% net change _upscale Zastanów się nad ilością (taki, który ma osiemdziesiąt osiemdziesiąt dziesięciokątnych znaków). Przedstawiając a - który prawidłowo odzwierciedla stawkę. 17,000000000000000000 17.988250950000000000 5.8% increase Podobnie, w odniesieniu do jednego z (jak większość stablecoins mają), używając ilości Daje , który wciąż odpowiada mniej więcej tym samym . 6 decimals 17,000000 17.988250 5.8% positive change Trunkowanie jest maksymalizowane poprzez tworzenie jest tak duży, jak to możliwe, więc produkt traci maksymalną precyzję, gdy dzieli się przez 1e18. amount*scalingFactor mod 1e18 Na przykład w poniższej tabeli, kwota = 17 i kwota = 50 obie wywołują absolutną stratę zaokrąglania wynoszącą około 0,90. Przykłady Przykłady błędów zaokrąglania podłogi przy skalowaniu przez współczynnik 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 proc. 100 % 50 52 0.90 1,80 proc. 17 proc. ... ... ... ... ... o Funkcja będzie później używać tych zaokrąglonych wartości do obliczenia kwoty należnej przez atakującego do puli po swap. Ta wartość jest sztucznie deflatowana, co czyni swap tańszym. są złożone, a także uzasadniają, dlaczego można to osiągnąć w puli, w której można uzyskać niskie stany płynności na życzenie. Jest to spowodowane kontrolą niezmienną, która zapewnia konwergencję w pewnym stopniu. _swapGivenOut _swapGivenOut Ostatecznie, przy dużej liczbie iteracji, delty po batchSwap są napełnione, przypisując atakującemu większość funduszy w basenie. Dodatkowo istnieje odpowiednia obserwacja dotycząca _upscale in-line docstrings: /* 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. */
 Wcześniejsza wersja tego komentarza miała dodatkową notatkę: /* …as the impact of this rounding is expected to be minimal (and there's no rounding error unless `_scalingFactor()` is overriden). */
 Jest to ważne, ponieważ Wprowadzono na Później zmieniono nazwę na Wdrażamy dokładnie te Wyżej omówione wyżej. StablePhantomPool September 20, 2021 ComposableStablePool _scalingFactor W poprzednich wersjach , o Funkcja ta uwzględniała tylko różnice w wartościach dziesiętnych tokenów. W nowszej implementacji jednak zawiera również Oznacza to zasadniczą zmianę. StablePool _scalingFactor exchange rate Jak zauważono w komentarze funkcji, kod ewoluował z używania (w tym np. a) do Ta zmiana, choć funkcjonalnie konieczna, wprowadza potencjał Wraz z nimi, nowy . _upscale unitary scaling factors 1e12 non-unitary exchange rates rounding errors attack vector Podczas gdy umożliwienie błędu zaokrąglania było przyczyną, wykorzystanie go wymagało wykorzystania dodatkowej mechaniki protokołu i konkretnych kroków ataku. Balancer’s batchSwap pozwala na przejściowe bilansy wewnętrzne, które są rozliczane tylko na końcu partii.Dzięki temu atakujący skutecznie „pożyczył” BPT w ramach partii, aby manipulować basenem bez konieczności zakończenia transakcji prowadzącej BPT. BPT (Balancer Pool Token) to ERC-20, który reprezentuje proporcjonalny udział w poolie Balancer.W niektórych projektach poolowych, w tym ukierunkowanych ComposableStablePools, BPT może również pojawić się jako aktyw poolowy i być handlowy/zmienny. Pierwsza faza skłoniła saldo tokenów poolowych (np. WETH / osETH) do bardzo niskich poziomów (prawdopodobnie 100k) poprzez wielokrotną wymianę BPT na token1 i BPT na token2. Celem jest zmaksymalizowanie odrzuconej części frakcyjnej w arytmetyce podłogowej, tj. zmaksymalizowanie kwoty*scalingFactor mod 1e18 tak, aby produkt stracił jak najwięcej precyzji, gdy dzieli się przez 1e18. Eksploit polega na powtarzaniu trzech swapów: 
 
 
 
 Prime: przenieś basen do stanu, w którym nastąpi trunkowanie w następnej operacji.W zrzucie ekranu poniżej, wymiana WETH na osETH Wykorzystaj: wykonaj swap, który realizuje stratę zaokrąglania. Na zrzucie ekranu, swap 17 WETH dla osETH. Reset: przywróć równowagę, aby można było odtworzyć trójkąt. Na zrzucie ekranu znajduje się wymiana osETH na WETH. Jak pokazano w poniższym śladzie, krytyczna wymiana często używa kwoty = 17 w porównaniu do salda skrzynki 18 można zobaczyć powtarzające się 17 kwoty w drugiej wymianie każdego trójkąta. Rozwój najlepszych praktyk w zakresie bezpieczeństwa: lekcje dla przemysłu Ten incydent wywołał debatę na temat skuteczności audytów bezpieczeństwa inteligentnych kontraktów, a niektórzy komentatorzy kwestionują, czy zapewniają one wartość.Mimo że ten sentiment może być zrozumiały w momencie frustracji, nie rozpoznaje się, dlaczego audyty bezpieczeństwa stały się najlepszą praktyką w branży i ogromny wpływ praktyki audytu bezpieczeństwa miał na łagodzenie ryzyka i ochronę użytkowników w ciągu ostatniej dekady. Firmy zabezpieczeń zbiorowo zapobiegają setkom potencjalnych exploitów każdego roku. Sam OpenZeppelin zidentyfikował ponad 700 krytycznych i wysoce poważnych luk przed dotarciem do produkcji we wszystkich naszych audytach. Te zapobiegające katastrofom nie tworzą nagłówków, ale stanowią miliardy wartości chronionej i niezliczone użytkownicy uratowani od strat. Wysokiej jakości audyty bezpieczeństwa pomagają również zespołom rozwojowym poprawić postawę bezpieczeństwa w całym cyklu życia rozwoju, co prowadzi do eksponencyjnego zmniejszenia prawdopodobieństwa wprowadzenia dalszych błędów do aplikacji blockchain. Prawdziwą lekcją nie jest to, że audyty są nieskuteczne – jest to fakt, że praktyki audytu w branży nie są jeszcze w stanie zrozumieć, jak szybko zmieniają się złożone protokoły, które zapewniają znaczącą wartość. Ponieważ audyty są często rozmieszczane jako odosobnione przeglądy, a nie ciągłe zaangażowania, kontekst może zostać utracony w miarę ewolucji baz kodów. 2.1 Ustanowienie ciągłego bezpieczeństwa jako standardu branżowego Odkąd wprowadziliśmy praktykę audytu inteligentnych kontraktów w 2016 roku, widzieliśmy, jak najbardziej udane wyniki bezpieczeństwa pochodzą z ciągłych partnerstw bezpieczeństwa, które obejmują całe bazy kodów protokołów i wszystkie ich zmiany w czasie, a nie ad hoc przeglądy kodów dużych uaktualnień, które często są ograniczone w zakresie tylko do tych zmian. Podczas ciągłej pracy z protokołami naukowcy zajmujący się bezpieczeństwem rozwijają głęboką znajomość architektury protokołu, procesów inżynierskich i tego, dlaczego podjęto konkretne decyzje projektowe. Chociaż bazę kodową Balancer v2 przeglądano przez cztery niezależne firmy audytorskie, każda firma zaangażowała się w skupienie się na różnych obszarach protokołu.Udział wielu audytorów pomaga zmniejszyć prawdopodobieństwo braku luk w zabezpieczeniach, ale utrzymanie co najmniej jednego długoterminowego partnera bezpieczeństwa zapewnia głębsze, ciągłe zrozumienie tego, jak ewoluuje baza kodowa i jak nowe zmiany wchodzą w interakcję z istniejącą logiką. 2.2 Budowanie lepszych ram bezpieczeństwa Dzięki dziesięcioletniemu doświadczeniu, OpenZeppelin konsekwentnie pracował nad ustaleniem i podniesieniem standardów bezpieczeństwa w całej branży.Umowa OpenZeppelin stała się de facto standardem budowy bezpiecznych inteligentnych kontraktów, obecnie zasilając ponad 30 bilionów dolarów całkowitej wartości przeniesionej w całym ekosystemie. Oprócz długoterminowych relacji z naszymi klientami, aktywnie pracujemy nad kształtowaniem tych standardów zarówno na poziomie branżowym, jak i regulacyjnym. Na przykład, OpenZeppelin przyczynia się do ustalania standardów branżowych, takich jak Rada Bezpieczeństwa Blockchain, Enterprise Ethereum Alliance i Międzynarodowa Organizacja Normalizacyjna (ISO), aby upewnić się, że najlepsze praktyki bezpieczeństwa, które nasz zespół i społeczność pomogły pionierowi, są dostępne dla całej branży. W szczególności OpenZeppelin współpracował z Departamentem Skarbu Stanów Zjednoczonych, Komisją Papierów Wartościowych i Giełd Stanów Zjednoczonych, UK Financial Conduct Authority oraz francuskim ACPR i AMF w odniesieniu do korzyści płynących z regularnego przeprowadzania kompleksowych audytów bezpieczeństwa. Ponadto zbadaliśmy potencjał tworzenia dedykowanej samoregulacyjnej organizacji podobnej do audytorów w innych dziedzinach, które, jak uważamy, mogą pomóc w sformalizowaniu standardów i metodologii audytu bezpieczeństwa dla technologii blockchain, określić wymagania jakościowe i etyczne dla audytorów oraz zarządzać akredytacją w celu certyfikacji wykwalifikowanych audytorów, co mogłoby poprawić wyniki bezpieczeństwa i zwiększyć zaufanie Wspólne wzmocnienie ekosystemu bezpieczeństwa Blockchain Eksploit Balancer v2 wzmacnia fakt, że w miarę jak protokoły stają się bardziej cenne i wyrafinowane, dla zespołów protokołów staje się kluczowe inwestowanie w bieżące zabezpieczenia, a także audyt firm w celu budowania ram, które je wspierają.

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

Ten dźwięk jest produkowany w oryginalnym języku historii!

Eksploatacja Balancer V2 wyjaśniona: wewnątrz błędu okrążenia inteligentnej umowy, który kosztował 120 milionów dolarów

About Author

UWAGI

ZAWIEŚĆ TAGI

ARTYKUŁ TEN ZOSTAŁ PREZENTOWANY W

Related Stories

Google's Gemini AI: A Thought Experiment in Deception

From Desk to HackerNoon: Your Ultimate Guide on How to Publish a Story

The Blockchain Social Experiment: Enforced Logic

Verified Writers

Google's Gemini AI: A Thought Experiment in Deception

From Desk to HackerNoon: Your Ultimate Guide on How to Publish a Story

The Blockchain Social Experiment: Enforced Logic

Verified Writers

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps