Smart-Contract-Audit: der Umfang gilt, und nichts darüber hinaus

Ein Scoping-Dokument pinnt Repository, Branch und Commit-Hash und listet, welche Contracts, Bibliotheken und Deployment-Skripte drin sind. Die Liste des Ausgeschlossenen zählt genauso: Frontends, Indexer, Off-Chain-Keeper, das Betriebsverfahren der Governance-Multisig und jedes integrierte Fremdprotokoll liegen normalerweise draußen, und ihr Fehlen ist der Grund, warum ein geprüftes Protokoll über eine ungeprüfte Komponente Geld verlieren kann.

Praktische Bedingung ist stabiler Code während der Prüfung. Sherlocks Darstellung des Ablaufs setzt den richtigen Zeitpunkt nach dem Festlegen des Entwurfs und dem Testen der Contracts an, wenn das Team eine stabile Version über die Dauer halten kann. Ein Umfang, der mitten in der Prüfung wandert, streckt die Dauer und lässt Teile gegen Annahmen geprüft, die nicht mehr gelten. Einfache Contracts brauchen eine bis zwei Wochen, ein komplexes Protokoll mit Fremdintegrationen drei bis sechs, dazu die Fix-Runde danach.

Eine solide Prüfung läuft zweimal über denselben Code. Der erste Durchgang klärt, was der Code soll: das gewollte Verhalten, die Annahmen der Entwickler und die Invarianten, die immer gelten müssen. Der zweite greift diese Annahmen an. Dedaub beschreibt diese Teilung als Analyse der regulären Nutzung, gefolgt von der Analyse aus Angreifersicht, und die Reihenfolge zählt, denn eine nicht aufgeschriebene Annahme lässt sich nicht unterlaufen.

Vier Techniken tragen die Arbeit, und jede findet eine andere Fehlerklasse. Statische Analyse führt Mustererkennung über den Code und fängt die bekannten Formen: ein fehlender Zugriffsmodifizierer, ein ungeprüfter Rückgabewert, ein driftendes Rechenmuster. Fuzzing erzeugt große Mengen Eingaben und treibt den Contract in Zustände, die ein handgeschriebener Test nie erreicht, und zustandsbehaftetes Fuzzing über lange Aufruffolgen findet die Fehler, die nur bei einer bestimmten Reihenfolge erscheinen. Formale Verifikation beweist eine kleine Zahl kritischer Invarianten mathematisch, ist teuer und bleibt darum den Zusagen vorbehalten, deren Bruch total wäre. Die manuelle Prüfung durch Erfahrene findet, was keine der drei kann: einen Logikfehler, bei dem der Code genau das tut, was er sagt, und das Falsche sagt.

Die Techniken ersetzen sich nicht, und jede lässt eine vorhersehbare Lücke. Statische Analyse endet, wo Verständnis der Absicht beginnt. Fuzzing findet nur den Bruch einer Eigenschaft, die jemand formuliert hat, eine unformulierte Invariante wird also nie geprüft. Formale Verifikation beweist die angegebene Eigenschaft über das gebaute Modell, und eine falsche Spezifikation verifiziert sauber.

Ein belastbarer Bericht benennt vier Dinge. Den Umfang: Repository, Commit-Hash und die Grenzen, Ausgeschlossenes eingeschlossen. Die Methode: welche Techniken liefen, welche Werkzeuge, wie viele Prüfende. Die Befunde: jeder mit Schweregrad, mit einer Erklärung der Wirkung in der Form, was ein Angreifer bekommt, und mit einem Pfad, den ein Entwickler nachstellen kann. Und die Behebung je Befund, konkret genug zum Handeln.

Dann die Fix-Runde, der Teil, den Teams unter Termindruck weglassen. Die Prüfenden testen die Patches nach, statt die Behauptung zu übernehmen, dass sie wirken, und bestätigen, dass der ausgerollte Code dem geprüften entspricht. Ein Bericht ohne diesen Abschnitt dokumentiert Probleme und keine Lösung. Wo ein Befund als Risiko angenommen und nicht behoben wurde, gehört die Begründung ins Dokument, denn der nächste Leser muss wissen, dass das absichtlich geschah.

Die übliche Leiter heißt kritisch, hoch, mittel, niedrig und informativ, und das Etikett sagt weniger, als es scheint. Firmen ziehen die Grenzen anders: eine nach dem Geld im Risiko, eine nach der Erreichbarkeit des Pfads, eine dritte nach einer Matrix aus beidem. Was eine Firma hoch nennt, steht im Bericht einer anderen über denselben Code als mittel.

Damit sind Befundzahlen als Vergleich zweier Berichte wertlos. Zwei Audits desselben Protokolls durch verschiedene Firmen ergeben verschiedene Summen, weil anders gezählt wurde, und nicht weil eine mehr gefunden hat. Nutzbar ist der Inhalt: was ein Befund bei Ausnutzung kostet, ob der Pfad von einem unprivilegierten Aufrufer erreichbar ist, und was das Team getan hat. Ein Bericht mit drei Befunden, die ihre Wirkung konkret erklären, sagt mehr als einer mit dreißig informativen Hinweisen.

Die OWASP Smart Contract Top 10 sammelt, was tatsächlich Verluste verursacht, und die oberen Einträge haben sich über Jahre kaum verändert. Zuerst Fehler in der Zugriffskontrolle: eine privilegierte Funktion, die ein Aufrufer erreicht, der sie nicht erreichen sollte, meist ein fehlender Modifizierer oder eine Initialisierung, die zweimal laufen kann. Dann Reentrancy, wo ein externer Aufruf dem Aufgerufenen den Wiedereintritt erlaubt, bevor die erste Ausführung ihre Zustandsänderungen abschloss.

Dritter ist die Manipulation des Preisorakels, und dort beißt die Audit-Grenze am stärksten, denn der Contract kann korrekt und die Eingabe falsch sein. Ein Contract, der einen Spotkurs aus einem einzelnen Pool liest, lässt sich über diesen Pool angreifen, und keine Prüfung des Contracts behebt einen Entwurf, der einer manipulierbaren Quelle vertraut. Danach Logikfehler in den Geldflüssen, wo der Code kompiliert und unter einer bestimmten Bedingung das Falsche ergibt, und ungeprüfte externe Aufrufe, wo ein nicht ausgewerteter Rückgabewert einen Fehlschlag als Erfolg durchgehen lässt.

Die stille Klasse ist das Runden. Eine Division, die zugunsten des Protokolls abschneidet, ist unproblematisch; dieselbe Kürzung zugunsten des Nutzers, oft genug wiederholt, leert einen Pool Wei für Wei. Die forensische Seite behandelt Finance Loop unter Blockchain-Forensik, die Entwicklungspraxis unter Blockchain-Softwareentwicklung.

Vier Gründe, und alle vier liegen außerhalb des Berichts. Der ausgerollte Code weicht vom geprüften ab, durch eine späte Änderung oder einen anderen Build. Die Deployment-Parameter weichen ab, ein geprüfter Contract wird also mit einer Konfiguration initialisiert, die niemand modelliert hat. Eine Abhängigkeit kommt danach: ein neues Orakel, ein Token mit Transfergebühr, eine Bridge. Oder der Contract wird aktualisiert, und die neue Implementierung wurde nie geprüft.

Der Fall der Komponierbarkeit verdient eine eigene Erwähnung, denn er erwischt sorgfältige Teams. Zwei Protokolle, jedes für sich korrekt geprüft, können ein ausnutzbares Zusammenspiel ergeben, wenn eines einen Wert liest, den das andere in derselben Transaktion bewegen kann. Niemandes Umfang deckte das Paar. Das ist das Argument für Laufzeitüberwachung und für ein Bug-Bounty auf laufenden Code, was ein Audit weder ersetzt noch ersetzt wird: Ein Audit sieht eine Momentaufnahme, ein Bounty bezahlt Angreifer dafür, das Laufende anzusehen.

Drei Modelle für drei Fragen. Ein privates Audit setzt wenige erfahrene Prüfende für einen festen Zeitraum auf den Code, was Tiefe, einen benannten Vertragspartner und einen Bericht ergibt, den eine Aufsicht oder ein Investor lesen kann. Ein Audit-Wettbewerb öffnet den Code parallel einem großen Feld von Forschenden, was Breite ergibt: Hundert Leute finden die flachen Probleme schnell und gelegentlich das tiefe, das dem blinden Fleck eines kleinen Teams entging. Ein Bug-Bounty läuft dauerhaft gegen ausgerollten Code und zahlt je gültigem Befund.

Ein regulierter Emittent braucht das private Audit, denn das Ergebnis muss benennen, wer was geprüft hat, und dafür einstehen. Ein Protokoll mit erheblichen Werten im Risiko hat am Ende meist alle drei hintereinander: die private Prüfung vor dem Start, einen Wettbewerb für die Breite und danach das laufende Bounty.

Trägt ein Smart Contract ein Wertpapier, ist das Audit keine Entwicklerentscheidung mehr. Das Register eines tokenisierten Wertpapiers muss rechtlich wirksam sein, der Emittent muss also nachweisen, wer einen Bestand bewegen kann, wer ihn sperren oder wiederherstellen kann, und unter welcher Befugnis ein Upgrade diese Antwort ändert. Das Audit ist das Dokument, das zeigt, dass die privilegierten Rollen erkannt und der Upgrade-Pfad geprüft wurden. Das Instrument behandelt Finance Loop unter tokenisierte Wertpapiere.

Aufsichtsbehörden anderswo haben die Anforderung aufgeschrieben. Die VARA in Dubai und die SFC in Hongkong formulieren beide Erwartungen an den Smart Contract hinter einer regulierten Tätigkeit, und die Entwurfsanforderungen des EU Data Act an Smart Contracts in Datenteilungsverträgen gingen durch eine öffentliche Auseinandersetzung, bevor sie verengt wurden. Die Richtung ist überall dieselbe: Ein Contract mit regulierter Funktion braucht einen geprüften Pfad zur Beendigung oder Unterbrechung, damit sich etwas anhalten lässt. Die Resilienzseite behandelt Finance Loop unter Cybersicherheit in der Finanzbranche.

Ein Smart-Contract-Audit ist eine strukturierte Sicherheitsprüfung des Codes, der Nutzergelder und Protokolllogik auf einer Blockchain steuern wird, durchgeführt an einer festen Version dieses Codes und geliefert als Bericht mit Befunden, Schweregraden und Behebungsvorschlägen. Es ist eine Prüfung und keine Zertifizierung: Die Prüfenden sagen, was sie ansahen und was sie fanden, und die Verantwortung für das ausgerollte System bleibt beim Team, das es ausrollt.

Eine bis zwei Wochen für einen einfachen Contract, drei bis sechs für ein komplexes Protokoll mit Fremdintegrationen, dazu eine Fix-Runde nach dem Patchen. Am stärksten streckt nicht die Codemenge, sondern die Codebewegung: Ein wandernder Umfang erzwingt, Teile der Prüfung zu wiederholen. Ein Team, das den Branch vor dem Auftrag einfriert, bekommt den zugesagten Zeitplan.

Alles außerhalb des Scoping-Dokuments, meist also Frontend, Off-Chain-Dienste, Schlüsselverwaltung der privilegierten Konten, Governance-Prozess und jedes integrierte Fremdprotokoll. Es deckt auch die Zukunft nicht ab: Ein späteres Upgrade, eine neue Abhängigkeit oder ein geänderter Parameter ist ungeprüfter Code, was der frühere Bericht auch sagte. Und es deckt den wirtschaftlichen Entwurf nicht ab, sofern der Auftrag das nicht ausdrücklich einschloss, ein ausnutzbarer Mechanismus besteht also ein Audit, während jede Zeile tut, was sie sagt.

Einen statischen Analysator über Quelltext und Bytecode für die bekannten Fehlerformen, einen eigenschaftsbasierten Fuzzer wie Echidna oder Medusa, dem das Team Invarianten vorgibt, die er über zufällige Eingaben und lange Aufruffolgen zu brechen versucht, ein Werkzeug zur formalen Verifikation für die wenigen beweiswürdigen Invarianten, und ein Test- und Simulationsgerüst, um einen Befund auf einem Fork der laufenden Chain nachzustellen. Die Werkzeuge liefern Kandidaten, die Prüfenden entscheiden, welche echt sind, und darum ist ein Bericht aus Werkzeugausgaben kein Audit.

Kein allgemeines Gesetz verlangt es, die Vertragspartner tun es in der Praxis. Ein Handelsplatz, ein Verwahrer, ein Versicherer und ein institutioneller Investor fragen den Bericht ab, bevor sie das Risiko nehmen, und ein regulierter Emittent eines tokenisierten Wertpapiers braucht ihn für die eigene Dokumentation der Registerintegrität. Die Anforderung kommt kaufmännisch vor der rechtlichen.