Ciao a tutti, nell'attuale ecosistema di Ethereum, sia l'Optimistic Rollup che lo ZK Rollup stanno mantenendo un sistema di verifica su catene personalizzate che è estremamente ingombrante e ad alto rischio. Ogni volta che un bug nella macchina virtuale di base viene corretto, deve affrontare un lungo e pericoloso processo di aggiornamento della governance decentralizzata.
Recentemente, sul forum di ricerca di Ethereum (ethresear.ch) è emersa una proposta rivoluzionaria: si propone di generalizzare l'EIP-8025 e introdurre un nuovo EIP per aggiungere un primitivo di "Verifica di Prova Nativa (Native Proof Verification)" al livello base di Ethereum.
Se questa proposta verrà attuata, i futuri Rollup non dovranno più implementare contratti di verifica complessi on-chain, ma potranno "usufruire" direttamente dell'infrastruttura di verifica del layer di consenso di Ethereum (CL). Questo non solo ridurrà drasticamente il codice ridondante sulla mainnet di Ethereum, ma eleverà anche la sicurezza e la logica di aggiornamento di Ethereum L2 a nuove altezze.
Questo articolo scompone la logica centrale di questa proposta tecnica, il meccanismo di attuazione e il suo impatto profondo sulla futura corsa all'espansione.
Uno, analisi dei punti critici: il "tallone d'Achille" del sistema di verifica Rollup attuale
Attualmente, ogni Ethereum L2 è come un "regno" indipendente, combattendo ognuno per conto proprio e costruendo una complessa infrastruttura di verifica su L1.
Contratti complessi on-chain: i ZK Rollup devono implementare contratti di verifica, adattatori e scheduler specifici per zkVM (macchina virtuale a conoscenza zero); gli Optimistic Rollup richiedono di implementare enormi macchine virtuali per prove di frode e logiche di risoluzione delle controversie.
Alti costi di manutenzione e rischi di sicurezza: questi contratti sono mantenuti indipendentemente dai rispettivi team. Se viene scoperto un bug nel sistema di prova di base o nella macchina virtuale, il team di sviluppo deve eseguire un aggiornamento del contratto tramite un multi-sig personalizzato o un voto DAO.
Ripetizioni inefficaci nell'ecosistema: nell'ecosistema Ethereum esistono molte situazioni in cui si ripete la creazione della ruota, diversi progetti mantengono librerie di codice di verifica simili, consumando enormi quantità di Gas e amplificando esponenzialmente l'esposizione ai rischi di sicurezza dell'intera rete.
Prendendo come esempio un Rollup che utilizza un'architettura "multi-proof", per raggiungere la massima sicurezza, potrebbe dover implementare fino a sei contratti su L1 (compresi diversi validatori zkVM di diversi fornitori, adattatori personalizzati, scheduler per multi-proof, ecc.). Qualsiasi aggiornamento in uno di questi aspetti rappresenta un incubo catastrofico.
Due, rottura centrale: generalizzare l'EIP-8025, introdurre primitive di verifica generiche
L'EIP-8025 è stato progettato per la statelessness (assenza di stato) di Ethereum L1, introducendo un'infrastruttura di verifica delle prove zkVM nel layer di consenso (CL). Tuttavia, il design iniziale era troppo "egoistico", servendo solo la verifica del carico utile di esecuzione specifico della mainnet di Ethereum.
L'astuzia della nuova proposta è: poiché il layer di consenso ha già un motore di prove, protocolli di broadcast e logiche di verifica, perché non aprirlo a tutti i contratti intelligenti?
Questa proposta realizza questo obiettivo attraverso due modifiche centrali:
Generalizzazione completa del motore di verifica del layer di consenso (CL)
Proponiamo di separare la parte legata alla logica specifica di Ethereum nell'EIP-8025, rendendo l'infrastruttura di verifica della prova sottostante "indipendente dal programma (Program-agnostic)".
Il nuovo contenitore di prove è stato suddiviso in due dimensioni chiave:
Identificativo del backend (Backend Type): serve a indicare al layer di consenso quale sistema di prova di base utilizzare (ad esempio, un particolare zkVM).
Hash del programma (Program Hash): serve a identificare univocamente il programma cliente specifico in esecuzione.
In questo modo, il motore di verifica del layer di consenso funziona come una "presa" universale; qualsiasi Rollup, anche i protocolli di privacy e i processori ZK, può connettersi a questa rete di verifica, fornendo il corretto "spina (backend identifier e hash del programma)".
2. Nuovo "Proof-carrying Transaction"
Per consentire ai contratti intelligenti a livello applicativo di percepire e utilizzare i risultati di verifica del layer di consenso, la proposta introduce un nuovo tipo di transazione e tre nuovi codici operativi (Opcode) di supporto:
Trasformazione a livello di transazione: il nuovo corpo della transazione include un elenco di prove aggiuntive (che registrano l'hash del programma e il tipo di backend) e un hash di output pubblico.
Alleggerimento a livello di contratto intelligente: la proposta ha aggiunto tre opcode che non richiedono calcoli crittografici complessi (rispettivamente per leggere l'hash del programma, l'hash dell'output pubblico e il numero di prove).
Ristrutturazione del flusso di lavoro: quando questa transazione che porta prove si diffonde nel mempool, i nodi di rete e i costruttori di blocchi saranno responsabili dell'esecuzione della pesante verifica matematica alla base. Una volta che la transazione viene impacchettata in un blocco, il contratto intelligente deve solo chiamare i nuovi opcode sopra menzionati per convalidare "leggermente" se la prova è valida o meno.
Tre, salto di paradigma: "rilascio del client" sostituisce la "governance on-chain"
L'introduzione di questo meccanismo porterà a un cambiamento architettonico fondamentale.
In passato, se la libreria di base zkVM utilizzata da un Rollup presentava vulnerabilità di sicurezza, il team del Rollup doveva affrettarsi a lanciare una proposta e seguire il processo di governance on-chain per aggiornare il contratto di verifica su L1.
Nella "verifica nativa delle prove", tutto il pesante lavoro di verifica è stato scaricato nel software client di Ethereum L1 (ad esempio Geth, Nethermind, ecc.). Quando la zkVM di base deve essere riparata, il team di sviluppo del client di Ethereum deve solo rilasciare una nuova versione del software. Dopo l'aggiornamento del software del nodo Ethereum, i bug vengono naturalmente risolti.
È come se il sistema operativo aggiornasse le patch di sicurezza di base, tutto il software in esecuzione ne trarrebbe automaticamente beneficio, senza che ogni sviluppatore di software debba riscrivere il proprio codice. I Rollup realizzano davvero l'eredità del meccanismo di aggiornamento della sicurezza di Ethereum L1.
Quattro, impatto profondo sulla corsa L2
Secondo le stime approssimative nella proposta, se si adotta questo meccanismo nativo, i principali Rollup attuali (inclusi quelli basati su WASM o MIPS per l'espansione ottimistica, e quelli basati su vari zkVM per l'espansione di validità) potranno eliminare tra il 20% e il 50% del codice di logica core on-chain.
Una volta che le complessità della pila di verificatori da migliaia di righe saranno ridotte a un semplice contratto di "inbox", questo contratto dovrà solo utilizzare i nuovi opcode per verificare se il numero di prove soddisfa i requisiti e se l'hash del programma è nella propria whitelist per completare la conferma.
Allo stesso tempo, questo meccanismo risolve elegantemente il problema della "multi-proof". Le prove di backend diverse possono essere impacchettate a livello di transazione e verificate in parallelo, senza che i contratti intelligenti debbano più scrivere codice "a spaghetti" per coordinare più sistemi di prova.
Conclusione; dalla "catena on-chain personalizzata" che combatte ognuna per conto proprio, verso primitive "native del layer di consenso" unificate, questo è il percorso inevitabile per la maturità e la modularità dell'ecosistema Ethereum.
Sebbene questa proposta necessiti ancora di ulteriori discussioni su dettagli come la "garanzia di stabilità dell'hash del programma (cioè come eseguire la manutenzione del codice di base in modo ordinario senza cambiare l'identificativo on-chain)", la direzione indicata — rendere i Rollup più leggeri, sicuri e strettamente legati al consenso di base di Ethereum L1 — offre senza dubbio una soluzione futuristica e immaginativa per il percorso di espansione bloccato nella governance e nell'ingombro del codice.
⚠️ 【Disclaimer】Il contenuto di questo articolo è solo una divulgazione delle tecnologie di base e dei modelli economici, non costituisce alcun consiglio di investimento. I dati provengono da fonti online. Il trading di derivati cripto comporta rischi elevati, valuta sempre la tua capacità di tolleranza al rischio e prendi decisioni con cautela.
🌹 Se ti è piaciuto questo approfondimento, sentiti libero di mettere un like, seguire, commentare e condividere! Il tuo supporto è la nostra massima motivazione per continuare a produrre contenuti.
