Blockchain
Token e smart contract: quando hanno senso per un'attività, e cosa comporta svilupparli bene
Token e smart contract senza promesse: quando un registro condiviso risolve un problema reale, standard ERC, immutabilità e aggiornabilità, audit, oracoli, costi, MiCA e l'esperienza del wallet.
Fabio Folgori5 min di lettura

Token e smart contract sono arrivati con promesse enormi e, in molti progetti, con risultati deludenti. Non perché la tecnologia non funzioni, ma perché è stata usata dove non serviva. Una blockchain è un registro condiviso, verificabile e difficile da modificare. Quando quel profilo risponde a un problema reale, è uno strumento potente; quando non lo fa, è un database lento e costoso.
Il test da fare prima di tutto
Una blockchain ha senso quando valgono insieme queste condizioni:
- più soggetti devono scrivere o verificare lo stesso registro;
- non esiste un soggetto di fiducia che tutti accettino come gestore dei dati;
- la verificabilità pubblica o la resistenza alla censura sono requisiti, non effetti collaterali;
- le regole possono essere espresse in codice deterministico.
Se un'attività gestisce da sola i propri dati, un database con un buon registro delle modifiche fa lo stesso lavoro meglio. Programmi fedeltà, certificati interni e tracciabilità gestita da un solo soggetto rientrano quasi sempre in questo caso.
Token: cosa sono tecnicamente
Su una rete compatibile con EVM, un token è un contratto che tiene un registro di saldi e regole di trasferimento secondo uno standard:
- ERC-20 per token fungibili (unità intercambiabili);
- ERC-721 per token non fungibili, ciascuno unico;
- ERC-1155 per collezioni miste, efficienti quando servono molti tipi di token.
Usare uno standard non è un dettaglio: è ciò che rende il token compatibile con wallet, exchange e strumenti esistenti. Si parte da implementazioni consolidate e verificate, non da zero.
Smart contract: dove si concentra il rischio
Immutabilità
Il codice pubblicato non si modifica. Un errore resta, e se il contratto custodisce valore può essere sfruttato in pochi minuti. I proxy aggiornabili permettono di cambiare la logica, ma reintroducono un soggetto con il potere di farlo: va dichiarato agli utenti e protetto con firme multiple e ritardi.
Sicurezza
Le classi di vulnerabilità sono note: rientranza, controlli di accesso mancanti, errori aritmetici, manipolazione dei prezzi, dipendenza dall'ordine delle transazioni. La difesa è un processo: librerie verificate, test estesi, analisi automatiche, revisione indipendente, rilascio graduale.
Oracoli
Uno smart contract non vede il mondo esterno. Prezzi, eventi, consegne arrivano tramite oracoli, che diventano il punto di fiducia del sistema. Un contratto perfetto con dati in ingresso manipolabili non è sicuro.
Costi di esecuzione
Ogni scrittura costa una commissione (gas), variabile. Il design del contratto incide molto: dati salvati sulla catena solo se indispensabili, il resto fuori, con un riferimento verificabile.
Wallet ed esperienza d'uso
È il punto dove falliscono più progetti rivolti al pubblico. Frasi di recupero, firme di transazioni incomprensibili, commissioni da pagare in una valuta che l'utente non ha. Ogni schermata ha a che fare con il denaro delle persone: la chiarezza dell'interfaccia conta quanto la correttezza del codice. Le soluzioni moderne (account astratti, commissioni pagate dal servizio, accesso con credenziali familiari) riducono l'attrito, ma vanno progettate con cura.
Regole
In Europa il regolamento MiCA disciplina l'emissione di diverse categorie di cripto-attività e i servizi su di esse. Se un token ha valore economico, è trasferibile o è offerto al pubblico, la valutazione legale va fatta prima della progettazione, non dopo.
Come procedere in modo serio
- Il test del registro condiviso, onestamente.
- Una valutazione legale, se il token ha valore.
- Scelta della rete in base a costi, ecosistema, requisiti di privacy.
- Contratti minimi su standard consolidati, con test e audit.
- Interfaccia e wallet progettati per utenti reali, non per addetti ai lavori.
- Piano per incidenti e, se previsto, governance degli aggiornamenti.
Un esempio ragionato
Un consorzio di produttori vuole certificare l'origine dei propri prodotti e permettere al cliente finale di verificarla con un codice sull'etichetta.
- Con un solo soggetto che gestisce i dati (il consorzio stesso), il test del registro condiviso fallisce: un database con registro delle modifiche, firme digitali sui lotti e una pagina di verifica pubblica fa lo stesso lavoro, costa meno ed è più semplice da correggere.
- Con più soggetti indipendenti (produttori, trasformatori, distributori) che scrivono ciascuno la propria parte e non accettano un gestore unico, un registro condiviso inizia ad avere senso. Anche qui, sulla catena si scrive solo l'impronta dei dati e i passaggi di proprietà; documenti e foto restano fuori, con un riferimento verificabile.
In entrambi i casi il problema più difficile non è tecnico: è garantire che ciò che entra nel registro corrisponda alla realtà. Nessuna blockchain verifica un'etichetta applicata al prodotto sbagliato.
Come la vedo io
Ho lavorato al frontend React di VeWorld, il wallet per la rete VeChain che vive come estensione di Chrome, insieme a un team internazionale. È lì che ho capito dove si gioca davvero un progetto blockchain rivolto alle persone: non nel contratto, ma nell'interfaccia che deve spiegare una firma, un saldo, un'operazione irreversibile senza spaventare e senza nascondere nulla.
Per questo, quando un'attività mi chiede un token, la prima cosa che faccio è il test del registro condiviso. Spesso la risposta onesta è che basta un buon gestionale. Quando invece la blockchain serve davvero, va trattata con la serietà del software che muove denaro.
E quando il test fallisce, lo dico senza imbarazzo: è un servizio anche quello.
Perché affidarlo a me
Programmo dal 1999, ho consegnato più di 300 progetti e lavoro come sviluppatore esterno con circa 30 agenzie, da Roma e da remoto. Ho esperienza diretta su interfacce di wallet e progetti blockchain, e ti dico con franchezza se il tuo caso ne ha bisogno.
Se stai valutando token o smart contract, scrivimi: in una chiacchierata di circa 20 minuti facciamo insieme il test del registro condiviso. Il servizio è in Blockchain, token e smart contract.
Domande frequenti
Quando più soggetti che non si fidano pienamente l'uno dell'altro devono condividere un registro che nessuno di loro controlla da solo, e quando la verificabilità pubblica è un requisito. Se c'è un soggetto di fiducia che gestisce i dati, un database è più semplice, economico e veloce.
Il codice pubblicato è immutabile. Si può prevedere un meccanismo di aggiornamento (proxy), che però reintroduce un soggetto con il potere di cambiare le regole: va dichiarato e governato. In entrambi i casi un errore costa molto più che nel software tradizionale.
Per qualunque contratto che custodisce o muove valore, sì. Un audit indipendente, test estesi e analisi automatiche riducono il rischio; nessuno lo elimina del tutto.
Sì. Il regolamento europeo MiCA disciplina l'emissione di alcune categorie di cripto-attività e i servizi su di esse. Se il token ha un valore economico o è offerto al pubblico, serve una valutazione legale prima di progettarlo.
- #smart contract
- #token
- #blockchain
- #wallet
- #sicurezza


