Smart Contract Audits: What Auditors Check—and What an Audit Does Not Guarantee

Ein Smart-Contract-Audit ist eine unabhängige Prüfung von Code und Architektur innerhalb eines festgelegten Umfangs. Ziel ist es, Schwachstellen, Implementierungsfehler und Abweichungen zwischen vorgesehenem und tatsächlichem Verhalten zu erkennen.

Ein Audit kann Unsicherheit verringern, macht einen Vertrag jedoch nicht risikofrei. Die offizielle Sicherheitsdokumentation von Ethereum beschreibt Audits als zusätzliche Prüfung und nicht als Allheilmittel, das jeden Fehler erkennt.

Dieser Artikel dient ausschließlich Bildungszwecken. Ein Audit garantiert weder Sicherheit noch die Wiederbeschaffung von Mitteln oder Erträge.

Der Prüfungsumfang steht an erster Stelle

Ein aussagekräftiger Bericht nennt genau, was geprüft wurde:

Repository und Commit-Hash;
Dateien und Verträge;
Compiler-Version und Build-Einstellungen;
Abhängigkeiten;
Architektur und privilegierte Rollen;
Branch oder Release;
Ausschlüsse, Einschränkungen und Annahmen;
Prüfdatum.

Dies ist wichtig, weil selbst ein echtes Audit eine alte Version, ein anderes Deployment oder nur einen Teil eines größeren Systems abdecken kann.

Was Auditoren üblicherweise prüfen

1. Vorgesehenes Verhalten und Invarianten

Auditoren vergleichen den Code mit seiner Spezifikation:

wer die jeweilige Funktion aufrufen darf;
wie Beträge und Gebühren berechnet werden;
wann Statusänderungen erfolgen;
welche Eigenschaften stets erfüllt bleiben müssen;
wie Grenzfälle und Fehler behandelt werden.

Fehlt in der Spezifikation eine wichtige Anforderung, kann technisch korrekter Code dennoch ein unsicheres oder unerwünschtes Design umsetzen.

2. Zugriffskontrolle

Prüfer untersuchen Eigentümer-, Administrator-, Operator- und andere privilegierte Rollen einschließlich der Befugnis:

Berechtigungen erteilen oder widerrufen;
System pausieren;
Gebühren und Grenzen ändern;
Token prägen;
Assets auszahlen;
eine Implementierung aktualisieren.

Außerdem wird geprüft, ob ein einzelner Schlüssel eine kritische Änderung ausführen kann und ob Kontrollmechanismen wie Multisignatur oder Zeitsperre Teil des Designs sind.

3. Externe Aufrufe und Reentrancy

Ein Vertrag kann während der Ausführung die Kontrolle an einen anderen Vertrag übergeben. Dadurch kann Reentrancy entstehen: Der externe Vertrag ruft zurück, bevor die ursprüngliche Zustandsänderung abgeschlossen ist. Die offizielle Solidity-Dokumentation empfiehlt, Prüfungen, Zustandsänderungen und externe Interaktionen gegebenenfalls sorgfältig zu ordnen.

4. Berechnungen und Einheiten

Auditoren suchen nach:

Rundungs- und Genauigkeitsverluste;
nicht übereinstimmende Token-Dezimalstellen;
falsche Reihenfolge von Vorgängen;
Grenzwerte;
Division durch null;
unsafe unchecked arithmetic;
Abweichungen zwischen internen und angezeigten Einheiten.

5. Denial of Service und Gas

Unbegrenzte Schleifen, wachsende Arrays, fehlgeschlagene externe Aufrufe oder rechenintensive Vorgänge können die Ausführung einer Funktion unpraktikabel machen. Prüfer testen, ob das Design bei wachsenden Datenmengen und ungewöhnlichen Eingaben nutzbar bleibt.

6. Proxys und Upgrades

Bei aktualisierbaren Systemen sollte die Prüfung Folgendes umfassen:

Proxy- und Implementierungsverträge;
Upgrader- oder Administratorrechte;
Initialisierung;
Kompatibilität des Speicherlayouts;
nicht autorisierte Upgrade-Pfade;
die Auswirkungen einer Logikänderung nach dem Audit.

Ein Proxy kann dieselbe für Benutzer sichtbare Adresse beibehalten und Aufrufe an eine neue Logik weiterleiten. Aussagen wie „Der Vertrag kann nicht geändert werden“ müssen deshalb anhand der tatsächlichen Architektur geprüft werden.

7. Integrationen

Verträge können von Token, Preisorakeln, Bridges, DEXs, Signaturen oder anderen Verträgen abhängen. Auditoren untersuchen Annahmen zu diesen Abhängigkeiten, veraltete Daten, ungewöhnliches Token-Verhalten und externe Ausfallszenarien.

8. Ereignisse und Überwachung

Prüfer können untersuchen, ob Events wichtige Aktionen wie Rollenänderungen, Upgrades, Pausen und Übertragungen korrekt offenlegen. Events erleichtern die Überwachung, ersetzen jedoch nicht die Prüfung des Zustands.

Bei einem Audit verwendete Methoden

Eine Prüfung kombiniert üblicherweise:

manuelle Code- und Architekturanalyse;
Unit- und Integrationstests;
statische und dynamische Analyse;
Fuzzing mit generierten Eingaben;
eigenschaftsbasiertes Testen;
Prüfungen auf bekannte Schwachstellenklassen;
Prüfung von Build und Deployment;
gegebenenfalls formale Verifizierung ausgewählter Eigenschaften.

Keine einzelne Methode deckt alles ab. Formale Verifizierung kann beweisen, dass Code eine formale Spezifikation erfüllt; sie kann jedoch keine Eigenschaft beweisen, die in der Spezifikation nicht ausgedrückt wurde.

So sollten Benutzer ein Audit lesen

1. Mit der geprüften Version abgleichen

Ermitteln Sie den Commit-Hash und prüfen Sie:

ob die aktuelle Implementierung aus diesem Code erstellt wurde;
ob nach dem Berichtsdatum Upgrades erfolgt sind;
ob Blockchain und bereitgestellte Adressen übereinstimmen;
ob kritische Abhängigkeiten Teil des Prüfungsumfangs waren.

Lässt sich dies nicht feststellen, liefert der Bericht nur begrenzte Nachweise zum aktiven Deployment.

2. Befunde lesen, nicht nur die Zusammenfassung

Prüfen Sie für jeden Befund:

Schweregrad und Szenario;
betroffener Code;
Empfehlung;
Reaktion der Entwickler;
aktueller Status;
ob der Auditor die Korrektur erneut getestet hat.

Behoben oder Beschlossen is meaningful only when tied to a specific corrected version.

3. Einschränkungen lesen

Berichte können Folgendes ausschließen:

Frontend- und Backend-Systeme;
Schlüsselverwaltung;
wirtschaftliches Modell;
Verträge Dritter;
Deployment-Infrastruktur;
Produktionskonfiguration;
rechtliche und betriebliche Probleme.

Benutzer interagieren mit dem gesamten System und nicht nur mit seinen Solidity-Dateien.

4. Administratives Risiko prüfen

Fragen Sie:

wer Upgrades kontrolliert;
ob Vorgänge pausiert werden können;
ob Gebühren oder verknüpfte Adressen geändert werden können;
ob eine Zeitsperre besteht;
ob eine Multisignatur verwendet wird;
wie Benutzer über Änderungen informiert werden.

Dies sind Governance- und Vertrauensfragen, selbst wenn im Code keine Schwachstelle gefunden wurde.

5. Sicherheit auch nach dem Audit prüfen

Zu sinnvollen laufenden Maßnahmen gehören:

Testen jeder Veröffentlichung;
Prüfung bedeutender Upgrades;
ein Bug-Bounty-Programm;
Überwachung von Rollen und Implementierungen;
Verfahren zur Reaktion auf Vorfälle;
Begrenzung der gefährdeten Asset-Menge.

Was eine Prüfung nicht garantiert

Ein Audit garantiert nicht:

das Fehlen sämtlicher Fehler;
Sicherheit von Code, der nach der Prüfung geändert wurde;
Sicherheit von Website, Wallet, DNS oder Servern;
Sicherheit privilegierter Schlüssel;
Korrektheit externer Token, Orakel und Bridges;
Widerstandsfähigkeit gegen jeden wirtschaftlichen Angriff;
Integrität eines Teams;
Rechtskonformität;
Token-Liquidität;
Rückführung von Mitteln;
feste oder sonstige Renditen.

Fragen, die ein vorsichtiger Benutzer stellen sollte

Is an auditor’s logo enough?
No. Find the report from the auditor’s own source and check its scope, commit, date, and findings.

If every finding was fixed, is the contract safe?
It means the listed findings were addressed in a stated version. Unknown issues and out-of-scope risks remain.

Are several audits automatically better?
The count alone says little. Coverage, quality, independence, recency, and version matching matter more.

Does an audit still apply after a proxy upgrade?
Only if the new implementation and configuration are covered by the reviewed version.

Checkliste für Berichte

Der Bericht ist beim Auditor verfügbar.
Repository und Commit-Hash sind angegeben.
Kritische Verträge und Abhängigkeiten sind Teil des Prüfungsumfangs.
Die geprüfte Version entspricht dem aktiven Deployment.
Proxy, Implementierung und Administrator sind abgedeckt.
Statusermittlung und erneute Prüfung sind dokumentiert.
Annahmen und Ausschlüsse wurden gelesen.
Risiken außerhalb des Codes wurden separat bewertet.

Quellen und weiterführende Literatur

Ethereum.org — Smart-Contract-Sicherheit
Ethereum.org — Smart Contracts testen
Ethereum.org — Formale Verifizierung von Smart Contracts
Solidity Documentation — Sicherheitsaspekte
OpenZeppelin Docs — Proxy-Upgrade-Muster