Sākotnējais autors: Ye Zhang

Sākotnējais avots: Scroll CN

Sastādītājs: F.F

Jaunākajā ZKP Mooc kursā Scroll līdzdibinātājs Zhang Ye uzstājās ar runu par zkEVM dizainu, optimizāciju un lietojumu. Scroll veido ZK-Rollup Ethereum ekvivalentu, kas ir saderīgs baitu koda līmenī un tieši atbalsta visus esošos rīkus.

Tālāk ir sniegta video atšifrētā versija

Runa tika sadalīta četrās daļās. Pirmajā daļā Zhang Ye iepazīstināja ar izstrādes fonu un to, kāpēc mums ir nepieciešams zkEVM un kāpēc tas ir kļuvis tik populārs pēdējo divu gadu laikā lai izveidotu zkEVM no nulles, tostarp aritmētisko un pierādīšanas sistēmu, trešajā daļā tiek runāts par problēmām, ar kurām Ritināšana saskārās, veidojot zkEVM, izmantojot dažus interesantus izpētes jautājumus, un visbeidzot iepazīstinās ar dažām citām lietojumprogrammām, izmantojot zkEVM.

Pamatinformācija un motivācija

Tradicionālajām 1. slāņa blokķēdēm ir daži mezgli, kas tiek kopīgi uzturēti, izmantojot P2P tīklu. Kad tie saņem transakcijas no lietotājiem, tie tiek izpildīti EVM virtuālajā mašīnā, nolasa izsaukuma līgumu un krātuvi un atjaunina globālo stāvokļa koku atbilstoši transakcijai.

Šādas arhitektūras priekšrocības ir decentralizācija un drošība, bet trūkumi ir tādi, ka darījumu maksas 1. līmenī ir augstas un darījumu apstiprināšana ir lēna.

ZK-Rollup arhitektūrā L2 tīklam dati un datu pareizības pierādījums ir jāaugšupielādē tikai L1 tīklā, kur pierādījums tiek aprēķināts, izmantojot nulles zināšanu pierādījuma shēmu.

Agrīnajā ZK-Rollup versijā shēmas tika izstrādātas īpašiem lietojumiem. Lietotājiem bija jānosūta darījumi uz dažādiem pārbaudītājiem, un pēc tam dažādu lietojumprogrammu ZK-Rollup iesniedza savus datus un pierādījumus L1. Problēma ir tā, ka sākotnējā L1 līguma salikšanas iespējamība tiek zaudēta.

Scroll vēlas izveidot 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ī ļauj izstrādātājiem iegūt izstrādes pieredzi L1. Protams, izstrādes grūtības, kas ir šī iemesla dēļ, ir ārkārtīgi augstas, un arī pierādījumu ģenerēšanas izmaksas tagad ir ļoti augstas.

Par laimi, nulles zināšanu pierādījumu efektivitāte pēdējo divu gadu laikā ir ievērojami uzlabojusies, tāpēc zkEVM pēdējo divu gadu laikā ir kļuvis tik populārs. Ir vismaz četri iemesli, kas to padara iespējamu. Pirmais ir polinomu saistību rašanās. Saskaņā ar sākotnējo Groth16 pierādījumu sistēmu ierobežojumu mērogs ir ļoti liels, un polinomiālas saistības var atbalstīt augstākas kārtas ierobežojumus un samazināt pierādījumu mērogu. Otrais ir uzmeklēšanas tabulu un pielāgotu vārtu parādīšanās, kas var atbalstīt elastīgākus dizainus un padarīt pierādījumus efektīvākus. Trešais ir sasniegumi aparatūras paātrinājumā. Izmantojot GPU, FPGA un ASIC, pierādīšanas laiku var saīsināt par 1–2 lieluma kārtām. Ceturtkārt, rekursīvos pierādījumos 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 lieluma kārtām augstāka nekā pirms diviem gadiem, kas ir arī Scoll izcelsme.

Saskaņā ar Džastina Dreika definīciju, zkEVM var iedalīt trīs kategorijās. Pirmā kategorija ir saderība valodas līmenī. Galvenais iemesls ir tāds, ka EVM nav paredzēts ZK un tam ir daudz opkodu, kas nav draudzīgi ZK, kas radīs daudz papildu izmaksu. Tāpēc Starkware un zkSync izvēlas kompilēt Solidity vai Yul ZK draudzīgā kompilatorā valodas līmenī.

Otrais veids ir baitkoda līmeņa saderība, pie kuras strādā Scroll, kas tieši pierāda, vai EVM baitkoda apstrāde ir pareiza vai nē, un tieši manto Ethereum izpildes vidi. Daži kompromisi, ko šeit var veikt, ir izmantot citu stāvokļa sakni nekā EVM, piemēram, izmantot ZK draudzīgu datu struktūru. Hermez un Consensys dara līdzīgas lietas.

Trešā kategorija ir saderība konsensa līmenī. Kompromiss šeit ir tāds, ka ne tikai EVM ir jāpaliek nemainīgam, bet arī krātuves struktūrai utt. ir jābūt pilnībā saderīgai ar Ethereum, taču tas prasa ilgāku pierādīšanas laiku. Scroll sadarbojas ar Ethereum fonda PSE komandu, lai ieviestu uz ZK balstītu Ethereum.

zkEVM veidošana no 0 līdz 1

Otrajā daļā Džans Je visiem parādīja, kā no nulles izveidot ZKVM.

Pabeigt procesu

Pirmkārt, ZKP priekšējā galā aprēķini jāizsaka, izmantojot matemātisku aritmētiku. Visbiežāk izmantotie ir lineārie R1CS, Plonkish un AIR. Pēc ierobežojumu iegūšanas, izmantojot aritmētiku, ZKP aizmugursistēmā ir jāpalaiž pierādīšanas algoritms, lai pierādītu aprēķina pareizību. Šeit ir visbiežāk izmantotie polinomiālie interaktīvie orākulu pierādījumi (Polinomial IOP) un polinomiālās saistību shēmas (PCS).

Šeit mums jāpierāda, ka zkEVM, Scroll izmanto Plonkish, Plonk IOP un KZG kombināciju.

Lai saprastu, kāpēc mēs izmantojam šīs trīs shēmas. Sāksim 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 mainīgo lineāru kombināciju bez papildu izmaksām, bet katra ierobežojuma kārta ir ne vairāk kā 2. Tāpēc augstākas kārtas darbībām ir nepieciešams vairāk ierobežojumu.

Plonkišā tabulā ir jāievada visi mainīgie, tostarp ieejas, izejas un starpposma mainīgo liecinieki. Papildus tam varat definēt dažādus ierobežojumus. Plonkišā var izmantot trīs ierobežojumu veidus.

Pirmais ierobežojums ir pielāgots vārti (Custom Gate), kur var definēt polinoma ierobežojumus 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 var definēt ierobežojumus jebkuram mainīgajam, un var definēt dažus ļoti atšķirīgus ierobežojumus.

Otrais ierobežojumu veids ir Permuācija, kas ir vienlīdzības pārbaude. To var izmantot, lai pārbaudītu dažādu šūnu līdzvērtību, un to bieži izmanto, lai saistītu dažādus vārtus ķēdē, piemēram, lai pierādītu, ka iepriekšējo vārtu izeja ir vienāda ar nākamo vārtu ieeju.

Pēdējais ierobežojuma veids ir uzmeklēšanas tabula. Uzmeklēšanas tabulu varam iedomāties kā mainīgo lielumu attiecības, kuras var attēlot kā tabulu. Piemēram, ja vēlamies pierādīt, ka vc7 atrodas diapazonā no 0 līdz 15, R1CS vispirms šī vērtība ir jāsadala 4 bināros bitos un pēc tam jāpierāda, ka katrs bits atrodas diapazonā no 0 līdz 1, kam būs nepieciešami četri ierobežojumi. Plonkišā jūs varat uzskaitīt visus iespējamos diapazonus vienā kolonnā un tikai jāpierāda, ka vc7 pieder šai kolonnai. Tas ir ļoti efektīvi diapazona pierādījumiem. zkEVM programmā uzmeklēšanas tabulas ir ļoti noderīgas, lai pārbaudītu atmiņas lasīšanas un rakstīšanas operāciju skaitu.

Rezumējot, Plonkish atbalsta pielāgotus vārtus, ekvivalences pārbaudes un uzmeklēšanas tabulas, kas var elastīgi apmierināt dažādu shēmu vajadzības. Veiksim vienkāršu salīdzinājumu ar STARK. STARK valodā katra rinda ir ierobežojums, un ierobežojumam ir jāatspoguļo stāvokļa pāreja starp rindām. Tomēr pielāgotie ierobežojumi Plonkish valodā acīmredzami ir elastīgāki.

Tagad jautājums ir, kā izvēlēties lietotāja saskarni zkEVM. zkEVM ir četri galvenie izaicinājumi. Pirmais izaicinājums ir tas, ka EVM lauks ir 256 biti, kas nozīmē, ka mainīgajiem ir jābūt efektīvi ierobežotiem diapazonā; Otrais izaicinājums ir tāds, ka EVM ir daudz ZK nedraudzīgu opkodu, tāpēc šo opkodu pierādīšanai ir nepieciešami ļoti liela mēroga ierobežojumi, piemēram, Keccak-256; Trešais izaicinājums ir atmiņas lasīšanas un rakstīšanas problēma, jums ir nepieciešama derīga kartēšana, lai pierādītu, ka lasītais atbilst iepriekš rakstītajam; Ceturtais izaicinājums ir tāds, ka EVM izpildes trase mainās dinamiski, tāpēc mums ir nepieciešami pielāgoti vārti, lai pielāgotos dažādām izpildes trasēm. Iepriekš minēto iemeslu dēļ mēs izvēlējāmies Plonkišu.

Tālāk aplūkosim pilnu zkEVM procesu. Balstoties uz sākotnējo globālo stāvokļa koku, kad ienāk jauna transakcija, EVM nolasīs saglabāto un izsaukto līgumu baitkodu, ģenerēs atbilstošas ​​izpildes pēdas, piemēram, PUSH, PUSH, STORE, CALLVALUE, atbilstoši transakcijai, un pēc tam pakāpeniski izpildīs un atjauninās globālo stāvokli, lai iegūtu globālo stāvokļa koku pēc transakcijas. zkEVM kā ievaddatus ņem sākotnējo globālo stāvokļu koku, pašu transakciju un globālo stāvokļu koku pēc transakcijas un pierāda izpildes izsekošanas pareizību saskaņā ar EVM specifikāciju.

Iedziļinieties EVM shēmas detaļās, un katram izpildes izsekošanas solim ir atbilstoši shēmas ierobežojumi. Konkrētāk, katra soļa ķēdes ierobežojumi ietver soļa kontekstu, gadījuma pārslēgšanu un opkoda specifisko liecinieku. Soļa konteksts satur koda jaucējkodu, atlikušo gāzi un skaitītāju, kas atbilst izpildes izsekošanai; Lietu pārslēgšana satur visus opkodus, visus kļūdu nosacījumus un atbilstošās soļa darbības; Opkoda specifiskais liecinieks satur papildu lieciniekus, kas nepieciešami opkodam, piemēram, operandus utt.

Ņemot vienkāršu saskaitīšanu kā piemēru, ir jānodrošina, lai saskaitīšanas opkoda vadības mainīgais sADD būtu iestatīts uz 1, un visu pārējo opkodu vadības mainīgie būtu nulle. Soļu kontekstā patērētās gāzes daudzums tiek ierobežots līdz 3, iestatot gas' - gas - 3 = 0. Līdzīgi skaitītājs tiek ierobežots un steka rādītājs pēc šī soļa tiek palielināts par 1. Lietu “Case Switch” gadījumā solis ir ierobežots kā saskaitīšanas operācija, iestatot opcode vadības mainīgo un 1. Lietu “Opcode Specific Witness” gadījumā operandu faktiskā saskaitīšana ir ierobežota.

Turklāt ir nepieciešami papildu ķēdes ierobežojumi, lai nodrošinātu no atmiņas nolasīto operandu pareizību. Šeit vispirms ir jāizveido uzmeklēšanas tabula, lai pierādītu, ka operandi pieder atmiņai. Atmiņas tabulas pareizība tiek pārbaudīta, izmantojot atmiņas shēmu (RAM shēmu).

To pašu pieeju var pielietot arī zk nedraudzīgām heša funkcijām, izveidojot heša funkcijas uzmeklēšanas tabulu, kartējot izpildes trasē esošo heša ievadi un izvadi uzmeklēšanas tabulā un izmantojot papildu heša shēmu, lai pārbaudītu heša uzmeklēšanas tabulas pareizību.

Tagad aplūkosim zkEVM shēmas arhitektūru. Galvenā EVM shēma tiek izmantota, lai ierobežotu katra izpildes izsekošanas soļa pareizību. Dažās vietās, kur EVM shēmu ir grūti ierobežot, mēs tās kartējam, izmantojot uzmeklēšanas tabulas, tostarp fiksēto tabulu, Keccak tabulu, RAM tabulu, baitkodu, darījumu, bloka kontekstu, un pēc tam izmantojam atsevišķas shēmas, lai ierobežotu šīs uzmeklēšanas tabulas. Piemēram, Keccak shēma tiek izmantota, lai ierobežotu Keccak tabulu.

Rezumējot, pilnīga zkEVM darbplūsma ir parādīta zemāk esošajā attēlā.

Pierādījumu sistēma

Tā kā iepriekš minēto EVM shēmu, atmiņas shēmu, krātuves shēmu utt. tieša verifikācija L1 ir ārkārtīgi dārga, Scroll pierādījumu sistēma izmanto divslāņ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 daudz aprēķinu. Tāpēc pirmā slāņa pierādījumu sistēmai ir jāatbalsta pielāgoti vārti un uzmeklēšanas tabulas, jābūt draudzīgai aparatūras paātrinājumam, jāģenerē aprēķini paralēli ar mazu atmiņas maksimālo slodzi un jābūt ar nelielu verifikācijas shēmas mērogu ātrai verifikācijai. Daudzsološas alternatīvas ir Plonky2, Starky un eSTARK, kas pamatā izmanto Plonk priekšpusē, bet var izmantot FRI aizmugurē, un visas atbilst iepriekš minētajām četrām īpašībām. Vēl viena iespēja ietver Zcash izstrādāto Halo2 un Halo2 KZG versiju.

Ir arī dažas daudzsološas jaunas pierādījumu sistēmas, piemēram, HyperPlonk, kas nesen noņēma FFT, un NOVA pierādījumu sistēma, kas var veikt mazākus rekursīvus pierādījumus. Bet viņi atbalsta R1CS tikai pētniecībā. Ja viņi nākotnē varēs atbalstīt Plonkišu un pielietot to praksē, tas būs ļoti praktiski un efektīvi.

Otrā slāņa pierādījumu sistēma tiek izmantota, lai pierādītu pirmā slāņa pierādījuma pareizību. Tam jābūt iespējai efektīvi verificēt EVM. Ideālā gadījumā tam vajadzētu būt arī aparatūras paātrinājumam draudzīgam un atbalstīt caurspīdīgu vai universālu iestatīšanu. Daudzsološas alternatīvas ir Groth16 un mazāku kolonnu Plonkish pierādījumu sistēma. Groth16 joprojām ir ārkārtīgi augstas pierādīšanas efektivitātes pārstāvis pašreizējos pētījumos, un Plonkiša pierādīšanas sistēma var sasniegt augstu pierādīšanas efektivitāti arī ar mazāku kolonnu skaitu.

Uzņēmumā Scroll mēs izmantojam Halo2-KZG pierādījumu sistēmu abiem pierādījumu sistēmas slāņiem. Tā kā Halo2-KZG var atbalstīt pielāgotus vārtus un uzmeklēšanas tabulas, tas labi darbojas GPU aparatūras paātrinājumā, un verifikācijas shēma ir maza un to var ātri verificēt. Atšķirība ir tāda, ka pirmā slāņa pierādījumu sistēmā mēs izmantojam Poseidon hešu, lai vēl vairāk uzlabotu pierādījumu efektivitāti, savukārt otrā slāņa pierādījumu sistēma joprojām izmanto Keccak hešu, jo tas tiek pārbaudīts tieši Ethereum. Scroll arī pēta daudzslāņu pierādījumu sistēmas iespēju, lai vēl vairāk apkopotu otrā slāņa pierādījumu sistēmas ģenerētos apkopotos pierādījumus.

Saskaņā ar pašreizējo ieviešanu Scroll pirmā slāņa pierādījuma sistēmas EVM shēmai ir 116 kolonnas, 2496 pielāgoti vārti, 50 uzmeklēšanas tabulas, augstākā secība ir 9, un 1M gāzes jaudai ir nepieciešamas 2^18 rindas; savukārt otrā slāņa pierādījuma sistēmas apkopošanas shēmai ir tikai 23 kolonnas, 1 pielāgots vārts, 7 uzmeklēšanas tabulas un augstākā secība ir 5. Lai apkopotu EVM shēmu, atmiņas shēmu un krātuves shēmu, ir nepieciešamas 2^25 rindas.

Scroll ir arī paveicis daudz pētījumu un optimizācijas darba GPU aparatūras paātrināšanas jomā. EVM shēmai optimizētais GPU pārbaudītājs aizņem tikai 30 sekundes, kas ir 9 reizes efektīvāk nekā CPU pārbaudītājs; un apkopošanas shēmai optimizētais GPU pārbaudītājs aizņem tikai 149 sekundes, kas ir 15 reizes efektīvāk nekā centrālais procesors (CPU). Pašreizējos optimizētajos apstākļos pirmā slāņa izturības sistēmas izveidošana 1M gāzes gadījumā aizņem aptuveni 2 minūtes, bet otrā slāņa izturības sistēmas izveidošana – aptuveni 3 minūtes.

Interesanti pētniecības jautājumi

Trešajā daļā Džans Je runāja par dažiem interesantiem pētniecības jautājumiem Scroll zkEVM veidošanas procesā, sākot no priekšējās daļas aritmētiskās shēmas līdz pierādīšanas programmas ieviešanai.

Ķēde

Pirmais ir nejaušība shēmā, jo, tā kā EVM lauks ir 256 biti, mums tas ir jāsadala 32 8 bitu laukos, lai efektīvāk veiktu diapazona pierādījumus. Pēc tam mēs izmantojām nejaušas lineāras kombinācijas (RLC) metodi, lai 32 laukus kodētu vienā, izmantojot nejaušus skaitļus. Mums ir jāpārbauda tikai šis lauks, lai pārbaudītu sākotnējo 256 bitu lauku. Taču problēma ir tā, ka nejaušo skaitļu ģenerēšanai jānotiek pēc lauka 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 RLC tiek ģenerēts, izmantojot nejaušus skaitļus pēc lauka sadalīšanas. Šis risinājums ir iekapsulēts izaicinājumu API. RLC ir daudz pielietojuma scenāriju zkEVM vidē. Tas var ne tikai saspiest EVM laukus vienā laukā, bet arī šifrēt mainīga garuma ievades datus vai optimizēt uzmeklēšanas tabulu izkārtojumu. Tomēr joprojām ir daudz neatrisinātu problēmu.

Otra interesanta pētījumu problēma ķēdēs ir shēmu izkārtojums. Iemesls, kāpēc Scroll front-end izmanto Plonkish, ir tāds, ka EVM izpildes izsekošana dinamiski mainās un tai ir jāatbalsta dažādi ierobežojumi un mainīgas ekvivalences pārbaudes, savukārt R1CS standartizētajiem vārtiem ir nepieciešams lielāks shēmas mērogs.

Tomēr Scroll pašlaik izmanto vairāk nekā 2000 pielāgotu vārtu, lai izpildītu dinamiski mainīgās izpildes izsekošanas prasības, un arī pēta, kā vēl vairāk optimizēt shēmas izkārtojumu, tostarp sadalot Opcode mikro Opcode vai atkārtoti izmantojot šūnas vienā tabulā.

Trešais interesants pētījumu jautājums shēmās ir dinamiskā mērogošana. Tā kā dažādiem opkodiem ir atšķirīgi ķēdes izmēri, bet, lai apmierinātu dinamiski mainīgās izpildes pēdas, katra soļa opkodiem ir jāatbilst maksimālajam ķēdes izmēram, piemēram, Keccak hešēšanai, tāpēc mēs faktiski maksājam papildu izmaksas. Pieņemot, ka mēs varam panākt, lai zkEVM dinamiski pielāgotos dinamiski mainīgajām izpildes trasēm, tas ietaupītu nevajadzīgas papildu izmaksas.

Provers

Runājot par pierādīšanas aspektu, Scroll ir veicis daudz MSM un NTT optimizāciju GPU paātrinājuma ziņā, taču tagad vājā vieta ir pārgājusi uz liecinieku ģenerēšanu un datu replikāciju. Tā kā tiek pieņemts, ka MSM un NTT aizņem 80% no pierādīšanas laika, pat ja aparatūras paātrinājums var uzlabot šo efektivitāti par vairākām lieluma pakāpēm, sākotnējie 20% no pierādīšanas laika, kas bija paredzēts liecinieku ģenerēšanai un datu replikācijai, kļūs par jauno sašaurinājumu. Vēl viena problēma ar pārbaudītājiem ir tā, ka tiem nepieciešams daudz atmiņas, tāpēc ir nepieciešams arī izpētīt lētākus un decentralizētākus aparatūras risinājumus.

Vienlaikus Scroll arī pēta aparatūras paātrinājumu un pierādījumu algoritmus, lai uzlabotu pierādīšanas ierīču 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 pirmskaitli utt., vai arī pieturēšanās pie jaunas pierādījumu sistēmas, kuras pamatā ir eliptiskās līknes (EC), piemēram, SuperNova. Protams, ir arī citi iespējamie ceļi. Draugi ar idejām ir laipni aicināti sazināties tieši ar Scroll.

Drošība

Drošība ir ārkārtīgi svarīga, veidojot zkEVM. PSE un Scroll veidotajā zkEVM ir aptuveni 34 000 koda rindiņu. No programmatūras inženierijas viedokļa tik sarežģītai koda bāzei nav iespējams ilgstoši būt brīvai no ievainojamībām. Scroll pašlaik pārskata zkEVM koda bāzi, veicot lielu skaitu auditu, tostarp no nozares vadošajām auditorfirmām.

Citas lietojumprogrammas, kas izmanto zkEVM

4. daļā ir aplūkotas dažas citas lietojumprogrammas, kas izmanto zkEVM.

zkRollup arhitektūrā mēs izmantojam viedos līgumus 1. līmenī, lai pārbaudītu, vai n darījumi 2. līmenī ir derīgi.

Ja mēs pārbaudām L1 blokus tieši, tad L1 mezgliem nav atkārtoti jāizpilda transakcijas, bet tikai jāpārbauda katra bloka pierādījuma derīgums. Šo arhitektūras risinājumu sauc par Enshrine Blockchain. Pašlaik to ir ļoti grūti ieviest tieši Ethereum, jo ​​ir jāpārbauda viss Ethereum bloks, kas ietver liela skaita parakstu pārbaudi, kā rezultātā pierādīšanas laiks ir ilgāks un drošība ir zemāka. Protams, jau pastāv arī dažas citas publiskas ķēdes, kas izmanto rekursīvus pierādījumus un vienu pierādījumu visas blokķēdes pārbaudei, 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 tās zina noteiktu viedo līgumu ievainojamības un vēlas saņemt atlīdzību no projekta.

Pēdējais lietošanas gadījums ir pierādīt apgalvojumus par vēsturiskiem datiem, izmantojot nulles zināšanu pierādījumu, un izmantot to kā orākulu. Axiom pašlaik strādā pie produktiem šajā jomā. Nesenajā ETHBeijing hakatonā GasLockR komanda izmantoja šo funkciju, lai pierādītu vēsturiskās gāzes izmaksas.

Visbeidzot, Scroll izstrādā zkRollup vispārējas mērogošanas risinājumu Ethereum, izmantojot ļoti progresīvas aritmētiskās shēmas un pierādījumu sistēmas, kā arī veidojot ātrus validatorus un pierādot rekursiju, izmantojot aparatūras paātrinājumu. Alfa testa tīkls tagad ir tiešsaistē un jau ilgstoši darbojas stabili.

Protams, joprojām ir dažas interesantas problēmas, kas jāatrisina, tostarp protokolu un mehānismu izstrāde, nulles zināšanu inženierija un praktiskā efektivitāte. Ikviens ir laipni aicināts pievienoties Scroll, lai kopīgi veidotu!

Ritināt

Tīmekļa vietne: https://scroll.io/

Twitter: https://twitter.com/Scroll_ZKP

Discord: https://discord.com/invite/scroll

Github: https://github.com/scroll-tech

Youtube: https://www.youtube.com/@Scroll_ZKP