Warum bedeutet „auditiert" nicht absolut sicher?

Kurz erklärt: Ein Smart-Contract-Audit ist eine Sicherheitsprüfung, die von einer Fachorganisation zu einem bestimmten Zeitpunkt an einem eingereichten Code durchgeführt wird. Es reduziert das Risiko bekannter Schwachstellen, kann aber Codeänderungen nach dem Audit, neue Angriffsmethoden und systemische Risiken auf der Ebene des Wirtschaftsmodells nicht abdecken.

Warum das wichtig ist

In der DeFi-Community wird „auditiert" oft als Standardstempel für Sicherheit verwendet. Dennoch sind bei auditierten Protokollen schwerwiegende Sicherheitsvorfälle aufgetreten, die zu Verlusten von Dutzenden Millionen oder sogar Hunderten von Millionen US-Dollar geführt haben. Wer die Grenzen von Audits nicht versteht, wird durch die drei Wörter „wurde auditiert" leicht in falscher Sicherheit gewiegt und geht Risiken ein, die über sein Verständnis hinausgehen.

Das Verständnis von Wert und Grenzen von Audits ist ein unverzichtbares Grundwissen bei der Bewertung von DeFi-Projekten. Die Sicherheitslernseite von Revoke.cash weist ebenfalls darauf hin, dass Vertragsberechtigungsrisiken durch die Existenz eines Audits nicht verschwinden.

Kernmechanismus: Was kann ein Audit – und was nicht?

Was ein Audit kann

• Scannen nach bekannten Schwachstellenmustern: Klassische Schwachstellen wie Reentrancy-Angriffe, Integer-Überläufe und fehlende Zugangskontrollen können von erfahrenen Prüfern erkannt werden.
• Überprüfung der Vertragslogik: Prüfer lesen die Vertragslogik und suchen nach Problemen in der Reihenfolge von Funktionsaufrufen, der Berechtigungsgestaltung usw.
• Empfehlungen zur Behebung: Gefundene Schwachstellen werden nach Schweregrad (Critical/High/Medium/Low/Informational) eingestuft und mit Empfehlungen zur Behebung versehen.

Was ein Audit nicht kann

1. Audits decken nur die eingereichte Version ab Ein Audit prüft den „zu einem bestimmten Zeitpunkt eingereichten Code". Wenn Entwickler nach Abschluss des Audits den Vertrag upgraden oder neue Module hinzufügen, gilt der Auditbericht nicht mehr für den geänderten Code. Manche Protokolle iterieren nach der Auditsicherung weiter – jedes Upgrade ist eine neue Risikoöffnung.

2. Neue Angriffsmethoden können nicht vorhergesehen werden Sicherheit ist ein dynamischer Wettkampf. Ein heute unentdeckter Angriffsvektor kann morgen zur gängigen Angriffsmethode werden. Prüfer können nur auf Basis des aktuellen Sicherheitswissens prüfen und zukünftige neue Exploits nicht vorhersehen.

3. Wirtschaftsmodellrisiken werden nicht abgedeckt Flash-Loan-Angriffe, Preismanipulationen durch Orakel und andere wirtschaftliche Angriffe nutzen oft keine Code-Bugs aus, sondern logische Lücken im wirtschaftlichen Design des Protokolls. Diese Risiken erfordern spezialisierte wirtschaftliche Sicherheitsanalysen, keine Standardcode-Prüfung.

4. Auditqualität variiert stark Es gibt viele Prüfungsdienstleister am Markt mit erheblichen Unterschieden in Fähigkeit und Gründlichkeit. Einige minderwertige „Schnellaudits" führen nur oberflächliche Prüfungen durch, die wenig belastbar sind. Den Unterschied zwischen „Tiefenaudit durch eine renommierte Institution" und „minderwertigem Audit durch einen unbekannten Anbieter" zu erkennen ist bei der Recherche unerlässlich.

5. Besonderheiten upgradefähiger Verträge Viele Protokolle verwenden das Proxy-Contract-Muster, das es Entwicklern ermöglicht, die tatsächliche Logik in Zukunft zu ersetzen. Das bedeutet, dass die Vertragslogik, mit der du interagierst, ersetzt werden kann, und die auditierte alte Logik durch neue, nicht-auditierte Logik ersetzt werden kann. Zu überprüfen, ob ein Vertrag upgradefähig ist und wer die Upgrade-Berechtigung kontrolliert, ist ein in der Recherche oft übersehener wichtiger Schritt.

Anwendungsszenarien

Szenario 1: Du entdeckst einen DEX-Aggregator, der behauptet, „von zwei Institutionen auditiert" worden zu sein. Beim Einsehen der Berichte stellst du fest, dass einer der Audits 18 Monate alt ist und das Protokoll seitdem zwei größere Versionsupgrades durchgeführt hat. Du erkennst, dass der alte Bericht für die aktuelle Vertragsversion begrenzte Aussagekraft hat, und beschließt, auf eine neue Prüfrunde zu warten.

Szenario 2: Im Auditbericht eines Protokolls sind 3 High-Schwachstellen vermerkt. Du prüfst die Behebungsnotizen der neuesten Version und stellst fest, dass nur 2 behoben wurden und 1 als „bekanntes Risiko, akzeptiert" markiert ist. Diese Information lässt dich die Risikoeinstufung des Protokolls nach oben korrigieren und die Beteiligungsgröße entsprechend anpassen.

OneKey App – Einstieg

Beim Interagieren mit DeFi-Protokollen über die OneKey App:

• Die integrierte Signaturvorschau hilft dir, vor der Genehmigung zu prüfen, ob die Vertragsadresse mit der offiziellen Adresse übereinstimmt – zum Schutz vor Interaktionen mit Phishing- oder Fälschungsverträgen;
• In Kombination mit der OneKey Hardware-Wallet muss jede Transaktion physisch bestätigt werden – selbst wenn das Frontend manipuliert wird, erkennst du Anomalien auf dem Gerätebildschirm;
• Über Revoke.cash kannst du regelmäßig nicht mehr benötigte Vertragsgenehmigungen prüfen und widerrufen, um langfristige Risiken durch historische Genehmigungen zu reduzieren.

Risiken und Hinweise

• Selbst bei Protokollen, die von Top-Institutionen mehrfach auditiert wurden, können Sicherheitsvorfälle auftreten.
• Auditberichte sind Forschungsreferenzen, keine Sicherheitsgarantien, und stellen keine Anlageempfehlung dar.
• Bei der Teilnahme an DeFi-Protokollen sollte man stets nur Mittel einsetzen, deren vollständigen Verlust man sich leisten kann.
• Die offiziellen Kanäle der Protokolle verfolgen, an denen man teilnimmt, um über Vertragsupdates und Sicherheitsankündigungen informiert zu bleiben.

FAQ

F1: Wie beurteilt man die Qualität eines Auditberichts? Auf Bekanntheit und Erfolgsgeschichte der Prüfinstitution achten, auf die Übereinstimmung zwischen Veröffentlichungsdatum des Berichts und der aktuellen Vertragsversion, auf die Anzahl und den Schweregrad der gefundenen Schwachstellen sowie auf den Behebungsstatus kritischer Lücken. Bekannte Institutionen sind z. B. Trail of Bits, ChainSecurity, OpenZeppelin, Certik – aber selbst renommierte Institutionen können keine Vollständigkeit garantieren.

F2: Kann man an einem Protokoll ohne Auditbericht teilnehmen? Das hängt von der eigenen Risikobereitschaft ab. Kein Auditbericht bedeutet ein höheres unbekanntes Risiko. Wenn man teilnehmen möchte, empfiehlt es sich in der Regel, zu warten, bis das Protokoll ausreichend Praxiserfahrung gesammelt oder ein formelles Audit erhalten hat.

F3: Wo findet man Auditberichte? Normalerweise auf der „Security"- oder „Audit"-Seite der offiziellen Protokoll-Website oder im GitHub-Repository. Manche Prüfinstitutionen veröffentlichen eine Liste ihrer Berichte auf ihren eigenen Websites.

F4: Sind upgradefähige Verträge riskanter als nicht-upgradefähige? Upgradefähige Verträge bieten die Flexibilität, Schwachstellen zu beheben, bringen aber auch das Risiko eines Missbrauchs der Upgrade-Berechtigung mit sich. Entscheidend ist: Wer kontrolliert die Upgrade-Berechtigung, werden Multisig oder Timelocks benötigt, hat die Community Überwachungsmechanismen für Upgrades? Beides – upgradefähige Verträge als gefährlicher oder sicherer einzustufen – wäre zu einseitig.

Jetzt handeln

Besuche vor der Teilnahme an einem DeFi-Protokoll dessen offizielle Website, sieh dir die Auditberichte an und überprüfe Berichtsdatum und aktuelle Vertragsversion. Lerne über Revoke.cash das Management von Vertragsgenehmigungen und lade die OneKey App herunter, um jeder On-Chain-Transaktion eine Ebene physischer Bestätigung hinzuzufügen.