Le regole di Bitcoin

Ogni sistema monetario funziona grazie a regole: quanta moneta può essere emessa, chi può spendere che cosa, quale pagamento è valido e quale no. Nella moneta che usiamo ogni giorno quelle regole hanno un custode. La banca centrale decide quanta moneta emettere, le banche tengono i conti e registrano i trasferimenti, e chi usa il denaro può soltanto fidarsi che lo facciano correttamente.

Satoshi Nakamoto indicava proprio questo come il difetto di partenza. L’11 febbraio 2009, presentando Bitcoin sul forum della P2P Foundation, scriveva: «Il problema alla radice della moneta convenzionale è tutta la fiducia necessaria a farla funzionare. Bisogna fidarsi che la banca centrale non svaluti la moneta, ma la storia delle valute fiat è piena di violazioni di quella fiducia».

«The root problem with conventional currency is all the trust that’s required to make it work. The central bank must be trusted not to debase the currency, but the history of fiat currencies is full of breaches of that trust.»

— Satoshi Nakamoto, Bitcoin open source implementation of P2P currency, P2P Foundation, 11 febbraio 2009

Chi controlla il controllore?

Un sistema con un custode ha un problema che nessun regolamento può risolvere fino in fondo. Chi ha il compito di far rispettare le regole ha anche il potere di cambiarle o di violarle, e sopra di lui può esserci soltanto un altro controllore, di cui bisogna fidarsi a sua volta. La domanda «chi controlla il controllore?» non trova mai una risposta definitiva, perché ogni nuovo livello di controllo sposta la fiducia un gradino più in alto senza eliminarla.

Il whitepaper di Bitcoin descrive la stessa situazione nei pagamenti elettronici. Per impedire che una moneta digitale venga spesa due volte, la soluzione comune è affidarsi a «un’autorità fiduciaria centrale, o zecca, che controlli tutte le transazioni». Il problema, scrive Nakamoto, «è che il destino di tutto il sistema monetario dipende dalla società che gestisce la zecca». Per questo il whitepaper propone «un sistema di pagamento elettronico basato su prova crittografica invece che sulla fiducia».

Un protocollo, non un’azienda

Bitcoin non è un’azienda: non ha un CEO né un amministratore. È un protocollo, cioè un insieme di regole pubbliche che permettono a molti computer di mantenere e verificare lo stesso registro.

Le regole del protocollo non sono affidate a un’autorità che le applica per conto di tutti: le applica ogni full node, cioè ogni computer che esegue il software di Bitcoin, conserva una copia completa del registro e controlla da solo ogni transazione e ogni blocco che riceve.

Nessuno coordina questi controlli dall’alto. Mastering Bitcoin parla di un «consenso emergente»: non c’è un’elezione né un momento in cui qualcuno decide quale sia il registro corretto, ma migliaia di nodi indipendenti che seguono le stesse regole arrivano da soli alla stessa conclusione.

In un sistema così la domanda sul controllore perde senso. Nessuno controlla gli altri per conto di tutti e nessuno ha bisogno di essere controllato da qualcun altro, perché chi esegue un nodo non si affida al giudizio di un’autorità: verifica direttamente. Un blocco che viola le regole viene respinto da ogni nodo che lo riceve, chiunque l’abbia prodotto.

Restano due domande. Quali sono le regole che i nodi applicano? E se nessuno ha l’autorità di cambiarle, chi può proporre una modifica e come viene accettata?

Quali sono le regole di Bitcoin

Le regole che un nodo applica sono di due tipi: le regole di consenso, uguali per tutti, e le regole di policy, scelte da ogni nodo.

1. Le regole di consenso: uguali per tutti

Le regole di consenso stabiliscono quali transazioni e quali blocchi sono validi. Sono le regole che definiscono Bitcoin e devono essere identiche su tutti i nodi.

Alcune riguardano la moneta stessa. La regola di emissione stabilisce quanti nuovi bitcoin vengono creati e a che ritmo: chi produce un nuovo blocco riceve il block subsidy, la ricompensa in bitcoin di nuova emissione, partita da 50 nel 2009 e dimezzata ogni 210.000 blocchi, circa ogni quattro anni, con l’halving. Per questo l’emissione complessiva si ferma a circa 21 milioni di bitcoin.

Altre proteggono chi possiede bitcoin. Il divieto di doppia spesa impedisce di spendere una seconda volta una moneta già spesa, e la verifica della firma digitale richiede a chi spende di dimostrare di averne il diritto con una firma valida.

Altre ancora riguardano i blocchi. Il limite di dimensione fissa quanto può essere grande un blocco, mentre il difficulty adjustment, aggiustamento della difficoltà, stabilisce quanto debba essere difficile produrlo: ogni nodo ricalcola da solo questa difficoltà circa ogni due settimane.

Se due nodi applicano regole di consenso diverse, lo stesso blocco può essere valido per uno e non valido per l’altro. Il primo lo aggiunge alla propria copia del registro, il secondo lo rifiuta, e da quel punto i due nodi non condividono più la stessa storia: il registro si divide in due catene parallele. Questa separazione si chiama fork, biforcazione, come una strada che a un certo punto si divide in due direzioni, con una moneta che mantiene e lavora sulla sua storia originale e una nuova moneta che da quel punto in poi non condivide più nulla con la vecchia.

Per questo nessun nodo può cambiare da solo le regole di consenso: non cambierebbe Bitcoin, ma si separerebbe dal resto della rete; e se altri lo seguissero, nascerebbe una nuova moneta, una nuova altcoin o shitcoin che dir si voglia.

2. Le regole di policy: scelte da ogni nodo

Le regole di policy, cioè i criteri di inoltro delle transazioni, riguardano soltanto le transazioni non ancora confermate. Prima di entrare in un blocco, una transazione passa da un nodo all’altro e attende nella mempool, lo spazio in cui ogni nodo conserva le transazioni in attesa di conferma. Le regole di policy stabiliscono quali di queste transazioni il nodo accetta di conservare e di inoltrare agli altri nodi. Due esempi sono la commissione minima di inoltro, cioè la commissione che una transazione deve pagare perché il nodo la trasmetta, e il limite di dimensione della mempool, oltre il quale il nodo smette di conservare altre transazioni in attesa.

Queste regole esistono per proteggere il nodo. Ogni transazione ricevuta occupa memoria, banda e capacità di calcolo, e un nodo che accettasse e inoltrasse qualsiasi cosa potrebbe essere sommerso da transazioni inutili. La commissione minima di inoltro impone un piccolo costo a ogni transazione e scoraggia lo spam e gli abusi; il limite della mempool impedisce che le transazioni in attesa occupino più memoria di quella disponibile.

Sono diverse dalle regole di consenso perché i nodi non sono tutti uguali: c’è chi ne esegue uno su un piccolo computer come un Raspberry Pi e chi su un server, e ogni operatore può adattare i propri limiti alla macchina che usa. Questa libertà è possibile perché le regole di policy sono criteri locali del singolo nodo e non si applicano alle transazioni già contenute nei blocchi.

Se due nodi applicano regole di policy diverse, una transazione in attesa può essere inoltrata dal primo e scartata dal secondo. Quando però quella transazione entra in un blocco valido, entrambi accettano il blocco, e il registro resta uno solo.

Oltre a queste regole, il software di un nodo offre impostazioni che non riguardano la validità di blocchi e transazioni. Chi ha poco spazio su disco, per esempio, può attivare il pruning, potatura, che conserva solo i blocchi più recenti e cancella i più vecchi: il nodo usa meno risorse, ma applica le stesse regole degli altri.

Le due regole a confronto

Le regole di policy cambiano quando un operatore lo decide. Le regole di consenso, invece, cambiano soltanto se cambia il software eseguito da un numero molto ampio di nodi: per capire come, bisogna guardare come nasce e come viene accettata una modifica.

Chi può proporre una modifica

Chiunque. Bitcoin è open source: il codice del software di Bitcoin è pubblico e chiunque può leggerlo. È distribuito con la licenza MIT, che permette a chiunque di usarlo, copiarlo e modificarlo. Non serve chiedere un permesso per studiarlo, e chi sa programmare può verificare da sé come il software applica ogni regola.

Su questo codice lavorano molti sviluppatori, che rivedono le modifiche proposte da altri, le testano e scrivono il codice delle nuove funzionalità. Il progetto segue un modello aperto, in cui chiunque può contribuire e non esistono sviluppatori privilegiati: la fiducia si guadagna nel tempo con il lavoro svolto.

Come si propone una modifica

Una proposta di modifica alle regole di consenso passa da un BIP, Bitcoin Improvement Proposal, proposta di miglioramento di Bitcoin. Il documento che ne descrive il processo, il BIP 3, chiede a chi ha un’idea di verificare prima se sia già stata discussa e poi di presentarla in un nuovo thread sulla mailing list pubblica degli sviluppatori di Bitcoin, per capire se interessa alla comunità prima di scriverne la bozza. Un BIP può essere presentato da chiunque, purché il contenuto sia di qualità e non faccia perdere tempo alla comunità.

Lo stesso BIP 3 chiarisce che un BIP non definisce che cosa sia Bitcoin e non rappresenta il consenso della comunità: è la raccomandazione personale dei suoi autori. Alcuni BIP non vengono mai adottati, altri arrivano a cambiare le regole di consenso che l’ecosistema di Bitcoin fa rispettare insieme.

Il codice che realizza una proposta segue la stessa strada di ogni altra modifica al software. Tutti i contributori, senza eccezioni, propongono le proprie modifiche con una pull request, cioè una richiesta pubblica di integrare nel progetto una serie di cambiamenti: chi la presenta crea una propria copia del repository, vi scrive le modifiche e chiede che vengano accolte nel codice principale. Deve averle comprese a fondo e testate, indicare quali test le verificano ed essere pronto a spiegarne le ragioni; se ci sono dubbi, la richiesta può essere chiusa.

Come viene esaminata e accettata

Una volta pubblicata, la pull request viene esaminata da altri partecipanti, e anche questa revisione è aperta a chiunque: si svolge con commenti pubblici nella pull request stessa. Prima i revisori giudicano l’idea: con un «Concept ACK» dichiarano di essere d’accordo con l’obiettivo della modifica, con un «Concept NACK» di non esserlo, e un rifiuto deve essere motivato, altrimenti può essere ignorato. Poi esaminano il codice vero e proprio e dichiarano se lo hanno testato o soltanto letto.

A integrare le modifiche nel codice principale sono i maintainer del repository, che si occupano anche del ciclo dei rilasci e della moderazione. La guida del progetto spiega che questa gerarchia esiste per ragioni pratiche, in un progetto che non riconosce sviluppatori privilegiati. Prima di integrare una pull request i maintainer valutano se rispetta i principi generali del progetto e gli standard minimi, e se riflette il consenso generale dei contributori; nel giudicare le opinioni dei revisori possono dare più peso a chi ha dimostrato nel tempo un impegno e una comprensione del progetto più profondi. Le modifiche alle regole di consenso sono molto più impegnative: devono essere precedute da un’ampia discussione sulla mailing list, avere un BIP numerato e ampiamente discusso e godere di un consenso tecnico diffuso sul fatto che il cambiamento sia utile. Su quella base i maintainer integrano nel codice la nuova regola proposta dal BIP, oppure la lasciano fuori.

Dal software alla rete

Una nuova regola di consenso vale soltanto nei nodi i cui operatori scelgono di installare il software che la contiene. Se una parte della rete la applicasse e un’altra no, i due gruppi rischierebbero di non riconoscere più gli stessi blocchi e il registro si dividerebbe in due. Per questo gli aggiornamenti delle regole comuni vengono preparati in modo da entrare in vigore solo quando una larghissima maggioranza è pronta ad applicarli.

Per i soft fork più recenti, cioè le modifiche che restringono le regole esistenti, si è usata la segnalazione dei miner: chi produce un blocco può indicare nel blocco stesso il sostegno alla nuova regola, e i nodi contano le segnalazioni su periodi di 2.016 blocchi, circa due settimane. La regola entra in vigore solo se in un periodo la quota di blocchi che la segnalano raggiunge la soglia prevista: il 95% secondo il BIP 9, il 90% per l’attivazione di Taproot nel 2021. Se la soglia non viene raggiunta entro la scadenza, la proposta non si attiva. I tipi di cambiamento e le loro conseguenze sono spiegati nell’articolo Cos’è un fork in Bitcoin.

Lungo tutto il percorso nessuno può imporre una modifica agli altri. Gli autori di un BIP formulano una raccomandazione, i revisori danno il proprio parere, i maintainer integrano codice che nessuno è obbligato a installare, e alla fine ogni operatore decide quali regole far applicare al proprio nodo.

Perché le regole comuni cambiano lentamente

Mastering Bitcoin ricorda che Bitcoin, come sistema decentralizzato, non ha un’autorità che possa imporre la propria volontà ai partecipanti. Il potere è distribuito tra miner, sviluppatori, wallet, commercianti e utenti, e nessuno di loro può decidere da solo: se i miner provassero a cambiare le regole per conto proprio, il resto dei partecipanti potrebbe rifiutarsi di seguirli. Per questo, conclude il libro, la situazione esistente è lo stato stabile del sistema, e i cambiamenti sono possibili solo con un consenso molto ampio.

Questa lentezza protegge le regole più importanti e, in generale, l’integrità del codice. Prendiamo la regola di emissione. Chi volesse aumentare l’emissione oltre i 21 milioni potrebbe riscrivere il codice, ma dovrebbe convincere ogni operatore a installarlo, e ogni nodo che non lo installa continuerebbe a respingere i blocchi che violano il limite dei 21 milioni. Se qualcuno lo seguisse, non avrebbe cambiato Bitcoin: avrebbe creato un’altra moneta.

Nel sistema economico convenzionale la quantità di denaro la decide la banca centrale, e chi lo usa può soltanto fidarsi che non lo svaluti; per cambiare le regole basta la decisione di chi gestisce la moneta. In Bitcoin la regola di emissione non è affidata a nessuno: è scritta nel protocollo, e ogni nodo la controlla da sé su ogni blocco che riceve. Il limite dei 21 milioni non è una promessa, è il risultato di un calcolo che chiunque può rifare: 50 bitcoin per ciascuno dei primi 210.000 blocchi, 25 per i successivi 210.000, poi 12,5, e così via a ogni halving, finché dopo 33 dimezzamenti la ricompensa si azzera. La somma si ferma a 20.999.999,9769 bitcoin. Lo stesso vale per le altre regole di consenso: una firma è valida o non lo è, un blocco rispetta la difficoltà richiesta o non la rispetta, e il risultato è lo stesso per chiunque faccia il controllo.

Non esiste una persona, un’azienda o un’istituzione che possa cambiare queste regole per tutti, e la domanda «chi controlla il controllore?» perde senso: non esiste un controllore, perché ognuno controlla da sé secondo regole ben precise. Dove la moneta convenzionale chiede fiducia, Bitcoin offre la possibilità di verificare.

Fonti

• Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, 2008, introduzione e sezione 2 «Transazioni», citato dalla traduzione italiana di @terzim.
• Satoshi Nakamoto, Bitcoin open source implementation of P2P currency, P2P Foundation, 11 febbraio 2009, archivio del Satoshi Nakamoto Institute: testo originale citato e traduzione BitCal.
• Bitcoin Core, CONTRIBUTING.md — modello aperto di contribuzione, pull request, requisiti per chi le presenta, revisione (Concept ACK/NACK, ACK testato o non testato), ruolo dei maintainer e criteri di integrazione, requisiti per le modifiche al consenso; COPYING — licenza MIT; Transaction Relay Policy — definizione di policy: regole locali e configurabili, applicate alle transazioni non confermate e non a quelle contenute nei blocchi.
• BIP 3 — Updated BIP Process, repository ufficiale dei BIP — chi può presentare un BIP, verifica preliminare e discussione sulla mailing list, sezione «What is the Significance of BIPs?».
• BIP 9 — Version bits with timeout and delay — segnalazione dei miner, periodi di 2.016 blocchi, soglia del 95%, scadenza; BIP 341, sezione «Deployment» — soglia del 90% per l’attivazione di Taproot.
• Andreas M. Antonopoulos, Mastering Bitcoin, traduzione italiana — consenso emergente, validazione delle transazioni, emissione e halving (script max_money e totale di 2.099.999.997.690.000 satoshi), aggiustamento della difficoltà, mempool, commissioni come deterrente contro lo spam, opzioni di configurazione per nodi con risorse limitate (minrelaytxfee, maxmempool, prune) e nodi su Raspberry Pi o server, ripartizione del potere tra i partecipanti, «Sviluppo del Software di Consenso».