---
title: "Smart contract"
description: "Scopri cos'è uno smart contract, come viene eseguito dai nodi, dove intervengono dati esterni e poteri di aggiornamento e cosa verificare prima di interagire."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Smart contract
> 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:
1. Gli sviluppatori scrivono e testano il codice sorgente, lo compilano quando richiesto dalla piattaforma e distribuiscono il programma risultante tramite una transazione.
2. La distribuzione assegna al programma un identificatore o indirizzo on-chain e può inizializzarne lo stato e i ruoli amministrativi.
3. Un utente, un'applicazione o un altro contratto invia una chiamata con selettore di funzione, parametri e talvolta asset.
4. 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.
5. 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
- [Ethereum](/it/crypto/ethereum/)
- [Ethereum Virtual Machine](/it/crypto/evm/)
- [Audit del contratto](/it/crypto/contract-audit/)
- [Oracolo](/it/crypto/oracle/)
- [Contratto proxy](/it/crypto/proxy-contract/)
## Fonti
- [Panoramica della tecnologia blockchain](https://doi.org/10.6028/NIST.IR.8202) - NIST (consultato: 2026-08-21)
- [Introduzione agli smart contract](https://ethereum.org/developers/docs/smart-contracts/) - Ethereum.org (consultato: 2026-08-21)
- [Considerazioni sulla sicurezza](https://docs.soliditylang.org/en/latest/security-considerations.html) - Solidity documentation (consultato: 2026-08-21)
Source: https://wiki.fcontext.com/it/crypto/smart-contract/index.mdx