Was ein Smart-Contract-Audit Ihnen sagt und was nicht

„Auditiert“ erscheint auf Landingpages, als wäre es eine Zertifizierung mit definierter Bedeutung. Ist es nicht. Es ist eine professionelle Dienstleistung mit variablem Umfang, und der Unterschied zwischen einer gründlichen und einer flüchtigen Prüfung ist am Siegel nicht zu erkennen.

Was ein Audit tatsächlich ist

Eine Firma wird beauftragt, eine festgelegte Menge von Verträgen zu einem festgelegten Commit über einen festgelegten Zeitraum zu prüfen und dabei nach Fehlern gegen ein festgelegtes Bedrohungsmodell zu suchen. Sie erstellt einen Bericht, der die Funde nach Schweregrad auflistet, das Projekt antwortet, und ein Abschlussbericht hält meist fest, was behoben wurde.

Jedes „festgelegt“ dort leistet Arbeit. Der Umfang wird verhandelt, und ein Bericht über drei Verträge sagt nichts über den vierten, der die Mittel hält.

Lesen Sie zuerst den Abschnitt zum Umfang

Der Umfang sagt Ihnen, welche Dateien geprüft wurden und bei welchem Commit-Hash. Daraus folgen zwei Fragen, und beide lassen sich in wenigen Minuten beantworten.

Umfasst der Umfang die Verträge, die tatsächlich Wert halten oder bewegen, oder nur periphere? Und stimmt der geprüfte Commit mit dem überein, was ausgerollt ist? Code ändert sich nach einem Audit, und ein Bericht gegen einen Commit von vor mehreren Upgrades beschreibt Software, die es nicht mehr gibt. Den ausgerollten Bytecode gegen den auditierten Quellcode zu verifizieren ist die Prüfung, die diese Lücke schließt, und sie wird von denen, die das Siegel lesen, selten durchgeführt.

Funde und ihre Behandlung

Berichte ordnen Funde nach Schweregrad. Wichtiger als die Anzahl ist die Behandlung: behoben, anerkannt oder bestritten.

„Anerkannt“ bedeutet, dass das Projekt den Fund gelesen und sich entschieden hat, nichts zu ändern. Das kann völlig vernünftig sein — der Fund beschreibt womöglich eine akzeptierte Abwägung — aber es bedeutet, dass ein bekanntes Problem live ist, und es taucht in einer Zusammenfassung, die nur das Siegel meldet, nicht auf.

Ein Bericht ganz ohne Funde ist kein Triumph. Er bedeutet meist einen engen Umfang oder eine oberflächliche Prüfung. Kompetente Prüfungen nicht trivialer Systeme finden etwas.

Worin Audits strukturell schwach sind

Bestimmte Kategorien sind durch die Prüfung von Code schwer zu erkennen:

• Fehler im ökonomischen Design. Code, der sich genau so verhält, wie er geschrieben ist, wobei die von ihm gesetzten Anreize ausnutzbar sind. Das erfordert eine Modellierung der Ökonomie des Systems, was eine andere Disziplin ist und häufig außerhalb des Umfangs liegt.
• Komponierbarkeit. Ein Vertrag kann für sich genommen solide und in Kombination mit einem anderen, von niemandem vorhergesehenen Protokoll unsicher sein.
• Annahmen zum Orakel. Verträge, die auf externe Preisdaten setzen, erben die Verlässlichkeit dieser Daten, und das Orakel liegt meist außerhalb des Umfangs.
• Governance und Schlüssel. Ein aktualisierbarer Vertrag, der von einer kleinen Multisig kontrolliert wird, birgt ein Risiko, das keine Code-Prüfung adressiert, weil der Code das Upgrade konstruktionsbedingt zulässt.

Der letzte Punkt verdient Nachdruck. Lässt sich ein Vertrag aktualisieren, beschreibt das Audit die aktuelle Implementierung, und wer die Upgrade-Schlüssel hält, kann sie ersetzen. Wichtig ist dann, wer diese Haltenden sind und welches Verfahren sie regelt — eine Governance-Frage mit technischem Siegel.

Wie ein guter Bericht aussieht

Vollständig veröffentlicht statt zusammengefasst. Umfang mit Commit-Hashes angegeben. Funde mit Schweregrad, Beschreibung und Behandlung. Ein Abschnitt zur Methodik, der beschreibt, was geprüft wurde und was nicht. Und ein Datum, damit Sie ihn mit der Rollout-Historie abgleichen können.

Ein Projekt, das all das veröffentlicht, tut etwas merklich anderes als eines, das ein Logo zeigt. Das Logo ist der Teil, der am wenigsten kostet.

Wie man ihn nutzt

Behandeln Sie ein Audit als Beleg dafür, dass ein Projekt Geld für Prüfung ausgegeben und das Ergebnis veröffentlicht hat, was ein echtes Signal dafür ist, wie es arbeitet. Behandeln Sie es nicht als Sicherheitsgarantie, denn der Bericht erhebt diesen Anspruch nicht — der Haftungsausschluss darin sagt das meist ausdrücklich, in dem Abschnitt, den niemand zitiert.

Die praktischen Fragen bleiben: Welcher Anteil Ihrer Bestände ist diesem Vertrag ausgesetzt, könnten Sie dessen Verlust verkraften, und ist die angebotene Rendite plausibel eine Entschädigung für dieses Risiko? Daran ändert das Vorliegen eines Berichts nichts, und genau deshalb wird das Siegel so verwendet, wie es verwendet wird.

Nicht alle Prüfungen haben dieselbe Tiefe

„Audit“ deckt ein Spektrum an Tätigkeiten mit sehr unterschiedlichen Kosten und unterschiedlicher Strenge ab, und der Bericht macht den Unterschied nicht immer offensichtlich.

Eine manuelle Prüfung durch erfahrene Fachleute, die den Code lesen, ist das teure Ende. Automatisierte Analyse erkennt bekannte Muster günstig und übersieht alles Neuartige. Formale Verifikation beweist mathematisch, dass Code eine Spezifikation erfüllt, was mächtig und nur so gut wie die Spezifikation ist. Wettbewerbliche Audit-Plattformen lagern die Prüfung an eine Menge aus, was ein breites Spektrum an Problemen findet, aber eine weniger gleichmäßige Abdeckung erzeugt.

Jede hat ihre Rolle. Worauf es ankommt, ist zu wissen, welche Sie vor sich haben, und der Abschnitt zur Methodik sagt es. Ein Bericht, der seine Methode nicht beschreibt, verlangt, auf die Kraft des Logos hin geglaubt zu werden.

Bug-Bounties sagen etwas aus, was ein Bericht nicht kann

Ein Audit ist eine Momentaufnahme; ein Bug-Bounty läuft fortlaufend. Ein Projekt, das ein substanzielles, klar abgegrenztes Bounty mit öffentlicher Auszahlungshistorie betreibt, ist einer laufenden Prüfung ausgesetzt, wie sie eine einmalige Durchsicht nicht bietet.

Die Höhe zählt. Eine maximale Auszahlung weit unter dem, was ein Exploit einbringen würde, ist kein Anreiz, sondern eine Geste — wer eine kritische Schwachstelle in einem Vertrag findet, der eine große Summe hält, steht vor einem offensichtlichen Rechenproblem, wenn das Bounty im Vergleich trivial ist. Bounties, die am Wert unter Risiko bemessen sind, sind ein echtes Signal dafür, wie ernst ein Projekt die Möglichkeit nimmt, dass es falsch liegt.

Zeit im Produktivbetrieb ist ebenfalls ein Beleg

Verträge, die über einen langen Zeitraum ohne Zwischenfall erheblichen Wert gehalten haben, waren der strengsten verfügbaren Prüfung ausgesetzt: der anhaltenden Aufmerksamkeit von Menschen, die finanziell motiviert sind, sie zu brechen.

Das ist kein Beweis — schlummernde Fehler existieren, und mehrere langlebige Protokolle sind spät gescheitert. Aber ein kürzlich ausgerollter Vertrag mit einem Bericht und ohne Betriebshistorie wurde von einer Firma über wenige Wochen geprüft. Ein älterer mit demselben Bericht hat zusätzlich Jahre feindseligen Interesses überstanden, und das ist eine andere Qualität von Beleg.

Beides zu kombinieren ist der praktische Ansatz: Lesen Sie den Bericht für das, was geprüft wurde, und gewichten Sie die Rollout-Historie für das, was der Bericht nicht abdecken konnte.