I ricercatori di Ethereum si affrettano a colmare il divario di sicurezza zkEVM prima dell'obiettivo di dicembre
Punti chiave
- •La classifica del 21 agosto per koalaIRS12 mostrava un certificato inferiore di 63,99 bit e un certificato superiore di 116,13 bit, lasciando 52,14 bit irrisolti dopo nove submission promosse da sette risolutori.
- •Il concorso prevede due binari opposti in cui le submission di soundness alzano il certificato inferiore e le submission di attacco abbassano il certificato superiore, con ogni prova promossa verificata dal kernel di Lean in un ambiente bloccato.
- •La roadmap zkEVM della Ethereum Foundation richiede una sicurezza dimostrabile di 128 bit, proof finali di 300 KiB o meno e un argomento formale di soundness per l'architettura di ricorsione, con la scadenza dell'M3 spostata all'inizio di dicembre 2026.
- •Il punteggio della challenge si applica solo al punto parametrico codificato e non è espressamente una misura della soundness dell'intero sistema o della sicurezza dell'intero protocollo, che richiederebbero analisi separate.
- •L'impatto immediato del concorso è limitato alle evidenze di ricerca, perché le proof di esecuzione zkEVM attualmente integrano i test sulla mainnet in una fase non critica per il consenso, senza cambiare il percorso di validazione di Ethereum.

I ricercatori di Ethereum si affrettano a colmare il divario di sicurezza zkEVM prima dell'obiettivo di dicembre
Il concorso better.codes di Ethereum ha trasformato un divario di proof crittografica in una misurazione pubblica e riproducibile che i ricercatori possono far avanzare da entrambi i lati.
Alle 15:44:47 UTC del 21 agosto, la classifica in tempo reale mostrava per koalaIRS12 un certificato inferiore di 63,99 bit e un certificato superiore di 116,13 bit. Dopo nove submission promosse da sette risolutori, tra i due limiti restano irrisolti 52,14 bit.
KoalaIRS12 è un profilo di parametri fissi per una riduzione Reed–Solomon interlacciata utilizzata nella ricerca sui sistemi di proof. Le questioni di prossimità Reed–Solomon di questo tipo sono fondative e non periferiche: FRI, il Fast Reed–Solomon IOP of Proximity, è la tecnica che gli STARK e gli altri SNARK basati su hash impiegano per verificare se una stringa di cui è stato fatto il commit sia vicina a un polinomio di basso grado. Il repository della challenge definisce il suo punteggio come una grandezza di verifica a campione ed esclude espressamente che venga interpretato come il meno-log2 della soundness dell'intero sistema o come la sicurezza dell'intero protocollo. Ciò che i ricercatori hanno ora a disposizione è una misura pubblica della distanza tra ciò che la challenge ha dimostrato sicuro e ciò che il suo certificato superiore considera ancora non sicuro.
Cosa dimostra la classifica
Il concorso prevede due binari concepiti per chiudere l'intervallo da direzioni opposte.
Il binario di soundness alza il certificato inferiore. A un raggio certificato, una submission di successo dimostra che il limite dell'errore di riduzione eseguibile del benchmark soddisfa l'obiettivo codificato, per poi mappare quel raggio nel punteggio mostrato in classifica.
Il binario di attacco abbassa il certificato superiore. Il suo teorema certifica un suffisso non sicuro in base alla condizione di densità dell'insieme vincente del benchmark, e il repository copre direttamente quel suffisso perché la formalizzazione non assume alcun teorema di monotonicità per la densità dell'insieme vincente. Il punteggio del binario del certificato superiore descrive il confine formale per koalaIRS12; un costo di attacco su Ethereum richiederebbe un'analisi separata dell'intero sistema.
Secondo l'annuncio di lancio della Ethereum Foundation, l'enunciato del teorema, il punto parametrico e l'ambiente di verifica sono bloccati (pinned). Ogni submission esporta il teorema richiesto, un comparatore confronta quell'enunciato con l'obiettivo e il kernel di Lean verifica la dimostrazione prima della promozione. Lean è un dimostratore interattivo di teoremi il cui piccolo kernel affidabile verifica automaticamente ogni passo della dimostrazione. Un risultato accettato dimostra il teorema inviato all'interno di quell'ambiente bloccato.
Le garanzie di produzione vanno oltre. Devono infatti coprire anche la completezza del modello, le ipotesi incorporate nelle sue definizioni, la fedeltà dell'implementazione e la composizione di componenti analizzati separatamente. La revisione di maggio della Foundation su un lavoro di verifica formale relativo a SP1, uno zkVM sviluppato da Succinct, mostra perché questi livelli aggiuntivi contano: le specifiche e gli enunciati dei teoremi sono codice, input e versioni richiedono un blocco riproducibile e i risultati a livello di componente richiedono un ragionamento più ampio prima di poter sostenere conclusioni su un sistema completo.
Un articolo accademico separato di Gal Arnon, Dan Boneh e Giacomo Fenzi individua la decodifica a lista, i divari di prossimità Reed–Solomon, l'accordo correlato e l'accordo correlato reciproco come questioni aperte per i sistemi di proof succinct. Pubblicato prima dell'attuale snapshot della classifica, l'articolo spiega l'importanza di questa famiglia di problemi senza valutare i punteggi attuali.
La Foundation presenta better.codes come un percorso di ricerca verificato automaticamente per la sicurezza degli SNARK basati su hash, e migliorare i certificati di koalaIRS12 affinerebbe una riduzione all'interno di quel programma. Il certificato da 116,13 bit ha la stessa portata limitata: si applica al punto parametrico codificato nella challenge, mentre altre scelte di parametri, costruzioni e componenti di sistema restano questioni di ricerca separate.
È il formato a due lati a rendere informativo l'intervallo. Ogni promozione modifica un confine verificabile e il teorema bloccato mantiene comparabili i risultati successivi.
Il divario rispetto all'obiettivo di dicembre di Ethereum
La roadmap di sicurezza zkEVM di dicembre 2025 della Foundation richiedeva una sicurezza dimostrabile di 128 bit — una soglia convenzionalmente intesa come un attacco che richiede dell'ordine di 2^128 operazioni — oltre a una dimensione finale della proof di 300 KiB o meno e a un argomento formale di soundness per l'architettura di ricorsione. Un aggiornamento di febbraio sullo sprint di sicurezza ha spostato la scadenza dell'M3 all'inizio di dicembre 2026 e ha allineato l'argomento di sicurezza dell'architettura a un deliverable del 1° dicembre. La roadmap chiede ai team di collegare i limiti dei componenti a un pacchetto di sistema verificabile tramite audit.
Per koalaIRS12, un certificato inferiore che raggiungesse l'obiettivo codificato di 128 bit risolverebbe il lato soundness di questo benchmark nel suo punto parametrico fisso. Un'affermazione di produzione su uno zkEVM richiederebbe inoltre una contabilità della soundness su ogni componente rilevante, il rispetto dei limiti di dimensione della proof, una topologia di ricorsione documentata, un argomento su come le sue parti si compongano e prove che le specifiche corrispondano alle implementazioni.
La pagina pubblica dei progressi della Foundation, sincronizzata per l'ultima volta il 20 agosto, elenca i risultati sulla preparazione degli zkVM e sulla conformità ISA e indica il proving in tempo reale e l'integrazione di soundcalc tra i criteri. Le sue tabelle renderizzate non contengono alcun indicatore di completamento per il pacchetto completo di inizio dicembre e restano silenziose sul lavoro tracciato altrove.
Un aggiornamento di maggio sulle proof di esecuzione opzionali ha descritto una fase non critica per il consenso in cui le proof zkEVM integrano i test sulla mainnet mentre la ri-esecuzione ordinaria dei client di esecuzione continua a guidare l'attestazione. Questo ruolo opzionale mantiene l'effetto immediato della classifica nell'ambito della ricerca: il movimento dei certificati modifica le evidenze disponibili per futuri argomenti di sicurezza senza cambiare l'attuale percorso di validazione critico per il consenso di Ethereum.
Su better.codes, le submission di soundness possono innalzare il certificato inferiore di 63,99 bit e le submission di attacco possono abbassare il certificato superiore di 116,13 bit. Lungo tutta la roadmap zkEVM, i team dovranno pubblicare la contabilità a livello di sistema, le dimensioni delle proof, gli argomenti di ricorsione e le evidenze di implementazione richieste per la revisione di inizio dicembre.
Per ora, l'intervallo di 52,14 bit resta una misura in tempo reale del lavoro incompiuto su koalaIRS12. Il caso di produzione a 128 bit di Ethereum dipenderà da come queste evidenze sui componenti si inseriscano nella proof più ampia.
Fonte: CryptoNews