Questo articolo è il nono (e la seconda parte) di una guida al network di Bitcoin, accessibile anche a coloro a digiuno di codice. Questo articolo continua altresì una sorta di approfondimento pensata per entrare gradualmente in quella che molti definiscono “la tana del bianconiglio”.
A livello bibliografico è d’obbligo citare il testo “Mastering Bitcoin” di Andreas Antonopoulos, riferimento costante, dal quale sono state tratte le immagini. Chi fosse interessato ad approfondire questi temi, con o senza integrazione delle dinamiche legate al codice, può trovare supporto nei corsi formativi e nella attività consulenziali erogate da Bcademy.
SPV Nodes
Molti client bitcoin sono progettati per funzionare su dispositivi con limitazioni di spazio e di potenza (smartphone, tablet, etc). Per tali dispositivi viene utilizzato un metodo di verifica dei pagamenti semplificata (SPV) per consentire loro di operare senza memorizzare la blockchain completa. Questi tipi di client sono chiamati client SPV o client leggeri. Con l’aumento dell’adozione di bitcoin, il nodo SPV sta diventando la forma più comune di nodo bitcoin, specialmente per i wallet bitcoin.
I nodi SPV scaricano solo gli header dei blocchi e non scaricano le transazioni incluse in ciascun blocco. La catena risulta 1000 volte più piccola della blockchain completa. I nodi SPV non sono in grado di creare un’immagine completa di tutti gli UTXO disponibili per la spesa poiché non sono al corrente di tutte le transazioni sulla rete. I nodi SPV verificano le transazioni utilizzando una metodologia leggermente diversa che si basa sui peer per fornire viste parziali delle parti rilevanti della blockchain su richiesta.
La “verifica semplificata del pagamento” verifica le transazioni facendo riferimento alla loro profondità nella blockchain anziché alla loro altezza. Mentre un nodo blockchain completo costruisce una catena completamente verificata di migliaia di blocchi e transazioni che raggiungono la blockchain (indietro nel tempo) fino al blocco genesis, un nodo SPV verificherà la catena di tutti i blocchi (ma non tutte le transazioni) e collega tale catena alla transazione di interesse.
Ad esempio, quando si esamina una transazione nel blocco 300.000, un nodo completo collega tutti i 300.000 blocchi al blocco di genesi e crea un database completo di UTXO, stabilendo la validità della transazione confermando che l’UTXO rimane non utilizzato. Un nodo SPV non può validare se l’UTXO non è in uso. Invece, il nodo SPV stabilirà un collegamento tra la transazione e il blocco che la contiene, utilizzando un merkle path.
Quindi, il nodo SPV attende fino a quando vede i sei blocchi da 300,001 a 300,006 posti sopra il blocco contenente la transazione e lo verifica stabilendone la profondità sotto i blocchi da 300,006 a 300,001. Il fatto che altri nodi sulla rete accettassero il blocco 300.000, e il lavoro necessario per produrre altri sei blocchi su di esso è la prova che la transazione non era una doppia spesa.
Un nodo SPV non può essere persuaso che una transazione esiste in un blocco (se non vi è inclusa), ma l’esistenza di una transazione può essere nascosta a un nodo SPV, che può provare che la transazione esiste ma non verificare che, come nel caso di doppia spesa, non esista (perché non ha memoria di tutte le transazioni). Questa vulnerabilità può essere usata in attacchi denial-of-service o di doppia-spesa.
Per contrastare ciò, un nodo SPV si connette casualmente a diversi nodi, per aumentare la probabilità di essere in contatto con almeno un nodo onesto; ciò a sua volta rende il nodo SPV vulnerabile a network partitioning attacks o Sybil attacks, laddove siano connessi a nodi fasulli o reti fasulle e non abbiano accesso a nodi onesti o alla vera rete Bitcoin. Per la maggior parte degli scopi pratici, nodi SPV ben connessi sono abbastanza sicuri, raggiungendo un equilibrio tra utilizzo di risorse, sicurezza e praticità. Posto che i nodi SPV recuperano specifiche transazioni per verificarle selettivamente, creano un rischio di privacy: richiedendo specifici dati possono inavvertitamente rivelare gli indirizzi nei loro wallet (una terza parte monitorante la rete potrebbe mantenere traccia di tutte le transazioni richieste da un wallet su un nodo SPV e usarle per associare indirizzi Bitcoin all’utilizzatore del wallet, minandone la privacy).
Poco dopo l’introduzione dei nodi SPV gli sviluppatori di bitcoin hanno aggiunto una funzionalità chiamata bloom filters per aggirare i rischi per la privacy dei nodi SPV. Questi filtri consentono ai nodi SPV di ricevere un sottoinsieme delle transazioni senza rivelare con precisione gli indirizzi a cui sono interessati, attraverso un meccanismo di filtraggio che utilizza probabilità anziché pattern fissi.
Bloom Filters
Sono usati per filtrare le transazioni (e i blocchi che le contengono) che un nodo SPV riceve dai pari, selezionando solo le transazioni di interesse del nodo senza rivelare quali indirizzi o chiavi siano interessate. Un nodo SPV inizializza un bloom filter come vuoto (empty, in questo stato il filtro non matcha con nessun pattern). Il nodo SPV allora crea una lista di tutti gli indirizzi, chiavi e hash a cui è interessato, estraendo l’hash della chiave pubblica, lo script di hash e l’ID della transazione da una UTXO controllata dal suo wallet. Il nodo SPV allora aggiunge ciascuno di questi al filtro di modo che possa corrispondere se questi pattern sono presenti in una transazione, senza rivelarli.
Il nodo SPV invia un messaggio filterload ai pari, contenente il bloom filter da usare nella connessione. Sui pari, i filtri vengono controllati rispetto a ciascuna transazione in entrata. Il nodo completo controlla diverse parti della transazione rispetto al filtro, cercando una corrispondenza che includa:
- l’ID della transazione;
- i dati componenti dagli script di blocco di ogni output di transazioni (ogni chiave e hash nello script);
- ognuno degli input della transazione;
- ognuno dei dati componenti gli input della firma (o script di witness).
Controllando tutte queste componenti, i filtri possono essere usati per matchare hash di chiavi pubbliche, script, valori OP_RETURN, chiavi pubbliche nelle firme o futuri componenti come smart contract o script complessi. Stabilito un filtro, i pari testeranno ogni transazione rispetto ad esso, inoltrando solo quelle che matchano. Il protocollo di rete il meccanismo dei bloom filters sono descritti in BIP-137.
Encrypted and Authenticated Connections
I nuovi credono che nel network Bitcoin le comunicazioni tra nodi siano criptate: nell’implementazione originale esse sono totalmente in chiaro. Questo non è un problema come si è detto per i full node, ma è un grosso problema per i nodi SPV. Per aumentare la privacy sono state proposte due soluzioni per criptare le comunicazioni:
- TOR Transport: The Onion Routing Network è un progetto che offre crittografia e incapsulamento dei dati attraverso percorsi di rete randomizzati che offrono anonimità, non tracciabilità e privacy (Bitcoin Core offre diverse opzioni di configurazione che permettono di eseguire un nodo Bitcoin il cui traffico dati è trasportato sulla rete TOR, e inoltre offre anche un servizio nascosto che permette ad altri nodi TOR di connettersi ad un nodo direttamente via TOR).
- P2P Authentication and Encryption (BIP-150/151): le due BIP definiscono servizi opzionali che possono essere offerti attraverso nodi compatibili. BIP-151 abilita negotiated encryption per tutte le comunicazioni tra nodi che supportano la BIP; BIP-150 offre un’opzionale autenticazione tra pari che permette ai nodi di autenticare ciascuno la loro identità utilizzando ECDSA e chiavi private (a gennaio 2017 non sono ancora implementate in Bitcoin Core, ma in un altro client chiamato bcoin). Le due BIP permettono ad un nodo SPV di connettersi ad un trusted full node utilizzando la crittografia e autenticando al fine di proteggere la privacy del client SPV. Inoltre, l’autenticazione può essere usata per creare reti di nodi bitcoin fidati e prevenire gli attacchi man-in-the-middle. Per ultimo, la crittografia P2P, se ampiamente utilizzata, rinforzerebbe la resistenza di Bitcoin all’analisi del traffico dati e alla sorveglianza, specialmente in paesi dove internet è sorvegliato e monitorato.
Transaction Pools
Quasi tutti i nodi della rete bitcoin mantengono un elenco temporaneo di transazioni non confermate denominato memory pool (o transaction pool). I nodi utilizzano questo pool per tenere traccia delle transazioni note alla rete ma non ancora incluse nella blockchain. Come le transazioni vengono ricevute e verificate, vengono aggiunte alla memory pool e inoltrate ai nodi adiacenti per propagarsi sulla rete.
Alcune implementazioni di nodi mantengono anche un pool separato di transazioni orfane. Se gli input di una transazione si riferiscono a una transazione che non è ancora nota, ad esempio un genitore mancante, la transazione orfana verrà archiviata temporaneamente nel pool orfano fino all’arrivo della transazione padre. Quando una transazione viene aggiunta alla mempool, il pool orfani viene controllato per gli orfani che sono riferimenti agli output di questa transazione (i figli), e gli orfani corrispondenti vengono convalidati.
Se validi, vengono rimossi dal pool orfani e aggiunti alla mempool, completando la catena avviata con la transazione principale. Alla luce della transazione appena aggiunta, che non è più orfana, il processo viene ripetuto ricorsivamente alla ricerca di ulteriori figli, fino a quando non vengono trovati più discendenti. Attraverso questo processo, l’arrivo di una transazione padre innesca una ricostruzione a cascata di un’intera catena di transazioni interdipendenti, riunendo gli orfani con i loro genitori lungo tutta la catena.
Sia la mempool sia il pool orfani (laddove implementato) sono memorizzati nella memoria locale e non vengono salvati nella memoria permanente; piuttosto, sono “popolati” dinamicamente dai messaggi di rete in arrivo (all’avvio di un nodo, entrambe le pool sono vuote e vengono gradualmente popolate con nuove transazioni ricevute sulla rete; attualmente da qualche versione di Bitcoin Core la mempool viene salvata su disco alla chiusura del nodo e recuperata all’avvio).
