Curve Finance: Exploit statt Hack
Curve Finance hat kürzlich eine nahezu tödliche Erfahrung gemacht (und deren Ausbreitung verhindert), die wie ein verschwommener Rückspiegelblick in Web3 erscheinen mag, aber tatsächlich etwas ist, das in der Branche immer wieder vorkommt. Es ist nicht das erste Mal, dass ein dezentrales Finanzprotokoll – oder eine dezentrale App im Allgemeinen – von einem Angriff betroffen ist, der in seinem eigenen Code vollkommen legal ist. Darüber hinaus hätte die Krise verhindert werden können, wenn ein On-Chain-Risikomanagement bestanden hätte. All dies weist auf ein größeres Problem in Web3 hin: das Problem der begrenzten Ausdrucksfähigkeit und Ressourcen, die in deren Entwicklungsumgebungen existieren und wie sich das insgesamt auf die Sicherheit auswirkt.
Hack oder Exploit?
Als der Angreifer von Curve Finance in der Lage war, 61,7 Millionen US-Dollar an Vermögenswerten aus den Smart Contracts von Curve Finance abzurufen, bezeichneten viele Medien und Kommentatoren das Ereignis als „Hack“. Aber das hier war kein Hack – es war ein Exploit. Der Unterschied hier ist entscheidend.
In diesem Zusammenhang hätte ein Hack stattgefunden, wenn der Angreifer irgendwie eine vorhandene Sicherheitsmaßnahme umgangen oder gebrochen hätte. Aber der Angriff auf Curve war ein Exploit. Es ist nichts Ungewöhnliches passiert, was die Vyper-Codebasis des Protokolls erlaubt hat. Der Plünderer hat einfach die Funktionsweise des Protokolls ausgenutzt.
Wer trägt die Schuld dafür? Niemand. Der Vyper-Code von Curve, wie auch der Großteil des (Solidity)-Codes, der in Web3-Anwendungen verwendet wird, ist stark eingeschränkt in seiner Fähigkeit, Komplexität jenseits relativ einfacher Transaktionslogik auszudrücken.
Das erschwert es jedem, Sicherheitsmaßnahmen zu entwerfen, die solche oder andere Angriffe verhindern würden. Besorgniserregender ist jedoch, dass es auch schwer für jemanden ist, Tools ordnungsgemäß zu entwerfen, um deren Ausbreitung in der weitläufigen und miteinander verbundenen Liquiditätslandschaft von DeFi zu verhindern.
Risikoanalyse On-Chain
Es bedeutet jedoch nicht, dass Curve nichts tun konnte, um diesen Angriff und seine Ausbreitung in DeFi zu verhindern. Ein einfaches Beispiel für eine Lösung wäre eine On-Chain-Risikoanalyse.
Die verallgemeinerte Version eines problematischen Musters, das gelöst werden könnte, kann in einer hypothetischen Situation wie dieser zusammengefasst werden:
Schurke Bob kauft via Flashloan $5 Millionen der hochvolatilen und risikoreichen Token $RISKY.
Der Wert des $RISKY-Token wird nach dem Kauf von Bob stark erhöht.
Bob nimmt bei Naive Finance einen Kredit in Höhe von $100 Millionen auf, gegen den $RISKY als Sicherheit hinterlegt wird.
Naive Finance überprüft den Preis von $RISKY und bestätigt, dass Bob genug Geld hat.
Bob verschwindet.
Als Naive Finance $RISKY liquidiert, ist es nur noch $5 Millionen wert.
(Ein weiteres Beispiel für dieses allgemeine Muster ist der Euler-Hack vom März.)
Traditionell wird dieses Problem durch Risikoanalyselösungen gelöst, die bestimmen, wie sicher eine Sicherheit sein kann. Wenn diese On-Chain vorhanden wären, könnte Naive Finance statistische Schätzungen auf der Grundlage des historischen Preises des Tokens überprüfen, bevor der Kredit genehmigt wird. Das Protokoll hätte den Kursanstieg erkannt und Bob die $100 Millionen verweigert.
DeFi fehlt eine solche On-Chain-Risikoanalyse und -verwaltung.
Bei Curve Finance hätte eine Ausbreitung verhindert werden können, wenn Aave und Frax eine automatisierte On-Chain-Grenze für Kreditgenehmigungen hatten, wenn diese einen Prozentsatz des umlaufenden Angebots des Sicherheitstokens überschritten. Dies wäre eine sicherere und weniger stressige Situation für alle Beteiligten gewesen.
Begrenzte Ausdrucksfähigkeit und Ressourcen
Das eigentliche Problem hier ist, dass die aktuellen Web3-Ökosysteme eine solche On-Chain-Risikoanalyselösung nicht unterstützen können. Sie sind begrenzt durch die Art der Bibliotheken und Frameworks, die in virtuellen Maschinen wie der Ethereum Virtual Machine verfügbar sind. Sie sind auch begrenzt hinsichtlich der verfügbaren Ressourcen.
Um eine Risikoanalyse- und -managementlösung wie diese zu entwickeln, müsste eine dezentrale App auf Codierungs-Bibliotheken zurückgreifen können, die Funktionen für zumindest grundlegende mathematische Konzepte wie Logarithmen und andere enthält.
Das ist jedoch in Web3 nicht der Fall, da dApps keinen Zugriff auf NumPy oder das math-Modul in Python haben, um nur ein Beispiel zu nennen. Das typische Werkzeugsortiment ist nicht vorhanden und Entwickler müssten das Rad neu erfinden.
Ein weiteres Problem besteht darin, dass selbst wenn solche Bibliotheken vorhanden wären, sie zu teuer in der Codierung wären. Wörtlich teuer. Die Ethereum Virtual Machine ist so konzipiert, dass jede Berechnung geld kostet.
Obwohl es gute Gründe dafür gibt, wie das Verhindern von Endlosschleifen usw., schafft es auch eine Ressourcenbegrenzung für dApps, die ohne übermäßige Kosten skalieren müssen. Es ist leicht vorstellbar, dass eine Risikomanagementlösung mehr kostet, als sie an Geldern einsparen kann.
Fokussierung auf die richtigen Probleme
Auf lokaler Ebene hätte die Ausbreitung des Curve Finance Vorfalls mit On-Chain-Risikomanagement verhindert werden können. Auf allgemeiner Ebene könnten diese Angriffe insgesamt mit mehr Ausdrucksfähigkeit und Ressourcen in Web3 verhindert werden.
Das sind zwei Aspekte der Blockchain-Skalierbarkeit, die lange Zeit übersehen wurden, weil sie über das Bereitstellen von mehr gemeinsam genutztem Blockplatz für dApps hinausgehen. Es geht tatsächlich um die Schaffung von Entwicklungsumgebungen in Web3, die jenen von Web2 ähneln. Es geht um rechnerische Skalierbarkeit und Programmierbarkeit, nicht nur um die Skalierung der verfügbaren Daten On-Chain.
Vielleicht hätten die Protokollentwickler bei Curve, Aave oder Frax die Möglichkeit gehabt, auf ein besseres Werkzeugset und mehr Ressourcen zurückgreifen zu können, um solche und zukünftige Exploits gänzlich zu vermeiden. Vielleicht könnten wir mit On-Chain-Risikomanagement beginnen.
