Scroll līdzdibinātājs Zhang Ye runāja par četrām daļām. Pirmajā daļā Zhang Ye iepazīstināja ar izstrādes fonu un to, kāpēc mums vispirms ir nepieciešams zkEVM un kāpēc tas ir kļuvis tik populārs pēdējo divu gadu laikā paskaidrots, kā pilnā procesā zkEVM izveidošana no nulles ietver aritmētiskās un pierādīšanas sistēmas. Trešajā daļā tiek runāts par problēmām, ar kurām sastopas, veidojot zkEVM, un, visbeidzot, tiek iepazīstinātas ar dažām citām lietojumprogrammām, izmantojot zkEVM.
Tradicionālajā 1. slāņa blokķēdē daži mezgli tiks uzturēti kopā, izmantojot P2P tīklu. Saņemot lietotāja darījumu, viņi to izpildīs EVM virtuālajā mašīnā, nolasīs zvanīšanas līgumu un krātuvi un atjauninās globālo stāvokļa koku atbilstoši darījumam.
Šādas arhitektūras priekšrocība ir decentralizācija un drošība. Trūkums ir tas, ka L1 transakciju maksas ir dārgas un darījumu apstiprināšana notiek lēni.
ZK-Rollup arhitektūrā L2 tīklam ir tikai jāaugšupielādē dati un pierādījums, lai pārbaudītu datu pareizību L1, kur pierādījums tiek aprēķināts, izmantojot nulles zināšanu pierādījumu ķēdi.
Agrīnā ZK-Rollup shēma bija paredzēta īpašām lietojumprogrammām, kas lietotājiem bija jānosūta darījumiem dažādiem pārbaudītājiem, un pēc tam dažādu lietojumprogrammu ZK-Rollups iesniedza savus datus un pierādījumus L1. Problēma, ko tas rada, ir tāda, ka tiek zaudēta sākotnējā L1 līguma saliekamība.
Scroll nodrošina vietējo zkEVM risinājumu, kas ir vispārējas nozīmes ZK-Rollup. Tas ir ne tikai lietotājam draudzīgāks, bet arī nodrošina izstrādātājiem labāku izstrādes pieredzi L1. Protams, attīstība aiz tā ir ļoti sarežģīta, un arī pašreizējās pierādījumu iegūšanas izmaksas ir ļoti augstas.
Par laimi, nulles zināšanu pierādījumu efektivitāte pēdējos divos gados ir ievērojami uzlabojusies, tāpēc zkEVM pēdējo divu gadu laikā ir kļuvis tik populārs. Ir vismaz četri iemesli, kāpēc tas ir iespējams. Pirmais ir polinoma saistību rašanās Saskaņā ar sākotnējo Groth16 ierobežojumu skala bija ļoti liela, bet polinoma saistības var atbalstīt augstākas pakāpes ierobežojumus un samazināt apmēru. otrkārt, uzmeklēšanas tabulu un pielāgotu vārtu rašanās var atbalstīt elastīgākus dizainus un padarīt pierādījumus efektīvākus, trešais ir sasniegums aparatūras paātrināšanā, kas var saīsināt pārbaudes laiku par 1–2 kārtībām, izmantojot GPU, FPGA un ASIC; Ceturtais Rekursīvajā pierādījumā vairākus pierādījumus var saspiest vienā pierādījumā, padarot pierādījumu mazāku un vieglāk pārbaudāmu. Tātad, apvienojot šos četrus faktorus, nulles zināšanu pierādījumu ģenerēšanas efektivitāte ir par trim kārtām augstāka nekā pirms diviem gadiem, kas arī ir Scoll izcelsme.
Saskaņā ar Džastina Dreika definīciju zkEVM var iedalīt trīs kategorijās. Pirmā kategorija ir valodas līmeņa saderība. Galvenais iemesls ir tas, ka EVM nav paredzēts ZK un tajā ir daudz opkodu, kas nav draudzīgi ZK. daudz papildu pieskaitāmu izmaksu. Tāpēc tādi uzņēmumi kā Starkware un zkSync izvēlas apkopot Solidity vai Yul ZK draudzīgos kompilatoros valodas līmenī.
Otrais veids ir baitkoda līmeņa saderība, ko veic Scroll, kas tieši pierāda, vai EVM baitkoda apstrāde ir pareiza vai nē, un tieši pārmanto Ethereum izpildes vidi. Daži kompromisi, ko šeit var izdarīt, ir izmantot citu stāvokļa sakni nekā EVM, piemēram, izmantojot ZK draudzīgu datu struktūru. Hermez un Consensys dara kaut ko līdzīgu.
Trešā kategorija ir saderība vienprātības līmenī. Kompromiss šeit ir tāds, ka ir nepieciešams ne tikai saglabāt EVM nemainīgu, bet arī iekļaut krātuves struktūru, lai panāktu pilnīgu saderību ar Ethereum, maksājot ilgāku pārbaudes laiku. Scroll tiek veidots sadarbībā ar Ethereum fonda PSE komandu, lai realizētu Ethereum ZKization.
Otrajā daļā Zhang Ye visiem parādīja, kā izveidot ZKVM no nulles.
Pabeigts process
Pirmkārt, ZKP priekšējā daļā aprēķini ir jāizsaka, izmantojot matemātisko aritmētiku. Visbiežāk izmantotie ir lineārais R1CS, kā arī Plonkish un AIR. Pēc ierobežojumu iegūšanas, izmantojot aritmētiku, jums ir jāpalaiž pierādīšanas algoritms ZKP aizmugurē, lai pierādītu aprēķina pareizību. Šeit ir visbiežāk izmantotie polinoma interaktīvie orākula pierādījumi (polinoma IOP) un polinomu saistību shēma (PCS).
Šeit mums jāpierāda, ka zkEVM un Scroll izmanto Plonkish, Plonk IOP un KZG kombināciju.
Lai saprastu, kāpēc mēs izmantojam šos trīs risinājumus. Vispirms mēs sākam ar vienkāršāko R1CS. R1CS ierobežojums ir tāds, ka lineārā kombinācija, kas reizināta ar lineāro kombināciju, ir vienāda ar lineāro kombināciju. Varat pievienot jebkuru lineāru mainīgo kombināciju bez papildu izmaksām, taču maksimālā secība katrā ierobežojumā ir 2. Tāpēc augstākas pakāpes operācijām ir nepieciešams vairāk ierobežojumu.
Plonkish valodā tabulā ir jāaizpilda visi mainīgie, tostarp starpposma mainīgo ievades, izvades un liecinieki. Papildus tam varat definēt dažādus ierobežojumus. Plonkish valodā ir pieejami trīs veidu ierobežojumi.
Pirmā veida ierobežojumi ir pielāgoti vārti. Varat definēt polinoma ierobežojumu attiecības starp dažādām šūnām, piemēram, va3 * vb3 * vc3 - vb4 =0. Salīdzinot ar R1CS, secība var būt augstāka, jo jūs varat definēt ierobežojumus jebkuram mainīgajam, un jūs varat definēt dažus ļoti dažādus ierobežojumus.
Otrs ierobežojumu veids ir permuācija jeb vienlīdzības pārbaudes. To var izmantot, lai pārbaudītu dažādu šūnu līdzvērtību, un to bieži izmanto, lai ķēdē saistītu dažādus vārtus, piemēram, lai pierādītu, ka iepriekšējo vārtu izeja ir vienāda ar nākamo vārtu ievadi.
Pēdējais ierobežojuma veids ir uzmeklēšanas tabula. Uzmeklēšanas tabulu var saprast kā attiecību starp mainīgajiem, ko var izteikt kā tabulu. Piemēram, mēs vēlamies pierādīt, ka vc7 ir diapazonā no 0 līdz 15 R1CS vispirms ir jāsadala šī vērtība 4 bitu binārā formā un pēc tam jāpierāda, ka katrs bits ir diapazonā no 0 līdz 1. būs nepieciešami četri ierobežojumi. Plonkish valodā varat uzskaitīt visus iespējamos diapazonus vienā un tajā pašā kolonnā, un tikai jāpierāda, ka vc7 pieder šai kolonnai. Tas ir ļoti efektīvs diapazona pierādīšanai.
Rezumējot, Plonkish atbalsta arī pielāgotus vārtus, līdzvērtības pārbaudes un uzmeklēšanas tabulas, kas var būt ļoti elastīgas, lai apmierinātu dažādas ķēdes vajadzības. Vienkāršs STARK salīdzinājums. Katra STARK rinda ir ierobežojums. Ierobežojumam ir jāatspoguļo stāvokļa pāreja starp rindām, taču pielāgoto ierobežojumu elastība ir acīmredzami lielāka.
Tagad jautājums ir par to, kā mēs izvēlamies zkEVM priekšējo daļu. ZkEVM ir četri galvenie izaicinājumi. Pirmais izaicinājums ir tas, ka EVM lauks ir 256 biti, kas nozīmē, ka mainīgie ir efektīvi jāierobežo diapazonā, otrs izaicinājums ir tas, ka EVM ir daudz ZK nedraudzīgu opkodu, tāpēc ir nepieciešami ļoti liela mēroga ierobežojumi, lai pierādītu šīs darbības; kods, piemēram, Keccak-256, ir atmiņas lasīšanas un rakstīšanas problēma, lai pierādītu, ka lasītais atbilst iepriekš rakstītajam ir dinamiski mainīgs, tāpēc mums ir nepieciešami pielāgoti vārti, lai pielāgotos dažādām izpildes trasēm. Iepriekš minēto apsvērumu dēļ mēs izvēlējāmies Plonkish.
Tālāk apskatīsim visu zkEVM procesu. Pamatojoties uz sākotnējo globālo stāvokļu koku, pēc jauna darījuma ienākšanas EVM nolasīs saglabāto un izsaukto līgumu baitu kodu un ģenerēs atbilstošas izpildes trases, pamatojoties uz darījumu, piemēram, piemēram. PUSH, PUSH , STORE, CALLVALUE un pēc tam pakāpeniski atjauniniet globālo stāvokli, lai pēc darījuma iegūtu globālo stāvokļa koku. zkEVM kā ievadi izmanto sākotnējo globālo stāvokļu koku, pašu darījumu un globālo stāvokļu koku pēc darījuma, un izmanto EVM specifikāciju, lai pierādītu izpildes trasēšanas pareizību.
Iedziļinoties EVM shēmas detaļās, katram izpildes trases posmam ir atbilstoši ķēdes ierobežojumi. Konkrēti, katra posma ķēdes ierobežojumi ietver soļa kontekstu, gadījuma slēdzi un opkoda specifisko liecinieku. Step Context satur codehash, atlikušo gāzi un skaitītāju, kas atbilst izpildes izsekojamībai. Case Switch satur visus operācijas kodus, visus kļūdas nosacījumus un atbilstošās darbības Opcode Specific Witness satur papildu lieciniekus, kas nepieciešami operācijas kodam, piemēram, gaidīšanas operandi.
Kā piemēru ņemot vienkāršu pievienošanu, jums ir jānodrošina, ka pievienošanas operācijas koda vadības mainīgais sADD ir iestatīts uz 1 un pārējo opkodu vadības mainīgie ir nulle. Soļa kontekstā patērētā gāze ir ierobežota, lai tā būtu vienāda ar 3, iestatot gāzi' - gāze - 3 = 0. Tāpat skaitītājs ir ierobežots pēc soļa Case Switch, summa mainīgie tiek kontrolēti līdz 1, izmantojot opcode, lai ierobežotu šo darbību kā pievienošanas operāciju programmā Opcode Specific Witness, ierobežojiet operandu faktisko pievienošanu.
Turklāt ir nepieciešami papildu ķēdes ierobežojumi, lai nodrošinātu operandu pareizību, kas tiek nolasīti no atmiņas. Šeit vispirms ir jāizveido uzmeklēšanas tabula, lai pierādītu, ka operands pieder atmiņai. Un pārbaudiet atmiņas tabulas pareizību, izmantojot atmiņas ķēdi (RAM ķēde).
To pašu metodi var izmantot zk nedraudzīgām jaucējfunkcijām. Izveidojiet jaucējfunkcijas uzmeklēšanas tabulu, kartējiet jaucēja ievadi un izvadi uz meklēšanas tabulu un izmantojiet papildu jaucējshēmu, lai pārbaudītu jaucējfunkciju uzmeklēšanas tabulas pareizība.
Tagad apskatīsim zkEVM shēmas arhitektūru. Galvenā EVM shēma tiek izmantota, lai ierobežotu katra izpildes trases posma pareizību. Dažās vietās, kur EVM ķēdes ierobežojumi ir sarežģīti, kartēšanai izmantojam uzmeklēšanas tabulas, tostarp Fixed Table, Keccak. Tabula, RAM tabula, baitkods, transakcija, bloķēšanas konteksts un pēc tam izmantojiet atsevišķas shēmas, lai ierobežotu šīs uzmeklēšanas tabulas, piemēram, Keccak shēmas, lai ierobežotu Keccak tabulas.
Apkopojot, visa zkEVM darbplūsma ir parādīta zemāk esošajā attēlā.
pierādījumu sistēma
Tā kā iepriekš minēto EVM ķēžu, atmiņas ķēžu, uzglabāšanas ķēžu utt. pārbaude L1 ir dārga, Scroll pārbaudes sistēma izmanto divu slāņu arhitektūru.
Pirmais slānis ir atbildīgs par paša EVM tiešu pierādīšanu, un pierādījuma ģenerēšanai ir nepieciešams liels aprēķinu apjoms. Tāpēc pirmā līmeņa pārbaudes sistēma ir nepieciešama, lai atbalstītu pielāgotus vārtus un uzmeklēšanas tabulas, būtu draudzīga aparatūras paātrinājumam, paralēli ģenerētu aprēķinus zemas maksimālās atmiņas režīmā un tai būtu neliela verifikācijas ķēde, ko var ātri pārbaudīt. Daudzsološas alternatīvas ir Plonky2, Starky un eSTARK. Tās visas pamatā izmanto Plonk priekšpusē, bet var izmantot FRI aizmugurē, un tās visas atbilst četrām iepriekš minētajām īpašībām. Cita veida alternatīvie risinājumi ietver Halo2, ko izstrādājis Zcash, un Halo2 KZG versiju.
Ir arī dažas jaunas, daudzsološas pārbaudes sistēmas, piemēram, HyperPlonk, kas nesen noņēma FFT, un NOVA pārbaudes sistēma var sasniegt mazākus rekursīvos pierādījumus. Bet viņi atbalsta tikai R1CS pētniecībā, ja viņi varēs atbalstīt Plonkish nākotnē un pielietot to praksē, tas būs ļoti praktiski un efektīvi.
Otrā līmeņa pārbaudes sistēma tiek izmantota, lai pierādītu pirmā līmeņa pārbaudes pareizību, un tā ir efektīvi jāpārbauda EVM. Ideālā gadījumā tai vajadzētu būt draudzīgai aparatūras paātrinājumam un atbalstīt caurspīdīgu vai universālu iestatījumu. Daudzsološas alternatīvas ir Groth16 un Plonkish proof sistēma bez kolonnām. Groth16 joprojām ir ārkārtīgi augstas pierādīšanas efektivitātes pārstāvis pašreizējos pētījumos, un Plonkish proof sistēma var arī sasniegt augstu pierādīšanas efektivitāti pat ar nelielu kolonnu skaitu.
Uzņēmumā Scroll mēs izmantojam Halo2-KZG proof sistēmu abās mūsu divslāņu pārbaudes sistēmās. Tā kā Halo2-KZG var atbalstīt pielāgotus vārtus un uzmeklēšanas tabulas, tas labi darbojas, izmantojot GPU aparatūras paātrinājumu, un verifikācijas ķēde ir maza, un to var ātri pārbaudīt. Atšķirība ir tāda, ka mēs izmantojam Poseidon jaukšanu pirmā slāņa pārbaudes sistēmā, lai vēl vairāk uzlabotu pārbaudes efektivitāti, savukārt otrā slāņa pārbaudes sistēmā joprojām tiek izmantota Keccak jaukšana, jo tā tiek pārbaudīta tieši Ethereum. Scroll arī pēta iespēju izveidot daudzslāņu pierādījumu sistēmu, lai vēl vairāk apkopotu otrā līmeņa pierādījumu sistēmas radītos apkopotos pierādījumus.
Pašreizējā ieviešanā Scroll pirmā līmeņa pārbaudes sistēmas EVM ķēdē ir 116 kolonnas, 2496 pielāgoti vārti, 50 uzmeklēšanas tabulas, augstākais pasūtījums ir 9, un tai ir nepieciešamas 2^18 rindas zem 1M gāzes, savukārt otrā līmeņa pārbaudes sistēmai ir The apkopošanas ķēdē ir tikai 23 kolonnas, 1 pielāgots vārti, 7 uzmeklēšanas tabulas, un augstākā secība ir 5. Lai apkopotu EVM ķēdi, atmiņas ķēdi un uzglabāšanas ķēdi, ir nepieciešamas 2^25 rindas.
Scroll ir arī daudz pētījis un optimizējis GPU aparatūras paātrinājumu. EVM shēmām optimizētais GPU pārbaudītājs aizņem tikai 30 sekundes, kas ir 9 reizes efektīvāks nekā CPU pārbaudītājs, tikai pēc optimizācijas GPU pārbaudītājs aizņem 149 s, kas ir 15 reizes efektīvāk nekā centrālais procesors. Pašreizējos optimizācijas apstākļos 1M gāzes pirmā līmeņa pārbaudes sistēma aizņem apmēram 2 minūtes, bet otrā līmeņa pārbaudes sistēma aizņem apmēram 3 minūtes.
Trešajā daļā Džans Je runāja par dažiem interesantiem izpētes jautājumiem Scroll zkEVM veidošanas procesā, sākot no priekšgala aritmētiskās shēmas līdz pierādītāja ieviešanai.
ķēde
Pirmais ir ķēdes nejaušība Tā kā EVM lauks ir 256 biti, mums tas ir jāsadala 32 8 bitu laukos, lai veiktu diapazona pārbaudi. Pēc tam mēs izmantojam Random Linear Combination (RLC) metodi, lai kodētu 32 laukus vienā, izmantojot nejaušus skaitļus. Mums ir jāpārbauda tikai šis lauks, lai pārbaudītu sākotnējo 256 bitu lauku. Bet problēma ir tā, ka nejaušais skaitlis ir jāģenerē pēc lauku sadalīšanas, lai nodrošinātu, ka tas netiek manipulēts. Tāpēc Scroll un PSE komanda ierosināja daudzpakāpju pārbaudes risinājumu, lai nodrošinātu, ka pēc lauka sadalīšanas RLC ģenerēšanai tiek izmantoti nejauši skaitļi. Šis risinājums ir iekapsulēts Challenge API. RLC ir daudz lietojumprogrammu scenāriju zkEVM. Tas var ne tikai saspiest EVM lauku vienā laukā, bet arī šifrēt mainīga garuma ievadi vai optimizēt uzmeklēšanas tabulas izkārtojumu. Tomēr joprojām ir daudz neatrisinātu problēmu.
Otrs interesants pētniecības jautājums shēmās ir shēmas izkārtojums. Iemesls, kāpēc Scroll priekšgals izmanto Plonkish, ir tāpēc, ka EVM izpildes trase mainās dinamiski un ir jāspēj atbalstīt dažādus ierobežojumus un mainīgas ekvivalences pārbaudes, un R1CS standartizēto vārtu ieviešanai ir nepieciešams lielāks ķēdes mērogs. Tomēr Scroll pašlaik izmanto vairāk nekā 2000 pielāgotu vārtu, lai apmierinātu dinamiski mainīgas izpildes pēdas, un arī pēta, kā vēl vairāk optimizēt shēmas izkārtojumu, tostarp sadalot opkoda mikro opkodā vai atkārtoti izmantojot šūnas tajā pašā tabulā.
Trešais interesants pētniecības jautājums shēmās ir dinamiskā mērogošana. Tā kā dažādu opkodu shēmas skala ir atšķirīga, taču, lai izpildītu dinamiski mainīgo izpildes izsekošanu, katra soļa operētājkodam ir jāatbilst maksimālajai shēmas skalai, piemēram, Keccak jaukšanai, tāpēc mēs faktiski maksājam papildu izmaksas. Pieņemot, ka mēs varam likt zkEVM dinamiski pielāgoties dinamiski mainīgām izpildes trasēm, tas ietaupīs nevajadzīgas izmaksas.
prover
Runājot par pierādījumiem, Scroll ir veicis daudz optimizāciju MSM un NTT attiecībā uz GPU paātrinājumu, taču tagad vājais kakls ir novirzījies uz datu ģenerēšanu un kopēšanu. Tā kā tiek pieņemts, ka MSM un NTT aizņem 80% no pārbaudes laika, pat ja aparatūras paātrinājums var uzlabot šo efektivitāti par vairākām kārtām, sākotnējais datu ģenerēšanas un kopēšanas 20% pārbaudes laiks kļūs par jaunu vājo vietu. Vēl viena pārbaudītāja problēma ir tā, ka tas prasa daudz atmiņas, tāpēc ir jāizpēta lētāki un decentralizētāki aparatūras risinājumi.
Tajā pašā laikā Scroll pēta arī aparatūras paātrinājuma un pārbaudes algoritmus, lai uzlabotu pārbaudītāju efektivitāti. Pašlaik ir divi galvenie virzieni, vai nu pāreja uz mazāku domēnu, piemēram, izmantojot 64 bitu Goldilocks domēnu, 32 bitu Mersenne Prime utt., vai pieturēšanās pie jaunas pārbaudes sistēmas, kuras pamatā ir eliptiskās līknes (EC), piemēram, SuperNova . Protams, ir arī citi iespējamie ceļi, un draugi ar idejām ir laipni aicināti sazināties tieši ar Scroll.
drošību
Veidojot zkEVM, drošība ir vissvarīgākā. PSE un Scroll kopīgi izveidotajā zkEVM ir aptuveni 34 000 koda rindu No programmatūras inženierijas viedokļa nav iespējams, ka šīm sarežģītajām kodu bāzēm ilgstoši nav ievainojamību. Pašlaik Scroll pārskata zkEVM kodu bāzi, veicot lielu skaitu revīziju, tostarp no nozares vadošajiem auditorfirmām.
4. daļā ir apskatītas citas lietojumprogrammas, kas izmanto zkEVM.
zkRollup arhitektūrā mēs pārbaudām, vai n transakcijas L2 ir derīgas, izmantojot viedo līgumu L1.
Ja mēs tieši pārbaudām L1 bloku, tad L1 mezglam nav nepieciešams atkārtoti izpildīt darījumu, bet tikai jāpārbauda katra bloka sertifikāta derīgums. Šāds arhitektūras risinājums tiek saukts par Enshrine Blockchain. Pašlaik to ir ļoti grūti ieviest tieši Ethereum, jo ir jāverificē viss Ethereum bloks, kas ietvers liela skaita parakstu pārbaudi, kā rezultātā tiks pagarināts verifikācijas laiks un zemāka drošība. Protams, jau ir dažas citas publiskas ķēdes, kas izmanto rekursīvus pierādījumus, lai pārbaudītu visu blokķēdi, izmantojot vienu pierādījumu, piemēram, Mina.
Tā kā zkEVM var pierādīt stāvokļu pārejas, to var izmantot arī baltās cepures, lai pierādītu, ka viņi zina noteiktu viedo līgumu ievainojamības un vēlas saņemt atlīdzību no projekta pusēm.
Pēdējais izmantošanas gadījums ir pierādīt apgalvojumus par vēsturiskajiem datiem, izmantojot nulles zināšanu pierādījumu, un izmantot to kā orākulu, ko Axiom pašlaik ražo šajā jomā. Nesen notikušajā ETHBeijing Hackathon GasLockR komanda izmantoja šo funkciju, lai pierādītu vēsturisko Gas virsotni.
Visbeidzot, Scroll veido zkRollup universālo mērogošanas risinājumu Ethereum, izmantojot ļoti progresīvas aritmētiskās shēmas un pārbaudes sistēmas, kā arī veido ātrus pārbaudītājus, izmantojot aparatūras paātrinājumu, lai pierādītu rekursiju. Šobrīd Alfa testa tīkls ir bijis tiešsaistē un ilgu laiku darbojas stabili.
Protams, joprojām ir dažas interesantas problēmas, kas jāatrisina, tostarp protokola dizains un mehānismu dizains, nulles zināšanu inženierija un faktiskā efektivitāte.
