Tag: casper ffg

Introduzione Il protocollo di consenso di Ethereum, Gasper, si compone di due elementi fondamentali: LMD GHOST e Casper FFG. Nel precedente articolo vi ho parlato di LMD GHOST e di come questo sia cruciale nella gestione dei fork su Ethereum. In questo nuovo episodio di Tech With Ale vi spiegherò invece nel dettaglio il funzionamento di Casper FFG (Casper Friendly Finality Gadget), il secondo componente del protocollo Gasper. Casper FFG è progettato per introdurre un meccanismo di finalizzazione dei blocchi, aumentando così la sicurezza (safety) della rete. [pms-restrict] Correctness: Liveness e Safety Nel contesto dell’informatica, in particolare nei sistemi concorrenti e distribuiti, la correctness (correttezza) viene spesso suddivisa in due proprietà fondamentali: safety e liveness. Un programma è considerato completamente corretto se soddisfa entrambe queste proprietà. Come vedremo, nel contesto delle blockchain ciò non è sempre possibile. Liveness La liveness, talvolta indicata anche come availability, viene spesso riassunta informalmente con la frase "something good will eventually happen", ovvero prima o poi succederà qualcosa di buono. Il prima o poi è importante, perché implica che non esiste un limite di tempo entro il quale quell'evento positivo debba necessariamente verificarsi. Nel contesto di un meccanismo di consenso, la liveness rappresenta la garanzia che tutti i processi, validatori o attori coinvolti, giungeranno prima o poi a un consenso, cioè a un accordo sul nuovo stato della blockchain. Questa proprietà è fondamentale perché garantisce che la blockchain continuerà a produrre nuovi blocchi e ad accettare nuove transazioni, anche in presenza di eventuali guasti o attacchi esterni. In Gasper, il compito di garantire la liveness di Ethereum è affidato a LMD GHOST. Safety La safety, sempre in modo informale, viene spesso descritta con l’espressione "nothing bad ever happens", ovvero non accade mai nulla di male. Un concetto centrale legato alla safety in un sistema distribuito è la consistency (consistenza). Questa proprietà assicura che, se chiedessimo a diversi nodi onesti qual è lo stato della blockchain a una certa altezza (ad esempio il saldo di un account), otterremmo sempre la stessa risposta, indipendentemente da quale nodo consultiamo. In un sistema veramente sicuro, tutti i nodi condividono una visione coerente e immutabile della blockchain. In Gasper, è Casper FFG a garantire la safety di Ethereum. Il Teorema di Brewer Il teorema di Brewer, noto anche come CAP theorem, è una teoria fondamentale nel campo dei sistemi distribuiti. Essa afferma che nessun network distribuito può garantire contemporaneamente consistency, availability e partition tolerance. Una blockchain è considerata partition tolerant se è in grado di continuare a funzionare correttamente anche quando alcuni messaggi tra nodi vengono persi o ritardati indefinitamente, cioè quando la rete è parzialmente guasta o segmentata. Dimostrare la validità del teorema CAP nel contesto delle blockchain è piuttosto semplice. Immaginiamo che, improvvisamente, una nazione decida di bloccare tutto il traffico dati in entrata e in uscita dal proprio territorio. I nodi che operano su server localizzati in quella regione smetterebbero di comunicare con il resto del mondo, causando così una partizione della rete in due sottogruppi: A e B. Supponiamo che un utente connesso al network B decida di inviare una transazione. Una volta eseguita e memorizzata nella blockchain, il network B raggiungerà uno stato differente rispetto al network A che, nel frattempo, potrebbe aver processato altre transazioni non conosciute da B. In questo scenario è evidente che la blockchain ha perso consistenza, poiché le due partizioni si trovano in stati differenti. Perdere consistenza significa compromettere la safety. L’unico modo per evitare questa perdita di consistenza sarebbe rifiutare le transazioni nelle due partizioni fino a quando la rete non sarà nuovamente in grado di comunicare in modo completo. In tal modo, il network conserva la safety, ma sacrifica l’availability e, di conseguenza, anche la liveness. Questo semplice esempio dimostra che, in caso di partizione della rete, occorre necessariamente scegliere se dare priorità alla safety, bloccando di fatto l’attività della chain, oppure alla liveness, accettando però il rischio di divergenze tra le partizioni. Gasper, il protocollo di consenso di Ethereum, garantisce sia safety che liveness in condizioni normali, ma dà priorità alla liveness in presenza di anomalie. Ethereum opera infatti su una rete asincrona, in cui non esistono garanzie sui tempi di consegna dei messaggi tra i nodi. Questo significa che, per mantenere sia safety che liveness, il sistema può tollerare al massimo un terzo dei validatori inattivi o malevoli. Nel caso di una partizione di rete, i nodi su ciascun lato continueranno a produrre blocchi. Tuttavia, in base alla proporzione di stake detenuta da ciascuna parte, solo uno dei due lati, oppure nessuno, potrà continuare a raggiungere la finalità dei blocchi, e quindi la safety. In situazioni di stallo prolungato, entra in gioco il meccanismo dell’inactivity leak, un sistema esclusivo di Ethereum che, attraverso penalità mirate, mira a ripristinare la finalizzazione dei blocchi anche in presenza di partizioni. Nel prosieguo dell’articolo ci concentreremo su Casper FFG e sulla strategia che adotta per raggiungere la finalità dei blocchi su Ethereum. All’inactivity leak sarà invece dedicata la prossima puntata di Tech With Ale, dove analizzeremo in dettaglio questo particolare meccanismo. Casper FFG: Preliminari Casper Friendly Finality Gadget è un protocollo che, preso singolarmente, non costituisce un vero e proprio meccanismo di consenso. Esso integra protocolli di consenso già esistenti con l'obiettivo di fornire finalità ai blocchi. Il nome del protocollo è in parte attribuibile a Vlad Zamfir. In parallelo a Vitalik, infatti, egli ideò Casper the Friendly Ghost, un protocollo basato su GHOST che mirava a limitare la censura da parte dei validatori nei confronti degli altri partecipanti (da qui il termine friendly) e a trovare un compromesso tra safety e availability. Inizialmente Zamfir aveva chiamato il proprio protocollo semplicemente The Friendly Ghost, ma, come da lui stesso ammesso, fu poi convinto da Jeremy Gardner a chiamarlo “Casper”, probabilmente ispirandosi anche al celebre cartone animato degli anni '90. Vitalik, in contatto con Zamfir, ideò un protocollo quasi del tutto differente dal suo e decise di chiamarlo Casper Friendly Finality Gadget, per sottolineare il fatto che non si tratta di un protocollo di consenso completo e autonomo, bensì di un gadget che aggiunge finalità a un protocollo di consenso sottostante. Cosa si intende per finalità? Nel contesto dei protocolli di consenso, la finalità (finality) è una proprietà riconducibile alla safety, e indica la garanzia che un determinato blocco, una volta finalizzato, non sarà mai più soggetto a riorganizzazioni della chain (e quindi a modifiche). Un blocco finalizzato implica che tutti i nodi onesti del network hanno raggiunto un consenso irrevocabile circa la sua inclusione nella blockchain. Questo significa che anche tutti i blocchi precedenti a quello finalizzato saranno a loro volta considerati finalizzati. I protocolli di consenso deterministici, come Tendermint, forniscono finalità immediata per ogni round, ossia finalizzano ogni blocco al termine della fase di consenso. Questo approccio massimizza la safety, ma introduce un limite dal punto di vista della liveness: qualora più di un terzo dei validatori risultasse non disponibile o non rispondesse (ad esempio a causa di partizioni di rete o attacchi malevoli), il sistema non riuscirebbe più a progredire, provocando un blocco del consenso. Al contrario, protocolli come quello di Bitcoin non offrono una vera finalità forte. Poiché è sempre possibile che emerga un ramo alternativo con un maggiore lavoro computazionale accumulato (heaviest long chain), ogni blocco può potenzialmente essere soggetto a una riorganizzazione (reorg). In tal caso, i nodi onesti devono ristrutturare la propria visione locale della chain, invalidando blocchi e transazioni precedentemente confermati. In questi contesti, si afferma spesso che una transazione può essere considerata sicura solo dopo un certo numero di conferme (confirmations). Tuttavia, queste conferme sono solo euristiche: un blocco con molte conferme è probabilmente stabile, ma non offre alcuna garanzia di finalità assoluta. La sicurezza delle transazioni aumenta col tempo, ma non raggiunge mai una vera finalizzazione, rendendo il sistema più resiliente dal punto di vista della liveness, ma più debole in termini di safety. Nozioni in Pillole: Cosa sono le confirmations? 💡 Con confirmations si intende il numero di blocchi aggiunti alla blockchain dopo il blocco che contiene una certa transazione. Come spiegato in precedenza, non vi è un numero di conferme che possano definire una transazione finalizzata nelle chain PoW; possiamo dolo dire che maggiori sono le conferme e maggiore sarà la sicurezza acquisita da quella transazione. I Concetti fondamentali dietro Casper FFG Casper FFG opera in modo differente rispetto a protocolli come Tendermint o Bitcoin. Si basa sui giudizi che i validatori esprimono su una coppia di checkpoint, denominati rispettivamente source e target, con l’obiettivo di determinare se tali blocchi possano essere giustificati e successivamente finalizzati. Questi giudizi vengono espressi attraverso dei voti inclusi nelle attestations, i quali sono ponderati in base al bilancio effettivo di ciascun validatore. Se tutto ciò ti sembra inizialmente poco chiaro, non preoccuparti: lo scopo di questa sezione è proprio quello di analizzare, passo dopo passo, ogni elemento chiave del funzionamento di Casper FFG. Come spiegato in questo articolo dedicato a LMD GHOST, i validatori non rilasciano le loro attestations tutti nello stesso momento: i voti sono distribuiti all’interno dei 32 slot che compongono un’epoca, e ogni validatore vota una sola volta per epoca. Un checkpoint corrisponde a uno slot la cui altezza è multipla di 32, ossia allo slot 32N, dove N > 0. Poiché nei sistemi informatici il conteggio inizia solitamente da 0, nella seguente immagine viene mostrato graficamente dove si collocano i blocchi checkpoint nella rete di Ethereum: I checkpoint rappresentano quindi il primo slot successivo alla chiusura di un’epoca, ed essendo slot multipli di 32 (cioè 32, 64, 96, ...), fungono da punti di riferimento per le votazioni dei validatori. All’interno di ciascuna attestation troviamo un voto espresso su una coppia di checkpoint, uno come source e l’altro come target. Si tratta, in sostanza, di due checkpoint sucsseguenti: nel nostro esempio, i validatori si troverebbero a esprimere un giudizio sul blocco 32 (source) e sul blocco 64 (target). Giustificaziione e Finalizzazione Casper FFG raggiunge la finalità attraverso un meccanismo articolato in due fasi successive: giustificazione e finalizzazione. Nel primo round, ciascun validatore trasmette alla rete il proprio checkpoint preferito per l’epoca corrente (che chiameremo X) e raccoglie le attestazioni degli altri validatori. Se almeno due terzi dei validatori, ponderati per lo stake, supportano lo stesso checkpoint X (supermaggioranza), allora esso viene considerato giustificato. Questa giustificazione rappresenta una proprietà locale, in quanto si basa sulla visione soggettiva del validatore: egli ritiene, sulla base delle informazioni disponibili, che la rete stia convergendo verso X. Tuttavia, in ambienti asincroni o in presenza di comportamenti malevoli, è possibile che tale percezione non sia condivisa da tutti i partecipanti, e che altri validatori non abbiano ancora maturato una visione coerente. Nel secondo round, ogni validatore comunica alla rete di aver giustificato il checkpoint X e raccoglie a sua volta le giustificazioni degli altri. Se almeno due terzi dei validatori confermano la giustificazione dello stesso checkpoint, allora è possibile procedere alla sua finalizzazione. A differenza della giustificazione, la finalizzazione è una proprietà globale: una volta che un checkpoint è stato finalizzato, nessun validatore onesto potrà più contribuire a una sua riorganizzazione. Anche se un nodo non ha ancora marcato X come finalizzato, si assume che abbia almeno riconosciuto la sua giustificazione, e non esiste alcun comportamento lecito (cioè non soggetto a slashing) che possa invalidarne la validità. Operativamente, il processo si articola come segue: Round 1: il validatore propone un checkpoint, raccoglie le proposte degli altri, e giustifica il checkpoint scelto se riscontra il supporto di almeno due terzi dei validatori. Round 2: comunica alla rete di aver giustificato il checkpoint, raccoglie le giustificazioni altrui, e procede alla finalizzazione se almeno due terzi dei validatori confermano la stessa giustificazione. In condizioni ideali, ciascun round corrisponde a un’epoca, con una durata di circa 6,4 minuti. Pertanto, la finalizzazione di un checkpoint richiede due epoche consecutive, per un totale di 12,8 minuti. Tuttavia, Casper FFG adotta una strategia che consente di finalizzare un checkpoint ogni epoca andando a sovrapporre le votazioni per il primo e il secondo round. Source, Target e Supermajority Link In Casper FFG, ogni validatore emette voti all’interno delle attestations, esprimendo una preferenza su una coppia ordinata di checkpoint, rappresentata come un collegamento s → t, dove s è il checkpoint di origine (source) e t quello di destinazione (target). Questa struttura consente di condensare, in un singolo messaggio, sia il voto del primo round (giustificazione), sia quello del secondo round (finalizzazione), seguendo così il processo a due fasi descritto in precedenza. Per essere considerato valido, un collegamento s → t deve rispettare il vincolo secondo cui t è un discendente di s nella chain. Il comportamento atteso da un validatore onesto prevede che il source coincida con il checkpoint giustificato più recente nella sua vista locale della catena, mentre il target sia un checkpoint successivo che discende logicamente dal primo, tipicamente quello dell’epoca corrente. Non è necessario che source e target siano consecutivi: è possibile saltare dei checkpoint. Tuttavia, in condizioni di rete ottimali, il target di un’epoca tende naturalmente a diventare il source dell’epoca successiva, seguendo una progressione ordinata. Quando un collegamento s → t riceve il supporto di almeno due terzi dei validatori, si parla di supermajority link. Nell’immagine mostrata, al tempo T, alla fine della terza epoca, i validatori si sono espressi sui checkpoint s e t evidenziati in figura. Il checkpoint s, che corrisponde allo slot 32 è già stato giustificato in precedenza e, in caso di una supermaggioranza verrà finalizzato. Il checkpoint t invece si appresta ad essere giustificato. Al tempo T+1 avremo che lo slot 64, precedentemente giustificato diventerà il nuovo checkpoint s da essere votato all’interno dell’epoca 4, mentre lo slot 96 che appartiene all’epoca corrente, diventerà il checkpoint t. A livello operativo, solo i voti inclusi nei blocchi vengono considerati validi ai fini del calcolo della finalità. A differenza di LMD GHOST, Casper FFG ignora i voti ricevuti via gossip o attraverso altri canali informali: ciò è motivato dalla necessità di avere un registro condiviso e verificabile, che è garantito unicamente dalla cronologia dei blocchi. Infine, come per LMD GHOST, i voti sono ponderati in base al bilancio effettivo del validatore. Un validatore con un bilancio inferiore a 32 ETH, ad esempio, avrà un peso proporzionalmente minore. Casper FFG: Funzionamento nei dettagli Chiariti gran parte dei concetti inerenti Casper FFG è arrivato il momento di spiegare concretamente come esso funziona. Ripartiamo prima di tutto dal concetto di giustificazione, finalizzazione e supermajority link. In un’applicazione reale, un validatore giustifica un checkpoint t se s → t è un supermajority link e il checkpoint s è a sua volta giustificato. Nelle immagini correlate a questa discussione, sono mostrati per semplicità solo gli slot checkpoint omettendo gli slot intermedi. Come descritto poco sopra, in caso di un supermajority link s → t che parte da un checkpoint s già giustificato e arriva ad un checkpoint t, lo slot target verrà giustificato esso stesso. Per la giustificazione non è richiesto che i due checkpoint siano susseguenti uno a l’altro, ma è ammesso anche operare dei salti. In un’applicazione reale, un validatore finalizza un checkpoint s se s → t è un supermajority link e il checkpoint t è un figlio diretto di s. A differenza di prima, il supermajority link s → t non solo giustifica t ma finalizza anche s in quanto t ne è un diretto discendente. K-Finality Quanto appena visto è ciò che è dettagliatamente descritto nel paper originale di Casper FFG. In Gasper però, è utilizzata una variante generalizzata che permette una maggiore flessibilità: il suo nome è k-finality. Con k-finality si intende la possibilità di finalizzare un checkpoint s, che vede esistere un supermajority link s → t, anche se t non è figlio diretto di s, a patto che i checkpoint fra s e t siano tutti giustificati. Vediamo un esempio per chiarire la questione. Nell’ipotesi 1, il supermajority link s → t unisce due checkpoint che non sono direttamente parenti, ma che sono seprati da checkpoint tutti giustificati. In questo caso il checkpoint t verrà dunque giustificato, seguendo le normali leggi di Caser FFG, mentre il checkpoint s viene finalizzato grazie alla k-finality. Nell’ipotesi 2 invece, dato che vi è un checkpoint di intermezzo che non è giustificato, il checkpoint t verrà giustificato ma il checkpoint s non verrà finalizzato in quanto non rispetta nè le leggi di Casper FFG, nè della k-finaliy. Gasper, nello specifico, adotta il 2-finality. Esso tiene traccia dello stato di giustificazione di quattro epoche consecutive e permette di ****processare ****i voti per i checkpoint target fino a due epoche precedenti. Le possibile casistiche sono dunque 4: Le ipotesi 2 e 4, cioè quelle che prevedono 1-finality sono le classiche situazioni che si presentano all’interno della rete Ethereum. I casi di 2-finality si verificano solo in situazioni in cui molte attestazioni sono in ritardo oppure quando siamo molto vicini alla soglia di partecipazione dei due terzi dei validatori. I checkpoint rappresentati in bianco non influiscono sulla casistica rappresentata, indipendentemente dal loro status. Le regole da seguire per i validatori In Ethtereum, ad ogni checkpoint è assegnato lo stesso numero dell’epoca a cui appartiene. Ad esempio, se un checkpoint risiede nell’epoca 4, esso sarà riferito come checkpoint 4. Casper FFG, al fine di garantire la correttezza dei voti, impone ai validatori due regole da seguire: Ogni validatore non può eseguire due voti diversi su uno stesso target. Al fine di violare questa regola, un validatore potrebbe decidere di: Votare per un solito target da due source differenti: s1 → t, s2 → t Votare per due target differenti partendo da un solito source: s → t, s → t’ Un validatore non può emettere un voto che “circonda” un voto precedente. In termini più specifici, non è possibile effettuare due votazioni s → t e s’ → t’ tale che s < s’ < t’ < t. Qualsiasi validatore che violi una delle regole elencate è soggetto a slashing. Questo significa che una parte, o l’intero importo, del suo stake può essere rimossa, e il validatore viene può essere espulso dal set di validatori. Le violazioni delle regole possono essere difficili da rilevare all’interno del protocollo stesso. Per questo motivo, ci si affida a servizi esterni, che si occupano di individuare le violazioni e inviare le prove ai proposer dei blocchi. I validatori che svolgono il loro compito onestamente vengono ben ricompensat; difatti la maggiorparte delle staking rewards dipende dal buon esito del loro voto. Influenza su LMD GHOST Nel protocollo LMD GHOST, la ricerca del blocco head inizierebbe ****sempre dal blocco di genesi. Tale regola viene però modificata da Casper FFG; difatti LMD GHOST inizia la sua ricerca del blocco head a partire dal checkpoint giustificato più recente che conosce, e ignora tutti i blocchi head potenziali che non discendono da quel checkpoint giustificato. Questa modifica alla regola di fork choice del protocollo di consenso è ciò che garantisce la finalità. Quando un nodo giustifica un checkpoint nella propria vista locale, si impegna a non tornare mai indietro da esso. Di conseguenza, la chain sottostante deve sempre includere quel checkpoint e tutti i rami che non includono quel checkpoint devono essere ignorati. Accountable Safety e Plausible Liveness Il protocollo di consenso Casper FFG fornisce due garanzie che sono analoghe, ma differenti, dai concetti di safety e liveness visti in precedenza. I protocolli PBFT classici garantiscono la safety solo quando meno di un terzo dei validatori è malevolo mentre, in caso contrario, non possono fare alcuna promessa. Casper FFG riesce invece a fornire essenzialmente la stessa garanzia di sicurezza anche quando i validatori malevoli controllano più di un terzo dello stake, rendendo i checkpoint finalizzati comunque irrevertibili. In aggiunta, fornisce anche la garanzia che, se mai dovessero essere finalizzati checkpoint in conflitto, i validatori malevoli verranno slashati. Questa garanzia è chiamata accountable safety. La sicurezza aggiuntiva dell’accountable safety non è però da confondersi con la garanzia fornita da un protocollo di consenso. Difatti essa si basa sull’imporre forte disincentivi ai validatori nel compiere azioni malevole e non a caso è spesso nominata anche finalità economica. Infatti, per poter finalizzare due checkpoint in conflitto, significa che una delle due regole fondamentali di Casper sono state violate da almeno 1/3 dei validatori ponderati per il loro stake. Tali comportamenti, una volta riconosciuti porteranno i validatori malevoli a subire lo slashing e a riportare i 2/3 dello stake a favore dei validatori onesti. Casper FFG non offre liveness nel senso classico di garantire che le transazioni degli utenti vengano incluse nella blockchain. Tutta la produzione dei blocchi e la costruzione della chain è responsabilità del meccanismo di consenso sottostante, che nel caso di Gasper è LMD GHOST. Tuttavia vogliamo sempre poter continuare a giustificare e finalizzare checkpoint se almeno due terzi dei validatori sono onesti, senza che nessuno di quei validatori venga slashati e non vogliamo mai finire in uno stallo in cui non è possibile finalizzare un nuovo checkpoint senza che i validatori onesti vengano slashati. Questa volontà rispecchia teoricamente i principi della liveness, attribuendo quindi a Casper la garanzia di plausible liveness. Le prove dell’accountable safety e della plausible liveness non verranno discusse in questo articolo. Conclusione Casper FFG rappresenta il secondo pilastro fondamentale del protocollo di consenso Gasper, adottato da Ethereum per garantire finalizzazione e sicurezza alla sua chain. In questo articolo abbiamo analizzato i concetti chiave che lo caratterizzano, come la giustificazione e la finalizzazione dei blocchi, i supermajority link, e accennato i concetti di accountable safety e plausible liveness. Abbiamo anche parzialmente visto in che modo Casper FFG si integra con LMD GHOST, modificandone la fork choice rule per costruire la chain sempre a partire dal checkpoint giustificato più recente. A differenza di altri protocolli di consenso, Casper FFG non è autonomo, ma funge da gadget che fornisce finalità economica a un protocollo sottostante. Questa architettura modulare consente ad Ethereum di bilanciare safety e liveness, offrendo garanzie solide in scenari normali e strumenti efficaci per gestire situazioni di rete degradate o ostili, come partizioni o attacchi coordinati. La forza di Casper FFG risiede nella sua capacità di prevenire riorganizzazioni della chain grazie alla finalizzazione, ma anche nel suo meccanismo di slashing che disincentiva fortemente comportamenti malevoli, contribuendo a mantenere l'integrità del network. Nel prossimo articolo tratteremo l’inactivity leak, un meccanismo di sicurezza di Ethereum che garantisce una risoluzione efficace quando si entra in situazioni di stallo del consenso prolungate nel tempo. [/pms-restrict]