L’Open Source è qualcosa che ha rivoluzionato internet e la tecnologia nel sui insieme, ma non è tutto oro ciò che luccica, anche qualcosa di così rivoluzionario infatti porta con sè, oltre a numerosi vantaggi e opportunità, alcuni rischi e criticità che non possiamo assolutamente non considerare.
La maggior parte delle persone comprende ed è consapevole che una moneta ha due facce, una buona e una cattiva. Tutto dipende dalla decisione che stanno prendendo.
La maggior parte delle iniziative blockchain sono open source. Ciò implica che chiunque al mondo può consultare i repository pubblici dei progetti ed esaminare il codice sorgente che li sottende.
Il concetto di “open source” è una delle aree più difficili e controverse nello sviluppo del software, secondo la mia esperienza di sviluppatore dal 2009.
Molte persone lo sostengono, soprattutto perché pensano che le iniziative debbano essere trasparenti e che le informazioni debbano essere messe a disposizione della community.
C’è però un’altra organizzazione che si oppone al termine “open source”. La loro principale difesa è che le idee originali dovrebbero ottenere un certo riconoscimento invece di essere riciclate. Inoltre, ritengono che pubblicare pubblicamente il codice possa esporre difetti e falle nella sicurezza, aggiungendo inutile complessità alle iniziative.
Parlando di blockchain e criptovalute, l'”open source” è un altro argomento e una tendenza molto diffusa. In questo articolo anremo ad esplorare tre vantaggi (pro) e tre svantaggi (contro) dell’utilizzo di software open source nei progetti blockchain esistenti e in arrivo.
Indice dei contenuti
Rischio #1: Clonazione di iniziative/progetti in corso
La natura open-source dei progetti blockchain consente a chiunque lavori nel settore di ottenere una copia del codice del progetto e di riutilizzarlo con modifiche minime o nulle. Ciò comporta una serie di conseguenze.
Innanzitutto, l’uso ridondante di script difettosi in numerosi progetti aumenta il pericolo di falle nella sicurezza e di vulnerabilità del codice. Si tenga presente che il codice dello smart contract è immutabile, il che significa che una volta installato nell’ambiente di produzione di una blockchain, né gli sviluppatori né altri possono modificarlo. In altre parole, se un codice è soggetto a errori, la vera falla nel codice è irreversibile. Ogni utente che interagisce con questo codice e con questi contratti si assume un certo rischio.
Un altro problema della duplicazione del codice – e delle idee open source in generale – è che molte persone si limitano a utilizzare le idee di altre persone intelligenti senza fare alcuno sforzo aggiuntivo per migliorare la propria situazione. In poche parole, riutilizzano i codici pronti all’uso. Spesso non comprendono nemmeno la logica del codice. Ancora peggio, a causa della maggiore promozione sui social media, sui forum e così via, molti di questi codici clonati ricevono più attenzione del codice originale.
Infine, ma non per questo meno importante, la duplicazione del codice porta spesso alla diffusione dell’uso degli smart contract tra numerosi protocolli identici. Immaginiamo di avere nove duplicati dello smart contract originale. È possibile che dieci protocolli quasi identici condividano l’uso di questo protocollo. Peggio ancora, a causa della scarsa diffusione di queste iniziative tra gli utenti, alla fine falliranno tutte. Se il traffico e il consumo appartenessero solo al protocollo originale, il concetto o l’iniziativa potrebbero decollare.
Rischio #2: Difetti di sicurezza/vulnerabilità nel codice
Sono disponibili le revisioni pubbliche dei progetti open source. Ciò implica che chiunque può accedere agli archivi del codice sorgente ed esaminare il codice. Può anche scaricare una copia, configurarla ed eseguire il codice in un ambiente di prova o locale, se necessario. Poiché gli sviluppatori di progetti si sforzano di produrre la migliore edizione dei loro codici, questa è una cosa meravigliosa. È molto probabile che ricevano anche commenti e verifiche del codice. Tuttavia, c’è un problema significativo.
Tutto ciò che viene reso pubblico è vulnerabile ad attacchi e hack. Chiunque abbia sufficienti conoscenze di programmazione ed esperienza tecnica può analizzare il codice, trovarne i bug ed eventualmente preparare qualche attacco.
In effetti, se si guarda indietro nel tempo, il noto hack di The DAO sulla blockchain di Ethereum non è stato un attacco difficile. Le due righe di codice di questo contratto contenevano una piccola falla. L’attaccante (o gli attaccanti) hanno trovato questa falla, hanno creato uno script per rivelare questa debolezza e hanno rimosso milioni di dollari dallo smart contract di The DAO.
L’open source può quindi svolgere sia il ruolo di panacea per tutti i mali che di veleno mortale.
Rischio #3: Impegni/Linee di codice che influenzano l’atteggiamento generale
Questo è un esempio intramontabile. Numerosi individui (sviluppatori, manager, stakeholder, ecc.) nel settore dello sviluppo del software utilizzano metriche specifiche per valutare il calibro delle soluzioni software. Ce ne sono due particolarmente degne di nota:
- L’intero numero di linee di codice (compresi i commenti) in un determinato progetto è noto come numero di linee di codice.
- Il numero totale di commit effettuati su repository accessibili a tutti, come GitLab e Github.
- Anche tra i professionisti IT esperti, il consenso prevalente è che il progetto è migliore e più complesso quanto più sono le linee di codice e i commit.
- Non tutti i guru del settore operano in questo modo. Tuttavia, molte persone hanno questo pregiudizio!
- Nel campo delle criptovalute esiste un atteggiamento simile nei confronti delle basi di codice dei progetti.
Il LOC e il numero di commit di vari progetti vengono spesso confrontati in articoli e rapporti. Alla fine di questi rapporti, di solito si trovano conclusioni che consigliano ai lettori di concentrarsi maggiormente sui progetti con LOC e commit maggiori.
Per molti aspetti, ciò è errato.
Tanto per cominciare, il LOC è un’idea fraintesa. Non è sempre vero che più linee di codice equivalgono a una logica più forte o a una soluzione più complicata. È giusto, ma in genere è vero il contrario. Le basi di codice diventano sempre più piccole grazie a tutti i miglioramenti apportati nella creazione di librerie e framework di terze parti e all’introduzione di idee come il clean coding. Gli smart contract che operano sulle reti sono un altro fattore. Questi contratti sono spesso caratterizzati da una logica molto semplice e da un codice molto ridotto (tra le 10 e le 50 righe). In genere devono essere in grado di eseguire UNA sola operazione, e di farlo perfettamente.
Inoltre, tenete presente che un numero maggiore di commit non sempre indica un livello più alto di attività del progetto. Molti progetti manipolano questa misura aggiungendo contributi inutili e modifiche minori alle loro basi di codice. I commit spesso riguardano la riparazione di problemi o il miglioramento di funzionalità. Tenete presente che questi difetti non esistono (o sono rari) nei programmi stabili o ben sviluppati e la funzionalità è sufficientemente affidabile.
Opportunità #1: completa trasparenza e visibilità
La tecnologia open source comporta una visibilità pubblica, come suggerisce il termine. Nell’ultima sezione abbiamo parlato dei pericoli di un progetto open source. L’avere cioè il proprio codice sorgente pubblico e disponibile a chiunque, a quanto pare, offre anche molti vantaggi.
Tanto per cominciare, i progetti non devono nascondere nulla ai loro utenti. I progetti beneficiano di piena visibilità e apertura grazie all’open source. Un utente può semplicemente ispezionare il codice o chiedere a un professionista di farlo per lui se ha domande su qualcosa in un particolare progetto. Di conseguenza, sarà in grado di fare azioni commerciali e investire in modo più saggio.
L’esposizione al pubblico controllo impone inoltre agli sviluppatori di progetti di impegnarsi al massimo per fornire codice di alta qualità e privo di errori. Se non c’è trasparenza nel codice, i programmatori possono facilmente creare codice difettoso e insicuro, perché nessuno è a conoscenza di ciò che accade in background.
Opportunità #2 – Evitare di ripartire da zero
I progetti blockchain non hanno bisogno di partire da zero come molte altre soluzioni software. Il fatto che praticamente tutto nel settore della blockchain sia open-source ha qualcosa a che fare con questo.
Se siete interessati a creare un progetto blockchain e avete competenze di codifica, potete facilmente cercare tra le decine di migliaia di repository pubblici per scoprire un codice di base adatto alle vostre esigenze e aggiungervi miglioramenti.
Le versioni clonate di questi repository spesso hanno già molti dei loro codici controllati e con i bug più comuni risolti. Di conseguenza, avrete una base solida su cui costruire.
In questo modo risparmierete una tonnellata di denaro, tempo e fatica!
Opportunità #3: Recensioni e feedback pubblici
Infine, gli sviluppatori possono aspettarsi di ricevere più commenti e raccomandazioni dai progetti open source. La comunità open-source è incredibilmente generosa e ci sono innumerevoli sviluppatori ed esperti di materia che forniscono liberamente i loro consigli e la loro assistenza agli sviluppatori di progetti open-source.
Soprattutto per i progetti blockchain con risorse minime, questa è un’opportunità fantastica. Basta pubblicare gratuitamente il proprio codice online, nella speranza di ricevere un’ampia gamma di feedback utili. Entrambe le parti traggono vantaggio dal gioco.
I commenti legati alla revisione rientrano in un’altra categoria. Come già accennato, una volta che il codice del vostro smart contract è stato inserito nella blockchain, non può essere modificato. Di conseguenza, dovreste procedere al processo di distribuzione con grande cautela. Le revisioni sono una pratica vantaggiosa svolta da molti progetti. Le società di revisione, sia pubbliche che private, sono ampiamente disponibili. Esaminano i codici sorgente e utilizzano i risultati per produrre rapporti di revisione. Spesso conducono uno studio approfondito nelle seguenti aree:
grammatica, strutture dati, velocità, sicurezza, errori potenziali e codice pulito.
La capacità di essere completamente trasparenti nei confronti della comunità è uno dei requisiti per essere ammessi alle revisioni. Pertanto, è possibile realizzarla con progetti open source.
Considerazioni finali
L’uso di software open-source è una tendenza in crescita nel settore. È un argomento difficile anche nella criptosfera. Alla fine, presenta sia molti vantaggi che svantaggi.
Pro:
- Rende i progetti completamente trasparenti e visibili agli utenti.
- L’utilizzo di componenti di codice controllati e pronti all’uso nei programmi di altri sviluppatori è vantaggioso.
- Rende più facile per gli sviluppatori di progetti blockchain ottenere commenti e input significativi dal pubblico.
Contro:
- È incline alla duplicazione illimitata del codice e al furto di proprietà intellettuale.
- Rende gli hacker malvoli e gli aggressori consapevoli delle falle di sicurezza e delle vulnerabilità del codice.
- La comunità può interpretare erroneamente la quantità di linee di codice e di commit completati.
Dopo tutto, l'”open-source” può avere lati belli e brutti, proprio come molte altre cose nel settore tecnologico.
“La maggior parte delle persone capisce che una moneta ha due lati, uno buono e uno cattivo. Tutto dipende dalla decisione che si sta prendendo.”
_Michael Oneill
*NB: Le riflessioni e le analisi condivise sono da intendere ad esclusivo scopo divulgativo. Quanto esposto non vuole quindi essere un consiglio finanziario o di investimento e non va interpretato come tale. Ricorda sempre che le scelte riguardo i propri capitali di rischio devono essere frutto di ricerche e analisi personali. L’invito è pertanto quello di fare sempre le proprie ricerche in autonomia.
