Com'è rivedere il codice di Bitcoin

Il 19 giugno, lo sviluppatore di Chaincode John Newbery ha riunito un gruppo di sviluppatori per esaminare una proposta di modifica al codice Bitcoin.

Avvenuto tramite Internet Relay Chat (IRC), l'argomento era se il cambiamento, che avrebbe aiutato a impedire a un gruppo di minatori non autorizzati diaccelerando la velocità con cui vengono prodotti i blocchi di bitcoin, è una <a href="https://bitcoin-core-review-club.github.io/15481.html one with">ONE positiva https://bitcoin-core-review-club.github.io/15481.html con</a> rischi per la sicurezza o impatti negativi limitati.

L'obiettivo di Newbery è quindi quello di trasmettere le sue conoscenze sulla revisione di tale codice.

Questo blocco dell'attacco "timewarp" è stato un cambiamento concreto?

"Il timewarp sfrutta questo fenomeno spostando il blocco di regolazione della difficoltà nel futuro e poi il blocco successivo nel presente", ha scritto Newbery, spiegando il vettore di attacco.

Ma il fatto che Newbery tenga queste sessioni può essere visto come un segno della maturità della comunità di sviluppatori di bitcoin, poiché questo è ONE esempio di come i migliori programmatori del progetto abbiano lavorato duramente per rendere il progetto più inclusivo. Il processo di revisione del codice forse T è mai stato discusso così apertamente e approfonditamente prima.

Newbery ha avviato il Bitcoin CORE Review Club <a href="https://bitcoin-core-review-club.github.io/">https://bitcoin-core-review-club.github.io/</a> per dare ai programmatori suggerimenti su come capire come esaminare una modifica e determinare se è vantaggiosa per la Criptovaluta. Le trascrizioni delle riunioni vengono ora pubblicate sul sito Web ogni settimana.

Ciò è possibile perché il codice di Bitcoin è open source e risiedesu GitHubper chiunque abbia una connessione internet da guardare, o anche modificare. Questo processo ha portato il progetto da programmatori un tempo chiamati "macchia monolitica"a un software più facile da leggere per gli sviluppatori con bug meno critici. Le persone cercano costantemente di migliorarlo, con l'obiettivo finale ambizioso di renderlo una base di codice degna del futuro del denaro.

Quindi, è anche possibile essere ONE delle persone che contribuiscono al codice di Bitcoin. A differenza del codice proprietario, il suo codice può essere visto e utilizzato da chiunque, il che è noto come "open source".

ONE dei motivi per cui viene chiamata "denaro programmabile" è che, a differenza di altri soldi digitali, chiunque nel mondo con le giuste conoscenze può provare ad aggiungere nuove funzionalità di codice al denaro. ONE dei modi per Imparare la base di codice è rivedere e testare il codice inviato dai programmatori, per assicurarsi che funzioni davvero e T introduca un bug o, sfortunatamente, non divida accidentalmente la rete Bitcoin a metà.

Ma sfogliando le pagine del codice e le centinaia di modifiche proposte, è difficile sapere da dove cominciare.

"Questo club IRC settimanale è per le persone che vogliono aiutare a rivedere le richieste di pull Bitcoin CORE ma trovano il processo intimidatorio", spiega il sito web del club, proseguendo:

"Revisionare e testare le richieste di pull è il modo migliore per iniziare a contribuire a Bitcoin CORE, ma è difficile sapere da dove iniziare. Ci sono centinaia di richieste di pull aperte, molte richiedono molta conoscenza contestuale e i Collaboratori e i revisori spesso usano una terminologia non familiare."

Pertanto, mentre il codice per questa valuta digitale è in circolazione e chiunque può guardarlo o modificarlo, non è necessariamente facile farlo. Ci vuole pratica per sapere cosa esaminare.

Ecco come funziona il processo.

Chiunque può farlo

Per iniziare, gli utenti possono andare su GitHub, un sito web che ospita tutti i tipi di progetti di codice open source. Ce n'è ONE specifico per Bitcoin CORE, l'implementazione software sottostante Bitcoin che la maggior parte degli utenti esegue.

Noterai che c'è molto da fare su GitHub, ma rivedere il codice significa fondamentalmente guardare "richieste di pull, una serie di modifiche che gli sviluppatori dell'intero ecosistema hanno sottoposto a revisione.

In altre parole, ci sono 300 modifiche che T sono state ancora esaminate a sufficienza per essere aggiunte ufficialmente alla base di codice, dal rendere la documentazione che descrive il codice più facile da leggere al migliorare le prestazioni di Bitcoin.

A questo punto, gli sviluppatori stanno cercando di decidere se queste modifiche debbano essere approvate. Il problema è che ci sono pochi sviluppatori che hanno abbastanza esperienza nella revisione delle modifiche al codice per determinare se debbano essere aggiunte ufficialmente alla base di codice. Per questo motivo, ONE collaboratore Bitcoin CORE una volta ha descritto l'elenco delle richieste di pull come un "cimitero di idee fantastiche."

Ecco perché Newbery sta cercando di dare il suo contributo in questo processo.

Quindi, come ONE fa effettivamente a rivedere una modifica? Come Newbery descrive sul sito web del club, ci sono alcuni passaggi chiave per iniziare, come guardare attraverso il "contribuire alla guida Bitcoin CORE" e armeggiando con C++, il linguaggio di programmazione in cui è scritto Bitcoin CORE .

Il passo successivo è semplicemente scegliere una modifica da esaminare. Con oltre 300 richieste pull attive e vegete, da dove ONE inizia? Le scelte migliori per chi T conosce ancora la base di codice sono le modifiche al codice che sono specificamente etichettate come "buoni primi numeri".

Una volta completate le fasi preliminari, lo sviluppatore deve "clonare" il repository o utilizzare git per creare una copia del codice di base sul proprio computer, in modo da poter verificare che la modifica funzioni come previsto.

Basta un semplice comando per copiare l'intero codice di base sul tuo computer.

Da lì, puoi rivedere la Request di pull. Gli sviluppatori in questione dovrebbero quindi eseguire tutti i "test", per assicurarsi che la modifica del codice T faccia inciampare accidentalmente un altro pezzo di codice, quindi passare alla revisione del resto del codice.

Nella mente di un recensore

A cosa devono pensare i revisori?

Innanzitutto, ci sono preoccupazioni di alto livello. Determinare se un cambiamento debba essere fatto, specialmente ONE critico, si basa fondamentalmente su un "consenso approssimativo", il che significa che la maggior parte Collaboratori attivi concorderebbe sul fatto che un cambiamento debba essere perseguito.

In un altro incontro del club, Newbery ha affermato https://bitcoin-core-review-club.github.io/16060.html:

"I miei pensieri sull'apertura di richieste pull: nessuno ti deve una revisione. Chiunque revisioni il tuo codice ti sta facendo un favore. Se apri una Request pull, stai competendo con altre richieste pull per il tempo di revisione."

"Se hai dubbi su quanto utile pensino gli altri la tua Request di pull, sentiti libero di chiedere su #bitcoin-core-dev o chiedendo direttamente ad altri Collaboratori", ha aggiunto Newbery, riferendosi a un altro gruppo IRC in cui gli sviluppatori possono porre domande relative allo sviluppo Bitcoin CORE .

Detto questo, gli sviluppatori T sempre concordano se una modifica valga la pena di essere aggiunta o meno. ONE settimana il gruppo di sviluppatori si è concentrato su una controversa modifica del codice. Alcuni hanno sostenuto che il male superava il bene, mentre altri sostengono ancora che potrebbe essere utile.

Ma anche se l'idea è ONE in generale, ci sono anche preoccupazioni di livello inferiore. Ci sono bug? La modifica del codice è accompagnata da test che assicurano che la modifica del codice funzioni come previsto? Queste sono le domande a cui si dedica molto tempo di revisione per rispondere.

Ad esempio, nell'incontro del 29 maggio (di cui puoi trovare la trascrizione completa qui <a href="https://bitcoin-core-review-club.github.io/15741.html">https://bitcoin-core-review-club.github.io/15741.html</a> ), gli sviluppatori hanno esaminato un miglioramento delle prestazioni per la parte wallet del nodo Bitcoin .

Un collaboratore che usa lo pseudonimo "Ariard" ha guidato l'incontro esaminando il processo di revisione che hanno sviluppato nel tempo. "Ho cercato prima di identificare che tipo di PR fosse: Doc, stile del codice, correzione di buf, nuova funzionalità o aggiunta di test. Perché [ Opinioni me] conoscere questo fatto guiderà il modo in cui leggerete i commit la prima volta, quanto tempo vi servirà per la revisione e che tipo di test sono necessari", ha affermato lo sviluppatore.

Un altro recensore ha sottolineato di aver notato un miglioramento semplicemente controllando quanto tempo impiegava il codice a funzionare, prima e dopo. "La mia importazione di 10000 chiavi è passata da 8 minuti a 3 secondi xD", ha detto un altro utente che si fa chiamare 'jb55'.

Le trascrizioni delle riunioni sono ulteriormente disseminate di altri suggerimenti su come semplificare questo processo e renderlo più facile da rivedere, con altre riunioni da programmare in futuro. Le prossime due sezioni saranno guidate dal redattore tecnico e collaboratore Bitcoin David Harding.

Immagine di Adam Back tramite gli archivi di Consensus