Il cofondatore di Scroll, Zhang Ye, ha parlato di quattro parti. Nella prima parte, Zhang Ye ha introdotto il background dello sviluppo e in primo luogo il motivo per cui abbiamo bisogno di zkEVM e, nella seconda parte, il motivo per cui è diventato così popolare ha spiegato come, attraverso un processo completo, la creazione di zkEVM da zero include sistemi aritmetici e di prova. La terza parte parla dei problemi incontrati durante la creazione di zkEVM attraverso alcune interessanti domande di ricerca e infine introduce alcune altre applicazioni che utilizzano zkEVM.
La tradizionale blockchain di livello 1 avrà alcuni nodi mantenuti insieme attraverso la rete P2P. Quando ricevono la transazione dell'utente, la eseguiranno nella macchina virtuale EVM, leggeranno il contratto di chiamata e l'archiviazione e aggiorneranno l'albero dello stato globale in base alla transazione.
Il vantaggio di tale architettura è la decentralizzazione e la sicurezza. Lo svantaggio è che le commissioni di transazione su L1 sono costose e la conferma della transazione è lenta.
Nell'architettura ZK-Rollup, la rete L2 deve solo caricare i dati e la prova per verificare la correttezza dei dati su L1, dove la prova viene calcolata attraverso un circuito di prova a conoscenza zero.
Nei primi ZK-Rollup, il circuito era progettato per applicazioni specifiche. Gli utenti dovevano inviare transazioni a diversi prover, quindi ZK-Rollup di diverse applicazioni inviavano i propri dati e prove a L1. Il problema che ciò comporta è che si perde la componibilità del contratto L1 originale.
Ciò che fa Scroll è una soluzione zkEVM nativa, ovvero uno ZK-Rollup generico. Questo non solo è più user-friendly, ma offre anche agli sviluppatori una migliore esperienza di sviluppo su L1. Naturalmente, lo sviluppo alla base di tutto ciò è molto difficile e anche il costo dell’attuale generazione di prove è molto elevato.
Fortunatamente, l’efficienza delle dimostrazioni a conoscenza zero è migliorata in modo significativo negli ultimi due anni, motivo per cui zkEVM è diventato così popolare negli ultimi due anni. Ci sono almeno quattro ragioni per cui ciò diventa fattibile. Il primo è l’emergere dell’impegno polinomiale. Sotto il sistema di prova originale di Groth16, la scala dei vincoli era molto ampia, ma l’impegno polinomiale può supportare vincoli di ordine superiore e ridurre la scala dell’impegno. prova; in secondo luogo, l'emergere di tabelle di ricerca e porte personalizzate può supportare progetti più flessibili e rendere le prove più efficienti; il terzo riguarda innovazioni nell'accelerazione hardware, che possono ridurre i tempi di prova di 1-2 ordini di grandezza tramite GPU, FPGA e ASIC; Il quarto Nella dimostrazione ricorsiva, più dimostrazioni possono essere compresse in una dimostrazione, rendendo la dimostrazione più piccola e più facile da verificare. Quindi, combinando questi quattro fattori, l’efficienza di generazione delle dimostrazioni a conoscenza zero è tre ordini di grandezza superiore rispetto a due anni fa, il che è anche l’origine di Scoll.
Secondo la definizione di Justin Drake, zkEVM può essere suddiviso in tre categorie La prima categoria è la compatibilità a livello di lingua. Il motivo principale è che EVM non è progettato per ZK e ha molti codici operativi che non sono compatibili con ZK, quindi causerà un problema. molte spese generali aggiuntive. Pertanto, aziende come Starkware e zkSync scelgono di compilare Solidity o Yul in compilatori compatibili con ZK a livello di linguaggio.
Il secondo tipo è la compatibilità a livello di bytecode eseguita da Scroll, che dimostra direttamente se l'elaborazione del bytecode di EVM è corretta o meno ed eredita direttamente l'ambiente di esecuzione di Ethereum. Alcuni compromessi che possono essere fatti qui consistono nell'utilizzare una root di stato diversa rispetto all'EVM, come l'utilizzo di una struttura dati compatibile con ZK. Hermez e Consensys stanno facendo qualcosa di simile.
La terza categoria è la compatibilità a livello di consenso. Il compromesso qui è che non solo è necessario mantenere l’EVM invariato, ma includere anche la struttura di archiviazione per ottenere la piena compatibilità con Ethereum, a scapito di tempi di prova più lunghi. Scroll è stato costruito in collaborazione con il team PSE della Ethereum Foundation per realizzare la ZKizzazione di Ethereum.
Nella seconda parte, Zhang Ye ha mostrato a tutti come costruire ZKVM da zero.
Processo completo
Prima di tutto, nella parte front-end di ZKP, devi esprimere i tuoi calcoli attraverso l'aritmetica matematica. Quelli più comunemente usati sono R1CS lineare, così come Plonkish e AIR. Dopo aver ottenuto i vincoli tramite l'aritmetica, è necessario eseguire l'algoritmo di prova sul backend di ZKP per dimostrare la correttezza del calcolo. Ecco le prove oracolari interattive polinomiali (Polynomial IOP) e lo schema di impegno polinomiale (PCS) più comunemente utilizzati.
Qui dobbiamo dimostrare che zkEVM e Scroll utilizzano una combinazione di Plonkish, Plonk IOP e KZG.
Per capire perché utilizziamo queste tre soluzioni. Iniziamo innanzitutto con il più semplice R1CS. Il vincolo in R1CS è che la combinazione lineare moltiplicata per la combinazione lineare è uguale alla combinazione lineare. È possibile aggiungere qualsiasi combinazione lineare di variabili senza costi aggiuntivi, ma l'ordine massimo in ciascun vincolo è 2. Pertanto, per le operazioni di ordine superiore, sono necessari più vincoli.
In Plonkish, devi inserire tutte le variabili nella tabella, inclusi input, output e testimoni per le variabili intermedie. Oltre a ciò, è possibile definire diversi vincoli. Ci sono tre tipi di vincoli disponibili in Plonkish.
Il primo tipo di vincolo è un cancello personalizzato. È possibile definire relazioni di vincolo polinomiale tra celle diverse, ad esempio va3 * vb3 * vc3 - vb4 =0. Rispetto a R1CS, l'ordine può essere più elevato poiché è possibile definire vincoli su qualsiasi variabile e alcuni vincoli molto diversi.
Il secondo tipo di vincolo è la Permuazione, o controlli di uguaglianza. Può essere utilizzato per verificare l'equivalenza di celle diverse e viene spesso utilizzato per associare porte diverse in un circuito, ad esempio per dimostrare che l'uscita della porta precedente è uguale all'ingresso della porta successiva.
L'ultimo tipo di vincolo è una tabella di ricerca. Possiamo intendere la tabella di ricerca come una relazione tra variabili, che può essere espressa come una tabella. Ad esempio, vogliamo dimostrare che vc7 è compreso nell'intervallo 0-15. In R1CS è necessario prima scomporre questo valore in un binario a 4 bit, quindi dimostrare che ciascun bit è compreso nell'intervallo 0-1. richiederà quattro vincoli. In Plonkish, puoi elencare tutti gli intervalli possibili nella stessa colonna e devi solo dimostrare che vc7 appartiene a quella colonna. Questo è molto efficiente per le prove degli intervalli. In zkEVM, le tabelle di ricerca sono molto utili per dimostrare le letture e le scritture della memoria.
Per riassumere, Plonkish supporta anche porte personalizzate, controlli di equivalenza e tabelle di ricerca, che possono essere molto flessibili per soddisfare le diverse esigenze dei circuiti. Un semplice confronto di STARK. Ogni riga in STARK è un vincolo. Il vincolo deve rappresentare la transizione di stato tra le righe, ma la flessibilità dei vincoli personalizzati in Plonkish è ovviamente maggiore.
La domanda ora è come scegliamo il front-end in zkEVM. Ci sono quattro sfide principali per zkEVM. La prima sfida è che il campo di EVM è di 256 bit, il che significa che le variabili devono essere limitate in modo efficiente nell'intervallo, la seconda sfida è che EVM ha molti codici operativi ostili a ZK, quindi sono necessari vincoli su larga scala per dimostrare queste operazioni; ., come Keccak-256; la terza sfida è il problema di lettura e scrittura della memoria, è necessaria una mappatura efficace per dimostrare che ciò che leggi è coerente con ciò che hai scritto prima; È Cambia dinamicamente, quindi dobbiamo personalizzare il cancello per adattarlo alle diverse tracce di esecuzione. Abbiamo scelto Plonkish per le considerazioni di cui sopra.
Successivamente, diamo un'occhiata al processo completo di zkEVM Sulla base dell'albero dello stato globale iniziale, dopo l'arrivo di una nuova transazione, EVM leggerà il bytecode dei contratti memorizzati e chiamati e genererà tracce di esecuzione corrispondenti in base alla transazione, come ad esempio. PUSH, PUSH , STORE, CALLVALUE, quindi aggiorna gradualmente lo stato globale per ottenere l'albero dello stato globale dopo la transazione. zkEVM prende come input l'albero dello stato globale iniziale, la transazione stessa e l'albero dello stato globale dopo la transazione e utilizza la specifica EVM per dimostrare la correttezza della traccia di esecuzione.
Approfondendo i dettagli del circuito EVM, ogni passo della traccia di esecuzione ha vincoli di circuito corrispondenti. Nello specifico, i vincoli del circuito di ogni passaggio includono Step Context, Case Switch e Opcode Specific Witness. Step Context contiene il codehash, il gas rimanente e il contatore corrispondente alla traccia di esecuzione; Case Switch contiene tutti gli opcode, tutte le condizioni di errore e le operazioni corrispondenti dello step Opcode Specific Witness contiene testimoni aggiuntivi richiesti dall'opcode, come l'attesa degli operandi;
Prendendo come esempio una semplice addizione, è necessario assicurarsi che la variabile di controllo sADD del codice operativo di addizione sia impostata su 1 e che le variabili di controllo degli altri codici operativi siano tutte zero. Nel contesto del passo, il gas consumato è vincolato a essere uguale a 3 impostando gas' - gas - 3 = 0. Allo stesso modo, il contatore è vincolato. Il puntatore dello stack accumula 1 dopo il passo nel caso Switch, la somma di le variabili sono controllate su 1 tramite l'opcode. Per vincolare questo passaggio ad essere un'operazione di addizione in Opcode Specific Witness, vincolare l'effettiva aggiunta di operandi;
Inoltre, sono necessari ulteriori vincoli circuitali per garantire la correttezza degli operandi letti dalla memoria. Qui dobbiamo prima costruire una tabella di ricerca per dimostrare che l'operando appartiene alla memoria. E verificare la correttezza della tabella di memoria attraverso il circuito di memoria (circuito RAM).
Lo stesso metodo può essere applicato a funzioni hash non compatibili con zk. Costruisci una tabella di ricerca della funzione hash, mappa l'input e l'output dell'hash nella traccia di esecuzione sulla tabella di ricerca e utilizza un circuito hash aggiuntivo per verificare la funzione hash la correttezza della tabella di ricerca.
Ora diamo un'occhiata all'architettura del circuito di zkEVM. Il circuito EVM principale viene utilizzato per vincolare la correttezza di ogni passaggio della traccia di esecuzione. In alcuni punti in cui i vincoli del circuito EVM sono difficili, utilizziamo le tabelle di ricerca per mappare, inclusa la tabella fissa, Keccak Tabella, Tabella RAM, Bytecode, Transazione, Contesto blocco, quindi utilizzare circuiti separati per vincolare queste tabelle di ricerca, ad esempio i circuiti Keccak per vincolare le tabelle Keccak.
Per riassumere, il flusso di lavoro completo di zkEVM è mostrato nella figura seguente.
sistema di prova
Poiché verificare direttamente i suddetti circuiti EVM, circuiti di memoria, circuiti di archiviazione, ecc. su L1 è costoso, il sistema di prova di Scroll adotta un'architettura a due livelli.
Il primo livello è responsabile della dimostrazione diretta dell’EVM stesso, richiedendo una grande quantità di calcoli per generare la prova. Pertanto, il sistema di prova di primo livello deve supportare porte personalizzate e tabelle di ricerca, essere favorevole all'accelerazione hardware, generare calcoli in parallelo con memoria a basso picco e avere un piccolo circuito di verifica che possa essere verificato rapidamente. Alternative promettenti includono Plonky2, Starky ed eSTARK. Fondamentalmente usano tutti Plonk sul front-end, ma possono usare FRI sul back-end e tutti soddisfano le quattro caratteristiche di cui sopra. Un altro tipo di soluzioni alternative includono Halo2 sviluppato da Zcash e la versione KZG di Halo2.
Ci sono anche alcuni nuovi sistemi di prova promettenti, come HyperPlonk, che ha recentemente rimosso la FFT, e il sistema di prova NOVA può ottenere dimostrazioni ricorsive più piccole. Ma supportano solo R1CS nella ricerca. Se potranno supportare Plonkish in futuro e applicarlo nella pratica, sarà molto pratico ed efficiente.
Il sistema di prova di secondo livello viene utilizzato per dimostrare la correttezza della prova di primo livello e deve essere verificato in modo efficiente nell'EVM. Idealmente, dovrebbe essere compatibile con l'accelerazione hardware e supportare una configurazione trasparente o universale. Alternative promettenti includono Groth16 e il sistema di prova Plonkish senza colonne. Groth16 è ancora un rappresentante di un'efficienza di prova estremamente elevata nella ricerca attuale, e il sistema di prova Plonkish può anche raggiungere un'efficienza di prova elevata anche con un numero limitato di colonne.
Noi di Scroll utilizziamo il sistema di prova Halo2-KZG in entrambi i nostri sistemi di prova a due strati. Poiché Halo2-KZG può supportare gate personalizzati e tabelle di ricerca, funziona bene con l'accelerazione hardware GPU e il circuito di verifica è di piccole dimensioni e può essere verificato rapidamente. La differenza è che utilizziamo l'hashing Poseidon nel sistema di prova di primo livello per migliorare ulteriormente l'efficienza della prova, mentre il sistema di prova di secondo livello utilizza ancora l'hashing Keccak perché è verificato direttamente su Ethereum. Scroll sta inoltre esplorando la possibilità di un sistema di prova multistrato per aggregare ulteriormente le prove aggregate generate dal sistema di prova di secondo livello.
Con l'attuale implementazione, il circuito EVM del sistema di prova di primo livello di Scroll ha 116 colonne, 2496 porte personalizzate, 50 tabelle di ricerca, l'ordine più alto è 9 e richiede 2 ^ 18 righe sotto 1M Gas mentre il sistema di prova di secondo livello ha The il circuito di aggregazione ha solo 23 colonne, 1 gate personalizzato, 7 tabelle di ricerca e l'ordine più alto è 5. Per aggregare il circuito EVM, il circuito di memoria e il circuito di archiviazione, sono necessarie 2 ^ 25 righe.
Scroll ha anche svolto molto lavoro di ricerca e ottimizzazione sull'accelerazione hardware della GPU. Per i circuiti EVM, il prover GPU ottimizzato impiega solo 30 secondi, che è 9 volte più efficiente del prover CPU Per i circuiti di aggregazione, dopo l'ottimizzazione solo del prover GPU impiega 149 secondi, ovvero 15 volte più efficiente della CPU. Nelle attuali condizioni di ottimizzazione, il sistema di prova di primo livello 1M Gas impiega circa 2 minuti e il sistema di prova di secondo livello impiega circa 3 minuti.
Nella terza parte, Zhang Ye ha parlato di alcuni interessanti temi di ricerca nel processo di costruzione di zkEVM da parte di Scroll, dal circuito aritmetico front-end all'implementazione del prover.
circuito
Il primo è la casualità nel circuito Poiché il campo EVM è di 256 bit, dobbiamo suddividerlo in 32 campi da 8 bit per eseguire la prova di intervallo in modo più efficiente. Quindi utilizziamo il metodo RLC (Random Linear Combination) per codificare 32 campi in 1 utilizzando numeri casuali. Dobbiamo solo verificare questo campo per verificare il campo originale a 256 bit. Ma il problema è che il numero casuale deve essere generato dopo aver suddiviso i campi per garantire che non venga manomesso. Pertanto, Scroll e il team PSE hanno proposto una soluzione di prova a più fasi per garantire che, dopo la suddivisione del campo, vengano utilizzati numeri casuali per generare RLC. Questa soluzione è incapsulata nell'API Challenge. RLC ha molti scenari applicativi in zkEVM. Non solo può comprimere il campo EVM in un campo, ma anche crittografare l'input di lunghezza variabile o ottimizzare il layout della tabella di ricerca. Tuttavia, ci sono ancora molti problemi aperti che devono essere risolti.
Una seconda domanda di ricerca interessante sui circuiti è il layout del circuito. Il motivo per cui il front-end Scroll utilizza Plonkish è perché la traccia di esecuzione di EVM cambia dinamicamente e deve essere in grado di supportare diversi vincoli e modificare i test di equivalenza, e il gate standardizzato di R1CS richiede una scala di circuito più ampia da implementare. Tuttavia, Scroll attualmente utilizza più di 2.000 porte personalizzate per soddisfare le tracce di esecuzione che cambiano dinamicamente e sta anche esplorando come ottimizzare ulteriormente il layout del circuito, inclusa la suddivisione di Opcode in Micro Opcode o il riutilizzo di celle nella stessa tabella.
Una terza interessante domanda di ricerca sui circuiti è il ridimensionamento dinamico. Poiché la scala del circuito dei diversi codici operativi è diversa, ma per soddisfare la traccia di esecuzione che cambia dinamicamente, il codice operativo di ogni passaggio deve soddisfare la scala massima del circuito, come l'hashing Keccak, quindi in realtà paghiamo un sovraccarico aggiuntivo. Supponendo di poter fare in modo che zkEVM si adatti dinamicamente alle tracce di esecuzione che cambiano dinamicamente, ciò consentirà di risparmiare inutili spese generali.
dimostratore
In termini di prover, Scroll ha apportato molte ottimizzazioni per MSM e NTT in termini di accelerazione GPU, ma ora il collo di bottiglia si è spostato per testimoniare la generazione e la copia dei dati. Poiché si presuppone che MSM e NTT occupino l'80% del tempo di prova, anche se l'accelerazione hardware può migliorare questa efficienza di diversi ordini di grandezza, il tempo di prova originale del 20% per la generazione e la copia dei dati diventerà un nuovo collo di bottiglia. Un altro problema con il dimostratore è che richiede molta memoria, quindi è necessario esplorare soluzioni hardware più economiche e decentralizzate.
Allo stesso tempo, Scroll sta anche esplorando l’accelerazione hardware e gli algoritmi di prova per migliorare l’efficienza dei dimostratori. Attualmente ci sono due direzioni principali, o passare a un dominio più piccolo, come utilizzare il dominio Goldilocks a 64 bit, Mersenne Prime a 32 bit, ecc., oppure attenersi a un nuovo sistema di prova basato su curve ellittiche (EC, ad esempio SuperNova). . Naturalmente ci sono altri percorsi possibili e gli amici con idee sono invitati a contattare direttamente Scroll.
sicurezza
Quando si crea zkEVM, la sicurezza è fondamentale. La zkEVM creata congiuntamente da PSE e Scroll contiene circa 34.000 righe di codice. Dal punto di vista dell'ingegneria del software, è impossibile che queste complesse basi di codice siano prive di vulnerabilità per un lungo periodo. Scroll sta attualmente esaminando la base di codice zkEVM attraverso un gran numero di audit, anche da parte delle principali società di revisione del settore.
La parte 4 esplora altre applicazioni che utilizzano zkEVM.
Nell'architettura zkRollup, verifichiamo che n transazioni su L2 siano valide attraverso lo smart contract su L1.
Se verifichiamo direttamente il blocco L1, allora il nodo L1 non avrà bisogno di eseguire ripetutamente la transazione, ma dovrà solo verificare la validità di ciascun certificato di blocco. Una soluzione architetturale di questo tipo si chiama Enshrine Blockchain. Attualmente, è molto difficile implementarlo direttamente su Ethereum perché è necessario verificare l'intero blocco Ethereum, il che include la verifica di un gran numero di firme, con conseguenti tempi di verifica più lunghi e minore sicurezza. Naturalmente, ci sono già altre catene pubbliche che utilizzano prove ricorsive per verificare l’intera blockchain utilizzando un’unica prova, come Mina.
Poiché zkEVM può dimostrare le transizioni di stato, può anche essere utilizzato dai cappelli bianchi per dimostrare di conoscere le vulnerabilità di alcuni contratti intelligenti e chiedere premi alle parti del progetto.
L'ultimo caso d'uso è dimostrare affermazioni sui dati storici attraverso prove a conoscenza zero e utilizzarle come oracolo. Axiom sta attualmente realizzando prodotti in quest'area. Al recente ETHBeijing Hackathon, il team GasLockR ha approfittato di questa funzionalità per dimostrare lo storico sovraccarico del Gas.
Infine, Scroll sta costruendo la soluzione di scalabilità universale di zkRollup per Ethereum, utilizzando circuiti aritmetici e sistemi di prova molto avanzati e costruendo verificatori veloci attraverso l'accelerazione hardware per dimostrare la ricorsione. Al momento, la rete di test Alpha è online e funziona stabilmente da molto tempo.
Naturalmente, ci sono ancora alcuni problemi interessanti che devono essere risolti, tra cui la progettazione del protocollo e del meccanismo, l'ingegneria a conoscenza zero e l'effettiva efficienza. Tutti sono invitati a unirsi a Scroll per costruire insieme!
