Come controllare uno smart contract prima di firmare

Cosa prova davvero la verifica

Un contratto distribuito su Ethereum o qualsiasi chain EVM è bytecode. È deterministico, auditabile in principio, e illeggibile in pratica.

La verifica è il processo di sottomettere il codice sorgente Solidity o Vyper originale, insieme alla versione esatta del compilatore e alle impostazioni di ottimizzazione usate, così che chiunque possa ricompilarlo e confermare che l'output corrisponda al bytecode effettivamente sulla chain. Etherscan esegue quel controllo e poi pubblica la fonte.

Ciò che questo stabilisce è ristretto e importante: il codice che sta leggendo è il codice che verrà eseguito. Elimina la possibilità che un progetto abbia pubblicato una cosa e ne abbia distribuita un'altra, il che è una forma di frode reale e storicamente comune.

Ciò che non stabilisce è che il codice faccia qualcosa di ragionevole. Un contratto verificato può contenere una funzione di mint illimitata, un proprietario che può mettere in pausa tutti i trasferimenti, una commissione che può essere alzata al cento per cento, o una funzione che trasferisce i token di tutti a un unico indirizzo. Tutto ciò è perfettamente verificabile e perfettamente ostile.

Quindi "verificato su Etherscan" è diventata una domanda di sicurezza di primo ordine in tutto l'ecosistema, posta da persone che non hanno mai letto Solidity, e risponde a una domanda considerevolmente più ristretta di quanto pensino. È una condizione preliminare per giudicare un contratto, non un giudizio.

I proxy, e leggere il codice sbagliato

La maggior parte dei contratti significativi oggi sono proxy. L'indirizzo con cui interagisce è un guscio sottile e permanente che delega tutta la logica a un contratto di implementazione separato, e quell'implementazione può essere sostituita da chiunque detenga il permesso di aggiornamento.

Questo pattern esiste per buone ragioni — i bug possono essere corretti, le funzionalità aggiunte — e cambia fondamentalmente la domanda di sicurezza. Il codice che audita oggi non è necessariamente il codice che gira domani.

Un explorer naïve le mostra il proprio bytecode del proxy, che è circa quaranta righe di boilerplate di delega e non le dice assolutamente nulla. Etherscan rileva i pattern di proxy comuni, risolve l'implementazione, e offre un interruttore "Read as Proxy". Diversi concorrenti non lo fanno, e il fallimento è silenzioso: sta guardando codice reale, verificato, e trae una conclusione sul contratto sbagliato.

Le domande da porsi sono chi può aggiornare, e se c'è un timelock. Un aggiornamento controllato da un unico conto a proprietà esterna senza ritardo significa che una chiave compromessa cambia tutto. Un aggiornamento controllato da un multisig con un timelock di quarantotto ore significa che le persone hanno un avviso.

Entrambi gli arrangiamenti sono visibili sull'explorer, nelle funzioni di amministrazione del proxy e nell'indirizzo del proprietario. Se il proprietario sia un multisig o una chiave singola è esso stesso leggibile — un multisig ha codice di contratto, una chiave singola no.

Privilegi del proprietario: le funzioni che contano

Se non legge nient'altro in un contratto, legga le funzioni protette da un controllo di proprietario o admin. È lì che risiede il potere.

Mint. Possono essere creati nuovi token dopo la distribuzione, e da chi? Una funzione di mint illimitata detenuta da un unico indirizzo significa che l'offerta è qualunque cosa quell'indirizzo decida, quando lo decide. Questo è il meccanismo dietro una gran parte dei collassi di token.

Pausa o blacklist. Possono essere fermati i trasferimenti, in generale o per indirizzi specifici? Le stablecoin legittime hanno questo e lo usano per conformarsi a ordini legali, il che è difendibile. Un meme token che lo ha è una proposta interamente diversa.

Aggiustamento delle commissioni. Può essere cambiata una commissione di trasferimento dopo il lancio? Un contratto con una commissione che parte da zero e può essere alzata al novantanove per cento è una trappola con una miccia ritardata.

Trasferimento arbitrario. Un indirizzo privilegiato può spostare token che non possiede? Raro, inequivocabile, e squalificante.

Nessuno di questi è automaticamente malevolo. Il contesto decide. Una stablecoin regolamentata ha bisogno della capacità di congelare; un token comunitario che afferma di essere decentralizzato no. Il punto è sapere quali esistono prima di impegnare fondi piuttosto che dopo.

L’approvazione che sta davvero concedendo

La maggior parte delle perdite non derivano dalla logica propria di un contratto. Derivano dalle approvazioni, e l'approvazione è la cosa che firma davvero.

Quando usa un exchange decentralizzato, concede al suo contratto il permesso di spostare un token specifico dal suo indirizzo. Quel permesso è di solito illimitato in importo e illimitato in durata, e persiste finché non lo revoca — molto dopo che ha dimenticato che il protocollo esistesse.

Due anni dopo, quel protocollo viene sfruttato. L'exploit non ha bisogno di rompere il suo portafoglio; ha solo bisogno di usare un permesso che ha già concesso. Le persone che perdono denaro sono spesso quelle che hanno interagito una volta, anni prima, e non ci hanno mai più pensato.

Il prompt del portafoglio le dice cosa sta approvando, e quasi nessuno lo legge. I due campi che contano sono lo spender — quale contratto viene autorizzato — e l'importo. Molti portafogli ora le permettono di impostare un importo finito piuttosto che illimitato, e il piccolo costo extra di approvare per transazione ne vale la pena per qualsiasi cosa di cui non si fidi pienamente.

Sia Etherscan che BscScan hanno verificatori di approvazioni di token che elencano ogni approvazione attiva su un indirizzo e le permettono di revocare. Controllare trimestralmente è l'abitudine di sicurezza più preziosa disponibile su qualsiasi chain EVM, e le approvazioni sono per chain, quindi ogni rete richiede un controllo separato.

Una sequenza pratica prima di interagire

Questo richiede circa tre minuti e coglie la maggior parte di ciò che è colgibile senza leggere Solidity.

Inizi confermando l'indirizzo del contratto contro la documentazione propria del progetto o i suoi account social verificati. Non il nome mostrato in un portafoglio, non un link da un messaggio — l'indirizzo, da una fonte che il progetto controlla. Nomi e simboli sono arbitrari e liberamente riutilizzabili, e l'usurpazione è l'attacco più comune di tutti.

Poi apra quell'indirizzo su un explorer e controlli che sia verificato. Non verificato non è automaticamente malevolo — molti contratti legittimi sono non verificati, particolarmente su chain più piccole — ma significa che si sta fidando senza la capacità di controllare.

Controlli se è un proxy e, se lo è, risolva l'implementazione. Legga l'indirizzo del proprietario e stabilisca se è un multisig o una chiave singola.

Scorra la lista delle funzioni per le operazioni privilegiate sopra. Non ha bisogno di capire l'implementazione; ha bisogno di sapere se la funzione esiste.

E quando appare il prompt del portafoglio, legga lo spender e l'importo. Quel prompt è l'ultimo punto in cui tutto ciò è reversibile.

Da cosa non la proteggerà

Essere onesti sui limiti di un controllo di tre minuti conta più che fingere che sia sufficiente.

Non troverà un bug logico sottile. Gli audit professionali li mancano, ripetutamente, e leggere un contratto su un explorer non è un audit. Ciò che trova è la categoria ovvia — le funzioni che permettono a qualcuno di prendere tutto, dichiarate chiaramente nel codice.

Non le dirà se un progetto è economicamente solido, se la sua tesoreria è reale, o se le persone dietro esso intendono rimanere. Quelle sono domande a cui la chain non può rispondere.

E non aiuterà sulle chain senza questo strumentario. L'intero approccio descritto qui è specifico per EVM. Su Cardano gli asset nativi sono oggetti di registro senza alcun meccanismo di approvazione affatto. Su Sui i package si pubblicano con informazioni di tipo e si aggiornano esplicitamente. Su Solana la domanda equivalente è quale programma possiede un conto e quale autorità delegata esiste.

Il principio generale si trasferisce anche dove la meccanica non lo fa: scopra cosa la cosa con cui sta per interagire è autorizzata a fare, prima di autorizzarla.