Il processo di approvazione delle modifiche

Non esistendo nessuna autorità centrale che governa Bitcoin, risulta difficile capire come questo sistema possa prendere decisioni sui miglioramenti da introdurre o sulle criticità da correggere. Infatti, contrariamente ai sistemi centralizzati dove c’è sempre un’entità preposta a fare le scelte, in un sistema distribuito come Bitcoin, quest’entità non esiste.

Per rispondere alla domanda: “Come fa Bitcoin a decidere gli sviluppi da implementare?”, bisogna ancora una volta far ricorso alla teoria dei giochi. Infatti, così come avviene per il consenso distribuito, anche le decisioni su come far evolvere il sistema vengono prese dalla collettività degli attori che vi partecipano, incentivando la cooperazione fra le parti per raggiungere (quasi) l’unanimità del consenso. Miner, proprietari di nodi, sviluppatori e utilizzatori, si ritrovano tutti tirati in ballo all’interno del processo decisionale, in quanto questo andrà a impattare sul funzionamento futuro della blockchain, e quindi sul benessere del loro lavoro e/o dei loro investimenti.

I passi per arrivare alle modifiche

Volendo fornire una descrizione ad alto livello di quest’operatività, si possono evidenziare i seguenti passi:

1. all’interno della comunità di Bitcoin, una o più entità iniziano a discutere di una modifica al sistema;
2. se tale idea riscuote interesse, allora il gruppo che l’ha proposta ne dà una definizione formale e inizia a promuoverla attivamente verso tutti gli attori della rete (più avanti nel processo avranno bisogno di ottenere quasi il consenso unanime per rendere la modifica utilizzata);
3. questa formalizzazione viene inserita in un‘apposita lista [1], in attesa di essere implementata;
4. se il sentiment sulla proposta continua a essere favorevole, uno o più sviluppatori si prendono in carico la modifica e, una volta completata, la rilasciano in un ambiente di test per fare le opportune verifiche sul funzionamento;
5. una volta che si ottiene luce verde da questi test, i miner avranno a disposizione un certo lasso di tempo per dirsi favorevoli o contrari a utilizzare tali modifiche. Affinché uno sviluppo diventi attivo si deve raggiungere un consenso dei miner di almeno il 95%;
6. se non si raggiunge il quorum la modifica viene abbandonata a se stessa e non entrerà mai a far parte di Bitcoin, mentre, se lo si raggiunge, la modifica diventa attiva, ossia utilizzabile da chiunque lo richieda, ed è inglobata nel codice sorgente del sistema;
7. a questo punto i vari nodi del network dovranno decidere se utilizzare o meno la nuova versione del software. Anche a questo livello è necessario un consenso quasi globale affinché la modifica risulti effettivamente in essere;
8. se non si raggiunge un’ampia maggioranza, la modifica risulta essere in stasi e potrebbe venire abbandonata nel futuro, mentre, se la si raggiunge, la proposta viene adottata in maniera definitiva e utilizzata dal sistema.

Sebbene il processo appena descritto sia molto lungo e laborioso, questo risulta essere necessario per il corretto funzionamento del sistema distribuito. Infatti, la necessità di avere un consenso quasi unanime a più livelli sulle modifiche che si apportano al sistema, assicura che queste siano eque (non decide mai una minoranza per una maggioranza), affidabili (in molti le valutano e, se ritenute OK, le supportano), e necessarie (non si sprecheranno mai risorse preziose come il tempo e le capacità di coloro che eseguono gli sviluppi senza una ricompensa economica diretta). Si capisce quindi che, anziché essere un punto a sfavore del sistema, questa è una caratteristica fondamentale.

Bitcoin Improvement Proposal

Lo strumento utilizzato per formalizzare le modifiche da apportare al sistema, è la proposta di miglioramento di Bitcoin, o Bitcoin Improvement Proposal (BIP), ossia una descrizione dettagliata delle variazioni che si vogliono eseguire sul sistema e di cosa queste comporteranno a regime.

Nella figura 1 è riportata la generica struttura di una BIP. Come si vede, questa si compone di una serie di campi: alcuni generici (i primi tre), che servono solo a contestualizzare la proposta, e altri specifici (tutti gli altri), che servono per fornire tutte le informazioni necessarie a valutare l’impatto che questa modifica avrà sul sistema finale, nonché per eseguire i successivi sviluppi nel caso la comunità l’accetti.

Dato che le modifiche possono essere di vario tipo e coinvolgere il sistema a livelli diversi, sono possibili tre tipologie di BIP: standard, di processo, informative.

BIP standard

Sono le proposte utilizzate per apportare modifiche dirette al protocollo di rete, come ad esempio la modifica dei metodi di validazione o dei servizi d’interoperabilità dei nodi. Data la delicatezza di queste implementazioni è necessario raggiungere almeno il consenso del 95% della comunità dei minatori per poterle attivare.

BIP di processo

Sono tutte le proposte che modificano indirettamente il protocollo Bitcoin, come ad esempio l’interazione con wallet esterni o con sidechain. Anche in questo caso è necessario il consenso di almeno il 95% della comunità dei minatori per renderle attive.

BIP informative

Sono le proposte che non modificano direttamente o indirettamente il protocollo Bitcoin, ma servono solo per specificare linee guida o metodi di sviluppo. Queste proposte, non modificando parti sensibili di Bitcoin, non richiedono l’approvazione della comunità.

Il percorso delle BIP

Formalizzata una BIP, questa viene aggiunta al repository GitHub di tutte tutte le proposte passate e presenti su Bitcoin e, successivamente il suo percorso seguirà l’evoluzione del diagramma di figura 2 [2].

Come si vede dall’immagine, inizialmente la proposta si troverà sotto forma di bozza (stato draft), e da qui potrà essere o differita nel futuro (stato deferred), o ritirata dall’autore (stato withdrawn), o rifiutata dalla comunità (stato rejected), o supportata dalla community (stato proposed). Da quest’ultimo stato, se la proposal va a modificare in maniera diretta o indiretta il protocollo di Bitcoin, sarà necessario raggiungere almeno il 95% di consenso dei miner per poterla attivare (stato final/active). Durante il periodo in cui la proposta è avallata dalla community ma non è ancora attivata, questa può essere o rimpiazzata da una più recente (stato replaced) o addirittura diventare obsoleta (stato obsolete); se ciò non avviene, uno o più sviluppatori si prenderanno in carico l’implementazione e la realizzeranno.

Principali BIP già attive sul sistema

Per comprendere meglio in cosa possono consistere queste proposte di miglioramento, elenchiamo di seguito le più significative fra quelle già attive su Bitcoin.

• BIP-32 [3], o Hierarchical Deterministic Wallets, è stata la proposta che ha consentito di standardizzare i wallet deterministici di tipo gerarchico, ossia i seeded wallet, grazie a una definizione formale degli stessi. Ad oggi, tutti gli attori che implementano questi walles si basano su queste linee guida per essere compatibili al 100% con i vari sistemi esistenti.
• BIP-39 [4], o Mnemonic Code for Generating Deterministic Keys, è stata la proposta che ha consentito di standardizzare la generazione della master key o seed di un generico wallet deterministico di tipo gerarchico. Ad oggi, tutti i sistemi che utilizzano HD wallets si basano su questo standard per calcolarne il seed.
• BIP-141 [5], o Segregated Witness, è stata la proposta che ha consentito di separare la firma di sblocco delle transazioni dal resto delle informazioni, così da risolvere il problema della malleabilità delle transazioni, ossia la possibilità di modificarne l’identificativo univoco delle transazioni prima che queste venissero confermate, e contemporaneamente risparmiare quasi il 75% del body di ogni blocco, il che equivale ad aver aumentato la scalabilità del sistema di 4 volte (senza apportare modifiche alle regole di validazione). Ad oggi, questa implementazione è stata una delle più importanti su Bitcoin, perché ha reso possibile l’implementazione del second layer Lightning Network.
• BIP-340 [6], o Schnorr Signature, è stata la proposta che ha consentito di sostituire le vecchie firme ECDSA, ingombranti e un po’ “goffe”, con le più eleganti e leggere firme di Schnorr. Anche questa implementazione ha comportato un aumento della scalabilità del sistema proprio grazie alla riduzione dello spazio necessario per le firme stesse.
• BIP-341 [7] e BIP-342 [8], o Taproot, sono state le proposte basate sulle firme di Schnorr che hanno consentito di sostituire l’indirizzo Bitcoin, ossia l’hash della chiave pubblica, con il merkle root della chiave pubblica per la finalizzazione delle transazioni, ossia per i pagamenti in bitcoin. Grazie a questa implementazione si è ottenuto un aumento della privacy di tutte le transazioni che ad essi fanno ricorso (c’è un merkle root al posto di un address), un aumento generale della scalabilità del sistema (maggior utilizzo delle firme di Schnorr), e una maggiore flessibilità sugli script che il network può supportare.

Possibili sviluppi futuri

Infine, per concludere la panoramica sulle BIP e capire la direzione dei possibili sviluppi futuri di Bitcoin, possiamo analizzare le principali idee su cui la community si sta confrontando per migliorare il sistema.

Queste possono essere divisi in due gruppi, quelle che hanno già una BIP in stato draft e quelle che non hanno ancora raggiunto tale stato.

Modifiche con BIP già in stato di draft

• BIP-118 [9], o SIGHASH o AnyPrevOut o APO, è una proposta basata su Taproot che mira a inserire un nuovo tipo di chiave pubblica, capace di spendere l’UTXO a questa associato anche in maniera parziale. Tale modifica consentirebbe di semplificare Lightning Network (il second layer di Bitcoin), sia nell’apertura di canali fra più di due parti che nel sistema di punizione verso comportamenti sleali.
• BIP-119 [10], o CheckTemplateVerify o CTV, è una proposta che consiste nell’inserire un nuovo OP_CODE nel sistema Bitcoin per renderlo capace di eseguire transazioni con ulteriori restrizioni sulla spendibilità delle monete, oltre a quelle già presenti sulla proprietà della chiave privata. Tale proposta renderebbe il sistema capace di creare ed eseguire transazioni di questo tipo: “Questo UTXO è spendibile se, oltre a rispettare tutte le regole di input, la transazione che lo spende o gli output che lo ricevono rientrano in un determinato insieme di hash”.
• BIP-300 [11] e BIP-301 [12], o DRIVECHAIN, sono le proposte per realizzare una sidechain di Bitcoin capace di separare il funzionamento base della catena nativa da tutta una serie di implementazioni ad hoc, così da estendere le funzionalità core del sistema senza inficiarne il funzionamento. La peculiarità delle catene laterali è quella di utilizzare la moneta della catena nativa, ossia in questo caso i bitcoin, senza però modificarne l’emissione o l’offerta totale. Tecnicamente le monete vengono congelate da uno smart contract sulla catena nativa e ricreate in uguale numero sulla sidechain in questione; una volta utilizzate per il loro scopo, vengono distrutte sulla catena laterale e sbloccate dallo smart contract sulla blockchain base.

Modifiche non ancora in stato di draft

• CISA, o Cross-Input Signature Aggregation, è un’idea che mira a rendere le firme su Bitcoin (e quindi su tutti i suoi layer successivi) aggregabili in maniera lineare, con tutti i vantaggi che questo genera a livello crittografico. Tale implementazione renderebbe il sistema più scalabile (riducendo la dimensione delle firme, specialmente per gli script complessi) e aumenterebbe la privacy grazie alla possibilità di eseguire coinjoint (strategia di anonimazione delle transazioni) nativi.
• GRAFTROOT è un’idea che mira a espandere la capacità di Taproot per rendere eseguibili smart contract sempre più complessi. Grazie a questa modifica, sarebbe possibile risolvere le incompatibilità fra Taproot (già sviluppato) e CISA (da sviluppare);
• G’ROOT è un modo diverso di risolvere il problema precedente, con una generalizzazione ancora più ampia dei possibili smart contract creabili ed eseguibili su Bitcoin;
• MIMBLEWIMBLE è uno sviluppo già realizzato sulla blockchain di Litecoin, la prima catena completamente clonata a partire da quella di Bitcoin. Grazie a questa modifica si è riusciti a introdurre un elevato concetto di privacy nelle transazioni, in quanto sia gli indirizzi di input che di output, nonché gli importi, vengono offuscati. Sebbene questa modifica sia già attiva su Litecoin, non è portabile direttamente su Bitcoin, in quanto gli sviluppi di quest’ultimo, a partire dal suo second layer, sono molto più avanzati e complessi che nel clone.
• RGB NATIVO è un’idea per la creazione di un third layer di Bitcoin, capace di eseguire smart contract più complessi di quelli che a oggi girano sulla blockchain di Ethereum. Con una tale modifica si potrebbero creare DEX, DeFi, NFT e altro ancora, sul questo nuovo layer, basandosi su Bitcoin per il consenso e su Lightning Network per la comunicazione.
• SIMPLICITY è un’idea per implementare un nuovo linguaggio di scripting per gli smart contract su Bitcoin, così da renderne la scrittura più semplice e versatile.

Conclusioni

In questo decimo articolo della serie Bitcoin abbiamo visto come evolve il sistema. Partendo dalla definizione di BIP siamo arrivati a parlare degli sviluppi già attivi sul sistema e di quelli futuri. Nel prossimo articolo ci concentreremo su ulteriori aspetti legati all’evoluzione futura di Bitcoin, parlando del protocollo e della sua “ossificazione”.

Riferimenti

[1] Repository GitHub delle Bitcoin Improvement Proposa
https://github.com/bitcoin/bips.

[2] Mediawiki BIP-2 (BIP process) da repo GitHub
https://github.com/bitcoin/bips/blob/master/bip-0002/process.png

[3] Mediawiki BIP-32 (Hierarchical Deterministic Wallets) da repo GitHub
https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki

[4] Mediawiki BIP-39 (Mnemonic Code for Generating Deterministic Keys) da repo GitHub
https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki

[5] Mediawiki BIP-141 (Segregated Witness) da repo GitHub
https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki

[6] Mediawiki BIP-340 (Schnorr Signature for secp256k1) da repo GitHub
https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki

[7] Mediawiki BIP-341 (Taproot: SegWit version 1 spending rules) da repo GitHub
https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki

[8] Mediawiki BIP-342 (Validation of Taproot Scripts) da repo GitHub
https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki

[9] Mediawiki BIP-118 (SIGHASH_ANYPREVOUT for Taproot Scripts) da repo GitHub
https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki

[10] Mediawiki BIP-119 (CHECKTEMPLATEVERIFY) da repo GitHub
https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki

[11] Mediawiki BIP-300 (Hashrate Escrows) da repo GitHub
https://github.com/bitcoin/bips/blob/master/bip-0300.mediawiki

[12] Mediawiki BIP-301 (Blind Merged Mining) da repo GitHub
https://github.com/bitcoin/bips/blob/master/bip-0301.mediawiki