Giugno ha portato una serie di sviluppi tecnici che stanno ridisegnando i contorni della sicurezza e della privacy nell’ecosistema blockchain. Da un fix urgente in Bitcoin Core a un rinvio che complica la tabella di marcia di Ethereum, passando per allarmi malware concreti e un chip quantistico che ha riacceso un dibattito mai del tutto sopito: gli aggiornamenti sulla tecnologia blockchain di questo mese raccontano un settore impegnato, forse più che mai, a rafforzare le proprie fondamenta.
Summary
Punti chiave
- Bitcoin Core 31.1 risolve una vulnerabilità di privacy nella funzione -privatebroadcast della versione 31.0, che poteva esporre l’indirizzo IP del mittente.
- L’upgrade Glamsterdam di Ethereum è stato posticipato alla seconda metà dell’anno; avanza invece la proposta EIP-8182 per trasferimenti privati nativi nell’hard fork Hegotá.
- Polygon zkEVM Mainnet Beta chiuderà ufficialmente il 1° luglio 2026: gli utenti devono ritirare i fondi prima della scadenza.
- L’upgrade Zcash Ironwood, previsto per luglio, punta a correggere le vulnerabilità nel pool Orchard e a ripristinare la fiducia nella fornitura fissa di ZEC.
- Il team SlowMist ha segnalato malware npm in 23 pacchetti compromessi, con oltre 408 repository GitHub contenenti credenziali rubate.
Bitcoin Core risolve una vulnerabilità di privacy con la versione 31.1
La versione 31.0 di Bitcoin Core aveva introdotto la funzione -privatebroadcast, pensata per migliorare la riservatezza delle transazioni. Ma in determinate condizioni di rete, questa funzione poteva invece fare l’effetto opposto: rivelare l’indirizzo IP del nodo che origina la transazione al nodo ricevente. Il fix è in arrivo con la versione 31.1.
Dettagli sulla perdita di IP nella funzione -privatebroadcast
Il problema si verifica quando il meccanismo di broadcast privato seleziona un nodo IPv4 o IPv6 che supporta il trasporto BIP324 v2. Se l’handshake v2 fallisce, Bitcoin Core tenta un fallback alla versione v1 — ma questa riconnessione bypassa il proxy Tor e stabilisce un collegamento diretto tramite IPv4 o IPv6, esponendo l’IP reale dell’utente.
I nodi interessati sono quelli con Bitcoin Core 31.0 che hanno abilitato -privatebroadcast, trasmettono transazioni via RPC sendrawtransaction e possono stabilire connessioni outbound IPv4/IPv6 dirette. Le connessioni via onion, I2P e il wallet RPC non sono coinvolte.
Consigli per gli utenti prima dell’aggiornamento
In attesa della versione 31.1, Bitcoin Core consiglia agli utenti esposti di disabilitare la funzione -privatebroadcast, disattivare il trasporto v2, oppure instradare tutto il traffico IPv4/IPv6 attraverso Tor. La release candidate Bitcoin Core v31.1rc1 è già disponibile per il download dal sito ufficiale e include anche correzioni su validazione, rete P2P, migrazione wallet, MuSig, sistema di build, testing e CI.
Vale la pena notare che questo episodio mette in luce un rischio reale nell’adozione di nuove funzionalità di privacy: l’implementazione tecnica deve essere robusta fin dall’inizio, perché una privacy che si “rompe” in silenzio è potenzialmente peggio di nessuna privacy.
Ethereum rinvia Glamsterdam e avanza proposte per la privacy
Ethereum è al centro di più storie parallele questo mese. L’upgrade Glamsterdam slitta, ma il lavoro su privacy e resistenza alla censura procede su altri fronti — con proposte concrete che avanzano verso i prossimi hard fork.
Rinvio di Glamsterdam alla seconda metà dell’anno
L’attivazione su mainnet di Glamsterdam, l’upgrade incentrato su scaling L1 e fairness MEV, è stata posticipata alla seconda metà dell’anno. Lo sviluppo prosegue con le iterazioni Devnet-5 e Devnet-6, mentre il core developer Terence ha confermato il rilascio di Glamsterdam devnet-6, che introduce EIP-8282 con le execution requests del builder ePBS e due nuovi system contract. Sul fronte execution layer, il lavoro post-devnet include aggiunte come EIP-2780, EIP-8038, EIP-7997 e altri aggiornamenti tecnici.
Proposta per un registro chiavi pubbliche post-quantistiche
I ricercatori Ethereum Thomas Coratger e Tom Wambsgans hanno pubblicato una proposta per creare un registro di chiavi pubbliche post-quantistiche per i validatori, con l’obiettivo di avviare una migrazione graduale delle firme BLS del Proof-of-Stake verso schemi post-quantum sicuri. La strategia prevede una prima fase di “registry fork” in cui i validatori pre-registrano le proprie chiavi post-quantistiche, seguita da fork successivi prima del passaggio definitivo al nuovo meccanismo.
La firma candidata è XMSS hash-based, con una chiave pubblica di soli 52 byte — ma ogni singola firma pesa circa 3.112 byte, richiedendo il supporto di leanVM e aggregazione SNARK post-quantum per limitare l’overhead di rete. È un’architettura tecnicamente ambiziosa, e i tempi di adozione resteranno lunghi.
EIP-8182 per trasferimenti privati nativi nell’hard fork Hegotá
EIP-8182, la proposta di trasferimento privato nativo su Ethereum sviluppata da Tom Lehman, ha ottenuto lo status “Proposed for Inclusion” nell’hard fork Hegotá. L’obiettivo è introdurre un meccanismo di trasferimento privato direttamente nel protocollo base di Ethereum L1, senza commissioni di protocollo aggiuntive e senza rendere obbligatoria la funzionalità.
Il sistema sfrutta smart contract a indirizzo fisso e precompile ZK per creare un anonimity pool condiviso a livello di protocollo, risolvendo la frammentazione tipica delle soluzioni di privacy applicative. L’evoluzione del sistema dipenderà esclusivamente dagli hard fork di Ethereum, senza token di governance né multisig — una scelta deliberata per eliminare vettori di centralizzazione.
Il CEO di Consensys sul futuro di Ethereum con zero-knowledge
Joseph Lubin, CEO di Consensys, ha dichiarato che Ethereum potrebbe diventare un protocollo completamente basato su zero-knowledge proof entro 3-5 anni. Lubin ha sottolineato che i Layer 2 hanno già raggiunto la generazione di prove ZK in tempo reale, e che queste capacità verranno progressivamente integrate nel Layer 1, portando Ethereum verso un’architettura supportata da più prover formalmente verificati.
Ha anche menzionato come Linea, Gnosis e altri stiano usando le prove ZK per abilitare composizione sincrona tra reti diverse — scenario che potrebbe aprire la strada a un’esecuzione atomica unificata senza bridge, risolvendo la frammentazione della liquidità. Sul piano organizzativo, Lubin ha indicato che almeno tre gruppi si separeranno dall’Ethereum Foundation, focalizzandosi rispettivamente su protocollo core, usabilità/scaling e outreach istituzionale.
Progressi su Ethereum Layer 2 e la fine di Polygon zkEVM
Sul fronte dei Layer 2, giugno ha portato lanci significativi e almeno una chiusura definitiva da segnare in agenda.
Lancio del framework di privacy STRK20 di Starknet
Starknet ha lanciato STRK20, un framework di privacy basato su zero-knowledge proof che consente a qualsiasi asset ERC20 sulla rete di ottenere saldi privati e trasferimenti riservati. A differenza dei mixer tradizionali, STRK20 integra la privacy direttamente nel flusso dell’asset, con supporto per trasferimenti, trading, lending, staking e pagamenti. Il framework introduce anche un meccanismo di Viewing Keys che permette agli utenti di divulgare selettivamente informazioni sulle transazioni per esigenze di compliance. Il primo asset a adottare STRK20 è strkBTC.
Cessazione attività di Polygon zkEVM Mainnet Beta
La notizia più urgente per chi opera su Polygon riguarda una data precisa: il 1° luglio 2026, quando Polygon zkEVM Mainnet Beta cesserà ufficialmente le operazioni. Gli utenti hanno poco tempo per ritirare asset e posizioni LP dalla rete prima della scadenza — chi non lo fa rischia di perdere i fondi bloccati in protocolli DeFi, poiché questi non possono essere migrati automaticamente.
Gli asset detenuti in wallet semplici, però, migreranno automaticamente alla mainnet Ethereum e potranno essere riscattati tramite un’interfaccia dedicata. La distinzione tra “wallet” e “DeFi protocol” è critica: chi ha fondi bloccati in contratti deve agire prima della scadenza.
Upgrade Ironwood di Zcash e sicurezza della rete
Zcash affronta il suo momento più delicato da anni. Il pool Orchard, cuore del sistema di privacy del protocollo, aveva una vulnerabilità critica. La risposta è strutturata e già in parte attuata.
Ironwood previsto per luglio: correzione delle vulnerabilità nel pool Orchard
La Zcash Foundation ha già rilasciato Zebra 4.5.3 e 5.0.0 per correggere una vulnerabilità di soundness nel circuito Orchard Action. Zebra 4.5.3 ha disabilitato temporaneamente le azioni Orchard sulla mainnet tramite un emergency soft fork al blocco 3.363.426, mentre Zebra 5.0.0 ha attivato l’hard fork NU6.2 al blocco 3.364.600 ripristinando Orchard con il circuito corretto. La Fondazione ha confermato che la vulnerabilità è stata scoperta prima di qualsiasi sfruttamento noto, senza creazione di valore non autorizzata e senza compromissione della privacy degli utenti.
L’upgrade Ironwood è ora programmato per luglio e introduce un nuovo privacy pool corretto, con la graduale chiusura del vecchio. L’obiettivo dichiarato è consentire a utenti e nodi di verificare in modo autonomo e decentralizzato che il totale in circolazione di ZEC non superi il hard cap di 21 milioni, ripristinando la fiducia nel meccanismo di offerta fissa.
Il developer core Sean Bowe ha aggiornato la community confermando che almeno tre importanti società di audit stanno revisionando Orchard, e che strumenti di AI auditing stanno analizzando il codebase in parallelo. Valar Group ha già lanciato un testnet e implementato alcune modifiche lato wallet.
Allarmi sicurezza e il chip quantistico di Microsoft
SlowMist avverte di malware npm che sfrutta credenziali sviluppatori rubate
Il team SlowMist Security ha emesso un alert su nuove varianti di malware — denominate Shai-Hulud, Miasma e Hades — legate all’account sviluppatore compromesso “czirker” nell’ecosistema npm. I malware si attivano durante il processo di installazione tramite un file binding.gyp pre-configurato, rubando token GitHub e npm, credenziali cloud (AWS, GCP, Azure), dati di ambiente locali e abusando di GitHub Actions.
Al momento sono stati confermati 23 pacchetti compromessi, tra cui leo-logger con 3.140 download settimanali. Sono stati individuati 408 repository GitHub contenenti credenziali rubate. SlowMist raccomanda di ispezionare immediatamente lockfile e record di pacchetti, rimuovere i pacchetti interessati, ruotare tutte le chiavi critiche e attivare l’autenticazione a due fattori.
Questo tipo di attacco è particolarmente insidioso perché non sfrutta una vulnerabilità di codice, ma la fiducia implicita nell’ecosistema di dipendenze. Un singolo account sviluppatore compromesso può contaminare decine di pacchetti usati da migliaia di progetti.
Microsoft presenta il chip quantistico Majorana 2
Microsoft ha presentato al Build conference il suo chip quantistico topologico di seconda generazione, Majorana 2. L’azienda dichiara una affidabilità 1.000 volte superiore rispetto alla generazione precedente, con una durata media dei qubit di 20 secondi e alcuni qubit che raggiungono circa 1 minuto. Microsoft punta a raggiungere il computing quantistico scalabile entro il 2029, con il supporto di tool AI Agent per accelerare screening dei materiali, automatizzare misurazioni e ottimizzare i processi produttivi.
Il progresso ha riacceso il dibattito sulla futura minaccia del quantum computing alle firme digitali di Bitcoin — un tema che i ricercatori di sicurezza tengono d’occhio da anni. Come ha sottolineato Decrypt, questo non significa che i computer quantistici attuali siano in grado di attaccare Bitcoin: siamo ancora lontani da quel punto. Ma il ritmo di avanzamento di Majorana 2 rende la migrazione post-quantum un tema da pianificare ora, non tra dieci anni — ed è precisamente quello che stanno facendo in parallelo sia il team di ricerca Ethereum che l’Algorand Foundation, che punta a una transizione quantum-resistant entro fine 2027.
FAQ
Quale problema di privacy è stato corretto in Bitcoin Core versione 31.1?
Bitcoin Core 31.1 ha risolto una vulnerabilità nella funzione -privatebroadcast della versione 31.0, che in determinate condizioni di rete poteva esporre l’indirizzo IP del nodo che originava la transazione al nodo ricevente.
Quando è atteso ora l’upgrade Glamsterdam di Ethereum?
L’upgrade Glamsterdam di Ethereum è stato posticipato alla seconda metà dell’anno. Lo sviluppo prosegue attraverso le iterazioni Devnet-5 e Devnet-6, con diverse EIP in fase di revisione attiva.
Cos’è EIP-8182 e perché è importante?
EIP-8182 è una proposta di trasferimento privato nativo per Ethereum, sviluppata da Tom Lehman. Mira a introdurre funzionalità di privacy direttamente nel protocollo L1 tramite un anonimity pool condiviso e precompile ZK. È stata ufficialmente proposta per l’inclusione nell’hard fork Hegotá, dove entrerebbe come meccanismo opzionale senza commissioni di protocollo aggiuntive.
Quali minacce evidenzia l’allarme malware di SlowMist?
SlowMist ha segnalato malware npm che sfruttano credenziali di sviluppatori rubate per compromettere pacchetti nell’ecosistema npm. Le varianti individuate rubano token GitHub e npm, credenziali cloud (AWS, GCP, Azure) e dati di ambiente locali, con 23 pacchetti confermati come infetti e 408 repository GitHub contenenti credenziali compromesse.
Contenuto realizzato con l’assistenza dell’intelligenza artificiale e con revisione editoriale umana.
