Sicherheit von Smart Contracts: Audits, häufige Schwachstellen, Upgrade-Möglichkeiten und Time Locks.

Technischer Leitfaden. Aktualisiert am 15. Februar 2026.

Smart Contracts haben zwischen 2020 und 2025 mehr als 5 Milliarden US-Dollar an Nutzern verloren. Nicht, weil die Technologie von Natur aus unsicher ist, sondern weil es schwierig ist, korrekten Code zu schreiben, der den Wert verarbeitet, und die Folgen von Fehlern irreversibel sind. Wenn Sie verstehen, wie wichtige Fehler funktionieren, was ein Audit abdeckt und wie ein Vertrag vor der Interaktion überprüft wird, können Sie das Risiko auf praktische Weise reduzieren.

Die häufigsten Fehler in Smart Contracts

Wiedereintritt: die Schwachstelle, die das DAO betraf

Wiedereintritt ist die bekannteste Fehlerklasse in der Geschichte intelligenter Verträge. Der Mechanismus: Ein Vertrag A ruft einen Vertrag B auf, um ETH zu übertragen; Vertrag B ruft in seiner Empfangsfunktion A auf, bevor A seinen internen Status aktualisiert hat. Das Ergebnis ist, dass A getäuscht wird und glaubt, dass das Guthaben des Angreifers immer noch hoch ist und mehrmals in derselben Transaktion aufgebraucht werden kann.

Der DAO-Hack von 2016 nutzte genau das aus: gestohlene ETH im Wert von 60 Millionen US-Dollar. Die Standardlösung ist das Muster „Checks-Effects-Interactions“: Aktualisieren Sie immer den internen Status (Effekte), bevor Sie mit externen Verträgen (Interaktionen) interagieren. ReentrancyGuard von OpenZeppelin ist heute das Standard-Verteidigungstool.

Oracle-Preismanipulation

Viele DeFi-Protokolle lesen den Preis eines Vermögenswerts aus einem Spotpreis in der Kette (z. B. einem AMM-Pool). Ein Angreifer mit ausreichend Kapital – oft über Schnellkredite – kann diesen Preis vorübergehend manipulieren und ihn nutzen, um Positionen künstlich zu liquidieren oder Wert aus Kreditprotokollen zu extrahieren. Die Verteidigung besteht darin, TWAP-Preise (Time-Weighted Average Price) anstelle von Spotpreisen zu verwenden: Die Manipulation des Durchschnitts über die Zeit ist viel teurer. Chainlink und andere Off-Chain-Orakel lösen das Problem anders, führen aber eine externe Abhängigkeit ein.

Blitzkredit-Angriff

Mit Flash-Darlehen können Sie einen beliebigen Betrag ohne Sicherheit leihen, sofern dieser in derselben Transaktion zurückgezahlt wird. Sie sind nicht grundsätzlich gefährlich – sie sind ein nützliches Instrument für Arbitrage und Liquidationen. Sie werden zu einem Angriffsvektor, wenn ein Protokoll nicht dafür ausgelegt ist, große Vorgänge in einem einzigen Block abzuwickeln. Beanstalk (2022, 182 Millionen US-Dollar), Cream Finance (2021, 130 Millionen US-Dollar) und Dutzende anderer Protokolle wurden mit Schnellkrediten überschwemmt, die die Schwachstellen in der Vertragsgestaltung verstärkten.

Ganzzahliger Überlauf und Unterlauf

Vor Solidity 0.8.x konnten arithmetische Operationen die Grenzen des Integer-Typs ohne Zurücksetzen überwinden. Ein Zähler, der auf 100 gehen sollte, könnte bei richtiger Manipulation auf 0 „enden“. Seit Solidity 0.8.x wird das Standardverhalten bei Überlauf wiederhergestellt, ältere Verträge (oder Verträge, die mit alten Versionen kompiliert wurden) bleiben jedoch anfällig. SafeMath von OpenZeppelin war die Lösung vor 0.8.x.

So funktioniert ein Sicherheitsaudit

Ein Smart Contract Audit ist eine systematische Überprüfung des Codes durch Sicherheitsexperten. Es ist keine Garantie dafür, dass es keine Fehler gibt – es ist eine deutliche Verringerung der Wahrscheinlichkeit häufiger, bekannter Fehler.

Was ein Audit abdeckt

Eine gute Prüfung umfasst: Geschäftslogik (Tut der Code, was im Whitepaper steht?), bekannte Schwachstellen (Wiedereintritt, Überlauf, Oracle-Manipulation, unbefugter Zugriff), externe Abhängigkeiten (Oracle, als Sicherheit verwendete Token, sogenannte Verträge) und Zentralisierung (wer kann den Vertrag pausieren, wer kann ihn aktualisieren, durch welchen Mechanismus).

Was ein Audit nicht abdeckt: Marktrisiko, die Qualität des Teams, die Nachhaltigkeit des Geschäftsmodells, zum Zeitpunkt des Audits unbekannte Zero-Day-Schwachstellen. Eine Prüfung des alten Codes deckt keine späteren Änderungen ab, es sei denn, es erfolgt eine erneute Prüfung.

So finden und lesen Sie Audits

Öffentliche Prüfungen sind auf dem GitHub des Projekts, in seinen Dokumenten oder auf Plattformen wie Solodit.xyz verfügbar, die sie zusammenfassen. Achten Sie beim Lesen eines Audits auf Folgendes: Wie viele „kritische“ und „schwere“ Probleme wurden gefunden? Wurden sie gelöst? Bestätigt der Post-Fix-Bericht die Lösung? Ein Bericht, der nur „gering“ und „informativ“ feststellt, kann ein Zeichen dafür sein, dass die Prüfung nicht gründlich war oder dass der Code wirklich sauber ist – Sie müssen den Kontext kennen, um zu verstehen, was das ist.

Im Jahr 2026 anerkannte Auditoren: Trail of Bits, Spearbit, OpenZeppelin, Halborn, Code4rena (Wettbewerbsmodell), Cantina. Eine Prüfung durch einen unbekannten, nicht überprüfbaren Prüfer ist als Sicherheitssignal nahezu wertlos.

Aktualisierbarkeit: Proxy-Muster und Risiken

Die meisten großen DeFi-Verträge sind aktualisierbar: Der Code kann nach der Bereitstellung geändert werden. Dies scheint der Prämisse der „Unveränderlichkeit“ der Blockchain zu widersprechen, ist aber eine praktische Notwendigkeit, um Fehler zu beheben oder Funktionen hinzuzufügen.

So funktioniert das Proxy-Muster

Der Standardmechanismus ist das Proxy-Muster: Benutzer interagieren mit einem Proxy-Vertrag, der die Ausführung an einen Implementierungsvertrag delegiert. Bei einem Upgrade wird der Implementierungsvertrag ersetzt. Der Speicher bleibt im Proxy, der Code ändert sich in der Implementierung.

Das Hauptrisiko besteht darin, dass ein schlecht konzipiertes Upgrade zu einer „Speicherkollision“ führen kann: Wenn die neue Implementierung Variablen an anderen Speicherorten als die vorherige verwendet, kann es zu einer Beschädigung vorhandener Daten kommen. Das UUPS-Muster (Universal Upgradeable Proxy Standard) und der Transparent Proxy von OpenZeppelin werden am häufigsten verwendet und geprüft.

Wer kann upgraden?

Die entscheidende Frage ist nicht technischer Natur, sondern eine der Governance: Wer besitzt die Schlüssel zur Autorisierung eines Upgrades? Wenn es sich um ein Multisig mit 3 anonymen Personen handelt, kann der Vertrag durch die Kompromittierung von 2 Schlüsseln böswillig geändert werden. Wenn es sich um eine DAO-Governance mit 48-Stunden-Zeitsperre handelt, haben Sie zumindest Zeit zum Beenden, bevor eine böswillige Änderung wirksam wird.

Timelock: Der Sicherheitsmechanismus für die Governance

Eine Zeitsperre ist ein Vertrag, der eine Verzögerung zwischen dem Vorschlag einer Änderung und ihrer Ausführung vorsieht. Dies soll den Benutzern Zeit geben, zu prüfen, was passieren wird, und den Vorgang zu beenden, wenn sie nicht zustimmen.

Marktstandard: 24–48 Stunden für kleinere Protokolle, 72 Stunden oder mehr für Protokolle mit hohem TVL. Aave v3 verwendet eine Zeitsperre von 24 Stunden für kleinere Parameter und 7 Tage für kritische Änderungen. Compound benötigt 48 Stunden. Ein Protokoll ohne Zeitsperren – bei dem Upgrades sofort durchgeführt werden können – ist für Benutzer strukturell unsicher.

Überprüfen Sie den Timelock-Vertrag in der Kette: Suchen Sie im Explorer nach dem Timelock-Vertrag und überprüfen Sie den Wert von minDelay und welche Adresse hat die PROPOSER-Rolle? Wenn minDelay 0 ist oder der Executor ein einzelnes EOA (Externally Owned Account) ist, ist die Zeitsperre praktisch nutzlos.

So überprüfen Sie einen Vertrag, bevor Sie interagieren

Etherscan: Verifiziert vs. nicht verifiziert

Bei Etherscan wird ein Vertrag „verifiziert“, wenn der Quellcode veröffentlicht wurde und mit dem bereitgestellten Bytecode übereinstimmt. Das bedeutet nicht, dass der Code sicher ist – es bedeutet, dass Sie ihn lesen können. Ein nicht verifizierter Vertrag lässt Sie nicht wissen, was er bewirkt: Vermeiden Sie ihn für alle relevanten Interaktionen.

Überprüfen Sie außerdem das Bereitstellungsdatum und die Anzahl der Transaktionen. Ein Vertrag, der gestern mit null Transaktionen implementiert wurde, ist ein anderes Signal als ein Vertrag, der vor zwei Jahren mit Millionen von Interaktionen implementiert wurde.

Zulage: das Risiko, das sich stillschweigend ansammelt

Jedes Mal, wenn Sie einen Vertrag zur Ausgabe Ihrer Token genehmigen (über die ERC-20-Genehmigung), erteilen Sie eine dauerhafte Unterschrift, bis Sie sie widerrufen. Im Laufe der Zeit sammeln Sie Dutzende Zulagen aus Verträgen an, die Sie möglicherweise nicht mehr nutzen. Wenn einer dieser Verträge kompromittiert wird, können Ihnen genehmigte Token entzogen werden, selbst wenn Sie nicht mehr mit ihm interagieren.

Überprüfen und widerrufen Sie Berechtigungen regelmäßig mit Tools wie Revoke.cash oder Etherscan Token Approvals. Stellen Sie den Freibetrag auf das erforderliche Minimum ein, statt auf „Maximum genehmigen“ – viele Wallets und dApps bieten diese Option an. Die Gaskosten eines Widerrufs sind im Vergleich zum Risiko, das er beseitigt, minimal.

Sicherheitscheckliste vor der Interaktion mit einem neuen Vertrag

• Ist der Vertrag auf Etherscan/Basescan/usw. verifiziert?
• Gibt es ein aktuelles Audit (nicht älter als 12 Monate für eine aktive Codebasis) durch einen anerkannten Auditor?
• Wer kann den Vertrag upgraden und mit welcher Zeitsperre?
• Welches Orakel verwendet er für die Preisgestaltung – Spotpreis oder TWAP?
• Wie hoch ist der Zuschuss, den ich gebe – ist er begrenzt oder unbegrenzt?
• Gibt es ein aktives Bug-Bounty für Immunefi oder ähnliches?
• Wie war der Sicherheitsverlauf des Protokolls in den letzten 12 Monaten?

Zugriffskontrolle: Eigentümer, Rollen und Berechtigungen

Die meisten Governance-Exploits – keine reinen Codefehler, sondern absichtliche Manipulationen – nutzen Fehlkonfigurationen der Zugriffskontrolle aus. Wer welche Funktion auf einem Vertrag aufrufen kann, ist ebenso wichtig wie die Korrektheit der internen Logik.

Das Ownable-Muster

Der einfachste Vertrag hat einen „Eigentümer“, der Verwaltungsfunktionen wahrnehmen kann. OpenZeppelin Ownable ist das Standardmuster: eine Besitzervariable, ein onlyOwner-Modifikator und Eigentumsübertragungsfunktionen. Das Hauptrisiko besteht darin, dass der Angreifer die vollständige Kontrolle hat, wenn der private Schlüssel des Eigentümers kompromittiert wird. Für Verträge mit hohem TVL reicht ein EOA als Eigentümer nicht aus – es ist mindestens ein Multisig erforderlich.

Rollenbasierte Zugriffskontrolle (RBAC)

AccessControl von OpenZeppelin führt granulare Rollen ein: ADMIN_ROLE, PAUSER_ROLE, UPGRADER_ROLE usw. Jede Rolle kann verschiedenen Adressen zugewiesen werden – einem Multisig für Upgrades, einer separaten Adresse für Notpausen und einer dritten für Betriebsparameter. Granularität reduziert das Risiko: Die Kompromittierung der PAUSER-Rolle gewährt keinen Zugriff auf Vertrags-Upgrades.

So überprüfen Sie: Suchen Sie auf Etherscan im Abschnitt „Vertrag lesen“ nach den Funktionen hasRole und getRoleAdmin und lesen Sie, welche Adressen welche Rollen haben. Überprüfen Sie dann diese Adressen: Handelt es sich um EOA oder Multisig? Wenn es sich um Multisig handelt, wie viele Unterzeichner und mit welchem ​​Schwellenwert?

So lesen und interpretieren Sie einen Auditbericht

Ein Auditbericht ist ein technisches Dokument, das die gefundenen Schwachstellen, deren Schweregrad und den Status der Lösung beschreibt. Wenn Sie verstehen, wie man es liest, können Sie es als Bewertungsinstrument verwenden und nicht als einfaches Zertifikat, das Sie im Marketing anzeigen können.

Struktur eines typischen Berichts

Die meisten Audit-Berichte sind gegliedert in: Zusammenfassung, Umfang (welcher Code überprüft wurde, bei welchem ​​Commit), Feststellungen (Schwachstellen) und technischer Anhang. Der wichtigste Abschnitt für einen Nicht-Techniker sind die Befunde mit ihrem Lösungsstatus.

Schweregrade

Ein Bericht mit kritischen oder schwerwiegenden Problemen, die vor der Bereitstellung nicht gelöst wurden, ist ein ernstes Warnsignal. Ein Bericht mit nur „Niedrig“ und „Informativ“ kann auf eine gut geschriebene Codebasis hinweisen – oder auf eine Prüfung, die nicht gründlich genug ist. Der Kontext und der Ruf des Prüfers sind der Schlüssel zur korrekten Interpretation.

Was tun, wenn das Audit alt ist?

Ein zum Zeitpunkt der Bereitstellung gültiges Audit kann bei einer Vertragsänderung hinfällig werden. Achten Sie immer auf Folgendes: Ist der Bericht veraltet? Gab es seit dem Audit irgendwelche Upgrades oder Änderungen? Wenn ja, gibt es eine erneute Prüfung, die die Änderungen abdeckt? Ein Protokoll, das sich mit Audits von Code im Jahr 2021 rühmt, der seitdem zehnmal geändert wurde, bietet nicht die Garantien, die es zu sein scheint.

Bug-Bounty: Der Sicherheitsmarkt geht weiter

Ein Bug-Bounty-Programm ist ein Programm, das diejenigen belohnt, die Schwachstellen finden und verantwortungsvoll melden, anstatt sie auszunutzen. Bei Immunefi, dem führenden Krypto-Bug-Bounty-Aggregator, reichen die Belohnungen für kritische Schwachstellen von einigen tausend bis zu Millionen Dollar. MakerDAO, Compound, Aave und Uniswap haben alle Bug-Bounties mit maximalen Belohnungen von über 1 Million US-Dollar.

Das Vorhandensein einer aktiven und gut finanzierten Fehlerprämie ist ein positives Zeichen: Es zeigt, dass das Team ein wirtschaftliches Interesse daran hat, Fehler vor Angreifern zu finden, und dass die Gemeinschaft der Sicherheitsforscher einen Anreiz hat, sich den Code anzusehen. Ein Protokoll mit 500 Millionen US-Dollar TVL und ohne Bug-Bountys setzt darauf, dass seine Prüfungen perfekt waren – eine Wette, die in der Vergangenheit eine schlechte Erfolgsbilanz vorzuweisen hat.

Kontinuierliche Überwachung: Das Erstaudit reicht nicht aus

Die Sicherheit eines Protokolls ist nicht statisch. Alle paar Sekunden werden neue Blöcke abgebaut; Neue Transaktionen interagieren auf eine Art und Weise mit Verträgen, die keine Prüfung vollständig vorhersagen könnte. Governance-Updates ändern die Parameter. Kontinuierliche Überwachung ist ein wesentlicher Bestandteil der Sicherheit.

Mit Tools wie Tenderly und Forta können Sie Benachrichtigungen zu bestimmten Ereignissen einrichten: eine ungewöhnlich große Transaktion zu einem von Ihnen genutzten Vertrag, ein Eigentümerwechsel, die Aktivierung einer Notfallfunktion. OpenZeppelin Defender bietet eine umfassendere Suite für Teams, die Verträge in der Produktion verwalten.

Für Benutzer (nicht für Entwicklungsteams) ist die praktische Überwachung einfacher: Folgen Sie den Warnkanälen der von Ihnen verwendeten Protokolle (viele verfügen über Telegram- oder Discord-Bots für Sicherheitswarnungen), richten Sie Etherscan-Warnungen per E-Mail für große Verträge ein und verwenden Sie Sicherheitsaggregatoren wie DeFi Safety oder DefiWatch, die Exploits melden, sobald sie erkannt werden.

Im Falle eines Exploits ist die Reaktionsgeschwindigkeit von entscheidender Bedeutung: Seriöse Protokolle verfügen über Verfahren zur Reaktion auf Vorfälle, die Notpausen (Leistungsschalter) umfassen. Aber wenn Sie als Benutzer innerhalb von 30 Minuten nach einem Exploit eine Warnung erhalten, haben Sie Zeit, auszusteigen, bevor sich die Situation weiter verschlechtert – oft der Unterschied zwischen einer Wiederherstellung von 90 % und 20 % des Werts.

Bug Bounty: der Markt für präventive Sicherheit

Bug-Bounty-Programme stellen einen der wirksamsten Mechanismen zur präventiven Sicherheit von Smart Contracts dar. Plattformen wie Immunefi haben über 100 Millionen US-Dollar an Belohnungen an unabhängige Forscher verteilt, die kritische Schwachstellen identifiziert haben, bevor sie ausgenutzt wurden. Die Kosten für eine Bug-Bounty sind fast immer geringer als die Kosten für einen uneingeschränkten Exploit.

Abschluss

Die Sicherheit intelligenter Verträge ist kein gelöstes Problem, aber ein beherrschbares Problem. Die teuersten Fehler der Geschichte – Wiedereintritt, Oracle-Manipulation, böswillige Upgrades – können mit bekannten Designmustern, Qualitätsprüfungen und transparenten Governance-Mechanismen verhindert werden. Als Benutzer besteht Ihre Aufgabe darin, zu überprüfen, ob diese Elemente vorhanden sind, bevor Sie einem Vertrag Ihr Kapital anvertrauen.

Weiterlesen: Bitcoin-Marktzyklen: Der umfassende Leitfaden für jede Phase des Zyklus. · On-Chain-Analyse: Der Leitfaden zur Analyse des Kryptomarktes