Was ein Smart-Contract-Audit aussagt und was nicht

„Auditiert“ steht auf Landingpages, als handle es sich um ein Zertifikat mit fest definierter Bedeutung. Das ist es nicht. Es ist eine Dienstleistung mit variablem Umfang, und der Unterschied zwischen einer gründlichen und einer oberflächlichen Prüfung ist am Gütesiegel nicht erkennbar.

Was ein Audit tatsächlich ist

Eine Firma wird beauftragt, einen festgelegten Satz von Contracts bei einem festgelegten Commit über einen festgelegten Zeitraum auf Mängel gegen ein festgelegtes Bedrohungsmodell zu prüfen. Sie erstellt einen Bericht, der Befunde nach Schweregrad auflistet, das Projekt reagiert darauf, und ein Abschlussbericht hält üblicherweise fest, was behoben wurde.

Jedes „festgelegt“ darin leistet Arbeit. Der Umfang wird ausgehandelt, und ein Bericht über drei Contracts sagt nichts über den vierten aus, der die Gelder hält.

Zuerst den Abschnitt zum Prüfungsumfang lesen

Der Umfang zeigt, welche Dateien geprüft wurden und bei welchem Commit-Hash. Daraus ergeben sich zwei Fragen, beide in wenigen Minuten zu beantworten.

Umfasst der Prüfungsumfang die Contracts, die tatsächlich Werte halten oder bewegen, oder nur periphere? Und stimmt der geprüfte Commit mit dem überein, was tatsächlich läuft? Code ändert sich nach einem Audit, und ein Bericht zu einem Commit von vor mehreren Upgrades beschreibt Software, die es nicht mehr gibt. Den bereitgestellten Bytecode gegen den geprüften Quellcode zu verifizieren ist die Prüfung, die diese Lücke schließt, und sie wird von denjenigen, die nur das Gütesiegel lesen, so gut wie nie durchgeführt.

Befunde und ihr Umgang

Berichte klassifizieren Befunde nach Schweregrad. Wichtiger als die Anzahl ist der Umgang damit: behoben, zur Kenntnis genommen oder bestritten.

„Zur Kenntnis genommen“ bedeutet, dass das Projekt den Befund gelesen und sich entschieden hat, nichts zu ändern. Das kann völlig vernünftig sein — der Befund mag einen akzeptierten Kompromiss beschreiben —, bedeutet aber, dass ein bekanntes Problem live ist, und das taucht in einer Zusammenfassung, die nur das Gütesiegel wiedergibt, nicht auf.

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

Wo Audits strukturell schwach sind

Bestimmte Kategorien sind durch reine Code-Prüfung schwer zu erfassen:

• Fehler im ökonomischen Design. Code, der sich exakt wie geschrieben verhält, dessen geschaffene Anreize aber ausnutzbar sind. Das erfordert eine Modellierung der Ökonomie des Systems, was eine andere Disziplin ist und häufig außerhalb des Prüfungsumfangs liegt.
• Composability. Ein Contract kann für sich genommen solide und in Kombination mit einem anderen, nicht vorhergesehenen Protokoll unsicher sein.
• Annahmen zu Oracles. Contracts, die auf externe Preisdaten angewiesen sind, übernehmen die Verlässlichkeit dieser Daten, und das Oracle liegt meist außerhalb des Prüfungsumfangs.
• Governance und Schlüssel. Ein aktualisierbarer Contract, der von einer kleinen Multisig kontrolliert wird, birgt ein Risiko, das keine Code-Prüfung adressiert, weil der Code das Upgrade konstruktionsbedingt erlaubt.

Der letzte Punkt verdient Betonung. Wenn ein Contract aktualisiert werden kann, beschreibt das Audit die aktuelle Implementierung, und die Inhaber der Upgrade-Schlüssel können sie ersetzen. Entscheidend ist dann, wer diese Inhaber sind und welches Verfahren sie kontrolliert — eine Governance-Frage im technischen Gewand.

Wie ein guter Bericht aussieht

Vollständig veröffentlicht statt nur zusammengefasst. Umfang mit Commit-Hashes angegeben. Befunde mit Schweregrad, Beschreibung und Umgang. Ein Methodikabschnitt, der beschreibt, was untersucht wurde und was nicht. Und ein Datum, damit Sie es mit der Deployment-Historie abgleichen können.

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

Wie man einen Bericht nutzt

Behandeln Sie ein Audit als Beleg dafür, dass ein Projekt Geld für Prüfung ausgegeben hat und bereit war, das Ergebnis zu veröffentlichen — das ist ein echtes Signal darüber, 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 bestehen: Welcher Anteil Ihres Bestands ist diesem Contract ausgesetzt, könnten Sie den Verlust verkraften, und ist die angebotene Rendite plausibel eine Entschädigung für dieses Risiko? Daran ändert das Vorhandensein eines Berichts nichts, und genau deshalb wird das Gütesiegel so eingesetzt, wie es eingesetzt wird.

Nicht alle Prüfungen haben dieselbe Tiefe

„Audit“ umfasst eine Bandbreite von Tätigkeiten mit sehr unterschiedlichen Kosten und unterschiedlicher Sorgfalt, und der Bericht macht diesen Unterschied nicht immer deutlich.

Eine manuelle Prüfung durch erfahrene Ingenieure, 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 einer Spezifikation genügt, was mächtig ist und nur so gut wie die Spezifikation selbst. Wettbewerbsbasierte Audit-Plattformen lagern die Prüfung per Crowdsourcing aus, was ein breites Spektrum an Problemen findet, aber eine weniger konsistente Abdeckung liefert.

Jede Methode hat ihre Rolle. Entscheidend ist zu wissen, mit welcher man es zu tun hat, und der Methodikabschnitt sagt das. Ein Bericht, der seine Methode nicht beschreibt, verlangt, allein auf die Kraft des Logos hin akzeptiert zu werden.

Bug-Bounties sagen etwas, das ein Bericht nicht kann

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

Die Höhe zählt. Eine Maximalauszahlung weit unter dem, was ein Exploit einbringen würde, ist kein Anreiz, sondern eine Geste — ein Forscher, der einen kritischen Fehler in einem Contract mit hohem Bestand findet, steht vor einem offensichtlichen Rechenproblem, wenn das Bounty im Vergleich dazu geringfügig ist. Bounties, die am gefährdeten Wert bemessen sind, sind ein echtes Signal dafür, wie ernst ein Projekt die Möglichkeit nimmt, dass es sich irrt.

Auch die Zeit im Produktivbetrieb ist ein Beleg

Contracts, die über einen langen Zeitraum erhebliche Werte ohne Zwischenfall gehalten haben, wurden der strengsten verfügbaren Prüfung unterzogen: anhaltender Aufmerksamkeit von Menschen mit einem finanziellen Anreiz, sie zu brechen.

Das ist kein Beweis — schlummernde Fehler existieren, und mehrere langlebige Protokolle sind spät gescheitert. Aber ein kürzlich bereitgestellter Contract mit einem Bericht und ohne Betriebshistorie wurde von einer Firma über ein paar 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: den Bericht dafür lesen, was untersucht wurde, und die Deployment-Historie dafür gewichten, was der Bericht nicht abdecken konnte.