Wie sichern Sie Ihren Smart Contract? (Eine Sicherheitscheckliste)

Code-Audit und formale Verifizierung

1. Beauftragen Sie mehrere unabhängige Sicherheitsfirmen mit der Durchführung manueller Codeüberprüfungen vor der Bereitstellung.

2. Wenden Sie formale Verifizierungstools wie Certora oder MythX an, um die Korrektheit kritischer Invarianten mathematisch zu beweisen.

3. Stellen Sie sicher, dass alle externen Aufrufe mithilfe von Checks-Effects-Interactions-Mustern anhand von Wiedereintrittsvektoren validiert werden.

4. Überprüfen Sie alle importierten Bibliotheken, einschließlich OpenZeppelin-Verträge, auf versionenspezifische Schwachstellen.

5. Pflegen Sie einen unveränderlichen Prüfpfad, der jeden Commit mit dem entsprechenden Verifizierungsbericht und Zeitstempel verknüpft.

Zugriffskontrolle und Berechtigungsverwaltung

1. Implementieren Sie eine rollenbasierte Zugriffskontrolle mithilfe der Ownable- oder AccessControl-Muster aus geprüften Standards.

2. Erzwingen Sie eine strikte Trennung zwischen Verwaltungsfunktionen und benutzerorientierter Logik – keine privilegierten Vorgänge an öffentlichen Einstiegspunkten.

3. Fordern Sie Multi-Signatur-Genehmigungen für sensible Aktionen wie Pausieren, Upgraden oder Abheben von Geldern.

4. Rotieren Sie Admin-Schlüssel regelmäßig und speichern Sie sie mithilfe von Hardware-Sicherheitsmodulen offline – nicht in GitHub-Repositorys oder Klartextdateien.

5. Protokollieren Sie jede Berechtigungsänderung in der Kette mit vollständigem Kontext: Aufrufer, Zeitstempel, Zielrolle und Vorbesitzer.

Gasoptimierung und Laufzeitsicherung

1. Vermeiden Sie unbegrenzte Schleifen, die während der Ausführung zu Ausfällen aufgrund von Gasmangel führen können – verwenden Sie Paginierung oder begrenzte Iterationen.

2. Fügen Sie explizite Gasgrenzwerte für externe Anrufe ein, um DoS über unendliche Fallback-Schleifen zu verhindern.

3. Überprüfen Sie Eingabelängen und -bereiche, bevor Sie Arrays oder Zeichenfolgen verarbeiten, um einen Stapelüberlauf oder stilles Abschneiden zu vermeiden.

4. Verwenden Sie die integrierten Überlaufprüfungen von SafeMath oder Solidity 0.8+ für alle arithmetischen Operationen, die vom Benutzer bereitgestellte Werte beinhalten.

5. Stellen Sie es mit aktivierten Wiederherstellungszeichenfolgen bereit, um das Debuggen zu unterstützen, ohne sensible Logik in Produktionsfehlermeldungen preiszugeben.

Aktualisierbarkeit und Proxy-Muster

1. Bevorzugen Sie transparente Proxys nur dann, wenn die Upgrade-Logik vollständig von der Geschäftslogik entkoppelt bleiben muss.

2. Speichern Sie die Proxy-Administratoradresse in einem separaten, gehärteten Vertrag – nicht im Proxy selbst –, um unbefugte Upgrades zu verhindern.

3. Einfrieren der Upgrade-Fähigkeit nach dem Start des Mainnets, sofern dies nicht durch ein zeitlich begrenztes DAO mit durch Quorum erzwungenen Abstimmungsperioden geregelt wird.

4. Überprüfen Sie die Kompatibilität des Speicherlayouts zwischen Implementierungen mithilfe von Slither oder Crytic-Tools, bevor Sie neue Logik bereitstellen.

5. Erlauben Sie niemals Selbstzerstörung oder Delegatenaufrufe an beliebige Adressen – auch nicht innerhalb von Upgrade-Funktionen –, es sei denn, sie werden ausdrücklich auf die Whitelist gesetzt und protokolliert.

Überwachung, Alarmierung und Reaktion auf Vorfälle

1. Integrieren Sie Echtzeit-Transaktionsverfolgung über Tenderly oder BlockSec, um anomale Zustandsübergänge zu erkennen.

2. Richten Sie On-Chain-Ereignisbeobachter für kritische Bedingungen wie plötzliche Guthabenabfälle, unerwartete Eigentumsübertragungen oder wiederholte Zurücksetzungen ein.

3. Leiten Sie Warnungen über verschlüsselte Kanäle an bestimmte Antwortende weiter – nicht an öffentliche Slack- oder Discord-Gruppen.

4. Halten Sie eine vorab unterzeichnete Notfall-Pause-Transaktion bereit, die innerhalb von Sekunden nach der bestätigten Kompromittierung gesendet werden kann.

5. Archivieren Sie alle historischen Zustands-Snapshots wöchentlich mit IPFS-gestützten Merkle-Roots, die von Governance Multisig signiert sind.

Häufig gestellte Fragen

F: Kann ich mich ausschließlich auf automatisierte Scanner wie Slither oder Mythril verlassen? Automatisierte Tools erkennen bekannte Muster, übersehen jedoch logische Fehler, die für Ihr Tokenomics- oder Interaktionsmodell spezifisch sind. Die menschliche Überprüfung bleibt unerlässlich.

F: Ist es sicher, ERC-20-Vorlagen von GitHub ohne Änderungen zu verwenden? Nein. Viele beliebte Vorlagen enthalten veraltete Annahmen über Compilerversionen, fehlende Modifikatoren oder unsichere Übertragungssemantik. Jede Zeile erfordert eine kontextbezogene Validierung.

F: Sollte ich meinen Vertrag mit einer Selbstzerstörungsfunktion bereitstellen? Selbstzerstörung birgt ein irreversibles Risiko. Wenn es zum Testen erforderlich ist, deaktivieren Sie es vor dem Mainnet-Start dauerhaft mithilfe von Flags zur Kompilierungszeit oder bedingter Kompilierung.

F: Wie oft sollte ich Administratorschlüssel für einen Live-Vertrag wechseln? Die Rotation des Admin-Schlüssels ist nach der Bereitstellung nicht anwendbar, da private Schlüssel Smart Contracts nicht direkt steuern. Rotieren Sie stattdessen die Governance-Unterzeichner und aktualisieren Sie die Multisig-Schwellenwerte über zeitlich begrenzte Vorschläge.