Come Funziona Bitcoin: Oltre il Protocollo [Understanding Bitcoin-Part 3]
Questo articolo è la traduzione della terza sezione di ‘Understanding Bitcoin’, un ebook guida gratuito prodotto da Silas Barta e Robert P. Murphy, scaricabile visitando questo sito, dove è anche possibile donare agli autori. Silar Barta scrive sul suo blog in merito a diversi argomenti, tra cui Bitcoin, finanza e teoria dell’informazione, mentre Robert P. Murphy è autore di diversi libri nel campo della scuola austriaca di economia, oltre ad essere co-host del podcast Contra Krugman insieme a Tom Woods.
Sezione precedente — Come Funziona Bitcoin: Il Protocollo (3/3)
La sezione precedente ha descritto il funzionamento del protocollo di Bitcoin. Questo capitolo esamina i sistemi e i meccanismi che si sono sviluppati intorno ad esso, diventando parte integrante dell’ecosistema delle criptovalute pur non essendo presenti nel disegno originale.
a) Mining pool: come affrontare un network enorme
Come esposto in precedenza, il sistema del mining premia gli utenti in proporzione alla velocità in cui riescono a calcolare le “hash.” Maggiore la velocità di generazione, maggiore la frequenza con cui scopriranno una “proof of work” vincente con l’attuale coefficiente di difficoltà, e di conseguenza i bitcoin che riceveranno.
Tuttavia, la “hashing power” del network è diventata presto molto grande, elevando il coefficiente di difficoltà fino a raggiungere il punto in cui i piccoli utenti arrivavano ad aspettare, in media, mesi o persino anni prima di trovare la prima soluzione e riceverne la ricompensa. Di per sé, non sarebbe un problema insormontabile, ma tieni presente che la difficoltà potrebbe aumentare durante questo periodo — e potrebbe aumentare con una tale velocità da rendere il miner non competitivo prima della ricompensa prevista, il che significa che avrebbero lavorato per niente.
Soluzione: Riunire diversi Miner
Gli utenti di Bitcoin hanno realizzato di poter unire le forze per creare una macchina più potente. Dal punto di vista del network, questa macchina appare come un singolo utente che trova soluzioni più frequentemente degli altri. Il tasso di rendimento per-hash previsto rimane invariato, ma i partecipanti ricevono pagamenti più frequenti. Ogni volta che la pool trova una soluzione, distribuisce la ricompensa ai suoi membri, in proporzione alla quantità di lavoro contribuito, ovvero al numero di tentativi che un membro ha effettuato.
Parlando in termini del gioco che abbiamo descritto nella sezione precedente, supponiamo che alcuni giocatori lavorino insieme, concordando di dividersi la vincita se uno di loro trova il numero giusto e aumentando quindi le probabilità di vittoria. In tal senso, possiamo considerare la partecipazione a una mining pool come una forma di copertura (o assicurazione), in cui un gruppo di piccoli miner trasformano la loro bassa-probabilità-di-grande-ricompensa in alta-probabilità-di-piccola-ricompensa. Per ribadire il concetto, visto come un gruppo collettivo, una pool di, ad esempio, 1,000 miner non si aspetta di ricevere nel corso dell’anno un numero di bitcoin (significativamente) maggiore rispetto a quanto i 1,000 miner avrebbero guadagnato individualmente nello stesso anno lavorando in modo indipendente. Il problema del lavoro indipendente è la sporadicità delle ricompense, magari ricevendo nulla per diversi mesi e vincendo il jackpot quando finalmente si trova una soluzione e si ottiene la ricompensa piena di 25 bitcoin (NdT, attualmente 12,5). Attraverso il ”pooling” dei propri sforzi di mining in un team collettivo, i 1,000 piccoli miner rendono la propria fonte di reddito molto più prevedibile (e, ovviamente, più contenuta) settimana dopo settimana. Nel corso dell’anno, ciascun miner prevede di guadagnare approssimativamente lo stesso numero di bitcoin, sia lavorando indipendentemente che all’interno del team. Detto questo, la grande maggioranza preferisce una fonte di reddito costante piuttosto che sporadica, a parità di valore; in economia, questa tendenza viene definita “avversione al rischio.” Questa è la logica fondamentale dietro alla formazione delle mining pool.
Garantire l’Onestà dei Membri di una Mining Pool
Forse ti starai chiedendo, come ci siamo chiesti noi, come fa una mining pool a sapere quanto attribuire a ciascun utente. In fondo, la grande maggioranza dei contribuenti non troverà mai una soluzione vincente, anche se aiuta ad incrementare il numero di tentativi che la pool può fare. Pensandoci bene, un miner disonesto potrebbe approfittarsi della pool senza spendere risorse dicendo, “Accidenti, abbiamo fatto i nostri tentativi su quel blocco di numeri, purtroppo non abbiamo trovato una soluzione. Cosa ci vuoi fare, a volte si vince a volte si perde. Oh, e non dimenticatevi di ricompensarci per quei tentativi quando trovate la soluzione!”
In realtà, le mining pool hanno una soluzione geniale per difendersi da questo stratagemma, che praticamente consiste in una rielaborazione dello stesso protocollo proof-of-work impiegato da Bitcoin. Così come gli utenti di Bitcoin possono verificare la quantità di lavoro investito in un problema, anche una mining pool riesce a verificare la quantità di lavoro contribuita dai suoi membri.
Per comprendere questo processo, torniamo alla variante crypto del nostro gioco [descritta qui]: viene dichiarato un numero target, l’output, e i giocatori devono tirare a indovinare per trovare un numero input che, quando inserito nella funzione scrambler, risulta nel numero target. Per semplicità, diciamo che ci sono 1,000 possibili output, quindi servono mille tentativi per essere sicuri di una soluzione, sebbene — in media — questa viene trovata dopo 500 tentativi. In questo esempio, supponiamo che i miner partecipanti in una pool abbiano come numero target 747. Chiunque faccia parte del team conosce la funzione matematica attraverso cui un numero input viene trasformato in un numero output, e l’obiettivo è trovare il numero input magico che — quando inserito nella funzione — risulta in “747”. Ricorda che queste sono funzioni unidirezionali, ovvero è facile trasformare un input nell’output associato, ma è virtualmente impossibile fare il contrario. Per questo motivo i miner non possono “risolvere” direttamente, con un po’ di reverse engineering, partendo da 747. Invece, devono usare un approccio di tentativi ed errori, chiamato brute force, inserendo nella funzione tutti i numeri nell’intervallo 1–1000 fino a quando qualcuno ha un colpo di fortuna e trova il numero che risulta in 747.
Quando i miner si uniscono a una pool, gli vengono assegnati diversi sottogruppi dei numeri possibili, per fare in modo che qualcuno nella pool trovi il numero giusto il più presto possibile. Se ci sono dieci miner nella pool, il primo avrà il compito di tentare i numeri 1–100, il secondo miner lavorerà su 101–200, e così via, fino al decimo membro della pool che riceverà 901–1000. Ricorda, anche se tutti sanno che l’obiettivo è arrivare a 747, nessuno ha la minima idea del numero input necessario. La funzione scrambler è talmente impenetrabile che non è neanche possibile trovare i numeri che si avvicineranno a 747, in quanto non esiste uno schema prevedibile per la trasformazione del numero input in numero output. Per esempio, se Jake è la seconda persona nella mining pool, inizia a calcolare 101, 102, e 103, trovando, rispettivamente, output di 851, 282, e 360. Prima di questi calcoli, né Jake né altri avevano la minima idea che 101 risultasse in 851, e anche dopo aver provato i primi tre numeri input a lui assegnati, Jake non ha un metodo più efficace di quanto ha fatto finora, fare scorrere la sua lista e sperare di aver fortuna. Non è in grado di “scoprire di più sulla funzione scrambler” con ogni tentativo.
In questo scenario ipotetico, mentre la macchina di Jake svolge i calcoli della funzione scrambler con input 104, un altro membro del gruppo — che chiameremo Alice — dichiara di aver trovato la soluzione! Alice è il decimo membro della pool, e ha provato i numeri 901, 902, e 903 senza successo. Inserendo 904 nel suo computer e svolgendo i calcoli, l’output che ha ottenuto è 747 — il numero target. Quindi il gruppo può smettere di lavorare, e i dieci membri si dividono i 25 bitcoin della ricompensa rilasciata dal protocollo.
Ora richiamiamo il problema a cui la mining pool deve far fronte: come essere sicuri che Jake abbia davvero contribuito 100 tentativi (“hash”) senza dover ricontrollare i risultati che ha inviato, vanificando la finalità della pool?
Ricorda che i risultati del processo di hashing sono distribuiti in modo uniforme, anche quando gli input sono limitati a gruppi specifici. Di conseguenza, possiamo trovare il numero n di un blocco di numeri per cui, a prescindere da come selezioniamo questi numeri n, il 10% rientrerà in un intervallo desiderato, a patto di prevedere un “arrotondamento” in cui 999 conta come “two away” da 1 e così via. (In questo esempio ci sono 1,000 possibili valori di output, quindi il 10% dei tentativi ricadrà nell’intervallo 100–199, un altro 10% nell’intervallo 200–299, ecc.)
Di conseguenza, l’unica comunicazione tra i membri e l’organizzatore della pool ha come obiettivo la segnalazione di questi “near hits.” Per esempio, le persone che gestiscono la nostra pool ipotetica potrebbero chiedere ai membri di segnalare tutti i tentativi i cui risultati rientrano in un intervallo di ±10 unità dal numero target 747. In altre parole, un membro della pool dichiara “bingo!” quando trova 747, ma segnala anche i tentativi che portano a un numero nel raggio tra 737 e 757. Per esempio, se Jake calcola 104 e ottiene il risultato 751, segnalerà “104” al gestore della pool, anche se non è il numero vincente. Questo potrà, a sua volta, controllare che effettivamente 104 porta a un risultato compreso nell’intervallo scelto.
L’obiettivo della segnalazione di questi “near hits” è assicurarsi che ogni membro della pool stia effettivamente contribuendo allo sforzo collettivo svolgendo i calcoli sui numeri a lui assegnati. Maggiore il numero di “near hits” segnalati da Jake, maggiore la quantità di lavoro che deve aver investito; non c’è modo per cui Jake possa conoscere in anticipo come adattare le sue ricerche in modo da ottenere soluzioni vicine a 747. Il numero di questi risultati sarà sempre direttamente proporzionale al numero di tentativi effettuati, quindi indicherà accuratamente i contributi relativi dei membri, permettendo al gestore della pool di calcolare la quota di ricompensa da assegnare a ciascuno. Per esempio, supponiamo che al momento in cui un membro del team trova la soluzione — l’input che porta all’output 747 — Jake abbia segnalato 8 near hits mentre un altro membro, Charley, ne abbia segnalati solo 2. Di conseguenza, Jake riceverà una percentuale della ricompensa quattro volte superiore a quella di Charley, in quanto il computer di Jake ha esaminato il quadruplo dei numeri, durante il periodo di tempo in questione.
Per chiarire, nel nostro esempio abbiamo scelto in maniera arbitraria il raggio di ±10 unità dal numero target, un raggio di “near hits” che equivale all’1% del dominio originale. Ritoccare la soglia di “prossimità” dei “near hits” porta a un compromesso: Più grande è il raggio, più precisa sarà la distribuzione dei pagamenti. In questo caso i membri della mining pool riceveranno ricompense più adeguate al loro contributo effettivo. Questo però porta a uno svantaggio per le persone che gestiscono la pool, in quanto devono verificare i near hits segnalati per accertarsi che i membri non stiano mentendo. Così facendo impegnano potenza di calcolo preziosa, svolgendo calcoli che non portano a nessuna ricompensa in bitcoin.
A livello teorico, il punto ottimale di questo spettro non è ovvio, soprattutto quando si ha a che fare con membri che contribuiscono potenze di calcolo molto diverse e membri poco scrupolosi. A un’estremità dello spettro, potrebbe esserci un raggio di “prossimità” estremamente stretto, in cui i membri della pool dichiarano soltanto la soluzione vincente — un raggio di ±0. Questa configurazione non avrebbe nessun “peso” sulla potenza di calcolo della pool, in quanto non sarebbe necessario controllare alcuna segnalazione. Tuttavia, vorrebbe anche dire che tutti i membri si divideranno i 25 bitcoin equamente, dato che non ci sarebbe modo per capire quanti tentativi sono stati effettuati da ciascuno prima della soluzione vincente.
Considerando l’estremo opposto, il gestore della pool potrebbe insistere affinché i partecipanti segnalino un near hit entro ±499 del numero target. Seguendo questo sistema li porterebbe a segnalare ogni tentativo. Dopodiché, se il gestore verifica i tentativi comunicati da ciascun membro, ci sarebbe la certezza assoluta sui contributi relativi di ciascun membro (in quanto il gestore ha ricontrollato ogni singolo tentativo segnalato da ogni membro). Ovviamente, questo sistema annullerebbe l’intento della pool, portando il gestore a dedicare i propri computer alla duplicazione di tutti i calcoli effettuati dai membri.
Perché non Rubare la Soluzione?
Un altro problema per chi si unisce a una mining pool potrebbe essere l’opposto: uno dei membri potrebbe trovare il numero vincente e, invece di comunicarlo al gestore, scappare con la soluzione e reclamare la ricompensa tutta per sé. Fortunatamente, le pool hanno un modo (crittograficamente sicuro) per prevenire anche questo: i membri trovano una soluzione (o “nonce”) per la hash di un pacchetto di transazioni, ma non del contenuto del pacchetto stesso. Quindi non hanno le informazioni necessarie per redimere le soluzioni che trovano.
Il proprietario della pool potrebbe invece rifiutare di pagare i membri dopo che questi hanno trovato una soluzione vincente, quindi a tale riguardo dipendono dalla loro reputazione nel pagare le ricompense. Fortunatamente, i membri possono verificare che a) il tasso con cui guadagnano crediti (near hits) corrisponde al tasso di tentativi, e b) la loro percentuale della ricompensa è coerente al numero di crediti che hanno contribuito e al numero di “near hits” necessari per trovare una soluzione.
Abbiamo dedicato molto tempo a questa discussione sulle mining pool per due ragioni: Primo, aiuta a fare luce sull’operazione più ampia dello stesso Bitcoin, obiettivo primo di questa guida. Secondo, una delle obiezioni più intelligenti a Bitcoin riguarda le “economie di scala” nelle mining pool. Più avanti cercheremo di affrontare questa obiezione, ma la nostra missione sarà molto più semplice ora che abbiamo spiegato metodicamente le basi delle mining pool.
b) Bitcoin Exchange
Come esistono siti tipo eBay per coordinare compratori e venditori, e mercati valutari per coordinare chi converte tra valute, ci sono siti che agevolano lo scambio tra bitcoin e valute convenzionali. In un tipico Bitcoin exchange, il proprietario della piattaforma prende possesso “fisico” sia di bitcoin che di valute convenzionali (dal punto di vista del network di Bitcoin, un indirizzo che appartiene al proprietario dell’exchange è anche il proprietario dei bitcoin al suo interno).
Quando vengono scambiati bitcoin all’interno di un simile exchange, la procedura è diversa dalle solite transazioni nel network di Bitcoin. Nessun messaggio firmato viene prodotto e trasmesso, e il trasferimento non viene indicato in nessun aggiornamento del registro; è una questione di contabilità interna per l’exchange. Solo quando arriva il momento di ritirare i bitcoin dall’exchange, per onorare la promessa, devono seguire il solito protocollo Bitcoin.
Per un’analogia con il dollaro, Alice deposita $100 in denaro fisico nel suo conto corrente con CitiBank. CitiBank prende fisicamente possesso dei pezzi di carta verdi, e nella propria contabilità indica che Alice ha un $100 aggiuntivo nel proprio conto. Alice può vedere questo numero online o attraverso un ATM. Se Alice fa un assegno a Billy, il quale è cliente di CitiBank, non c’è movimento fisico di moneta. CitiBank conserva le banconote nelle sue casseforti, ma modifica i propri registri sottraendo $100 dal conto di Alice e aggiungendo $100 al conto di Billy, Ovviamente, se Billy vuole ritirare soldi dal suo conto con CitiBank, la banca deve rinunciare al possesso fisico nello steso momento in cui sottrae la somma dal conto di Billy.
Lo stesso processo avviene con i Bitcoin exchange. Quando Alice deposita un bitcoin nell’exchange, questo “prende possesso” nel senso che Alice trasferisce formalmente il controllo su quel particolare bitcoin a un indirizzo di proprietà dell’exchange; ora il registro pubblico di Bitcoin indica l’exchange come proprietario di quel bitcoin, con l’autorità di decidere come verrà speso (trasferito a qualcun altro) in futuro. Quando Alice deposita un bitcoin, l’exchange (se è onesto) utilizzerà la propria contabilità interna per riflettere questo fatto. Se chiede all’exchange di trasferire il bitcoin a Billy (forse perché ha acquistato da lui una scrivania), l’exchange può mantenere il controllo del bitcoin per quanto riguarda il registro di Bitcoin, purché anche Billy sia un cliente dell’exchange; semplicemente sottrarrà 1 BTC dal saldo di Alice e lo aggiungerà a quello di Billy. Tuttavia, se qualcuno vuole ritirare bitcoin dall’exchange, dovrà trasferire il controllo inviando le istruzioni appropriate al network di Bitcoin, per fare in modo che il registro venga aggiornato opportunamente.
c) Processori di pagamento
Qualsiasi siano i meriti di Bitcoin, deve esistere in un mondo in cui non tutti lo accettano o ci lavorano. Ma se i suoi sostenitori vogliono aumentare il tasso di adozione, è importante che le persone siano in grando di spenderlo in un numero di posti sempre maggiore. Il ruolo dei processori di pagamento è offrire una conversione trasparente tra Bitcoin e valute convenzionali in modo che il cliente spende bitcoin mentre il commerciante riceve una moneta più tradizionale (come il dollaro o l’euro). Concretamente, il processore di pagamenti riceve i bitcoin dal cliente e, allo stesso tempo, invia la valuta desiderata al commerciante, in base al tasso di cambio prevalente al momento della vendita (con un margine integrato come commissione sullo scambio). Il processore di pagamenti ha accesso a un mercato (magari un grande Bitcoin exchange) in cui può vendere bitcoin per la valuta tradizionale di cui ha bisogno, al fine di mantenere la disponibilità di varie valute per consentire transazioni veloci.
Il servizio può sembrare elaborato, ma è simile a quello che molte società di carte di credito fanno quando i loro clienti viaggiano all’estero e usano la carta per acquistare prodotti denominati in valute straniere. Sia il compratore che il venditore vedono una transazione nella propria valuta (spesso con una tariffa), basata sul tasso di cambio nel momento della vendita, mentre l’emittente converte silenziosamente senza richiedere ulteriori sforzi dalle due parti.
d) Mixing pool
Sebbene Bitcoin introduce il potenziale per l’anonimato, richiede una certa quantità di lavoro per raccoglierne i benefici. Tutte le transazioni sono pubbliche, quindi per essere anonimi è necessario generare costantemente nuovi indirizzi verso cui deviare pagamenti in arrivo, per fare in modo che non ci sia una connessione unica al proprietario originale. Questo richiede un azione coordinata tra più utenti che inviano le proprie monete a nuovi indirizzi casuali che oscurano le loro origini. Usando semplicemente lo stesso indirizzo per ogni transazione, tutta la cronologia sarebbe visibile non appena qualcuno riesce a collegarti a una di queste — magari vendendoti qualcosa e chiedendo un pagamento in bitcoin. (Per questo si raccomanda ai commercianti di generare un indirizzo nuovo per ogni transazione: https://en.bitcoin.it/w/index.php?title=Merchant_Howto&oldid=52425#Common_ Errors)
Come già abbiamo detto, gli utenti possono creare quanti indirizzi vogliono, e spostare i propri fondi tra di loro a volontà, ma è necessario un importante ulteriore livello di privacy per garantire che le transazioni non riportino direttamente alla stessa persona che ha creato gli indirizzi. In una mixing pool, un utente collabora con altri per distribuire i propri bitcoin originali non solo tra diversi indirizzi, ma anche tra diversi utenti. I soldi finirebbero in nuovi indirizzi come nel caso precedente, ma gran parte “arriverebbe” da altri utenti. Per esempio, invece di spedire a 5 indirizzi, l’utente potrebbe inviare a 95 indirizzi, ricevendo i propri soldi in 5 indirizzi che effettivamente sono stati inviati da altre persone.
In questo modo anche se un investigatore molto motivato trova un percorso che collega una transazione alla persona in esame, il valore della prova è molto limitato; quella persona sarebbe uno dei tanti che quei bitcoin ha attraversato. Possiamo fare un’analogia al denaro contante. Secondo uno studio, il 90% delle banconote in dollari negli Stati Uniti hanno tracce di cocaina. Tuttavia per questo stesso motivo, il possesso di queste banconote è una prova debole, e pertanto inammissibile, in quanto tutti, non solo chi fa uso di questa droga, hanno delle banconote. Le mixing pool realizzano qualcosa di simile: fanno in modo che i bitcoin di una persona siano ben mescolati in altri indirizzi, creando una situazione in cui l’obiettivo di un’indagine potrebbe affermare onestamente, “Si, c’è una catena di transazioni che collega uno dei miei indirizzi a quello che lei cita… ma si potrebbe dire lo stesso per il 90% del network!”
e) Messaggi integrati
Il protocollo consente di allegare messaggi arbitrari, non correlati al trasferimento di bitcoin, a una transazione. Sebbene questa funzionalità possa sembrare una distrazione superflua, eredita effettivamente tutte le proprietà di marcatura temporale dei trasferimenti nella blockchain, istituendo un registro di eventi cronologico non falsificabile. Ovvero, fornisce la convalida che l’intero network ha visto il messaggio all’interno di una piccola finestra, di fatto marcandolo. Infatti, uno sviluppatore ha creato uno strumento che “sfrutta” il network di Bitcoin esistente per integrare messaggi. E una variante del protocollo Bitcoin (Namecoin) viene già usata come una forma di registrazione di trasferimenti di domini Internet in un modo più resistente alle frodi rispetto ai metodi convenzionali di autenticazione; la stessa idea di base potrebbe essere estesa ad altre proprietà.
f) Scripting e smart contract
Il protocollo ammette una limitata quantità di automazione, affinché si possano “innescare” determinati eventi in futuro, applicando condizioni di approvazione da parte di partecipanti futuri. Un esempio comune sono i servizi di escrow: normalmente, è necessario una terza parte con il compito di trattenere i fondi fino a quando le parti interessate concordano su chi li riceverà. Ma grazie allo scripting puoi fare in modo che il network aderisca alla regola per cui “tra due settimane, i fondi andranno alla parte A o alla parte B, come determinato dalla parte C,” senza dover consentire a una parte di avere il possesso fisico sui fondi, evitando così il rischio di qualcuno che scappi con i soldi.
