L'ecosistema zkEVM ha trascorso un anno concentrandosi sulla latenza. Il tempo di verifica per un blocco Ethereum è crollato da 16 minuti a 16 secondi, i costi sono diminuiti di 45 volte e la partecipazioneL'ecosistema zkEVM ha trascorso un anno concentrandosi sulla latenza. Il tempo di verifica per un blocco Ethereum è crollato da 16 minuti a 16 secondi, i costi sono diminuiti di 45 volte e la partecipazione

La Fondazione Ethereum Si Concentra Sulla Sicurezza Piuttosto Che Sulla Velocità – Stabilisce Una Rigida Regola A 128-bit Per Il 2026

2025/12/20 19:51

L'ecosistema zkEVM ha trascorso un anno concentrandosi sulla latenza. Il tempo di dimostrazione per un blocco Ethereum è crollato da 16 minuti a 16 secondi, i costi sono diminuiti di 45 volte e i zkVM partecipanti ora dimostrano il 99% dei blocchi della mainnet in meno di 10 secondi sull'hardware di destinazione.

La Ethereum Foundation (EF) ha dichiarato vittoria il 18 dicembre: la dimostrazione in tempo reale funziona. I colli di bottiglia delle prestazioni sono stati eliminati. Ora inizia il vero lavoro, perché la velocità senza solidità è una responsabilità, non una risorsa, e la matematica alla base di molti zkEVM basati su STARK si è discretamente incrinata per mesi.

A luglio, l'EF ha stabilito un obiettivo formale per la "dimostrazione in tempo reale" che raggruppa latenza, hardware, energia, apertura e sicurezza: dimostrare almeno il 99% dei blocchi della mainnet entro 10 secondi, su hardware che costa circa $100.000 e funziona entro 10 kilowatt, con codice completamente open-source, con sicurezza a 128 bit e con dimensioni di prova pari o inferiori a 300 kilobyte.

Il post del 18 dicembre afferma che l'ecosistema ha raggiunto l'obiettivo di prestazioni, misurato sul sito di benchmarking EthProofs.

Il tempo reale qui è definito in relazione al tempo di slot di 12 secondi e circa 1,5 secondi per la propagazione dei blocchi. Lo standard è essenzialmente "le prove sono pronte abbastanza velocemente da consentire ai validatori di verificarle senza interrompere la disponibilità".

L'EF ora passa dal throughput alla solidità, e il passaggio è netto. Molti zkEVM basati su STARK si sono affidati a congetture matematiche non dimostrate per raggiungere i livelli di sicurezza pubblicizzati.

Negli ultimi mesi, alcune di queste congetture, in particolare le ipotesi di "proximity gap" utilizzate nei test di basso grado SNARK e STARK basati su hash, sono state matematicamente violate, abbassando la sicurezza effettiva in bit dei set di parametri che dipendevano da esse.

L'EF afferma che l'unico risultato finale accettabile per l'uso L1 è la "sicurezza dimostrabile", non "la sicurezza supponendo che la congettura X sia valida".

Hanno stabilito la sicurezza a 128 bit come obiettivo, allineandola agli organismi di standardizzazione crittografica mainstream e alla letteratura accademica sui sistemi a lungo termine, nonché ai calcoli record del mondo reale che dimostrano che 128 bit è realisticamente fuori dalla portata degli attaccanti.

L'enfasi sulla solidità rispetto alla velocità riflette una differenza qualitativa.

Se qualcuno può falsificare una prova zkEVM, può coniare token arbitrari o riscrivere lo stato L1 e far mentire il sistema, non solo drenare un contratto.

Questo giustifica quello che l'EF chiama un margine di sicurezza "non negoziabile" per qualsiasi zkEVM L1.

Roadmap a tre traguardi

Il post delinea una roadmap chiara con tre fermate obbligatorie. Primo, entro la fine di febbraio 2026, ogni team zkEVM in gara collega il proprio sistema di prova e i circuiti a "soundcalc", uno strumento mantenuto dall'EF che calcola le stime di sicurezza basate sui limiti crittanalitici attuali e sui parametri dello schema.

La storia qui è "righello comune". Invece di ogni team che cita la propria sicurezza in bit con ipotesi personalizzate, soundcalc diventa il calcolatore canonico e può essere aggiornato man mano che emergono nuovi attacchi.

Secondo, "Glamsterdam" entro la fine di maggio 2026 richiede almeno 100 bit di sicurezza dimostrabile tramite soundcalc, prove finali pari o inferiori a 600 kilobyte e una spiegazione pubblica compatta dell'architettura di ricorsione di ciascun team con uno schema del motivo per cui dovrebbe essere solida.

Questo riduce silenziosamente il requisito originale di 128 bit per la distribuzione anticipata e tratta 100 bit come un obiettivo intermedio.

Terzo, "H-star" entro la fine del 2026 è lo standard completo: sicurezza dimostrabile a 128 bit tramite soundcalc, prove pari o inferiori a 300 kilobyte, più un argomento di sicurezza formale per la topologia di ricorsione. È qui che questo diventa meno una questione di ingegneria e più di metodi formali e prove crittografiche.

Leve tecniche

L'EF indica diversi strumenti concreti destinati a rendere fattibile l'obiettivo di 128 bit e sotto i 300 kilobyte. Evidenziano WHIR, un nuovo test di prossimità Reed-Solomon che funge anche da schema di impegno polinomiale multilineare.

WHIR offre sicurezza trasparente e post-quantistica e produce prove più piccole e verifica più veloce rispetto agli schemi di tipo FRI più vecchi allo stesso livello di sicurezza.

I benchmark con sicurezza a 128 bit mostrano prove circa 1,95 volte più piccole e verifica diverse volte più veloce rispetto alle costruzioni di base.

Fanno riferimento a "JaggedPCS", un insieme di tecniche per evitare un padding eccessivo quando si codificano le tracce come polinomi, che consentono ai dimostratori di evitare lavoro sprecato pur producendo impegni succinti.

Menzionano il "grinding", che è la ricerca brute-force sulla casualità del protocollo per trovare prove più economiche o più piccole rimanendo entro i limiti di solidità, e "topologia di ricorsione ben strutturata", che significa schemi stratificati in cui molte prove più piccole vengono aggregate in un'unica prova finale con solidità attentamente argomentata.

Matematica polinomiale esotica e trucchi di ricorsione vengono utilizzati per ridurre le prove dopo aver aumentato la sicurezza a 128 bit.

Lavori indipendenti come Whirlaway utilizzano WHIR per costruire STARK multilineari con efficienza migliorata, e costruzioni di impegno polinomiale più sperimentali vengono costruite da schemi di disponibilità dei dati.

La matematica si sta muovendo velocemente, ma si sta anche allontanando da ipotesi che sembravano sicure sei mesi fa.

Cosa cambia e le domande aperte

Se le prove sono costantemente pronte entro 10 secondi e rimangono sotto i 300 kilobyte, Ethereum può aumentare il limite di gas senza costringere i validatori a rieseguire ogni transazione.

I validatori verificherebbero invece una piccola prova, consentendo alla capacità dei blocchi di crescere mantenendo realistico lo staking domestico. Questo è il motivo per cui il precedente post in tempo reale dell'EF collegava esplicitamente latenza e potenza ai budget di "dimostrazione domestica" come 10 kilowatt e rig sotto i $100.000.

La combinazione di ampi margini di sicurezza e prove piccole è ciò che rende un "L1 zkEVM" un livello di regolamento credibile. Se tali prove sono sia veloci che dimostratamente sicure a 128 bit, i L2 e gli zk-rollup possono riutilizzare la stessa macchina tramite precompilazioni, e la distinzione tra "rollup" ed "esecuzione L1" diventa più una scelta di configurazione che un confine rigido.

La dimostrazione in tempo reale è attualmente un benchmark off-chain, non una realtà on-chain. I numeri di latenza e costi provengono dalle configurazioni hardware e dai carichi di lavoro curati di EthProofs.

C'è ancora un divario tra questo e migliaia di validatori indipendenti che effettivamente eseguono questi dimostratori a casa. La storia della sicurezza è in evoluzione. L'intero motivo per cui soundcalc esiste è che i parametri di sicurezza STARK e SNARK basati su hash continuano a muoversi man mano che le congetture vengono smentite.

I risultati recenti hanno ridisegnato la linea tra regimi di parametri "decisamente sicuri", "congetturalmente sicuri" e "decisamente non sicuri", il che significa che le impostazioni "100 bit" odierne potrebbero essere nuovamente riviste man mano che emergono nuovi attacchi.

Non è chiaro se tutti i principali team zkEVM raggiungeranno effettivamente la sicurezza dimostrabile a 100 bit entro maggio 2026 e 128 bit entro dicembre 2026 rimanendo sotto i limiti di dimensione delle prove, o se alcuni accetteranno silenziosamente margini inferiori, faranno affidamento su ipotesi più pesanti o spingeranno la verifica off-chain più a lungo.

La parte più difficile potrebbe non essere la matematica o le GPU, ma formalizzare e verificare le architetture di ricorsione complete.

L'EF ammette che diversi zkEVM spesso compongono molti circuiti con sostanziale "glue code" tra di loro, e che documentare e dimostrare la solidità per quegli stack personalizzati è essenziale.

Questo apre una lunga coda di lavoro per progetti come Verified-zkEVM e framework di verifica formale, che sono ancora precoci e disomogenei tra gli ecosistemi.

Un anno fa, la domanda era se gli zkEVM potessero dimostrare abbastanza velocemente. A quella domanda è stata data risposta.
La nuova domanda è se possano dimostrare in modo sufficientemente solido, a un livello di sicurezza che non dipende da congetture che potrebbero crollare domani, con prove abbastanza piccole da propagarsi attraverso la rete P2P di Ethereum e con architetture di ricorsione formalmente verificate abbastanza da ancorare centinaia di miliardi di dollari.

Lo sprint delle prestazioni è finito. La corsa alla sicurezza è appena iniziata.

Il post Ethereum Foundation si riconcentra sulla sicurezza rispetto alla velocità - stabilisce una regola rigorosa di 128 bit per il 2026 è apparso per primo su CryptoSlate.

Opportunità di mercato
Logo Bitdealer
Valore Bitdealer (BIT)
$0.002658
$0.002658$0.002658
-0.44%
USD
Grafico dei prezzi in tempo reale di Bitdealer (BIT)
Disclaimer: gli articoli ripubblicati su questo sito provengono da piattaforme pubbliche e sono forniti esclusivamente a scopo informativo. Non riflettono necessariamente le opinioni di MEXC. Tutti i diritti rimangono agli autori originali. Se ritieni che un contenuto violi i diritti di terze parti, contatta [email protected] per la rimozione. MEXC non fornisce alcuna garanzia in merito all'accuratezza, completezza o tempestività del contenuto e non è responsabile per eventuali azioni intraprese sulla base delle informazioni fornite. Il contenuto non costituisce consulenza finanziaria, legale o professionale di altro tipo, né deve essere considerato una raccomandazione o un'approvazione da parte di MEXC.