Perché la sicurezza dei contratti intelligenti è diversa da quella del normale software?

La sicurezza degli smart contract è diversa perché il codice è pubblico, spesso custodisce direttamente denaro e di solito non può essere modificato dopo la distribuzione. Un errore in un'applicazione web può essere corretto in una notte; un errore in un contratto può essere scoperto da chiunque legga il codice e sfruttato prima che il team si svegli. Ethereum.org stima che le perdite dovute a difetti negli smart contract superino il miliardo di dollari e cita l'attacco alla DAO del 2016 come uno dei primi esempi.

Consideriamo uno studio immaginario di quattro persone, Larkspur Labs, che sta creando un semplice fondo di risparmio comune in cui i membri versano denaro e ritirano la propria quota. Lo sviluppatore, Kofi, lascia alcune note di revisione prima della distribuzione: 'withdraw invia i fondi e poi imposta il saldo a 0. setFee è pubblica, limiterò l'accesso più avanti. uso una vecchia versione del compilatore presa dal tutorial. prezzo del token di ricompensa letto da un unico piccolo pool di scambio. test: provato deposito + prelievo una volta a mano, funziona'. Ogni riga corrisponde a una categoria nota di vulnerabilità.

Quali sono le vulnerabilità più comuni dei contratti intelligenti?

Le vulnerabilità più comuni dei contratti intelligenti sono le falle nel controllo degli accessi, la manipolazione degli oracoli di prezzo, gli errori logici, la mancata convalida dei dati in ingresso e la rientranza, che occupano i primi posti della OWASP Smart Contract Top 10 per il 2025. Ethereum.org tratta le stesse categorie principali.

Rientranza

Un contratto invia fondi o chiama un altro contratto prima di aggiornare i propri dati. Un destinatario malevolo richiama il contratto mentre risulta ancora il vecchio saldo e preleva di nuovo. La funzione di prelievo di Kofi, che eroga i fondi prima di azzerare il saldo, è l'esempio classico. La soluzione abituale è aggiornare prima lo stato e interagire con gli altri contratti solo alla fine, secondo la sequenza spesso chiamata controlli, effetti, interazioni.

Controllo degli accessi

Funzioni sensibili che chiunque può chiamare. La funzione pubblica setFee di Kofi permette a qualsiasi estraneo di modificare la commissione. Ethereum.org descrive modelli come un ruolo di proprietario, l'accesso basato sui ruoli e l'approvazione multifirma.

Overflow e underflow degli interi

Un calcolo aritmetico che, superato il proprio limite, riparte dall'estremo opposto, trasformando un saldo sotto zero in un numero enorme. Ethereum.org segnala che Solidity 0.8.0 e versioni successive impediscono questo comportamento per impostazione predefinita, mentre il codice più vecchio richiede controlli espliciti: ecco perché il vecchio compilatore di Kofi è rilevante.

Manipolazione dell'oracolo

Leggere un prezzo da un unico mercato poco liquido che un attaccante può manipolare, spesso con un prestito lampo, contratto e rimborsato nella stessa transazione. Le soluzioni robuste usano oracoli decentralizzati o prezzi mediati nel tempo.

Errori di logica e di convalida

Regole che non corrispondono alla progettazione prevista o dati in ingresso che non vengono mai controllati, come un importo pari a zero o un indirizzo inatteso.

Come fanno i team a testare e verificare gli smart contract?

I gruppi di lavoro verificano e sottopongono a revisione i contratti intelligenti su più livelli, perché nessun metodo rileva tutto: test automatizzati, strumenti di analisi, distribuzione su una rete di prova, revisione indipendente e, per i contratti che custodiscono valori significativi, una verifica esterna e un programma di ricompense per la segnalazione di vulnerabilità.

1. Test unitari e basati sulle proprietà

Scrivi test per ogni funzione, inclusi casi ostili come un destinatario che richiama la funzione durante l'esecuzione. Il fuzzing prova automaticamente migliaia di input casuali.

2. Analisi statica

Ethereum.org cita strumenti come Slither, Mythril e Aderyn, che analizzano il codice alla ricerca di schemi noti per essere rischiosi.

3. Metti alla prova le reti

Distribuisci su una rete di prova pubblica prima di passare alla rete principale. Ethereum.org consiglia Sepolia per lo sviluppo di applicazioni e contratti; gli ether della rete di prova non dovrebbero avere alcun valore reale, quindi gli errori non costano nulla.

4. Revisione tra pari e librerie sottoposte ad audit

Usa il controllo delle versioni, revisori indipendenti per ogni modifica e librerie sottoposte a verifiche approfondite, come OpenZeppelin Contracts, anziché scrivere da zero il controllo degli accessi.

5. Audit, ricompense per la segnalazione di vulnerabilità e monitoraggio

Gli audit indipendenti aggiungono un livello di verifica ma, come osserva ethereum.org, non individuano tutti i bug. I programmi di ricompensa per la segnalazione di bug, le funzioni di pausa d’emergenza e il monitoraggio degli eventi coprono i rischi residui.

Come si presenta una verifica di sicurezza debole rispetto a una migliorata?

Revisione debole: 'Deposito e prelievo testati manualmente, tutto funziona, pronto per la distribuzione.' Una prova del percorso senza imprevisti dimostra che il contratto funziona per gli utenti onesti, cosa che gli aggressori non sono affatto.

Revisione migliorata: Rientranza: ora withdraw azzera il saldo prima dell’invio e un test usa un contratto destinatario ostile per tentare una chiamata di rientro. Controllo degli accessi: setFee è limitata a un ruolo di proprietario fornito da una libreria sottoposta ad audit, con un test che verifica il fallimento della chiamata di un estraneo. Compilatore: aggiornato a una versione 0.8 recente, così i controlli di overflow sono attivi. Oracolo: il prezzo ricavato da un singolo pool è stato sostituito da un flusso di prezzi decentralizzato, con un limite di plausibilità per le variazioni improvvise. Test: test unitari, una sessione di fuzzing e un’analisi statica con una spiegazione di ogni risultato, poi due settimane su Sepolia con un collega che cerca di mettere in crisi il contratto. Audit esterno prenotato prima di accettare fondi reali.

Quali sono gli errori più comuni nella sicurezza dei contratti intelligenti?

L'errore più comune è testare solo lo scenario ideale, come se chiunque chiamasse il contratto fosse onesto. Altri errori: lasciare aperte le funzioni di amministrazione pensando di limitarle in seguito, copiare il codice di una guida usando un compilatore obsoleto, fidarsi di un'unica fonte di prezzo, considerare una verifica come una garanzia, saltare la fase sulla rete di prova e distribuire il contratto senza un piano per sospenderlo o aggiornarlo.

Dove si colloca questa lezione in Tosheo.ai?

Questa è una lezione di programmazione della categoria Blockchain e del corso sulla blockchain. Questa pagina gratuita spiega ogni passaggio a parole; la versione pratica completa, in cui esamini e correggi il codice di contratti reali ed esegui test su una rete di prova, è disponibile nel percorso facoltativo di programmazione dopo l'iscrizione. Se non conosci le basi, inizia dalla spiegazione dei contratti intelligenti. Tosheo.ai non è un corso intensivo a tempo pieno né una qualifica per revisori professionisti, e nessun contenuto costituisce un consiglio di investimento; i contratti che custodiscono valore reale richiedono una verifica specialistica.

Fonti e ambito

ethereum.org, sicurezza dei contratti intelligenti (verificato il 19 October 2026) ↗

OWASP: i 10 principali rischi dei contratti intelligenti, 2025 (verificato il 19 October 2026) ↗

ethereum.org, reti e reti di prova (verificato il 19 October 2026) ↗