Sigma Prime, blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">il team che sviluppa Lighthouse, ha pubblicato Lighthouse v8.3.3, datata 9 novembre sulla pagina della release su GitHub, e ha chiesto a chiunque gestisca un beacon node Lighthouse di aggiornarlo «il prima possibile». Le note di rilascio la definiscono una patch ad alta priorità che contiene correzioni di sicurezza. Non dicono però quali siano le vulnerabilità: i dettagli «saranno resi noti in un secondo momento», quando gli operatori dei nodi avranno avuto il tempo di installare la nuova versione.
La questione va oltre un singolo team di sviluppo. Secondo almeno una delle rilevazioni, Lighthouse è il client di consenso più usato di Ethereum: Miga Labs lo colloca al 46,96%, nei dati mostrati su clientdiversity.org quando Coindaro li ha consultati l’11 novembre. Un altro tracker sulla stessa pagina, Rated.Network, indica il 20,6%. Un bug grave in un client di queste dimensioni riguarda l’intera rete.
Né le note di rilascio né l’articolo di CryptoSlate dell’11 novembre parlano di sfruttamenti delle falle o di fondi persi. CryptoSlate ha anche sottolineato che il funzionamento e il possibile impatto delle vulnerabilità non sono stati resi pubblici.
Cosa dice l’aggiornamento di sicurezza Lighthouse v8.3.3, e cosa non dice
La release, soprannominata «Sleepy Gary» e firmata con la chiave PGP di Sigma Prime, contiene una tabella delle priorità di aggiornamento. Divide il software nelle sue due parti: il beacon node, che segue la catena e dialoga con gli altri nodi, e il validator client, che custodisce le chiavi di firma ed esprime i voti.
| Componente | Chi fa staking | Chi non fa staking |
|---|---|---|
| Beacon node | Alta | Alta |
| Validator client | Bassa | Non indicata |
La parte urgente è quindi il beacon node, per tutti quelli che ne gestiscono uno, che facciano staking o no. Il validator client può aspettare un normale ciclo di aggiornamento. Nella scala di priorità di Lighthouse, così come la riassume CryptoSlate, «alta» significa intervenire entro ore o giorni, mentre «bassa» rientra nel prossimo aggiornamento di routine, con due settimane citate come esempio.
Le note non segnalano modifiche incompatibili. A chi è ancora su v8.2.x o versioni precedenti viene chiesto di leggere prima le note di rilascio della v8.3.0, perché quella versione ha introdotto cambiamenti propri.
L’elenco pubblico delle modifiche è breve: un aggiornamento di libp2p, un passaggio a una nuova versione di crypto-bigint, modifiche al modo in cui vengono conteggiate e recuperate le richieste di rete in entrata e i substream scaduti, la correzione di un metodo is_infinity e qualche correzione di compilazione. La release non dice quali di queste voci, ammesso che ce ne siano, siano le correzioni di sicurezza. Leggere l’elenco come una mappa dei bug sarebbe pura congettura.
Cosa non si sa, all’11 novembre: quali versioni siano vulnerabili, quanto siano gravi le falle e chi le abbia segnalate. Lighthouse non ha nemmeno indicato una data per gli avvisi di sicurezza.
Perché Sigma Prime per ora tiene segrete le vulnerabilità
Non rivelare i dettagli è la politica dichiarata di Sigma Prime. Quattro giorni prima della release, il 5 novembre, l’ingegnere di Sigma Prime Tan Chee Keong ha descritto il processo in un articolo del blog dedicato alle segnalazioni di bug. I ricercatori segnalano le falle tramite il bug bounty della Ethereum Foundation o via email; di solito uno sviluppatore risponde entro 24 ore con una prima valutazione su validità e gravità. Sigma Prime usa anche un proprio strumento di analisi sul codice e riceve i bug individuati dal team di sicurezza del protocollo della Ethereum Foundation.
Secondo questa politica, prima arriva la correzione e i dettagli aspettano. Finiscono nelle note di rilascio e negli avvisi di sicurezza su GitHub più tardi, quando gli utenti hanno avuto il tempo di aggiornare.
Lo stesso articolo offre uno sguardo raro sui numeri. Delle 81 segnalazioni chiuse, il 54% si è rivelato valido. Tra quelle valide, il 45% è stato classificato di gravità bassa, il 41% media e il 14% alta, e Sigma Prime afferma di non aver ancora ricevuto una segnalazione critica. Il tempo mediano tra la segnalazione e la correzione integrata nel codice è stato di 17 giorni, la media di 33.
Anche i precedenti vanno nella stessa direzione. La pagina degli avvisi di sicurezza di Lighthouse elenca patch precedenti i cui dettagli sono usciti dopo, tra cui quattro avvisi pubblicati il 26 ottobre 2026 (uno di gravità alta, per esaurimento della memoria nel servire le richieste di data column) e tre il 15 ottobre. Nemmeno le release ad alta priorità sono rare. La pagina delle release classifica ad alta priorità per i beacon node la v8.2.0 (22 giugno), la v8.2.1 (21 luglio) e la v8.2.2 (18 agosto), tutte con correzioni di sicurezza, e ad alta priorità per chi fa staking la v8.3.1 (22 ottobre), dopo la compromissione dell’autorità di certificazione eMudhra.
Cosa devono fare solo staker e operatori di nodi validatori Ethereum
- Se gestite un beacon node Lighthouse, aggiornatelo subito alla v8.3.3. Sono disponibili binari per Linux x86_64 e aarch64 e per i Mac con Apple Silicon, e l’immagine Docker è sigp/lighthouse:v8.3.3.
- Prima di installare, verificate la firma PGP del file scaricato con la chiave di Sigma Prime, indicata sulla pagina della release.
- Aggiornate il validator client Lighthouse alla prossima manutenzione ordinaria. La release lo classifica a bassa priorità.
- Arrivate da v8.2.x o da una versione più vecchia? Leggete le note della v8.3.0 prima del salto.
- Tenete d’occhio la pagina della release: i link agli avvisi di sicurezza verranno aggiunti lì quando gli operatori avranno avuto il tempo di aggiornare.
Chi fa staking tramite un exchange, un protocollo di proof of stake coin with a protocol that stakes it for you and issues a transferable token (such as Lido stETH or rETH) representing the deposit plus rewards, which you can use or sell while the coins stay staked.">liquid staking o un servizio di staking non deve installare nulla: il software lo gestisce il suo operatore di nodi. In un cluster di validatori distribuiti costruito con Obol o SSV Network, l’indicazione vale per ogni macchina che esegue un beacon node Lighthouse. La release riguarda solo Lighthouse. Per le basi su cosa fa ciascuna macchina, c’è la nostra guida ai nodi blockchain.
Diversità dei client Ethereum: perché conta la quota di un singolo client
Il proof of stake di Ethereum richiede l’accordo di due terzi dei validatori perché un blocco diventi definitivo. Per questo la quota di un client è un indicatore di sicurezza. Se si guasta un client usato da più di un terzo dei validatori, la catena può continuare a produrre blocchi ma non riesce a finalizzarli. Se un client difettoso superasse i due terzi, potrebbe finalizzare una catena sbagliata. Clientdiversity.org fissa l’obiettivo sotto il 33% per ogni client e considera zona di pericolo qualsiasi quota sopra il 66%.
La posizione di Lighthouse dipende da chi fa il conteggio, e i tracker sono in netto disaccordo.
| Tracker (clientdiversity.org, consultato l’11 nov 2026) | Lighthouse | Prysm | Teku | Nimbus |
|---|---|---|---|---|
| Miga Labs | 46,96% | 17,73% | 6,45% | 18,86% |
| Rated.Network | 20,6% | 21,17% | 53,86% | 3,12% |
La pagina dice che ogni fonte viene aggiornata ogni giorno, ma non mostra una data per queste rilevazioni e avverte che i dati «potrebbero non essere accurati al 100%». Un terzo tracker presente sulla pagina, Blockprint, indicava l’11 novembre Teku al 99,83% e Lighthouse allo 0,16%, lontanissimo dalle altre due letture. Secondo il conteggio di Miga Labs Lighthouse è sopra la soglia di un terzo e sotto quella dei due terzi. Secondo quello di Rated, è ben al di sotto di un terzo.
Il precedente di Prysm a dicembre 2025
Ethereum ha già visto che effetto può avere un bug in un client. L’aggiornamento Fusaka è entrato in funzione sulla mainnet il 3 dicembre 2025 alle 21:49 UTC, secondo la Ethereum Foundation. Il giorno dopo i nodi Prysm hanno esaurito le risorse mentre elaboravano le attestazioni di nodi non sincronizzati, ricostruendo da zero stati vecchi, secondo la ricostruzione di Cointelegraph basata sul post-mortem di Prysm.
All’epoch 411.448 la partecipazione al voto è scesa al 74,7%, circa otto punti sopra la soglia dei due terzi, come ha riportato Cointelegraph sulla base dei dati di beaconcha.in. È tornata vicino al 99% entro l’epoch 411.712. I validatori hanno perso circa 382 ETH di ricompense per le attestazioni nell’arco di oltre 42 epoch, secondo lo stesso resoconto di Cointelegraph, pubblicato il 15 dicembre 2025. Prysm deteneva meno di un terzo della rete, quindi la finalità ha retto.
Anthony Sassano, divulgatore dell’ecosistema Ethereum, scrisse allora su X, come riportato da Cointelegraph, che la rete avrebbe perso la finalità se il bug avesse colpito Lighthouse. L’articolo di Cointelegraph del 5 dicembre 2025, citando MigaLabs, collocava Lighthouse al 52,55% dopo l’incidente, rispetto a meno del 48,5% prima. La lettura di Miga Labs su clientdiversity.org all’11 novembre 2026 è del 46,96%.
Il 7 novembre è stato il client di esecuzione Reth ad avere una sua falla, che ha costretto Base, BNB Chain e Tempo a correre ai ripari. Per capire come funzionano i compiti mancati e le penalità, c’è la nostra guida a slashing e ricompense dei validatori Ethereum.
Cosa seguire nei prossimi giorni
Il prossimo passo è la divulgazione vera e propria. Lighthouse dice che i link agli avvisi di sicurezza compariranno sulla pagina della release v8.3.3 quando gli operatori avranno aggiornato. Quando gli avvisi arriveranno, dovrebbero indicare quali versioni erano esposte e quanto erano gravi le falle. Lighthouse non ha fornito una data.