Attacco e difesa della Proof-of-Stake di Ethereum

Modifica pagina

Ladri e sabotatori sono costantemente alla ricerca di opportunità per attaccare il software client di Ethereum. Questa pagina delinea i vettori di attacco noti sul livello di consenso di Ethereum e illustra come ci si può difendere da tali attacchi. Le informazioni in questa pagina sono adattate da una versione più estesa (opens in a new tab).

Prerequisiti

È richiesta una conoscenza di base della Proof-of-Stake (PoS). Inoltre, sarà utile avere una comprensione di base del livello degli incentivi di Ethereum e dell'algoritmo di scelta del fork, LMD-GHOST.

Cosa vogliono gli attaccanti?

Un malinteso comune è che un utente malintenzionato di successo possa generare nuovi ether o prosciugare ether da account arbitrari. Nessuna di queste due cose è possibile perché tutte le transazioni vengono eseguite da tutti i client di esecuzione sulla rete. Devono soddisfare le condizioni di base di validità (ad es., le transazioni sono firmate dalla chiave privata del mittente, il mittente ha un saldo sufficiente, ecc.) altrimenti vanno semplicemente in revert. Ci sono tre classi di risultati a cui un utente malintenzionato potrebbe realisticamente puntare: riorganizzazioni, doppia definitività o ritardo della definitività.

Una "riorganizzazione" è un rimescolamento dei blocchi in un nuovo ordine, forse con qualche aggiunta o sottrazione di blocchi nella catena canonica. Una riorganizzazione malevola potrebbe garantire che blocchi specifici vengano inclusi o esclusi, consentendo la doppia spesa o l'estrazione di valore tramite transazioni di front-running e back-running (MEV). Le riorganizzazioni potrebbero anche essere utilizzate per impedire che determinate transazioni vengano incluse nella catena canonica: una forma di censura. La forma più estrema di riorganizzazione è la "reversione della definitività" che rimuove o sostituisce i blocchi che sono stati precedentemente finalizzati. Questo è possibile solo se più di ⅓ degli ether totali in staking viene distrutto dall'attaccante (questa garanzia è nota come "definitività economica"); ne parleremo più avanti.

La doppia definitività è la condizione improbabile ma grave in cui due fork sono in grado di essere finalizzati simultaneamente, creando uno scisma permanente nella catena. Questo è teoricamente possibile per un utente malintenzionato disposto a rischiare il 34% degli ether totali in staking. La community sarebbe costretta a coordinarsi offchain e a raggiungere un accordo su quale catena seguire, il che richiederebbe forza nel livello sociale.

Un attacco di ritardo della definitività impedisce alla rete di raggiungere le condizioni necessarie per finalizzare sezioni della catena. Senza definitività, è difficile fidarsi delle applicazioni finanziarie costruite su Ethereum. Lo scopo di un attacco di ritardo della definitività è probabilmente solo quello di interrompere Ethereum piuttosto che trarne profitto diretto, a meno che l'attaccante non abbia delle posizioni corte strategiche.

Un attacco al livello sociale potrebbe mirare a minare la fiducia del pubblico in Ethereum, svalutare l'ether, ridurre l'adozione o indebolire la community di Ethereum per rendere più difficile il coordinamento fuori banda.

Avendo stabilito perché un avversario potrebbe attaccare Ethereum, le sezioni seguenti esaminano come potrebbe farlo.

Metodi di attacco

Attacchi di Layer 0

Prima di tutto, gli individui che non partecipano attivamente a Ethereum (eseguendo il software client) possono attaccare prendendo di mira il livello sociale (Layer 0). Il Layer 0 è la base su cui è costruito Ethereum e, in quanto tale, rappresenta una potenziale superficie per attacchi con conseguenze che si ripercuotono sul resto dello stack. Alcuni esempi potrebbero includere:

Una campagna di disinformazione potrebbe erodere la fiducia che la community ha nella roadmap di Ethereum, nei team di sviluppatori, nelle app, ecc. Questo potrebbe quindi diminuire il numero di individui disposti a partecipare alla messa in sicurezza della rete, degradando sia la decentralizzazione che la sicurezza cripto-economica.
Attacchi mirati e/o intimidazioni dirette alla community degli sviluppatori. Questo potrebbe portare all'uscita volontaria degli sviluppatori e rallentare i progressi di Ethereum.
Anche una regolamentazione eccessivamente zelante potrebbe essere considerata un attacco al Layer 0, poiché potrebbe disincentivare rapidamente la partecipazione e l'adozione.
Infiltrazione di attori esperti ma malintenzionati nella community degli sviluppatori il cui scopo è rallentare i progressi perdendosi in discussioni futili (bike-shedding), ritardando decisioni chiave, creando spam, ecc.
Tangenti offerte a figure chiave nell'ecosistema di Ethereum per influenzare il processo decisionale.

Ciò che rende questi attacchi particolarmente pericolosi è che in molti casi è richiesto pochissimo capitale o know-how tecnico. Un attacco di Layer 0 potrebbe essere un moltiplicatore di un attacco cripto-economico. Ad esempio, se la censura o la reversione della definitività venissero ottenute da un azionista di maggioranza malintenzionato, minare il livello sociale potrebbe rendere più difficile coordinare una risposta della community fuori banda.

Difendersi dagli attacchi di Layer 0 probabilmente non è semplice, ma si possono stabilire alcuni principi di base. Uno è mantenere un rapporto segnale/rumore complessivamente elevato per le informazioni pubbliche su Ethereum, create e propagate da membri onesti della community attraverso blog, server Discord, specifiche annotate, libri, podcast e YouTube. Qui su ethereum.org ci impegniamo a fondo per mantenere informazioni accurate e tradurle nel maggior numero di lingue possibile. Inondare uno spazio con informazioni e meme di alta qualità è una difesa efficace contro la disinformazione.

Un'altra importante fortificazione contro gli attacchi al livello sociale è una chiara dichiarazione di intenti e un protocollo di governance. Ethereum si è posizionato come il campione della decentralizzazione e della sicurezza tra i layer 1 (l1) per contratti intelligenti, pur valutando molto la scalabilità e la sostenibilità. Qualunque disaccordo sorga nella community di Ethereum, questi principi fondamentali sono minimamente compromessi. Valutare una narrativa rispetto a questi principi fondamentali ed esaminarli attraverso successivi cicli di revisione nel processo EIP (Ethereum Improvement Proposal), potrebbe aiutare la community a distinguere gli attori buoni da quelli cattivi e limita il margine di manovra per gli attori malintenzionati di influenzare la direzione futura di Ethereum.

Infine, è fondamentale che la community di Ethereum rimanga aperta e accogliente per tutti i partecipanti. Una community con guardiani (gatekeeper) ed esclusività è particolarmente vulnerabile agli attacchi sociali perché è facile costruire narrative del tipo "noi contro loro". Il tribalismo e il massimalismo tossico danneggiano la community ed erodono la sicurezza del Layer 0. Gli Etherean con un interesse acquisito nella sicurezza della rete dovrebbero considerare la loro condotta online e nel mondo reale (meatspace) come un contributo diretto alla sicurezza del Layer 0 di Ethereum.

Attaccare il protocollo

Chiunque può eseguire il software client di Ethereum. Per aggiungere un validatore a un client, a un utente è richiesto di mettere in staking 32 ether nel contratto di deposito. Un validatore consente a un utente di partecipare attivamente alla sicurezza della rete di Ethereum proponendo e attestando nuovi blocchi. Il validatore ora ha una voce che può usare per influenzare i contenuti futuri della blockchain: può farlo onestamente e far crescere la sua scorta di ether tramite le ricompense, oppure può cercare di manipolare il processo a proprio vantaggio, rischiando il proprio stake. Un modo per sferrare un attacco è accumulare una percentuale maggiore dello stake totale e poi usarla per superare i voti dei validatori onesti. Maggiore è la percentuale dello stake controllata dall'attaccante, maggiore è il suo potere di voto, specialmente in corrispondenza di determinati traguardi economici che esploreremo in seguito. Tuttavia, la maggior parte degli attaccanti non sarà in grado di accumulare ether sufficienti per attaccare in questo modo, quindi dovranno invece usare tecniche sottili per manipolare la maggioranza onesta affinché agisca in un certo modo.

Fondamentalmente, tutti gli attacchi con stake ridotto sono sottili variazioni di due tipi di comportamento scorretto del validatore: sotto-attività (mancata attestazione/proposta o farlo in ritardo) o sovra-attività (proporre/attestare troppe volte in uno slot). Nelle loro forme più basilari, queste azioni sono facilmente gestite dall'algoritmo di scelta del fork e dal livello degli incentivi, ma ci sono modi intelligenti per aggirare il sistema a vantaggio di un attaccante.

Attacchi che utilizzano piccole quantità di ETH

riorganizzazioni

Diversi documenti hanno spiegato attacchi a Ethereum che ottengono riorganizzazioni o ritardi della definitività con solo una piccola percentuale degli ether totali in staking. Questi attacchi si basano generalmente sul fatto che l'attaccante nasconda alcune informazioni agli altri validatori per poi rilasciarle in modo sfumato e/o in un momento opportuno. Di solito mirano a rimuovere alcuni blocchi onesti dalla catena canonica. Neuder et al 2020 (opens in a new tab) hanno mostrato come un validatore attaccante possa creare e attestare un blocco (B) per un particolare slot n+1 ma astenersi dal propagarlo ad altri nodi sulla rete. Invece, trattengono quel blocco attestato fino allo slot successivo n+2. Un validatore onesto propone un blocco (C) per lo slot n+2. Quasi simultaneamente, l'attaccante può rilasciare il blocco trattenuto (B) e le relative attestazioni trattenute, e anche attestare che B è la testa della catena con i propri voti per lo slot n+2, negando di fatto l'esistenza del blocco onesto C. Quando viene rilasciato il blocco onesto D, l'algoritmo di scelta del fork vede che D costruito sopra B è più pesante di D costruito su C. L'attaccante è quindi riuscito a rimuovere il blocco onesto C nello slot n+2 dalla catena canonica utilizzando una riorganizzazione ex ante di 1 blocco. Un attaccante con il 34% (opens in a new tab) dello stake ha ottime probabilità di riuscire in questo attacco, come spiegato in questa nota (opens in a new tab). In teoria, però, questo attacco potrebbe essere tentato con stake inferiori. Neuder et al 2020 (opens in a new tab) hanno descritto questo attacco funzionante con uno stake del 30%, ma in seguito è stato dimostrato che è fattibile con il 2% dello stake totale (opens in a new tab) e poi di nuovo per un singolo validatore (opens in a new tab) utilizzando tecniche di bilanciamento che esamineremo nella prossima sezione.

Un diagramma concettuale dell'attacco di riorganizzazione di un blocco descritto sopra (adattato da https://notes.ethereum.org/plgVdz-ORe-fGjK06BZ_3A#Fork-choice-by-block-slot-pair (opens in a new tab))

Un attacco più sofisticato può dividere l'insieme dei validatori onesti in gruppi discreti che hanno visioni diverse della testa della catena. Questo è noto come attacco di bilanciamento. L'attaccante aspetta la sua occasione per proporre un blocco e, quando arriva, commette un'equivocazione e ne propone due. Invia un blocco a metà dell'insieme dei validatori onesti e l'altro blocco all'altra metà. L'equivocazione verrebbe rilevata dall'algoritmo di scelta del fork e il proponente del blocco subirebbe lo slashing e verrebbe espulso dalla rete, ma i due blocchi esisterebbero ancora e avrebbero circa metà dell'insieme dei validatori che attesta ciascun fork. Nel frattempo, i restanti validatori malintenzionati trattengono le loro attestazioni. Quindi, rilasciando selettivamente le attestazioni a favore dell'uno o dell'altro fork a un numero appena sufficiente di validatori proprio mentre viene eseguito l'algoritmo di scelta del fork, fanno pendere il peso accumulato delle attestazioni a favore dell'uno o dell'altro fork. Questo può continuare indefinitamente, con i validatori attaccanti che mantengono una divisione uniforme dei validatori tra i due fork. Poiché nessuno dei due fork può attrarre una supermaggioranza di 2/3, la rete non verrebbe finalizzata.

Gli attacchi di rimbalzo (bouncing attack) sono simili. I voti vengono nuovamente trattenuti dai validatori attaccanti. Invece di rilasciare i voti per mantenere una divisione uniforme tra due fork, usano i loro voti nei momenti opportuni per giustificare i checkpoint che si alternano tra il fork A e il fork B. Questo continuo capovolgimento della giustificazione tra due fork impedisce che ci siano coppie di checkpoint di origine e di destinazione giustificati che possono essere finalizzati su entrambe le catene, bloccando la definitività.

The game of reorgs in proof of stake Ethereum

Caspar Schwarz-Schilling presents research on block reorganization attacks in proof of stake Ethereum, covering attack vectors, defense mechanisms, and the protocol-level mitigations in place.

Guarda con trascrizione

Sia gli attacchi di rimbalzo che quelli di bilanciamento si basano sul fatto che l'attaccante abbia un controllo molto preciso sulla tempistica dei messaggi attraverso la rete, il che è improbabile. Tuttavia, le difese sono integrate nel protocollo sotto forma di peso aggiuntivo dato ai messaggi tempestivi rispetto a quelli lenti. Questo è noto come potenziamento del peso del proponente (proposer-weight boosting) (opens in a new tab). Per difendersi dagli attacchi di rimbalzo, l'algoritmo di scelta del fork è stato aggiornato in modo che l'ultimo checkpoint giustificato possa passare a quello di una catena alternativa solo durante il primo 1/3 degli slot in ogni epoca (opens in a new tab). Questa condizione impedisce all'attaccante di risparmiare voti per distribuirli in seguito: l'algoritmo di scelta del fork rimane semplicemente fedele al checkpoint che ha scelto nel primo 1/3 dell'epoca, durante il quale la maggior parte dei validatori onesti avrebbe votato.

Insieme, queste misure creano uno scenario in cui un proponente del blocco onesto emette il proprio blocco molto rapidamente dopo l'inizio dello slot, quindi c'è un periodo di ~1/3 di slot (4 secondi) in cui quel nuovo blocco potrebbe far passare l'algoritmo di scelta del fork a un'altra catena. Dopo la stessa scadenza, le attestazioni che arrivano da validatori lenti vengono declassate rispetto a quelle arrivate prima. Questo favorisce fortemente i proponenti e i validatori tempestivi nel determinare la testa della catena e riduce sostanzialmente la probabilità di un attacco di bilanciamento o di rimbalzo riuscito.

Vale la pena notare che il potenziamento del proponente da solo difende solo dalle "riorganizzazioni economiche", ovvero quelle tentate da un attaccante con uno stake ridotto. In effetti, il potenziamento del proponente stesso può essere aggirato dagli stakeholder più grandi. Gli autori di questo post (opens in a new tab) descrivono come un attaccante con il 7% dello stake possa distribuire i propri voti in modo strategico per indurre i validatori onesti a costruire sul proprio fork, riorganizzando un blocco onesto. Questo attacco è stato ideato ipotizzando condizioni di latenza ideali che sono molto improbabili. Le probabilità sono ancora molto basse per l'attaccante e lo stake maggiore significa anche più capitale a rischio e un disincentivo economico più forte.

È stato proposto anche un attacco di bilanciamento mirato specificamente alla regola LMD (opens in a new tab), che è stato suggerito essere fattibile nonostante il potenziamento del proponente. Un attaccante imposta due catene in competizione equivocando la propria proposta di blocco e propagando ciascun blocco a circa metà della rete ciascuno, stabilendo un equilibrio approssimativo tra i fork. Quindi, i validatori collusi equivocano i loro voti, calcolando i tempi in modo che metà della rete riceva prima i loro voti per il Fork A e l'altra metà riceva prima i loro voti per il Fork B. Poiché la regola LMD scarta la seconda attestazione e mantiene solo la prima per ogni validatore, metà della rete vede i voti per A e nessuno per B, l'altra metà vede i voti per B e nessuno per A. Gli autori descrivono la regola LMD come un elemento che conferisce all'avversario un "potere notevole" per sferrare un attacco di bilanciamento.

Questo vettore di attacco LMD è stato chiuso aggiornando l'algoritmo di scelta del fork (opens in a new tab) in modo che scarti del tutto i validatori che equivocano dalla considerazione della scelta del fork. I validatori che equivocano vedono anche la loro influenza futura scontata dall'algoritmo di scelta del fork. Questo previene l'attacco di bilanciamento descritto sopra, mantenendo al contempo la resilienza contro gli attacchi a valanga.

Un'altra classe di attacchi, chiamata attacchi a valanga (avalanche attack) (opens in a new tab), è stata descritta in un documento del marzo 2022 (opens in a new tab). Per sferrare un attacco a valanga, l'attaccante deve controllare diversi proponenti del blocco consecutivi. In ciascuno degli slot di proposta del blocco, l'attaccante trattiene il proprio blocco, raccogliendoli fino a quando la catena onesta non raggiunge un peso del sottoalbero uguale a quello dei blocchi trattenuti. Quindi, i blocchi trattenuti vengono rilasciati in modo che equivochino al massimo. Gli autori suggeriscono che il potenziamento del proponente, la difesa principale contro gli attacchi di bilanciamento e di rimbalzo, non protegge da alcune varianti di attacco a valanga. Tuttavia, gli autori hanno anche dimostrato l'attacco solo su una versione altamente idealizzata dell'algoritmo di scelta del fork di Ethereum (hanno usato GHOST senza LMD).

L'attacco a valanga è mitigato dalla porzione LMD dell'algoritmo di scelta del fork LMD-GHOST. LMD significa "guidato dall'ultimo messaggio" (latest-message-driven) e si riferisce a una tabella tenuta da ogni validatore contenente l'ultimo messaggio ricevuto dagli altri validatori. Quel campo viene aggiornato solo se il nuovo messaggio proviene da uno slot successivo rispetto a quello già presente nella tabella per un particolare validatore. In pratica, questo significa che in ogni slot, il primo messaggio ricevuto è quello che viene accettato e qualsiasi messaggio aggiuntivo è un'equivocazione da ignorare. In altre parole, i client di consenso non contano le equivocazioni: usano il primo messaggio in arrivo da ogni validatore e le equivocazioni vengono semplicemente scartate, prevenendo gli attacchi a valanga.

Ci sono molti altri potenziali aggiornamenti futuri alla regola di scelta del fork che potrebbero aumentare la sicurezza fornita dal potenziamento del proponente. Uno è la fusione delle viste (view-merge) (opens in a new tab), in cui gli attestatori congelano la loro vista della scelta del fork n secondi prima dell'inizio di uno slot e il proponente aiuta quindi a sincronizzare la vista della catena attraverso la rete. Un altro potenziale aggiornamento è la definitività a slot singolo (single-slot finality) (opens in a new tab), che protegge dagli attacchi basati sulla tempistica dei messaggi finalizzando la catena dopo un solo slot.

Ritardo della definitività

Lo stesso documento (opens in a new tab) che ha descritto per primo l'attacco di riorganizzazione di un singolo blocco a basso costo ha anche descritto un attacco di ritardo della definitività (noto anche come "fallimento della liveness") che si basa sul fatto che l'attaccante sia il proponente del blocco per un blocco di confine dell'epoca. Questo è fondamentale perché questi blocchi di confine dell'epoca diventano i checkpoint che Casper FFG usa per finalizzare porzioni della catena. L'attaccante trattiene semplicemente il proprio blocco fino a quando un numero sufficiente di validatori onesti non usa i propri voti FFG a favore del precedente blocco di confine dell'epoca come attuale obiettivo di finalizzazione. Quindi rilascia il blocco trattenuto. Attesta il proprio blocco e lo fanno anche i restanti validatori onesti, creando fork con diversi checkpoint di destinazione. Se ha calcolato bene i tempi, impedirà la definitività perché non ci sarà una supermaggioranza di 2/3 che attesta nessuno dei due fork. Minore è lo stake, più precisa deve essere la tempistica perché l'attaccante controlla direttamente meno attestazioni e minori sono le probabilità che l'attaccante controlli il validatore che propone un determinato blocco di confine dell'epoca.

Attacchi a lungo raggio

Esiste anche una classe di attacchi specifica per le blockchain Proof-of-Stake (PoS) che coinvolge un validatore che ha partecipato al blocco genesi mantenendo un fork separato della blockchain insieme a quello onesto, convincendo infine l'insieme dei validatori onesti a passare ad esso in un momento opportuno molto più tardi. Questo tipo di attacco non è possibile su Ethereum a causa del meccanismo di definitività che garantisce che tutti i validatori concordino sullo stato della catena onesta a intervalli regolari ("checkpoint"). Questo semplice meccanismo neutralizza gli attaccanti a lungo raggio perché i client di Ethereum semplicemente non riorganizzeranno i blocchi finalizzati. I nuovi nodi che si uniscono alla rete lo fanno trovando un hash di stato recente e affidabile (un checkpoint di "soggettività debole (opens in a new tab)") e usandolo come pseudo-blocco genesi su cui costruire. Questo crea un "gateway di fiducia" per un nuovo nodo che entra nella rete prima che possa iniziare a verificare le informazioni da solo.

Denial of Service (Negazione del servizio)

Il meccanismo PoS di Ethereum sceglie un singolo validatore dall'insieme totale dei validatori per essere un proponente del blocco in ogni slot. Questo può essere calcolato utilizzando una funzione nota pubblicamente ed è possibile per un avversario identificare il successivo proponente del blocco con un leggero anticipo rispetto alla sua proposta di blocco. Quindi, l'attaccante può inviare spam al proponente del blocco per impedirgli di scambiare informazioni con i suoi pari. Al resto della rete, sembrerebbe che il proponente del blocco fosse offline e lo slot rimarrebbe semplicemente vuoto. Questa potrebbe essere una forma di censura contro validatori specifici, impedendo loro di aggiungere informazioni alla blockchain. L'implementazione di elezioni segrete del leader singolo (SSLE) o di elezioni segrete del leader non singolo mitigherà i rischi di DoS perché solo il proponente del blocco sa di essere stato selezionato e la selezione non è conoscibile in anticipo. Questo non è ancora implementato, ma è un'area attiva di ricerca e sviluppo (opens in a new tab).

Tutto ciò indica il fatto che è molto difficile attaccare con successo Ethereum con uno stake ridotto. Gli attacchi fattibili che sono stati descritti qui richiedono un algoritmo di scelta del fork idealizzato, condizioni di rete improbabili, oppure i vettori di attacco sono già stati chiusi con patch relativamente minori al software client. Questo, ovviamente, non esclude la possibilità che esistano zero-day in circolazione (in the wild), ma dimostra l'asticella estremamente alta di attitudine tecnica, conoscenza del livello di consenso e fortuna richiesta affinché un attaccante con uno stake di minoranza sia efficace. Dal punto di vista di un attaccante, la scommessa migliore potrebbe essere quella di accumulare quanti più ether possibile e tornare armato di una percentuale maggiore dello stake totale.

Attaccanti che utilizzano >= 33% dello stake totale

Tutti gli attacchi menzionati in precedenza in questo articolo hanno maggiori probabilità di successo quando l'attaccante ha più ether in staking con cui votare e più validatori che potrebbero essere scelti per proporre blocchi in ogni slot. Un validatore malintenzionato potrebbe quindi mirare a controllare quanti più ether in staking possibile.

Il 33% degli ether in staking è un punto di riferimento per un attaccante perché con qualsiasi importo superiore a questo ha la capacità di impedire la finalizzazione della catena senza dover controllare finemente le azioni degli altri validatori. Possono semplicemente scomparire tutti insieme. Se 1/3 o più degli ether in staking attesta in modo malevolo o non attesta, allora non può esistere una supermaggioranza di 2/3 e la catena non può essere finalizzata. La difesa contro questo è la perdita per inattività. La perdita per inattività identifica quei validatori che non attestano o attestano contrariamente alla maggioranza. Gli ether in staking di proprietà di questi validatori non attestanti vengono gradualmente prosciugati fino a quando non rappresentano collettivamente meno di 1/3 del totale, in modo che la catena possa essere nuovamente finalizzata.

Lo scopo della perdita per inattività è far sì che la catena venga nuovamente finalizzata. Tuttavia, l'attaccante perde anche una parte dei propri ether in staking. L'inattività persistente tra i validatori che rappresentano il 33% degli ether totali in staking è molto costosa, anche se i validatori non subiscono lo slashing.

Supponendo che la rete Ethereum sia asincrona (ovvero, ci sono ritardi tra l'invio e la ricezione dei messaggi), un attaccante che controlla il 34% dello stake totale potrebbe causare una doppia definitività. Questo perché l'attaccante può equivocare quando viene scelto per essere un produttore di blocchi, quindi votare due volte con tutti i suoi validatori. Questo crea una situazione in cui esiste un fork della blockchain, ciascuno con il 34% degli ether in staking che vota per esso. Ogni fork richiede solo che il 50% dei restanti validatori voti a suo favore affinché entrambi i fork siano supportati da una supermaggioranza, nel qual caso entrambe le catene possono essere finalizzate (perché il 34% dei validatori attaccanti + metà del restante 66% = 67% su ogni fork). I blocchi in competizione dovrebbero essere ricevuti ciascuno da circa il 50% dei validatori onesti, quindi questo attacco è fattibile solo quando l'attaccante ha un certo grado di controllo sulla tempistica dei messaggi che si propagano sulla rete, in modo da poter spingere metà dei validatori onesti su ciascuna catena. L'attaccante distruggerebbe necessariamente il suo intero stake (il 34% di ~10 milioni di ether con l'attuale insieme di validatori) per ottenere questa doppia definitività perché il 34% dei suoi validatori voterebbe due volte simultaneamente: un'offesa passibile di slashing con la massima penalità di correlazione. La difesa contro questo attacco è il costo molto elevato della distruzione del 34% degli ether totali in staking. Il recupero da questo attacco richiederebbe alla community di Ethereum di coordinarsi "fuori banda" e concordare di seguire l'uno o l'altro dei fork e ignorare l'altro.

Attaccanti che utilizzano ~50% dello stake totale

Al 50% degli ether in staking, un gruppo malintenzionato di validatori potrebbe teoricamente dividere la catena in due fork di uguali dimensioni e quindi utilizzare semplicemente il proprio intero stake del 50% per votare contrariamente all'insieme dei validatori onesti, mantenendo così i due fork e impedendo la definitività. La perdita per inattività su entrambi i fork porterebbe alla fine alla finalizzazione di entrambe le catene. A questo punto, l'unica opzione è ripiegare su un recupero sociale.

È molto improbabile che un gruppo avversario di validatori possa controllare costantemente e con precisione il 50% dello stake totale, dato un certo grado di fluttuazione nel numero di validatori onesti, nella latenza di rete, ecc. L'enorme costo per sferrare un simile attacco, combinato con la bassa probabilità di successo, sembra essere un forte disincentivo per un attaccante razionale, specialmente quando un piccolo investimento aggiuntivo per ottenere più del 50% sblocca molto più potere.

A >50% dello stake totale, l'attaccante potrebbe dominare l'algoritmo di scelta del fork. In questo caso, l'attaccante sarebbe in grado di attestare con il voto di maggioranza, ottenendo un controllo sufficiente per effettuare brevi riorganizzazioni senza dover ingannare i client onesti. I validatori onesti seguirebbero l'esempio perché anche il loro algoritmo di scelta del fork vedrebbe la catena favorita dall'attaccante come la più pesante, quindi la catena potrebbe essere finalizzata. Questo consente all'attaccante di censurare determinate transazioni, eseguire riorganizzazioni a corto raggio ed estrarre il massimo MEV riordinando i blocchi a proprio favore. La difesa contro questo è l'enorme costo di uno stake di maggioranza (attualmente poco meno di 19 miliardi di dollari USA) che viene messo a rischio da un attaccante perché è probabile che il livello sociale intervenga e adotti un fork di minoranza onesto, svalutando drasticamente lo stake dell'attaccante.

Attaccanti che utilizzano >=66% dello stake totale

Un attaccante con il 66% o più degli ether totali in staking può finalizzare la propria catena preferita senza dover costringere alcun validatore onesto. L'attaccante può semplicemente votare per il proprio fork preferito e poi finalizzarlo, semplicemente perché può votare con una supermaggioranza disonesta. In qualità di stakeholder di supermaggioranza, l'attaccante controllerebbe sempre i contenuti dei blocchi finalizzati, con il potere di spendere, riavvolgere e spendere di nuovo, censurare determinate transazioni e riorganizzare la catena a piacimento. Acquistando ether aggiuntivi per controllare il 66% anziché il 51%, l'attaccante sta effettivamente acquistando la capacità di eseguire riorganizzazioni ex post e reversioni della definitività (ovvero, cambiare il passato oltre a controllare il futuro). Le uniche vere difese qui sono l'enorme costo del 66% degli ether totali in staking e l'opzione di ripiegare sul livello sociale per coordinare l'adozione di un fork alternativo. Possiamo esplorare questo aspetto in modo più dettagliato nella prossima sezione.

Le persone: l'ultima linea di difesa

Se i validatori disonesti riescono a finalizzare la loro versione preferita della catena, la community di Ethereum viene messa in una situazione difficile. La catena canonica include una sezione disonesta integrata nella sua storia, mentre i validatori onesti possono finire per essere puniti per aver attestato una catena alternativa (onesta). Si noti che una catena finalizzata ma errata potrebbe anche derivare da un bug in un client di maggioranza. Alla fine, il ripiego finale è fare affidamento sul livello sociale (Layer 0) per risolvere la situazione.

Uno dei punti di forza del consenso PoS di Ethereum è che c'è una serie di strategie difensive (opens in a new tab) che la community può impiegare di fronte a un attacco. Una risposta minima potrebbe essere quella di forzare l'uscita dei validatori degli attaccanti dalla rete senza alcuna penalità aggiuntiva. Per rientrare nella rete, l'attaccante dovrebbe unirsi a una coda di attivazione che garantisce che l'insieme dei validatori cresca gradualmente. Ad esempio, l'aggiunta di un numero sufficiente di validatori per raddoppiare la quantità di ether in staking richiede circa 200 giorni, facendo guadagnare di fatto ai validatori onesti 200 giorni prima che l'attaccante possa tentare un altro attacco del 51%. Tuttavia, la community potrebbe anche decidere di penalizzare l'attaccante più duramente, revocando le ricompense passate o bruciando una parte (fino al 100%) del suo capitale in staking.

Qualunque sia la penalità imposta all'attaccante, la community deve anche decidere insieme se la catena disonesta, pur essendo quella favorita dall'algoritmo di scelta del fork codificato nei client di Ethereum, sia di fatto non valida e che la community debba invece costruire sulla catena onesta. I validatori onesti potrebbero concordare collettivamente di costruire su un fork della blockchain di Ethereum accettato dalla community che potrebbe, ad esempio, essersi separato dalla catena canonica prima dell'inizio dell'attacco o aver rimosso forzatamente i validatori degli attaccanti. I validatori onesti sarebbero incentivati a costruire su questa catena perché eviterebbero le penalità applicate loro per non aver (giustamente) attestato la catena dell'attaccante. Gli exchange, i servizi di on-ramp e le applicazioni costruite su Ethereum preferirebbero presumibilmente trovarsi sulla catena onesta e seguirebbero i validatori onesti verso la blockchain onesta.

Tuttavia, questa sarebbe una sfida di governance sostanziale. Alcuni utenti e validatori ci rimetterebbero senza dubbio a causa del ritorno alla catena onesta, le transazioni nei blocchi validati dopo l'attacco potrebbero potenzialmente essere annullate, interrompendo il livello dell'applicazione, e questo mina semplicemente l'etica di alcuni utenti che tendono a credere che "il codice è legge" (code is law). Gli exchange e le applicazioni avranno molto probabilmente collegato azioni offchain a transazioni onchain che ora potrebbero essere annullate, innescando una cascata di ritrattazioni e revisioni che sarebbe difficile districare in modo equo, specialmente se i guadagni illeciti sono stati mescolati, depositati nella finanza decentralizzata (DeFi) o in altri derivati con effetti secondari per gli utenti onesti. Indubbiamente alcuni utenti, forse anche istituzionali, avrebbero già beneficiato della catena disonesta per scaltrezza o per caso, e potrebbero opporsi a un fork per proteggere i propri guadagni. Ci sono state richieste di provare la risposta della community agli attacchi >51% in modo che una mitigazione coordinata e sensata possa essere eseguita rapidamente. C'è un'utile discussione di Vitalik su ethresear.ch qui (opens in a new tab) e qui (opens in a new tab) e su Twitter qui (opens in a new tab). Lo scopo di una risposta sociale coordinata dovrebbe essere quello di essere molto mirata e specifica nel punire l'attaccante e ridurre al minimo gli effetti per gli altri utenti.

La governance è già un argomento complicato. Gestire una risposta di emergenza di Layer 0 a una catena di finalizzazione disonesta sarebbe senza dubbio impegnativo per la community di Ethereum, ma è successo (due volte nella storia di Ethereum).

Tuttavia, c'è qualcosa di abbastanza soddisfacente nel fatto che il ripiego finale risieda nel mondo reale (meatspace). In definitiva, anche con questo fenomenale stack di tecnologia sopra di noi, se dovesse mai accadere il peggio, persone reali dovrebbero coordinarsi per uscirne.

Riepilogo

Questa pagina ha esplorato alcuni dei modi in cui gli attaccanti potrebbero tentare di sfruttare il protocollo di consenso Proof-of-Stake (PoS) di Ethereum. Le riorganizzazioni e i ritardi della definitività sono stati esplorati per gli attaccanti con proporzioni crescenti degli ether totali in staking. Nel complesso, un attaccante più ricco ha maggiori probabilità di successo perché il suo stake si traduce in potere di voto che può usare per influenzare i contenuti dei blocchi futuri. A determinate soglie di ether in staking, il potere dell'attaccante sale di livello:

33%: ritardo della definitività

34%: ritardo della definitività, doppia definitività

51%: ritardo della definitività, doppia definitività, censura, controllo sul futuro della blockchain

66%: ritardo della definitività, doppia definitività, censura, controllo sul futuro e sul passato della blockchain

Esiste anche una serie di attacchi più sofisticati che richiedono piccole quantità di ether in staking ma si basano su un attaccante molto sofisticato che ha un controllo preciso sulla tempistica dei messaggi per influenzare l'insieme dei validatori onesti a proprio favore.

Nel complesso, nonostante questi potenziali vettori di attacco, il rischio di un attacco riuscito è basso, certamente inferiore agli equivalenti della Prova di lavoro (PoW). Questo a causa dell'enorme costo degli ether in staking messi a rischio da un attaccante che mira a sopraffare i validatori onesti con il proprio potere di voto. Il livello degli incentivi integrato "bastone e carota" protegge dalla maggior parte dei comportamenti illeciti, specialmente per gli attaccanti con stake ridotto. È anche improbabile che attacchi di rimbalzo e di bilanciamento più sottili abbiano successo perché le condizioni reali della rete rendono molto difficile ottenere il controllo preciso della consegna dei messaggi a sottoinsiemi specifici di validatori, e i team dei client hanno rapidamente chiuso i vettori di attacco noti di rimbalzo, bilanciamento e a valanga con semplici patch.

Gli attacchi del 34%, 51% o 66% richiederebbero probabilmente un coordinamento sociale fuori banda per essere risolti. Sebben questo sarebbe probabilmente doloroso per la community, la capacità di una community di rispondere fuori banda è un forte disincentivo per un attaccante. Il livello sociale di Ethereum è l'ultimo baluardo: un attacco tecnicamente riuscito potrebbe ancora essere neutralizzato dalla community che accetta di adottare un fork onesto. Ci sarebbe una corsa tra l'attaccante e la community di Ethereum: i miliardi di dollari spesi per un attacco del 66% verrebbero probabilmente annientati da un attacco di coordinamento sociale riuscito se venisse sferrato abbastanza rapidamente, lasciando l'attaccante con pesanti borse di ether in staking illiquidi su una catena disonesta nota ignorata dalla community di Ethereum. La probabilità che questo finisca per essere redditizio per l'attaccante è sufficientemente bassa da costituire un deterrente efficace. Ecco perché l'investimento nel mantenimento di un livello sociale coeso con valori strettamente allineati è così importante.

Letture consigliate

Ultimo aggiornamento della pagina: 13 aprile 2026

Torna all'inizio ↑