{"id":236326,"date":"2026-07-29T21:01:09","date_gmt":"2026-07-29T21:01:09","guid":{"rendered":"https:\/\/cryptonews.com\/it\/news\/zcash-ironwood-upgrade-supply-zec-verificabile\/"},"modified":"2026-07-29T21:00:23","modified_gmt":"2026-07-29T21:00:23","slug":"zcash-ironwood-offerta-zec-verificabile","status":"publish","type":"post","link":"https:\/\/cryptonews.com\/it\/news\/zcash-ironwood-offerta-zec-verificabile\/","title":{"rendered":"Hard fork Ironwood: come Zcash ha reso verificabile l’offerta di ZEC"},"content":{"rendered":"
La rete Zcash<\/strong> ha completato con successo l’aggiornamento Ironwood<\/strong> al blocco 3.428.143<\/strong>, attivato alle ore 16:08 italiane del 28 luglio 2026. L’upgrade, implementato tramite hard fork, risponde direttamente al bug individuato nella pool Orchard<\/strong> e introduce un meccanismo di contabilizzazione che rende verificabile pubblicamente l’offerta circolante di $ZEC<\/strong>.<\/p>
Il contesto \u00e8 quello di una vulnerabilit\u00e0 scoperta nella pool Orchard che, in teoria, avrebbe potuto consentire la creazione di token $ZEC contraffatti al di sopra dell’offerta prevista dal protocollo, senza che ci\u00f2 fosse rilevabile dall’esterno. Gli sviluppatori avevano gi\u00e0 rassicurato la comunit\u00e0 sull’improbabilit\u00e0 di uno sfruttamento concreto, ma la verifica definitiva richiedeva un intervento strutturale sul protocollo.<\/p><\/figure>
Come funziona il meccanismo turnstile<\/h2><\/span>
L’aggiornamento Ironwood opera secondo una logica in tre passaggi. La pool Orchard viene sigillata per i nuovi depositi<\/strong>: nessun fondo aggiuntivo pu\u00f2 entrare. I circa 3,76 milioni di $ZEC<\/strong> gi\u00e0 presenti al suo interno – pari a circa il 22% della supply circolante<\/strong> – possono esclusivamente essere prelevati verso le nuove pool del modello Ironwood. Il trasferimento avviene attraverso il meccanismo turnstile<\/em>, che traccia con precisione gli ingressi e le uscite tra le diverse pool private.<\/p>
Il principio sottostante \u00e8 matematicamente vincolante: il turnstile impedisce che dalla pool Orchard escano pi\u00f9 $ZEC di quanti ne siano stati provabilmente depositati. Qualsiasi token contraffatto eventualmente creato attraverso il bug rimarrebbe intrappolato in una pool non pi\u00f9 funzionale, oppure si renderebbe visibile nel momento stesso in cui qualcuno tentasse di migrarlo verso le nuove pool. \u00c8 in questo senso che Ironwood trasforma la verificabilit\u00e0 della supply da promessa teorica a meccanismo applicato.<\/p>
Tempistiche di verifica: giorni o settimane<\/h2><\/span>
Un elemento critico da distinguere \u00e8 la differenza tra verificabilit\u00e0 tecnica<\/em> e conferma pratica<\/em>. L’architettura di Ironwood consente in linea di principio il calcolo dell’offerta reale gi\u00e0 a partire dall’attivazione. Tuttavia, la conferma definitiva che la vulnerabilit\u00e0 non sia mai stata sfruttata emerger\u00e0 solo man mano che gli utenti migreranno i propri fondi da Orchard alle nuove pool: pi\u00f9 token vengono trasferiti senza evidenziare incongruenze, pi\u00f9 alta diventa la probabilit\u00e0 statistica che la supply sia rimasta integra.<\/p>