Cos’è un governance attack nel crypto e come possono proteggersi i protocolli?

Cos’è un governance attack nel crypto?

Un governance attack è un attacco in cui qualcuno usa o prende il controllo del processo decisionale di una DAO o di un protocollo per compiere un’azione (di solito) dannosa. Una DAO è un’organizzazione che prende decisioni tramite regole nei smart contracts e i voti dei partecipanti.

In molti protocolli, i token determinano quanto diritto di voto hai. Chi accumula abbastanza potere di voto può, per esempio, proporre di cambiare impostazioni, aggiungere nuove funzioni, aggiornare la logica di un contratto o spostare fondi da una treasury. Una treasury è, in parole semplici, il fondo comune con le risorse di un protocollo.

Non tutti i governance attack nascono da un errore di programmazione. A volte un attaccante segue formalmente le regole, ma riesce comunque a raccogliere abbastanza influenza da far approvare una proposta dannosa per gli altri utenti. Questo si chiama governance capture: in pratica, il processo decisionale finisce nelle mani di una sola parte o di un piccolo gruppo.

Un possibile trucco in questi casi è un flash loan. Si tratta di un prestito che deve essere rimborsato all’interno della stessa transazione blockchain. Se un protocollo basa il peso di voto sul numero attuale di token in un wallet, senza un periodo di attesa o uno snapshot storico, un attaccante può ottenere temporaneamente molto potere di voto.

Esempio: immagina che un protocollo assegni un voto per ogni token. Qualcuno prende in prestito temporaneamente tantissimi token, vota per una proposta che sposta fondi dalla treasury e rimborsa subito il prestito. Se il sistema conta quei token temporanei, può bastare per influenzare il voto.

In breve

• Un governance attack sfrutta il processo decisionale di una DAO o di un protocollo per compiere un’azione dannosa.
• Nella governance pesata sui token, spesso il numero di token determina quanto diritto di voto ha una persona.
• Un attacco può sfruttare un errore tecnico, ma può anche avvenire dentro le regole esistenti.
• I flash loan possono dare temporaneamente molto potere di voto se un protocollo usa i saldi attuali.
• Le proposte possono, tra le altre cose, modificare impostazioni, aggiornare contratti o spostare asset della treasury.

Come funziona un governance attack?

Un governance attack di solito funziona così: prima l’attaccante raccoglie abbastanza potere di voto effettivo, poi fa approvare una proposta dannosa e infine la esegue. Il modo preciso dipende dalle regole del protocollo.

Il peso di voto può derivare, per esempio, dai token che possiedi, dai voti che altri delegano a te, dai token in staking o dalle posizioni LP. Una posizione LP è la tua quota in una liquidity pool. Il punto cruciale è: in quale momento il protocollo fissa quanto diritto di voto hai?

Spesso un attacco si presenta più o meno così:

1. Raccogliere il diritto di voto L’attaccante compra token, raccoglie deleghe, usa un potere di voto già grande oppure prende in prestito token temporaneamente tramite un flash loan.

2. Presentare una proposta La proposta contiene una o più azioni che gli smart contract devono eseguire. Per esempio, possono essere modifiche alle impostazioni, ma anche un upgrade o un trasferimento dalla treasury.

3. Vincere la votazione La proposta deve ottenere abbastanza voti e raggiungere il quorum richiesto. Il quorum è la quantità minima di partecipazione necessaria perché una votazione sia valida.

4. Eseguire l’azione Dopo una votazione riuscita, la governance esegue le transazioni previste. Senza ritardo, questo può avvenire subito. Con un timelock, invece, l’azione deve prima aspettare.

Uno snapshot storico aiuta contro alcuni attacchi con flash loan. Uno snapshot è, in pratica, una foto dei diritti di voto in un momento precedente e fisso. Un voting delay, cioè un tempo di attesa prima che i voti contino, funziona bene solo se i token presi in prestito temporaneamente non sono già presenti in quello snapshot.

Beanstalk mostra quanto può essere grande l’impatto. Il 17 aprile 2022 il protocollo è stato attaccato tramite governance on-chain. L’attaccante ha usato un flash loan per compromettere il meccanismo di governance di allora e sottrarre asset dalla DAO.

Tra l’altro, uno snapshot non è una soluzione completa. Se un attaccante ha già comprato o controlla i token prima del momento scelto, quel potere di voto conta comunque.

Quali conseguenze può avere un governance attack?

Un governance attack può permettere a un attaccante di ottenere denaro, diritti o impostazioni importanti di un protocollo. Quanto sia grave dipende tutto da ciò che la governance può davvero fare.

In alcuni protocolli, la governance può per esempio modificare le impostazioni del sistema, aggiungere nuovi mercati o funzioni e aggiornare parti del protocollo. Se la governance controlla anche proxy importanti, componenti di configurazione o contratti della treasury, una proposta malevola può causare danni seri.

Le possibili conseguenze includono:

• perdita di asset della treasury o degli utenti;
• minting indesiderato di nuovi token;
• impostazioni modificate che danneggiano gli utenti;
• diritti amministrativi cambiati;
• un upgrade verso una logica di contratto dannosa;
• blocco temporaneo o totale delle funzioni.

Durante l’attacco a Beanstalk, il 17 aprile 2022, tutti gli asset non BEAN degli utenti sono stati rubati, per un valore di circa 77 milioni di dollari. Dopo di ciò, il protocollo è stato messo in pausa, la governance on-chain è stata rimossa e la struttura di governance è cambiata.

Il danno spesso è più grande della sola perdita diretta. Un protocollo può dover migrare verso nuovi contratti, pagare audit e lavoro di recupero e affidare temporaneamente più controllo d’emergenza a un piccolo gruppo. Questo può colpire molto la fiducia degli utenti.

Come può un protocollo perdere il controllo?

Un protocollo perde di fatto il controllo quando un attaccante ottiene abbastanza diritti sui contratti che eseguono azioni critiche. Pensa al proprietario di un proxy, a un account che può eseguire upgrade, a un ruolo che può pianificare proposte in un timelock o al controller della treasury.

Qui un proxy è, in parole semplici, un indirizzo di contratto fisso che punta a una certa versione della logica del contratto. In un protocollo aggiornabile, la governance può far puntare quell’indirizzo a una nuova logica. Così, una sola proposta approvata può cambiare in modo profondo il funzionamento del protocollo.

Per farlo, un attaccante non deve sempre avere la maggioranza di tutti i token holder. Con una partecipazione bassa, un quorum basso o deleghe molto concentrate, anche un gruppo relativamente piccolo può avere abbastanza potere di voto effettivo.

Dopo un’esecuzione dannosa, il recupero può diventare ancora più difficile. L’attaccante può cambiare i permessi, spostare gli asset o persino modificare le regole future della governance. In quel caso, la comunità potrebbe non riuscire più a intervenire con la stessa strada, oppure solo molto più tardi.

La perdita di controllo può avvenire anche senza attacco. Se gli account autorizzati di un timelock autogestito non sono più disponibili, un contratto gestito da quel timelock può bloccarsi a tempo indeterminato.

Come possono proteggersi i protocolli crypto e DeFi?

I protocolli crypto e DeFi possono ridurre il rischio evitando che potere di voto, permessi ed esecuzione si concentrino troppo facilmente nello stesso momento. Non esiste un’impostazione magica che blocchi ogni attacco, ma più livelli insieme rendono l’abuso più difficile.

Le misure importanti sono:

1. Usare snapshot e un voting delay Fissa il peso di voto in un momento precedente e inserisci un periodo di attesa. Così è più difficile procurarsi token all’ultimo minuto e usarli subito per votare.

2. Scegliere soglie di voto adeguate Un minimo per presentare una proposta rende più difficile lo spam di proposte economiche. Un quorum impedisce che decida solo una partecipazione molto piccola. Il compromesso resta difficile: soglie troppo basse rendono più facile la capture, soglie troppo alte possono rendere la governance poco praticabile.

3. Mettere le azioni sensibili dietro un timelock Upgrade, grandi modifiche ai parametri e azioni sulla treasury non devono per forza avvenire subito dopo una votazione. Un timelock dà agli utenti il tempo di controllare un’azione pianificata e, se serve, chiudere la propria posizione.

4. Limitare i diritti per ruolo Non dare alla governance automaticamente un potere illimitato. In particolare, i diritti per upgrade, minting e chiamate esterne senza limiti meritano restrizioni extra. I poteri d’emergenza devono essere chiaramente definiti.

5. Testare le vere azioni della proposta Non basta controllare solo il modulo di voto. I team devono testare e simulare anche le transazioni esatte dietro una proposta. Una proposta può sembrare innocua a grandi linee, mentre le chiamate concrete fanno tutt’altro.

6. Monitorare proposte e potere di voto Il monitoraggio non impedisce da solo un attacco, ma può far notare in tempo una proposta sospetta o un grande spostamento nelle deleghe. Un piano di risposta agli incidenti già definito aiuta poi a reagire più velocemente.

Gli audit restano utili, ma non sono una garanzia. Non tutti i governance attack nascono da un bug nel codice. Anche proposte ingannevoli, bassa partecipazione e transazioni valutate male possono creare problemi.

Come possono aiutare timelock e multisig governance?

I timelock e i multisig possono aggiungere un ulteriore livello di sicurezza, perché impediscono che un singolo account approvato o compromesso possa eseguire tutto subito.

Un timelock controller impone un tempo minimo di attesa tra la pianificazione e l’esecuzione di un’azione importante. Se il timelock è l’amministratore di un contratto, quel ritardo vale anche per azioni che altrimenti potrebbero avvenire subito con i diritti amministrativi.

Questa finestra di reazione è importante. Utenti e ricercatori di sicurezza possono controllare i dati esatti della transazione prima che la modifica vada live. In caso di proposta pericolosa, per esempio, gli utenti possono chiudere la propria posizione prima che l’azione venga eseguita. Il timelock non rende automaticamente invalida un’azione dannosa, ma toglie velocità a un attacco visibile.

Compound v2, per esempio, usa più fasi: due giorni di revisione, tre giorni di voto e poi due giorni di timelock. Così una modifica del protocollo richiede almeno una settimana.

Un multisig funziona in modo diverso. Qui più proprietari devono confermare una transazione. In un multisig 3-su-5 servono tre firme valide. Una chiave rubata o compromessa non basta quindi per spostare fondi o cambiare impostazioni da sola.

Un multisig può, per esempio, essere l’unica parte autorizzata a pianificare azioni in un timelock. In questo modo prima deve esserci l’accordo di un gruppo di firmatari, e solo dopo inizia il periodo di attesa impostato.

C’è però una cosa importante da sapere: un multisig sposta la fiducia sui firmatari. Se abbastanza signer si mettono d’accordo, se troppe chiavi vengono rubate o se i signer non sono raggiungibili, possono comunque nascere problemi. Anche i moduli o le estensioni extra meritano attenzione, perché in certe condizioni possono eseguire transazioni fuori dal normale controllo delle firme.

Quali sono i limiti della governance nel crypto?

La governance nel crypto può eseguire decisioni in modo trasparente e automatico, ma il sistema non sa da solo se una proposta sia anche saggia o giusta. Una votazione on-chain valida dimostra solo che le regole sono state seguite.

Nella governance pesata sui token, l’influenza dipende dal peso economico. I grandi holder, i fondi e i delegate noti possono quindi avere molta più influenza dei piccoli partecipanti, anche senza attacchi o bug nel codice. La delega rende più facile votare, ma può anche concentrare il potere in un piccolo gruppo.

Anche velocità e sicurezza a volte entrano in conflitto. Periodi di voto più lunghi e timelock danno più tempo per valutare bene le proposte e reagire. Allo stesso tempo, però, rallentano gli upgrade utili, gli aggiustamenti e a volte anche la risposta a un incidente.

Quorum e minimi per le proposte hanno lo stesso compromesso. Se sono troppo bassi, un gruppo piccolo ma ben organizzato può prendere decisioni. Se sono troppo alti, le proposte normali possono bloccarsi perché vota troppo poca gente.

Un altro problema è la complessità. La calldata esatta di una proposta, un upgrade della logica del contratto o l’interazione tra più smart contract sono difficili da valutare per molti votanti. Di conseguenza, una proposta può essere corretta dal punto di vista procedurale, mentre poche persone capiscono davvero cosa stia succedendo.

Un multisig o un guardian può ridurre il rischio di un attacco rapido, ma introduce anche rischi di centralizzazione e disponibilità. Un guardian è un account o un gruppo con poteri speciali di emergenza. Se una parte del genere agisce in modo malevolo, non è raggiungibile o blocca le transazioni, quel livello di sicurezza può diventare a sua volta un punto debole.

La governance quindi non è un’impostazione che sistemi una volta e poi dimentichi. La distribuzione di token, deleghe, diritti, incentivi, controllo delle proposte e procedure d’emergenza va rivista regolarmente.

Conclusione

Un governance attack non riguarda solo hacker che trovano un errore tecnico. Anche una parte che, secondo le regole, riesce a raccogliere abbastanza potere di voto può mettere in difficoltà un protocollo se la governance ha troppi diritti o se le proposte vengono eseguite troppo in fretta.

Una buona protezione si basa su più livelli: snapshot, voting delay, soglie adeguate, permessi limitati, controllo delle azioni delle proposte e monitoraggio. Timelock e multisig possono aggiungere ulteriore tempo e controllo. Alla fine, la domanda più importante resta semplice: chi può cambiare cosa, e quanto tempo ha il resto per accorgersene e reagire?