Anatomia del grande dibattito sulla scalabilità di Bitcoin

Il dott. Paul Ennis è assistente di ricerca presso il Centro per l'innovazione, la Tecnologie e l'organizzazione dell'University College di Dublino, specializzato in studi Bitcoin e blockchain.

In questo articolo Opinioni , il dott. Ennis analizza come si è evoluto finora il dibattito sulla scalabilità di Bitcoin, esaminando i vari sforzi concorrenti, i loro processi e cosa dicono le differenze sulla comunità degli sviluppatori e sulla sua cultura.

Il dibattito sulla scalabilità di Bitcoin è chiaramente ONE dei suoi momenti più decisivi.

Ha messo nettamente a ONE le basi di utenti, sia attraverso infiniti dibattiti su Reddit, media digitali o persino al "top" livello dei team di sviluppo. Ha anche sollevato questioni significative sulla centralizzazione e sulla relazione un po' imbarazzante di bitcoin con l'industria mineraria per lo più basata in Cina.

In questo post, cercherò di documentare diverse parti del dibattito, così come si è svolto da diverse prospettive. Non mi considero legato a nessun filone specifico e ho cercato di essere il più neutrale possibile. Le correzioni sono sempre benvenute.

Il dibattito ha riguardato una questione tecnica centrale che ha avuto anche implicazioni significative su come è governato il Bitcoin . Per il Bitcoin Classico team, ciò significava, in sostanza, trovare una soluzione che risolvesse il problema del riempimento dei blocchi dovuto agli elevati volumi di transazioni, trovando al contempo un modo per spostare la governance dal team di sviluppo Bitcoin CORE alla comunità di mining.

ONE dei primi tentativi di affrontare questo problema venne da Mike Hearn, all'epoca sviluppatore Bitcoin CORE , sotto forma di BIP 64. BIP 64 fu annunciato nel Giugno 2014, ma il client Bitcoin XT (il "precursore" di Classic) è emerso nel dicembre 2014.

Bitcoin XT non è mai decollato, ma ha indicato la convinzione iniziale di Hearn nella necessità di un nuovo approccio al problema della scalabilità. Tuttavia, c'era supporto per XT da ONE gruppo notevole della rete Bitcoin : vale a dire le comunità di pagamento e portafoglio.

Ciò è probabilmente dovuto al fatto che più piccoli sono i blocchi, più gli utenti devono pagare in commissioni di transazione e più lenta diventa la rete. Poiché questi servizi sono orientati verso persone che vogliono effettuare transazioni rapide, una rete costosa e lenta ha effetti negativi su un'adozione più ampia.

Emerge il problema dell'hard fork

Nel giugno 2015, l'allora capo scienziato della Bitcoin Foundation Gavin Andresen annunciò BIP 101. BIP 101 era srotolatoin XT nell'agosto 2015, ma non ha mai avuto molto successo nella comunità mineraria.

Tuttavia, il fatto che sviluppatori Bitcoin così illustri stessero cercando attivamente di introdurre un hard fork ha dato il via a un acceso dibattito non solo su questa questione tecnica, ma anche su come i cambiamenti di Bitcoin avrebbero dovuto avvenire in futuro.

Poiché Bitcoin XT non stava ottenendo supporto, è stata avanzata una proposta meno drastica per aumentare la dimensione del blocco tramite un hard fork che avrebbe aumentato il limite a 2 megabyte. Noto come Bitcoin Classic, questo fork è stato sviluppato da attori cruciali nella più ampia comunità Bitcoin , in particolare Gavin Andresen e Jeff Garzik (fondatore di Bloq). Gli altri sviluppatori erano Pedro Pinheiro (Blockchain), Tom Zander e Jon Rumion.

Ci sono delle discrepanze tra la versione originale e il sito web di Classic su questo fronte. Sul sito Peter Rizun è elencato come sviluppatore, ma sulla versione come consulente esterno. Tuttavia, sono i nomi che compaiono sulla versione e non sul sito a essere più interessanti per comprendere la storia di Classic.

Il comunicato di Classic afferma che il mining sarà sotto la responsabilità di Marshall Long, attuale CTO del servizio di cloud mining FinalHash. Non ci sono molte informazioni, oltre al suo nome, sul comunicato riguardo al suo ruolo in Classic (anche se è abbastanza ben inserito da aver partecipato alla Satoshi Roundtable). Un altro nome interessante è Jonathon Toomim, elencato come consulente esterno, che ha lavorato parecchio su Classic prima di cedere le redini ad Andresen (che sembra non aver voluto svilupparlo all'inizio, secondo Guy Corem qui).

Infine, Olivier Janssens è elencato come facilitatore nella release (e come "utente" sul sito Classic). Janssens è un giocatore piuttosto influente poiché, insieme a Long, ha assicurato Toomim come sviluppatore originale per Classic. La presenza di Janssens è importante perché, durante il suo mandato come membro del consiglio della Bitcoin Foundation, ha fatto trapelare dettagli dannosi sul modo incompetente in cui era gestito.

Per molti versi, quindi, Classic può essere visto come un tentativo di sfidare la struttura di governance della Bitcoin Foundation, attualmente non coinvolta nello sviluppo, ma anche, cosa più importante, il team di sviluppo Bitcoin CORE in quanto tale.

Le due motivazioni per Classic possono essere ampiamente viste nel BIP 100 di Garzik, che essenzialmente vedrebbe i minatori decidere la dimensione appropriata del blocco e il suo compromesso BIP 102, che avrebbe aumentato la dimensione del blocco a 2 MB come compromesso per garantire che i blocchi non diventassero troppo pieni (mirato a risolvere il problema delle transazioni lente e costose nell'immediato).

Il modo in cui tutto questo si è svolto passerà alla Bitcoin come l'inizio di ONE dei dibattiti più controversi, ma anche affascinanti, su cosa dovrebbe essere il Bitcoin . La prossima volta ci concentreremo su come i minatori hanno reagito all'introduzione di Classic nell'ecosistema.

CORE Bitcoin

In questa sezione, devo fare un po' di lavoro preliminare riguardante il team di sviluppo Bitcoin CORE e il suo processo di sviluppo.

Ciò è necessario perché il Bitcoin è insolito in termini organizzativi perché è, per progettazione, una rete nominalmente decentralizzata (senza un leader o con ONE"assente"). Tuttavia, ci sono quasi gerarchie operative. Principalmente tra gli sviluppatori e i minatori per lo più cinesi. Come si arriva al consenso? La questione è immensamente complessa quando ci riferiamo all'ecosistema Bitcoin più ampio, ma il processo di sviluppo diretto è molto più diretto.

Lo sviluppo Bitcoin è aperto a tutti gli sviluppatori interessati al progetto.

La maggior parte della sua attività avviene aBitcoin in azionerepository. Il software che viene sviluppato è noto comeCORE Bitcoin; ed è open source. È importante notare che, sebbene questa sia la sede dominante, la discussione avviene anche su una mailing list nota comesviluppo bitcoinEsiste anche un canale IRC (Internet Relay Chat) più informale che viene registrato (irc.freenode.net #bitcoin-dev).

In genere, il processo prevede che gli utenti suggeriscano "richieste di pull" che sono simili a suggerimenti che sono stati sottoposti a revisione da altri sviluppatori. Il loro scopo è quello di correggere o migliorare la base di codice.

Non è raro vedere proposte, suggerimenti o dibattiti emergere nelle comunità Bitcoin di Reddit o nei forum dedicati a Bitcoin .

Come funziona CORE

Molti degli sviluppatori di Bitcoin CORE elencati hanno contribuito una volta al repository.

Un altro sottoinsieme ha contribuito tra due e 10 volte. Da lì, i numeri si assottigliano fino ad arrivare a quello che può essere definito il CORE, nel senso normale, del team di sviluppo che esiste perché "una certa gerarchia è necessaria per scopi pratici.

Esistono quindi dei "manutentori" del repository che sono responsabili dell'unione delle richieste pull, nonché un "manutentore capo" che è responsabile del ciclo di rilascio, dell'unione complessiva, della moderazione e della nomina dei manutentori.

In altre parole, non esiste un team ufficiale di sviluppatori CORE , ma ci sono dei manutentori e un manutentore capo. Sono queste persone ad avere l'ultima parola se una patch diventa parte di Bitcoin CORE. Se la patch risolve un problema relativamente minore, il processo segue i criteri generali che 'una patch è in linea con i principi generali del progetto; soddisfa gli standard minimi per l'inclusione; e giudicherà il consenso generale dei Collaboratori.'

Per gli studiosi questo processo è simile alla revisione paritaria, ma meno formalizzato.

Ancora più interessante è il punto in cui la patch si riferisce alle regole del consenso, poiché queste sono fondamentali per la natura di Bitcoin.

Richiedono un processo molto più rigoroso e tali suggerimenti tenderanno a essere ascoltati solo quando provengono da sviluppatori leader. Il dibattito sulla scalabilità è ONE in cui questo è diventato abbastanza chiaro anche a coloro che guardano Bitcoin dall'esterno.

Qui è importante fare una QUICK distinzione.

In Bitcoin è possibile implementare un "soft fork" che potrebbe, ad esempio, migliorare o risolvere un problema relativamente minore. Gli utenti non saranno tenuti ad aggiornare il loro software, ma saranno incoraggiati a farlo. Con un hard fork, tutti devono effettuare l'aggiornamento alla nuova implementazione. Poiché un hard fork "rompe" o scarta una vecchia regola essenziale per il protocollo attuale, è possibile che emergano due blockchain distinte con regole che sono in contraddizione ONE loro.

Gli hard fork sono, quindi, prevedibilmente controversi, poiché introducono la possibilità di una scissione. Tale scissione tecnica può sempre portare alla possibilità di una scissione della comunità.

Note minori

Vale la pena menzionare altre piccole note: molte persone potrebbero aver credutoBIP (Proposte di implementazione Bitcoin ) si riferisce a una sorta di piattaforma per suggerimenti che richiedono un hard fork.

Questo è in gran parte un effetto del dibattito sulla scalabilità, in cui i BIP concorrenti venivano spesso prodotti semplicemente come idee concorrenti su come scalare al meglio (o meno). In effetti, alcuni BIP forniscono semplicemente informazioni. Molti BIP sono stati applicati, ma molti altri no. Alcuni sono stati ritirati e altri sono in stasi.

Sono complicati, ma nel dibattito sulla scalabilità sono emersi come un mezzo chiaro per le visioni contrastanti su come procedere con Bitcoin generalmente.

Ora è importante ricordare che a volte gli sviluppatori diventano dormienti o si presume che siano completamente inattivi. Ad esempio, l'inventore del sistema BIP,Amir Taaki, un tempo era molto visibile nel mondo dei Bitcoin, ma ha smesso di impegnarsi attivamente in esso.

Ci sono anche, devo sottolineare, un numero enorme di persone che tralascerò in seguito e tra queste ci sono Collaboratori molto importanti (anche se meno rumorosi) di Bitcoin CORE. Alcuni sviluppatori sono semplicemente silenziosi e lavorano in background.

Per coloro che non hanno alcun interesse evidente nei dibattiti pubblici, li ho lasciati da parte.

Il team CORE

Ora, tecnicamente coloro che hanno lavorato su Classic non hanno mai smesso di lavorare su CORE di per sé.

Ad esempio, Gavin Andresen (BIP 101) è sempre stato considerato centrale per CORE. È stato anche notoriamente il Chief Scientist presso Fondazione Bitcoin(pagato) e ora è finanziato dalIniziativa di valuta digitale del MIT Media Lab. Jeff Garzik (BIP 100/102) sarà sempre una figura importante. Mike Hearn non è più impegnato con Bitcoin e si è trasferito aR3CEV.

È, ovviamente,L'uscita drammatica di Hern da Bitcoin che ha davvero scaldato gli animi con il dibattito sulla scalabilità.

Ora, insieme ad Andresen all'iniziativa del MIT Media Lab troviamoCampi di Cory che non è mai stato troppo esplicito. Poi abbiamo Wladimir J van der Laan con l'iniziativa del MIT (entrambi finanziati dalla Bitcoin Foundation).

Van der Laan è anche il responsabile della manutenzione e spesso sembra essere il più anziano degli altri due responsabili della manutenzione, vale a direJonas Schnelli E Marco Falke. Nessuno di questi ha avuto un ruolo particolarmente eloquente nel dibattito sulla scalabilità, sebbene Schnelli sia una figura molto più visibile. Coloro che non sono manutentori, ma hanno avuto di più da dire sul dibattito sulla scalabilità includonoEric Lombroso, amministratore delegato diCifratura.

Ci sono ancora alcuni membri di Bitcoin CORE su cui dovremmo concentrarci.

Innanzitutto vorrei concentrarmi sulla relazione tra CORE e Flusso di blocco(fondata nel 2015).

Blockstream è un'entità distinta da CORE in quanto è un'impresa finanziata (vedere Qui E Qui). Sviluppatori CORE come Jorge Timón E Matt Corallo sono tra una concentrazione di sviluppatori CORE sotto il banner Blockstream. In altre parole, è davvero Blockstream che finanzia il numero più alto di sviluppatori CORE .

Pertanto è essenziale capire cosa Blockstream sta effettivamente tentando di fare. Non abbiamo ancora trattato tutti quelli che vorremmo su CORE, ma prima dobbiamo fare una QUICK digressione.

Blockstream è orientata allo sviluppo dicatene lateralied è stato originariamente annunciato dal'inventore dell'hashcash Adam Back e Austin Hill(nessuno dei quali è uno sviluppatore CORE ). Le sidechain sono utili per una serie di motivi, ma non ultimo perché offrono un modo per innovare senza introdurre un hard fork.

Una tale modifica delle regole del consenso richiede tempo. Per coloro che sono impegnati nella prospettiva decentralista, e per i quali i cambiamenti tecnici in Bitcoin dovrebbero essere gestiti con estrema cura, le sidechain offrono una soluzione. Per essere precisi, stiamo parlando di pegged sidechain che sono, più o meno, blockchain personalizzate per il "lato" di la blockchain Bitcoin .

Per molti versi, un'azienda come Coinbase è fondamentalmente una quasi-sidechain. Quando invii bitcoin lì, escono dalla solita griglia peer-to-peer. Coinbase avrà probabilmente un pool di bitcoin, una riserva (liquidità) e ciò che sposti potrebbe non essere la stessa moneta. Quindi agisce come una quasi-sidechain nella misura in cui sconvolge la solitaetica di Bitcoin in cui ogni persona dimostra di possedere la chiave privata per spendere alcune monete.

Ma il bonus è che puoi fare le cose piuttosto velocemente con Coinbase. E, naturalmente, questo è stato un argomento cruciale sollevato durante il dibattito sulla scalabilità: vale a dire che dovremmo concentrarci sul miglioramento della velocità delle transazioni lungo queste linee come preoccupazione più importante per una valuta digitale.

Nel complesso, le sidechain Seguici fondamentalmente il modello "sandbox". Isolando la sidechain dalla catena principale, pur consentendo la trasferibilità dell'asset, diventa possibile correre più rischi. T vuoi metterti a rompere la tua sidechain, ma T perderai tutto se lo fai.

Funziona più o meno nello stesso modo in cui sandboxare il tuo browser significa che un bug del browser T finirà per distruggere l'intero sistema operativo. Inoltre, i tuoi bitcoin non sono mai a rischio poiché agiscono semplicemente come token sulla o per la sidechain. Abbastanza rapidamente, forse a causa di una mancanza di adozione, Elementi della catena lateraleè stato annunciato.

Elements era più funzionale, rendendo la vita più facile per gli adottanti, ma conteneva una caratteristica sottile nota comeTestimone segregato. Segwit era l'idea diGregorio Maxwell, sviluppatore CORE e anche membro di Blockstream. La bozza originale di segwit avrebbe richiesto un hard fork, ma, fortunatamente, Luca Dashjrè venuto in soccorso (dettagli qui) con un metodo che gli consentirebbe di essere un soft fork.

Segwit è stato, dopo la concettualizzazione di Maxwell e la correzione di Dashjr, codificato dall'ultimo membro che dovremmo nominare, il brillante programmatoreDott. Pieter Wiuelle (di Blockstream) – con il contributo, come per la maggior parte delle iniziative Bitcoin, di altri sviluppatori.

Segwit ora sta andando avanti, anche se uncronologia esattaper la sua uscita non è stata indicata.

Questo post è la ONE e la seconda parte di una serie del Dott. Ennis, ripubblicata qui con il suo permesso. Per i post futuri, Seguici il Dott. Ennis su Medio.

Immagine dello scheletrotramite Shutterstock