Quando la blockchain risolve un problema reale e quando basta un database
La consulenza blockchain seria comincia da una domanda scomoda: questo progetto ha bisogno di una catena oppure no.
Una blockchain serve a mettere d'accordo più soggetti che non si fidano l'uno dell'altro su un registro che nessuno di loro controlla da solo. Fuori da questa condizione esiste quasi sempre una soluzione più semplice, più veloce e meno costosa da mantenere.
I casi in cui la scelta ha senso sono riconoscibili. La tracciabilità di filiera, quando produttore, trasportatore, certificatore e acquirente devono leggere la stessa storia e nessuno accetta che sia il database di un altro a custodirla. La certificazione di documenti, quando conta poter dimostrare che un file esisteva in una certa forma a una certa data, senza chiedere a un archivio privato di confermarlo. I biglietti e i titoli trasferibili, quando il passaggio da un titolare all'altro deve restare verificabile anche a distanza di anni.
Un database relazionale resta la scelta giusta quando i dati hanno un proprietario unico, quando vanno corretti o cancellati su richiesta dell'interessato, quando servono ricerche rapide su grandi volumi o quando il costo di ogni singola scrittura pesa sul modello economico. In quei casi lo diciamo in fase di valutazione, prima del preventivo, e proponiamo un'architettura tradizionale.
Interventi di sviluppo smart contract, dApp e integrazione wallet
Il perimetro tecnico su cui lavoriamo è ristretto e dichiarato. Preferiamo fare poche cose verificabili.
Smart contract su reti EVM
Scrittura in Solidity di contratti per registri, certificazioni, permessi e trasferimento di diritti, con suite di test automatici e riuso di librerie consolidate al posto di implementazioni scritte da zero.
Interfacce dApp
Sviluppo dell'applicazione web che parla con il contratto: lettura dello stato, invio delle transazioni, gestione degli errori di rete e degli stati di attesa, che su catena durano più a lungo di quanto un utente si aspetti.
Integrazione wallet
Connessione dei portafogli più diffusi, firma delle operazioni, controllo della rete attiva e messaggi chiari su cosa l'utente sta per firmare, senza scorciatoie che nascondano il contenuto della transazione.
Revisione di contratti esistenti
Lettura di codice già scritto contro una lista di vulnerabilità note e di errori di logica applicativa, con relazione scritta dei problemi trovati e del rischio associato. Per i contratti che gestiscono valore consigliamo anche un audit esterno indipendente.
Tokenizzazione di titoli e certificati
Rappresentazione on-chain di un diritto già esistente fuori dalla catena, come un attestato, un biglietto o una quota di accesso, con la parte documentale conservata su storage esterno e solo l'impronta registrata sul registro.
Formazione tecnica interna
Sessioni per team di sviluppo su modello di esecuzione, costi di gas, limiti dell'immutabilità e gestione delle chiavi, con esempi di codice e prove su rete di test.
Sicurezza degli smart contract: immutabilità, costi di gas e chiavi
La differenza rispetto allo sviluppo web ordinario sta tutta in un punto: dopo il rilascio non si corregge in cinque minuti.
Il codice pubblicato su una rete pubblica resta lì. Un errore di logica non si sistema con un aggiornamento notturno e, se il contratto custodisce valore, diventa immediatamente sfruttabile da chiunque legga il sorgente. Esistono schemi di aggiornamento tramite contratto proxy, ma spostano il problema: introducono un ruolo capace di cambiare il comportamento del sistema, e quel ruolo va protetto e dichiarato agli utenti.
Ogni scrittura sulla catena ha un costo di gas che dipende dalla rete, dalla congestione e da come sono strutturati i dati. La scelta di cosa registrare on-chain e cosa lasciare su un archivio esterno va fatta con i numeri davanti: decide il costo di esercizio per anni. Nella maggior parte dei progetti sulla catena finiscono solo l'impronta crittografica e i riferimenti minimi.
Prima del rilascio il codice passa da test automatici, da un deploy su rete di prova con simulazioni di uso reale e da una rilettura riga per riga contro le vulnerabilità classiche: rientranza, controlli di accesso mancanti, dipendenza da fonti di dati esterne, ordine delle operazioni. Per i contratti che muovono valore un audit esterno è denaro speso bene.
Le chiavi private restano il punto più fragile. Chi possiede la chiave possiede il contratto, e non esiste procedura di recupero. Progettiamo i ruoli amministrativi in modo che siano pochi e separati, consigliamo schemi a firma multipla dove il rischio lo giustifica e non conserviamo chiavi private né fondi dei clienti.
Come si sviluppa un progetto blockchain: quattro fasi
La verifica del codice occupa una fase autonoma, con tempi e documentazione propri.
- 01
Valutazione
Analisi del processo da digitalizzare e confronto onesto con l'alternativa senza catena. Il risultato è una nota tecnica con architettura proposta, architettura tradizionale equivalente e stima dei costi di esercizio. Quando la conclusione è che la blockchain non serve, il lavoro si ferma qui e la nota resta al cliente.
- 02
Progettazione
Definizione di cosa va registrato sulla catena e cosa resta fuori, scelta della rete, disegno dei ruoli e dei permessi, stima del gas per le operazioni più frequenti. Qui si decide anche come si comporta il sistema se la rete rallenta o se un utente perde l'accesso al proprio portafoglio.
- 03
Sviluppo e verifica del codice
Implementazione dei contratti con test automatici, deploy su rete di prova e revisione documentata contro le vulnerabilità note. Per i progetti che gestiscono valore si affianca un audit esterno. Il rilascio non parte finché la relazione di verifica non è chiusa.
- 04
Rilascio e consegna
Pubblicazione sulla rete definitiva, verifica del sorgente sull'explorer così che chiunque possa leggerlo, consegna degli indirizzi, della documentazione e delle procedure di custodia delle chiavi. Da quel momento il cliente controlla il proprio sistema.
Web3 in Italia: dove usiamo la catena e dove abbiamo scelto di non usarla
Il modo più diretto per capire quanto siamo prudenti è guardare i prodotti che abbiamo costruito.
DietApp, Beachfy, BarbierItalia e CivitApp sono prodotti dello studio e nessuno dei quattro usa una blockchain. Prenotazioni di ombrelloni, appuntamenti dal barbiere, piani alimentari e comunicazioni di un comune hanno un titolare unico dei dati, richiedono correzioni e cancellazioni frequenti e devono rispondere in fretta: girano su Firebase e su Google Cloud perché è la scelta corretta per quei problemi.
La stessa disciplina l'applichiamo ai progetti dei clienti. In Italia il web3 arriva spesso come richiesta di comunicazione, senza un'esigenza tecnica che la sostenga, e in quel caso il primo risultato utile della consulenza è dire di no. Quando invece i soggetti coinvolti sono davvero più di uno e nessuno accetta di fare da custode, la catena diventa la parte semplice del progetto: il lavoro vero sta nel definire chi può scrivere che cosa.
Domande frequenti su smart contract e consulenza blockchain
Le cinque che riceviamo più spesso, con risposte che non promettono nulla.
Nella maggior parte dei casi no. Serve quando più organizzazioni indipendenti devono condividere un registro e nessuna può fare da custode delle altre, oppure quando un diritto deve restare trasferibile e verificabile senza intermediario. Se il progetto ha un solo proprietario dei dati, un database tradizionale costa meno e fa lo stesso lavoro meglio.
Il contratto in sé non ha un canone: una volta pubblicato resta attivo. I costi ricorrenti sono il gas di ogni scrittura, che varia con la rete e con la congestione, l'accesso a un nodo per leggere lo stato e l'hosting dell'interfaccia web. Senza sapere rete e numero di operazioni previste non è possibile dare una cifra, e diffidiamo di chi la dà subito.
Non direttamente: il codice pubblicato è immutabile. Le strade sono due. Prevedere fin dall'inizio uno schema proxy aggiornabile, che però introduce un ruolo con potere di modifica da proteggere e da dichiarare. Oppure pubblicare un nuovo contratto e migrare lo stato. Entrambe hanno costi, per questo la fase di verifica pesa più che in un progetto web.
Lavoriamo su reti compatibili con la macchina virtuale Ethereum. La rete principale ha i costi più alti e la permanenza maggiore, le reti di secondo livello abbattono il costo per transazione, una rete a partecipazione controllata ha senso quando i soggetti coinvolti sono noti e pochi. La scelta si fa in progettazione, sulla base del valore in gioco e del numero di scritture previste.
Sviluppare e utilizzare smart contract è lecito. L'emissione di token, i servizi sulle cripto-attività e i profili fiscali rientrano però in normative specifiche, europee e nazionali, che cambiano nel tempo. Non forniamo pareri legali né fiscali: il quadro va verificato con un avvocato e con un commercialista prima di avviare il progetto. Il nostro contributo si ferma alla parte tecnica.