DeFi- und Protokollanalyse: Liquidität, MEV und wirtschaftliche Angriffe

Gewinne:

• Fähigkeit, DeFi-Bausteine wie AMM, Liquiditätspool, Oracle und Flash Loan zu verstehen und künstliche Intelligenz bei der Erklärung von Mechanismen und der Szenarioerstellung zu nutzen
• In der Lage sein zu unterscheiden, dass es sich bei den meisten DeFi-Risiken um Schwachstellen in der Wirtschafts-/Geschäftslogik und nicht um Codefehler handelt und dass künstliche Intelligenz bei der ursprünglichen wirtschaftlichen Schwachstelle schwach ist
• In der Lage sein zu verstehen, dass wirtschaftliche Sicherheit durch Simulation und nicht durch Denken bewiesen wird und dass die Orakelsucht der fragilste Punkt ist.

DeFi (Decentralized Finance) ist die wertvollste und am häufigsten angegriffene Domäne von Web3. Börsen, Kreditprotokolle, Liquiditätspools – alle laufen als Code und bewegen Millionen von Dollar in einer feindseligen Umgebung. In dieser Einheit verwenden wir KI als Protokollanalyseassistenten; Wir werden lernen, Liquidität, Preisgestaltung, MEV und wirtschaftliche Angriffe zu verstehen und zu verstehen, wo KI in diesem Kontextbereich hilfreich und ungeeignet ist.

Grundbausteine von DeFi

• AMM (Automated Market Maker): Ein Börsenmechanismus, der Preise anhand einer Formel (z. B. x·y=k) festlegt, anstatt Käufer und Verkäufer zusammenzubringen.
• Liquiditätspool: Ein gemeinsamer Fonds, in den Benutzer Token einzahlen und der Handel stattfindet.
• Kreditprotokoll: Kreditaufnahme gegen Sicherheiten; Die Liquidation erfolgt, wenn der Wert der Sicherheit sinkt.
• Oracle: Die Datenquelle, die den Preis der Außenwelt in das Protokoll einbringt – die kritischste und fragilste Abhängigkeit von DeFi.
• Flash-Kredit: Ein Kredit, der ohne Sicherheit in einer einzigen Transaktion aufgenommen und in derselben Transaktion zurückgegeben wird; Es hat sowohl legitime Verwendungszwecke als auch ein Angriffstool.

MEV und wirtschaftliche Angriffe

MEV (Maximal Extractable Value – der von der Behörde zum Anordnen/Hinzufügen/Entfernen von Transaktionen extrahierte Wert) ist eine für DeFi spezifische Risikoklasse. Ausstehende Transaktionen werden im öffentlichen Pool (Mempool) angezeigt. Diese Sichtbarkeit öffnet Tür und Tor für folgende Angriffe:

• Front-Running: Eine gewinnbringende Transaktion sehen und die eigene Transaktion davor einfügen.
• Sandwich-Angriff: Transaktionen vor und nach dem Kauf des Opfers durchführen und von der Preisdifferenz profitieren.
• Oracle-Manipulation: Täuschung des Protokolls durch sofortige Änderung des Preises eines Pools, normalerweise durch einen Schnellkredit.

Diese Angriffe entstehen nicht durch den „Fehler“ des Codes, sondern durch die Ausnutzbarkeit des wirtschaftlichen Designs. Hier hat KI die größten Schwierigkeiten: KI, die technischen Code gut scannen kann, kann eine protokollspezifische wirtschaftliche Schwachstelle oft nicht erkennen.

Achtung: Bei den meisten DeFi-Schwachstellen handelt es sich nicht um „Codefehler“, sondern um Schwachstellen in der Wirtschafts-/Geschäftslogik. Beim standardmäßigen Code-Scannen von AI fehlen diese; Dies ist der Bereich, der das meiste menschliche Fachwissen, Simulation und Modellierung erfordert.

Die Rolle der KI in der DeFi-Analyse

1. Beschreibung des Mechanismus. KI ist in der Lage, im Klartext zu erklären, wie ein komplexes Protokoll (z. B. ein kurvenbasiertes AMM) funktioniert. Dies ermöglicht einen schnellen Einstieg in die Analyse.

2. Erstellen eines Szenarios/einer Gegenhypothese. „Bei welcher Preisbewegung wird dieses Schuldenprotokoll in eine Liquidationskrise geraten?“ KI erstellt Szenarioentwürfe mit Fragen wie: diese werden durch Simulation getestet.

3. Erinnern Sie sich an bekannte Angriffsmuster. Die KI ruft die Muster vergangener DeFi-Angriffe (Orakelmanipulation, Wiedereintritt, Liquidationsspirale) wie eine Checkliste hervor.

4. Entwurf eines Simulationsplans. KI kann einen Plan erstellen, welche Szenarien getestet werden sollen; aber die Simulation selbst erfolgt mit dem Tool (Foundry, Tenderly).

Schwache Eingabeaufforderung / Starke Eingabeaufforderung

Schwache Eingabeaufforderung:

Ist dieses DeFi-Protokoll sicher?

Kraftvolle Aufforderung:

Ihre Rolle: DeFi-Protokollanalyst. Untersuchen Sie den Protokollmechanismus unten. Betrachten Sie nacheinander die folgenden wirtschaftlichen Angriffsvektoren: Oracle-Manipulation (mit Blitzkredit), Sandwich/Front-Running, Liquidationsspirale, Liquiditätsentzugseffekt. Für jeden Vektor: Wie wird ausgelöst, welche Bedingung ist erforderlich, mögliche Auswirkungen. Dies sind die Hypothesen, die DURCH SIMULATION getestet werden müssen; Sagen Sie nicht unbedingt „sicher/unsicher“. GENERATE Tatsächlicher Angriffscode; Beschreiben Sie das Risiko nur zu Verteidigungszwecken.

Vier kopierbare Vorlagen

1) Beschreibung des Mechanismus:

Erklären Sie im Klartext Schritt für Schritt den Preis-/Liquiditätsmechanismus dieses Protokolls: Was passiert, wenn ein Benutzer eine Transaktion durchführt, wie wird der Preis ermittelt, welche externen Abhängigkeiten gibt es? Markieren Sie den Teil, den Sie nicht verstehen, oder lassen Sie ihn unklar.

2) Wirtschaftliche Angriffsfläche:

Kartieren Sie die wirtschaftliche Angriffsfläche dieses Protokolls: Welche Annahmen können in Oracle, Liquidität, Sicherheit, Liquidation, Governance ausgenutzt werden? Schreiben Sie jedes Risiko mit einer Bedingung („Was wäre wenn“). Präsentieren Sie es als Hypothese, die durch Simulation bestätigt werden soll.

3) Stressszenario:

Betrachten Sie die folgenden Szenarien: Wenn der Collateral-Token um 50 % fällt, wenn der Oracle-Preis vorübergehend um 30 % abweicht, wenn 80 % der Liquidität abgezogen werden, wie wird das Protokoll aussehen? Notieren Sie die Folgewirkung jedes Szenarios. Beanspruchen Sie keine numerische Präzision; Geben Sie an, dass eine Simulation erforderlich ist.

4) Vergleich der Verlaufsangriffsmuster:

Erfüllt das Design dieses Protokolls ähnliche Bedingungen wie die bekannten DeFi-Angriffsmuster (z. B. Single-Source-Oracle, Flash-Loan-Open-Price)? Weisen Sie zu Verteidigungszwecken auf Ähnlichkeiten hin; Machen Sie nicht den Exploit-Schritt, er erzeugt nur einen Punkt der Aufmerksamkeit.

Drei Minikoffer (in Zahlen)

Fall 1 – Oracle-Risiko frühzeitig erkannt. Ein Team entwarf ein neues Schuldenprotokoll. Während der Erklärung des Mechanismus stellte YZ die Hypothese auf, dass „der Preis einem einzigen Pool entnommen wird und mit Schnellkrediten manipuliert werden kann“. Das Team bestätigte dies in der Simulation und wechselte zu TWAP + Multi-Sourcing. Geschätzter vermiedener Verlust: der gesamte gesperrte Wert des Protokolls. Lektion: KI ist wertvoll, wenn es darum geht, bekannte Muster hervorzurufen.

Fall 2 – KI hat die ursprüngliche Schwachstelle übersehen. In einem anderen Protokoll handelte es sich bei der Schwachstelle um einen einzigartigen wirtschaftlichen Fehler, der aus dem Zusammenspiel zweier Mechanismen (Belohnung + Liquidation) resultierte. Die KI fand jeden Mechanismus nacheinander „fehlerfrei“; Konnte die Interaktion nicht sehen. Menschlicher Modellierer und Simulation erfasst. Lektion: Während die Komponenten stimmen, ist die Wirtschaftlichkeit des Ganzen der blinde Fleck der KI.

Fall 3 – Der Simulationsplan sparte Zeit. Ein Analyst entwarf 15 verschiedene Stressszenarien in der KI, anstatt sie manuell zu planen; Dann ließ ich es bei Foundry laufen. Die Planung verkürzte sich von einem Tag auf zwei Stunden. aber die Interpretation der Ergebnisse und die Entscheidung waren Sache des Menschen. Lektion: KI-Pläne, Fahrzeugmaßnahmen, menschliche Entscheidungen.

Die Unverzichtbarkeit der Simulation

Bei DeFi wird Sicherheit nicht durch „Denken“ bewiesen; Es wird durch Simulation getestet. Die wirtschaftliche Robustheit eines Protokolls kann durch numerisches Durchspielen verschiedener Preis-, Liquiditäts- und Angriffsszenarien verstanden werden. KI kann den Code dieser Simulationen planen und entwerfen; Aber es sind die Werkzeuge und Menschen, die die Ergebnisse produzieren und interpretieren. Die von der KI erzeugte Aussage „wahrscheinlich langlebig“ ist kein Simulationsergebnis und kann nicht als solches dargestellt werden.

Tipp: Wenn Sie eine DeFi-Risikobewertung von AI erhalten, sollten Sie jede Hypothese fragen: „Mit welcher Simulation teste ich das?“ Machen Sie daraus eine Frage. Ein Sicherheitsanspruch, der nicht überprüft werden kann, ist in DeFi keine Zusicherung.

Häufige Fehler

• Das Wirtschaftsdefizit scannen wie ein Codefehler. DeFi-Risiken liegen hauptsächlich in der Geschäftslogik.
• Der KI vertrauen, dass sie „sicher“ sagt, und die Simulation überspringen. Tests sind erforderlich.
• Komponenten einzeln validieren und Interaktion überspringen. Die Ökonomie des Ganzen ist entscheidend.
• Vertrauen Sie Oracle aus einer Hand. Die häufigste DeFi-Katastrophe.
• Ignorieren von MEV/Frontrunning. Vergessen Sie die Tatsache des öffentlichen Mempools.
• Generieren von Exploit-Code. Nur eine defensive Analyse ist legitim.

Zusammenfassend

• DeFi ist ein hochwertiger und feindseliger Raum; Die Risiken liegen hauptsächlich in der wirtschaftlichen/geschäftlichen Logik.
• MEV, Front-Running, Sandwich und Oracle-Manipulation sind für DeFi spezifische Angriffsklassen.
• KI ist stark in der Erklärung von Mechanismen und beim Entwerfen von Szenarien. Das ursprüngliche Wirtschaftsdefizit ist gering.
• Wirtschaftliche Sicherheit wird durch Simulation bewiesen, nicht durch Denken; KI-Pläne, Fahrzeugmaßnahmen.
• Die Oracle-Abhängigkeit ist der anfälligste Punkt von DeFi. Mehrere Ressourcen und TWAP erforderlich.

Anwendungsaufgabe

Wählen Sie ein AMM- oder Kreditprotokoll (mit klarer Dokumentation). Wenden Sie die Eingabeaufforderungen „Mechanismusbeschreibung“ und „wirtschaftliche Angriffsfläche“ auf die KI an. Für jede Risikohypothese, die die KI erstellt, „mit welcher Simulation würde ich das testen?“ Beantworten Sie die Frage. Suchen Sie dann den tatsächlichen Prüfbericht dieses Protokolls und vergleichen Sie die tatsächlichen Ergebnisse mit den von der KI gemeldeten Risiken: Was hat die KI erkannt, was hat sie übersehen?

Checkliste

• [ ] Ich habe die Risiken in zwei Dimensionen diskutiert: Code + Wirtschaft.
• [ ] Ich habe MEV/Frontrunning bewertet.
• [ ] Ich habe auch die Oracle-Abhängigkeit untersucht.
• [ ] Ich habe das Zusammenspiel der Komponenten (der gesamten Wirtschaft) in Frage gestellt.
• [ ] Ich habe jede Hypothese mit einem Simulationsplan verknüpft.
• [ ] Ich habe den „Safe“ der KI durch Simulation ersetzt.
• [ ] Ich habe nur zu Verteidigungszwecken analysiert.