Vai al contenuto
Financial Context Wiki

Come funziona un timelock di governance?

Un timelock di governance trasforma un'azione approvata in un'operazione osservabile pubblicamente che deve attendere prima dell'esecuzione. Scopri come funzionano ID, ruoli, ritardi, scadenza, annullamento e finestre di uscita.

Aggiornato

Solo a scopo educativo; non costituisce consulenza d’investimento. Gli investimenti possono comportare perdite.

Risposta diretta

Un timelock di governance è un controllore dell’esecuzione, non un’altra votazione. Dopo che la governance ha autorizzato un payload, un proponente approvato pianifica l’operazione esatta. Il contratto registra quando essa può diventare eseguibile e ne rifiuta l’esecuzione prima di quel momento. Questo ritardo rende osservabile un aggiornamento, una modifica dei parametri, un trasferimento dalla tesoreria o una modifica dei ruoli prima che abbia effetto.

Il ritardo dichiarato è solo una parte del controllo. Occorre esaminare l’ID operazione, il primo momento utile per l’esecuzione, l’eventuale regola di scadenza, il predecessore, il proponente, l’esecutore, il soggetto autorizzato all’annullamento, l’amministratore e ogni altro percorso in grado di controllare il contratto di destinazione. Un timelock di 48-hour non offre una finestra di uscita di 48-hour se l’operazione viene accodata tardi, il monitoraggio è in ritardo, i prelievi richiedono più tempo oppure un’altra chiave privilegiata può effettuare immediatamente la stessa modifica.

Un timelock non stabilisce se un’azione sia legittima o sicura. Offre tempo alle persone e ai sistemi di monitoraggio automatico per decodificare le chiamate, simularne gli effetti, annullare o mettere in pausa quando autorizzati, comunicare la modifica e chiudere le posizioni quando esiste un percorso di uscita effettivo.

Come funziona

  1. L’autorità viene assegnata al timelock. Il timelock deve essere proprietario del contratto di destinazione o detenerne il ruolo pertinente. Se un governor non ha alcuna autorità sul contratto di destinazione, l’approvazione di una proposta non cambia nulla; se un amministratore separato conserva un’autorità parallela, quel percorso può aggirare il ritardo.
  2. Un proponente pianifica un’operazione esatta. Nel TimelockController di OpenZeppelin, l’ID di un’operazione singola è l’hash di target, value, data, predecessor e salt; per le operazioni in batch viene calcolato l’hash dei relativi array, insieme alla stessa dipendenza e allo stesso salt. La modifica di un solo campo genera un ID operazione diverso. Il salt distingue azioni altrimenti identiche.
  3. Il ritardo minimo inizia al momento della pianificazione. Una votazione approvata non fa necessariamente partire il timelock. La pianificazione registra un timestamp di disponibilità usando un ritardo che deve essere almeno pari al minimo corrente del contratto. Le operazioni OpenZeppelin passano da Unset a Waiting, quindi a Ready e infine a Done dopo l’esecuzione riuscita.
  4. Dipendenze e autorizzazioni vengono controllate all’esecuzione. Un predecessore deve essere già Done. Il chiamante deve soddisfare la regola dell’esecutore e la chiamata al contratto di destinazione deve riuscire. Un esecutore non può modificare il payload pianificato. Assegnare il ruolo di esecutore a address(0) rende l’esecuzione aperta a chiunque dopo la maturazione; ciò migliora la disponibilità, ma consente a qualsiasi account di scegliere il momento esatto di esecuzione tra quelli idonei.
  5. L’annullamento riporta un’operazione in sospeso allo stato iniziale. Negli attuali contratti OpenZeppelin, un account con CANCELLER_ROLE può annullare un’operazione mentre è in sospeso, anche quando è pronta ma non ancora eseguita. Una nuova pianificazione fa partire un nuovo timer. La configurazione dei ruoli è importante: versioni precedenti e altri timelock possono attribuire l’annullamento al proponente o all’amministratore.
  6. La scadenza dipende dall’implementazione. Il TimelockController di OpenZeppelin non prevede una scadenza incorporata basata su un periodo di tolleranza: un’operazione pronta rimane tale finché non viene eseguita o annullata. Il Timelock di Compound v2 richiede invece l’esecuzione entro eta + GRACE_PERIOD e il suo codice sorgente imposta GRACE_PERIOD su 14 days. Governor Bravo considera scaduta una proposta accodata dopo tale limite.
  7. Anche l’amministrazione deve essere ritardata. OpenZeppelin consente updateDelay solo mediante una chiamata del timelock a se stesso. Analogamente, una distribuzione autoamministrata obbliga a effettuare le modifiche dei ruoli tramite operazioni pianificate. Un amministratore esterno temporaneo usato durante la configurazione dovrebbe rinunciare al ruolo al termine; altrimenti resta un percorso di fiducia separato.

Per ogni azione accodata, ricostruisci dai dati dello stato e dagli eventi del contratto un registro dei controlli: ID della chain, indirizzi del timelock e del contratto di destinazione, ID operazione, payload decodificato, proponente, transazione e timestamp di pianificazione, ritardo minimo, momento di disponibilità, eventuale scadenza, predecessore, politica dell’esecutore, autorità di annullamento e stato finale della transazione. Non dedurre questi campi soltanto da un sito web di governance.

Esempio svolto

Supponiamo che una proposta riduca la soglia di liquidazione di un mercato dei prestiti dal 75% al 60%. La votazione termina alle Monday 12:00 UTC, ma un proponente non pianifica l’operazione fino a Tuesday 18:00 UTC. Il ritardo pianificato è di 48 hours, quindi il primo momento utile per l’esecuzione è Thursday 18:00 UTC, non Wednesday 12:00 UTC.

L’operazione contiene il contratto del gestore del rischio come target, zero value in token nativo, i data codificati per la modifica del parametro, nessun predecessore e un salt reso pubblico. Il ricalcolo dell’hash a partire da questi campi deve corrispondere all’ID operazione emesso. Un indirizzo di mercato, una soglia o un salt diversi costituiscono un’operazione diversa, anche se la descrizione nell’interfaccia appare identica.

Gli utenti dispongono quindi di 48 hours dalla pianificazione, ma il loro tempo di uscita utilizzabile è inferiore. Se l’avviso arriva 6 hours dopo la pianificazione e una coda di unstaking o prelievo richiede 24 hours, rimangono soltanto 18 hours di margine:

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

Se un multisig di emergenza può sospendere immediatamente i prelievi, può ridurre le perdite durante un incidente, ma anche rendere impossibile l’uscita prima della modifica accodata. Esamina separatamente tale autorità. Dopo l’esecuzione, verifica lo storage effettivo del contratto di destinazione e gli eventi emessi: una transazione di esecuzione del timelock può riuscire anche quando il risultato economico atteso è ancora frainteso.

Rischi e controlli

  • Autorità che consente di aggirare il timelock. Elenca proprietari, amministratori dei proxy, ruoli di controllo degli accessi, beacon di aggiornamento, consigli di emergenza, moduli ed esecutori cross-chain. Il percorso privilegiato più breve determina il ritardo effettivo.
  • Sostituzione del payload o decodifica inadeguata. Ricalcola l’ID operazione dai campi grezzi, individua le implementazioni dei proxy, decodifica ogni selettore e argomento e simula l’intero batch. Il testo leggibile della proposta non è il payload eseguibile.
  • Preavviso insufficiente. Genera avvisi dagli eventi on-chain di pianificazione e annullamento, non soltanto dai post nei forum. Misura il preavviso dalla pianificazione confermata al primo blocco o timestamp eseguibile, quindi sottrai i tempi di rilevamento e regolamento dell’uscita.
  • Mancato annullamento. Verifica quali account possono annullare, se sono operativi, quale soglia richiedono e se l’annullamento resta possibile dopo che l’operazione è diventata pronta. Prova la transazione prima di un incidente.
  • Mancata esecuzione o manipolazione dei tempi. Gli esecutori con restrizioni possono diventare indisponibili o ritardare intenzionalmente l’esecuzione. L’esecuzione aperta migliora la disponibilità, ma permette a terzi di eseguire immediatamente alla maturazione; prezzi dipendenti, aggiornamenti degli oracoli e posizioni degli utenti devono quindi essere sicuri in quel momento.
  • Azioni accodate obsolete. Se non esiste una scadenza, le vecchie operazioni pronte possono restare eseguibili a tempo indeterminato. Monitora e annulla esplicitamente le operazioni abbandonate. Se esiste un periodo di tolleranza, controllane la fine esatta e richiedi un nuovo ciclo di governance dopo la scadenza.
  • Rischi di dipendenza e batch. Verifica l’ID del predecessore e l’ordine atomico del batch. Una singola chiamata che produce un revert può bloccare un batch atomico; una dipendenza errata può portare a uno stallo permanente di un’operazione altrimenti valida.
  • Amministrazione non sicura. Assoggetta al timelock stesso le riduzioni del ritardo, le assegnazioni di ruoli e la sostituzione del timelock. Rimuovi gli amministratori della distribuzione, conserva almeno un proponente e un esecutore operativi ed evita una configurazione che blocchi permanentemente il controllo.
  • Assenza di un’uscita credibile. Confronta il ritardo con le code di prelievo, la finalità dei bridge, la liquidità del mercato, i poteri di pausa e la congestione. Un ritardo pubblicato non protegge gli utenti se gli asset non possono uscire prima dell’esecuzione.

Lo standard operativo è una cronologia supportata da prove, non un conto alla rovescia visualizzato. Archivia l’evento di pianificazione, le chiamate decodificate, il risultato della simulazione, i titolari dei ruoli, il piano di annullamento, il primo e l’ultimo momento utile per l’esecuzione, i canali di comunicazione e la differenza di stato successiva all’esecuzione.

Errori comuni

  • “Il ritardo inizia quando termina la votazione.” Normalmente inizia quando l’azione approvata viene pianificata, a meno che l’implementazione distribuita non colleghi esplicitamente i due momenti.
  • “Chiunque può eseguire, quindi chiunque può modificare la proposta.” Un esecutore aperto può attivare soltanto un payload già pianificato, il cui ID operazione e le cui condizioni corrispondono.
  • “Ready significa che l’azione deve essere eseguita immediatamente.” Ready significa idonea. L’esecuzione richiede comunque una transazione, le autorizzazioni, dipendenze soddisfatte e una chiamata riuscita al contratto di destinazione.
  • “Ogni timelock ha una finestra di esecuzione.” La scadenza varia secondo l’implementazione. Compound v2 usa un periodo di tolleranza; il TimelockController di OpenZeppelin non fa scadere per impostazione predefinita le operazioni pronte.
  • “Un timelock lungo elimina il rischio di governance.” Il ritardo è utile soltanto quando monitoraggio, comprensione, annullamento o pausa, comunicazione e uscita sono tutti possibili prima dell’esecuzione. Amministratori paralleli e prelievi bloccati possono annullarne il beneficio.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...