Perché gli sviluppatori CORE di Bitcoin vogliono più versioni

I recenti dibattiti sulla possibilità di consentire alle persone di apportare le proprie modifiche al protocollo Bitcoin hanno evidenziato un concetto importante: forse sviluppare Bitcoin CORE, la versione di riferimento del codice, T è l'unico modo in cui le persone possono contribuire.

Una recente modifica al codice Bitcoin che è stato inserito in una variante di Linux chiamata Gentooha fatto infuriare alcune persone prima che lo sviluppatore la disattivasse di default.

"Questi non verranno mai uniti al repository Bitcoin su Github, ma le persone che vorranno utilizzarli potranno farlo", ha affermato Wladimir J van der Laan, sviluppatore principale Bitcoin .

Ma cos'è Github, perché van der Laan ha l'autorità di scegliere cosa inserirvi e, innanzitutto, come viene sviluppato Bitcoin ?

Come si sviluppa il Bitcoin

L'implementazione di riferimento per il protocollo Bitcoin è chiamata Bitcoin CORE. Questo è il codice che Satoshi ha originariamente trasmesso a un gruppo CORE di sviluppatori prima di scomparire.

Quei "discepoli" ora mantengono quel codice, insieme all'aiuto di una comunità più ampia di sviluppatori. L'attenzione è rivolta a rendere il codice più efficiente, ma farlo con attenzione e in modo conservativo, in modo che nulla si rompa.

Bitcoin CORE è gestito tramite un sistema di controllo della versione software chiamato IncitareCiò consente alle persone di KEEP traccia delle versioni del codice su cui stanno lavorando e delle modifiche apportate.

Gli sviluppatori Bitcoin che eseguono Git sui loro computer si collegano a un servizio centrale in modo che possano lavorare tutti contemporaneamente su versioni dello stesso progetto. Questo servizio, chiamato Guida, ha molti progetti diversi gestiti da diversi gruppi di persone. Bitcoin è ONE di quei progetti e ha il suo Pagina Github.

Il codice per il progetto è conservato in un unico posto su Github, chiamato repository. La versione ufficiale e distribuibile del repository Bitcoin è nota come repository upstream, ma le persone che vogliono lavorare sulle proprie modifiche al codice possono creare le proprie versioni del repository, copiandolo in un "fork" online.

Gli sviluppatori possono modificare i loro fork quanto vogliono. Possono chiedere che il loro fork venga unito nuovamente al repository master inviando una "pull Request", che apre la loro versione del repository ad altri membri del progetto, che possono esaminarla e commentarla.

"L'idea è che altri sviluppatori nella comunità esamineranno la modifica", ha spiegato van der Laan. "Quindi, chi invia corregge i problemi sollevati dagli altri. Potrebbe anche essere necessario Rally alcune persone per testare la modifica, soprattutto se è complicata o se c'è una componente soggettiva (ad esempio, per le modifiche all'interfaccia utente o RPC)."

Se a un numero sufficiente di persone piacciono le modifiche apportate in una Request di pull, allora questa viene unita di nuovo al repository master. Ma chi riesce effettivamente a unire il pull?

Si scopre che esiste una sorta di sacerdozio Bitcoin che gestisce ciò che alla fine entra nel codice Bitcoin CORE . Van der Laan, scienziato capo ed ex sviluppatore capo Gavin Andresen, Jeff Garzik, Gregory Maxwell e Pieter Wuille sono il team che prende la decisione finale, e questa T è una cosa che si decide tramite votazione, come si potrebbe trovare in una democrazia.

"I repository Github singoli non sono democratici", ha spiegato van der Laan. "I suoi manutentori collaborano allo sviluppo e decidono cosa viene unito e quando, e cosa no. I problemi tecnici difficili non vengono risolti dal voto popolare".

BIPS e richieste pull

Tuttavia, laddove possibile, lo sviluppo Bitcoin in genere avviene tramite consenso popolare. Ci sono due categorie di cambiamento, in linea di massima.

Il Bitcoin CORE è mantenuto in modo volutamente conservativo e la maggior parte delle modifiche vengono apportate in modo "non controverso e di pulizia", ​​ha detto van der Laan. Si occupano di piccole modifiche incrementali, piuttosto che di grandi modifiche rivoluzionarie. Una patch Bitcoin potrebbe spostare un po' di codice per renderlo più leggibile o forse ottimizzare un po' l'utilizzo della memoria.

C'è un'altra classe di cambiamenti a Bitcoin che hanno molte più ramificazioni, e sono quelli che cambiano le regole del consenso. Le regole del consenso sono le regole tecniche che tutti i client Bitcoin devono rispettare affinché la rete Bitcoin funzioni correttamente.

"Questi devono essere esaminati attentamente. Devono essere discussi prima sulla mailing list, e deve esserci un BIP, e i pull sono generalmente controversi e rimangono aperti per molto tempo per essere discussi", ha detto.

Un BIP – abbreviazione diProposta di miglioramento Bitcoin– è un documento che suggerisce un cambiamento globale ad alcuni aspetti di Bitcoin. Può estendersi a cose esterne a Bitcoin CORE, inclusi i portafogli mobili o la generazione di chiavi nei portafogli hardware. Può anche governare i processi attorno a Bitcoin, come i cambiamenti al processo decisionale.

Chiunque può creare un BIP, a patto che sia scritto inquesto formatoLa comunità ne parla e, se piace, il suo stato può essere cambiato in "attivo" o "finale".

I cambiamenti lungo queste linee sono il cambiamento inPIP 62, che è stato un cambiamento che ha riguardato ildifetto di malleabilità delle transazioni nel Bitcoin.

Cosa aumenta la possibilità che una modifica proposta venga implementata nel protocollo? È utile per l'autore di un BIP aver scritto un esempio del codice affinché le persone possano testarlo e rivederlo, ha aggiunto van der Laan.

Revisione e approvazione

Consulente Bitcoin e revisore della sicurezza Sergio Lernervorrei vedere una maggiore formalizzazione nel processo di approvazione del codice.

"Quando vedi una Request di pull che è stata unita, è difficile dire chi l'ha approvata [e] in che misura la patch è stata esaminata", ha detto. "Devi leggere molti commenti e alcuni '+1' che puoi interpretare come 'Accetto di unirla', ma puoi anche interpretarli come 'Mi piace, ma T ho ancora esaminato il codice'".

Lerner vorrebbe vedere unmulti-firma processo di approvazione delle patch, in cui una certa percentuale di sviluppatori approva formalmente il codice firmando la revisione. Questa sarebbe una versione più grande del processo attualmente utilizzato in alcuni wallet, in cui devono essere utilizzate più firme per un indirizzo Bitcoin da utilizzare.

Altre cose che Lerner vorrebbe vedere includono un registro dei bug trovati e un'analisi del motivo per cui non sono stati individuati in tempo, una revisione esterna del codice incentrata sulla sicurezza per ogni patch, una descrizione formale della documentazione che dovrebbe accompagnare una patch e una descrizione di cosa significhi effettivamente rivedere una patch.

"Significa una revisione del codice sorgente riga per riga? Significa controllare se la documentazione della modifica è sufficiente?" chiese Lerner. "Significa analizzare la modifica rispetto ai vettori di attacco noti?"

Il problema è che tutto questo richiede tempo e risorse Human , ha affermato Lerner:

"Ovviamente implementare tutto questo richiede più housekeeping, un budget più alto e più risorse di sviluppo CORE (che al momento sono scarse). Ma un software che gestisce un'industria da 6 miliardi di $ lo richiede."

Oltre Bitcoin CORE

Mentre Lerner delinea alcuni requisiti per le revisioni del codice, van der Laan riecheggia il discorso principale di Gavin Andresen allaConferenza Bitcoin 2014, dove ha detto chesi potrebbe fare di più per semplificare l'approvazione del BIP.

"Il processo BIP potrebbe necessitare di un po' di lavoro. Sarei felice se gli sviluppatori di altre implementazioni (complete) di nodi fossero più attivi nel commentare le proposte (o nell'elaborare proposte)", ha affermato.

Andresen propone inoltre di spostare la discussione sul BIP e altre questioni relative all'implementazione incrociata dalla mailing list generale sullo sviluppo di bitcoin a una mailing list specifica sul BIP.

Proprio come accade nello sviluppo di un software in un progetto open source, l'onere di realizzarlo ricade sempre sugli utenti.

"Poiché si tratta di un processo intrinsecamente globale, distribuito e disorganizzato, non spetta a una singola organizzazione gestire il processo BIP, quindi l'onere ricadrebbe sulle persone e sulle organizzazioni che desiderano BAND e fare qualcosa", ha suggerito van der Laan.

Ma la Bitcoin Foundation, la principale organizzazione commerciale di bitcoin, T dovrebbe occuparsi di queste cose? No, sostiene. Invece, le cose nel mondo Bitcoin si stanno espandendo oltre, e il team di sviluppo accoglie con favore diverse implementazioni di Bitcoin.

Van der Laan ha detto:

"Il discorso di Gavin al Bitcoin 2014ha chiarito che il suo obiettivo è diversificare. Ha parlato di diverse implementazioni full node, ha persino detto "di più è meglio". Anche se mantenere Bitcoin CORE è il mio lavoro, tendo a essere d'accordo con questo."

Van der Laan ritiene che l'onere non dovrebbe più ricadere sullo sviluppo di Bitcoin CORE.

"Negli anni iniziali Bitcoin CORE era forse eccessivamente importante, e i suoi sviluppatori dovevano KEEP accesa la luce per l'infrastruttura dei nodi (e restare svegli la notte per correggere i bug quando si presentavano). Ma, andando avanti, affinché Bitcoin diventi il ​​sistema distribuito globale che avrebbe dovuto essere, dovremmo andare oltre."

Quindi, potrebbe esserci un sacerdozio benevolo per Bitcoin CORE, nel senso che la decisione finale su cosa inserire nel codice spetta a un piccolo gruppo di persone. Ma ciò T significa che questo gruppo voglia che le cose siano esclusive o elitarie, tutt'altro.

Almeno alcuni degli sviluppatori CORE stanno attivamente incoraggiando altri ad espandere la rete con le proprie implementazioni, partendo dal presupposto che la maggior parte di loro si atterrà alle regole del consenso. Quelli che T faranno perderanno la sincronia, rendendo ovvio chi è in minoranza e costringendoli a risolvere il problema.

L’evoluzione Bitcoin in quella direzione potrebbe creare spazio per i tipi di variazioni Politiche che alcune persone hanno chiesto, pur preservando le regole del consenso: le parti che rendono davvero Bitcoin ciò che è. Ciò allevierebbe anche la pressione su un gruppo di persone sovraccariche che cercano di supportare la Tecnologie alla base di un'attività in rapida crescita. E, se fatto correttamente, potrebbe introdurre alcuni dei nuovi processi che partecipanti come Lerner stanno chiedendo.

La domanda è: come potrà il Bitcoin sviluppare una tale varietà di implementazioni alternative in modo pulito, efficiente e senza i relativi drammi?

Diversificare l'immaginetramite Shutterstock