Spoluzakladatel Scroll Zhang Ye mluvil o čtyřech částech V první části představil Zhang Ye pozadí vývoje a proč potřebujeme zkEVM a proč se stal v posledních dvou letech tak populární vysvětlil, jak prostřednictvím kompletního procesu vytváření zkEVM od nuly zahrnuje aritmetické a důkazové systémy. Třetí část pojednává o problémech, se kterými se Scroll setkává při vytváření zkEVM, prostřednictvím několika zajímavých výzkumných otázek a nakonec představuje některé další aplikace využívající zkEVM.
Tradiční blockchain vrstvy 1 bude mít některé uzly udržované společně prostřednictvím P2P sítě. Když obdrží transakci uživatele, provede ji na virtuálním stroji EVM, přečte si smlouvu o volání a úložiště a aktualizuje strom globálního stavu podle transakce.
Výhodou takové architektury je decentralizace a bezpečnost. Nevýhodou je, že transakční poplatky na L1 jsou drahé a potvrzování transakcí je pomalé.
V architektuře ZK-Rollup potřebuje síť L2 pouze nahrát data a důkaz pro ověření správnosti dat do L1, kde je důkaz vypočítán prostřednictvím obvodu důkazu s nulovými znalostmi.
V raných verzích ZK-Rollup byl obvod navržen pro specifické aplikace. Uživatelé potřebovali posílat transakce různým dokazovatelům, a pak ZK-Rollupy různých aplikací předkládaly svá vlastní data a důkazy L1. Problém, který to přináší, je, že se ztrácí složitelnost původní smlouvy L1.
Scroll dělá nativní řešení zkEVM, což je univerzální ZK-Rollup. To je nejen uživatelsky přívětivější, ale také poskytuje vývojářům lepší zkušenost s vývojem na L1. Vývoj za tím je samozřejmě velmi obtížný a náklady na současné generování důkazů jsou také velmi vysoké.
Naštěstí se efektivita důkazů s nulovými znalostmi v posledních dvou letech výrazně zlepšila, a proto se zkEVM v posledních dvou letech stal tak populární. Existují nejméně čtyři důvody, proč se to stává proveditelným. Prvním je vznik polynomiálního závazku V původním systému důkazů Groth16 byl rozsah omezení velmi velký, ale polynomický závazek může podporovat omezení vyššího řádu a snížit rozsah omezení. důkaz za druhé, vznik vyhledávacích tabulek a vlastních hradel může podporovat flexibilnější návrhy a zefektivnit důkazy, třetí je průlom v hardwarové akceleraci, který může zkrátit dobu důkazu o 1-2 řády prostřednictvím GPU, FPGA a ASIC; Čtvrtý V rámci rekurzivního důkazu lze více důkazů zkomprimovat do jednoho důkazu, takže důkaz je menší a snáze se ověřuje. Kombinací těchto čtyř faktorů je tedy generační efektivita důkazů s nulovými znalostmi o tři řády vyšší než před dvěma lety, což je také původem Scoll.
Podle definice Justina Drakea lze zkEVM rozdělit do tří kategorií. První kategorií je kompatibilita na jazykové úrovni. Hlavním důvodem je, že EVM není určeno pro ZK a má mnoho operačních kódů, které nejsou přátelské ke ZK. spoustu dalších režií. Společnosti jako Starkware a zkSync se proto rozhodly zkompilovat Solidity nebo Yul do kompilátorů vhodných pro ZK na jazykové úrovni.
Druhým typem je kompatibilita na úrovni bytecode, kterou Scroll dělá, která přímo dokazuje, zda je zpracování bytecode EVM správné nebo ne, a přímo dědí prostředí pro provádění Etherea. Některé kompromisy, které zde lze provést, jsou použití jiného kořene stavu než EVM, jako je použití datové struktury přátelské k ZK. Hermez a Consensys dělají něco podobného.
Třetí kategorií je kompatibilita na úrovni konsenzu. Kompromisem je, že je nutné nejen ponechat EVM beze změny, ale také zahrnout strukturu úložiště pro dosažení plné kompatibility s Ethereem, a to za cenu delší doby ověření. Scroll je budován ve spolupráci s týmem PSE nadace Ethereum za účelem realizace ZKizace Etherea.
V druhé části Zhang Ye všem ukázal, jak postavit ZKVM od nuly.
Kompletní proces
Nejprve musíte v přední části ZKP vyjádřit své výpočty pomocí matematické aritmetiky. Nejčastěji používané jsou lineární R1CS, stejně jako Plonkish a AIR. Po získání omezení pomocí aritmetiky musíte spustit důkazní algoritmus na backendu ZKP, abyste prokázali správnost výpočtu Zde jsou nejběžněji používané polynomické interaktivní důkazy oracle (Polynomial IOP) a schéma zapojení polynomů (PCS).
Zde musíme dokázat, že zkEVM a Scroll používají kombinaci Plonkish, Plonk IOP a KZG.
Abychom pochopili, proč používáme tato tři řešení. Nejprve začneme s nejjednodušším R1CS Omezení v R1CS je, že lineární kombinace krát lineární kombinace se rovná lineární kombinaci. Můžete přidat jakoukoli lineární kombinaci proměnných bez další režie, ale maximální pořadí v každém omezení je 2. Proto je pro operace vyššího řádu vyžadováno více omezení.
V Plonkish musíte do tabulky vyplnit všechny proměnné, včetně vstupů, výstupů a svědků pro meziproměnné. Kromě toho můžete definovat různá omezení. V Plonkish jsou k dispozici tři typy omezení.
Prvním typem omezení je vlastní brána Můžete definovat vztahy polynomických omezení mezi různými buňkami, například va3 * vb3 * vc3 - vb4 =0. Ve srovnání s R1CS může být pořadí vyšší, protože můžete definovat omezení pro libovolnou proměnnou a můžete definovat několik velmi odlišných omezení.
Druhým typem omezení je permuace neboli kontrola rovnosti. Může být použit ke kontrole ekvivalence různých buněk a často se používá k přidružení různých hradel v obvodu, jako je například dokazování, že výstup předchozího hradla je roven vstupu dalšího hradla.
Posledním typem omezení je vyhledávací tabulka. Vyhledávací tabulku můžeme chápat jako vztah mezi proměnnými, který lze vyjádřit tabulkou. Například chceme dokázat, že vc7 je v rozsahu 0-15 V R1CS musíte nejprve rozložit tuto hodnotu na 4bitovou binární hodnotu a pak dokázat, že každý bit je v rozsahu 0-1. bude vyžadovat čtyři omezení. V Plonkish můžete vypsat všechny možné rozsahy ve stejném sloupci a stačí dokázat, že vc7 do tohoto sloupce patří. To je velmi efektivní pro důkazy rozsahu V zkEVM jsou vyhledávací tabulky velmi užitečné pro dokazování čtení a zápisu paměti.
Abych to shrnul, Plonkish také podporuje vlastní hradla, kontroly ekvivalence a vyhledávací tabulky, které mohou být velmi flexibilní, aby vyhovovaly různým potřebám obvodů. Jednoduché srovnání STARK Každý řádek ve STARK je omezení Omezení musí představovat přechod stavu mezi řádky, ale flexibilita vlastních omezení v Plonkish je samozřejmě vyšší.
Otázkou nyní je, jak zvolíme frontend v zkEVM. Pro zkEVM existují čtyři hlavní výzvy. Prvním problémem je, že pole EVM je 256 bitů, což znamená, že proměnné musí být efektivně omezeny rozsahem, druhým problémem je, že EVM má mnoho operačních kódů nevhodných pro ZK, takže k prokázání těchto operací jsou zapotřebí velmi rozsáhlá omezení; kód, jako je Keccak-256, třetí problém je problém se čtením a zápisem paměti, potřebujete nějaké účinné mapování, abyste dokázali, že to, co jste napsali, je v souladu s tím, co jste napsali dříve; se dynamicky mění, takže potřebujeme vlastní brány, které se přizpůsobí různým trasám provádění. Pro výše uvedené úvahy jsme zvolili Plonkishe.
Dále se podívejme na kompletní proces zkEVM Na základě počátečního stromu globálního stavu, po příchodu nové transakce, EVM načte bajtkód uložených a volaných kontraktů a na základě transakce vygeneruje odpovídající trasování provedení, jako je například. PUSH, PUSH, STORE, CALLVALUE a poté postupně aktualizujte globální stav, abyste získali strom globálního stavu po transakci. zkEVM bere počáteční strom globálních stavů, samotnou transakci a strom globálních stavů po transakci jako vstup a používá specifikaci EVM k prokázání správnosti trasování provedení.
Když se ponoříme do detailů obvodu EVM, každý krok trasování provádění má odpovídající omezení obvodu. Konkrétně okruhová omezení každého kroku zahrnují kontext kroku, přepínač případu a svědectví specifického pro operační kód. Kontext kroku obsahuje codehash, zbývající plyn a čítač odpovídající trasování provedení Case Switch obsahuje všechny operační kódy, všechny chybové stavy a odpovídající operace kroku Specifický svědek obsahuje další svědky požadované operačním kódem, jako jsou operandy čekání.
Vezmeme-li jako příklad jednoduché sčítání, musíte zajistit, aby řídicí proměnná sADD sčítacího operačního kódu byla nastavena na 1 a řídicí proměnné ostatních operačních kódů byly všechny nulové. V kontextu kroku je spotřebovaný plyn omezen na hodnotu 3 nastavením plyn' - plyn - 3 = 0. Podobně je ukazatel zásobníku omezen na 1 po kroku, součet; proměnné jsou řízeny na 1 přes operační kód Chcete-li omezit tento krok na operaci sčítání v Opcode Specific Witness, omezte skutečné přidávání operandů.
Kromě toho jsou vyžadována další obvodová omezení pro zajištění správnosti operandů čtených z paměti. Zde musíme nejprve vytvořit vyhledávací tabulku, abychom dokázali, že operand patří do paměti. A ověřte správnost paměťové tabulky přes paměťový obvod (RAM Circuit).
Stejnou metodu lze použít pro hašovací funkce zk-nepřátelské Sestavte vyhledávací tabulku hašovací funkce, namapujte vstup a výstup hašování v trasování provádění na vyhledávací tabulku a použijte další hašovací obvod k ověření hašovací funkce správnost vyhledávací tabulky.
Nyní se podívejme na architekturu obvodu zkEVM Základní obvod EVM se používá k omezení správnosti každého kroku trasování provádění V některých místech, kde jsou omezení obvodu EVM obtížná, používáme k mapování vyhledávací tabulky, včetně Fixed Table, Keccak. Table, RAM Table, Bytecode, Transaction, Block Context, a pak použijte samostatné obvody k omezení těchto vyhledávacích tabulek, jako například Keccakovy obvody k omezení Keccakových tabulek.
Abychom to shrnuli, kompletní pracovní postup zkEVM je znázorněn na obrázku níže.
důkazní systém
Protože přímé ověřování výše uvedených obvodů EVM, paměťových obvodů, obvodů úložiště atd. na L1 je drahé, systém Scroll používá dvouvrstvou architekturu.
První vrstva je zodpovědná za přímý důkaz samotného EVM, což vyžaduje velké množství výpočtů pro vytvoření důkazu. Proto je vyžadován systém ověření první úrovně, aby podporoval vlastní hradla a vyhledávací tabulky, byl přátelský k hardwarové akceleraci, generoval paralelně výpočty s nízkou špičkovou pamětí a měl malý ověřovací obvod, který lze rychle ověřit. Slibné alternativy zahrnují Plonky2, Starky a eSTARK Všechny v podstatě používají Plonk na předním konci, ale mohou používat FRI na zadním konci a všechny splňují výše uvedené čtyři vlastnosti. Dalším typem alternativních řešení je Halo2 vyvinuté společností Zcash a KZG verze Halo2.
Existují také některé nové systémy důkazů, které jsou slibné, jako je HyperPlonk, který nedávno odstranil FFT, a systém důkazů NOVA může dosáhnout menších rekurzivních důkazů. Podporují ale pouze R1CS ve výzkumu Pokud dokážou podpořit Plonkish v budoucnu a aplikovat jej v praxi, bude to velmi praktické a efektivní.
Systém nátisku druhé úrovně se používá k prokázání správnosti nátisku první úrovně a musí být efektivně ověřen v EVM V ideálním případě by měl být přátelský k hardwarové akceleraci a podporovat transparentní nebo univerzální nastavení. Mezi slibné alternativy patří Groth16 a bezsloupový systém Plonkish proof. Groth16 je v současném výzkumu stále představitelem extrémně vysoké nátiskové efektivity a Plonkishův nátiskový systém může také dosáhnout vysoké nátiskové efektivity i s malým počtem kolon.
Ve společnosti Scroll používáme nátiskový systém Halo2-KZG v obou našich dvouvrstvých nátiskových systémech. Protože Halo2-KZG může podporovat vlastní brány a vyhledávací tabulky, funguje dobře při hardwarové akceleraci GPU a ověřovací obvod má malou velikost a lze jej rychle ověřit. Rozdíl je v tom, že v systému důkazu první vrstvy používáme hash Poseidon k dalšímu zlepšení účinnosti důkazu, zatímco systém ověřování druhé vrstvy stále používá hash Keccak, protože je ověřen přímo na Ethereu. Scroll také zkoumá možnost vícevrstvého systému nátisku pro další agregaci agregovaných nátisků generovaných systémem nátisku druhé úrovně.
Podle současné implementace má obvod EVM systému kontroly první úrovně Scroll 116 sloupců, 2496 vlastních hradel, 50 vyhledávacích tabulek, nejvyšší řád je 9 a vyžaduje 2^18 řádků pod 1M Gas, zatímco systém kontroly druhé úrovně má The agregační obvod má pouze 23 sloupců, 1 vlastní hradlo, 7 vyhledávacích tabulek a nejvyšší řád je 5. Aby bylo možné agregovat obvod EVM, paměťový obvod a obvod úložiště, je potřeba 2^25 řádků.
Scroll také provedl spoustu výzkumů a optimalizačních prací na hardwarové akceleraci GPU U obvodů EVM trvá optimalizovaný zkoušeč GPU pouze 30 sekund, což je 9krát efektivnější než u agregačních obvodů, po optimalizaci pouze ověřovač GPU trvá 149 s, což je 15krát efektivnější než CPU. Za současných podmínek optimalizace trvá 1M Gas první úroveň nátiskového systému přibližně 2 minuty a druhá úroveň nátiskového systému trvá přibližně 3 minuty.
Ve třetí části Zhang Ye hovořil o některých zajímavých výzkumných problémech v procesu vytváření zkEVM ve Scroll, od front-end aritmetického okruhu až po implementaci dokazovatele.
obvod
První je náhodnost v obvodu Protože pole EVM má 256 bitů, musíme jej rozdělit na 32 8bitových polí, abychom mohli efektivněji provádět důkaz rozsahu. Pak použijeme metodu Random Linear Combination (RLC) ke kódování 32 polí do 1 pomocí náhodných čísel. Toto pole potřebujeme pouze ověřit, abychom ověřili původní 256bitové pole. Problém je ale v tom, že náhodné číslo musí být vygenerováno po rozdělení polí, aby se zajistilo, že s ním nebude manipulováno. Společnost Scroll a tým PSE proto navrhli řešení s vícestupňovým ověřováním, které zajistí, že po rozdělení pole budou ke generování RLC použita náhodná čísla. Toto řešení je zapouzdřeno v Challenge API. RLC má v zkEVM mnoho aplikačních scénářů. Umí nejen komprimovat pole EVM do jednoho pole, ale také šifrovat vstup s proměnnou délkou nebo optimalizovat rozvržení vyhledávací tabulky. Stále však existuje mnoho otevřených problémů, které je třeba vyřešit.
Druhou zajímavou výzkumnou otázkou v obvodech je uspořádání obvodu. Důvod, proč front-end Scroll používá Plonkish, je ten, že průběh provádění EVM se dynamicky mění a musí být schopen podporovat různá omezení a měnící se testy ekvivalence, a standardizované hradlo R1CS vyžaduje implementaci většího měřítka obvodu. Scroll však v současné době používá více než 2 000 vlastních hradel, aby vyhovoval dynamicky se měnícím trasám provádění, a také zkoumá, jak dále optimalizovat rozložení obvodů, včetně rozdělení Opcode na Micro Opcode nebo opětovného použití buněk ve stejné tabulce.
Třetí zajímavou výzkumnou otázkou v obvodech je dynamické škálování. Protože škála obvodů různých operačních kódů je různá, ale abychom splnili dynamicky se měnící průběh provádění, operační kód každého kroku musí splňovat maximální měřítko obvodu, jako je Keccak hash, takže ve skutečnosti platíme další režii. Za předpokladu, že dokážeme přimět zkEVM dynamicky se přizpůsobovat dynamicky se měnícím trasám provádění, ušetří to zbytečnou režii.
dokazovat
Pokud jde o důkazy, Scroll provedl mnoho optimalizací pro MSM a NTT, pokud jde o akceleraci GPU, ale nyní se úzké hrdlo posunulo k generování a kopírování dat. Protože se předpokládá, že MSM a NTT zabírají 80 % doby důkazu, i když hardwarová akcelerace může tuto efektivitu zlepšit o několik řádů, původní 20% doba důkazu generování svědků a kopírování dat se stane novým úzkým hrdlem. Dalším problémem dokazovače je, že vyžaduje hodně paměti, takže je třeba prozkoumat levnější a decentralizovanější hardwarová řešení.
Současně Scroll také zkoumá hardwarovou akceleraci a algoritmy důkazu pro zlepšení efektivity testerů. V současné době existují dva hlavní směry, buď přechod na menší doménu, jako je použití 64bitové domény Zlatovláska, 32bitové Mersenne Prime atd., nebo setrvání u nového systému důkazů založeného na eliptických křivkách (EC například SuperNova). . Samozřejmě existují i jiné možné cesty a přátelé s nápady mohou kontaktovat přímo Scroll.
bezpečnost
Při budování zkEVM je bezpečnost prvořadá. ZkEVM společně vytvořený společnostmi PSE a Scroll má přibližně 34 000 řádků kódu Z hlediska softwarového inženýrství je nemožné, aby tyto složité základny kódu byly po dlouhou dobu bez zranitelností. Scroll v současné době přezkoumává kódovou základnu zkEVM prostřednictvím velkého počtu auditů, včetně auditů od nejlepších auditorských firem v oboru.
Část 4 zkoumá další aplikace, které používají zkEVM.
V architektuře zkRollup ověřujeme, že n transakcí na L2 je platných prostřednictvím smart kontraktu na L1.
Pokud ověřujeme přímo blok L1, pak uzel L1 nemusí opakovaně provádět transakci, ale potřebuje pouze ověřit platnost každého blokového certifikátu. Takové architektonické řešení se nazývá Enshrine Blockchain. V současné době je velmi obtížné implementovat přímo na Ethereum, protože je třeba ověřit celý blok Etherea, což bude zahrnovat ověření velkého počtu podpisů, což má za následek delší dobu ověřování a nižší zabezpečení. Samozřejmě již existují některé další veřejné řetězce, které používají rekurzivní důkazy k ověření celého blockchainu pomocí jediného důkazu, jako je Mina.
Protože zkEVM může prokázat přechody mezi stavy, může být také použit bílými klobouky k prokázání, že znají zranitelnost určitých chytrých kontraktů a hledají odměny od účastníků projektu.
Posledním případem použití je dokázat tvrzení o historických datech prostřednictvím důkazu s nulovými znalostmi a použít je jako věštce, které v této oblasti v současnosti vyrábí společnost Axiom. Na nedávném ETHBeijing Hackathonu využil tým GasLockR tuto funkci, aby dokázal historickou režii plynu.
Nakonec společnost Scroll vytváří univerzální škálovací řešení od zkRollup pro Ethereum pomocí velmi pokročilých aritmetických obvodů a důkazních systémů a vytváří rychlé ověřovače prostřednictvím hardwarové akcelerace k prokázání rekurze. V současné době je testovací síť Alpha online a funguje dlouhodobě stabilně.
Samozřejmě stále existují některé zajímavé problémy, které je třeba vyřešit, včetně návrhu protokolu a návrhu mechanismu, inženýrství s nulovými znalostmi a skutečné efektivity.
