Come le blockchain raggiungono il consenso · Lezione 2 di 5
Blocchi, hash e catena
8 min di lettura
Dalle singole transazioni ai blocchi
In genere, una blockchain non chiede a ogni nodo di accordarsi su ciascuna transazione come se fosse un record permanente del tutto separato. Le transazioni vengono invece organizzate in gruppi chiamati blocchi, con regole che descrivono come i blocchi vengono proposti, verificati e collegati. Un blocco non è soltanto una pagina di un registro elettronico. È una struttura di dati definita dal protocollo, che contiene o impegna le transazioni e riporta informazioni usate per collegare il blocco alla cronologia precedente. I campi esatti variano da un sistema all'altro. Alcuni protocolli separano i dati di esecuzione da quelli di consenso; altri usano un'intestazione del blocco relativamente compatta, seguita dalle transazioni.
Per comprendere la catena, occorre distinguere il contenuto delle transazioni, un impegno sintetico e un puntatore alla cronologia precedente. Una transazione descrive una modifica richiesta dello stato del registro. Un hash crittografico è un output di lunghezza fissa prodotto a partire da dati di input da un algoritmo definito. Un blocco può includere un hash o un impegno correlato all'insieme delle transazioni; in genere, l'intestazione fa riferimento a un predecessore tramite un hash. Collegare i record in questo modo rende rilevabile una modifica non dichiarata, perché i dati alterati cambiano il relativo impegno con probabilità schiacciante, in base alle ipotesi di sicurezza della funzione hash.
A cosa serve un hash crittografico
Una funzione hash crittografica converte informazioni di lunghezza arbitraria in un digest di dimensione fissa. Per esempio, SHA-256 genera un digest di 256 bit. SHA-256 è specificato nella pubblicazione FIPS 180-4, Secure Hash Standard, del National Institute of Standards and Technology. Il digest non è una cifratura: non contiene un segreto che possa essere sbloccato per recuperare l'input originale. Un hash, inoltre, non certifica chi ha creato un documento. È utile per confrontare informazioni e rilevare modifiche, a condizione che sia implementato correttamente e che venga usato un algoritmo appropriato. Le diverse blockchain utilizzano algoritmi e combinazioni più specializzati.
Una buona funzione hash crittografica è progettata in modo che sia computazionalmente impraticabile trovare un messaggio diverso che produca lo stesso digest, o risalire dal digest a un messaggio originale scelto. Si tratta di proprietà di sicurezza, non di impossibilità matematiche assolute. Se l'input cambia anche solo leggermente, il relativo digest apparirà di solito del tutto diverso. Pertanto, un nodo che conosce l'impegno corretto può rilevare se il corpo di un blocco è stato sostituito o modificato. Questa rilevazione, da sola, non identifica la persona responsabile della modifica e non dimostra che il contenuto originale fosse corretto.
Un puntatore hash è più di un semplice collegamento
Un puntatore in un database convenzionale indica dove trovare un altro record. Un puntatore hash combina un riferimento a un record precedente con un valore che impegna al contenuto atteso di quel record. Consideriamo i blocchi A, B e C. Il blocco B registra un hash che fa riferimento ad A; C fa riferimento a B. Se qualcuno modifica A, il digest atteso da B non corrisponde più. Correggere il riferimento di B ne modifica il contenuto e interrompe quindi il riferimento di C. Questa dipendenza si estende ai blocchi successivi. Nei protocolli reali, un attaccante che desidera sostituire la cronologia accettata deve anche soddisfare le regole di consenso applicabili, non soltanto ricalcolare gli hash.
Intestazioni, corpi e impegni alle transazioni
Molte strutture di blocco hanno un'intestazione contenente metadati compatti e un corpo con transazioni o altre informazioni di esecuzione. In Bitcoin, l'intestazione include l'hash del blocco precedente, una radice di Merkle che riassume le transazioni, un timestamp, la codifica del target di difficoltà, una versione e un nonce. Un nonce è un campo che può essere variato nel tentativo di ottenere una prova di lavoro valida. Questo elenco di campi è un esempio, non un requisito universale per le blockchain. I sistemi moderni possono usare alberi di impegno diversi, firme, attestazioni dei validatori o strutture di payload separate.
Un albero di Merkle riassume una raccolta di record usando una gerarchia di hash. I valori foglia si impegnano ai singoli elementi; i valori intermedi si impegnano a combinazioni di elementi; il valore in cima è chiamato radice di Merkle. Questa struttura può supportare una prova di inclusione: un insieme compatto di hash che dimostra che un particolare elemento appartiene alla raccolta a cui si impegna la radice. Le prove di inclusione aiutano a ridurre la quantità di dati necessaria per alcune verifiche, ma non sostituiscono tutti i controlli eseguiti da un nodo completo, come la verifica che la transazione sia stata autorizzata e che non esista una spesa in conflitto.
Ordine e serializzazione sono regole del protocollo
Un nodo non può calcolare l'hash di una descrizione vaga come «Alice ha pagato Bob». Deve calcolare l'hash di una sequenza precisa di byte in un formato specificato. Questo processo è detto serializzazione: la rappresentazione di informazioni strutturate come byte secondo regole pubblicate. L'ordine dei campi, la codifica dei numeri e altri dettagli sono importanti. Se due nodi serializzano lo stesso record concettuale in modo diverso, i loro hash possono differire. Il consenso dipende quindi da più della sola robustezza della crittografia: richiede anche definizioni deterministiche della codifica valida, dell'ordine delle transazioni ove applicabile, dei limiti dei blocchi e delle modifiche di stato prodotte da ciascuna transazione.
Prova di manomissione e immutabilità
È comune descrivere le blockchain come immutabili. In un corso introduttivo, «rilevanti in caso di manomissione» e «resistenti alla manomissione» sono espressioni più precise. I collegamenti hash fanno emergere le modifiche non autorizzate a una catena registrata, mentre i meccanismi di consenso rendono difficile sostituire la cronologia accettata, in base alle ipotesi dichiarate. Nessuna delle due caratteristiche rende la cronologia metafisicamente impossibile da modificare. Fork, riorganizzazioni, aggiornamenti del protocollo e violazioni delle ipotesi di sicurezza di una rete possono influire sulla catena accettata. Anche i documenti legali possono richiedere modifiche; un sistema può conservare le voci precedenti e aggiungere voci correttive senza sovrascriverle di nascosto.
Una questione progettuale importante riguarda ciò che viene memorizzato on-chain. Memorizzare un impegno hash a un documento off-chain può consentire ai revisori di verificare in seguito se è stato presentato lo stesso documento. Ciò non significa che il documento stesso sia disponibile sulla blockchain, e un hash da solo potrebbe non costituire una prova legalmente sufficiente di paternità, identità o consenso. Per gli impieghi nel settore pubblico, i requisiti di conservazione, i dati sensibili e la disponibilità dei documenti di origine possono essere più importanti dell'eleganza della struttura di impegno. Gli hash sono componenti fondamentali preziosi, ma la gestione dei documenti istituzionali richiede controlli aggiuntivi.
Come verificano un blocco proposto i nodi
Un nodo che riceve un blocco candidato esegue in genere più livelli di controlli. Valuta la struttura dei dati e la codifica di base, verifica il riferimento al predecessore, controlla la presenza delle prove di consenso richieste e testa le transazioni rispetto alle regole di transizione di stato del protocollo. In una rete basata sulla prova di lavoro, verifica anche la prova dell'intestazione rispetto a un target. In una rete proof-of-stake, può controllare l'autorizzazione del proponente e i voti o le attestazioni pertinenti. Queste operazioni sono specificate con precisione in ciascun protocollo; la semplice presenza di un hash dall'aspetto valido non è mai sufficiente per dichiarare accettabile un blocco.
Il requisito relativo al predecessore spiega anche perché scaricare un blocco isolato non equivale a stabilire uno stato del registro affidabile. La convalida dipende dal contesto: le regole precedenti, i saldi o gli output non spesi e la catena selezionata dalla rete. Un client leggero può ottenere prove di inclusione senza eseguire autonomamente tutte le transazioni; questa comodità può comportare ipotesi di fiducia diverse. Responsabili e revisori dovrebbero distinguere tra l'affermazione «questa transazione è comparsa in un blocco» e l'affermazione «la cronologia della rete, convalidata integralmente, accetta questo trasferimento». La seconda richiede ulteriore contesto e una politica di conferma definita.
Contesto di governance e divulgazione
La struttura tecnica è una parte della documentazione più ampia del sistema. La norma ISO 23257:2022 descrive componenti funzionali e relazioni per i sistemi di registro distribuito. Le regole di divulgazione in alcune giurisdizioni (per esempio, i requisiti dell'UE per i white paper sulle cripto-attività) chiedono agli emittenti di descrivere la tecnologia sottostante, ma tali obblighi non prescrivono un'unica struttura universale dei blocchi né rendono sicuro un particolare algoritmo hash. Ciò illustra perché una descrizione tecnica e una divulgazione legale rispondono a domande diverse: la prima spiega come funziona un protocollo; la seconda stabilisce quali informazioni devono essere comunicate in un contesto regolamentato.
Riferimento rapido
| Componente | Scopo principale |
|---|---|
| Transazione | Descrive una modifica di stato richiesta |
| Hash o impegno alla radice | Rileva modifiche ai dati a cui ci si è impegnati |
| Riferimento al blocco precedente | Collega un blocco alla cronologia precedente |
| Prova di consenso | Supporta l'accettazione secondo le regole del protocollo |
Cosa dovrebbero ricordare gli studenti
I blocchi sono gruppi strutturati o impegni disciplinati da regole del protocollo. Gli hash crittografici creano impronte digitali compatte e collegano la cronologia dipendente; rilevano le modifiche, ma non stabiliscono l'identità né la verità dei fatti. Funzioni hash robuste, serializzazione deterministica, convalida completa e un meccanismo di consenso operano insieme. La lezione successiva esamina un metodo con cui una rete rende costoso modificare la catena accettata: la prova di lavoro. Le chiavi e le firme digitali sono trattate separatamente nel Modulo 3.
Focus d'esame: Identificare i ruoli di un'intestazione del blocco, di un hash crittografico, di un riferimento al predecessore e di un impegno alle transazioni; spiegare perché i collegamenti hash forniscono una prova di manomissione anziché un'immutabilità incondizionata.
Note sulle fonti
Riferimenti pertinenti: NIST FIPS 180-4 (2015), Secure Hash Standard; NIST IR 8202 (2018), Blockchain Technology Overview; ISO 23257:2022, Reference architecture.