Bitcoin Magazine
Open Source vs. Source-Available: Cosa insegna il fallimento di Coldcard sugli incentivi del software Bitcoin
Il codice Closed versus Open Source ha diviso l'industria Bitcoin e quella crypto più ampia per oltre un decennio. Gli sostenitori di Bitcoin sostengono da tempo che l'infrastruttura finanziaria del mondo dovrebbe essere costruita in pubblico. La trasparenza e l'auditabilità, dicono, sono non negoziabili quando ci sono in gioco soldi veri. Eppure, le app e i livelli legacy della finanza spesso non sono d'accordo.
Tuttavia, il recente hack di Coldcard, un popolare wallet hardware di auto-custodia dove gli utenti hanno perso oltre 100 milioni di dollari in bitcoin (più di 1.500 BTC), ha messo in dubbio cosa significhi realmente "Open Source". Ha rivelato che forse la maggior parte delle persone, anche molti hardcore bitcoiners, sono poco informati sulla filosofia dello sviluppo software Open Source e quando essa fallisce.
I Principi e la Terminologia
Il linguaggio attorno all'Open Source può essere complicato. Il Free and Open Source Software (FOSS) e il Free/Libre and Open Source Software (FLOSS) si riferiscono a software che soddisfa definizioni formali di libertà per l'utente.
La Free Software Foundation (FSF) definisce il software libero attraverso quattro libertà essenziali:
- Libertà 0: La libertà di eseguire il programma come desideri, per qualsiasi scopo.
- Libertà 1: La libertà di studiare come funziona il programma e modificarlo affinché faccia ciò che desideri (l'accesso al codice sorgente è una precondizione per questo).
- Libertà 2: La libertà di ridistribuire copie in modo da poter aiutare gli altri.
- Libertà 3: La libertà di distribuire copie delle tue versioni modificate ad altri (l'accesso al codice sorgente è una condizione necessaria per questo).
La FSF sottolinea che “libero” si riferisce alla libertà, non al prezzo, in una citazione comune ascoltata dagli sostenitori del FOSS: “‘libero’ come in ‘libertà di parola’, non come in ‘birra gratis.’”
La Definizione di Open Source dell'Open Source Initiative aggiunge dieci criteri pratici. Questi includono la ridistribuzione gratuita senza diritti d'autore, la disponibilità del codice sorgente nella forma preferita per la modifica, il diritto di creare e distribuire opere derivate e nessuna discriminazione contro persone, gruppi o settori di attività — incluso l'uso commerciale. Una licenza deve soddisfare tutti e dieci i criteri per qualificarsi come Open Source secondo lo standard OSI.
“Codice sorgente disponibile” o “codice sorgente visibile” è diverso. Il codice può essere leggibile pubblicamente mentre la licenza limita il diritto di venderlo. Il firmware di Coldcard, ad esempio, è rilasciato sotto i termini MIT più la Commons Clause. La Clausola rimuove specificamente il diritto di “Vendere” il software — definito come fornirlo a terzi per una commissione o altra considerazione in un prodotto o servizio il cui valore deriva interamente o sostanzialmente dal software stesso. In altre parole, il firmware di Coldcard non potrebbe essere utilizzato commercialmente.
Il FAQ della Commons Clause afferma esplicitamente la differenza: “È questo ‘Open Source’? No.” Nota che applicare la clausola significa che il software soddisfa molti elementi della Definizione di Open Source ma non tutti, e quindi non dovrebbe essere chiamato Open Source.
Queste distinzioni sono importanti. Pubblicare il codice sorgente crea la possibilità di ispezione. Concedere l'intero insieme di diritti definiti dalla Definizione di Software Libero o dalla Definizione di Open Source è ciò che rende il software FOSS o FLOSS. Ma avere il badge di approvazione, poter sventolare una bandiera FOSS o FLOSS, non è il punto. La libertà commerciale nel FOSS sblocca incentivi di terze parti per testare e rivedere il codice che altrimenti potrebbe non esserci, sostengono i critici.
Le quattro libertà formano il nucleo filosofico dell'Open Source. In pratica si basano su un'assunzione economica: che un numero sufficiente di persone motivate esaminerà effettivamente il codice. Quando quell'assunzione fallisce, il sistema produce una classica tragedia dei beni comuni, una situazione in cui una risorsa condivisa è sovrautilizzata o trascurata perché gli utenti individuali agiscono nel proprio interesse a breve termine piuttosto che nell'interesse a lungo termine del gruppo.
Ogni persona ha un incentivo a prendere di più (o contribuire di meno) di quanto sia sostenibile, e la risorsa si degrada di conseguenza. Questo accade quando c'è una disallineamento tra l'interesse a breve termine dell'individuo e l'interesse a lungo termine del gruppo. A volte esiste un allineamento; a volte non esiste.
Un sviluppatore di Bitcoin ha messo il problema in modo diretto: “Usare mock e stub di codice Open Source nei test è irresponsabile e miope. Il codice Open Source è considerato sicuro perché chiunque può verificarlo. Se non sei disposto a fare il minimo indispensabile per testare le funzionalità di cui dipendi realmente, allora ti comporti come una sanguisuga.”
Di conseguenza, l'Open Source non crea sicurezza di per sé. Crea la possibilità di verifica. Se quella verifica avviene dipende da incentivi, abilità e attenzione. Si crede che la storia del FOSS si indurisca nel tempo man mano che le vulnerabilità vengono scoperte, divulgate e corrette, creando solide fondamenta su cui altri costruiscono. Il kernel Linux è un ottimo esempio di FOSS indurito; alimenta la stragrande maggioranza dei server del mondo, dell'infrastruttura cloud, dei dispositivi Android e dei sistemi embedded, rendendolo uno dei pezzi di software più ampiamente distribuiti nella storia.
Open Source come dimostrato da Bitcoin Core
Bitcoin Core, l'implementazione di riferimento di Bitcoin, è un altro esempio lungimirante di funzionamento puro dell'open-source nel mondo reale. Il software, che gestisce la maggior parte dell'infrastruttura legata a Bitcoin, è rilasciato sotto la licenza MIT. Il suo processo di sviluppo è ampiamente pubblico per design.
Chiunque può aprire una pull request. La revisione del codice è il filtro principale e il punto di ingresso raccomandato per i nuovi collaboratori. I revisori usano un vocabolario formale—Concept ACK (riconoscimento e accordo con l'obiettivo), Approach ACK (accordo con l'obiettivo e il metodo), ACK con un hash di commit specifico (testato e approvato per la fusione), o NACK (disaccordo, che dovrebbe essere accompagnato da ragionamenti tecnici).
I manutentori valutano il consenso tra i collaboratori e i meriti tecnici di una modifica prima di fondere. Le modifiche critiche per il consenso affrontano una soglia ancora più alta e di solito richiedono una Bitcoin Improvement Proposal e ampie discussioni che durano anni sulla mailing list bitcoin-dev e su IRC.
Non esiste una casta privilegiata di “sviluppatori di Bitcoin Core.” La fiducia si guadagna attraverso la competenza dimostrata nel tempo. I manutentori esistono per motivi pratici—auditing e fusione del codice, gestione delle versioni e moderazione di base—ma il lavoro prodotto è puro codice open-source che chiunque può ispezionare, costruire, forkare o eseguire. Gli sviluppatori che ottengono ‘commit’ di codice fusi in Bitcoin Core sono comunemente chiamati Collaboratori di Bitcoin Core.
Calle, un sviluppatore di Bitcoin open-source di lunga data, ha riassunto recentemente la realtà: “Le persone che pensano che il core sia una sorta di istituzione opaca che opera nell'ombra sono o troppo pigre o troppo stupide per andare a dare un'occhiata da sole. Letteralmente tutto ciò che fanno è pubblico, chiunque può intervenire e il risultato del loro lavoro è puro codice Open Source.”
Il finanziamento per questo lavoro proviene principalmente da strutture nonprofit e di sovvenzione come Brink, OpenSats, Spiral e altre, piuttosto che da una tradizionale roadmap di prodotto aziendale. La discussione e il dibattito tecnico avvengono pubblicamente sulla mailing list bitcoin-dev e nel canale IRC #bitcoin-core-dev su Libera Chat, dove le proposte vengono scrutinizzate prima e durante il processo di pull-request. I problemi e le pull request di GitHub portano spesso storie di commenti che risalgono a un decennio fa. Il risultato è una cultura di sviluppo ottimizzata per la correttezza e l'auditabilità piuttosto che per la velocità o la velocità delle funzionalità commerciali.
L'economia dell'open source
La maggior parte degli utenti di software open-source o disponibile sorgente non legge mai il codice personalmente. Si basano sull'assunzione che altri lo stiano esaminando. Nel caso di Coldcard, un difetto critico di entropia è rimasto nel firmware disponibile pubblicamente per circa cinque anni prima di essere sfruttato e quindi scoperto.
Il bug è entrato nel codice durante una riscrittura importante del 2021 che ha anche rimosso il codice derivato da GPL rimasto in Trezor, il primo hardware wallet e ora il secondo più grande nel settore della custodia autonoma. La libreria al centro del fallimento dell'entropia, che ha sostituito trezor-crypto, si chiama libngu e ha avuto una minima attenzione esterna, con solo 7 stelle e meno di 20 fork in oltre 5 anni di utilizzo in produzione. Confronta questo con le 512 stelle portate dalla libreria trezor-crypto insieme a 212 fork, o i 793 fork e 1.8k stelle del più moderno trezor-firmware. La sola disponibilità della fonte non ha prodotto la revisione che contava, perché altre aziende a scopo di lucro, ben finanziate, erano escluse dal suo utilizzo, o così sostengono i critici.
Le poste in gioco sono più alte in Bitcoin rispetto alla maggior parte dei domini software. Un difetto critico può essere convertito direttamente in fondi liquidi sul mercato aperto. Mentre la prima metà dei fondi Coldcard rubati è ancora detenuta in un pugno di indirizzi e l'hacker potrebbe essere catturato un giorno, gli hacker imitatori che sono seguiti sono stati più cauti, e alcuni hanno rubato più bitcoin e lo hanno riciclato con successo, secondo Galaxy Research. La resistenza alla censura di Bitcoin e la sua transazionabilità immutabile creano sia un potente incentivo per gli attaccanti che un filtro darwiniano; solo i progetti che attraggono continuamente una revisione competente, e gli utenti e le aziende che prendono precauzioni serie, tendono a sopravvivere a lungo termine.
Le scelte di licenza plasmano quegli incentivi secondo gli sostenitori del FOSS che hanno criticato le decisioni di licenza di Coinkite per anni. Le licenze open-source pure massimizzano il pool di potenziali revisori e fork. Le licenze “source available” ristrette possono ridurre il free-riding commerciale ma anche restringere il cerchio delle persone con sia il diritto legale che il motivo economico per investire attenzione profonda. Purtroppo, il peso della revisione del codice ricade sulla società sotto una licenza restrittiva, ponendola in un certo senso più vicina al closed source che all'open.
Come l'IA cambia lo sviluppo open e closed source
L'intelligenza artificiale sta ora anche alterando l'equilibrio tra FOSS e closed source.
Dopo l'incidente di Coldcard, uno sforzo di volontariato noto come Bitcoin Red Team—guidato da sviluppatori tra cui Calle e Rob Hamilton di AnchorWatch, e supportato da OpenSats—ha utilizzato modelli di IA all'avanguardia per scansionare centinaia di repository Bitcoin open-source. In un periodo intensivo, il team ha presentato migliaia di risultati, inclusi dozzine classificati come critici o di alta gravità, attraverso centinaia di progetti. Sono state effettuate divulgazioni responsabili ai manutentori prima della pubblicazione più ampia. L'esercizio ha dimostrato che una revisione sistematica assistita dall'IA può far emergere problemi su una scala e una velocità precedentemente impraticabili per team puramente umani.
Su questo fronte, vale la pena notare che il Red Team ha trovato i modelli cinesi open-weight molto più affidabili rispetto ai modelli americani closed-source, che, anche con permessi informatici e accesso di alto livello, si sono rifiutati di rispondere alle domande del Red Team, una tendenza di cui i sviluppatori americani si rammaricano.
Allo stesso tempo, il flusso di codice generato dall'IA ha creato una nuova pressione di denial-of-service sui manutentori di FOSS. Revisionare l'output dell'IA spesso richiede più tempo rispetto a generarlo. Alcuni progetti open-source al di fuori di Bitcoin hanno limitato i tracker delle issue o imposto rigide regole anti-contributo IA semplicemente per rimanere funzionali.
Fonte: BitcoinMagazine
