Nur zu Bildungszwecken; stellt keine Anlageberatung oder Anlageempfehlung dar. Anlagen können zu Verlusten führen.
Direkte Antwort
Ein Timelock ist eine von einer Blockchain oder einem Smart Contract erzwungene Regel, die verhindert, dass eine Transaktion, Ausgabe oder Verwaltungsaktion gültig oder ausführbar wird, bevor eine festgelegte Blockhöhe, ein Zeitstempel oder ein Zeitintervall erreicht ist. Er verändert, wann eine Aktion stattfinden kann; er entscheidet nicht, ob sie richtig ist.
Der Begriff umfasst unterschiedliche Mechanismen. Eine Zeitsperre auf Transaktionsebene kann Coins bis zum Eintritt einer Kettenbedingung unausgebbar machen oder eine Transaktion nicht final halten. Ein Governance-Timelock stellt einen bereits autorisierten Vertragsaufruf in eine Warteschlange und verlangt eine Mindestverzögerung, bevor ein Ausführer ihn absenden kann. Uhren, Zustandsübergänge und Fehlerbilder unterscheiden sich.
Der Sicherheitswert entsteht durch die erzwungene Verzögerung. In der Governance erhalten Überwacher und Nutzer Zeit, die eingereihte Nutzlast zu prüfen, zu warnen, über einen autorisierten Weg abzubrechen oder zu pausieren und bei einem echten Ausstiegsweg auszusteigen. Jeder privilegierte Weg, der dasselbe System ohne Timelock ändern kann, hebt diesen Vorteil auf.
Funktionsweise
- Der Mechanismus definiert eine Uhr. Der Schwellenwert kann Blockhöhe, einen von der Kette abgeleiteten Zeitstempel oder die Zeit seit einem früheren On-Chain-Ereignis nutzen. Das sind Protokollwerte, keine Zusagen exakter Kalenderzeit.
- Die gesperrte Aktion wird an eine Bedingung gebunden. Eine absolute Zeitsperre nennt eine künftige Höhe oder Zeit. Eine relative Sperre misst ein Intervall ab einem Ereignis wie der Bestätigung der auszugebenden Ausgabe. Ein Governance-Controller speichert eine geplante Operation und ihre Bereitschaftszeit.
- Die zuständige Schicht erzwingt das Warten. Konsensregeln können eine verfrühte Transaktion oder Skriptausgabe ablehnen. Ein Smart Contract kann einen frühen Funktionsaufruf abweisen. Ein Countdown auf einer Website ist kein Timelock, weil die Oberfläche umgangen werden kann.
- Die Reife ändert die Zulässigkeit, nicht die Absicht. Nach Eintritt der Bedingung kann die Aktion gültig oder bereit werden, wird aber nicht zwingend automatisch übertragen oder ausgeführt. Jemand muss sie einreichen; alle weiteren Autorisierungs- und Gültigkeitsprüfungen bleiben bestehen.
- Die Abdeckung hängt von der Befugnis ab. In der Governance muss der Timelock Eigentümer oder notwendiger Rolleninhaber des Zielvertrags sein; jeder gleichwertige privilegierte Weg muss ebenfalls verzögert sein. Rechte von Vorschlagenden, Abbrechenden, Ausführenden und Administratoren bestimmen, wer planen, stoppen, ausführen oder neu konfigurieren darf.
Bitcoin zeigt den Unterschied auf Transaktionsebene. BIP 65 spezifiziert CHECKLOCKTIMEVERIFY, wodurch eine Ausgabe bis zu einer absoluten Blockhöhen- oder Zeitbedingung unausgebbar bleiben kann. BIP 68 verleiht geeigneten Eingabesequenznummern eine vom Konsens erzwungene relative Zeitsperre, gemessen ab dem Alter der auszugebenden Ausgabe. Diese Regeln sind nicht die Warteschlange eines Governance-Vertrags.
OpenZeppelins TimelockController zeigt die Governance-Verzögerung. Ein Vorschlagender plant eine identifizierte Operation mit mindestens der Mindestverzögerung. Nach Ablauf des Timers wechselt sie von wartend zu bereit; anschließend muss ein Ausführer sie ausführen. Abbruch und Rollenverwaltung folgen den Vertragsregeln, und eine Änderung der Mindestverzögerung muss selbst den Timelock durchlaufen.
Beispiele
Eingereihte Protokollaktualisierung
Eine DAO genehmigt eine Aktualisierung, und ihr Governor plant im Timelock die genaue Zieladresse, den Wert, die Aufrufdaten, die Abhängigkeit und das Salt. Überwachungswerkzeuge können während der Verzögerung Nutzlast und Vorschlag vergleichen und die Auswirkungen simulieren. Wenn die Operation bereit ist, reicht ein autorisierter Ausführer sie ein.
Der Schutz besteht nur, wenn der Timelock die Aktualisierungsbefugnis tatsächlich kontrolliert. Kann ein anderer Eigentümer, Proxy-Administrator, Sicherheitsrat oder ein Modul dieselbe Aktualisierung sofort installieren, muss dieser Umgehungsweg separat bewertet werden. Eine Verzögerung hilft außerdem nur, wenn die Überwachung rechtzeitig erfolgt und Auszahlung oder Migration vor der Ausführung abgeschlossen werden können.
Verzögerter Transaktionspfad
Ein Skript kann vor einer Frist einen Ausgabepfad und danach einen Erstattungspfad anbieten. Die Kette erzwingt die Bedingung bei der Prüfung der Ausgabe. Das Erreichen der Schwelle bewegt keine Mittel: Die berechtigte Partei muss eine gültige Transaktion erstellen und verbreiten; die Bestätigung hängt weiterhin von Gebühren und Blockaufnahme ab.
Risiken und Prüfliste
- Umgehungsbefugnis: Ein anderer Eigentümer, eine Rolle, ein Modul, ein Aktualisierungsschlüssel oder Notfallpfad kann die geschützte Aktion ohne Warten ausführen.
- Falsche Uhr oder Grenze: Blockhöhe, Kettenzeit und verstrichene Zeit sind nicht austauschbar; ein Fehler um eine Einheit kann eine Ausgabe früher oder später als erwartet erlauben.
- Unzureichende Verzögerung: Die Wartezeit kann kürzer sein als für Erkennung, Analyse, Kommunikation und Reaktion nötig.
- Kein praktischer Ausstieg: Pausierte Auszahlungen, Brückenverzögerungen, Illiquidität, Unbonding oder Überlastung können Handlungen im nominellen Fenster verhindern.
- Kompromittierte Rolle oder Stillstand: Böswillige Vorschlagende oder Administratoren können schädliche Aufrufe einreihen; verlorene Ausführer oder zu breite Abbruchrechte können legitime Operationen blockieren.
- Abweichende Nutzlast: Ein lesbarer Vorschlagstitel beweist nicht, dass Ziel, Wert, Aufrufdaten, Abhängigkeit und Salt das Genehmigte umsetzen.
- Implementierungsunterschiede: Ablauf, Abbruch, Stapel, Abhängigkeiten, offene Ausführung und Verzögerungsänderungen variieren je Vertrag und Version.
- Sperrfehler: Ein falscher Zeitstempel, eine falsche Höhe, Sequenz, Skriptverzweigung oder ein nicht verfügbarer Schlüssel kann Vermögenswerte länger als beabsichtigt unzugänglich machen.
Häufige Missverständnisse
Wird ein Timelock bei Ablauf automatisch ausgeführt?
In der Regel nicht. Die Reife macht eine Aktion gewöhnlich nur zulässig. Eine Transaktion muss noch verbreitet werden, oder ein Ausführer muss den Governance-Vertrag aufrufen.
Macht ein Timelock Governance sicher?
Nein. Er schafft Reaktionszeit, prüft aber nicht die Nutzlast, schützt keine privilegierten Schlüssel, garantiert keinen Abbruch und sichert keinen Ausstieg. Unverzögerte parallele Befugnisse können die Kontrolle aufheben.
Beruht jeder Timelock auf Kalenderzeit?
Nein. Manche verwenden Blockhöhe, andere Kettenzeitstempel und wieder andere ein relatives Alter. Erwartete Blockintervalle und Zeitstempel sind keine exakten Terminpläne.
Sind Transaktions- und Governance-Timelocks austauschbar?
Nein. Beide verzögern die Zulässigkeit, doch Konsensregeln für Transaktionen, Skriptbedingungen und Governance-Warteschlangen schützen unterschiedliche Aktionen und müssen nach ihren eigenen Spezifikationen geprüft werden.
Verwandte Themen
- Funktionsweise eines Governance-Timelocks
- Hashed Timelock Contract
- Smart Contract
- DAO
- Notfallpause eines Protokolls
Quellen
- Governance-API: TimelockController - OpenZeppelin-Dokumentation (abgerufen: 2026-08-21)
- BIP 65: OP_CHECKLOCKTIMEVERIFY - Bitcoin Improvement Proposals (abgerufen: 2026-08-21)
- BIP 68: Relative Zeitsperre mit konsenserzwungenen Sequenznummern - Bitcoin Improvement Proposals (abgerufen: 2026-08-21)