Tag: Inactivity Leak

Introduzione Nei precedenti articoli dedicati al protocollo di consenso di Ethereum, abbiamo approfondito il funzionamento di LMD GHOST e di Casper FFG. In questo nuovo episodio di Tech With Ale, ci concentreremo invece sull’inactivity leak, un meccanismo speciale che può attivarsi all'interno della Beacon Chain in condizioni di emergenza. In tale regime, le logiche di ricompensa e penalità vengono modificate per penalizzare in modo molto più severo i validatori inattivi, ovvero coloro che non partecipano correttamente al processo di consenso. L’inactivity leak si attiva quando la Beacon Chain non riesce a finalizzare checkpoint per più di quattro epoche consecutive, una situazione che si verifica, nella maggior parte dei casi, quando oltre un terzo dei validatori è offline. Nei capitoli che seguono, forniremo una panoramica dei meccanismi di incentivazione previsti dal protocollo di Ethereum, con un focus particolare sul funzionamento, le implicazioni e le finalità dell’inactivity leak. [pms-restrict] Ethereum: Ricompense e Penalità Le blockchain permissionless sono sistemi che combinano varie strategie per poter operare correttamente. In particolare, la crittografia garantisce il rispetto delle regole del protocollo quando è possibile farlo in modo deterministico, mentre gli incentivi economici entrano in gioco nei casi in cui il protocollo non può imporre un comportamento, ma può renderlo la scelta più conveniente per i partecipanti. Il comportamento atteso dai partecipanti al network è quello di garantire il rispetto della liveness e della safety, concetti già approfonditi nell’articolo dedicato a Casper FFG. Tralasciando gli aspetti puramente crittografici, Ethereum impiega una serie di strumenti economici per orientare il comportamento degli attori verso l’interesse collettivo della rete. Questi strumenti si suddividono principalmente in: Ricompense, assegnate per azioni che favoriscono il corretto funzionamento del protocollo; Penalità, distinte in: sanzioni minori, per comportamenti negligenti o subottimali; punizioni gravi (es. slashing), applicate in risposta a violazioni intenzionali delle regole di sicurezza. Nel contesto di Ethereum, questi incentivi economici si articolano in più livelli: Stake: Nel modello di consenso basato su Proof-of-Stake (PoS), lo stake rappresenta il cuore dell’infrastruttura economica. Ogni validatore deposita un certo quantitativo di ETH a garanzia del proprio comportamento. In caso di violazioni, il validatore può perdere parte o tutto il proprio deposito. L’influenza di ciascun validatore è determinata dal suo saldo effettivo (effective balance), calcolato sulla base del saldo reale, ma limitato superiormente a 32 ETH. Questo valore stabilisce sia il peso del validatore nelle votazioni sia l’ammontare delle ricompense e delle penalità che riceve. Ricompense per il comportamento corretto: I validatori che seguono correttamente il protocollo sono ricompensati con l’emissione di nuovi ETH. In particolare, vengono premiate attività quali:La proposizione di blocchi validi nella Beacon Chain;L’emissione di attestazioni tempestive e coerenti con la visione corrente della blockchain.Queste ricompense incentivano direttamente la partecipazione attiva e affidabile al consenso, contribuendo a mantenere elevati livelli di liveness e safety. Penalità per comportamenti negligenti: In presenza di condotte inattive o scorrette, il protocollo applica penalità proporzionali. Tra le infrazioni più comuni rientrano:La mancata emissione di attestazioni;L’invio tardivo di attestazioni;La mancata partecipazione nei processi di finalizzazione.In condizioni normali, queste penalità sono relativamente contenute. Tuttavia, quando l’inattività di una parte significativa dei validatori compromette la finalizzazione della chain, entra in gioco un meccanismo di emergenza chiamato inactivity leak. Inactivity Leak: Questo regime speciale si attiva quando la Beacon Chain non riesce a finalizzare per almeno quattro epoche consecutive, tipicamente perché oltre un terzo dei validatori è offline. Durante l’inactivity leak:Le penalità per inattività aumentano progressivamente;Le ricompense vengono ridotte o annullate.L’obiettivo è degradare selettivamente i bilanci effettivi dei validatori inattivi, fino a ristabilire la soglia dei due terzi di stake attivo necessaria per tornare alla finalizzazione. Questo meccanismo funge da sistema di recupero automatico, riportando gradualmente il protocollo in uno stato di consenso operativo. Slashing: Lo slashing è la forma di penalità più severa, riservata a comportamenti esplicitamente malevoli che compromettono la sicurezza del protocollo. Esempi tipici includono:La firma di due attestazioni contraddittorie per lo stesso slot;La proposta di blocchi multipli nello stesso intervallo di tempo;Il double-signing o altre azioni che possono portare a fork dannosi.Un validatore slashed subisce la perdita forzata di una parte significativa (fino al 100%) del proprio stake, ed è espulso dal protocollo. Il meccanismo di slashing costituisce una forte deterrenza economica contro attacchi intenzionali. Le considerazioni sopra riportate si riferiscono al livello di consenso del protocollo Ethereum. Esistono tuttavia ulteriori meccanismi di remunerazione esterni a questo layer, tra cui: Il MEV (Maximal Extractable Value), ovvero il valore aggiuntivo che un validatore può ottenere ordinando le transazioni in modo strategico; Il restaking, una pratica che consente di mettere a rendita gli stessi asset già in staking anche in altri protocolli. Inactivity Leak: Un Primo Approccio Nel protocollo di consenso di Ethereum, la finalizzazione regolare dei checkpoint è un meccanismo centrale per garantire la safety del sistema. Tuttavia, in condizioni eccezionali, ad esempio in caso di una partizione della rete o di un attacco su larga scala, può accadere che la Beacon Chain non riesca a finalizzare alcun checkpoint per un periodo prolungato. Se questa situazione persiste per più di quattro epoche consecutive (valore corrispondente al parametro di soglia MIN_EPOCHS_TO_INACTIVITY_PENALTY), il protocollo attiva automaticamente un regime di emergenza noto come inactivity leak. Funzionamento del Regime di Inactivity Leak L’inactivity leak è stato progettato per consentire al sistema di recuperare la finalizzazione anche in presenza di una prolungata inattività da parte di almeno un terzo dei validatori. In questo stato, il protocollo modifica le regole di incentivo ed esegue le seguenti azioni: I validatori che emettono attestazioni non ricevono ricompense, mentre le penalità per mancata partecipazione restano attive e vengono applicate normalmente. I validatori classificati come inattivi vedono crescere progressivamente il proprio inactivity score, un parametro individuale che determina un’ulteriore penalità la cui entità aumenta nel tempo, seguendo una dinamica potenzialmente quadratica. Le ricompense per i proponenti di blocchi e per i membri del sync committee non subiscono modifiche e continuano a essere distribuite. Poiché la finalizzazione richiede il voto favorevole di validatori che rappresentino almeno due terzi dello stake totale, un periodo prolungato di inattività può bloccare indefinitamente il progresso della chain, compromettendo anche la liveness del protocollo. Per contrastare questo scenario, l’inactivity leak agisce secondo un principio di adattamento dinamico del quorum: penalizzando progressivamente i validatori offline, il loro peso sul totale dello stake si riduce. Questo processo continua finché i validatori attivi non rappresentano almeno i 2/3 dello stake residuo, consentendo così di riprendere la finalizzazione. Prevenzione di Attacchi Strategici Un aspetto particolarmente rilevante nella progettazione dell’inactivity leak è la sospensione delle ricompense per le attestazioni, una scelta mirata a contrastare i cosiddetti attacchi di scoraggiamento (discouragement attacks). In questo tipo di attacco, un validatore malevolo potrebbe sfruttare strumenti di censura selettiva o attacchi DDoS per impedire ad altri validatori di partecipare, restando però attivo e continuando a percepire le ricompense previste dal protocollo. In tal modo, l’attaccante trarrebbe vantaggio economico da una condizione che penalizza gli altri partecipanti, generando un evidente incentivo non funzionale alla chain. Per neutralizzare questa dinamica, Ethereum annulla completamente le ricompense per le attestazioni durante il periodo di inactivity leak, rendendo tale strategia non profittevole anche per chi la mette in atto. In parallelo, le penalità inflitte ai validatori inattivi non vengono redistribuite tra gli altri validatori, ma sono interamente bruciate (burned), ovvero rimosse dalla circolazione. Inactivity Leak: La Matematica Dietro al Protocollo Per comprendere l’impatto dell’inactivity leak sui validatori, consideriamo il caso limite di un validatore che rimane completamente offline durante l’intero periodo di mancata finalizzazione della Beacon Chain. In questa situazione, il validatore è soggetto a una penalità per ogni epoca, calcolata secondo la seguente formula: (t * B)/ α dove: t rappresenta il numero di epoche trascorse dall’ultima finalizzazione, B è il saldo effettivo (effective balance) del validatore, α è il coefficiente di penalità per inattività (INACTIVITY_PENALTY_QUOTIENT), attualmente fissato a 16.777.216. Tale formulazione risale alla prima versione del meccanismo di inactivity leak, quando la penalità era applicata in modo globale e uniforme: tutti i validatori non partecipanti venivano penalizzati allo stesso modo, a prescindere dal loro comportamento storico. Questo approccio si è dimostrato problematico in termini di equità, poiché penalizzava severamente anche quei validatori che, pur avendo partecipato correttamente per la maggior parte del tempo (ad esempio il 90% delle epoche), si trovavano temporaneamente offline. In tali casi, le perdite potevano arrivare a circa il 4% dello stake, una cifra rilevante in termini assoluti. Per correggere questa situazione, l’upgrade Altair ha introdotto un sistema di penalità personalizzato, basato su un parametro individuale chiamato inactivity score. Questo punteggio rappresenta una misura storica del livello di inattività del validatore ed è utilizzato per modulare le penalità in modo più equo. Il punteggio: ha un valore minimo di zero, non può mai assumere valori negativi. L’inactivity score viene aggiornato a ogni epoca, seguendo regole ben precise: Alla fine dell’epoca N: Se il validatore ha prodotto un voto corretto e tempestivo nell’epoca N−1, il suo score viene ridotto di 1. In caso contrario, lo score aumenta di un valore pari al parametro INACTIVITY_SCORE_BIAS, attualmente fissato a 4. Quando la rete non si trova in stato di inactivity leak, ogni validatore vede comunque decrescere il proprio score di un valore pari a INACTIVITY_SCORE_RECOVERY_RATE, che è attualmente pari a 16 per epoca. Questo meccanismo consente di distinguere i validatori sistematicamente inattivi da quelli che subiscono disconnessioni temporanee o isolate, mitigando le penalizzazioni per chi partecipa in modo generalmente corretto ma può occasionalmente incorrere in malfunzionamenti. Durante un periodo di inactivity leak, l’evoluzione dell’inactivity score di ciascun validatore è determinata principalmente da due parametri: la percentuale media di partecipazione, indicata con p (compresa tra 0 e 1), e il valore di bias, rappresentato dal parametro INACTIVITY_SCORE_BIAS, che denotiamo con λ. Lo score atteso di un validatore dopo N epoche può essere approssimato dalla seguente espressione: scoreN = max(0,N⋅((1−p)λ−p)) Sostituendo il valore attuale di λ = 4, utilizzato nel protocollo Ethereum, la formula si semplifica in: scoreN = max(0,N⋅(4−5p)) Da questa relazione emerge un risultato molto importante: se un validatore partecipa almeno all’80% delle epoche, ossia se p≥0.8, allora il termine (4−5p) diventa minore o uguale a zero, e lo score rimane costantemente vicino a zero. In altre parole, il protocollo è tollerante verso validatori che, pur non perfetti, mantengono un’elevata affidabilità operativa. Il grafico seguente, preso dall’ottimo lavoro di Ben Edgington, eth2book illustra alcuni scenari possibili. Consideriamo uno scenario in cui l’inactivity leak ha inizio all’epoca 0 e si conclude dopo 100 epoche. Vengono analizzati cinque validatori, ciascuno con un diverso profilo di partecipazione. Per semplicità, definiamo come online un validatore che emette un voto corretto e tempestivo in ogni epoca. Le caratteristiche dei validatori sono le seguenti: Sempre online (always online): il validatore partecipa regolarmente in ogni epoca. Il suo inactivity score rimane costantemente pari a 0. Online per il 90% del tempo: il validatore partecipa alla maggior parte delle epoche, con rare assenze. Il suo inactivity score resta contenuto e prossimo allo zero, coerentemente con l’analisi teorica che dimostra come partecipazioni superiori all’80% mantengano lo score stabile. Online per il 70% del tempo: in questo caso, il validatore accumula uno score crescente, sebbene in modo relativamente lento. La penalità riflette un comportamento che, pur non essendo completamente negligente, si discosta significativamente dal comportamento atteso. Generalmente online, ma completamente offline tra le epoche 50 e 75 (intervallo A → B): durante la prima metà del leak, il validatore rimane online, mantenendo uno score pari a 0. Tuttavia, nel periodo di disconnessione lo score cresce rapidamente. Al ritorno online, lo score inizia a decrescere in modo progressivo. Sempre offline: il validatore non partecipa a nessuna epoca durante il leak. Il suo inactivity score cresce linearmente e rapidamente, accumulando penalità in modo continuo per tutta la durata del regime di emergenza. Al termine dell’inactivity leak, il protocollo prevede un meccanismo di decadimento dello score, che si applica a tutti i validatori, indipendentemente dal loro comportamento. La velocità con cui ciascun validatore tornerà a uno score pari a zero dipende dal proprio tasso di partecipazione nelle epoche successive: i validatori attivi vedranno lo score azzerarsi più rapidamente, mentre per quelli ancora intermittenti o offline il processo sarà più lento. Penalità Applicata Considerando l’Inactivty Score A ogni epoca, viene applicata a ciascun validatore una penalità proporzionale al proprio livello di inattività, misurato tramite l’inactivity score. La formula che regola l’importo della penalità per il validatore è la seguente: SiBi/(INACTIVITY_SCORE_BIAS * INACTIVITY_PENALTY_QUOTIENT) dove: Si è l’inactivity score del validatore i, Bi è il saldo effettivo (effective balance) del validatore i, INACTIVITY_SCORE_BIAS è una costante del protocollo, attualmente pari a 4, INACTIVITY_PENALTY_QUOTIENT è il denominatore del sistema di penalità, attualmente pari a 16.777.216. Prendendo spunto ancora una volta da eth2book, nell’immagine sottostante è mostrato l’effetto delle penalità su 5 differenti tipologie di validatori. In particolare, dall’analisi dei diversi profili di validatori emergono i seguenti comportamenti: I validatori sempre online (always online) non subiscono alcuna penalità: il loro inactivity score rimane costantemente pari a zero. I validatori con un uptime del 90% accumulano penalità trascurabili, confermando che una partecipazione superiore all’80% è sufficiente per evitare conseguenze economiche significative. I validatori con un uptime del 70% o soggetti a disconnessioni temporanee vedono una penalità che cresce in modo quasi lineare durante il periodo di leak, ma che si interrompe rapidamente non appena termina lo stato di emergenza. I validatori completamente offline subiscono una penalità che cresce in modo quadratico: lo score aumenta rapidamente durante il leak, e continua a generare penalità anche dopo la sua conclusione, finché non si azzera gradualmente nelle epoche successive. Questa persistenza delle penalità oltre la fine dell’inactivity leak è una scelta progettuale deliberata. Interrompere le penalità immediatamente al momento della ripresa della finalizzazione lascerebbe la rete in una condizione fragile, con uno stake attivo appena superiore alla soglia critica dei 2/3. Una partecipazione fluttuante potrebbe far oscillare la rete tra finalizzazione e non finalizzazione. Mantenere attivo il meccanismo di penalità anche dopo il recupero della finalità consente di rafforzare progressivamente lo stake attivo, portandolo sopra la soglia minima con un margine di sicurezza, e garantendo così maggiore stabilità al consenso della Beacon Chain. Inactivity Leak: Ejection Essere inattivi per un breve periodo durante un inactivity leak non comporta automaticamente l’espulsione di un validatore dal set attivo. Tuttavia, il protocollo prevede l’espulsione forzata (ejection) quando il bilancio effettivo (effective balance) del validatore scende al di sotto della soglia definita come EJECTION_BALANCE, attualmente pari a 16 ETH. A causa del meccanismo di aggiornamento del bilancio effettivo, l’espulsione si verifica di fatto quando il saldo reale del validatore scende sotto i 16,75 ETH. Secondo simulazioni condotte da ricercatori della community di Ethereum, un validatore che inizia il periodo di leak con un saldo pieno di 32 ETH, e rimane completamente inattivo, impiegherà circa 4686 epoche (circa 3 settimane) per raggiungere il livello di espulsione. È importante sottolineare che l’espulsione non avviene istantaneamente: il validatore viene infatti inserito in una exit queue (coda di uscita), e sarà rimosso dal set attivo solo quando raggiungerà la testa della coda. Durante questo intervallo, continua a essere considerato un validatore attivo, e quindi continua a subire penalità, il che può portare il suo bilancio a deteriorarsi ben oltre la soglia minima. La rapidità con cui il validatore viene effettivamente espulso dipende dalla lunghezza della coda. Questo significa che, in condizioni di congestione, il tempo di permanenza in coda può essere significativo, con conseguenze economiche rilevanti per il validatore coinvolto. Il grafico mostra in modo semplificato l’evoluzione del bilancio effettivo di un validatore inattivo durante un’inactivity leak. Si assume che il validatore inizi con un saldo effettivo di 32 ETH. Non appena inizia la fase di leak, il validatore, risultando inattivo, accumula progressivamente inactivity score, e ciò si traduce in una penalità crescente che erode il suo bilancio. All’aumentare dell’inactivity score, la velocità con cui il bilancio decresce diventa sempre più elevata. Una volta superata la soglia di EJECTION_BALANCE, il validatore entra formalmente nella coda di uscita. A questo punto, possono verificarsi due scenari: Breve lista di attesa: il validatore viene espulso rapidamente e smette di subire penalità aggiuntive. Lunga lista di attesa: il validatore continua a perdere bilancio effettivo, anche dopo la fine del leak, poiché resta nel set attivo fino al completamento della sua uscita. Nel secondo caso, quando il periodo di leak termina, l’inactivity score inizia a diminuire e la pendenza del declino del bilancio si riduce. Tuttavia, fintanto che il validatore non è ancora stato espulso, continua a essere penalizzato, anche se in misura minore fino a quanto l’inactivity score non diventa 0. Questo esempio ha lo scopo di chiarire come funziona l’inactivity leak nella fase critica in cui un validatore entra nella condizione di ejection, e quali possono essere le conseguenze economiche associate alla latenza del meccanismo di espulsione. Conclusione Il meccanismo di inactivity leak rappresenta una componente fondamentale nell’architettura della Beacon Chain di Ethereum. Esso si attiva in risposta a condizioni estreme di rete in cui la finalizzazione dei blocchi viene interrotta per un periodo prolungato, tipicamente a causa dell’inattività di oltre un terzo dei validatori. Attraverso una serie di penalità crescenti legate all’inactivity score dei singoli validatori, il protocollo riduce progressivamente lo stake dei partecipanti non attivi, fino a ristabilire la maggioranza qualificata (2/3 dello stake effettivamente online) necessaria per riprendere la finalizzazione. In questo senso, l’inactivity leak rappresenta una strategia di sopravvivenza automatica per la rete, capace di adattarsi a fallimenti importanti e prolungati. Il processo è lento ma ragionato: mira a evitare decisioni affrettate in contesti potenzialmente recuperabili, ma interviene con decisione se la situazione persiste. In tal modo, il protocollo prioritizza la liveness rispetto alla safety, accettando anche eventuali conseguenze ritenute drastiche, come la divisione permanente della rete in due partizioni indipendenti, se ciò rappresenta l’unica via per garantire la liveness in scenari irreversibili. Tuttavia, l’esito dell’inactivity leak non è predeterminato. Esistono due scenari principali di risoluzione: Ritorno alla normalità: se la causa della non finalizzazione è temporanea (es. problemi di rete, aggiornamenti mal riusciti o altro) e una porzione sufficiente di validatori torna online prima di subire penalità troppo gravi, allora l’inactivity leak permette una ripresa controllata della finalizzazione. In questo caso, la rete si stabilizza senza divisioni, pur con qualche perdita economica per i validatori inattivi. Divisione permanente della rete: se la causa dell’inattività è strutturale (es. una partizione geografica, un attacco deliberato o una divergenza ideologica tra validatori), l’inactivity leak può portare a un "fork" duraturo, dove due insiemi di validatori finalizzano su chain separate. In questo scenario, Ethereum accetta in un certo senso la perdita della safety in cambio della capacità di ogni partizione di continuare ad avanzare autonomamente. In ultima analisi, il meccanismo di inactivity leak non è solo una risposta all’inattività, ma un mezzo per garantire che Ethereum, anche nei momenti peggiori, possa trovare un modo per andare avanti. [/pms-restrict]