Zum Inhalt springen
Financial Context Wiki

Wie funktioniert ein Governance-Timelock?

Ein Governance-Timelock macht aus einer genehmigten Aktion eine öffentlich beobachtbare Operation, die vor der Ausführung warten muss. Erfahren Sie, wie IDs, Rollen, Verzögerungen, Ablauf, Abbruch und Ausstiegsfenster funktionieren.

Aktualisiert

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

Direkte Antwort

Ein Governance-Timelock ist eine Ausführungssteuerung, keine weitere Abstimmung. Nachdem die Governance eine Nutzlast autorisiert hat, plant ein berechtigter Antragsteller die genaue Operation ein. Der Vertrag hält fest, wann sie ausführbar werden kann, und lehnt eine frühere Ausführung ab. Durch diese Verzögerung wird ein anstehendes Upgrade, eine Parameteränderung, eine Überweisung aus der Treasury oder eine Rollenänderung sichtbar, bevor sie wirksam wird.

Die angegebene Verzögerung ist nur ein Teil der Kontrolle. Prüfen Sie die Operations-ID, den frühestmöglichen Ausführungszeitpunkt, etwaige Ablaufregeln, den Vorgänger, den Antragsteller, den Ausführer, den Abbrecher, den Administrator und jeden anderen Pfad, der den Zielvertrag kontrollieren kann. Ein Timelock von 48-hour bietet kein Ausstiegsfenster von 48-hour, wenn die Operation spät eingeplant wird, die Überwachung verzögert reagiert, Auszahlungen länger dauern oder ein anderer privilegierter Schlüssel dieselbe Änderung sofort vornehmen kann.

Ein Timelock entscheidet nicht, ob eine Aktion legitim oder sicher ist. Er verschafft Menschen und automatisierten Überwachungssystemen Zeit, die Aufrufe zu decodieren, ihre Auswirkungen zu simulieren, bei entsprechender Berechtigung abzubrechen oder zu pausieren, die Änderung zu kommunizieren und Positionen zu verlassen, sofern ein tatsächlicher Ausstiegspfad besteht.

Funktionsweise

  1. Die Berechtigung wird dem Timelock zugewiesen. Der Timelock muss Eigentümer des Zielvertrags sein oder dort die relevante Rolle innehaben. Hat ein Governor keine Berechtigung für das Ziel, ändert die Annahme eines Vorschlags nichts; behält ein separater Administrator eine parallele Berechtigung, kann dieser Pfad die Verzögerung umgehen.
  2. Ein Antragsteller plant eine genaue Operation ein. Im TimelockController von OpenZeppelin ist die ID einer einzelnen Operation der Hash aus target, value, data, predecessor und salt; bei Batch-Operationen werden die entsprechenden Arrays sowie dieselbe Abhängigkeit und dasselbe Salt gehasht. Jede Änderung an einem Feld erzeugt eine andere Operations-ID. Das Salt unterscheidet ansonsten identische Aktionen.
  3. Die Mindestverzögerung beginnt mit der Einplanung. Eine erfolgreiche Abstimmung startet nicht zwangsläufig den Timelock. Bei der Einplanung wird ein Bereitschaftszeitstempel mit einer Verzögerung erfasst, die mindestens der aktuellen Mindestverzögerung des Vertrags entsprechen muss. Operationen von OpenZeppelin wechseln von Unset zu Waiting, dann zu Ready und nach erfolgreicher Ausführung schließlich zu Done.
  4. Abhängigkeiten und Berechtigungen werden bei der Ausführung geprüft. Eine Vorgängeroperation muss bereits den Zustand Done haben. Der Aufrufer muss die Ausführerregel erfüllen und der Aufruf des Ziels muss erfolgreich sein. Ein Ausführer kann die eingeplante Nutzlast nicht verändern. Wird die Ausführerrolle address(0) erteilt, kann nach Ablauf der Verzögerung jeder die Ausführung anstoßen. Das verbessert die Verfügbarkeit, erlaubt aber jedem Konto, den genauen zulässigen Ausführungszeitpunkt zu wählen.
  5. Der Abbruch setzt eine ausstehende Operation in ihren Ausgangszustand zurück. In aktuellen OpenZeppelin-Verträgen kann ein Konto mit CANCELLER_ROLE eine Operation abbrechen, solange sie aussteht, auch wenn sie bereits bereit, aber noch nicht ausgeführt ist. Eine erneute Einplanung startet einen neuen Zeitgeber. Die Rollenzuweisung ist wichtig: Ältere Versionen und andere Timelocks können das Abbruchrecht dem Antragsteller oder Administrator zuweisen.
  6. Der Ablauf hängt von der Implementierung ab. Der TimelockController von OpenZeppelin hat keinen eingebauten Ablauf nach einer Nachfrist; eine bereite Operation bleibt bereit, bis sie ausgeführt oder abgebrochen wird. Der Timelock von Compound v2 verlangt dagegen die Ausführung spätestens bis eta + GRACE_PERIOD, und sein Quellcode setzt GRACE_PERIOD auf 14 days. Governor Bravo kennzeichnet einen eingeplanten Vorschlag nach Überschreiten dieser Grenze als abgelaufen.
  7. Auch die Administration muss verzögert werden. OpenZeppelin erlaubt updateDelay nur durch einen Aufruf des Timelocks an sich selbst. Eine selbstverwaltete Bereitstellung zwingt Rollenänderungen ebenfalls durch eingeplante Operationen. Ein vorübergehender externer Administrator, der bei der Einrichtung eingesetzt wird, sollte seine Rolle nach der Konfiguration aufgeben; andernfalls bleibt er ein separater Vertrauenspfad.

Rekonstruieren Sie für jede eingeplante Aktion einen Kontrolldatensatz aus Vertragszustand und Ereignissen: Chain-ID, Adressen von Timelock und Ziel, Operations-ID, decodierte Nutzlast, Antragsteller, Einplanungstransaktion und -zeitstempel, Mindestverzögerung, Bereitschaftszeitpunkt, gegebenenfalls Ablauf, Vorgänger, Ausführerrichtlinie, Abbruchberechtigung und endgültiger Transaktionsstatus. Leiten Sie diese Felder nicht allein von einer Governance-Website ab.

Praxisbeispiel

Angenommen, ein Vorschlag senkt die Liquidationsschwelle eines Kreditmarkts von 75% auf 60%. Die Abstimmung endet am Monday 12:00 UTC, doch ein Antragsteller plant die Operation erst am Tuesday 18:00 UTC ein. Die eingeplante Verzögerung beträgt 48 hours, daher ist die früheste Ausführung am Thursday 18:00 UTC möglich und nicht am Wednesday 12:00 UTC.

Die Operation enthält den Risikomanagervertrag als target, einen value von null nativen Token, die codierten data für die Parameteränderung, keinen Vorgänger und ein offengelegtes salt. Der aus diesen Feldern neu berechnete Hash muss mit der ausgegebenen Operations-ID übereinstimmen. Eine andere Marktadresse, Schwelle oder ein anderes Salt ergibt eine andere Operation, auch wenn die Beschreibung in der Benutzeroberfläche gleich aussieht.

Benutzer haben somit ab der Einplanung 48 hours, ihre tatsächlich nutzbare Ausstiegszeit ist jedoch kürzer. Trifft die Warnung 6 hours nach der Einplanung ein und dauert eine Unstaking- oder Auszahlungswarteschlange 24 hours, bleiben nur 18 hours Puffer:

usable response time = ready time - detection time - exit settlement time

Kann eine Notfall-Multisig Auszahlungen sofort pausieren, kann sie Verluste während eines Vorfalls begrenzen, aber auch einen Ausstieg vor der eingeplanten Änderung unmöglich machen. Prüfen Sie diese Berechtigung separat. Überprüfen Sie nach der Ausführung den tatsächlichen Speicherzustand des Zielvertrags und die ausgegebenen Ereignisse; eine Timelock-Ausführungstransaktion kann erfolgreich sein, obwohl das erwartete wirtschaftliche Ergebnis weiterhin missverstanden wird.

Risiken und Kontrollen

  • Umgehungsberechtigungen. Erfassen Sie Eigentümer, Proxy-Administratoren, Zugriffskontrollrollen, Upgrade-Beacons, Notfallgremien, Module und Cross-Chain-Ausführer. Der kürzeste privilegierte Pfad bestimmt die effektive Verzögerung.
  • Austausch der Nutzlast oder mangelhafte Decodierung. Berechnen Sie die Operations-ID aus den Rohfeldern neu, ermitteln Sie die Proxy-Implementierungen, decodieren Sie jeden Selektor und jedes Argument und simulieren Sie den vollständigen Batch. Der menschenlesbare Vorschlagstext ist nicht die ausführbare Nutzlast.
  • Unzureichende Vorwarnung. Lösen Sie Warnungen durch On-Chain-Ereignisse zur Einplanung und zum Abbruch aus, nicht nur durch Forenbeiträge. Messen Sie die Vorwarnzeit von der bestätigten Einplanung bis zum frühesten ausführbaren Block oder Zeitstempel und ziehen Sie anschließend die Erkennungs- und Ausstiegsabwicklungszeit ab.
  • Fehlgeschlagener Abbruch. Bestätigen Sie, welche Konten abbrechen können, ob sie einsatzbereit sind, welchen Schwellenwert sie benötigen und ob ein Abbruch noch möglich ist, nachdem die Operation bereit geworden ist. Proben Sie die Transaktion vor einem Vorfall.
  • Ausführerausfall oder zeitliche Manipulation. Eingeschränkte Ausführer können ausfallen oder die Ausführung absichtlich verzögern. Eine offene Ausführung verbessert die Verfügbarkeit, erlaubt Dritten aber eine sofortige Ausführung bei Fälligkeit. Daher müssen abhängige Preise, Oracle-Aktualisierungen und Benutzerpositionen an dieser Grenze sicher sein.
  • Veraltete eingeplante Aktionen. Wo kein Ablauf besteht, können alte bereite Operationen unbegrenzt ausführbar bleiben. Verfolgen Sie sie und brechen Sie aufgegebene Operationen ausdrücklich ab. Wo eine Nachfrist gilt, überwachen Sie deren genaues Ende und verlangen Sie nach dem Ablauf einen neuen Governance-Zyklus.
  • Abhängigkeits- und Batch-Risiko. Überprüfen Sie die ID des Vorgängers und die Reihenfolge im atomaren Batch. Ein einziger zurückgesetzter Aufruf kann einen atomaren Batch blockieren; eine falsche Abhängigkeit kann eine ansonsten gültige Operation dauerhaft festsetzen.
  • Unsichere Administration. Unterwerfen Sie Verkürzungen der Verzögerung, Rollenzuweisungen und den Austausch des Timelocks dem Timelock selbst. Entfernen Sie Bereitstellungsadministratoren, erhalten Sie mindestens einen funktionsfähigen Antragsteller und Ausführer und vermeiden Sie Konfigurationen, die die Kontrolle dauerhaft sperren.
  • Kein glaubwürdiger Ausstieg. Vergleichen Sie die Verzögerung mit Auszahlungswarteschlangen, Bridge-Finalität, Marktliquidität, Pausenbefugnissen und Überlastung. Eine veröffentlichte Verzögerung schützt Benutzer nicht, wenn Vermögenswerte den Vertrag vor der Ausführung nicht verlassen können.

Der operative Maßstab ist ein durch Belege gestützter Zeitablauf, nicht ein angezeigter Countdown. Archivieren Sie das Einplanungsereignis, die decodierten Aufrufe, das Simulationsergebnis, die Rolleninhaber, den Abbruchplan, die frühesten und spätesten Ausführungszeiten, die Kommunikationskanäle und die Zustandsdifferenz nach der Ausführung.

Häufige Irrtümer

  • „Die Verzögerung beginnt mit dem Ende der Abstimmung.“ Sie beginnt normalerweise, wenn die erfolgreiche Aktion eingeplant wird, sofern die bereitgestellte Implementierung diese Zeitpunkte nicht ausdrücklich miteinander verknüpft.
  • „Jeder kann ausführen, also kann jeder den Vorschlag ändern.“ Ein offener Ausführer kann nur eine bereits eingeplante Nutzlast auslösen, deren Operations-ID und Bedingungen übereinstimmen.
  • „Bereit bedeutet, dass die Aktion sofort ausgeführt werden muss.“ Bereit bedeutet ausführbar. Die Ausführung erfordert weiterhin eine Transaktion, Berechtigungen, erfüllte Abhängigkeiten und einen erfolgreichen Aufruf des Ziels.
  • „Jeder Timelock hat ein Ausführungsfenster.“ Der Ablauf variiert je nach Implementierung. Compound v2 verwendet eine Nachfrist; der TimelockController von OpenZeppelin lässt bereite Operationen standardmäßig nicht ablaufen.
  • „Ein langer Timelock beseitigt das Governance-Risiko.“ Eine Verzögerung hilft nur, wenn Überwachung, Verständnis, Abbruch oder Pause, Kommunikation und Ausstieg vor der Ausführung möglich sind. Parallele Administratoren und blockierte Auszahlungen können diesen Vorteil zunichtemachen.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...