Formale Verifizierung vs. Audits: Warum „Wir haben den Code überprüft“ nicht mehr ausreicht

Nach Audits habe ich immer tief und fest geschlafen. Ich nicht mehr. Als ich zum ersten Mal sah, wie ein Post-Audit-Protokoll 30 Millionen US-Dollar durch eine von den Prüfern übersehene staatliche Interaktion verlor, sagte ich mir, dass es sich um einen Randfall handelte. Beim zweiten Mal gab ich dem Zielfernrohr die Schuld. Beim dritten Mal – etwa bei der fünften Obduktion, die ich in dieser Woche gelesen hatte – wurde mir klar, dass das Problem nicht bei den Prüfern lag. Es war die Methodik. Bei Audits lesen Menschen Code und schreiben Tests. Menschen vermissen Dinge. Testet fehlende Pfade. Und bei einem intelligenten Vertrag, der echtes Kapital verwaltet, ist „wir haben wahrscheinlich alles“ kein Sicherheitsmodell. Es ist ein Wunsch. Inhaltsverzeichnis Das Muster ist düster vorhersehbar geworden. Ein Protokoll beschafft Kapital, gibt eine Prüfung bei einem angesehenen Unternehmen in Auftrag, erhält einen Bericht, behebt die gemeldeten Probleme, stellt es bereit und gibt seiner Community „geprüft“ bekannt. Monate später – manchmal Wochen – ist das Geld weg. Team Finance verlor im Oktober 2022 14,5 Millionen US-Dollar. Zwei separate Wirtschaftsprüfungsgesellschaften hatten die Codebasis überprüft. Einer hatte die anfällige Migrationsfunktion gemeldet. Der Vertrag wurde trotzdem ausgenutzt. Am 18. April 2026 wurden der LayerZero-betriebenen Brücke von Kelp DAO 116.500 rsETH entzogen – etwa 292 Millionen US-Dollar und etwa 18 % des gesamten Umlaufangebots des Tokens. Es handelte sich um den größten DeFi-Exploit des Jahres 2026. Das Fazit der Obduktion: Es wurde kein Smart Contract gebrochen. Es wurde kein kryptografisches Grundelement kompromittiert. Die Verträge erfüllten genau das, was sie geschrieben hatten. Der Fehler lag in der Off-Chain-Verifier-Infrastruktur – einer Einzel-DVN-Konfiguration, die es einem Angreifer ermöglichte, eine kettenübergreifende Nachricht zu fälschen. Der Prüfbericht konnte dies nicht erkennen, da am Vertragscode nichts falsch war. Im Jahr 2025 beliefen sich die Gesamtverluste bei Web3 durch 313 große Sicherheitsvorfälle auf 3,375 Milliarden US-Dollar. Wenn ein Audit zu einem Kontrollkästchen wird – zu einer Sache, die ein Projekt tut, um Sorgfalt zu signalisieren, und nicht zu einem Prozess, der das Risiko sinnvoll reduziert –, hat die Branche ein strukturelles Problem. Und das tut es. Lassen Sie mich näher darauf eingehen, was ein Smart-Contract-Audit bietet, denn die Branche neigt dazu, dies zu beschönigen. Bei einem Audit liest ein Team von Sicherheitsforschern Ihren Code, führt statische Analysen aus, schreibt benutzerdefinierte Testfälle und dokumentiert die Ergebnisse. Die besten Unternehmen erkennen Wiedereintrittsschwachstellen, Ganzzahlüberläufe, Zugriffskontrollprobleme, Logikfehler und gefährliche wirtschaftliche Grenzfälle. Ihre Berichte sind detailliert und wirklich wertvoll. Eine Prüfung wird jedoch durch die menschliche Aufmerksamkeit und die von den Prüfern berücksichtigten Szenarien begrenzt. Bei keinem Audit werden alle möglichen Ausführungswege im Rahmen eines Vertrags umfassend untersucht. Der Zustandsraum eines nicht trivialen Smart Contracts – jede mögliche Kombination von Eingaben, Speicherzuständen, Aufruferkontexten und Ausführungssequenzen – ist zu groß, als dass ein Mensch oder Fuzzer ihn erschöpfend abdecken könnte. Fuzzing erfasst etwa 80 % der Probleme durch zufällige Eingabegenerierung. Die restlichen 20 % verstecken sich in mathematischen Randfällen, die zufällige Eingaben nie erreichen. Ein Prüfer, der ein Ersteinzahlungsszenario testet, stellt möglicherweise nie den genauen Zustand her, in dem „totalSupply“ 1 und „totalAssets“ type(uint256).max ist, was zu einem Inflationsangriff führt. Ein Audit antwortet: „Haben wir Fehler gefunden?“ Die Antwort lautet nicht und kann strukturell auch nicht sein: „Es sind keine Fehler vorhanden.“ Das ist keine Kritik an Wirtschaftsprüfern. Es handelt sich um eine mathematische Einschränkung der Methode. Bei der formalen Verifizierung handelt es sich um eine grundlegend andere Kategorie der Sicherheit. Anstatt den Code von Menschen lesen und nach Problemen suchen zu lassen, übersetzt die formale Verifizierung intelligente Verträge in mathematische Spezifikationen und verwendet dann einen automatisierten Prüfer, um umfassend nach Ausführungspfaden zu suchen, die gegen diese Spezifikationen verstoßen. Der Prüfer wird nicht müde. Randfälle werden nicht übersehen, weil die Zeit abgelaufen ist. Es ist nicht versäumt, ein Szenario in Betracht zu ziehen, weil es unwahrscheinlich erschien. Es untersucht systematisch den gesamten durch die Spezifikation definierten Zustandsraum. Wenn der Prüfer einen Verstoß feststellt – einen Zustandsübergang, von dem die Spezifikation sagt, dass er unmöglich sein sollte, der Code es aber zulässt – besteht die Überprüfung des Vertrags nicht. Das Team behebt das Problem und überprüft es erneut. Wenn der Prüfer keine Verstöße feststellt, hat er einen mathematischen Beweis erbracht. Keine Wahrscheinlichkeit. Kein hohes Vertrauensniveau. Ein Beweis dafür, dass sich der Code innerhalb der angegebenen Eigenschaften nicht auf nicht spezifizierte Weise verhalten kann. Der Schlüsselbegriff: innerhalb der angegebenen Eigenschaften. Eine formelle Verifizierung beweist, was Sie angeben. Wenn Sie die falschen Dinge angeben oder eine wichtige Eigenschaft nicht angeben, deckt der Beweis dies nicht ab. Aus diesem Grund ist das Schreiben präziser Spezifikationen – der Invarianten, der Zustandsübergangsregeln, der Zugriffskontrolleigenschaften – genauso wichtig wie das Ausführen des Prüfers. Das stärkste Argument für eine formale Verifizierung ist nicht theoretisch. Es sind die konkreten Fehler, die der Versandcode – überprüft von mehreren menschlichen Experten – noch enthielt. Der DAI von MakerDAO, eine der am meisten untersuchten Codebasen in DeFi, enthielt von seiner ersten Einführung im November 2019 bis Mai 2022 eine Verletzung seiner eigenen Kerninvariante. Dabei handelte es sich um einen mathematischen Fehler in der grundlegenden Darstellung des Protokolls