Una blockchain può rendere verificabile una registrazione senza dimostrare che il fatto registrato sia vero. È la distinzione da capire prima di attribuirle sicurezza, trasparenza o risparmi automatici. Un dato inserito correttamente nel registro può provenire da una fonte sbagliata; un file richiamato dalla catena può diventare irreperibile.
Questa guida spiega che cosa sono blocchi, consenso e permessi, e come valutare un utilizzo concreto. Distingue il funzionamento del registro dal prezzo di una criptovaluta e propone un esempio originale sui costi di un progetto. Non presenta un investimento, una piattaforma raccomandata o una certificazione di sicurezza.
Illustrazione editoriale originale generata con IA per BorsaMagazine: elementi ceramici collegati e foglio simbolico, non una rete reale o una visualizzazione di dati.
Che cos’è una blockchain e che rapporto ha con la DLT
Una blockchain è un registro digitale condiviso nel quale le registrazioni sono raggruppate in blocchi collegati crittograficamente. I partecipanti seguono regole per verificare gli aggiornamenti e concordare la storia accettata. NIST distingue il registro dalla rete che lo utilizza e descrive meccanismi che rendono le alterazioni rilevabili e difficili. Fonte: introduzione NIST alla blockchain.
DLT significa distributed ledger technology, tecnologia a registro distribuito. La blockchain è un tipo di DLT, non il nome di ogni database condiviso. L’approfondimento della BCE descrive il passaggio da un registro centrale a copie distribuite fra partecipanti, con possibilità di lettura e aggiornamento dipendenti dai permessi. Fonte: spiegazione della BCE.
Non basta dunque copiare un foglio su più computer per ottenere tutte le caratteristiche di una blockchain. Chiedi quali regole stabiliscano la validità degli aggiornamenti, chi possa proporli e come vengano gestite versioni incompatibili. La struttura dei dati e l’organizzazione dei partecipanti sono entrambe parte del problema.
Blocchi, hash e consenso: tre funzioni da distinguere
I blocchi raccolgono operazioni e includono riferimenti crittografici alla storia precedente. La documentazione Ethereum descrive sia l’ordinamento dei blocchi sia quello delle transazioni al loro interno. È un esempio di implementazione, non la prova che ogni rete abbia gli stessi tempi o gli stessi limiti. Fonte: documentazione sui blocchi.
Un hash è un’impronta calcolata dai dati. Il glossario NIST ne descrive le proprietà nel contesto delle funzioni crittografiche: può servire a confrontare un contenuto con l’impronta attesa. Non va confuso con il file originale o con una dichiarazione sulla sua veridicità. Fonte: NIST, hash function.
Il consenso comprende protocolli, incentivi e criteri che permettono ai nodi di accordarsi sullo stato. La documentazione Ethereum precisa che proof-of-work e proof-of-stake sono componenti del meccanismo, insieme, fra l’altro, alle regole di scelta della catena. Non è semplicemente “la maggioranza dei computer decide tutto”. Fonte: meccanismi di consenso.
Su mobile scorri orizzontalmente la tabella.
| Elemento | Funzione | Limite da ricordare |
|---|---|---|
| Blocco | Raggruppa e collega registrazioni secondo il protocollo | Il contenuto va comunque verificato secondo le regole applicabili |
| Hash | Permette controlli sull’integrità di un contenuto | Non certifica da solo autore, significato o verità del fatto |
| Consenso | Coordina l’accettazione dello stato fra partecipanti | Non sostituisce il controllo delle fonti esterne |
| Applicazione | Presenta informazioni e prepara richieste operative | La schermata non coincide con tutto il registro |
Pubblica o permissioned: chi può partecipare e chi decide
In una rete permissionless l’accesso ai ruoli previsti è aperto secondo le regole del protocollo. Una rete permissioned stabilisce invece criteri di ammissione e identità dei partecipanti. Lettura, proposta degli aggiornamenti e validazione sono permessi da verificare separatamente: non basta un’unica etichetta “pubblica” o “privata”.
Hyperledger Fabric è un esempio documentato di piattaforma permissioned: descrive identità, politiche di validazione e componenti configurabili. La sua architettura può operare senza una criptovaluta nativa che remuneri mining o esecuzione. Questo mostra perché adottare un registro distribuito non implichi automaticamente comprare un token. Fonte: documentazione ufficiale Fabric.
La governance resta una domanda concreta: chi approva un aggiornamento, modifica le regole, ammette un nuovo soggetto o interviene quando un partecipante non è disponibile? Una rete con molti nodi può dipendere da poche organizzazioni o servizi comuni. Il numero delle copie, da solo, non misura tutta la distribuzione del potere.
“Immutabile” non significa impossibile da modificare in ogni circostanza
NIST usa i concetti di resistenza alle alterazioni e possibilità di rilevarle. È una descrizione più precisa di una promessa assoluta. Le condizioni del protocollo, il coordinamento dei partecipanti e il modello di sicurezza contano; anche lo stato vicino alla testa della catena va interpretato secondo le regole della rete.
Nel caso Ethereum, la documentazione sul consenso descrive criteri di scelta fra blocchi concorrenti. Non estendiamo quel meccanismo a ogni infrastruttura. Prima di trattare una registrazione come definitiva, verifica che cosa significhino inclusione, conferma e finalità nel sistema utilizzato, distinguendoli dalla notifica ricevuta dall’app.
Per l’uso specifico di BTC, la guida al Bitcoin approfondisce transazioni, conferme e rischio. Qui il punto è generale: il registro accettato e lo stato di una richiesta ancora in elaborazione non sono la stessa evidenza.
Dati veri e registrazioni integre: il problema degli oracoli
Immagina un sistema che registri la frase “merce consegnata”. La verifica tecnica può dimostrare che una certa registrazione è stata accettata secondo le regole previste. Non permette, da sola, di osservare il magazzino o stabilire se la consegna sia realmente avvenuta. È un esempio logico della redazione, non un incidente attribuito a un’azienda.
Per utilizzare informazioni esterne, gli smart contract possono dipendere da oracoli: componenti che portano dati fuori catena nell’ambiente di esecuzione. Ethereum.org richiama correttezza, aggiornamento e disponibilità della fonte. Se il dato in ingresso è errato, l’esecuzione coerente del codice non corregge automaticamente il mondo esterno. Fonte: documentazione sugli oracoli.
In una verifica pratica cerca la provenienza del dato, chi lo firma o lo trasmette, come vengono risolte le discrepanze e che cosa accade quando la fonte smette di rispondere. Un accordo fra più fornitori può ridurre alcune dipendenze, ma non va presentato come verità garantita senza conoscerne il metodo.
Smart contract e file fuori catena: che cosa rimane da controllare
Uno smart contract è un programma con codice e stato sulla rete. La documentazione Ethereum ne descrive l’esecuzione e il limite nell’accedere autonomamente agli eventi esterni. L’automazione realizza le istruzioni previste: la convenienza o la completezza del processo sono domande ulteriori. Fonte: introduzione agli smart contract.
Se un progetto registra soltanto l’hash di un documento conservato altrove, deve mantenere anche il documento. L’impronta non è una copia recuperabile del suo contenuto. Devi sapere dove si trova il file, quale versione confrontare e chi ne garantisce accesso e conservazione nel tempo. La compatibilità dell’hash non dimostra inoltre, da sola, l’identità dell’autore o i diritti sul documento.
Un’ulteriore distinzione tecnica viene dalla documentazione Ethereum: disponibilità dei dati necessaria alla verifica e possibilità di recuperare informazioni storiche non sono sinonimi. Non promettere quindi conservazione perpetua di qualsiasi file perché compare un riferimento on-chain. Fonte: data availability e data retrievability.
Anche la custodia delle credenziali rimane un livello separato: la guida a cold wallet e hot wallet spiega perché rete, interfaccia e possibilità di autorizzare operazioni vadano distinte. Per valutare una singola applicazione servono poi codice, dipendenze e responsabilità effettive.
Quanto costa un progetto: non guardare soltanto la singola registrazione
Consideriamo un progetto immaginario nel suo primo anno. Ogni documento genera due transazioni; il costo variabile assunto è 0,002 euro per transazione. Sviluppo, integrazione, infrastruttura e verifica dei dati sono le altre voci del modello. Sono cifre inventate, non preventivi commerciali o tariffe di una rete.
Confrontiamo 100.000 e 50.000 documenti effettivamente trattati. Nei due scenari manteniamo fisse le altre voci: è un’ipotesi di capacità e contratti invariati, non una legge sui costi del software. Una transazione è qui un’operazione del registro, un documento è l’unità del processo aziendale; non li contiamo come sinonimi.
Scorri orizzontalmente la tabella per leggere entrambi gli scenari.
| Voce | Scenario A | Scenario B |
|---|---|---|
| Documenti trattati | 100.000 | 50.000 |
| Transazioni, due per documento | 200.000 | 100.000 |
| Sviluppo iniziale | 15.000 | 15.000 |
| Integrazione dei sistemi | 5.000 | 5.000 |
| Infrastruttura, 600 × 12 mesi | 7.200 | 7.200 |
| Verifica dei dati | 4.000 | 4.000 |
| Transazioni a 0,002 euro | 400 | 200 |
| Totale delle voci assunte | 31.600 | 31.400 |
| Costo per documento | 0,316 euro | 0,628 euro |
In A la sola componente delle transazioni è 200.000 × 0,002 = 400 euro, ossia 0,004 euro per documento. Il totale per documento è invece 31.600 ÷ 100.000 = 0,316 euro. Dividere per le transazioni darebbe 0,158 euro per operazione: un denominatore diverso. Non sono due addebiti aggiuntivi da sommare.
Dimezzando i documenti, il costo totale scende di 200 euro, ma quello per documento sale a 0,628 euro perché le voci mantenute fisse pesano su meno unità. Il confronto non dimostra che una blockchain convenga o che un database centrale sia più caro. Mancano un’alternativa misurata e benefici documentati; imposte e costi non elencati sono esclusi. Il progetto reale richiede un preventivo completo e una prova del processo.
Una checklist per leggere una proposta senza fermarsi allo slogan
La seguente scheda è un metodo della redazione. Chiede evidenze concrete, senza assegnare un punteggio universale di sicurezza o un rendimento atteso.
Su mobile la tabella può essere scorsa orizzontalmente.
| Domanda | Evidenza da cercare | Distinzione decisiva |
|---|---|---|
| Che cosa viene registrato? | Schema dei dati, operazioni e riferimenti ai file | Contenuto completo oppure soltanto impronta o collegamento |
| Chi può agire? | Permessi, validazione e regole degli aggiornamenti | Numero dei nodi e soggetti che li controllano |
| Da dove arriva il dato? | Fonti, controlli e gestione delle discrepanze | Integrità della registrazione e verità dell’evento |
| Come continua il servizio? | Conservazione, accesso, incidenti e uscita | Registro disponibile e interfaccia del singolo fornitore |
| Quanto costa il risultato? | Volumi reali, voci di costo e confronto con alternative | Commissione per transazione e costo complessivo del processo |
Lo stesso criterio vale quando si leggono attestazioni finanziarie: una prova limitata va usata per ciò che documenta. La guida alla proof of reserves distingue osservazione delle riserve, passività e solvibilità, senza trasformare un dato on-chain in una garanzia generale.
Domande frequenti
Blockchain e Bitcoin sono la stessa cosa?
No. Bitcoin è un sistema specifico che utilizza una blockchain. Il termine blockchain descrive una struttura di registro e il suo funzionamento va valutato nella rete concreta.
Ogni DLT è una blockchain?
No: blockchain è un tipo di registro distribuito. L’etichetta DLT, da sola, non descrive struttura dei dati, consenso e permessi.
Un hash dimostra che il documento è vero?
Può aiutare a verificare la corrispondenza con un contenuto atteso; non dimostra da solo verità del fatto, identità dell’autore o diritti sul documento.
Una rete con molti nodi è sempre più decentralizzata?
Il conteggio non basta. Verifica soggetti indipendenti, permessi, dipendenze comuni e capacità di modificare le regole.
Serve sempre una criptovaluta?
No. Fabric documenta configurazioni che non richiedono una criptovaluta nativa. Questo non significa che il sistema sia senza costi.
Uno smart contract controlla da solo il mondo esterno?
Non automaticamente. Può dipendere da oracoli e altre componenti: correttezza, disponibilità e aggiornamento dei dati restano da valutare.
Un collegamento on-chain conserva il file per sempre?
No. Se il file è esterno devi verificarne conservazione e accesso. Un hash non è una copia del documento da cui ricostruirlo.
Una commissione minima dimostra convenienza economica?
No. Il modello distingue spesa per transazioni e costo per documento, includendo le altre voci assunte. Servono volumi, alternative e benefici misurati.
Fonti e nota metodologica
Fonti originali consultate il 28 ottobre 2026. L’approfondimento BCE del 2017 è usato per le definizioni, senza trasferirne al presente le valutazioni sull’adozione. Le documentazioni dei progetti descrivono implementazioni specifiche e non sono certificazioni indipendenti. Il modello economico e i casi su documenti e consegne sono elaborazioni ipotetiche della redazione, non misure di mercato, prove eseguite su reti o promesse di risparmio. L’illustrazione è concettuale, senza dati quantitativi.
- NIST — Blockchain: registro, rete e resistenza alle alterazioni.
- BCE — How could new technology transform financial markets?, 19 aprile 2017: definizioni di DLT e blockchain.
- Ethereum.org — Blocks: collegamenti e ordinamento delle operazioni.
- Ethereum.org — Consensus mechanisms: regole, incentivi e scelta della catena.
- Ethereum.org — Oracles: provenienza e disponibilità dei dati esterni.
- Hyperledger Fabric — Introduction: rete permissioned, configurabilità e assenza di un token nativo obbligatorio.
- Ethereum.org — Data availability: verifica dei dati e recupero delle informazioni storiche.
- Ethereum.org — Introduction to smart contracts: programmi, stato e dipendenze esterne.
- NIST CSRC — Hash function: definizioni e proprietà delle impronte crittografiche.