Nella sesta puntata della serie “Alla Scoperta di Bitcoin” Giacomo Zucco esplora i concetti di dimostrazione della proprietà, smart contracts e Coinjoins.
Questa è la sesta puntata della serie “Alla scoperta di Bitcoin: una breve panoramica dagli uomini delle caverne alla Lightning Network” del bitcoiner Giacomo Zucco.
Leggi l’introduzione alla serie, alla scoperta di Bitcoin parte 1: a proposito del tempo, alla scoperta di Bitcoin parte 2: a proposito delle persone, alla scoperta di Bitcoin parte 3: introduzione al denaro, alla scoperta di Bitcoin parte 4: una svolta sbagliata (serve un nuovo piano) e alla scoperta di Bitcoin parte 5: scarsità digitale.
Nella sesta parte di questa serie “Alla scoperta di Bitcoin”, ci baseremo sull’idea di utilizzare i puzzle digitali come un modo per riprodurre la scarsità e sull’importanza di un meccanismo di controllo dell’offerta per garantire una certa durezza alla moneta digitale, per esplorare i concetti di dimostrazione della proprietà attraverso firme e script e sulla tecnica nota come Coinjoin.
Dimostrare la proprietà: le firme
Il nostro Piano B per il denaro ci riporta a concentrarci sul tema delle persone e sulla domanda “Chi?”.
Ora abbiamo stabilito le condizioni per la produzione di nuovi bitcoin, ma che dire del loro trasferimento? Chi è autorizzato a modificare i dati del bilancio condiviso, trasferendone la proprietà?
Se ci fosse un’autorità centrale incaricata di riassegnare i sats, seguendo le istruzioni degli attuali proprietari (magari loggati al sistema con il classico approccio username-and-password), ci sarebbe di nuovo un singolo punto di fallimento vulnerabile a Mario.
Perché allora preoccuparsi di passare dall’oro fisico alla “scarsità digitale” basata su PoW? Se, invece, ogni utente avesse lo stesso diritto di riassegnare la proprietà, il sistema non funzionerebbe affatto. Ognuno sarebbe incoraggiato ad assegnare continuamente a se stesso i sats degli altri. È dunque necessario un qualche tipo di protocollo coerente che definisca l’autorità e che tutti possano verificare in modo indipendente.
La soluzione è una tecnica crittografica chiamata “firma digitale”. Funziona così: per prima cosa, Alice sceglie un numero casuale chiamato “chiave privata”, che manterrà assolutamente segreto. Poi passa questo numero attraverso una speciale funzione matematica, facile da applicare in una direzione ma praticamente impossibile da invertire. Il risultato è un altro numero, chiamato “chiave pubblica”, che Alice non tiene affatto segreto: si assicura invece che Bob lo conosca. Infine, fa passare la chiave privata e il messaggio attraverso una seconda funzione, di nuovo difficile da invertire, che dà come risultato un numero molto grande chiamato “firma”.
Una terza e ultima funzione matematica può essere applicata da Bob al messaggio, alla firma e alla chiave pubblica di Alice, ottenendo una verifica positiva o negativa. Se il risultato è positivo, Bob sapra’ che Alice ha autorizzato il messaggio, che non potrà in seguito negare tale autorizzazione e che il messaggio non è stato alterato durante il transito.
In un certo senso, è simile alle firme autografe, che sono facili da verificare rispetto a un campione pubblico, ma difficili da riprodurre senza essere in possesso della firma corretta. Oppure ai sigilli in ceralacca: facili da verificare rispetto a un registro pubblico di sigilli, ma difficili da riprodurre senza il corretto stampino in ceralacca.
Quindi, si cambia il protocollo per poter rendere riutilizzabili le piccole frazioni risultanti dalla prova di lavoro tramite firme digitali. Il primo modello implementato è banale: ogni utente genera autonomamente una chiave privata e crea un “account” pubblico, etichettato con la chiave pubblica corrispondente. Quando gli utenti vogliono trasferire la proprietà, creano un messaggio che include il loro account, l’account ricevente e la quantità di sats che vogliono trasferire. Quindi firmano digitalmente e trasmettono il messaggio, che tutti possono verificare.
È interessante notare che uno schema simile può essere usato da sviluppatori pseudonimi per firmare diverse versioni del loro software in modo che possano liberamente cambiarlo, migliorarlo, correggerlo, aggiornarlo, controllarlo e rivederlo, e ogni utente finale può verificare in modo indipendente tali firme prima di eseguire la versione che preferisce, sfruttando una rete di fiducia ridotta al minimo e frammentata, senza la necessità di una singola autorità che distribuisca il software a livello centrale. Questo processo consente una vera decentralizzazione del codice.
Script e smart contracts
Non si vuole però limitare le condizioni che ogni peer deve verificare, prima di accettare qualsiasi modifica al bilancio condiviso, alla sola validità della firma digitale.
Si decide quindi che ogni messaggio può includere anche uno “script”: un elenco di istruzioni che descrivono ulteriori condizioni che il conto ricevente dovrà soddisfare per poter spendere di nuovo. Ad esempio, il mittente potrebbe richiedere una combinazione di più chiavi segrete o uno specifico tempo di attesa prima di spendere. Partendo da queste primitive molto semplici, si possono costruire contratti intelligenti (noti come smart contracts) complessi, rendendo il denaro effettivamente “programmabile”, anche in assenza di parti centrali.
Problemi di oscurità (e scalabilità)
A differenza di un sistema di messaggistica criptata, il vostro schema non è pero’ ottimizzato per l’oscurità di cui abbiamo parlato in precedenza. Il denaro circola e I beneficiari non possono fidarsi di alcun trasferimento di denaro se non possono verificare che i sats trasferiti siano stati effettivamente trasferiti a quello specifico pagatore, e così via, a monte, fino alla prima emissione basata su PoW.
Con una circolazione sufficiente di sats, i peer attivi verrebbero a conoscenza di un numero enorme di transazioni passate e si potrebbero utilizzare tecniche di analisi forense per correlare statisticamente importi, tempistiche, metadati e conti, de-anonimizzando così molti utenti e privandoli della loro negabilità.
Questo aspetto è problematico, come discusso nella Parte 2, l’oscurità è una qualità fondamentale per il denaro, sia per ragioni economiche che sociologiche. E gli smart contract peggiorano ulteriormente questo problema, poiché particolari condizioni di spesa possono essere utilizzate per identificare particolari implementazioni software o specifiche politiche organizzative.
Questa mancanza di oscurità è più grave di quella che ha colpito il vostro precedente esperimento di e-gold: È vero che allora memorizzavate la maggior parte dei metadati delle transazioni sui vostri server centrali, ma almeno eravate solo voi, e non letteralmente chiunque (compresi gli agenti del malvagio Mario), ad avervi accesso!
C’è anche un piccolo problema di scalabilità legato a questo progetto: le firme digitali sono piuttosto grandi, e la catena di trasferimenti che un beneficiario deve ricevere per convalidare tutto includerebbe molte firme, rendendo la convalida potenzialmente molto costosa. Inoltre, le modifiche al conto sono molto difficili da convalidare in parallelo.
Un nuovo paradigma: il Modello UTXOs
Per mitigare tali problemi, si decide di cambiare le entità fondamentali del modello da “conti” simili a quelli di una banca a un modello di “output di transazioni non spese” (UTXO).
Invece di istruzioni per spostare sats da un conto all’altro, ogni messaggio ora include un elenco di UTXO vecchie, provenienti da transazioni passate e “consumate” come ingredienti, e un elenco di UTXO nuove, “generate” come prodotti e pronti per transazioni future.
Invece di pubblicare una singola chiave pubblica statica da usare come riferimento generale del conto (come un IBAN o un indirizzo e-mail), Bob deve quindi fornire nuove chiavi pubbliche per ogni pagamento che vuole ricevere. Quando Alice lo paga, firma un messaggio che “sblocca” alcuni sats da una UTXO precedentemente creato e li “blocca” in una nuova UTXO.
A condizione che le persone non riutilizzino le chiavi per pagamenti diversi, questo sistema aumenta l’oscurità di per sé. E quando gli utenti iniziano a capire che le UTXO consumate e generate da una singola transazione non devono necessariamente provenire da due sole entità! Alice può creare un messaggio che spende le vecchie UTXO che controlla e genera nuove UTXO (associate a Bob), quindi può passare il messaggio a Carlo, che può semplicemente aggiungere le sue vecchie UTXO che vuole consumare e le nuove UTXO (associati a Daniele) che vuole creare. Infine, Alice e Carlo firmano e trasmettono il messaggio composito (pagando sia Bob che Daniele).
I Coinjoin
Questo uso speciale del modello UTXO è chiamato “CoinJoin”. (Attenzione: Nella storia reale di Bitcoin, questo uso non era la logica di progettazione di Satoshi per il modello UTXO stesso, ma è stato scoperto come una potenziale svolta su tale progetto da altri sviluppatori, molti anni dopo il lancio). Si rompe la collegabilità statistica tra gli output, pur preservando la cosiddetta “atomicità”.
Le transazioni sono del tutto valide o non valide, quindi Alice e Carlo non devono fidarsi l’uno dell’altro.
C’è una possibile modifica al sistema che potrebbe migliorare ulteriormente la situazione: uno schema di firma digitale diverso da quello attuale, che sia “lineare nelle firme”. Ciò significa che prendendo due chiavi private (che non sono altro che due numeri), firmando lo stesso messaggio con ciascuna di esse e sommando le firme risultanti (che non sono altro che due numeri molto grandi), il risultato è la firma corretta corrispondente alla somma delle due chiavi pubbliche associate alle due chiavi private iniziali!
Sembra complicato, ma l’implicazione è semplice: Alice e Carlo, al momento della CoinJoining, potrebbero sommare le loro firme individuali e trasmettere solo la somma, che tutti potrebbero verificare con la somma delle loro chiavi pubbliche!
Poiché, come abbiamo detto, le firme sono la parte più “pesante” delle transazioni, la possibilità di trasmetterne solo una firma invece che molte farebbe risparmiare molte risorse. Gli osservatori esterni finirebbero per sospettare che ogni transazione sia una Coinjoin, poiché molti utenti potrebbero essere alla ricerca di aumento di efficienza. Questa supposizione romperebbe la maggior parte delle euristiche forensi.
Un Sistema Scalabile e Oscuro
Anche senza questo ulteriore miglioramento, il modello UTXO aumenta già in qualche modo la scalabilità: A differenza dei cambiamenti di stato nel modello dell’account, consente di eseguire la convalida in modo efficiente in batch e in parallelo.
Finora avete imparato:
- che è possibile decentralizzare la proprietà utilizzando le firme digitali per il trasferimento;
- che è possibile trasformare le transazioni in “contratti” programmabili con un sistema di script; e
- che un paradigma più complesso chiamato Coinjoin può aumentare ulteriormente l’oscurità e la scalabilità.
- Ma ora che gli utenti possono emettere sats e trasferirli in modo completamente decentralizzato, come possono essere tutti sicuri che venga seguita un’unica cronologia, impedendo attacchi di double-spending o tentativi di manipolare il calendario dell’inflazione?
Risponderemo a questa domanda nella nostra ultima puntata, “alla scoperta di Bitcoin parte 7: i Pezzi Mancanti”.
Tradotto dall’originale scritto per Bitcoin Magazine