Solo a scopo educativo; non è consulenza finanziaria. Le transazioni con smart contract possono causare perdite irreversibili.
Risposta diretta
Uno smart contract è un programma distribuito su una blockchain o su una rete di esecuzione distribuita simile. Contiene codice e, su molte piattaforme, uno stato persistente. Una transazione o un altro contratto può chiamarne le funzioni; i nodi eseguono le stesse regole e accettano il cambiamento di stato risultante mediante la validazione e il consenso della rete.
“Smart” non significa che il programma comprenda le intenzioni e “contract” non lo rende automaticamente un accordo legalmente vincolante. Il termine descrive codice capace di applicare condizioni specifiche entro le funzioni e i dati disponibili nel suo ambiente di esecuzione.
Gli smart contract possono:
- detenere o trasferire asset digitali secondo condizioni programmate;
- registrare e aggiornare lo stato di un’applicazione; e
- combinarsi con altri contratti per creare borse, sistemi di prestito, giochi, strumenti di governance e altre applicazioni on-chain.
La loro prevedibilità si limita al codice implementato e agli input. Un contratto può funzionare esattamente come scritto e produrre comunque un risultato indesiderato per un difetto, un progetto malevolo, privilegi compromessi o dati esterni errati.
Come funziona
Un’interazione tipica segue questi passaggi:
- Gli sviluppatori scrivono e testano il codice sorgente, lo compilano quando richiesto dalla piattaforma e distribuiscono il programma risultante tramite una transazione.
- La distribuzione assegna al programma un identificatore o indirizzo on-chain e può inizializzarne lo stato e i ruoli amministrativi.
- Un utente, un’applicazione o un altro contratto invia una chiamata con selettore di funzione, parametri e talvolta asset.
- Ogni nodo validatore esegue la chiamata secondo le stesse regole della macchina virtuale e del protocollo. Se una condizione necessaria fallisce, la chiamata può essere annullata, ma la commissione può comunque essere addebitata.
- Se la chiamata riesce ed è inclusa dalla rete, i cambiamenti di stato e gli eventi emessi entrano nel registro della blockchain.
L’esecuzione è deterministica soltanto per le informazioni disponibili nel contesto concordato. Un contratto non può recuperare autonomamente da internet meteo, prezzo di mercato o pagamento bancario. Le applicazioni che richiedono fatti off-chain usano oracoli, messaggi firmati, bridge od operatori privilegiati, aggiungendo ipotesi di fiducia e guasto esterne al codice.
Il codice distribuito non è sempre l’intero sistema. Alcuni contratti sono immutabili, mentre proxy e governance possono inoltrare le chiamate a nuova logica o modificare parametri. Occorre quindi esaminare chiavi di aggiornamento, poteri amministrativi, controlli di pausa, disegno dell’oracolo e contratti collegati, oltre all’interfaccia visibile.
Prima di firmare, verifica:
- la rete e l’indirizzo completo del contratto tramite una fonte indipendente e affidabile;
- la funzione decodificata, i parametri, le quantità di asset e il destinatario;
- le autorizzazioni sui token o i permessi di operatore creati dalla chiamata;
- se il contratto è verificato, aggiornabile, sospeso o controllato da account privilegiati; e
- che, quando pratico, una piccola prova copra il percorso previsto di ingresso e uscita.
Esempio
Consideriamo un contratto di deposito a garanzia per un servizio digitale. L’acquirente deposita 1,000 USDC e il contratto registra acquirente, venditore, importo e condizione di regolamento. Se l’acquirente approva la consegna, il contratto rilascia i fondi al venditore. Se la condizione non è soddisfatta entro 24 ore, diventa disponibile il rimborso programmato.
Il contratto non sa se il servizio è stato soddisfacente, a meno che il progetto non gli fornisca questo fatto. Se l’approvazione dipende dalla chiave dell’acquirente, una chiave compromessa può autorizzare il rilascio. Se decide un oracolo o un amministratore, quella parte entra nel modello di fiducia. Anche un errore nel controllo degli accessi o nella gestione del token può vanificare la regola. L’esecuzione automatica riduce il lavoro manuale, ma non elimina la valutazione di ogni dipendenza.
Rischi e controlli
- Difetti del codice: rientranza, contabilità errata, chiamate esterne non sicure o casi limite possono perdere o bloccare asset. Preferisci progetti piccoli e ben testati e controlla il codice distribuito, non solo un marchio di audit.
- Rischio di privilegi e aggiornamento: un amministratore può sospendere il sistema, sostituire la logica, cambiare commissioni o spostare asset. Verifica chi controlla ogni ruolo, l’uso di timelock o multifirma e cosa può cambiare.
- Rischio di oracolo e integrazione: codice corretto può agire su dati obsoleti, manipolati o scalati male; guasti a token, bridge o altri contratti possono propagarsi tramite la composizione.
- Rischio di transazione e autorizzazione: un’interfaccia malevola può mostrare indirizzo, funzione, destinatario o autorizzazione illimitata errati. Decodifica la richiesta e limita i permessi al necessario.
- Rischio del disegno economico: transazioni valide possono comunque provocare liquidazioni, manipolazioni di prezzo, fallimento degli incentivi o corsa a liquidità limitata. La correttezza del codice non equivale a solvibilità economica.
- Rischio operativo: congestione, riorganizzazioni della catena, guasti del sequencer o front-end non disponibili possono ritardare un’azione pur con il contratto distribuito.
- Irreversibilità: le transazioni su catene pubbliche in genere non prevedono storno. Se i fondi passano dalla funzione sbagliata o a un contratto ostile, recuperarli può essere impossibile.
Un audit è una prova relativa a una versione e a un ambito definiti, non una garanzia. Controlla che bytecode o sorgente verificato corrispondano alla versione esaminata e se aggiornamenti, dipendenze o configurazioni successive siano fuori ambito.
Idee sbagliate comuni
- “Il codice si esegue automaticamente senza transazione.” La maggior parte delle funzioni che cambiano stato richiede una transazione o un’altra chiamata on-chain; le azioni temporizzate possono richiedere un esecutore esterno.
- “Il codice non può cambiare.” Un contratto immutabile non riscrive il proprio bytecode distribuito, ma proxy, governance e migrazioni possono cambiare la logica raggiunta dagli utenti.
- “Il codice pubblico è sicuro.” La visibilità aiuta la revisione, ma non dimostra correttezza, amministrazione onesta o solidità economica.
- “Un audit garantisce sicurezza.” Le revisioni hanno limiti temporali e di ambito, possono omettere difetti o escludere rischi operativi ed economici.
- “Una transazione riuscita significa che è avvenuta l’azione voluta.” Il successo indica solo che il codice non è stato annullato; vanno ancora verificati destinazione, eventi, movimenti di asset e permessi risultanti.
Argomenti correlati
Fonti
- Panoramica della tecnologia blockchain - NIST (consultato: 2026-08-21)
- Introduzione agli smart contract - Ethereum.org (consultato: 2026-08-21)
- Considerazioni sulla sicurezza - Solidity documentation (consultato: 2026-08-21)