Vai al contenuto
Financial Context Wiki

Timelock: transazioni e azioni di governance ritardate

Un timelock obbliga una transazione o un'azione contrattuale ad attendere un blocco, un timestamp o un intervallo. Scopri chi impone il ritardo e quali percorsi possono aggirarlo.

Aggiornato

Solo a scopo educativo; non costituisce consulenza o raccomandazione di investimento. Gli investimenti possono comportare perdite.

Risposta diretta

Un timelock è una regola applicata da una blockchain o da uno smart contract che impedisce a una transazione, una spesa o un’azione amministrativa di diventare valida o eseguibile prima del raggiungimento di un’altezza di blocco, un timestamp o un intervallo trascorso. Cambia quando un’azione può avvenire, ma non stabilisce se sia corretta.

Il termine comprende meccanismi diversi. Un timelock a livello di transazione può rendere una moneta non spendibile o mantenere una transazione non finale fino al verificarsi di una condizione della rete. Un timelock di governance mette in coda una chiamata già autorizzata e impone un ritardo minimo prima che un esecutore possa inviarla. Orologi, transizioni di stato e modalità di guasto differiscono.

Il valore di sicurezza deriva dal ritardo obbligatorio. Nella governance, concede a monitor e utenti il tempo di ispezionare il payload in coda, avvisare, annullare o sospendere tramite un percorso autorizzato, oppure uscire se esiste un vero percorso di uscita. Il vantaggio svanisce per ogni percorso privilegiato che possa modificare lo stesso sistema senza timelock.

Come funziona

  1. Il meccanismo definisce un orologio. La soglia può usare l’altezza del blocco, un timestamp derivato dalla rete o il tempo misurato da un evento on-chain precedente. Sono valori del protocollo, non promesse di un’ora civile esatta.
  2. L’azione bloccata è vincolata a una condizione. Un timelock assoluto indica un’altezza o un momento futuro. Uno relativo misura un intervallo da un evento, come la conferma dell’output da spendere. Un controller di governance registra un’operazione pianificata e il momento in cui sarà pronta.
  3. Il livello pertinente impone l’attesa. Le regole di consenso possono rifiutare una transazione o una spesa di script prematura. Uno smart contract può rifiutare una chiamata anticipata. Un conto alla rovescia su un sito non è un timelock, perché l’interfaccia è aggirabile.
  4. La maturazione cambia l’idoneità, non l’intento. Quando la condizione è soddisfatta, l’azione può diventare valida o pronta, ma non viene necessariamente trasmessa o eseguita automaticamente. Qualcuno deve ancora inviarla e restano validi tutti gli altri controlli di autorizzazione e validità.
  5. La copertura dipende dall’autorità. Nella governance, il timelock deve detenere la proprietà o i ruoli necessari sul contratto di destinazione, e ogni percorso privilegiato equivalente deve essere ritardato. I permessi di proponente, annullatore, esecutore e amministratore stabiliscono chi può pianificare, fermare, eseguire o riconfigurare.

Bitcoin illustra la distinzione transazionale. BIP 65 specifica CHECKLOCKTIMEVERIFY, che può mantenere un output non spendibile fino a una condizione assoluta di altezza o tempo. BIP 68 assegna ai numeri di sequenza degli input idonei un significato di timelock relativo imposto dal consenso, misurato dall’età dell’output speso. Queste regole non sono la coda di un contratto di governance.

TimelockController di OpenZeppelin illustra il ritardo di governance. Un proponente pianifica un’operazione identificata con un ritardo almeno pari al minimo. Scaduto il timer, passa da in attesa a pronta; un esecutore deve poi eseguirla. Annullamento e ruoli seguono le regole del contratto, e la modifica del ritardo minimo deve passare dal timelock stesso.

Esempi

Aggiornamento del protocollo in coda

Una DAO approva un aggiornamento e il suo governor pianifica nel timelock l’indirizzo di destinazione, il valore, i dati della chiamata, la dipendenza e il salt esatti. Durante il ritardo, gli strumenti di monitoraggio possono confrontare il payload con la proposta e simularne gli effetti. Quando l’operazione è pronta, un esecutore autorizzato la invia.

La protezione esiste solo se il timelock controlla davvero l’autorità di aggiornamento. Se un altro proprietario, amministratore proxy, consiglio di sicurezza o modulo può installare subito lo stesso aggiornamento, tale percorso di aggiramento va valutato a parte. Il ritardo è utile solo se il monitoraggio è tempestivo e prelievo o migrazione possono terminare prima dell’esecuzione.

Percorso di transazione ritardato

Uno script può offrire un percorso di spesa prima di una scadenza e uno di rimborso dopo. La rete applica la condizione quando convalida la spesa. Raggiungere la soglia non sposta i fondi: la parte idonea deve costruire e trasmettere una transazione valida, e la conferma dipende ancora dalle commissioni e dall’inclusione in un blocco.

Rischi e lista di controllo

  • Autorità di aggiramento: un altro proprietario, ruolo, modulo, chiave di aggiornamento o percorso di emergenza può eseguire l’azione protetta senza attendere.
  • Orologio o confine errato: altezza, tempo della rete e tempo trascorso non sono intercambiabili; un errore di un’unità può abilitare la spesa prima o dopo il previsto.
  • Ritardo insufficiente: l’attesa può essere inferiore al tempo necessario per rilevare, analizzare, comunicare e rispondere a un’azione.
  • Nessuna uscita pratica: prelievi sospesi, ritardi dei bridge, illiquidità, unbonding o congestione possono impedire di agire nella finestra nominale.
  • Ruolo compromesso o stallo: proponenti o amministratori malevoli possono mettere in coda chiamate dannose; esecutori persi o diritti di annullamento troppo ampi possono bloccare operazioni legittime.
  • Payload non corrispondente: un titolo leggibile non prova che destinazione, valore, dati, dipendenza e salt pianificati attuino ciò che è stato approvato.
  • Differenze di implementazione: scadenza, annullamento, batch, dipendenze, esecuzione aperta e modifiche del ritardo variano per contratto e versione.
  • Errore di blocco: timestamp, altezza, sequenza, ramo di script o chiave errati possono rendere gli asset inaccessibili più a lungo del previsto.

Idee sbagliate comuni

Un timelock si esegue automaticamente alla scadenza?

In genere no. La maturazione rende normalmente l’azione solo idonea. La transazione deve essere trasmessa oppure un esecutore deve chiamare il contratto di governance.

Un timelock rende sicura la governance?

No. Crea tempo di reazione, ma non convalida il payload, protegge le chiavi privilegiate, garantisce l’annullamento o assicura l’uscita degli utenti. Un’autorità parallela senza ritardo può annullare il controllo.

Ogni timelock usa l’ora civile?

No. Alcuni usano l’altezza del blocco, altri timestamp della rete, altri un’età relativa. Intervalli di blocco attesi e timestamp non sono calendari esatti.

I timelock di transazione e governance sono intercambiabili?

No. Entrambi ritardano l’idoneità, ma regole di consenso, condizioni di script e code di governance proteggono azioni diverse e vanno valutati secondo le rispettive specifiche.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...