Open-Source : Analisi del sorgente di una coin

Come detto nel video, il presente articolo serve soprattutto come supporto di studio e per l’esercizio. Tutte le spiegazioni sono nel video.

Comincio col cercare di limitare la valanga di flame che nel caso precedente è arrivata fino alle minacce di morte (giuro) facendo vedere che quanto fatto è stato precedentemente condiviso e non osteggiato. Sia chiaro: non c’è bisogno del permesso di nessuno per fare questi confronti…

Chi preferisce può scaricare il pacchetto di files di progetto “premasticati” che può rendere più comodo seguire l’esercizio senza farlo (se volete barare insomma). Oltretutto così ci assicuriamo che si possa fare l’esercizo anche nel caso i progetti cadano nell’oblio, vadano persi etc. Tuttavia il consiglio spassionato è :

non fidatevi (mai, non è “satoshi”)
fate l’esercizio anche voi, serve 😉

Iniziamo con lo scaricare i pacchetti dei relativi progetti. Possiamo fare riferimento a questi links:

Primo confronto con Meld

Usando Meld (WinMerge, KDiff3 o simili) vengono rilevate una marea di differenze ma tantissime risiedono nel cambio di nome della coin da Bytecoin a DinastyCoin. Per fare un confronto più utile dobbiamo prima eliminare questa differenza superficiale per concentrarci su quelle più serie.

Annullo differenze nei nomi

Per eliminare questa distrazione occorre fare un “find & replace” in tutti i file sostituendo il nome della coin nel progetto con un generico XXXXcoin. Usiamo due comandi: find e sed.

find dina-2101 | sed -i "s:Dinastycoin:"XXXXcoin:g"
find dina-2101 | sed -i "s:dinastycoin:"XXXXcoin:g"

find fork-952762 | sed -i "s:Bytecoin:"XXXXcoin:g"
find fork-952762 | sed -i "s:bytecoin:"XXXXcoin:g"

Rifaccio confronto con Meld

Eliminata questa differenza posso tornare a usare Meld per vedere le differenze sostanziali. Innanzitutto si vede che la struttura del coldice è identica: ci sono le stesse cartelle con gli stessi file con stesso nome e lunghezze identice. Le differenza sono minime dal punto di vista quantitativo. Per quello che riguarda la qualità e l’impatto è tutto un’altro paio di maniche che, oltretutto, è fuori dallo scopo di questo esercizio.

Conteggio delle righe

Cerciamo ora di farci un’idea approssimativa della percentuale di righe diverse per fare un confronto spannometrico quantitativo di questa differenza. Faremo una semplice proporzione tra il totale delle righe di un progetto (prendiamo quello con meno righe) e il numero delle righe diverse. Ma come facciamo a contare le righe diverse?
Mettiamo tutto il progetto in unico file. Facciamo lo stesso con l’altro.

find dina-2101 -type f -exec cat {} >> dina_whole.txt \;
find fork-952762 -type f -exec cat {} >> fork_whole.txt \;

Possiamo subito contare le righe e vedere quante sono

wc -l dina_whole.txt 
548287 dina_whole.txt
wc -l fork_whole.txt 
548943 fork_whole.txt

Diciamo quindi di considerare 548287 righe di codice totali

Valutazione delle differenze

Usiamo il comando diff, che evidenzia le differenze tra file e separa i blocchi con la stringa “—“. Se cerchiamo le volte che compare la stringa sapremo quanti blocchi di codice sono diversi

diff dina_whole.txt fork_whole.txt | grep -e '---' | wc -l
52

Ottengo come risultato 52, che sono i blocchi di codice che risultano essere diversi tra i due progetti. Ma quante righe circa ci sono di differnza ?

diff dina_whole.txt fork_whole.txt | grep -e "^<" | wc -l
1116
diff dina_whole.txt fork_whole.txt | grep -e "^>" | wc -l
1771

Ottengo due valori: 1116, 1771. Questi rappresentano rispettivamente le righe differenti presenti nel progetto Dynasty Coin e quelle nel progetto ForkNote. Se assumiamo che siano tutte o quasi sostituzioni possiamo approssimare la percentuale di righe diverse con:

548287 : 100 = 1771 : X

da cui

X = (1771 * 100)/548287 = 0,323...

Risultati

La differenza percentuale in termini di righe tra i due progetti è pari allo 0,3%.
Da qui ognuno faccia i suoi approfondimenti e le sue considerazioni. La cosa importante è farsi un’idea di quante informazioni utili si possono ricavare usando github e il codice quando è Open-Source. Segue un’unica considerazione: il codice di un qualsiasi progetto riguardante le criptovalute deve sempre essere Open-Source