Blocco serializzato

La serializzazione è il modo in cui un blocco astratto diventa qualcosa su cui puoi calcolare un hash, che puoi inviare e conservare. Il blocco genesi si serializza in 285 byte: 80 per l'intestazione, 1 per il conteggio delle transazioni e 204 per la sua unica transazione coinbase. Se hai mai incollato esadecimale grezzo in un block explorer o eseguito getblock con verbosity 0, è proprio questo che stavi guardando.

Come funziona

In un blocco serializzato ci sono tre parti una dopo l'altra, e solo la prima ha una lunghezza fissa.

L'intestazione occupa sempre 80 byte, in questo ordine: una versione di 4 byte, l'hash di 32 byte dell'intestazione precedente, la radice di Merkle di 32 byte, un timestamp di 4 byte, la codifica del target nBits di 4 byte e un nonce di 4 byte. Poi viene il numero di transazioni, scritto in compactSize, un intero a lunghezza variabile che occupa 1 byte per conteggi inferiori a 253 e fino a 9 byte per qualsiasi valore enorme. Infine le transazioni stesse, ciascuna serializzata per intero, con la coinbase per prima.

Dal BIP144 lo stesso blocco ha due serializzazioni valide. La forma stripped esclude del tutto i witness ed è quella che il software precedente al 2017 si aspetta. La forma completa li include, contrassegnando ogni transazione che porta witness con un byte 0x00 seguito da un flag 0x01 dove altrimenti starebbe il conteggio degli input. Entrambe codificano lo stesso blocco ed entrambe producono lo stesso hash del blocco, perché l'hash copre solo quegli 80 byte dell'intestazione e la radice di Merkle al loro interno impegna gli ID delle transazioni, che sono calcolati dalla codifica stripped. Quella separazione è il significato letterale di segregated witness.

Un'abitudine coglie tutti almeno una volta: gli interi su più byte sono scritti little endian, quindi il timestamp 0x495FAB29 appare sulla rete come 29 ab 5f 49, e gli hash sono mostrati nell'ordine inverso rispetto al loro ordine di byte serializzato. Un hash del blocco che copi da un explorer non è la sequenza di byte che sta nel file.

Dove lo vedi

I blocchi serializzati viaggiano sulla rete peer-to-peer dentro un messaggio block. Ogni messaggio porta prima un involucro di 24 byte: una stringa di avvio di 4 byte, f9beb4d9 sulla mainnet, un nome di comando di 12 byte, una lunghezza del payload di 4 byte e un checksum di 4 byte preso dai primi quattro byte di un doppio SHA-256 sul payload. Bitcoin Core limita il payload di ogni singolo messaggio a 4.000.000 byte, un limite della rete e non del consenso.

Gli stessi byte finiscono sul tuo disco. Bitcoin Core aggiunge i blocchi a file chiamati blk00000.dat e successivi, ciascuno limitato a 128 MiB, con la stessa stringa di avvio e un prefisso di lunghezza prima di ogni blocco, così che il file possa essere scansionato in modo lineare. Il blocco genesi è l'eccezione: è compilato nel software come costante anziché scaricato, ed è questo che lo rende l'ancora rispetto a cui un nodo in sincronizzazione misura tutto il resto.

Nell'uso quotidiano la serializzazione emerge tramite getblock con verbosity 0, tramite la scheda raw o hex della maggior parte degli explorer e dentro gli strumenti che ti permettono di decodificare un blocco a mano. Chi verifica che un explorer gli abbia detto la verità finisce qui, perché l'esadecimale è l'unica rappresentazione che nessuno ha riformattato.

Blocco serializzato vs blocco

Un blocco è l'oggetto; un blocco serializzato è una sua codifica. La distinzione era cosmetica fino al 2017, quando SegWit ha dato a ogni blocco due codifiche valide di lunghezza diversa, così la dimensione di un blocco è diventata una domanda che richiede una precisazione. Bitcoin Core risponde in tre modi in un'unica risposta RPC: size per la serializzazione completa, strippedsize per quella senza witness e weight per il numero che le regole applicano davvero.