Zum Inhalt springen
Financial Context Wiki

Notfallpause eines DeFi-Protokolls

Eine Protokoll-Notfallpause kann ausgewählte Smart-Contract-Aktionen stoppen, während ein Vorfall untersucht wird. Erfahren Sie, wie Umfang, Befugnisse, On-Chain-Nachweise, Ausstiegswege und Neustartbedingungen geprüft werden.

Aktualisiert

Nur zu Bildungszwecken; stellt keine Anlageberatung oder Anlageempfehlung dar. Anlagen können zu Verlusten führen.

Direkte Antwort

Eine Notfallpause ist eine Smart-Contract-Kontrolle, die ausgewählte Aktionen blockiert, während Betreiber einen Vorfall untersuchen oder eindämmen. Sie beweist weder einen Verlust von Geldern noch macht sie Gelder automatisch wiedererlangbar oder stoppt jede Protokollfunktion. Der bereitgestellte Code bestimmt, ob Einzahlungen, Abhebungen, Kredite, Rückzahlungen, Liquidationen, Swaps, Übertragungen, Prägungen oder Upgrades betroffen sind.

OpenZeppelins Hilfsmodul Pausable stellt einen Pausenzustand, die Modifikatoren whenNotPaused und whenPaused sowie die Ereignisse Paused(account) und Unpaused(account) bereit. Das Protokoll muss diese Prüfungen dennoch mit bestimmten Funktionen verbinden und eigene Pause- und Fortsetzungsfunktionen schützen. Angepasste Protokolle können stattdessen mehrere Schalter, marktbezogene Sperren, Obergrenzen oder einen Zustandsautomaten verwenden.

Eine Pause ist sowohl Werkzeug zur Vorfallreaktion als auch privilegierte Macht. Prüfen Sie den genauen Vertrag und die Chain, den aktuellen Zustand, die auslösende Transaktion, den Aufrufer, Rolleninhaber, weiterhin verfügbare Funktionen, die Buchungslogik während der Pause und die Bedingungen für die Wiedereröffnung. Eine deaktivierte Website-Schaltfläche ist kein maßgeblicher On-Chain-Nachweis.

Funktionsweise

  1. Ein Auslöser wird erkannt. Überwachung, Mitwirkende, Prüfer oder Nutzer können einen Codefehler, Oracle-Ausfall, eine ungewöhnliche Saldenänderung, einen Governance-Angriff oder eine Marktstörung feststellen.
  2. Ein autorisiertes Konto sendet eine Transaktion. Der Aufrufer kann Eigentümer, Guardian, Multisig, Zugriffskontrollrolle, Governance-Ausführer oder ein anderer Vertrag sein. Bezeichnungen sind keine Berechtigungen; prüfen Sie den bereitgestellten Autorisierungspfad und jeden Proxy-Administrator.
  3. Der Vertrag ändert seinen Zustand. Ein globaler Schalter kann alle geschützten Funktionen blockieren, während granulare Kontrollen nur einen Markt oder eine Aktion pausieren. Funktionen ohne die betreffende Prüfung laufen weiter.
  4. Zustand und Ereignisse liefern Nachweise. Lesen Sie Pausenvariable oder öffentlichen Getter, Transaktionseingabe, Beleg, ausgelöste Ereignisse, Blockzeit und Aufrufer. Ereignisse helfen bei der Rekonstruktion; der aktuelle Speicher bestimmt jedoch den gegenwärtigen Zustand.
  5. Die Buchung kann weiterlaufen. Zinsindizes, Funding, Belohnungen, Oracle-Aktualisierungen, Auszahlungswarteschlangen oder Liquidationsfristen können weiterlaufen, einfrieren oder später nachgeholt werden. Es gibt kein einheitliches Pausenverhalten.
  6. Reaktion und Behebung folgen. Betreiber können untersuchen, informieren, Rollen entziehen, Parameter ändern, Code aktualisieren, eine Unterdeckung finanzieren oder eine Notabhebung anbieten. Jede Aktion benötigt eine eigene Befugnis und On-Chain-Prüfung.
  7. Die Wiedereröffnung ist eine separate privilegierte Aktion. Prüfen Sie, wer die Pause aufheben kann, ob Timelock oder Abstimmung gelten, welche Code- und Konfigurationsänderungen erfolgten, welche Tests oder Audits sie abdecken und ob alte Genehmigungen oder Verträge riskant bleiben.

Erstellen Sie mit Block-Explorer und verifiziertem Quellcode oder Bytecode eine Funktionsmatrix: Aktion, Vertragsadresse, Pausenbedingung, aktuelle Verfügbarkeit, autorisierter Aufrufer und Wirkung auf Salden oder Schulden. Gleichen Sie Mitteilungen über die etablierte Domain, das Governance-Forum und offizielle Konten ab; verlassen Sie sich nicht auf Antworten oder Werbung, die während eines Vorfalls erscheinen.

Beispiel

Angenommen, ein Kreditprotokoll stellt fest, dass sein Sicherheiten-Oracle 30% vom Referenzmarkt abweicht. Ein Guardian pausiert neue Kredite und Liquidationen, lässt aber Rückzahlungen und zusätzliche Sicherheiten zu. Das begrenzt neue Risiken und verhindert Liquidationen zum umstrittenen Preis, zeigt jedoch nicht, dass Abhebungen, Zinsabgrenzung oder alle anderen Märkte pausiert sind.

Ein Nutzer sollte Guardian-Transaktion, betroffene Marktadresse, Pausenschalter, Oracle-Zustand, Reserven, Schuldenindex und offizielle Vorfallmeldung prüfen. Zeigt die Oberfläche nur „Protokoll pausiert“, lässt sich daraus noch keine vollständige Funktionsmatrix ableiten.

Installiert die Governance später ein neues Oracle und öffnet den Markt wieder, prüfen Sie Implementierungs- und Parameteränderungen, Auditumfang, Aufrufer der Fortsetzung und Zustand nach der Transaktion. Wiedereröffnung beweist nicht, dass Liquidität, Solvenz oder normale Markttiefe zurückgekehrt sind.

Risiken

  • Zu weitreichende Befugnisse. Ein Pausenschlüssel kann möglicherweise auch Code aktualisieren, Oracles ändern, Vermögenswerte prägen, Reserven bewegen oder Rollen vergeben. Listen Sie jede Berechtigung auf, statt anzunehmen, ein Guardian könne nur pausieren.
  • Kompromittierte oder nicht verfügbare Unterzeichner. Ein gestohlener Schlüssel kann den Dienst böswillig stoppen; nicht verfügbare oder operativ korrelierte Multisig-Unterzeichner können eine rechtzeitige Pause oder Wiederaufnahme verhindern.
  • Verborgene Umgehungen. Proxy-Administratoren, Module, alternative Einstiegspunkte, Cross-Chain-Ausführer oder ungeschützte Funktionen können die beworbene Kontrolle umgehen.
  • Blockierte Ausstiege und fortlaufende Verbindlichkeiten. Abhebungen können stoppen, während Zinsen, Funding, Warteschlangenpositionen oder andere Verpflichtungen weiterlaufen. Lesen Sie vor einer Handlung die Buchungsregeln.
  • Unsichere Wiederaufnahme. Eine Pause kann aufgehoben werden, bevor Ursache, Bereitstellungsidentität, Oracle-Konfiguration, Reserven und abhängige Integrationen vollständig geprüft sind.
  • Phishing während Vorfällen. Gefälschte „Wiederherstellungs“- oder „Migrations“-Seiten können Seed-Phrase, privaten Schlüssel, Signatur oder unbegrenzte Token-Genehmigung verlangen. Geben Sie niemals Wallet-Wiederherstellungsdaten preis und prüfen Sie jede Vertragsadresse und Genehmigung unabhängig.
  • Falsches Vertrauen. Eine Pause mindert nur die tatsächlich geschützten Pfade. Sie ist kein Solvenznachweis, Audit, Versicherungsschutz oder Versprechen, Verluste zurückzuholen.

Archivieren Sie vor erneuter Interaktion Vorfalltransaktion und Mitteilung, vergleichen Sie verifizierten Code mit Live-Proxy und Implementierung, prüfen Sie Rollenänderungen und Timelocks, widerrufen Sie gegebenenfalls veraltete Genehmigungen und testen Sie wesentliche Aktionen mit einem verkraftbaren Betrag. Direkte Vertragsaufrufe können eine defekte Oberfläche umgehen, aber auch deren Sicherheitsprüfungen; improvisieren Sie nicht ohne Verständnis von Calldata und Zustand.

Häufige Irrtümer

  • „Pausiert bedeutet, dass alle Vermögenswerte weg sind.“ Eine Pause kann vorsorglich sein; prüfen Sie Salden, Verbindlichkeiten, Reserven und betroffene Funktionen.
  • „Eine deaktivierte Oberfläche bedeutet, dass der Vertrag unbenutzbar ist.“ Frontend-Verfügbarkeit und Vertragszustand sind getrennt. Versuchen Sie direkte Aufrufe nur, wenn Sie Ziel, Funktion, Argumente und Folgen prüfen können.
  • „Ein Guardian kann nur pausieren.“ Die Bezeichnung hat keinen standardisierten Berechtigungssatz. Lesen Sie Rollen, Eigentümer, Module und Upgrade-Befugnisse on-chain.
  • „Während der Pause steht die Zeit still.“ Wirtschaftliche Buchungen und Warteschlangen können weiterlaufen oder mit aufgelaufenen Änderungen fortgesetzt werden.
  • „Nicht mehr pausiert bedeutet behoben und sicher.“ Die Wiedereröffnung ist nur ein Zustandswechsel; Behebung, Audits, Solvenz, Genehmigungen und Liquidität müssen separat geprüft werden.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...