Il problema della doppia spesa e i registri distribuiti

Perché un pagamento digitale richiede una cronologia condivisa

Un file digitale può essere copiato senza rimuovere l'originale. Questo è utile per documenti e fotografie, ma crea un problema se il file è destinato a rappresentare un valore scarso. Immaginiamo che un conto possa spendere un'unità una sola volta. Se due istruzioni incompatibili rivendicano entrambe quella stessa unità, limitarsi a confermare che ciascuna istruzione sembra autentica non permette di stabilire quale debba essere considerata valida. Questo è il problema della doppia spesa: la possibilità di usare lo stesso valore disponibile in più di una transazione in conflitto. La questione riguarda la coerenza dei registri, non necessariamente un furto o una frode intenzionale; due transazioni possono entrare in conflitto accidentalmente, ad esempio quando un software ritrasmette un pagamento usando parametri diversi.

In un sistema di pagamento tradizionale, un operatore autorizzato del registro determina normalmente l'ordine in cui vengono elaborate le istruzioni. L'operatore verifica lo stato del conto, rifiuta un'istruzione che supererebbe il saldo disponibile e conserva il registro ufficiale. Un registro distribuito, invece, mantiene i record su più computer, spesso gestiti da soggetti diversi. Questi computer sono comunemente chiamati nodi. Se possono ricevere messaggi in ordini diversi, hanno bisogno di un modo per concordare quali transazioni siano valide e su un ordinamento compatibile di tali transazioni. Questo problema di accordo è il punto di partenza del consenso blockchain.

Un esempio di transazioni in conflitto

Supponiamo che un registro indichi che un output del valore di dieci unità non è stato speso. Il titolare invia la transazione A, assegnando quell'output al destinatario Uno. Prima che tutti i partecipanti alla rete abbiano elaborato A, il titolare trasmette anche la transazione B, assegnando lo stesso output al destinatario Due. Ogni transazione può essere sintatticamente ben formata, ma entrambe non possono diventare effettive come spese separate dell'output originale. Nodi diversi possono ricevere A e B in ordine opposto a causa dei ritardi di rete. Una rete che accettasse semplicemente il primo messaggio ricevuto da ciascun computer rischierebbe di mantenere cronologie incoerenti.

Un progetto affidabile separa quindi due decisioni. La convalida determina se una transazione proposta rispetta le regole del protocollo, dato un determinato stato del registro. Il consenso determina quale cronologia i partecipanti considerano accettata quando competono proposte apparentemente valide. Una volta che il registro accetta A, B entra in conflitto con lo stato risultante e non dovrebbe essere accettata anch'essa come spesa dello stesso output. I dettagli variano tra i sistemi che tracciano output distinti non spesi e quelli che mantengono saldi dei conti e contatori delle transazioni. Il principio comune è che una transizione di stato non può consumare due volte la stessa autorità di spesa.

L'ordine conta tanto quanto l'autenticità

L'autorizzazione è solo uno degli elementi che concorrono alla decisione. Una firma può indicare che un'istruzione è stata autorizzata secondo lo schema crittografico applicabile, ma da sola non stabilisce che i fondi siano ancora disponibili quando l'istruzione viene elaborata. Allo stesso modo, un timestamp fornito dal mittente non stabilisce necessariamente l'ordine ufficiale della rete. I moduli successivi approfondiranno chiavi e firme. Per ora, ricordate la distinzione: una transazione deve essere sia autorizzata sia coerente con lo stato del registro accettato. Il consenso fornisce una base comune per valutare tale stato tra computer indipendenti.

Cosa rende distribuito un registro

Un registro distribuito è un insieme condiviso di record replicati, sincronizzati o altrimenti coordinati tra più partecipanti. I nodi non memorizzano necessariamente informazioni identiche in ogni istante. Alcuni possono essere temporaneamente offline, alcuni possono ricevere i messaggi lentamente e altri possono mantenere copie specializzate o viste parziali. Ciò che conta è che le regole offrano ai nodi partecipanti un modo per convergere verso uno stato o una cronologia coerenti, nel rispetto delle ipotesi del sistema. Una blockchain è una forma di registro distribuito in cui i record sono raggruppati in blocchi ordinati collegati crittograficamente. Non tutti i registri distribuiti utilizzano blocchi e non tutte le blockchain consentono una partecipazione senza restrizioni.

Il progetto di una rete determina anche chi può proporre aggiornamenti, chi può verificarli e i messaggi di chi contribuiscono al consenso. Le reti aperte e senza autorizzazioni generalmente ammettono i partecipanti senza che un amministratore li registri individualmente. Le reti con autorizzazioni possono identificare i validatori e applicare regole di governance all'appartenenza. Entrambe devono comunque affrontare questioni di coordinamento, sebbene le minacce, i requisiti prestazionali e le forme di responsabilità siano diversi. Il NIST Interagency/Internal Report 8202, Blockchain Technology Overview, descrive le blockchain come registri distribuiti e a prova di manomissione, mentre ISO 23257:2022 offre un'architettura di riferimento per i sistemi blockchain e altri sistemi di registro distribuito.

L'accordo non equivale alla verità

Il consenso può stabilire che un insieme di nodi ha accettato un determinato record, ma non può provare che ogni affermazione del mondo reale contenuta in quel record sia vera. Se un documento afferma che un container è arrivato ieri, il registro può conservare quando l'affermazione è stata registrata e come è stata approvata; non può ispezionare il container fisico. Analogamente, registrare rivendicazioni di proprietà non risolve di per sé il diritto sottostante. Per il personale giuridico e della pubblica amministrazione, questa distinzione evita l'errata convinzione che un database replicato generi automaticamente prove affidabili di eventi avvenuti al di fuori della rete.

Cosa possono verificare autonomamente i nodi

Un nodo completo di convalida applica il set di regole della rete agli aggiornamenti proposti invece di fidarsi di chi li propone. Spesso può verificare se un blocco usa la struttura richiesta, se le transazioni rispettano le regole di transizione dello stato e se la cronologia proposta è collegata correttamente. Non può verificare autonomamente fatti provenienti da organizzazioni esterne, a meno che il protocollo non preveda un metodo separato e affidabile per accertarli. Un osservatore potrebbe vedere diversi nodi concordare, senza accorgersi che si sono tutti basati sullo stesso rapporto esterno errato. L'accordo tra computer e la verifica indipendente di fatti fisici sono controlli diversi.

Obiettivi di progettazione e compromessi inevitabili

L'accordo distribuito deve tenere conto dei ritardi nei messaggi, delle interruzioni temporanee della rete e dei partecipanti che inviano messaggi errati o in conflitto. Un'interruzione di rete si verifica quando gruppi di nodi non riescono a comunicare normalmente tra loro. Un partecipante guasto o malevolo può proporre dati non validi, trattenere messaggi o inviare affermazioni diverse a peer diversi. I meccanismi di consenso stabiliscono regole per continuare a operare nonostante alcune di queste condizioni, ma nessun meccanismo garantisce progressi ininterrotti in ogni possibile scenario di guasto. Un progetto deve basarsi su ipotesi riguardanti la connettività, il comportamento dei partecipanti, le risorse disponibili e i ritardi accettabili.

Tre obiettivi pratici aiutano a inquadrare le valutazioni. La coerenza significa che i partecipanti non accettano indefinitamente cronologie ufficiali incompatibili. La disponibilità significa che gli utenti legittimi possono ancora inviare ed elaborare record quando il sistema opera come previsto. La verificabilità significa che gli operatori possono spiegare perché una transizione di stato è stata accettata e riprodurre i controlli pertinenti. Questi obiettivi dipendono dall'architettura e dalla governance, non dalla sola parola blockchain. Le affermazioni secondo cui un registro sarebbe semplicemente «decentralizzato», «immutabile» o «istantaneo» sono incomplete se non specificano chi convalida, quali condizioni di guasto si presuppongono e quando una voce è considerata definitiva.

Uno scenario istituzionale concreto

Consideriamo un'agenzia pubblica che coordina il rilascio di permessi elettronici con altre agenzie. Due uffici inviano aggiornamenti in conflitto sullo stato di un permesso. Un registro condiviso può aiutarli a concordare la sequenza registrata delle modifiche autorizzate e a conservare una traccia verificabile dei conflitti rifiutati. Tuttavia, non può stabilire quale ufficio avesse l'autorità giuridica sostanziale, a meno che tale autorità non sia espressa in politiche documentate e regole di autorizzazione applicabili. I progettisti devono decidere se le istituzioni note gestiranno nodi, cosa accade se un operatore non è disponibile e quale istituzione può correggere un'affermazione errata tramite una nuova voce visibile.

In questo scenario potrebbe essere appropriato anche un database standard amministrato in base a un accordo chiaro. Il valore del consenso distribuito aumenta quando operatori indipendenti hanno effettivamente bisogno di uno stato condiviso senza affidarsi a un singolo soggetto che effettua gli aggiornamenti. È più difficile giustificare i costi operativi aggiuntivi quando un'unica autorità controlla già ogni decisione. ISO 22739:2024, Blockchain and distributed ledger technologies — Vocabulary, è un riferimento utile per una terminologia coerente, ma non sostituisce l'esame delle effettive ipotesi di fiducia del progetto.

Riepilogo rapido

Cosa dovrebbero ricordare i discenti

Il problema della doppia spesa spiega perché copiare un valore rappresentato digitalmente non equivale a spenderlo validamente. I sistemi distribuiti affrontano il problema tramite la convalida e l'accordo su una sequenza o uno stato condivisi. Il consenso stabilisce quali record in conflitto la rete accetta; non accerta la verità di tutti i fatti menzionati in quei record né elimina ogni guasto operativo. Nelle lezioni successive esamineremo le strutture dei dati e le regole che rendono possibile questo coordinamento, anziché tornare alle categorie generali di asset introdotte nel Modulo 1.

Focus d'esame: Spiegare perché la sola autenticità non può impedire una doppia spesa; distinguere la convalida dal consenso e riconoscere che una blockchain è un tipo di registro distribuito, non un sinonimo di tutti i database condivisi.

Note sulle fonti

Riferimenti pertinenti: NIST IR 8202 (2018), Blockchain Technology Overview; ISO 22739:2024, Blockchain and distributed ledger technologies — Vocabulary; e ISO 23257:2022, Blockchain and distributed ledger technologies — Reference architecture.