Autore: Scott Sullivan | Pubblicazione originale: 29/08/2022 | Tradotto da: 31febbraio | Milano Trustless | Link: A Bitcoiner's Guide to Proof of Stake
Di solito i Bitcoiners non si preoccupano troppo di ciò che accade nella terra dei cachi (shitcoin-land), ma con il Merge previsto tra meno di una settimana, c'è stato un certo fermento su Bitcoin Twitter. Naturalmente la rete Bitcoin non ne risentirà, ma credo che questo "aggiornamento" meriti comunque una certa attenzione. Una volta che Ethereum si sarà ripulito dalle "sporche" e "dispendiose" esternalità di PoW, possiamo aspettarci che la guerra narrativa e credo che i Bitcoiners debbano essere pronti a rispondere al fuoco.
Imparare come funziona il PoS è un ottimo modo per interiorizzare le differenze e i compromessi tra PoW e PoS. Anche se avevo già visto tutte le argomentazioni di alto livello contro PoS - che PoS è più permissivo, centralizzante e oligarchico - ammetto che senza esaminare i dettagli, mi sembrava tutto un po' approssimativo. Immergendoci nell'algoritmo di PoS, possiamo iniziare a vedere come tutte queste proprietà emergano naturalmente da principi basilari. Quindi, se siete curiosi di sapere come funziona l'algoritmo PoS e perché porta a questo tipo di proprietà, continuate a leggere!
Risolvere il problema della doppia spesa
Cominciamo con un breve riassunto del problema che stiamo cercando di risolvere. Supponiamo di avere un grande gruppo di partecipanti a una rete di criptovalute che cerca di mantenere un libro mastro decentralizzato. Ecco il problema: come si possono aggiungere nuove transazioni al libro mastro di tutti, in modo che tutti siano d'accordo su quali nuove transazioni siano "corrette"? PoW risolve questo problema in modo abbastanza elegante: le transazioni sono raggruppate in blocchi, e ogni blocco richiede una grande quantità di lavoro computazionale per essere prodotto. La quantità di lavoro richiesta può aumentare o diminuire per garantire che i blocchi vengano prodotti in media ogni dieci minuti, dando a ogni nuovo blocco tutto il tempo di propagarsi nella rete prima che venga creato quello successivo. Qualsiasi ambiguità viene risolta selezionando la catena con il maggior numero di blocchi e si evita il double-spending, in quanto è necessario almeno il 51% dell'hashpower globale per recuperare un blocco che ha speso due volte.
Ma supponiamo che ora si voglia buttare via l'intuizione chiave di Satoshi che ha reso possibile tutto questo. Dopo tutto quei fastidiosi ASIC sono rumorosi, noiosi e consumano più energia di tutti i jet privati di George Soros, Bill Gates e Hillary Clinton messi insieme. C'è un modo per concordare in modo inequivocabile quali transazioni sono vere semplicemente parlandone?
La Proof of Stake di Ethereum risolve questo problema utilizzando due ingredienti chiave. Il primo consiste nel creare di tanto in tanto speciali "blocchi checkpoint", il cui scopo è quello di garantire a tutti i membri della rete la "verità" del sistema in momenti diversi . La creazione di un checkpoint richiede un voto a maggioranza di 2/3 da parte dei partecipanti, in modo da garantire che la maggioranza dei validatori sia d'accordo su quale sia la verità in quel momento. Il secondo ingrediente è quello di punire gli utenti che aggiungono ambiguità alla rete, un processo noto come "slashing". Ad esempio, se un validatore dovesse creare un fork o votare su una sidechain più vecchia (simile a un attacco del 51%), la sua quota verrebbe tagliata. I validatori possono essere tagliati anche per inattività, ma non in misura così elevata.
Questo ci porta al nostro primo principio alla base della PoS, ovvero che la PoS si basa su un sistema di incentivi negativi (basati su penalità). Questo principio contrasta fortemente con Bitcoin e con la proof-of-work, che è un sistema di incentivi positivi (basato sulla ricompensa). In Bitcoin, i miner possono tentare di infrangere le regole - blocchi mal formattati, transazioni non valide e così via - ma questi blocchi vengono semplicemente ignorati. Lo scenario peggiore è un po' di energia utilizzata per niente. I miner sono anche liberi di costruire su blocchi più vecchi ma, senza il 51% dell'hashpower, queste catene non riusciranno mai a recuperare, disperdendo ancora una volta solo energia. I miner che partecipano a queste azioni, intenzionalmente o meno, non devono preoccuparsi di perdere i bitcoin accumulati o le macchine da mining. Piuttosto che vivere nella paura, i minatori di bitcoin possono scegliere di agire e rischiare.
Il mondo è molto diverso per i validatori che vivono nella terra di Ethereum. Invece di lavorare sodo ed essere ricompensati per aver aggiunto sicurezza alla rete, i validatori non svolgono alcun lavoro effettivo, ma devono fare attenzione che il loro nodo non si comporti male, per evitare di vedere i loro risparmi andare in fumo. Se venissero proposte delle modifiche alla rete, il primo istinto di un validatore sarebbe quello di conformarsi a ciò che fanno tutti gli altri, altrimenti rischierebbe di essere tagliato. Essere un validatore significa vivere ogni giorno camminando suluue uova.
Tra l'altro, vivere in un sistema di incentivi negativi è uno dei "vantaggi" della proof-of-stake, secondo le FAQ di Vitalik:
Quindi, come funzionerebbe lo slashing a livello tecnico? Non dovremmo prima creare un elenco di tutti i validatori, per avere qualcosa da tagliare? La risposta è sì. Per diventare un validatore in Ethereum bisogna prima possedere ETH in uno speciale indirizzo di "staking". Questa lista è necessaria non solo per i tagli, ma anche per le votazioni, dato che per i blocchi di checkpoint è necessaria una maggioranza di 2/3.
Ci sono alcune implicazioni interessanti nel mantenere un elenco di tutti i validatori in ogni momento. Quanto è difficile aderire? Quanto è difficile andarsene? I validatori possono votare sullo stato degli altri validatori? Questo ci porta al secondo principio che sta alla base della PoS: la Proof of Stake è un sistema a permessi.
Il primo passo per diventare un validatore è depositare un po' di ETH in uno speciale indirizzo di staking. Quanto? Il minimo richiesto è di 32 ETH, pari a circa 50.000 dollari al momento in cui scriviamo. Per contestualizzare, un impianto di mining di bitcoin decente si aggira in genere intorno alle migliaia di dollari, e un miner domestico può iniziare con un singolo S9 per poche centinaia di dollari. A dire il vero, l'elevata tassa di ingresso dell'ETH ha una giustificazione tecnica, poiché una quota più alta significa meno validatori, il che ridurrebbe la larghezza di banda.
Quindi la tassa di deposito è alta, ma almeno chi possiede 32 ETH è libero di entrare o uscire in qualsiasi momento, giusto? Non proprio. Ci sono rischi per la sicurezza se grandi coalizioni di validatori dovessero entrare o uscire tutte nello stesso momento. Ad esempio, se la maggior parte della rete se ne andasse in una volta sola, potrebbe spendere due volte un blocco finalizzato riproducendo una biforcazione in cui non è mai uscita, senza essere slashato su nessuna delle due catene. Per mitigare questo rischio, le rampe di accesso e di uscita hanno un limite di throughput incorporato. Attualmente questo limite è impostato su max(4,|V|/65536) validatori per epoca (ogni 6,4 minuti), ed è lo stesso sia in entrata che in uscita. Ciò si traduce approssimativamente in un set completo di validatori ogni dieci mesi. Tra l'altro, anche se attualmente è possibile per i validatori pubblicare una transazione di "uscita" e smettere di validare, il codice per prelevare effettivamente i fondi non è ancora stato scritto. Sembra un po' come essere in Hotel California...
Un'ultima osservazione sugli incentivi per l'approvazione di nuovi validatori. Supponiamo di essere un azionista di una società grande e stabile che paga dividendi regolari ogni trimestre. Avrebbe senso regalare nuove azioni? Ovviamente no, perché così facendo diluireste i dividendi di tutti gli azionisti esistenti. Una struttura di incentivi simile esiste nella PoS, poiché ogni nuovo validatore diluisce le entrate di tutti i validatori esistenti. In teoria i validatori potrebbero semplicemente censurare ogni singola transazione che aggiunge un nuovo validatore, ma in pratica credo che un approccio così brusco sarebbe improbabile. Questo sarebbe molto evidente e distruggerebbe l'immagine di "decentralizzazione" di Ethereum da un giorno all'altro, facendo potenzialmente crollare il prezzo. Penso che si dovrebbe invece utilizzare un approccio più sottile. Ad esempio, le regole potrebbero cambiare lentamente nel tempo rendendo più difficile diventare un validatore, con scuse come "sicurezza" o "efficienza". Qualsiasi politica che arricchisca i validatori esistenti a scapito di quelli nuovi avrebbe una ricaduta finanziaria, che sia detta a voce alta o meno. Possiamo iniziare a capire perché il PoS tenderebbe all'oligarchia.
Panoramica dell'algoritmo Casper
Ora che conosciamo la strategia di alto livello alla base dei PoS, come funziona effettivamente l'algoritmo? Le idee principali alla base dei checkpoint e dello slashing sono state presentate in un algoritmo chiamato Casper, quindi inizieremo da lì. Casper di per sé non specifica nulla su come produrre i blocchi, ma fornisce piuttosto una struttura per sovrapporre una strategia di checkpoint/slashing a un albero di blockchain già esistente.
In primo luogo, si sceglie una costante arbitraria C come numero di "intervallo tra i checkpoint", che determina il numero di blocchi tra i checkpoint. Ad esempio, se C=100, i checkpoint avverranno ai blocchi 0, 100, 200 e così via. Poi tutti i nodi votano su quale blocco del checkpoint debba essere il prossimo checkpoint "qualificato" ("justified"). Invece di votare su singoli blocchi in modo isolato, i validatori votano su coppie di checkpoint (s,t), che collegano un checkpoint sorgente "s" precedentemente qualificato a un nuovo checkpoint di destinazione "t". Una volta che un collegamento di checkpoint (s,t) ottiene una maggioranza di 2/3 da parte dei partecipanti, allora t diventa un nuovo checkpoint giustificato. Il diagramma seguente mostra un esempio di albero dei checkpoint.
In questo diagramma, la funzione h(b) si riferisce all'"altezza del checkpoint", ovvero al multiplo di 100 del blocco. Si può notare che non ogni 100mo blocco è necessariamente qualificato, il che può accadere se la votazione non è andata a buon fine a una certa altezza. Ad esempio: supponiamo che all'altezza 200 due checkpoint distinti abbiano ricevuto ciascuno il 50% dei voti. Poiché votare due volte è un reato passibile di taglio, il sistema si "bloccherebbe" a meno che alcuni validatori non taglino volontariamente la propria quota per raggiungere i 2/3 dei voti. La soluzione sarebbe che tutti "saltassero" il checkpoint 200 e "ci riprovassero" al blocco 300.
Solo perché un checkpoint è qualificato, non significa che sia finalizzato. Affinché un checkpoint sia considerato definitivo, deve essere immediatamente seguito da un altro checkpoint giustificato all'altezza successiva. Ad esempio, se i punti di controllo 0, 200, 400, 500 e 700 sono tutti qualificati e collegati tra loro, solo il 400 sarà considerato "finalizzato", poiché è l'unico immediatamente seguito da un altro punto di controllo giustificato.
Poiché la terminologia è molto precisa, ricapitoliamo le tre categorie. Un "checkpoint" è qualsiasi blocco che si trova all'altezza C*n, quindi se C=100, tutti i blocchi con altezza 0, 100, 200, 300 e così via saranno tutti punti di controllo. Anche se venissero creati più blocchi ad altezza 200, sarebbero entrambi "checkpoint". Un punto di controllo è "qualificato" se è il blocco radice ad altezza 0, oppure se 2/3 dei validatori hanno votato per creare un collegamento tra un punto di controllo precedentemente qualificato e il punto di controllo attuale. Un checkpoint qualificato è quindi "finalizzato" se si collega a un altro alla prossima altezza possibile. Non tutti i checkpoint diventano necessariamente qualificati e non tutti quelli qualificati diventano necessariamente finalizzati, anche nella catena finale.
Regole di slashing in Casper
Le regole di slashing di Casper sono concepite in modo tale da rendere impossibile l'esistenza di due checkpoint finalizzati in due fork separati, a meno che almeno 1/3 dei validatori non infranga le regole di slashing. In altre parole: solo i checkpoint finalizzati dovrebbero essere contati come blocchi "veri" non ambigui. È anche possibile che due checkpoint qualificati si verifichino su entrambi i lati di una fork, ma non due checkpoint finalizzati. Inoltre non c'è alcuna garanzia su quando o dove si verificherà il prossimo checkpoint finalizzato, ma solo che se si dovesse verificare una divisione della catena, si dovrebbe stare seduti e aspettare fino a quando non appare un blocco finalizzato da qualche parte, e una volta che lo fa, si sa che quella è la catena "corretta".
Ci sono due regole di slashing in Casper che applicano questa proprietà:
La prima regola proibisce a chiunque di votare due volte su checkpoint con la stessa altezza target, quindi se un validatore votasse per due diversi blocchi di checkpoint con altezza obiettivo 200, sarebbe un'infrazione passibile di slash. Lo scopo di questa regola è impedire che la catena si divida in due diversi checkpoint giustificati con la stessa altezza, poiché ciò richiederebbe 2/3 + 2/3 = 4/3 dei voti totali dei validatori, il che implica che almeno 1/3 dei validatori ha infranto le regole di slashing. Però come abbiamo visto in precedenza, è possibile che i checkpoint qualificati "saltino" alcune altezze di blocco. Cosa impedisce a una catena di dividersi in diverse altezze di blocco? Ad esempio, il punto di controllo 200 non potrebbe dividersi in punti di controllo qualificati a 300 e 400 senza che nessun validatore venga tagliato?
È qui che entra in gioco la seconda regola, che fondamentalmente impedisce ai validatori di "mettere in un sandwich" i voti all'interno di altri voti. Ad esempio se un validatore votasse sia per 300→500 che per 200→700, sarebbe un'infrazione passibile di taglio. Nel caso di una divisione della catena, una volta che un ramo vede un checkpoint finalizzato, diventa impossibile per l'altro ramo vedere un checkpoint qualificato in seguito, a meno che almeno 1/3 dei validatori non abbia infranto la regola #2. Per capire perché supponiamo che la catena di blocchi si sia biforcata in checkpoint qualificati 500→800 e 500→900, e che a un certo punto la prima catena abbia visto un checkpoint finalizzato con link 1700→1800. Poiché sia 1700 che 1800 possono essere qualificati solo nel fork#1 (supponendo che nessuno abbia infranto la prima regola dello slashing), l'unico modo in cui il fork #2 potrebbe vedere un checkpoint qualificato dopo 1800 è se ci fosse qualche collegamento votato tra le altezze H<1700 e H>1800. Ma dal momento che questo voto "metterebbe in un sandwich" il collegamento 1700→1800 e richiederebbe un voto dei 2/3, e il 1700→1800 è già passato con un voto dei 2/3, allora almeno 1/3 dei validatori dovrebbe infrangere la regola #2. Il documento di Casper contiene un bel diagramma che dimostra questa proprietà:
E questo è tutto, seguite le regole di Casper e sarete a posto!
Sembra piuttosto semplice, no? Sono sicuro che PoS userebbe lo slashing solo come ultima risorsa per mantenere il consenso, e non come meccanismo estorsivo per fare pressione sui validatori affinché si comportino in un certo modo... giusto?
Questo ci porta al terzo principio della PoS: Non ci sono regole. Le "regole" sono quelle che dicono gli altri.
Un giorno il vostro nodo potrebbe tecnicamente seguire alla lettera ogni comandamento di Casper, e il giorno dopo i vostri risparmi potrebbero essere ridotti perché stavate facendo qualcosa che non piaceva agli altri. Avete approvato una transazione TEAM-RED quella volta? Domani la maggioranza del TEAM BLU potrebbe tagliarvi. O forse avete fatto il contrario e avete omesso troppe transazioni della TEAM ROSSO? Domani la maggioranza del TEAM-ROSSO potrebbe colpirvi per censura. La capacità di tagliare va ben oltre la portata limitata della censura dell'OFAC. Il PoS è come uno stallo messicano senza sosta, dove la minaccia implicita di taglio è sempre presente.
Non mi sorprenderebbe se, in un hard-fork conflittuale, entrambe le parti codificassero le regole di validazione dell'altro fork, nel caso volessero punire chiunque si unisca alla parte "sbagliata". Naturalmente, questa sarebbe un'opzione atomica e, come per le bombe nucleari, ogni parte potrebbe scegliere di colpire solo per ritorsione. Immagino che la maggior parte dei validatori individuali siano "neutrali", nel senso che darebbero la priorità all'autoconservazione finanziaria rispetto all'autosacrificio politico, ma potrebbero "schierarsi" esteriormente se sentissero che è la mossa giusta per evitare di essere tagliati.
Che ora è?
Ora che conosciamo le basi dei checkpoint e dei tagli, possiamo passare all'algoritmo vero e proprio utilizzato in Ethereum, chiamato Gasper. Si tratta di un portmanteau di Casper, di cui abbiamo già parlato, e GHOST, una strategia per selezionare la "migliore" catena di blocchi tra i checkpoint.
La prima cosa da capire di Gasper è che il tempo stesso è la principale variabile indipendente. Il tempo del mondo reale è diviso in unità di dodici secondi chiamate "slot", dove ogni slot contiene al massimo un blocco. Questi slot formano poi gruppi più grandi chiamati "epoche", dove ogni epoca si riferisce a intervalli tra checkpoint. Ogni epoca contiene 32 slot, per una durata di 6,4 minuti. Vale la pena notare che questo paradigma inverte la relazione causale tra tempo e produzione di blocchi rispetto alla PoW. Nella PoW, i blocchi vengono prodotti perché è stato trovato un hash valido, non perché è passato abbastanza tempo. In Gasper, invece, i blocchi vengono prodotti perché è passato abbastanza tempo reale per arrivare allo slot successivo. Posso solo immaginare i complicati bug di temporizzazione che un sistema del genere potrebbe incontrare, soprattutto quando non si tratta di un solo programma in esecuzione su un computer, ma di decine di migliaia di computer che cercano di funzionare in sincronia in tutto il mondo. Si spera che gli sviluppatori di Ethereum conoscano le false credenze che i programmatori attribuiscono al tempo.
Ora supponiamo di avviare un nodo validatore e di sincronizzare la blockchain per la prima volta. Solo perché avete osservato che certi blocchi fanno riferimento a determinati timestamp, come essere sicuri che quei blocchi siano stati realmente prodotti in quei momenti? Poiché la produzione di blocchi non richiede alcun lavoro, un gruppo di validatori malintenzionati non potrebbe simulare una blockchain completamente falsa fin dal primo giorno? E se si vedessero due blockchain concorrenti, come si farebbe a sapere quale è vera?
Questo ci porta al quarto principio che sta alla base della Proof of Stake: la PoS si basa sulla verità soggettiva. Semplicemente non esiste un modo oggettivo per scegliere tra due blockchain in competizione, e ogni nuovo nodo della rete deve in ultima analisi fidarsi di una fonte di verità esistente per risolvere qualsiasi ambiguità. Ciò contrasta in modo significativo con Bitcoin, dove la "vera" catena è sempre quella con il maggior numero di lavoro. Non importa se un migliaio di nodi vi dicono la catena X, se un singolo nodo trasmette la catena Y e questa contiene più lavoro, allora Y è la blockchain corretta. L'intestazione di un blocco può dimostrare il proprio valore, eliminando completamente la necessità di fiducia.
Affidandosi alla verità soggettiva PoS reintroduce la necessità di fiducia. Ora, ammetto che forse sono leggermente di parte, quindi se volete leggere l'altra parte, Vitalik ha scritto un saggio contenente il suo punto di vista qui. Ammetto che, in pratica, una divisione della catena non sembra così probabile, date le regole di Casper, ma a prescindere da ciò, mi sento tranquillo in Bitcoin sapendo che questa non è nemmeno una possibilità.
Produzione di blocchi e votazione
Adesso che conosciamo bene gli slot e le epoche, come vengono prodotti e votati i singoli blocchi? All'inizio di ogni epoca, l'intero set di validatori viene suddiviso "casualmente" in 32 gruppi, uno per ogni slot. Durante ogni slot, un validatore viene scelto "casualmente" per essere il produttore di blocchi, mentre gli altri vengono scelti per essere i votanti (o "attestatori"). Ho messo "casualmente" tra virgolette perché il processo deve essere deterministico, dato che tutti devono concordare senza ambiguità gli stessi set di validatori. Tuttavia, questo processo deve anche essere non sfruttabile, poiché essere il produttore del blocco è una posizione altamente privilegiata grazie alle ricompense extra disponibili dal Miner Extractable Value, o come è stato ribattezzato, "Maximum Extractable Value". Un'ottima lettura su questo tema è Ethereum is a Dark Forest.
Una volta prodotto un blocco, come votano o "attestano" gli altri validatori? La proposta del blocco dovrebbe avvenire entro la prima metà (sei secondi) di uno slot, mentre l'attestazione entro la seconda metà, quindi in teoria dovrebbe esserci abbastanza tempo per gli attestatori per votare il blocco del proprio slot. Ma cosa succede se il proponente del blocco è offline, o non riesce a comunicare, o costruisce un blocco sbagliato? Il compito di un attestatore non è necessariamente quello di votare il blocco di quello slot, ma piuttosto quello che "sembra il migliore" dal suo punto di vista in quel momento. In condizioni normali, di solito si tratta del blocco di quello slot, ma potrebbe anche essere un blocco più vecchio se qualcosa è andato storto. Ma cosa significa tecnicamente "sembra il migliore"? È qui che entra in gioco l'algoritmo GHOST.
GHOST è l'acronimo di "Greediest Heaviest Observed SubTree" (sottoalbero più pesante sotto osservazione) ed è un algoritmo ricorsivo avido per trovare il blocco con l'attività più "recente". In pratica, questo algoritmo esamina tutti i blocchi recenti sotto forma di albero e scende lungo l'albero selezionando avidamente il ramo con il maggior numero di attestazioni cumulative su quell'intero sottoramo. Solo l'attestazione più recente di ciascun validatore conta ai fini della somma, e alla fine questo processo approda a un blocco foglia.
Le attestazioni non sono solo voti per il miglior blocco attuale, ma anche per il checkpoint più recente che ha portato a quel blocco. Vale la pena notare che in Gasper i checkpoint sono basati sulle epoche piuttosto che sulle altezze dei blocchi. Ogni epoch si riferisce esattamente a un blocco di checkpoint, che è il blocco nel primo slot di quell'epoca o, se lo slot è stato saltato, il blocco più recente prima di quello slot. Lo stesso blocco può teoricamente essere un checkpoint in due epoche diverse se un'epoca ha saltato ogni singolo slot, quindi i checkpoint vengono rappresentati utilizzando coppie (epoca, blocco). Nel diagramma seguente, EBB sta per "Epoch Boundary Block" e rappresenta il checkpoint di un'epoca specifica, mentre "LEBB" sta per "Last Epoch Boundary Block" e rappresenta il checkpoint più recente in assoluto.
Come nel caso di Casper, un checkpoint diventa qualificato quando il numero totale di attestazioni supera la soglia dei 2/3, e finalizzato se è immediatamente seguito da un altro checkpoint qualificato nell'epoca successiva. Un esempio di come funziona questa votazione è mostrato di seguito.
Ci sono due condizioni di slashing in Gasper, che sono analoghe alle regole di slashing in Casper:
- Non si può votare due volte nella stessa epoca.
- Nessun voto può contenere punti di controllo epocali che "incastrano" i punti di controllo epocali di un altro voto.
Nonostante siano basate sulle epoche invece che sulle altezze dei blocchi, le regole di Casper assicurano comunque che non ci siano due checkpoint finalizzati su catene diverse, a meno che 1/3 dei validatori non possa essere tagliato.
Vale anche la pena notare che le attestazioni sono incluse nei blocchi stessi. Analogamente a come un blocco in PoW si giustifica usando il suo hash, un checkpoint finalizzato in PoS si giustifica usando tutte le sue attestazioni passate. Quando qualcuno infrange le regole dello slashing, le attestazioni sbagliate sono incluse in un blocco che prova la violazione. C'è anche una piccola ricompensa per il produttore del blocco che ha incluso la violazione, per fornire un incentivo a punire chi infrange le regole.
Fork
È interessante pensare a cosa potrebbe capitare in caso di fork. Per ricapitolare rapidamente: una biforcazione si riferisce a una modifica delle regole di consenso e si presenta in due varianti: hard fork e soft fork. In un hard fork, le nuove regole non sono retrocompatibili, il che potrebbe portare a due blockchain in competizione tra loro se non tutti passano ad una nuova versione. In un soft fork, le nuove regole sono più restrittive di quelle precedenti, pur mantenendole compatibili con il passato. Una volta che più del 50% dei miner o dei validatori iniziano ad applicare le nuove regole, il meccanismo di consenso passa senza dividere la catena. I soft fork sono generalmente associati agli aggiornamenti e ai nuovi tipi di transazioni, ma tecnicamente includono anche qualsiasi tipo di censura applicata da una maggioranza del 51%. PoS ha anche un terzo tipo di "fork" non presente in PoW: la divisione della catena senza alcuna modifica delle regole. Ma dato che ne abbiamo già parlato, ci concentreremo su hard e soft fork.
Cominciamo con il caso più semplice: un hard fork autonomo e conflittuale. Per contenzioso intendo una modifica delle regole che divide politicamente gli utenti. Una correzione di un bug o una modifica tecnica minore probabilmente non sarebbe controversa, ma qualcosa come la modifica della ricompensa di convalida probabilmente lo sarebbe. Se un hard fork fosse abbastanza controverso, potrebbe portare a una divisione della catena, che verrebbe risolta economicamente dagli utenti che vendono una catena e comprano l'altra. Sarebbe simile alla scissione di Bitcoin Cash nel 2017, che sembra avere un chiaro vincitore:
Supponiamo che un giorno i validatori si siano seduti e abbiano deciso di non essere pagati abbastanza e di aumentare le loro ricompense dal 5%/anno al 10%/anno. Questo sarebbe un chiaro compromesso a favore dei validatori a scapito dei non validatori, che ora verrebbero ulteriormente dilatati. In caso di divisione della catena, quale catena vincerebbe?
Questo porta al nostro quinto principio della PoS, ovvero che il denaro è potere. Dei 120 milioni di ETH esistenti, oltre il 10% viene attualmente accantonato, come si vede nel grafico sottostante.
In un fork e relativa contesa tra validatori e non validatori, supponendo che tutti i non validatori vendano sul mercato la nuova catena e tutti i validatori vendano sul mercato la vecchia catena, in teoria vincerebbe la vecchia catena, poiché la maggioranza degli ETH sarebbe ancora detenuta dai non validatori (90% contro 10%). Ma ci sono altre cose da considerare. Innanzitutto, dopo la divisione della catena, i validatori avrebbero ancora il "controllo" di entrambe le blockchain. Se i validatori fossero in grado di influenzare l'altra catena, potrebbero essere incentivati a farla fallire. In secondo luogo c'è anche l'opzione atomica discussa in precedenza, in base alla quale la nuova catena potrebbe colpire chiunque stia ancora convalidando la vecchia catena per fare pressione sull'adesione. Non ultimo: i validatori avrebbero probabilmente una notevole influenza sociale e politica su tutti gli altri membri della rete. Se Vitalik, la Fondazione Ethereum e gli exchange decidessero all'unisono di aumentare la ricompensa per la palificazione, trovo difficile credere che i normali utenti e validatori di Ethereum possano mantenere in vita il vecchio fork, rendendolo al contempo più prezioso attraverso la pressione sulle vendite.
Passando ai soft fork, cosa succederebbe in un soft fork controverso, come la censura dell'OFAC? I validatori sono abbastanza centralizzati, come si può vedere nel grafico sottostante.
A differenza della PoW, dove i miner possono cambiare pool premendo un pulsante, i validatori di Ethereum sono bloccati a un indirizzo di staking finché non elaborano una transazione di uscita. Se Lido e i principali exchange fossero costretti a censurare determinate transazioni, potrebbero facilmente superare la maggioranza dei 2/3 necessaria per decidere i checkpoint. Prima abbiamo visto come Vitalik e gli altri validatori di ETH potrebbero cercare di contrastare un soft fork di censura con un loro hard fork di controcensura, tagliando i censori durante il processo. Anche se riuscissero a creare un fork, molto valore verrebbe distrutto nel processo, sia per il taglio che per la perdita di fiducia.
Riflessioni conclusive
In questo saggio abbiamo esaminato come PoS risolve il problema della doppia spesa con Gasper, una combinazione di regole di checkpoint/slashing chiamata Casper e una regola di votazione del "miglior blocco" chiamata GHOST. Ricapitolando, Gasper divide il tempo in unità chiamate slot, dove ogni slot può avere al massimo un blocco, e gli slot sono raggruppati in epoche, dove ogni epoca si riferisce a un intervallo tra checkpoint. Se la maggioranza dei 2/3 vota su un checkpoint, questo diventa qualificato (justified) e se si verificano due checkpoint qualificati di seguito, il primo di questi due checkpoint diventa finalizzato. Una volta che un checkpoint diventa definitivo, diventa impossibile finalizzare una catena parallela, a meno che 1/3 dei validatori non venga tagliato.
In questo processo abbiamo scoperto cinque principi di PoS:
- PoS utilizza una struttura di incentivi negativi (basati su penalità).
- La PoS è un sistema a permessi.
- PoS non ha regole.
- La PoS si basa sulla verità soggettiva.
- Nella PoS, il denaro è potere.
Ognuno di questi principi ha un comportamento opposto in PoW:
- PoW utilizza un sistema di incentivi positivi (basati sulle ricompense).
- PoW è un sistema senza permessi (chiunque può iniziare o interrompere il mining in qualsiasi momento).
- Nella PoW, i fork che modificano le regole vengono ignorati.
- La PoW si basa sulla verità oggettiva.
- Nella PoW, i miner sono al servizio degli utenti e hanno poco potere.
Credo che ognuno debba sforzarsi di creare il tipo di mondo in cui vuole vivere. Se, come me, volete vivere in un mondo senza permessi, dove potete avere il controllo sul vostro denaro, dove il duro lavoro viene premiato e la proprietà passiva è una responsabilità e dove il vostro denaro conserverà il suo valore molto lontano nel futuro senza cambiare per capriccio, allora potreste voler pensare attentamente ai compromessi tra PoW e PoS, e lottare a favore dei principi in cui intendete credere.
