La parola "decentralizzato" è diventata una medaglia che molti progetti si appuntano da soli. Ma basta guardare da vicino per capire che c'è decentralizzazione e decentralizzazione. Una rete può avere mille nodi e restare controllata da un unico team; un protocollo può essere aperto alla partecipazione ma chiuso al controllo. La differenza, nel peer to peer, la fa quasi sempre una cosa: il codice è leggibile da chiunque?

Perché il P2P richiede fiducia tecnica

In una rete centralizzata la fiducia è concentrata in un attore: lo scegliamo, firmiamo un contratto, ci affidiamo alla sua reputazione. Nel P2P questa struttura salta. Non c'è più un fornitore a cui rivolgersi se qualcosa va storto. Quello che garantisce il comportamento corretto del sistema è il protocollo — cioè, alla fine, del codice.

Ma come si verifica un protocollo? Un modo serio è leggerlo. Non tutti lo faranno, ma basta che lo facciano alcuni, in pubblico, perché il controllo sia concreto. È questo il senso dell'open source nel P2P: non "etica da volantino", ma audit distribuito.

La fiducia nel codice, non nel brand

In un'infrastruttura decentralizzata non ha senso dire "fidati di noi". Non c'è un "noi": c'è un protocollo. E se il protocollo è opaco, nessuno può distinguere una rete davvero distribuita da un sistema che sembra distribuito ma risponde in realtà a un solo gruppo.

eMule si è presentato fin dall'inizio come software libero e open source. Il sito ufficiale di Bitcoin ripete lo stesso messaggio: il design è pubblico, il codice è open source, chiunque può partecipare. Non è una coincidenza: nei sistemi P2P che hanno retto, l'apertura del codice è un tratto ricorrente.

Open source come audit pubblico

Avere il codice non significa che tutti lo leggano, ma che qualcuno possa farlo. Significa:

  • ricercatori e sviluppatori indipendenti possono cercare bug e backdoor;
  • implementazioni alternative possono dimostrare le stesse proprietà;
  • le modifiche sospette lasciano traccia nella storia pubblica del progetto;
  • le comunità possono decidere se seguire un cambiamento o fare un fork e andare in un'altra direzione.

L'alternativa è un "fidati perché lo diciamo noi", che in un sistema distribuito non ha davvero senso: se devi fidarti comunque di qualcuno, tanto vale usarne la versione centralizzata, che è più semplice da far funzionare.

Comunità, fork, manutenzione

Un codice open source non è una statua: richiede manutenzione. Il P2P ha bisogno di persone che aggiornino i nodi, corrigano vulnerabilità, rispondano a cambi dell'infrastruttura di rete, conservino documentazione. Le comunità che reggono questa manutenzione sono una parte invisibile ma decisiva del sistema.

Il diritto di fork — la possibilità di prendere il codice e andare in una direzione diversa — è una seconda garanzia. Se chi guida il progetto sbaglia direzione, la comunità può biforcarsi. È un meccanismo di bilanciamento tipico dell'open source che nel P2P diventa ancora più importante: il "non mi piace come gestite questa rete" può diventare davvero "mi faccio la mia".

L'open source non è un dettaglio etico: nel P2P è spesso una condizione di credibilità.

Quando "decentralizzato" è solo marketing

Ci sono segnali concreti che aiutano a distinguere un progetto P2P credibile da uno che usa il vocabolario senza la sostanza:

  • c'è un repository pubblico con attività reale e storia di commit?
  • il codice ha una licenza open source riconosciuta?
  • esistono implementazioni indipendenti o client alternativi?
  • chi controlla le chiavi critiche: pochi attori o una comunità distribuita?
  • quanto sono distribuiti i nodi reali della rete, non solo i server dichiarati?

Dove la risposta è "no" a molte di queste domande, il termine "decentralizzato" rischia di essere un'etichetta. Dove la risposta è "sì", l'utente ha almeno gli strumenti per verificare cosa sta usando.

Il patto implicito del P2P

Una rete peer to peer pone un patto: ognuno contribuisce con risorse, tutti beneficiano del servizio. Questo patto regge solo finché le regole sono trasparenti. Se qualcuno può cambiarle senza che gli altri lo sappiano, il patto salta. L'open source è il linguaggio condiviso in cui queste regole sono scritte. Togli il linguaggio condiviso e ti resta un gruppo di persone che si fidano a scatola chiusa — che è esattamente il modello che il P2P voleva superare.