Zum Inhalt springen
Financial Context Wiki

Smart-Contract-Audits richtig lesen

Ein Smart-Contract-Audit ist eine begrenzte Prüfung festgelegter Codes, Builds, Deployments, Annahmen und Eigenschaften; Befunde und Korrekturen müssen mit dem Live-System abgeglichen werden.

Aktualisiert

Nur zu Bildungszwecken; keine Anlage- oder Sicherheitsberatung. Prüfbericht, Tool-Ergebnis, geschlossener Befund oder übereinstimmende Quelldatei sind weder Zertifizierung, Versicherung oder Entschädigung noch Nachweis eines sicheren Live-Deployments.

Direkte Antwort

Ein Audit prüft in einem benannten Zeitraum festgelegte Anforderungen, Quellcode, Build-Eingaben, Deployment-Logik und Sicherheitsannahmen. Komplementäre Methoden finden Fehler, belegen Angriffspfade, bewerten Folgen und prüfen Fixes. Das Ergebnis gilt nur für den dokumentierten Stand und dessen Belege.

Der Stand fixiert Repository, Commit oder Tree-Hash, Submodule, Dependencies, Compiler, Einstellungen, generierten Code, Deployment-Skripte, Chains, Adressen, Proxy, Implementierung oder Beacon, Constructor- oder Initializer-Daten, Libraries, Administratoren, Timelocks sowie Block oder Zeit. Ausnahmen sind ebenso wichtig: Frontend, Keeper, Oracle, Bridge, Governance oder Off-Chain-Signer können außerhalb des Audits das Risiko bestimmen.

Audit braucht Bedrohungsmodell und Spezifikation: Assets, Akteure, privilegierte Rollen, Vertrauensgrenzen, Fähigkeiten, Reihenfolge und Reorgs, Abhängigkeiten, Zustände sowie messbare Safety- und Liveness-Eigenschaften. Invarianten ohne Einheiten, Vorbedingungen, Quantoren und Ausnahmen prüfen womöglich perfekt das Falsche.

Vier Register sind getrennt: Umfang, Build und Deployment-Identität; Anforderungen, Bedrohungen und Invarianten; Befunde, Belege und Retest; Restrisiko, Akzeptanz und Offenlegung. Kein critical ist kein Zertifikat, resolved nicht zwingend deployed, und ein Beweis gilt nur für kodierte Eigenschaft, Modell und Annahmen.

Funktionsweise

Manuelle Prüfung verfolgt Architektur, Geldfluss, funktionsübergreifenden Zustand und ökonomische Absicht. Statische Analyse findet Muster, erzeugt aber Fehlalarme und übersieht Fehler. Unit-, Integrations-, Fork- und Differentialtests prüfen konkrete Fälle. Stateful Fuzzing und Invariantentests hängen von Handlern, Selektoren, Seeds, Korpus, Läufen, Tiefe und Modell ab.

Symbolische Ausführung und formale Verifikation beweisen ausgewählte Aussagen unter unterstützter Semantik. unknown, Timeout oder nicht unterstütztes Verhalten sind kein Beweis. Selbst bewiesene Eigenschaften können Oracle-Ökonomie, Governance, Konfiguration oder die tatsächlich gewünschte Anforderung auslassen. Menschen verantworten Spezifikation und Deutung; KI-Beobachtungen sind keine eigene Assurance-Methode.

Jeder Befund nennt Artefakt und Deployment, Voraussetzung, Minimalbeleg, Angriffspfad, Erreichbarkeit, Rechte, Kapital, Wiederholbarkeit, Auswirkung, Bewertungsmethode und Empfehlung. Ausnutzbarkeit beziehungsweise Wahrscheinlichkeit und Auswirkung bleiben getrennt. Theoretisches Maximum, Schwachstellenname oder Tool-Label beweisen keinen ausführbaren Verlust.

open, acknowledged, risk accepted, partially fixed, resolved und retested sind keine universellen Standards. Belastbarer Abschluss bindet den Befund an den exakten Fix-Commit und dokumentiert benachbarte Tests sowie Prüfer und Zeitpunkt. Akzeptiertes Risiko bleibt Risiko; begrenzter Retest erweitert den Umfang nicht.

Upgradeable Deployments verlangen Abgleich von Proxy-, Implementierungs- oder Beacon- und Admin-Slots, Initializer/Reinitializer, Implementierungssperre, Storage-Kompatibilität, Upgrade-Rechten, Timelock oder Bypass, Migration und Rollback. Creation- und Runtime-Bytecode werden reproduziert und Libraries, Parameter, Rollen und Zustand je Chain verglichen.

Der Bericht nennt Revision, Auditoren, Daten, Umfang, Methoden, Konfigurationen, Grenzen, Befunde, Belege, Status, Restrisiken und Disclosure. Danach sind Hashes, Rollen, Parameter, Dependencies und Vorfälle zu überwachen. Jede wesentliche Änderung erzeugt ein neues Delta; ein altes Badge folgt künftigem Code nicht.

Vorgehen:

  1. Manifest mit Repository, Commit, Dependencies, Compiler, Einstellungen, generiertem und Deployment-Code, Chains, Adressen, Proxy-Stack, Parametern, Block, Revision und Grenzen fixieren.
  2. Assets, Akteure, Rollen, Vertrauensgrenzen, Fähigkeiten, Lebenszyklus, Reihenfolge, Liveness, Abhängigkeiten und messbare Invarianten definieren.
  3. Build reproduzieren; Architektur, Storage, Daten, Mittel und Kontrolle abbilden; Quelle, Artefakte, Libraries, Bytecode, Initializer, Rollen und Deployment abgleichen.
  4. Manuelle, statische, Unit-, Integrations-, Fork-, Differential-, Fuzz-, Invarianten-, symbolische oder formale Methoden mit Versionen, Konfiguration, Seeds, Korpus, Coverage, Timeouts und Unbekannten ausführen.
  5. Artefakt, Voraussetzung, Beleg, Ausnutzbarkeit, Auswirkung, Schweregrad, Exposure, Empfehlung und vertrauliche Evidenz dokumentieren; Tool-Label ersetzt kein Urteil.
  6. Fix-Commit einfrieren und Befund, Nachbarpfade und Invarianten retesten; Storage, Initialisierung, Migration, Rollback, Build und Belege validieren, dann Status vergeben.
  7. Umfang, Methoden, Grenzen und Risiken veröffentlichen; Artefakte je Live-Chain abgleichen und Monitoring, Disclosure, Incident Response und Bug Bounty aktuell halten.

Beispiele

  • Vault-Inflation braucht vollständiges Register. Angreifer zahlt 1 asset, erhält 1 share, spendet 1,000,000 assets; Stand 1,000,001 assets und 1 share. Opfer zahlt 500,000 assets; unsichere Abrundung ergibt floor(500,000 * 1 / 1,000,001) = 0 shares. Bei Annahme hält der Vault 1,500,001 assets; der Angreifer erhält 500,000 assets mehr zurück als seinen Beitrag von 1,000,001-asset. Revert bei null Shares verhindert genau diesen Pfad.
  • Dateiabdeckung ist keine Deployment-Abdeckung. Manifest: 24 source units, 4 deployment scripts, 3 keeper services, also 31 items. Enthalten: 20 source units und 2 scripts; 22 / 31 = 70.96774194%, ausgeschlossen 9 items. Bei ausgeschlossener Implementierung ist Live-Abdeckung 0% trotz 70.96774194%.
  • Fuzzing beweist keine Fehlerfreiheit. Lauf: 2,000 sequences * 64 calls = 128,000 calls; Fehler in 3 sequences, also 3 / 2,000 = 0.15%. Nach Fix: 10,000 sequences * 64 calls = 640,000 calls, null Fehler. Unter Lehrannahmen ist die ungefähre 95%-Obergrenze 3 / 10,000 = 0.03% je Sequenz, kein Beweis.
  • Befundschluss und Identität sind unabhängig. 12 findings: 2 critical, 3 high, 4 medium, 3 low. Geschlossen 2 + 2 + 3 + 2 = 9, somit 9 / 12 = 75%; high, medium und low bleiben. Auditiert H1, live H2: Verifikation scheitert. Exaktes H1 plus Slot, Initializer und Rollen beweist Identität nur am Prüfblock.

Risiken

  • Repository, Commit, Submodule oder generierte Quelle sind unklar.
  • Compiler, Optimizer, Libraries oder Dependencies sind nicht fixiert.
  • Skripte, Constructor, Initializer oder CREATE2-Salt fehlen.
  • Falsche Chain, Adresse, Proxy, Beacon oder Implementierung wird geprüft.
  • Quelle, Artefakt und Bytecode stimmen nicht überein.
  • Bedrohungsmodell lässt Akteur, Recht, Asset oder Grenze aus.
  • Spezifikation oder Invariante hat falsche Einheiten oder Ausnahmen.
  • Admin-, Guardian-, Timelock-, Pause-, Upgrade- oder Migrationspfade fehlen.
  • Oracle-, Token-, Bridge-, Keeper-, Governance- oder Chain-Annahmen versagen.
  • Statische Analyse erzeugt untriagierten Fehlalarm.
  • Review, Test oder Fuzzing übersieht einen Pfad.
  • Harness, Selektor, Seed, Korpus, Tiefe oder Modell sind verzerrt.
  • Timeout, nicht unterstützte Semantik oder unknown gilt fälschlich als Beweis.
  • Korrekter Beweis formalisiert falsche Anforderung oder unvollständiges System.
  • Schweregrad folgt Namen statt Ausnutzbarkeit und Auswirkung.
  • Theoretischer Wert wird mit erreichbarem Verlust oder Gewinn verwechselt.
  • Fix erzeugt Regression oder bricht ökonomische Invariante.
  • Storage, Initializer, Upgrade oder Migration beschädigen Zustand.
  • Akzeptierter, offener oder teilweiser Befund wird vom Badge verdeckt.
  • Bericht gilt fälschlich als Versicherung, Zertifikat oder Dauerabdeckung.

Häufige Irrtümer

  • „Ohne critical ist der Vertrag sicher.“ Das beschreibt nur Befunde im begrenzten Umfang.
  • „Hohe Coverage oder null Fuzz-Fehler beweisen Fehlerfreiheit.“ Sie messen ausgewählten Code und generierte Pfade.
  • „Formale Verifikation beweist das gesamte Protokoll.“ Sie beweist Modelleigenschaften unter Annahmen.
  • „Resolved heißt, jedes Deployment ist repariert.“ Nötig sind Retest und Abgleich von Build, Bytecode, Proxy, Parametern und Rollen.
  • „Renommierte Auditoren garantieren Entschädigung oder Upgrades.“ Haftung folgt dem Vertrag; spätere Änderungen liegen außerhalb.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...