[Englischer Long-Post] Detaillierte Analyse des Balancer V2 Angriffs: Schwachstellenmechanismus, Angriffsschritte und Lehren

Chainfeeds Zusammenfassung:

Die Angreifer haben die Parameter, einschließlich der Anzahl der Iterationen und des Eingabebetrags, absichtlich so eingestellt, dass der Effekt des Präzisionsverlusts maximiert wird.

Quellenangabe:

Autor des Artikels:

BlockSec

Meinung:

BlockSec: Am 3. November 2025 wurden der Composable Stable Pool von Balancer V2 sowie mehrere darauf basierende Projekte auf verschiedenen Chains Opfer eines koordinierten Cross-Chain-Angriffs, der zu einem Gesamtschaden von über 125 Millionen US-Dollar führte. BlockSec gab umgehend eine Warnung heraus und veröffentlichte anschließend eine erste Analyse. Es handelte sich um einen hochkomplexen Angriff. Unsere Untersuchungen zeigen, dass die eigentliche Ursache im Präzisionsverlust bei der Invariant-Berechnung lag. Durch diesen Präzisionsverlust wurde eine Preismanipulation ausgelöst, die den Preis des BPT (Balancer Pool Token) beeinflusste. Die Angreifer nutzten eine einzelne batchSwap-Operation, um von bestimmten Stable Pools zu profitieren. Betroffen war die Komponente Composable Stable Pool von Balancer V2. Solche Pools sind speziell für Vermögenswerte konzipiert, die einen Wechselkurs nahe 1:1 beibehalten sollen, und ermöglichen große Transaktionen mit minimalem Slippage, wodurch die Kapitaleffizienz gleichartiger oder korrelierter Vermögenswerte erheblich gesteigert wird. Jeder Pool hat seinen eigenen BPT, dessen Preis näherungsweise wie folgt ausgedrückt werden kann: BPT-Preis = D / totalSupply, wobei D das Invariant in der Stable-Mathematik ist und den virtuellen Gesamtwert des Pools darstellt. Aus der Formel geht hervor, dass, wenn D mathematisch verringert wird (selbst wenn keine echten Mittel verloren gehen), der BPT-Preis niedriger erscheint. Balancer V2 bietet die Funktion batchSwap (), die Multi-Hop-Swaps im Vault ermöglicht. Im SwapRequest gibt es zwei Modi: GIVEN_IN und GIVEN_OUT. Im GIVEN_OUT-Modus gibt der Aufrufer den gewünschten Auszahlungsbetrag an, und der Pool berechnet den erforderlichen Eingabebetrag. Im Stable Pool muss bei der Berechnung des erforderlichen Eingabebetrags amountIn eine Polynomgleichung gemäß der Invariant-Formel gelöst werden; diese Berechnungen werden einheitlich mit Upscaling und Downscaling durchgeführt. Theoretisch sind dies entgegengesetzte Operationen, aber in der Praxis gibt es unterschiedliche Rundungsrichtungen: Upscaling verwendet nur Abrunden (mulDown), während Downscaling sowohl Auf- als auch Abrunden (divUp / divDown) zulässt. Genau diese Inkonsistenz eröffnete eine Angriffsfläche. Die Ursache der Schwachstelle liegt darin, dass in BaseGeneralPool._swapGivenOut () beim Upscaling von swapRequest.amount abgerundet wird. Der abgerundete Wert wird als amountOut für die Eingabe von _onSwapGivenOut () verwendet, was dazu führt, dass der letztlich berechnete amountIn geringer ist als tatsächlich erforderlich, und damit gegen das Prinzip verstößt, dass Rundungen immer zugunsten des Protokolls erfolgen sollten. Bei Pools wie (wstETH / rETH / cbETH) kann der Angreifer mit weniger Input-Assets mehr von einer anderen Asset erhalten, das Invariant D verringern und so den BPT-Preis drücken. Die Angreifer führten einen zweistufigen Angriff durch. In der ersten Phase wurde die Kernlogik des Angriffs in einer einzigen Transaktion ausgeführt, jedoch ohne sofortigen Profit; in der zweiten Phase wurde der Gewinn dann durch eine separate Transaktion abgezogen. Die erste Phase unterteilte sich in Parameterberechnung und batch swap. Am Beispiel der Angriffstransaktion auf der Arbitrum-Chain (TX: 0x7da32e…55773) beschaffte sich der Angreifer zunächst die Pool-Parameter, darunter scaling factors, A (Amplifikationskoeffizient), BPT-Wechselkurs, swap fee usw., berechnete dann trickAmt und simulierte den Angriff über einen Hilfsvertrag. Der Angreifer kombinierte Offline-Berechnungen mit On-Chain-Simulationen, um die Parameter für den nächsten Swap präzise abzustimmen, einschließlich der Anzahl der Iterationen und der jeweiligen Input-/Output-Werte. In jeder Iteration wurden drei Swap-Schritte ausgeführt: Im ersten Schritt wurde die Ziel-Token-Menge auf trickAmt + 1 erhöht; im zweiten Schritt wurde weiter das Ziel-Token geswappt, wodurch das Abrunden von _upscale () ausgelöst wurde; im dritten Schritt wurde ein umgekehrter Swap durchgeführt, wobei der Poolbestand nach dem Entfernen der beiden höchsten Dezimalstellen abgerundet und dann zurückgetauscht wurde, z. B. 324.816 → 320.000. In einigen Fällen schlug die Lösung der StableSwap-Mathematik mit der Newton–Raphson-Methode fehl, woraufhin der Angreifer zwei Fallbacks vorbereitet hatte, bei denen mit 9/10 des Ursprungswerts erneut versucht wurde. Nach dem Angriff konnte Balancer aufgrund bestimmter Mechanismen nicht pausiert werden, was die Auswirkungen des Angriffs verstärkte. In der Folge kam es zu Nachahmungs- und Copycat-Angriffen auf mehreren Chains, der Gesamtschaden überstieg 125 Millionen US-Dollar. Dieses Ereignis offenbarte vier zentrale Schwächen dezentraler Protokolle: inkonsistente Rundungsmechanismen, sich ständig weiterentwickelnde Angriffsmethoden, fehlende Pausierbarkeit zur Schadensbegrenzung und mangelndes Echtzeit-Monitoring von Initialisierungs- und Betriebszuständen. Upscaling erlaubt nur Abrunden, während Downscaling beides zulässt; diese Asymmetrie kann bei extremen Parametern zu ausnutzbaren Präzisionsverlusten führen. Die Rundungsrichtung, die eigentlich immer zugunsten des Protokolls sein sollte, schadete in diesem Fall den Interessen des Protokolls. Die Angreifer nutzten eine zweistufige Methode: In der ersten Phase wurde der Angriff ausgeführt, ohne dass ein Gewinn verbucht wurde, in der zweiten Phase erfolgte dann die Auszahlung, um On-Chain-Überwachungsmodelle zu umgehen. Jeder Schritt des Angriffs kombinierte Off-Chain- und On-Chain-Simulationen, und der Hilfsvertrag verwendete sogar die StableMath-Implementierung von Balancer, wobei selbst die Fehlermeldungen identisch waren. Nach dem Angriff folgten weitere Chains, und viele Fork-Projekte waren ebenfalls betroffen, was zeigt, dass die Schwachstelle sich über das gesamte Ökosystem ausbreiten kann, solange Stable-Mathematik und Rundungslogik identisch sind. Das Ereignis zeigt, dass DeFi-Protokolle präzisere mathematische Berechnungen, strengere Rundungsüberprüfungen und Mechanismen zur Simulation verdächtiger Pfade sowie die Fähigkeit zur Notfall-Pausierung in Ausnahmesituationen benötigen. [Originaltext auf Englisch]