Traduzione italiana di The Need for Formalized Governance
Traduzione italiana a cura di Lordwotton di RIOT Stake Pools. Se apprezzi queste traduzioni, per favore valuta di supportare il mio lavoro delegando i tuoi ada a RIOT 
entra nel nostro gruppo Telegram
La necessità di una governance formalizzata
Nel 2010, Satoshi Nakamoto ha salvato Bitcoin da morte certa. L’incidente del value overflow mise in luce la vulnerabilità di Bitcoin agli errori umani e ai malintenzionati, nonché la mancanza di un processo formale per affrontare tali problemi. Circa un anno dopo, è stato introdotto il processo Bitcoin Improvement Proposal (BIP) per affrontare queste sfide. Cardano ha introdotto il processo Cardano Improvement Proposal (CIP) nel 2020. Tuttavia, le CIP, così come le BIP, sono solo proposte che devono essere votate. Diamo uno sguardo al passato per vedere come si è formata la governance e che tipo di controversie può portare una votazione su una modifica del protocollo. Spiegheremo perché è necessario formalizzare la governance.
All’inizio, governava un dittatore
In questo articolo faremo seguito alla parte precedente ed esamineremo come si è sviluppata la governance della blockchain.
Si parlava di governance intorno al 2010, ma non in modo sistematico o coerente. La comunità Bitcoin era ancora piccola e composta per lo più da appassionati di tecnica che si fidavano di Satoshi Nakamoto come dittatore benevolo del progetto. Non esisteva una chiara distinzione tra governance on-chain e off-chain, né tra diversi ruoli e responsabilità all’interno della rete. La discussione era per lo più informale e ad hoc, e si svolgeva su forum online, mailing list o chat room.
L’incidente del value overflow è stato un bug che ha permesso a un hacker di creare 184 miliardi di monete BTC dal nulla sfruttando un errore di integer overflow nel codice Bitcoin. L’incidente ha messo in luce la vulnerabilità di Bitcoin agli errori umani e agli attori malintenzionati. È inoltre emerso che Bitcoin non dispone di un processo formale per affrontare tali problemi. Il processo BIP è stato introdotto un anno dopo per affrontare queste sfide e migliorare la qualità e la sicurezza dello sviluppo di Bitcoin.
Si è trattato di un’importante pietra miliare. Il processo BIP è stato uno dei primi tentativi di formalizzare e istituzionalizzare la governance nel settore della blockchain. La motivazione alla base della creazione del processo BIP è stata quella di fornire un modo chiaro e trasparente per la comunità Bitcoin di discutere e implementare nuove idee, senza fare affidamento su un’autorità o un leader centralizzato.
Amir Taaki ha creato il processo BIP nel 2011, ispirandosi al processo Python Enhancement Proposal (PEP), che è uno standard per proporre modifiche al linguaggio di programmazione Python. Taaki riteneva che il processo di sviluppo di Bitcoin avrebbe beneficiato di una maggiore strutturazione e responsabilità, oltre che di una maggiore apertura e collaborazione. Il 19 agosto 2011 ha presentato il primo BIP (BIP 0001), che descriveva il processo BIP stesso.
People were convinced that the introduction of the BIP process was an absolutely necessary step because Bitcoin is a decentralized system that requires coordination and consensus among various stakeholders, such as developers, miners, users, businesses, and governments.
Senza un meccanismo formale e trasparente per proporre, rivedere e implementare le modifiche al protocollo Bitcoin, la rete potrebbe incorrere in problemi quali bug, conflitti, fork o attacchi.
I BIP sono proposte formali che suggeriscono modifiche, aggiornamenti o miglioramenti al protocollo Bitcoin. Servono a coordinare lo sviluppo di Bitcoin in modo decentralizzato. Le BIP coprono vari argomenti, tra cui le modifiche alle regole del consenso, gli standard della comunità e i processi di sviluppo.
In particolare, i BIP presentano i seguenti vantaggi:
- Permettono a chiunque di contribuire al miglioramento di Bitcoin, indipendentemente dalle proprie competenze tecniche o dal proprio background.
- Favoriscono un ambiente collaborativo e costruttivo per l’innovazione e la risoluzione dei problemi.
- Assicurano che le modifiche siano ben documentate, testate e riviste prima di essere distribuite.
- Conservano la storia e la logica delle decisioni prese per riferimenti futuri.
- Come si vedrà in seguito, il processo BIP da solo non è sufficiente per il funzionamento della governance. Manca ancora una componente importante: la votazione. Ne parleremo più avanti.
Satoshi ha lasciato Bitcoin
Satoshi Nakamoto ha lasciato il progetto nell’aprile 2011. Ha annunciato la sua partenza in un’e-mail a un collega sviluppatore, dicendo: Sono passato ad altre cose. È in buone mani con Gavin e tutti gli altri.
La partenza è avvenuta circa un anno dopo l’incidente del value overflow e poco prima dell’introduzione del processo BIP.
Gavin Andresen, uno dei primi sviluppatori e collaboratori di Bitcoin, ha assunto la guida di Bitcoin dopo l’uscita di Satoshi. È stato nominato da Satoshi come principale manutentore del software Bitcoin Core e amministratore del sito web e del repository Bitcoin. Oltre ad altri diritti, Gavin poteva decidere quali modifiche apportare al repository con il software Bitcoin Core. Ha anche fondato la Bitcoin Foundation, un’organizzazione senza scopo di lucro che mirava a promuovere e sostenere il Bitcoin.
La Bitcoin Foundation è ancora attiva, ma non è più così influente e importante come un tempo. Nel corso degli anni l’organizzazione ha affrontato diverse sfide e controversie, come difficoltà finanziarie, questioni legali, conflitti interni e critiche pubbliche.
L’abbandono di Satoshi è stato ampiamente frainteso da alcuni come un abbandono del progetto al fine di decentralizzarlo. Il presupposto è che la blockchain possa essere decentralizzata solo se non è presente un leader. Questo assunto è sbagliato perché contraddice il modo in cui funziona lo sviluppo del software e ciò di cui ogni blockchain ha bisogno in un caso simile a quello del value overflow.
Prima di tutto, è necessario capire che Satoshi ha formalmente ceduto la sua posizione a Gavin. Gavin ha ottenuto i diritti che Satoshi aveva prima. Quindi, anche dopo la partenza di Satoshi, Bitcoin aveva ancora il suo leader. Nel 2016, a Gavin Andresen è succeduto Wladimir van der Laan, che è diventato il nuovo responsabile della manutenzione del software Bitcoin Core.
Wladimir van der Laan si è dimesso da manutentore capo del software Bitcoin Core nel febbraio 2023. Ha spiegato che si sentiva esaurito e stanco degli stessi problemi e delle stesse discussioni. Ha trasferito il suo accesso ai commit ad altri sviluppatori, che si occuperanno della manutenzione del repository Bitcoin Core.
Ogni progetto blockchain ha sempre bisogno di un leader o di un gruppo di leader. Può anche essere un’azienda o un gruppo di aziende che condividono i diritti di accesso al repository principale. La governance può essere trasparente e il pubblico sa esattamente chi ha quali diritti e responsabilità, oppure può essere avvolta nella nebbia. Ciò non toglie che il progetto blockchain abbia un suo leader.
Solana viene spesso riavviato dal team, che tende a essere al centro delle critiche. Tuttavia, la realtà è che se una qualsiasi rete blockchain esistente dovesse incorrere in problemi simili, gli utenti si aspetterebbero che un team la riavvii. Questo è l’unico modo in cui gli utenti possono accedere ai loro beni. Dal mio punto di vista, la blockchain può godere di maggiore fiducia se gli utenti sono convinti che un team di esperti sia pronto a risolvere problemi imprevisti. La trasparenza aumenta la fiducia.
Il team IOG è responsabile della ricerca e dello sviluppo di Cardano. Charles Hoskinson è il CEO di IOG. È responsabilità dello IOG creare canali e processi di comunicazione che consentano alle persone di ottenere gradualmente il controllo di Cardano dal punto di vista della gestione del team. Il processo CIP è solo uno dei primi passi. Verranno compiuti ulteriori passi.
È importante notare che se Charles Hoskinson dovesse mai lasciare lo IOG, sarà sostituito da qualcun altro. È del tutto normale e naturale. Questo non renderebbe Cardano più o meno decentralizzato. Ciò che decentralizza la blockchain a livello di gestione del progetto è una governance ben strutturata e formalizzata.
Il processo BIP e le votazioni
Il processo BIP è un meccanismo formale e trasparente per proporre, rivedere e implementare modifiche al protocollo Bitcoin. Comporta la creazione di un documento che descrive le motivazioni, le specifiche e l’implementazione della modifica proposta e lo sottopone alla comunità Bitcoin per la discussione e il feedback. Facilita la discussione e la valutazione delle modifiche proposte, ma non garantisce o impone l’attivazione o l’implementazione delle modifiche.
Pertanto, il processo BIP non ha lo scopo di votare se la modifica sarà effettivamente parte del protocollo. Per modificare il protocollo è necessaria una forma di votazione. Nelle reti decentralizzate, questo avviene attraverso una risorsa costosa, cioè in modo simile alla produzione di blocchi. I proprietari delle risorse sono coinvolti nel gioco e quindi ci si può aspettare che votino nell’interesse della comunità e della rete. Tuttavia, questa è solo un’aspettativa, non una garanzia.
In Bitcoin, il tasso di hash viene utilizzato per il voto. Quindi votano i minatori, non gli utenti. Il voto consiste nel segnalare il sostegno o il rifiuto della proposta includendo un codice speciale nei blocchi o seguendo determinate regole che determinano la validità dei blocchi.
Il processo BIP e il voto tramite hash rate fanno entrambi parte della governance e del processo decisionale di Bitcoin. Entrambi mirano a coordinare lo sviluppo di Bitcoin in modo decentralizzato.
L’idea di votare sui BIP è emersa dagli sforzi collettivi e dalle discussioni della comunità Bitcoin. I principali sostenitori dell’introduzione del voto sono stati Amir Taaki, Luke Dashjr e Gavin Andresen.
Essi avevano opinioni e preferenze diverse sulle modalità di votazione.
Amir preferiva un approccio al voto più radicale e guidato dagli utenti, che potevano forzare l’attivazione di una proposta rifiutando i blocchi che non la rispettavano. Luke preferiva un approccio al voto più tecnico e guidato dai minatori, che potevano segnalare il loro sostegno o rifiuto di una proposta includendo un codice speciale nei loro blocchi. Gavin preferiva un approccio al voto più pragmatico e orientato al compromesso, in cui sia i minatori che gli utenti potevano concordare una soglia più bassa e un periodo più breve per l’attivazione di una proposta.
Il processo CIP
Il processo CIP ha uno scopo simile a quello del processo BIP. La prima proposta di miglioramento di Cardano è stata creata da Sebastien Guillemot e Kevin Hammond l’8 maggio 2020.
Le CIP devono essere utilizzate per descrivere il problema in dettaglio e proporre una soluzione tecnica. La modifica proposta può essere discussa e le decisioni di progettazione possono essere documentate. Non è compito del processo CIP decidere se implementare le modifiche. Un documento CIP esistente (proposta) non è una garanzia che una modifica sarà implementata in un protocollo o comunque impiegata.
Le CIP hanno due compiti essenziali. Standardizzare la forma di comunicazione tra i partecipanti e consentire la proposta di modifiche in modo uniforme e formalizzato. Ogni documento CIP ha un autore e l’autore deve seguire la struttura del documento richiesta.
I redattori CIP salvaguardano il processo CIP. Tuttavia, il loro ruolo non è quello di approvare o rifiutare le proposte degli autori. Possono anche non essere d’accordo con la proposta, ma se è tecnologicamente valida e completa e se l’autore segue la struttura documentale richiesta, la proposta verrà prodotta.
Gli attuali redattori dei CIP sono Sebastien Guillemot, Matthias Benkort, KtorZ, Robert Phair, Ryan Williams e Adam Dean.
Attualmente, il processo CIP non ha nulla a che fare con la governance a catena. Si tratta di una componente guidata dalla comunità che può servire come input per la governance della catena. In teoria è possibile votare sui singoli documenti CIP. Per quanto ne so, non c’è un legame diretto tra il processo CIP e la governance on-chain proposta nel documento CIP-1694.
Dal mio punto di vista, la votazione sui CIP è assolutamente necessaria, poiché le modifiche al protocollo devono essere approvate dalla maggioranza delle parti interessate. Ci possono essere proposte che saranno controverse e che potrebbero dividere la comunità. Nessuna autorità centrale può avere l’ultima parola sul progetto approvato e sulla sua implementazione nel protocollo Cardano. Questa dovrebbe sempre essere una decisione collettiva.
Quanto può essere complicato modificare il protocollo?
Nel 2017, la prima grande controversia si è verificata durante la votazione per la modifica del protocollo. Non è stata esattamente la prima votazione nella storia della blockchain, ma può essere considerata la più complessa finora. Vediamo cosa è successo.
Nel 2017 è sorta un’importante disputa su come aumentare la scalabilità di Bitcoin, che ha portato alla creazione di due BIP in competizione tra loro: BIP-141 (Segregated Witness) e BIP-148 (User Activated Soft Fork). Il primo è stato sostenuto dalla maggior parte degli sviluppatori e dei minatori, mentre il secondo è stato favorito da alcuni utenti e aziende.
Si noti che non c’è stato consenso tra le parti interessate. La maggior parte dei minatori e degli sviluppatori aveva interessi diversi da quelli di alcuni utenti e aziende.
BIP-141 era l’implementazione originale di SegWit, proposta dagli sviluppatori di Bitcoin Core. Richiedeva il 95% della potenza di hash per segnalare il supporto a SegWit entro un periodo di due settimane, prima di novembre 2017. Tuttavia, questo metodo di attivazione ha incontrato la resistenza di alcuni minatori che si sono opposti a SegWit per vari motivi (alcuni preferivano aumentare il limite di dimensione dei blocchi invece di SegWit). Di conseguenza, l’attivazione di SegWit si è bloccata a circa il 30% della potenza di hash per mesi.
BIP-148 era un’implementazione alternativa di SegWit, proposta nel marzo 2017. Essa richiedeva agli utenti (i loro nodi) di rifiutare qualsiasi blocco che non segnalasse il supporto per SegWit dopo il 1° agosto 2017. Questo avrebbe creato una pressione sui minatori affinché seguissero la maggioranza degli utenti e adottassero SegWit, o avrebbero rischiato di perdere le loro ricompense e commissioni.
Questo metodo di attivazione ha dovuto affrontare anche le critiche di alcuni sviluppatori e utenti che lo consideravano rischioso e sconsiderato, in quanto avrebbe potuto causare una spaccatura della catena e un hard fork se alcuni minatori non si fossero adeguati.
L’esito della controversia è stato l’attivazione di SegWit tramite una soluzione di compromesso raggiunta nel luglio 2017. Questa soluzione è stata chiamata BIP-91. Ha abbassato la soglia di potenza hash per l’attivazione di SegWit dal 95% all’80% e ha anche applicato le regole BIP-148 ai minatori non conformi. In questo modo, ha soddisfatto sia i sostenitori di BIP-141 che di BIP-148, evitando una potenziale divisione della catena e un hard fork.
Tuttavia, alcuni minatori e utenti che volevano un limite di dimensione dei blocchi più ampio invece di SegWit hanno deciso di creare una nuova versione di Bitcoin chiamata Bitcoin Cash (BCH), che ha subito un hard fork da Bitcoin il 1° agosto 2017.
Come si può notare, gli interessi politici possono influenzare i PIF quando diversi gruppi o fazioni all’interno della comunità hanno opinioni o agende divergenti su come migliorare il protocollo. L’aggiornamento SegWit è stato infine attivato, ma in un PIF diverso da quello originale. Inoltre, si è verificato un hard fork, ovvero una divisione della comunità, del tasso di hash e degli sviluppatori. Come si può vedere, il processo decisionale in un mondo decentralizzato può essere controverso e difficile. La governance non è una cosa semplice.
I PIF sono proposti da singoli individui o da piccoli team. Devono avere dalla loro parte minatori, sviluppatori e la comunità. Per quanto riguarda la decentralizzazione, dobbiamo esaminare quanto sia difficile ottenere il sostegno e quante persone devono essere convinte del cambiamento.
Forse, se Satoshi non avesse lasciato Bitcoin, avrebbe potuto decidere in modo autorevole il destino di SegWit. Tuttavia, questa non poteva certo essere considerata una forma di governance decentralizzata. Il caos e la controversia che ne sono derivati sono stati probabilmente causati da una governance disfunzionale e dalla scarsa esperienza degli attori.
Si è verificata la prima grande lotta di potere nel settore della blockchain. Era chiaro a tutti che la governance non funzionava bene. Le controversie non devono finire in un hard fork.
Le critiche al processo BIP
Cardano, ma anche molti altri progetti blockchain, hanno adottato il processo BIP da Bitcoin. Nel corso del tempo, si è scoperto che questo processo potrebbe non essere perfetto. È importante pensare a un suo miglioramento. Il processo BIP ha iniziato a essere criticato dal suo autore.
Nel 2015, Amir Taaki ha iniziato a criticare il processo BIP. Sosteneva che fosse troppo lento, burocratico e conservatore. Sosteneva che il processo BIP favorisse lo status quo rispetto al progresso tecnologico e all’innovazione. Inoltre, scoraggiava le proposte radicali che potevano mettere in discussione le strutture di potere e i presupposti esistenti in Bitcoin. Ha anche suggerito che il processo BIP è stato influenzato da interessi politici ed economici, piuttosto che dal merito tecnico e dalla domanda degli utenti.
Altri critici del processo BIP sottolineano la lentezza e la complessità del tentativo di raggiungere un consenso, soprattutto nel caso di modifiche controverse. La controversia sull’aggiornamento di SegWit nel 2017 ha dimostrato che le preoccupazioni erano rilevanti. Inoltre, alcuni hanno percepito forti influenze politiche ed economiche che potrebbero non essere in linea con i migliori interessi della comunità e della rete.
Si sentono anche lamentele sulla censura e sulla manipolazione da parte di attori potenti. Ad esempio, i minatori possono censurare o manipolare i PIF scegliendo di segnalare o meno il loro sostegno a determinate proposte, oppure rifiutando o accettando blocchi che seguono determinate regole. Gli sviluppatori possono censurare o manipolare i PIF controllando la base di codice del software Bitcoin o influenzando il processo di revisione e test delle proposte.
Nel 2018, Taaki ha nuovamente criticato lo stato attuale dello sviluppo di Bitcoin in quanto troppo centralizzato e conformista. Ha affermato che il processo BIP ha creato una cultura della paura e del conformismo tra gli sviluppatori, che temono di proporre cambiamenti radicali o di sfidare le narrazioni dominanti in Bitcoin. Ha inoltre accusato alcuni sviluppatori di essere corrotti da interessi aziendali o da programmi ideologici e di imporre le loro opinioni al resto della comunità.
È importante rendersi conto che gli interessi di alcune parti interessate potrebbero non essere in linea con i migliori interessi della comunità e della rete. È logico, perché ognuno di noi vuole egoisticamente ottenere il massimo profitto possibile, e le strade che portano a questo risultato sono diverse per i singoli gruppi.
Ad esempio, potrebbe essere vantaggioso per i minatori introdurre la tail inflation del BTC, in quanto garantirebbe le loro ricompense, ma gli utenti non sarebbero d’accordo con questa proposta. Agli sviluppatori conviene mantenere bassa la scalabilità di Bitcoin, perché possono lavorare sui secondi livelli e trarre profitto dalla gestione dei nodi LN. Le diverse parti interessate perseguiranno obiettivi diversi e adatteranno di conseguenza le loro opinioni sui PIF.
La governance deve essere formalizzata
Attualmente, ritengo che la scarsa trasparenza sia la principale debolezza della governance in quasi tutti i progetti blockchain. La formalizzazione della governance può risolvere questo problema.
È necessario definire e documentare le regole, i ruoli e le responsabilità dei partecipanti a un sistema, nonché i meccanismi e le procedure per il processo decisionale e la risoluzione dei conflitti. La risoluzione dei conflitti può essere molto complessa, come dimostra non solo la storia ma anche il presente.
Con una struttura di governance formale e trasparente, può essere chiaro e coerente come vengono prese le decisioni, chi ha l’autorità e la responsabilità di prenderle e come vengono comunicate e fatte rispettare. Ciò può contribuire a evitare confusione, incomprensioni e conflitti tra i partecipanti al sistema blockchain.
È necessario introdurre una forma di monitoraggio e valutazione delle prestazioni e del comportamento dei partecipanti al sistema blockchain. Il sistema deve ritenere i partecipanti chiave (soprattutto il team) responsabili delle loro azioni e dei loro risultati. Questo può preservare la fiducia nel sistema e nei suoi partecipanti.
Senza una struttura di governance formale e trasparente, i sistemi blockchain potrebbero incontrare seri problemi. Per gli attori malintenzionati può essere più facile sfruttare le debolezze o le lacune del sistema blockchain, oppure manipolare o influenzare il processo decisionale. Ciò può compromettere la sicurezza e la stabilità del sistema e dei suoi partecipanti.
Le lotte di potere possono essere condotte in background e il pubblico potrebbe non venirne mai a conoscenza. L’unico modo per evitarlo è definire chiaramente ruoli e responsabilità.
Alcuni pensano che una rete decentralizzata, e quindi il codice, sia sufficiente a proteggere i loro beni. Vogliono fidarsi solo ed esclusivamente del codice. Devono rendersi conto che qualcuno deve mantenere il codice, qualcuno deve monitorare la rete e valutarne le prestazioni. La fiducia in una rete decentralizzata richiede anche fiducia nelle persone, cioè nella governance. Se ci si fida della blockchain, ci si fida anche del team, che lo si capisca o meno.
Formalization of governance can also help to align the interests and incentives of the participants, ensure the security and stability of the network, and foster innovation and development. This is especially important for Cardano, which must not lose its ability to evolve.
It must be easy and straightforward to propose, review, and implement changes or improvements to the blockchain system, especially when they involve controversial or radical aspects. Adapting to new conditions and innovating software is an integral part of every project, and blockchain protocols are no exception.
An integral part of governance is some form of voting, which in the case of Cardano will be largely (not necessarily exclusively) based on ADA coins. In a decentralized system, 1 person = 1 vote cannot apply, but rather 1 ADA = 1 vote. Voting in the Catalyst Fund10 showed us the weaknesses of this system, which need to be analyzed in order to improve it.
Conclusione
La governance è l’evoluzione della decentralizzazione. Non basta che la produzione di blocchi sia decentralizzata, perché questo processo dipende dall’esistenza del software. Ogni software deve essere mantenuto da qualcuno. La responsabilità collettiva non funzionerebbe. Ci deve sempre essere qualcuno che risponde e di cui la comunità si fida. Devono esserci regole e processi chiaramente definiti nel rapporto tra il team e le altre parti interessate. Non è mai garantito che l’interesse del team sia in linea con quello degli altri stakeholder. Pertanto, gli stakeholder devono avere il controllo sul team e sul codice sorgente.