Chi decide un aggiornamento di protocollo in una rete pubblica

Nessun amministratore delegato firma l’aggiornamento di una rete pubblica decentralizzata. Nessun consiglio di amministrazione vota una risoluzione che tutti sono tenuti a rispettare. Eppure queste reti cambiano nel tempo, introducono nuove funzionalità, correggono difetti e talvolta modificano regole economiche fondamentali, tutto senza una singola autorità che possa imporre la propria decisione a chiunque altro.

Questo apparente paradosso si risolve osservando come funziona davvero il processo, che non è né anarchico né perfettamente democratico, ma un equilibrio fra tre gruppi di soggetti con poteri diversi e complementari: chi scrive il codice, chi lo esegue mantenendo la rete operativa, e chi usa la rete quotidianamente attribuendole valore. Nessuno dei tre gruppi, da solo, può imporre un cambiamento che gli altri due rifiutano in modo sufficientemente ampio.

Questo testo ricostruisce il processo reale che porta a un aggiornamento di protocollo, il ruolo specifico di ciascun gruppo coinvolto, e i casi documentati in cui il disaccordo fra questi gruppi ha portato la rete a dividersi in due versioni distinte e concorrenti.

I tre poteri in equilibrio

• Gli sviluppatori propongono e scrivono il codice. Non possono obbligare nessuno a eseguirlo.
• I validatori eseguono il software che scelgono. Nessuno può obbligarli ad aggiornare senza il loro consenso.
• Gli utenti attribuiscono valore alla rete che preferiscono. Un aggiornamento senza il loro sostegno resta economicamente irrilevante.
• Il disaccordo irrisolvibile produce una divisione. Quando i tre gruppi non trovano un compromesso, la rete si divide in due versioni distinte.
• La maggioranza economica, non tecnica, decide quale versione prevale. Il mercato, più del codice, stabilisce quale ramo continua a essere rilevante.

Il ruolo degli sviluppatori core

Un piccolo gruppo di sviluppatori, riconosciuto informalmente dalla comunità per la propria esperienza tecnica e per un percorso di contributi documentato nel tempo, si occupa di proporre, discutere e implementare le modifiche al codice di riferimento della rete. Questo gruppo non possiede alcuna autorità formale superiore a quella di qualunque altro partecipante: la sua influenza deriva dalla fiducia tecnica accumulata, non da un titolo istituzionale riconosciuto da un’autorità esterna.

Le proposte di modifica seguono generalmente un processo documentato pubblicamente, con discussioni aperte a cui chiunque può contribuire tecnicamente, anche se nella pratica il peso delle osservazioni varia molto secondo la reputazione tecnica di chi le formula. Una proposta ben argomentata da uno sviluppatore senza track record consolidato riceve comunque attenzione, ma affronta generalmente un livello di scrutinio più alto rispetto a una proposta simile presentata da un contributore di lunga data.

Il potere reale degli sviluppatori core si ferma però a un confine preciso: possono scrivere e pubblicare il codice, ma non possono costringere nessun operatore di rete a eseguirlo. Se una proposta viene considerata dannosa, o anche solo indesiderata, da una porzione sufficientemente ampia degli operatori di rete, quella proposta resta lettera morta indipendentemente dalla qualità tecnica con cui è stata scritta.

Il ruolo dei validatori e degli operatori di nodo

I soggetti che eseguono effettivamente il software della rete, validando le transazioni e mantenendo una copia del registro condiviso, decidono in autonomia quale versione del software eseguire. Un aggiornamento pubblicato dagli sviluppatori core diventa operativo solo quando una quota sufficiente di questi operatori sceglie volontariamente di installarlo, sostituendo la versione precedente.

Questo potere di veto distribuito è il meccanismo che impedisce a un piccolo gruppo di sviluppatori di imporre unilateralmente modifiche indesiderate: se la maggioranza degli operatori rifiuta di aggiornare, la rete continua a funzionare secondo le regole precedenti, indipendentemente da quanto gli sviluppatori originali insistano sulla bontà tecnica della proposta scartata.

Va precisato che il peso di questo gruppo varia secondo il meccanismo di consenso adottato dalla rete: in un sistema dove il potere di validazione richiede un investimento economico proporzionale, come descritto a proposito di che cosa comporta delegare a un validatore, il potere decisionale tende a concentrarsi maggiormente in chi possiede quote più rilevanti di capitale impegnato nella rete, un fattore che influenza indirettamente anche la dinamica di adozione di un aggiornamento di protocollo.

Il ruolo degli utenti e la maggioranza economica

Anche se sviluppatori e validatori raggiungono un accordo su un aggiornamento, la sua rilevanza pratica dipende in ultima istanza da chi usa la rete e le attribuisce un valore economico. Una versione della rete che gli utenti smettono di considerare rilevante, spostando attività e capitali verso una versione alternativa, perde progressivamente significato anche se tecnicamente continua a funzionare secondo le regole previste dall’aggiornamento.

Questo terzo potere, spesso meno visibile nella discussione tecnica ma decisivo nell’esito finale, si manifesta attraverso segnali di mercato: dove si concentra il valore scambiato, quale versione gli scambi e le applicazioni scelgono di supportare, quale versione gli sviluppatori di applicazioni terze continuano a integrare nei propri prodotti. Nessuno di questi segnali è formalizzato in una procedura di voto esplicita, ma insieme costituiscono quella che nella pratica viene chiamata maggioranza economica.

Quando la rete si divide davvero

Quando il disaccordo fra questi tre gruppi supera una certa soglia, senza che nessuna delle parti sia disposta a cedere, la rete può dividersi in due versioni distinte, ciascuna con le proprie regole e la propria comunità di supporto, a partire dallo stesso registro storico condiviso fino al momento della divisione. Da quel momento in poi, le due versioni evolvono in modo indipendente, spesso con nomi diversi per distinguerle chiaramente agli occhi degli utenti.

Questi episodi non sono frequenti, proprio perché comportano un costo elevato per tutte le parti coinvolte: frammentano la comunità di sviluppo, dividono la liquidità disponibile fra due reti concorrenti e costringono gli utenti a scegliere quale versione considerare quella legittima, una scelta che nella pratica alcuni utenti risolvono mantenendo posizioni su entrambe le versioni finché il mercato non chiarisce quale delle due ha mantenuto la rilevanza maggiore.

I casi più noti di questo tipo di divisione nella storia del settore sono stati determinati non da un disaccordo puramente tecnico, ma da una divergenza più profonda su questioni di principio, come la direzione strategica di lungo periodo della rete o la risposta a un incidente di sicurezza rilevante che ha richiesto una decisione con conseguenze economiche significative per una parte della comunità.

La differenza fra un aggiornamento compatibile e uno che divide la rete

Non tutti gli aggiornamenti comportano il rischio di una divisione. Un aggiornamento progettato per restare compatibile con i nodi che non lo installano subito permette una transizione graduale, in cui i nodi aggiornati e quelli non ancora aggiornati continuano a riconoscersi reciprocamente come parte della stessa rete, riducendo drasticamente il rischio di frammentazione.

Un aggiornamento che introduce regole incompatibili con la versione precedente, al contrario, richiede che una quota sufficientemente ampia della rete adotti simultaneamente la nuova versione, altrimenti i nodi non aggiornati smettono di riconoscere come validi i blocchi prodotti secondo le nuove regole, un meccanismo che, in assenza di un consenso sufficientemente ampio, produce esattamente la divisione descritta nella sezione precedente.

La tabella dei tre poteri

Nessuna riga di questa tabella descrive un potere assoluto: ognuno dei tre soggetti dipende dagli altri due per rendere effettivo un cambiamento, ed è proprio questa dipendenza reciproca a spiegare perché il processo, pur apparendo caotico dall’esterno, tende comunque a produrre un risultato stabile nella maggior parte dei casi.

Due divisioni storiche che illustrano il meccanismo

Un caso spesso citato riguarda una rete che, dopo lo sfruttamento di una debolezza in un contratto che gestiva ingenti fondi raccolti dalla comunità, si è trovata davanti a una scelta di principio: intervenire con un aggiornamento che annullasse gli effetti dello sfruttamento, oppure lasciare che il registro restasse immutato secondo il principio per cui le transazioni convalidate non si toccano mai, qualunque sia stata la causa che le ha generate. La comunità non ha raggiunto un consenso unanime su questa scelta, e il risultato è stata una divisione in due reti distinte, ciascuna fedele a un principio diverso, entrambe tuttora attive con gradi di rilevanza molto diversi fra loro.

Un secondo caso riguarda un disaccordo di natura più tecnica, sulla capacità massima di transazioni che i singoli blocchi di una rete potessero contenere. Una parte della comunità sosteneva che aumentare questa capacità fosse necessario per sostenere una crescita nell’uso quotidiano della rete, mentre un’altra parte temeva che l’aumento avrebbe concentrato eccessivamente il potere di validazione in mano a pochi operatori con risorse sufficienti a gestire blocchi più grandi. Anche in questo caso il disaccordo non si è risolto con un compromesso condiviso, e la rete si è divisa in due versioni distinte, con regole diverse sulla capacità massima consentita.

Entrambi i casi condividono un tratto comune, utile a chi vuole riconoscere in anticipo il rischio di una divisione futura: il disaccordo non riguardava un dettaglio tecnico isolato, ma un principio di fondo sul quale le diverse fazioni della comunità non erano disposte a cedere, indipendentemente dagli argomenti tecnici presentati dall’una o dall’altra parte durante la discussione pubblica.

Come seguire una proposta di aggiornamento prima che diventi operativa

1. Individuare il canale ufficiale dove la comunità di sviluppo discute pubblicamente le proposte, generalmente un repository di codice pubblico con una cronologia consultabile.
2. Verificare il livello di consenso tecnico raggiunto sulla proposta specifica, distinguendo fra una discussione ancora aperta e una proposta già accettata dalla maggioranza degli sviluppatori attivi.
3. Controllare le dichiarazioni pubbliche degli operatori di nodo principali, spesso disponibili attraverso i canali di comunicazione delle organizzazioni che gestiscono infrastrutture di validazione rilevanti.
4. Osservare il comportamento degli scambi e delle applicazioni terze, che spesso dichiarano in anticipo come intendono comportarsi in caso di una divisione della rete.

Seguire questi quattro segnali insieme offre un quadro più affidabile di quanto una proposta sia effettivamente vicina a diventare operativa, rispetto a fidarsi di un singolo annuncio isolato pubblicato da una sola delle parti coinvolte nel processo. Un segnale isolato, per quanto autorevole la fonte, racconta solo una parte della storia: è la convergenza di più segnali indipendenti a offrire un’indicazione affidabile sull’esito probabile di una proposta ancora in discussione.

Domande frequenti

Chi decide un aggiornamento di protocollo quando gli sviluppatori sono in disaccordo fra loro?

In questi casi la proposta resta bloccata finché non si raggiunge un consenso sufficiente all’interno dello stesso gruppo di sviluppo, oppure emergono proposte alternative sostenute da fazioni diverse, che a quel punto competono per il sostegno di validatori e utenti secondo lo stesso meccanismo descritto in questo testo.

Un singolo grande validatore può bloccare un aggiornamento da solo?

Dipende dalla quota di potere di validazione che controlla rispetto al totale della rete. Un singolo operatore con una quota molto ampia ha un peso proporzionalmente maggiore, ma raramente sufficiente da solo a determinare l’esito senza il concorso di altri operatori con posizioni simili e senza un minimo di sostegno anche fra gli sviluppatori e gli utenti della rete.

Gli utenti comuni hanno davvero un potere reale in questo processo?

Sì, indirettamente: le loro scelte di quale versione usare, dove concentrare le proprie attività e quali applicazioni supportare, si sommano in un segnale di mercato che sviluppatori e validatori tendono a considerare attentamente prima di insistere su una proposta priva di sostegno diffuso.

Che cosa succede ai fondi di un utente quando la rete si divide?

Nella maggior parte dei casi documentati, i fondi esistenti al momento della divisione vengono replicati su entrambe le versioni della rete, secondo la cronologia condivisa fino a quel punto. La gestione pratica di questa duplicazione dipende dagli strumenti specifici usati dall’utente per accedere ai propri fondi.

Le divisioni di rete sono sempre permanenti?

Non necessariamente in teoria, ma nella pratica quasi tutti i casi documentati hanno prodotto due versioni che hanno continuato a esistere separatamente, con un livello di rilevanza economica molto diverso fra loro nel tempo, senza una riunificazione successiva delle due catene.

Chi decide un aggiornamento di protocollo, alla fine, non è un singolo soggetto ma l’esito di un equilibrio fra tre poteri distinti che devono convergere volontariamente. È un processo più lento e meno prevedibile di una decisione aziendale tradizionale, ma è proprio questa lentezza a rendere difficile per una singola parte imporre un cambiamento che le altre due non sono disposte ad accettare. Capire questo equilibrio aiuta a leggere con più attenzione ogni annuncio di aggiornamento imminente, distinguendo una proposta con un sostegno reale da una che resterà probabilmente confinata alla sola discussione teorica.