Articolo tradotto da Notes on Blockchain Governance di Vitalik Buterin, scritto il 17/12/2017.
Fonte originale: http://vitalik.ca/general/2017/12/17/voting.html

In cui sostengo che il voto “strettamente decisivo” on-chain è sopravvalutato, lo status quo di una “governance informale” come praticato da Bitcoin, Bitcoin Cash, Ethereum, Zcash e sistemi simili è molto meno cattivo di quanto si pensi comunemente, che le persone che pensano che lo scopo delle blockchain sia quello di eliminare completamente le poco precise intuizioni e sensazioni umane a favore di una governance completamente algoritmica (enfasi su “completamente”) sono assolutamente folli, e il voto debolmente vincolante come fatto da Carbonvotes e sistemi simili è sottovalutato, così come è folle descrivere in primo luogo quale framework dovrebbe essere utilizzato quando si pensa alla governance di blockchain.

Vedi anche: https://medium.com/@Vlad_Zamfir/against-on-chain-governance-a4ceacd040ca

Una delle tendenze recenti più interessanti nella governance della blockchain è il riemergere del voto on-chain da parte dei possessori di moneta come meccanismo decisionale polivalente. A volte i voti dai “coin holders” vengono utilizzati per decidere chi deve mantenere i super-nodi che gestiscono una rete (es. DPOS in EOS, NEO, Lisk e altri sistemi), a volte per votare i parametri del protocollo (ad esempio il limite del gas di Ethereum) e a volte per votare se implementare direttamente ed universalmente gli aggiornamenti del protocollo (ad esempio Tezos). In tutti questi casi, i voti sono automatici – il protocollo stesso contiene tutta la logica necessaria per modificare il set di validatori o per aggiornare le proprie stesse regole, e lo fa automaticamente in risposta al risultato dei voti.

La governance esplicita on-chain viene tipicamente reclamizzata come avente molti importanti vantaggi. In primo luogo, a differenza della filosofia altamente conservativa adottata da Bitcoin, può evolvere rapidamente e accettare i necessari miglioramenti tecnici. In secondo luogo, creando un sistema decentralizzato esplicito, evita le insidie percepite da una governance informale, che è considerata troppo instabile e incline a spaccature, o incline a diventare di fatto troppo centralizzata – quest’ultimo è lo stesso argomento trattato nel famoso saggio del 1972 “Tyranny of Structurelessness“.

Citando la Documentazione di Tezos:

Mentre tutte le blockchain offrono incentivi finanziari per mantenere il consenso sui loro registri, nessuna blockchain ha un solido meccanismo on-chain che modifica in modo trasparente le regole che governano il suo protocollo e premia lo sviluppo dello stesso. Di conseguenza, le blockchain di prima generazione offrono potere di fatto ai team di sviluppo core centralizzati o ai minatori per determinare le scelte di progetto.

E:

Sì, ma perché vorresti rendere [una divisione di una chain minoritaria] più semplice? Dividere distrugge gli effetti di rete.

La governance on-chain utilizzata per selezionare i validatori ha anche il vantaggio di consentire, per le reti che impongono requisiti di calcolo elevati agli stessi, di non introdurre rischi di centralizzazione economica e altre trappole di questo tipo che appaiono in blockchain pubbliche (es. il dilemma del validatore).

Sin qui, tutto sommato, la governance on-chain sembra un’ottima cosa… quindi cosa c’è di sbagliato in essa?

Cos’è la Blockchain Governance?

Per iniziare, dobbiamo descrivere più chiaramente cosa sia il processo di “blockchain governance”. In generale, ci sono due modelli informali di governance, che chiamerò la visione della “funzione decisionale” della governance e la visione di “coordinamento” della governance. Il punto di vista della funzione decisionale considera la governance come una funzione f(x1, x2 ... xn) -> y, dove gli input sono i desideri dei vari legittimi stakeholder (senatori, presidente, proprietari, azionisti, elettori, ecc.) e l’output è la decisione.

La considerazione della funzione decisionale è spesso utile come approssimazione, ma chiaramente diventa poco consistente molto facilmente nei casi estremi: le persone spesso possono infrangere le regole e farla franca, a volte le regole sono ambigue e talvolta avvengono delle rivoluzioni – e tutte e tre queste possibilità sono, almeno alle volte, una buona cosa. E spesso anche il comportamento all’interno del sistema è modellato da incentivi creati dalla possibilità di agire al di fuori del sistema, e questo ancora una volta è, almeno alle volte, una buona cosa.

Il modello di coordinamento della governance, al contrario, vede la governance come qualcosa che esiste a strati. Lo strato inferiore è rappresentato, nel mondo reale, dalle stesse leggi della fisica (come direbbe un realista geopolitico, pistole e bombe), e nell’ambito blockchain possiamo astrarre un po’ di più e dire che è rappresentato dalla capacità di ognuno di eseguire qualsiasi software voglia, nelle vesti di utente, minatore, stakeholder, validatore o qualunque altro tipo di agente che un protocollo blockchain consenta loro di essere. Lo strato inferiore è sempre lo strato decisivo definitivo; se, ad esempio, tutti gli utenti Bitcoin si svegliano un giorno e decidono di modificare il codice sorgente dei loro clienti e sostituire l’intero codice con un client Ethereum che ascolta i saldi di un particolare contratto token ERC20, significa che quel token ERC20 è bitcoin. Il potere di governo finale del livello inferiore non può essere fermato, ma le azioni che le persone intraprendono su questo livello possono essere influenzate dagli strati sopra di esso.

Il secondo livello (e di importanza cruciale) sono le istituzioni di coordinamento. Lo scopo di un istituto di coordinamento è di creare punti focali su come e quando le persone dovrebbero agire per coordinare meglio il comportamento. Ci sono molte situazioni, sia nella governance blockchain che nella vita reale, dove se agisci in un certo modo da solo, è probabile che non arrivi da nessuna parte (o peggio), ma se tutti agiscono insieme si può raggiungere il risultato desiderato.

In questi casi, è nel tuo interesse andare se tutti gli altri stanno andando e fermarti se tutti gli altri si fermano. Puoi pensare alle istituzioni di coordinamento come a mettere in aria bandiere verdi o rosse dicendo “vai” o “fermati”, con un accordo stabilito dove tutti guarderanno queste bandiere ed (in genere) faranno quello che indicano. Perché le persone hanno l’incentivo a seguire queste bandiere? Perché tutti gli altri stanno già seguendo queste bandiere, e tu hai l’incentivo a fare la stessa cosa di quello che fanno tutti gli altri.

Affermazione forte: questo concetto di flag di coordinamento comprende tutto ciò che intendiamo per “governance”; in scenari in cui non esistono giochi di coordinamento (o più in generale, giochi multi-equilibrio), il concetto di governance non ha senso.

Nel mondo reale, gli ordini militari gestiti fisicamente come una bandiera, e nel mondo blockchain, l’esempio più semplice di una tale bandiera è il meccanismo che comunica alla gente se un fork “sta accadendo” oppure no. Le istituzioni di coordinamento possono essere molto formali o possono essere informali e spesso forniscono suggerimenti ambigui. Le bandiere dovrebbero essere idealmente sempre rosse o verdi, ma a volte una bandiera potrebbe essere gialla, o addirittura olografica, apparendo verde per alcuni partecipanti e gialla o rossa per gli altri. Alle volte ci possono essere anche più flag che sono in conflitto tra loro.

Le domande chiave sulla governance diventano quindi:

• Cosa dovrebbe essere lo strato 1? Cioè, quali caratteristiche dovrebbero essere impostate nel protocollo iniziale stesso, e in che modo questo influenza la capacità di apportare modifiche alle formule del protocollo (ovvero con decisioni calcolate come funzioni), e modifiche al livello di potere da assegnare ai diversi tipi di agenti che agiscono in modi diversi?
• Cosa dovrebbe essere lo strato 2? Cioè, quali istituzioni di coordinamento dovrebbero le persone essere incoraggiate a seguire?

Il ruolo del Coin Voting

Ethereum ha una storia anche di voto con le monete, tra cui:

• Voti delle proposte DAO: https://daostats.github.io/proposals.html
• DAO Carbonvote: http://v1.carbonvote.com/
• EIP 186/649/669 Carbonvote: http://carbonvote.com/

Questi tre sono tutti esempi di coin voting (voto con monete) debolmente vincolanti, o voto con moneta con istituzione di coordinamento di livello 2. Ethereum non ha alcun esempio di voto con monete strettamente vincolante (o voto con monete come funzionalità di livello 1 in-protocollo), sebbene abbia un esempio di votazione con il minatore strettamente vincolante: il diritto dei miner di votare sul limite del gas. Chiaramente, il voto strettamente vincolante e il voto debolmente vincolante sono concorrenti nello spazio del meccanismo di governance, quindi vale la pena di analizzare: quali sono i vantaggi e gli svantaggi di ciascuno?

Supponendo costi di transazione pari a zero, e supponendo siano usati come unico meccanismo di governance, i due sono chiaramente equivalenti. Se un voto debolmente vincolante dice che il cambiamento X dovrebbe essere implementato, allora questo servirà da “bandiera verde” incoraggiando tutti a scaricare l’aggiornamento; se una minoranza vuole ribellarsi, semplicemente non scaricherà l’aggiornamento. Se un voto strettamente vincolante implementa il cambiamento di X, allora il cambiamento avviene automaticamente, e se una minoranza vuole ribellarsi, può installare un aggiornamento con un hard-fork che annulli la modifica. Tuttavia, vi sono chiaramente dei costi di transazione diversi da zero associati alla creazione di un hard-fork, e questo porta a differenze molto importanti.

Una differenza molto semplice, ed importante, è che il voto strettamente vincolante crea un default a favore della blockchain che adotta ciò che la maggioranza vuole, richiedendo alle minoranze di esercitare grandi sforzi per coordinare un hard fork per preservare le proprietà esistenti di blockchain, mentre il voto debolmente vincolante è solo uno strumento di coordinamento, e richiede ancora agli utenti di scaricare ed eseguire effettivamente il software che implementa un determinato fork. Ma ci sono anche molte altre differenze. Ora esaminiamo alcuni argomenti contro le votazioni e analizziamo come ogni argomento si applica sia al voto come livello 1, che al voto come livello 2.

Bassa partecipazione al voto

Una delle principali critiche ai meccanismi di votazione con moneta è che, non importa dove essi vengano valutati, tendono ad avere comunque una partecipazione degli elettori molto bassa. Il DAO Carbonvote aveva un tasso di partecipazione degli elettori di solo il 4,5%:

Inoltre, la distribuzione della ricchezza è molto diseguale, e i risultati di questi due fattori insieme sono meglio descritti da questa immagine creata da un critico del DAO fork:

L’EIP 186 Carbonvote ha avuto ~ 2,7 milioni di ETH votanti. I voti delle proposte DAO non sono andati meglio, con una partecipazione che non ha mai raggiunto il 10%. E al di fuori di Ethereum le cose non sono comunque splendenti; anche su Bitshares, un sistema in cui il social contract di base è progettato attorno al voto, il massimo risultato in un voto di approvazione ha ottenuto solo il 17% dei voti, e in Lisk è arrivato sino al 30%, anche se come vedremo più avanti questi sistemi hanno altri problemi per conto loro.

La bassa partecipazione al voto significa due cose. In primo luogo, il voto ha più difficoltà a raggiungere una percezione di legittimità, perché riflette solo le opinioni di una piccola percentuale di persone. Secondo, un attaccante con solo una piccola percentuale di tutte le monete può influenzare il voto. Questi problemi esistono indipendentemente dal fatto che il voto sia strettamente o debolmente vincolante.

Attacchi sulla Teoria dei Giochi

A prescindere da “il grande attacco” che ha attirato la gran parte dell’attenzione dei media, the DAO ha avuto anche una serie di vulnerabilità di teoria dei giochi molto più ridotte; questo articolo di HackingDistributed fa un buon lavoro nel riassumerle. Ma questa è solo la punta dell’iceberg. Anche se i più piccoli dettagli di un meccanismo di voto sono implementati correttamente, i meccanismi di voto in generale hanno un grosso difetto: in ogni votazione, la probabilità che ogni elettore abbia un impatto sul risultato è minima, e quindi l’incentivo personale che ogni votante debba votare correttamente è quasi insignificante. E se la dimensione del peso di ciascuna persona è piccola, il loro incentivo a votare correttamente è insignificante al quadrato. Quindi, una bustarella relativamente piccola distribuita tra i partecipanti può essere sufficiente per influenzare la loro decisione, probabilmente in un modo che essi collettivamente potrebbero disapprovare.

Ora si potrebbe dire che le persone non sono dei malvagi massimizzatori egoistici che accetteranno una tangente da $0,50 per votare di dare venti milioni di dollari a Josh solo perché il calcolo di cui sopra dice che la loro possibilità individuale di influenzare qualsiasi cosa è minima; piuttosto, si rifiuterebbero altruisticamente di fare qualcosa di così sbagliato. Ci sono due risposte a questa critica.

Primo, ci sono modi per realizzare una “bustarella” che sia piuttosto plausibile; ad esempio, un exchange può offrire dei tassi di interesse per i depositi (o, ancor più ambiguamente, utilizzare i soldi stessi dell’exchange per realizzare delle belle interfacce e funzionalità), con l’operatore dell’exchange che utilizza la grande quantità di depositi per votare come desidera. Gli exchange traggono profitto dal caos, quindi i loro incentivi sono chiaramente piuttosto disallineati da quelli degli utenti e dei possessori di monete.

In secondo luogo, e più incredibilmente, in pratica sembra che le persone, almeno nella loro qualità di possessori di crypto token, siano massimizzatori del profitto e sembrano non vedere nulla di male o egoista nel prendere una bustarella o due. Come “Esposto A”, possiamo guardare la situazione con Lisk, dove la pool delegata sembra essere stata catturata con successo da due importanti “partiti politici” che corrompono esplicitamente i possessori di monete per votare per loro, e richiedono anche che ogni membro della pool voti per tutti gli altri.

Ecco LiskElite, con 55 membri (su un totale di 101):

Ecco LiskGDT, con 33 membri:

E come “Esposto B” alcune tangenti dove gli elettori vengono pagati in Ark:

Qui, si noti che c’è una differenza fondamentale tra voti strettamente vincolanti e debolmente vincolanti. In un debolmente vincolante, è anche possibile la corruzione del voto diretto o indiretto, ma se la comunità è d’accordo sul fatto che alcune proposte o serie di voti costituiscono un attacco sulla teoria dei giochi, possono semplicemente accettare socialmente di ignorarlo. E infatti questo è già successo: il Carbonvote contiene una lista nera di indirizzi corrispondenti a noti indirizzi di exchange, e i voti di questi indirizzi non vengono contati. In un voto strettamente vincolante, non c’è modo di creare una tale lista nera a livello di protocollo, perché concordare chi fa parte della lista nera è essa stessa una decisione di governance blockchain. Ma dal momento che la lista nera fa parte di uno strumento di voto creato dalla comunità che influenza solo indirettamente le modifiche del protocollo, gli strumenti di voto che contengono cattive liste nere possono semplicemente essere respinti dalla comunità.

Vale la pena notare che questa sezione non è una previsione secondo cui tutti i sistemi di voto strettamente vincolanti soccomberanno rapidamente agli attacchi di corruzione. È del tutto possibile che molti sopravvivranno per una semplice ragione: tutti questi progetti hanno fondatori o fondazioni con grandi quantitativi pre-minati, e questi agiscono come grandi attori centralizzati interessati al successo delle loro piattaforme che non sono vulnerabili alle tangenti e tengono abbastanza monete per superare la maggior parte degli attacchi di corruzione. Tuttavia, questo tipo di modello di fiducia centralizzato, sebbene sia probabilmente utile in alcuni contesti nelle prime fasi di un progetto, è chiaramente non sostenibile a lungo termine.

Non-Rappresentatività

Un’altra importante obiezione al voto è che i possessori di monete sono solo una classe di utenti e possono avere interessi che si scontrano con quelli degli altri utenti. Nel caso di criptovalute pure come Bitcoin, l’uso come store-of-value (“hodling“) e l’uso come mezzo di scambio (“acquistare caffè”) sono naturalmente in conflitto, poiché il valore dello store-of-value ha molta più sicurezza del caso d’uso come mezzo di scambio, che valuta maggiormente l’usabilità. Con Ethereum, il conflitto è peggiore, poiché ci sono molte persone che usano Ethereum per ragioni che non hanno nulla a che fare con gli ether (si veda: criptokitties), o anche con risorse digitali portatrici di valore in generale (si veda: ENS).

Inoltre, anche nel caso in cui i possessori di monete siano l’unica classe di utenti rilevante (si potrebbe immaginare possa essere il caso in una criptovaluta in cui esiste un contratto sociale stabilito per cui l’unico scopo è quello di essere il prossimo oro digitale, e nient’altro), c’è ancora la sfida per cui il voto per detenzione di monete dia una voce molto più grande ai ricchi possessori piuttosto che a tutti gli altri, aprendo la porta alla centralizzazione dei grossi holder, per portare poi a una centralizzazione senza ostacoli del processo decisionale. O, in altre parole…

E se vuoi vedere una recensione di un progetto che sembra unire tutti questi svantaggi allo stesso tempo, vedi questo: https://btcgeek.com/bitshares-trying-memorycoin-year-ago-disastrous-ends/.

Questa critica si applica allo stesso modo sia per quanto riguarda il voto strettamente vincolante che quello meno vincolante; tuttavia, il voto debolmente vincolante è più suscettibile ai compromessi che mitigano la sua non rappresentatività, e ne discuteremo più avanti.

Centralizzazione

Diamo un’occhiata all’esperimento attualmente live esistente che abbiamo di votazione strettamente vincolante su Ethereum, il limite del gas. Ecco l’evoluzione del limite di gas negli ultimi due anni:

Potresti notare che la forma generale della curva è un po’ come quella  di un altro grafico che ti potrebbe essere abbastanza familiare:

Fondamentalmente, entrambi sembrano numeri magici che vengono creati e ripetutamente rinegoziati da un gruppo abbastanza centralizzato di ragazzi seduti insieme in una stanza. Cosa sta succedendo nel primo caso? I minatori seguono generalmente la direzione preferita dalla comunità, che è a sua volta valutata tramite richieste di consenso sociale simili a quelli che guidano gli hard-fork (supporto dagli sviluppatori core, voti su Reddit, ecc.; in Ethereum, il limite del gas non è mai diventato abbastanza controverso da richiedere nulla di serio come un voto con le monete).

Quindi, non è affatto scontato che il voto sarà in grado di fornire risultati che siano effettivamente decentrati, specie se gli elettori non sono tecnologicamente competenti e si limitano a rimandare ad un singolo gruppo dominante di esperti. Questa critica si applica ancora una volta sia al voto strettamente vincolante che al debolmente vincolante allo stesso modo.

Aggiornamento: da quando ho scritto questo, sembra che i minatori di Ethereum siano riusciti a superare il limite del gas da 6,7 a 8 milioni senza nemmeno discuterne con gli sviluppatori core o con la Fondazione Ethereum. Quindi c’è speranza; ma ci vuole un sacco di duro lavoro di community building e altri estenuanti lavori non tecnici per arrivare a quel punto.

Costituzioni digitali

Un approccio che è stato suggerito per mitigare il rischio di sfuggenti cattivi algoritmi di governance è istituire delle “costituzioni digitali” che specifichino matematicamente le proprietà desiderate che il protocollo dovrebbe avere, e richiedano che ogni nuovo codice venga fornito con una prova verificabile dal computer che l’algoritmo soddisfi queste proprietà. All’inizio sembra una buona idea, ma a mio avviso dovrebbe essere considerata scetticamente.

In generale, l’idea di avere delle norme sulle proprietà del protocollo, e il fatto che queste norme abbiano la funzione di uno dei flag di coordinamento, è molto buona. Questo ci consente di incorporare le proprietà fondamentali di un protocollo che consideriamo molto importanti e preziose, e renderle più difficili da modificare. Tuttavia, questo è esattamente il tipo di cosa che dovrebbe essere applicata in modo non strettamente vincolante (cioè strato due), piuttosto che in forma strettamente vincolante (strato uno).

Fondamentalmente, qualsiasi norma significativa è in realtà abbastanza difficile da esprimere nella sua interezza; questo fa parte del problema della complessità del valore. Questo è vero anche per qualcosa apparentemente non ambiguo come il limite di 21 milioni di monete. Certo, si può aggiungere una riga di codice dicendo assert total_supply <= 21000000, e fare un commento intorno ad esso dicendo “non rimuovere a tutti i costi”, ma ci sono molti modi per fare la stessa cosa. Ad esempio, si potrebbe immaginare un soft-fork che aggiunge una commissione di transazione obbligatoria che è proporzionale al valore della moneta * il tempo trascorso da quando le monete sono state inviate l’ultima volta, e questo è equivalente ad una tassa di controstallia, che equivale alla deflazione. Si potrebbe anche implementare un’altra valuta, chiamata Bjtcoin, con 21 milioni di nuove unità, e aggiungere una funzione in cui, se viene inviata una transazione bitcoin, il minatore può intercettarla e rivendicare il bitcoin, dando invece al destinatario bjtcoin; ciò costringerebbe rapidamente bitcoin e bjtcoin a essere fungibili l’uno con l’altro, aumentando la “riserva totale” a 42 milioni senza mai incappare in quella linea di codice. Le norme “più morbide”, come quelle che non interferiscono con lo stato dell’applicazione, sono ancora più difficili da applicare.

Vogliamo essere in grado di dire che un cambiamento di protocollo che viola una di queste garanzie dovrebbe essere considerato illegittimo – dovrebbe esserci un’istituzione di coordinamento che sventola una bandiera rossa – anche se viene approvata con un voto. Vogliamo anche essere in grado di dire che un cambiamento di protocollo che segue alla lettera una norma, ma della quale ne viola palesemente lo spirito, dovrebbe comunque essere considerato illegittimo. E avendo le norme sul livello 2 – nella mente degli umani nella community, piuttosto che nel codice del protocollo – si raggiunge al meglio questo obiettivo.

Verso un equilibrio

Tuttavia, non sto andando dall’altra parte a dire che il voto con le monete, o altri schemi espliciti di voto on-chain, non hanno alcun ruolo nella governance. L’alternativa principale sembra essere il consenso dello sviluppatore core, tuttavia la modalità di fallimento di un sistema controllato da “intellettuali sulla torre d’avorio” che si preoccupano di filosofie e soluzioni astratte che suonano tecnicamente impressionanti, al di là delle reali preoccupazioni quotidiane come l’esperienza dell’utente e le spese di transazione sono, a mio avviso, comunque una vera minaccia da prendere sul serio.

Quindi, come possiamo risolvere questo enigma? Bene, in primo luogo, possiamo ascoltare le parole di slatestarcodex nel contesto della politica tradizionale:

L’errore da principiante è: vedi che alcuni sistemi sono in parte Moloch [es. catturato da interessi speciali disallineati], quindi dici “Ok, lo aggiusteremo mettendolo sotto il controllo di questo altro sistema. E controlleremo questo altro sistema scrivendo ‘NON DIVENTARE MOLOCH’ su di esso in un indicatore rosso brillante.”
(“Vedo che il capitalismo a volte si disallinea, risolviamolo mettendolo sotto il controllo del governo: controlleremo il governo avendo solo persone virtuose negli alti uffici”).
Non ho intenzione di affermare che esiste un’alternativa eccezionale, ma l’alternativa, a volte occasionale, è quella neoliberale – trovare un paio di sistemi eleganti che tutti ottimizzano secondo criteri diversi approssimativamente allineati con la felicità umana, mettendoli l’uno contro l’altro in una struttura di controlli e contrappesi, sperano di posizionarli in posti diversi come in quel modello del formaggio svizzero, di mantenere una sufficiente libera scelta individuale intorno al fatto che le persone passono uscire da qualsiasi sistema che diventa troppo terribile, e lasciare che l’evoluzione culturale faccia il resto.

Nella governance blockchain, sembra che questa sia l’unica via da seguire. L’approccio per la governance blockchain che sostengo è il “consenso multifattoriale” in cui vengono impiegati diversi indicatori di coordinamento e diversi meccanismi e gruppi, e la decisione finale dipende dal risultato collettivo di tutti questi meccanismi messi insieme. Questi flag di coordinamento possono includere:

• La roadmap (cioè l’insieme di idee trasmesse precedentemente nella storia del progetto sulla direzione in cui il progetto dovrebbe andare)
• Consenso tra i team di sviluppo core dominanti
• Il voto dei possessori delle monete
• Voti degli utenti, attraverso una sorta di sistema di votazione resistente al sybil-attack
• Norme stabilite (es. non interferenza con le applicazioni, limite di 21 milioni di monete)

Direi che è molto utile per il voto con le monete essere una delle varie istituzioni di coordinamento che decidono se un determinato cambiamento viene attuato o meno. È un segnale imperfetto e non rappresentativo, ma è resistente al sybil-attack – se vedi 10 milioni di voti ETH per una determinata proposta, non puoi ignorare ciò dicendo semplicemente “oh, sono solo troll russi assoldati con falsi account di social media”. È anche un segnale sufficientemente distaccato dal team di sviluppo principale che, se necessario, può fungere da controllo sullo stesso. Tuttavia, come descritto sopra, ci sono ottime ragioni per cui non dovrebbe essere l’unica istituzione di coordinamento.

E tutto questo è la differenza principale, rispetto ai sistemi tradizionali, che rende interessanti i sistemi blockchain: il “layer 1”, che sottende l’intero sistema, è la richiesta verso i singoli utenti di assentire a qualsiasi cambio al protocollo, cambio alla loro libertà e di valutare ogni minaccia credibile, e di “forkare” se qualcuno tenta di forzare loro dei cambiamenti che considerano ostili (vedi anche: http://vitalik.ca/general/2017/05/08/coordination_problems.html).

Il voto strettamente vincolante va bene anche in alcuni contesti limitati – ad esempio, nonostante i suoi difetti, la capacità dei minatori di votare sul limite del gas è una caratteristica che si è dimostrata molto utile in più occasioni. Il rischio che i minatori provino ad abusare del loro potere potrebbe essere inferiore al rischio che qualsiasi limite di gas specifico, o limite di dimensione del blocco codificato dal protocollo il giorno 1, finisca per portare a seri problemi, e in tal caso lasciare che i minatori votino sul limite del gas è una buona cosa. Tuttavia, “consentire a minatori o validatori di votare su alcuni parametri specifici che devono essere rapidamente modificati di volta in volta” è molto lontano dal dare loro un controllo arbitrario sulle regole del protocollo, o lasciare la convalida sull’esito del voto, e queste visioni più espansive di governance on-chain hanno un potenziale molto più oscuro, sia nella teoria che nella pratica.