Co-fondatorul Scroll, Zhang Ye, a vorbit despre patru părți. În prima parte, Zhang Ye a prezentat contextul de dezvoltare și de ce avem nevoie de zkEVM și de ce a devenit atât de popular în ultimii doi ani a explicat cum, printr-un proces complet, construirea zkEVM de la zero include sisteme aritmetice și de demonstrare. Cea de-a treia parte vorbește despre problemele întâmpinate de Scroll prin intermediul unor întrebări de cercetare interesante și, în final, prezintă alte aplicații care utilizează zkEVM.
Blockchain-ul tradițional Layer 1 va avea câteva noduri menținute împreună prin rețeaua P2P. Când primesc tranzacția utilizatorului, o vor executa în mașina virtuală EVM, vor citi contractul de apelare și stocarea și vor actualiza arborele de stare global în funcție de tranzacție.
Avantajul unei astfel de arhitecturi este descentralizarea și securitatea. Dezavantajul este că taxele de tranzacție pe L1 sunt scumpe, iar confirmarea tranzacției este lentă.
În arhitectura ZK-Rollup, rețeaua L2 trebuie doar să încarce datele și dovezile pentru a verifica corectitudinea datelor în L1, unde dovezile sunt calculate printr-un circuit de verificare cu zero cunoștințe.
La începutul ZK-Rollup, circuitul a fost proiectat pentru aplicații specifice Utilizatorii trebuiau să trimită tranzacții către diferiți doveditori, iar apoi ZK-Rollup-urile diferitelor aplicații și-au trimis propriile date și dovezi la L1. Problema pe care aceasta o aduce este că se pierde compozibilitatea contractului original L1.
Ceea ce face Scroll este o soluție nativă zkEVM, care este un ZK-Rollup de uz general. Acest lucru nu este doar mai ușor de utilizat, dar oferă și dezvoltatorilor o experiență de dezvoltare mai bună pe L1. Desigur, dezvoltarea din spatele acestui lucru este foarte dificilă, iar costul generației actuale de probe este, de asemenea, foarte mare.
Din fericire, eficiența dovezilor cu cunoștințe zero s-a îmbunătățit semnificativ în ultimii doi ani, motiv pentru care zkEVM a devenit atât de popular în ultimii doi ani. Există cel puțin patru motive pentru care devine fezabilă. dovadă, în al doilea rând, apariția tabelelor de căutare și a porților personalizate poate susține proiecte mai flexibile și poate face dovezile mai eficiente; A patra În cadrul demonstrației recursive, dovezile multiple pot fi comprimate într-o singură demonstrație, făcând dovada mai mică și mai ușor de verificat. Deci, combinând acești patru factori, eficiența de generare a dovezilor cu cunoștințe zero este cu trei ordine de mărime mai mare decât acum doi ani, ceea ce este și originea Scoll.
Conform definiției lui Justin Drake, zkEVM poate fi împărțit în trei categorii. Prima categorie este compatibilitatea la nivel de limbaj. multe cheltuieli suplimentare. Prin urmare, companii precum Starkware și zkSync aleg să compileze Solidity sau Yul în compilatoare ZK-friendly la nivel de limbă.
Al doilea tip este compatibilitatea la nivel de bytecode pe care Scroll o face, care demonstrează direct dacă procesarea bytecode a EVM-ului este corectă sau nu și moștenește direct mediul de execuție al Ethereum. Unele compromisuri care pot fi făcute aici sunt utilizarea unei rădăcini de stare diferită de EVM, cum ar fi utilizarea unei structuri de date prietenoase cu ZK. Hermez și Consensys fac ceva similar.
A treia categorie este compatibilitatea la nivel de consens, compromisul aici este că nu este doar necesar să păstrați EVM-ul neschimbat, ci și să includeți structura de stocare pentru a obține compatibilitatea deplină cu Ethereum, cu prețul unui timp de probă mai lung. Scroll este construit în cooperare cu echipa PSE a Fundației Ethereum pentru a realiza ZKization Ethereum.
În a doua parte, Zhang Ye le-a arătat tuturor cum să construiască ZKVM de la zero.
Proces complet
În primul rând, în partea frontală a ZKP, trebuie să vă exprimați calculele prin aritmetică matematică. Cele mai frecvent utilizate sunt R1CS liniar, precum și Plonkish și AIR. După obținerea constrângerilor prin aritmetică, trebuie să rulați algoritmul de demonstrare pe backend-ul ZKP pentru a dovedi corectitudinea calculului Iată cele mai utilizate dovezi polinomiale interactive (IOP) și schema de angajament polinomial (PCS).
Aici trebuie să demonstrăm că zkEVM și Scroll folosesc o combinație de Plonkish, Plonk IOP și KZG.
Pentru a înțelege de ce folosim aceste trei soluții. Începem mai întâi cu cel mai simplu R1CS Constrângerea din R1CS este că combinația liniară cu combinația liniară este egală cu combinația liniară. Puteți adăuga orice combinație liniară de variabile fără costuri suplimentare, dar ordinea maximă în fiecare constrângere este 2. Prin urmare, pentru operațiunile de ordin superior, sunt necesare mai multe constrângeri.
În Plonkish, trebuie să completați toate variabilele în tabel, inclusiv intrările, ieșirile și martorii pentru variabilele intermediare. Pe lângă aceasta, puteți defini diferite constrângeri. Există trei tipuri de constrângeri disponibile în Plonkish.
Primul tip de constrângere este o poartă personalizată. Puteți defini relații de constrângeri polinomiale între diferite celule, cum ar fi va3 * vb3 * vc3 - vb4 =0. În comparație cu R1CS, ordinea poate fi mai mare, deoarece puteți defini constrângeri pentru orice variabilă și puteți defini unele constrângeri foarte diferite.
Al doilea tip de constrângere este Permuarea sau verificările de egalitate. Poate fi folosit pentru a verifica echivalența diferitelor celule și este adesea folosit pentru a asocia diferite porți într-un circuit, cum ar fi demonstrarea faptului că ieșirea porții anterioare este egală cu intrarea următoarei porți.
Ultimul tip de constrângere este un tabel de căutare. Putem înțelege tabelul de căutare ca o relație între variabile, care poate fi exprimată ca un tabel. De exemplu, dorim să demonstrăm că vc7 se află în intervalul 0-15 În R1CS, trebuie mai întâi să descompuneți această valoare într-un binar de 4 biți, apoi să demonstrați că fiecare bit este în intervalul 0-1. va necesita patru constrângeri. În Plonkish, puteți enumera toate intervalele posibile în aceeași coloană și trebuie doar să dovediți că vc7 aparține acelei coloane. Acest lucru este foarte eficient pentru dovezile de intervale. În zkEVM, tabelele de căutare sunt foarte utile pentru a dovedi citirile și scrierile din memorie.
Pentru a rezuma, Plonkish acceptă, de asemenea, porți personalizate, verificări de echivalență și tabele de căutare, care pot fi foarte flexibile pentru a răspunde nevoilor diferitelor circuite. O comparație simplă a STARK Fiecare rând din STARK este o constrângere.
Întrebarea acum este cum alegem front-end-ul în zkEVM. Există patru provocări principale pentru zkEVM. Prima provocare este că câmpul EVM este de 256 de biți, ceea ce înseamnă că variabilele trebuie să fie limitate în mod eficient, a doua provocare este că EVM are multe coduri operaționale neprietenoase cu ZK, deci sunt necesare constrângeri la scară foarte mare pentru a demonstra aceste operații; , cum ar fi Keccak-256, a treia provocare este problema de citire și scriere a memoriei, aveți nevoie de o mapare eficientă pentru a demonstra că ceea ce ați citit este în concordanță cu ceea ce ați scris înainte; se schimbă dinamic, așa că avem nevoie de porți personalizate pentru a se adapta la diferite urme de execuție. Am ales Plonkish pentru considerentele de mai sus.
În continuare, să ne uităm la procesul complet al zkEVM Pe baza arborelui de stare globală inițial, după ce apare o nouă tranzacție, EVM va citi bytecode-ul contractelor stocate și apelate și va genera urmele de execuție corespunzătoare pe baza tranzacției, cum ar fi. PUSH, PUSH , STORE, CALLVALUE și apoi actualizați treptat starea globală pentru a obține arborele de stare global după tranzacție. zkEVM ia ca intrare arborele de stare global inițial, tranzacția în sine și arborele de stare global după tranzacție și folosește specificația EVM pentru a dovedi corectitudinea urmăririi execuției.
Aprofundând în detaliile circuitului EVM, fiecare pas al urmei de execuție are constrângerile de circuit corespunzătoare. În mod specific, constrângerile de circuit ale fiecărui pas includ Step Context, Case Switch și Opcode Specific Witness. Contextul de pas conține codul de cod, gazul rămas și contorul corespunzător urmei de execuție Case Switch conține toate codurile operaționale, toate condițiile de eroare, iar operațiunile corespunzătoare ale pasului Opcode Specific Witness conține martori suplimentari solicitați de codul operațional, cum ar fi operanzii wait;
Luând ca exemplu adăugarea simplă, trebuie să vă asigurați că variabila de control sADD a codului operațional de adăugare este setată la 1, iar variabilele de control ale altor coduri operaționale sunt toate zero. În contextul de pas, gazul consumat este constrâns să fie egal cu 3 prin setarea gaz' - gaz - 3 = 0. În mod similar, indicatorul de stivă acumulează 1 după pasul variabilele sunt controlate la 1 prin opcode Pentru a constrânge acest pas să fie o operație de adăugare în Opcode Specific Witness, constrângeți adăugarea efectivă a operanzilor.
În plus, sunt necesare constrângeri suplimentare de circuit pentru a asigura corectitudinea operanzilor citiți din memorie. Aici trebuie mai întâi să construim un tabel de căutare pentru a demonstra că operandul aparține memoriei. Și verificați corectitudinea tabelului de memorie prin circuitul de memorie (circuit RAM).
Aceeași metodă poate fi aplicată funcțiilor hash neprietenoase pentru zk. Construiți o tabelă de căutare a funcției hash, mapați intrarea și ieșirea hash în urma de execuție și utilizați un circuit hash suplimentar pentru a verifica funcția hash corectitudinea tabelului de căutare.
Acum să ne uităm la arhitectura circuitului zkEVM. Circuitul EVM de bază este utilizat pentru a constrânge corectitudinea fiecărui pas al urmării de execuție. Table, RAM Table, Bytecode, Transaction, Block Context și apoi utilizați circuite separate pentru a constrânge aceste tabele de căutare, cum ar fi circuitele Keccak pentru a constrânge tabelele Keccak.
Pentru a rezuma, fluxul de lucru complet al zkEVM este prezentat în figura de mai jos.
sistem de probă
Deoarece verificarea directă a circuitelor EVM, a circuitelor de memorie, a circuitelor de stocare etc. menționate mai sus pe L1 este costisitoare, sistemul Scroll proof adoptă o arhitectură cu două straturi.
Primul strat este responsabil pentru demonstrarea directă a EVM în sine, necesitând o cantitate mare de calcul pentru a genera demonstrația. Prin urmare, sistemul de verificare de prim nivel este necesar pentru a susține porți personalizate și tabele de căutare, să fie prietenos cu accelerarea hardware, să genereze calcule în paralel în memoria de vârf scăzut și să aibă un circuit mic de verificare care poate fi verificat rapid. Alternativele promițătoare includ Plonky2, Starky și eSTARK. Toate folosesc practic Plonk pe partea din față, dar pot folosi FRI pe partea din spate și toate îndeplinesc cele patru caracteristici de mai sus. Un alt tip de soluții alternative includ Halo2 dezvoltat de Zcash și versiunea KZG a Halo2.
Există, de asemenea, câteva sisteme noi de dovezi care sunt promițătoare, cum ar fi HyperPlonk, care a eliminat recent FFT, iar sistemul de dovezi NOVA poate realiza dovezi recursive mai mici. Dar susțin R1CS doar în cercetare Dacă îl pot sprijini pe Plonkish în viitor și îl pot aplica în practică, va fi foarte practic și eficient.
Sistemul de verificare de nivel al doilea este utilizat pentru a dovedi corectitudinea probei de primul nivel și trebuie verificat eficient în EVM. În mod ideal, ar trebui să fie prietenos cu accelerarea hardware și să suporte o configurare transparentă sau universală. Alternativele promițătoare includ Groth16 și sistemul de verificare Plonkish fără coloane. Groth16 este încă un reprezentant al eficienței de verificare extrem de ridicată în cercetarea curentă, iar sistemul de verificare Plonkish poate, de asemenea, obține o eficiență ridicată a probei chiar și cu un număr mic de coloane.
La Scroll, folosim sistemul de verificare Halo2-KZG în ambele sisteme de verificare cu două straturi. Deoarece Halo2-KZG poate suporta porți personalizate și tabele de căutare, funcționează bine sub accelerarea hardware GPU, iar circuitul de verificare este de dimensiuni reduse și poate fi verificat rapid. Diferența este că folosim hashingul Poseidon în sistemul de verificare a primului strat pentru a îmbunătăți și mai mult eficiența probei, în timp ce sistemul de testare al doilea strat folosește în continuare hashing Keccak, deoarece este verificat direct pe Ethereum. Scroll explorează, de asemenea, posibilitatea unui sistem de dovezi cu mai multe straturi pentru a agrega în continuare dovezile agregate generate de sistemul de dovezi de al doilea nivel.
În cadrul implementării actuale, circuitul EVM al sistemului de verificare de prim nivel al Scroll are 116 coloane, 2496 de porți personalizate, 50 de tabele de căutare, cea mai mare ordine este de 9 și necesită 2^18 linii sub 1M Gas, în timp ce sistemul de dovadă de al doilea nivel are The circuitul de agregare are doar 23 de coloane, 1 poartă personalizată, 7 tabele de căutare, iar cea mai mare ordine este 5. Pentru a agrega circuitul EVM, circuitul de memorie și circuitul de stocare, sunt necesare 2^25 de rânduri.
Scroll a făcut, de asemenea, o mulțime de lucrări de cercetare și optimizare privind accelerarea hardware GPU Pentru circuitele EVM, proba GPU optimizat durează doar 30 de secunde, ceea ce este de 9 ori mai eficient decât probatorul CPU, numai după optimizare durează 149 de secunde, ceea ce este de 15 ori mai eficient decât procesorul. În condițiile actuale de optimizare, sistemul de testare de la primul nivel 1M Gas durează aproximativ 2 minute, iar sistemul de testare de al doilea nivel durează aproximativ 3 minute.
În cea de-a treia parte, Zhang Ye a vorbit despre câteva probleme de cercetare interesante în procesul Scroll de construire a zkEVM, de la circuitul aritmetic front-end până la implementarea probei.
circuit
Prima este caracterul aleatoriu din circuit Deoarece câmpul EVM este de 256 de biți, trebuie să-l împărțim în câmpuri de 32 de biți pentru a efectua o dovadă a intervalului mai eficient. Apoi folosim metoda Combinației liniare aleatoare (RLC) pentru a codifica 32 de câmpuri în 1 folosind numere aleatoare. Trebuie doar să verificăm acest câmp pentru a verifica câmpul original de 256 de biți. Dar problema este că numărul aleatoriu trebuie generat după împărțirea câmpurilor pentru a se asigura că nu este manipulat. Prin urmare, Scroll și echipa PSE au propus o soluție de testare în mai multe etape pentru a se asigura că, după împărțirea câmpului, sunt utilizate numere aleatorii pentru a genera RLC. Această soluție este încapsulată în API-ul Challenge. RLC are multe scenarii de aplicație în zkEVM Nu numai că poate comprima câmpul EVM într-un singur câmp, ci și poate cripta intrarea de lungime variabilă sau poate optimiza aspectul tabelului de căutare. Cu toate acestea, există încă multe probleme care trebuie rezolvate.
O a doua întrebare interesantă de cercetare în circuite este aspectul circuitului. Motivul pentru care front-end-ul Scroll folosește Plonkish este că urma de execuție a EVM se modifică dinamic și trebuie să poată suporta diferite constrângeri și teste de echivalență în schimbare, în timp ce poarta standardizată a R1CS necesită o scară de circuit mai mare pentru implementare. Cu toate acestea, Scroll utilizează în prezent peste 2.000 de porți personalizate pentru a îndeplini urmele de execuție în schimbare dinamică și explorează, de asemenea, cum să optimizeze în continuare aspectul circuitului, inclusiv împărțirea Opcode în Micro Opcode sau reutilizarea celulelor din același tabel.
O a treia întrebare interesantă de cercetare în circuite este scalarea dinamică. Deoarece scara circuitului a diferitelor coduri operaționale este diferită, dar pentru a îndeplini urmele de execuție care se schimbă dinamic, codul operațional al fiecărui pas trebuie să îndeplinească scara maximă a circuitului, cum ar fi hashingul Keccak, așa că plătim de fapt o suprasarcină suplimentară. Presupunând că putem face zkEVM să se adapteze dinamic la urmele de execuție care se schimbă în mod dinamic, acest lucru va economisi costuri suplimentare inutile.
doveditor
În ceea ce privește probatori, Scroll a făcut o mulțime de optimizări pentru MSM și NTT în ceea ce privește accelerarea GPU-ului, dar acum blocajul s-a mutat la generarea de martori și copierea datelor. Deoarece se presupune că MSM și NTT ocupă 80% din timpul de probă, chiar dacă accelerarea hardware poate îmbunătăți această eficiență cu câteva ordine de mărime, timpul inițial de probă de 20% de generare și copiere a datelor va deveni un nou blocaj. O altă problemă cu probatorul este că necesită multă memorie, așa că trebuie explorate soluții hardware mai ieftine și mai descentralizate.
În același timp, Scroll explorează, de asemenea, accelerarea hardware și algoritmi de demonstrare pentru a îmbunătăți eficiența probelor. În prezent, există două direcții principale, fie trecerea la un domeniu mai mic, cum ar fi utilizarea domeniului Goldilocks pe 64 de biți, Mersenne Prime pe 32 de biți etc., fie aderarea la un nou sistem de verificare bazat pe curbe eliptice (EC, de exemplu, SuperNova). . Desigur, există și alte căi posibile, iar prietenii cu idei sunt bineveniți să contacteze direct Scroll.
Siguranță
Când construiți zkEVM, securitatea este primordială. ZkEVM construit în comun de PSE și Scroll are aproximativ 34.000 de linii de cod Din perspectiva ingineriei software, este imposibil ca aceste baze de cod complexe să fie lipsite de vulnerabilități pentru o lungă perioadă de timp. Scroll examinează în prezent baza de coduri zkEVM printr-un număr mare de audituri, inclusiv de la cele mai importante firme de audit din industrie.
Partea 4 explorează alte aplicații care folosesc zkEVM.
În arhitectura zkRollup, verificăm că n tranzacții pe L2 sunt valide prin contractul inteligent pe L1.
Dacă verificăm direct blocul L1, atunci nodul L1 nu trebuie să execute în mod repetat tranzacția, ci trebuie doar să verifice valabilitatea fiecărui certificat de bloc. O astfel de soluție arhitecturală se numește Enshrine Blockchain. În prezent, este foarte dificil de implementat direct pe Ethereum deoarece trebuie verificat întregul bloc Ethereum, ceea ce va include verificarea unui număr mare de semnături, rezultând un timp de verificare mai lung și o securitate mai scăzută. Desigur, există deja alte lanțuri publice care folosesc dovezi recursive pentru a verifica întregul blockchain folosind o singură dovadă, cum ar fi Mina.
Deoarece zkEVM poate dovedi tranzițiile de stat, poate fi folosit și de pălăriile albe pentru a demonstra că cunosc vulnerabilitățile anumitor contracte inteligente și că caută recompense de la părțile din proiect.
Ultimul caz de utilizare este de a dovedi afirmațiile despre datele istorice prin dovezi de cunoștințe zero și de a le folosi ca un oracol Axiom produce în prezent produse în acest domeniu. La recentul Hackathon ETHBeijing, echipa GasLockR a profitat de această caracteristică pentru a demonstra costul istoric al gazului.
În cele din urmă, Scroll construiește soluția de scalare universală a zkRollup pentru Ethereum, folosind circuite aritmetice și sisteme de dovezi foarte avansate și construiește verificatoare rapide prin accelerarea hardware pentru a demonstra recursiunea. În prezent, rețeaua de testare Alpha este online și funcționează stabil de mult timp.
Desigur, mai sunt câteva probleme interesante care trebuie rezolvate, inclusiv proiectarea protocolului și proiectarea mecanismelor, ingineria fără cunoștințe și eficiența reală. Toată lumea este binevenită să se alăture Scroll pentru a construi împreună!
