Uno smart contract è un programma che vive su una blockchain ed esegue le regole scritte nel codice, senza che un intermediario possa fermarlo o riscriverlo in corsa. Sembra una piccola cosa; in realtà cambia il punto: non più «fidati di chi gestisce il sistema», ma «verifica le regole, che valgono per tutti». In questo articolo vedi come funzionano, dove rendono davvero e dove sono lo strumento sbagliato — con i costi che chi li propone raramente mette nel preventivo.

Un programma che nessuno può spegnere

Un’applicazione aziendale classica gira su un server: chi amministra il server può modificarla, sospenderla, spegnerla. Uno smart contract, una volta pubblicato su una rete, viene eseguito dai nodi secondo le stesse regole per chiunque lo invochi. Nessun amministratore ha un interruttore.

Questo è il punto di forza e, come vedremo, anche il rischio strutturale. L’assenza di un interruttore significa che le regole valgono per tutti, incluso chi le ha scritte.

Gas: perché ogni istruzione ha un prezzo

Ogni operazione di uno smart contract consuma «gas», un’unità che misura il costo computazionale e si paga in criptovaluta. Non è un dettaglio da sviluppatori: è il meccanismo che impedisce a un programma mal scritto o malintenzionato di bloccare la rete con un ciclo infinito. Quando finisce il gas, l’esecuzione si ferma.

La conseguenza pratica è che il codice va scritto frugale: ogni variabile in più costa a ogni esecuzione, e la progettazione diventa un esercizio di essenzialità. Se vuoi vedere come si ragiona a monte di questi sistemi, la documentazione per sviluppatori di Polygon mostra i vincoli reali, non quelli della brochure.

I casi in cui rendono davvero

Gli smart contract funzionano quando la regola è precisa e il valore si muove insieme all’evento. Quattro esempi concreti:

  • Escrow: il pagamento resta bloccato fino all’avverarsi di una condizione, e nessuna delle parti può ritirarlo prima.
  • Pagamento a consegna verificata: il vettore registra l’avvenuta consegna e il contratto rilascia il fondo al fornitore, senza fatture da inseguire.
  • Royalty automatici: ogni rivendita di un’opera versa la quota all’autore, perché la regola è dentro il token, non in una promessa.
  • Documenti di filiera: certificati e verbali registrati on-chain con la loro impronta, verificabili da chiunque a distanza di anni.

Un avvertimento onesto: quando la condizione arriva dal mondo esterno — una consegna, una temperatura, un prezzo — serve un «oracolo» che porti il dato sulla catena. L’affidabilità del sistema diventa allora quella dell’oracolo. È il punto più delicato di molti progetti, e va progettato, non dato per scontato.

Il rovescio: il codice resta, gli errori pure

L’immutabilità taglia in due sensi. Un contratto pubblicato non si corregge: se c’è un errore, resta. Il settore l’ha imparato a proprie spese, a partire dall’hack del DAO nel 2016, quando un difetto in un contratto permise di drenare fondi in grande scala e forzò la comunità a una scelta drammatica.

Da allora le pratiche di scrittura sono diventate più severe, e si sono diffusi pattern di aggiornamento che separano logica e dati. Ma ogni meccanismo di upgrade reintroduce un pizzico di fiducia in chi controlla l’aggiornamento: è un compromesso da progettare a occhi aperti, non una bacchetta magica.

Per questo esiste l’audit

Un audit pre-deployment è la lettura ostile del codice: un revisore cerca logica sbagliata, casi limite, vettori d’attacco, e prova a rompere il contratto prima che lo faccia qualcun altro. Non garantisce la perfezione — nessuno onesto lo promette — ma porta alla luce la maggior parte dei difetti quando correggerli costa ancora poco.

È pratica standard per i contratti che muovono valore, e dovrebbe esserlo anche per quelli che registrano impegni vincolanti. La sicurezza complessiva comunque non finisce lì: chiavi, server e procedure umane contano quanto il codice, come spieghiamo nella guida all’infrastruttura digitale sicura per le PMI.

Quando proprio no

Se il processo vive dentro una sola azienda, se le regole cambiano ogni trimestre, se serve discrezionalità umana su ogni singolo caso, lo smart contract è il martello sbagliato. Bastano un’API, un’integrazione tra sistemi, a volte un foglio di calcolo ben fatto.

La prima fase del nostro metodo si chiama Diagnosi proprio per questo: arriva a un no onesto quando c’è. I contesti in cui invece la catena regge sono descritti in questo sguardo d’insieme sulla blockchain per le imprese; e in ogni scelta di piattaforma vale lo stesso principio: prima gli obiettivi, poi lo strumento.

Se un contratto entrerà nei tuoi processi, noi lo scriviamo e lo passiamo all’audit prima del lancio: lo consideriamo parte del lavoro, non un extra. Il perimetro di cosa sviluppiamo — chain EVM, Solana, integrazioni — è nella pagina del servizio blockchain di Netcat.

Il codice giusto, verificato prima del lancio

Uno smart contract sbagliato non si aggiorna in corsa: si previene. Netcat sviluppa smart contract su chain EVM e li mette sotto audit prima del deployment, così quello che va in rete è quello che hai approvato in revisione.

Parla con NetcatScopri il servizio blockchain

Continua il percorso

Dalla meccanica alle decisioni di impresa:

Domande frequenti

Di chi è lo smart contract una volta pubblicato?

Dipende da come è progettato. Un contratto può prevedere funzioni di amministrazione, cederle a più firme contemporanee (multisig) o rinunciarci del tutto. È una decisione di governance da prendere prima della scrittura, non dopo l’incidente.

Si può correggere un bug dopo il lancio?

Non direttamente: il contratto resta com’è. Esistono pattern proxy che separano logica e dati e permettono aggiornamenti, al prezzo di complessità e di un nuovo punto di fiducia. La strada economica resta la prevenzione: revisione e audit prima del deployment.

Serve per forza una rete pubblica?

No. Le catene compatibili EVM esistono in versione pubblica e privata: la scelta dipende da chi deve verificare e da quanto devono restare riservati i dati. Si parte dal processo, non dalla rete del momento.