Ein Smart-Contract-Audit ist ein strukturierter Versuch, Schwachstellen, Missbrauchspotenzial oder unerwartete Manipulationen eines Vertrags aufzudecken. Er unterscheidet sich von der Ausführung eines Scanners, dem Ablesen eines Audit-Badges oder der Bestätigung der Quellcodeverifizierung. Nutzen Sie den unten beschriebenen Workflow, um einen bereitgestellten EVM-Contract oder eine Codebasis zu überprüfen, bevor Sie ihm größere Gelder anvertrauen.
Wichtig: Dies ist ein praktischer Bewertungsrahmen, keine Garantie für die Sicherheit eines Projekts und keine Anlageberatung. Ein Produktionsprotokoll von erheblichem Wert sollte von erfahrenen Sicherheitsexperten unabhängig geprüft werden. Die in diesem Leitfaden verwendeten Benutzeroberflächenabbildungen dienen lediglich der Veranschaulichung und sollten nicht als Beweis für ein bestimmtes Projekt oder eine bestimmte Implementierung herangezogen werden.
| Schritt | Hauptfrage | Nützliche Belege |
|---|---|---|
| 1. Geltungsbereich | Überprüfe ich genau den Vertrag, den die Nutzer anrufen? | Adresse, Kette, Bytecode, Proxy und Implementierung |
| 2. Zugangspunkte | Was kann jeder Anrufer tun? | Öffentliche/externe Funktionen, Zustandsänderungen, Aufrufdiagramm |
| 3. Automatisierung | Welche offensichtlichen Muster verdienen Beachtung? | Compiler-Ausgabe, Slither-Ergebnisse, Detektor-Triage |
| 4. Manuelle Sicherheit | Kann eine Anrufsequenz Annahmen verletzen? | Externe Anrufe, Wiedereintritt, Rückrufe, Fehlerbehandlung |
| 5. Logik | Bleibt die Buchführung auch in Grenzfällen korrekt? | Arithmetik, Runden, Gebühren, Grenzwerte, Zustandsübergänge |
| 6. Privilegien | Wer kann das System verändern oder stoppen? | Rollen, Eigentümer, Administratorschlüssel, Proxy, Initialisierer |
| 7. Testen | Gilt das Verhalten auch bei unerwarteten Eingaben und Sequenzen? | Unit-, Fuzz-, Invarianten- und Fork-Tests |
| 8. Berichterstattung | Kann eine andere Person das Ergebnis reproduzieren und erneut testen? | Feststellung, Auswirkungen, Beweise, Behebung und erneuter Test des Status |
Beginnen Sie mit der exakten Blockchain und Adresse. Notieren Sie die Bereitstellungsadresse, den Transaktions-Hash, die Blocknummer, die Compilerversion, die Optimierereinstellungen, die Konstruktorargumente und den Commit oder das Release, das laut Team bereitgestellt wurde. Ein Projekt kann mehrere Adressen für eine Token-, Router-, Vault-, Proxy-, Implementierungs-, Oracle- oder Testbereitstellung haben. Die Überprüfung einer falschen Adresse ist nutzlos.
Prüfen Sie, ob der verifizierte Quellcode des Explorers den bereitgestellten Bytecode reproduziert. Die Verifizierung ist nützlich, da sie die Untersuchung von Quellcode und ABI ermöglicht, stellt aber lediglich eine Identitätsprüfung dar: Sie beweist nicht die Sicherheit der Geschäftslogik. Ist der Vertrag aktualisierbar, ermitteln Sie sowohl den Proxy als auch dessen aktuelle Implementierung. Lesen Sie die Implementierungsadresse aus der Dokumentation des Proxy-Mechanismus oder den Explorer-Informationen und bestätigen Sie anschließend, dass es sich um die zu überprüfende Implementierung handelt. Der offizielle Foundry-Verifizierungsleitfaden von Etherscan dokumentiert die Verifizierung für neue und bestehende Verträge.
Definieren Sie außerdem die Abgrenzung. Berücksichtigen Sie importierte Bibliotheken, geerbte Verträge, verknüpfte Bibliotheken, bereitgestellte Hilfsverträge, Oracle-Adapter, von Benutzern erhaltene Token und privilegierte Off-Chain-Komponenten. Dokumentieren Sie, was nicht zum Geltungsbereich gehört und warum. Dadurch wird verhindert, dass eine eng gefasste Überprüfung fälschlicherweise als Überprüfung des gesamten Systems interpretiert wird.
Listen Sie alle öffentlichen und externen Funktionen auf, einschließlich geerbter Funktionen und Fallback- oder Empfangshandlern. Geben Sie für jede Funktion an, ob sie Folgendes kann:
Anschließend werden die Vermögenswerte und Vertrauensgrenzen abgebildet. Der Ablauf einer Einzahlung vom Benutzer über die Preis- und Anteilsberechnung bis hin zur Auszahlung wird verfolgt. Jede vom Aufrufer angegebene und jede aus dem Speicher geladene Adresse wird identifiziert. Es wird geprüft, welche Werte als vertrauenswürdig gelten: ein Orakel, ein Token, eine Brückennachricht, ein Verwalter, ein Rückrufempfänger oder ein Administrator. Die wichtigsten Prüfziele sind Funktionen, die benutzergesteuerte Eingaben, privilegierte Zustände, Arithmetik und einen externen Aufruf kombinieren.
Reproduzieren Sie den Build des Projekts mit der angegebenen Solidity-Version, den Abhängigkeitsversionen, der Optimiererkonfiguration und den Zielkettenannahmen. Behandeln Sie Compilerwarnungen als Prüfpunkte und nicht als harmlose Meldungen. Die Sicherheitsrichtlinien von Solidity empfehlen ausdrücklich, Warnungen ernst zu nehmen, Verträge verständlich zu gestalten und bekannte Compilerprobleme zu überprüfen. Konsultieren Sie die offizielle Liste bekannter Solidity-Compilerfehler, wenn die Compilerversion oder betroffene Codemuster dies erfordern.
Bei Hardhat-, Foundry- oder ähnlichen Projekten führen Sie Slither im Projektverzeichnis aus. Die offizielle Dokumentation beschreibt das Tool als statischen Analysator für Solidity und Vyper und gibt den üblichen Befehl an:
slither .Speichern Sie die Ausgabe und priorisieren Sie jedes Ergebnis nach Auswirkung und Zuverlässigkeit. Untersuchen Sie insbesondere Ergebnisse zu willkürlichen Token-Sendungen, ungeschützten Upgrades, Reentrancy, ungeprüften Rückgabewerten, gefährlichen Delegatecalls, tx.origin, schwacher Zufälligkeit und fehlerhaften Schnittstellen. Ein Detektor kann ein falsch positives Ergebnis liefern, einen projektspezifischen wirtschaftlichen Fehler übersehen oder Code markieren, der an anderer Stelle absichtlich eingeschränkt ist. Die statische Analyse schränkt die Suche ein, ersetzt aber nicht die manuelle Überprüfung. Das Slither-Repository und die Dokumentation enthalten außerdem Ausdrucke für Einstiegspunkte, Autorisierungen, Aufrufdiagramme und Vertragszusammenfassungen, die die Überprüfung strukturieren.
Bei jedem externen Aufruf sollten der Zustand vor, während und nach dem Aufruf protokolliert werden. Der Aufgerufene kann ein bösartiger Smart Contract, ein Token mit Hooks, ein Callback-Empfänger oder ein anderes Protokoll sein, das eine gemeinsame Abhängigkeit ändert. Die Solidity-Dokumentation erklärt, dass eine Interaktion mit einem anderen Smart Contract die Kontrolle an diesen übertragen kann und empfiehlt das Checks-Effects-Interactions-Muster: Zuerst validieren, dann den Zustand des eigenen Smart Contracts aktualisieren und zuletzt extern interagieren.
Beschränken Sie die Suche nicht auf offensichtliche Ether-Transfers. Prüfen Sie ERC-777-Hooks, ERC-1155-Callbacks, Flash-Loan-Callbacks, beliebige Router, Oracle-Aufrufe und Aufrufe über geerbte Bibliotheken. Überprüfen Sie die funktions- und vertragsübergreifende Wiedereintrittsfähigkeit: Ein Callback kann eine andere Funktion aufrufen, die einen Zwischenzustand liest. Stellen Sie sicher, dass jeder Low-Level-Aufruf sein Erfolgsergebnis prüft und den Rückgabewert korrekt verarbeitet. Prüfen Sie, ob ein fehlgeschlagener Empfänger Auszahlungen dauerhaft blockieren oder eine Endlosschleife verursachen kann.
Dokumentieren Sie für jedes plausible Problem eine konkrete Angriffssequenz. Beispiel: Der Angreifer tätigt eine Einzahlung, initiiert eine Auszahlung, erhält eine Rückruf-Nachricht, initiiert eine zweite Auszahlung und lässt erst dann den ersten Aufruf abschließen. Falls die Sequenz aufgrund einer bestimmten Invariante oder Schutzbedingung nicht funktioniert, notieren Sie den Grund. Dadurch wird die Schlussfolgerung nachvollziehbar und nicht spekulativ.
Prüfen Sie die Bedeutung jeder Einheit und Umrechnung: Wei versus Ether, Token-Dezimalzahlen, Basispunkte, Anteile versus Vermögenswerte, vorzeichenbehaftete Werte und Zeiteinheiten. Beachten Sie die Rundungsrichtung. Eine Division, die zugunsten eines Einzahlers, Kreditnehmers, Liquidators oder Gebührenempfängers gerundet wird, kann bei wiederholter Anwendung zu Wertverlusten führen. Überprüfen Sie die Multiplikation vor der Division, Mindest- und Höchstbeträge, Gebührenobergrenzen, veraltete Preise, Nullangebot, Nullsaldo sowie den ersten Einzahler bzw. letzten Abnehmer.
Solidity 0.8 und höher erkennen normalerweise arithmetische Über- und Unterläufe, aber Code innerhalb eines uncheckedBlocks kann dieses Verhalten gezielt ändern. Geprüfte Arithmetik kann außerdem dazu führen, dass ein Protokoll rückgängig gemacht oder unbrauchbar wird, wenn die Grenzwerte nicht korrekt definiert sind. Testen Sie beide möglichen Ergebnisse: Diebstahl oder fehlerhafte Abrechnung sowie einen Denial-of-Service-Angriff aufgrund eines Werts, der niemals verarbeitet werden kann.
Formulieren Sie Invarianten zunächst in einfacher Sprache, bevor Sie sie in Tests umwandeln. Beispiele hierfür sind: „Die Gesamtanzahl der Anteile entspricht den Vermögenswerten gemäß der angegebenen Rundungsregel“, „Ein Nutzer kann nicht mehr abheben, als ihm zusteht“, „Das gesamte Tokenangebot entspricht der Summe der Guthaben, sofern dieses Modell zutrifft“ und „Eine Gebühr darf ihr konfiguriertes Limit nicht überschreiten“. Vergleichen Sie die Speicherguthaben mit den tatsächlichen Tokenguthaben, da Token direkt an einen Smart Contract gesendet werden können oder sich anders verhalten als in der angenommenen ERC-20-Implementierung vorgesehen.
Erstellen Sie eine Berechtigungsmatrix. Identifizieren Sie für jede administrative Funktion die erforderliche Rolle, den aktuellen Inhaber, den Übertragungsmechanismus, die Verzögerung, die Multisignatur- oder Governance-Kontrolle sowie das Notfallverhalten. Achten Sie besonders auf das Erstellen, Pausieren, Ändern von Gebühren, Ändern von Oracle-Quellen, Sichern von Geldern, Aktualisieren von Code und Ändern von vertrauenswürdigen Token- oder Router-Adressen. Die Zugriffskontrolldokumentation von OpenZeppelin unterscheidet zwischen einfacher Besitzberechtigung und rollenbasierten Berechtigungen und beschreibt das Prinzip der minimalen Berechtigungen als sinnvolle Sicherheitspraxis.
Unterscheiden Sie zwischen „Der Code erlaubt dies einem Administrator“ und „Jeder beliebige Benutzer kann dies tun“. Ersteres kann ein explizites Governance- oder Verwahrungsrisiko darstellen; Letzteres eine Autorisierungsschwachstelle. Stellen Sie sicher, dass die Rollenprüfungen alle sensiblen Pfade abdecken, einschließlich interner Hilfsfunktionen, die über öffentliche Funktionen erreichbar sind. Prüfen Sie, ob ein Standardadministrator sich selbst oder anderen zusätzliche Berechtigungen erteilen kann und ob eine Eigentumsübertragung versehentlich an eine ungültige Adresse gesendet werden kann.
Überprüfen Sie bei Proxys den Initialisierer, die Implementierungsautorisierung, die Aktualisierungsverzögerung, das Speicherlayout und den Rollback- oder Notfallplan. Die Richtlinien von OpenZeppelin zu aktualisierbaren Verträgen erläutern, warum Konstruktoren den Proxy-Speicher nicht initialisieren, warum Initialisierer geschützt werden müssen, warum eine Implementierung nicht uninitialisiert bleiben sollte und warum Änderungen der Speicherreihenfolge oder -typen eine Aktualisierung beeinträchtigen können. Behandeln Sie einen Proxy-Admin-Schlüssel als Teil der Sicherheitsgrenze des Protokolls und nicht als Implementierungsdetail.
Führen Sie Unit-Tests für das erwartete Verhalten durch und ergänzen Sie diese anschließend um Negativtests für nicht autorisierte Aufrufer, Nullwerte, Maximalwerte, abgelaufene Signaturen, veraltete Oracle-Daten, fehlgeschlagene Übertragungen und wiederholte Operationen. Testen Sie die Eingaben durch Fuzzing, anstatt nur einige wenige ausgewählte Zahlen zu prüfen. Integrieren Sie mehrere Akteure und bösartige Empfängerverträge, sofern das Design Rückrufe zulässt.
Verwenden Sie Invariantentests für Eigenschaften, die auch nach vielen zufälligen Aufrufen gültig bleiben müssen. Die Foundry-Dokumentation zu Invariantentests beschreibt zufällige Sequenzen, Fuzzing-Eingaben, Testläufe, Testtiefe, Zielverträge und Zielsender. Konfigurieren Sie die Handler so, dass die Aufrufe aussagekräftig sind. Wenn beispielsweise jede Fuzzing-Einzahlung rückgängig gemacht wird, weil der Testakteur keine Token besitzt, bedeutet ein positives Ergebnis der Invariante möglicherweise lediglich, dass sich kein nützlicher Zustand geändert hat.
Nutzen Sie nach Möglichkeit einen Fork des Zielnetzwerks, um die bereitgestellten Adressen, die aktuelle Konfiguration, das Tokenverhalten und das Proxy-Routing zu testen. Halten Sie Fork-Tests sicher und schreibgeschützt, es sei denn, Sie verwenden einen isolierten lokalen Fork. Minimieren Sie jede fehlgeschlagene Sequenz und sichern Sie das Gegenbeispiel, die Aufruferadressen, den Blockkontext, die Guthaben und die relevanten Speicherwerte. Ein erfolgreicher Test liefert Hinweise auf die getesteten Pfade, beweist aber nicht alle möglichen Pfade.
Pro Problem ist ein Datensatz zu verwenden. Ein praktischer Befund sollte Folgendes enthalten:
Der Schweregrad sollte die realistischen Auswirkungen und die Ausnutzbarkeit widerspiegeln, nicht wie alarmierend ein Codemuster aussieht. Erläutern Sie die zugrunde liegenden Annahmen. Ein Low-Level-Aufruf kann durch eine starke Invariante geschützt sein; eine scheinbar gewöhnliche Parameteränderung kann kritisch sein, wenn sie ein Orakel oder ein Upgrade steuert. Überprüfen Sie nach einer Korrektur die Änderungen, führen Sie den relevanten Test und die gesamte Testsuite erneut aus und prüfen Sie auf Regressionen. Wenn die bereitgestellte Adresse bereits aktualisiert oder geändert wurde, testen Sie die tatsächliche On-Chain-Implementierung und -Konfiguration erneut.
Sie sollten diese Fragen mit Ja beantworten können:
Lautet eine der Antworten „Nein“, kennzeichnen Sie das Audit als unvollständig und geben Sie die fehlenden Nachweise an. Eine transparente Einschränkung ist aussagekräftiger als eine vage Schlussfolgerung wie „sicher“. Die Sicherheit von Smart Contracts ist ein fortlaufender Prozess: Jedes Upgrade, jede Änderung von Abhängigkeiten, jede neue Integration und jede Änderung von Berechtigungen kann einen neuen Prüfpunkt schaffen.
Lernen Sie, wie Sie Kryptowährungen nach Risikotoleranz, Anlagehorizont, Diversifizierung, Verwahrung, Liquidität und Rebalancing allokieren – ohne sich auf eine Einheitsformel zu verlassen.
Lernen Sie Schritt für Schritt, wie Sie den Smart Contract eines Kryptoprojekts prüfen – von der Überprüfung der Bereitstellung und der Zuordnung von Berechtigungen bis hin zum Testen von Logik, Upgrades und Fehlerbehebungen.
Erstellen Sie ein langfristiges Krypto-Portfolio mit einem risikoorientierten Ansatz für Allokation, Asset-Auswahl, Verwahrung, Kaufdisziplin, Rebalancing, Dokumentation und Betrugsprävention.
Lernen Sie, wie Sie On-Chain-Daten lesen, Whale-Wallets verfolgen, Smart-Money-Labels bewerten und überprüfbare Blockchain-Fakten von Schlussfolgerungen trennen, bevor Sie auf Wallet-Aktivitäten reagieren.
Erfahren Sie, warum Krypto-Futures-Plattformen die Fehlermeldung „Unzureichende Margin“ anzeigen, wie Sie die Ursache diagnostizieren, das Problem sicher beheben und Margin-Probleme vor Ihrem nächsten Trade vermeiden können.
Erfahren Sie, wie Binance Launchpad und Launchpool funktionieren, wie Sie die Teilnahmeberechtigung prüfen, sicher beitreten, Belohnungen verfolgen und die Grenzen und Risiken verstehen.
Erfahren Sie, was „Slippage-Toleranz überschritten“ auf CEXs und DEXs bedeutet, wie Sie überprüfen können, ob ein Trade fehlgeschlagen ist, und wann Sie aktualisieren, die Positionsgröße reduzieren, eine Limit-Order verwenden oder die Toleranz anpassen sollten.
Lernen Sie, wie Bybit Copy Trading funktioniert, wie Sie Master Trader bewerten, Kopierparameter festlegen, Risiken managen und kopierte USDT-Perpetual-Trades überwachen.
Erfahren Sie, wie Tokenangebot, Nachfrage, Entsperrungen, Emissionen, Verbrennungen und Nutzen den Preis einer Kryptowährung beeinflussen können – und was die Tokenomics nicht vorhersagen kann.
Lernen Sie, wie Sie das Kryptovolumen mit seinem Basiswert vergleichen, Preisausbrüche bestätigen, nachlassende Dynamik erkennen und vermeiden, einen manipulierten Kursanstieg mit Stärke zu verwechseln.
