Współzałożyciel Scroll, Zhang Ye, opowiedział o czterech częściach. W pierwszej części Zhang Ye przedstawił tło rozwoju oraz dlaczego w ogóle potrzebujemy zkEVM i dlaczego stał się on tak popularny w ciągu ostatnich dwóch lat wyjaśnił, w jaki sposób kompletny proces budowania zkEVM od podstaw obejmuje systemy arytmetyczne i dowodowe. Trzecia część omawia problemy napotkane podczas budowania zkEVM przez kilka interesujących pytań badawczych, a na koniec przedstawia kilka innych aplikacji wykorzystujących zkEVM.
Tradycyjny blockchain warstwy 1 będzie miał kilka węzłów utrzymywanych razem za pośrednictwem sieci P2P. Po otrzymaniu transakcji użytkownika wykona ją na maszynie wirtualnej EVM, odczyta kontrakt wywołujący i pamięć oraz zaktualizuje globalne drzewo stanów zgodnie z transakcją.
Zaletą takiej architektury jest decentralizacja i bezpieczeństwo. Wadą jest to, że opłaty transakcyjne na L1 są wysokie, a potwierdzanie transakcji jest powolne.
W architekturze ZK-Rollup sieć L2 musi jedynie przesłać dane i dowód, aby zweryfikować poprawność danych do L1, gdzie dowód jest obliczany za pomocą obwodu sprawdzającego o wiedzy zerowej.
We wczesnym ZK-Rollup obwód był zaprojektowany dla konkretnych aplikacji. Użytkownicy musieli wysyłać transakcje do różnych programów sprawdzających, a następnie ZK-Rollupy różnych aplikacji przesyłały własne dane i dowody do L1. Problem polega na tym, że utracona zostaje możliwość tworzenia oryginalnego kontraktu L1.
To, co robi Scroll, to natywne rozwiązanie zkEVM, które jest ZK-Rollupem ogólnego przeznaczenia. Jest to nie tylko bardziej przyjazne dla użytkownika, ale także zapewnia programistom lepsze doświadczenia programistyczne w L1. Oczywiście rozwój tego jest bardzo trudny, a koszt bieżącego generowania dowodów jest również bardzo wysoki.
Na szczęście w ciągu ostatnich dwóch lat skuteczność dowodów z wiedzą zerową znacznie się poprawiła, dlatego zkEVM stał się w ciągu ostatnich dwóch lat tak popularny. Istnieją co najmniej cztery powody, dla których stało się to wykonalne. Pierwszym jest pojawienie się zaangażowania wielomianowego. W pierwotnym systemie dowodowym Groth16 skala ograniczeń była bardzo duża, ale zaangażowanie wielomianowe może wspierać ograniczenia wyższego rzędu i zmniejszać skalę. dowód; po drugie, pojawienie się tabel przeglądowych i niestandardowych bramek może obsługiwać bardziej elastyczne projekty i zwiększyć wydajność dowodów. Trzeci to przełom w akceleracji sprzętowej, który może skrócić czas sprawdzania o 1-2 rzędy wielkości za pomocą procesorów graficznych, FPGA i ASIC. . Czwarty W ramach dowodu rekurencyjnego można skompresować wiele dowodów w jeden, dzięki czemu dowód jest mniejszy i łatwiejszy do sprawdzenia. Zatem łącząc te cztery czynniki, wydajność generowania dowodów o wiedzy zerowej jest o trzy rzędy wielkości wyższa niż dwa lata temu, co jest również początkiem Scolla.
Zgodnie z definicją Justina Drake'a, zkEVM można podzielić na trzy kategorie. Pierwszą kategorią jest kompatybilność na poziomie języka. Głównym powodem jest to, że EVM nie jest zaprojektowany dla ZK i ma wiele opkodów, które nie są przyjazne dla ZK, więc spowoduje to awarię. dużo dodatkowych kosztów ogólnych. Dlatego firmy takie jak Starkware i zkSync decydują się na kompilowanie Solidity lub Yul do kompilatorów przyjaznych ZK na poziomie języka.
Drugi typ to zgodność na poziomie kodu bajtowego, którą wykonuje Scroll, która bezpośrednio potwierdza, czy przetwarzanie kodu bajtowego EVM jest prawidłowe, czy nie, i bezpośrednio dziedziczy środowisko wykonawcze Ethereum. Niektóre kompromisy, które można tutaj dokonać, polegają na użyciu innego katalogu głównego stanu niż EVM, na przykład przy użyciu struktury danych przyjaznej dla ZK. Hermez i Consensys robią coś podobnego.
Trzecią kategorią jest kompatybilność na poziomie konsensusu. Kompromis polega na tym, że konieczne jest nie tylko utrzymanie EVM w niezmienionej formie, ale także uwzględnienie struktury pamięci, aby osiągnąć pełną kompatybilność z Ethereum, kosztem dłuższego czasu sprawdzania. Scroll powstaje we współpracy z zespołem PSE Fundacji Ethereum w celu realizacji ZKizacji Ethereum.
W drugiej części Zhang Ye pokazał wszystkim, jak zbudować ZKVM od podstaw.
Kompletny proces
Przede wszystkim w front-endowej części ZKP musisz wyrazić swoje obliczenia za pomocą arytmetyki matematycznej. Najczęściej używane są liniowe R1CS, a także Plonkish i AIR. Po uzyskaniu ograniczeń za pomocą arytmetyki należy uruchomić algorytm dowodu na zapleczu ZKP, aby udowodnić poprawność obliczeń. Oto najczęściej używane wielomianowe interaktywne dowody Oracle (Polynomial IOP) i wielomianowy schemat zaangażowania (PCS).
Tutaj musimy udowodnić, że zkEVM i Scroll używają kombinacji Plonkish, Plonk IOP i KZG.
Aby zrozumieć, dlaczego używamy tych trzech rozwiązań. Najpierw zaczynamy od najprostszego R1CS. Ograniczenie w R1CS polega na tym, że kombinacja liniowa pomnożona przez kombinację liniową równa się kombinacji liniowej. Można dodać dowolną liniową kombinację zmiennych bez dodatkowego narzutu, ale maksymalna kolejność w każdym ograniczeniu wynosi 2. Dlatego w przypadku operacji wyższego rzędu wymaganych jest więcej ograniczeń.
W języku płońskim należy wypełnić tabelę wszystkimi zmiennymi, łącznie z danymi wejściowymi, wynikami i świadkami zmiennych pośrednich. Ponadto można zdefiniować różne ograniczenia. W języku płońskim dostępne są trzy typy ograniczeń.
Pierwszy typ ograniczenia to bramka niestandardowa. Można zdefiniować relacje więzów wielomianowych między różnymi komórkami, takie jak va3 * vb3 * vc3 - vb4 =0. W porównaniu z R1CS kolejność może być wyższa, ponieważ można zdefiniować ograniczenia dla dowolnej zmiennej i można zdefiniować bardzo różne ograniczenia.
Drugi rodzaj ograniczeń to Permuacja, czyli kontrola równości. Można go używać do sprawdzania równoważności różnych ogniw i często jest używany do kojarzenia różnych bramek w obwodzie, na przykład do udowadniania, że sygnał wyjściowy poprzedniej bramki jest równy wejściu następnej bramki.
Ostatnim typem ograniczenia jest tabela przeglądowa. Tablicę przeglądową możemy rozumieć jako relację między zmiennymi, którą można wyrazić w postaci tabeli. Na przykład chcemy udowodnić, że vc7 mieści się w zakresie 0-15. W R1CS musisz najpierw rozłożyć tę wartość na 4-bitowy plik binarny, a następnie udowodnić, że każdy bit mieści się w zakresie 0-1, co oznacza. będzie wymagać czterech ograniczeń. W języku Plonkish możesz wypisać wszystkie możliwe zakresy w tej samej kolumnie i wystarczy udowodnić, że vc7 należy do tej kolumny. Jest to bardzo skuteczne w przypadku sprawdzania zakresów. W zkEVM tabele przeglądowe są bardzo przydatne do potwierdzania odczytów i zapisów pamięci.
Podsumowując, Plonkish obsługuje również niestandardowe bramki, kontrole równoważności i tabele przeglądowe, które mogą być bardzo elastyczne, aby spełnić różne potrzeby obwodów. Proste porównanie STARK. Każdy wiersz w STARK jest ograniczeniem. Ograniczenie musi reprezentować przejście stanu między wierszami, ale elastyczność niestandardowych ograniczeń w języku Plonkish jest oczywiście większa.
Pytanie teraz brzmi jak wybrać front-end w zkEVM. Przed zkEVM stoją cztery główne wyzwania. Pierwszym wyzwaniem jest to, że pole EVM ma 256 bitów, co oznacza, że zmienne muszą być skutecznie ograniczone zakresem; drugim wyzwaniem jest to, że EVM ma wiele rozkazów nieprzyjaznych ZK, więc do udowodnienia tych operacji potrzebne są ograniczenia na bardzo dużą skalę; .kod, taki jak Keccak-256; trzecim wyzwaniem jest problem z odczytem i zapisem pamięci, potrzebujesz skutecznego mapowania, aby udowodnić, że to, co czytasz, jest zgodne z tym, co napisałeś wcześniej; zmienia się dynamicznie, dlatego potrzebujemy niestandardowych bramek, aby dostosować się do różnych śladów wykonania. Ze względu na powyższe rozważania wybraliśmy język płoński.
Następnie przyjrzyjmy się całemu procesowi zkEVM. W oparciu o początkowe globalne drzewo stanów, po nadejściu nowej transakcji, EVM odczyta kod bajtowy przechowywanych i wywoływanych kontraktów i wygeneruje odpowiednie ślady wykonania na podstawie transakcji, takie jak. PUSH, PUSH, STORE, CALLVALUE, a następnie stopniowo aktualizuj stan globalny, aby po transakcji uzyskać globalne drzewo stanów. zkEVM przyjmuje jako dane wejściowe początkowe globalne drzewo stanów, samą transakcję i globalne drzewo stanów po transakcji i wykorzystuje specyfikację EVM do sprawdzenia poprawności śledzenia wykonania.
Zagłębiając się w szczegóły obwodu EVM, każdy krok ścieżki wykonania ma odpowiednie ograniczenia obwodu. W szczególności ograniczenia obwodu każdego kroku obejmują kontekst kroku, zmianę obudowy i świadka specyficznego dla kodu operacji. Kontekst kroku zawiera skrót kodu, pozostały gaz i licznik odpowiadający śladowi wykonania; Case Switch zawiera wszystkie kody operacji, wszystkie warunki błędów i odpowiadające im operacje kroku; OpcodeSpecific Witness zawiera dodatkowe elementy wymagane przez kod operacji, takie jak operandy oczekiwania.
Biorąc za przykład proste dodawanie, musisz upewnić się, że zmienna sterująca sADD kodu operacji dodawania jest ustawiona na 1, a wszystkie zmienne sterujące innych kodów operacji mają wartość zero. W kontekście kroku zużycie gazu jest ograniczone do wartości 3 poprzez ustawienie gas' - gas - 3 = 0. Podobnie licznik stosu kumuluje 1 po kroku w Case Switch, czyli sumę zmienne są ustawiane na 1 poprzez kod operacji. Aby ograniczyć ten krok do operacji dodawania w OpcodeSpecific Witness, ogranicz faktyczne dodawanie operandów.
Ponadto wymagane są dodatkowe ograniczenia obwodów, aby zapewnić poprawność argumentów odczytywanych z pamięci. Tutaj najpierw musimy zbudować tabelę przeglądową, aby udowodnić, że operand należy do pamięci. I sprawdź poprawność tabeli pamięci poprzez obwód pamięci (obwód RAM).
Tę samą metodę można zastosować do funkcji skrótu nieprzyjaznych ZK. Zbuduj tabelę przeglądową funkcji skrótu, zmapuj wejście i wyjście skrótu w ścieżce wykonania na tabelę przeglądową i użyj dodatkowego obwodu skrótu do sprawdzenia funkcji skrótu poprawność tabeli przeglądowej.
Przyjrzyjmy się teraz architekturze obwodu zkEVM. Rdzeń obwodu EVM służy do ograniczania poprawności każdego kroku śledzenia wykonania. W niektórych miejscach, gdzie ograniczenia obwodu EVM są trudne, do mapowania używamy tabel przeglądowych, w tym tabeli stałej i Keccaka. Tabela, Tabela RAM, Kod bajtowy, Transakcja, Kontekst bloku, a następnie użyj oddzielnych obwodów, aby ograniczyć te tabele przeglądowe, takich jak obwody Keccaka, aby ograniczyć tabele Keccak.
Podsumowując, pełny przebieg pracy zkEVM pokazano na poniższym rysunku.
system dowodowy
Ponieważ bezpośrednia weryfikacja wyżej wymienionych obwodów EVM, obwodów pamięci, obwodów pamięci itp. na L1 jest kosztowna, system sprawdzający Scroll przyjmuje architekturę dwuwarstwową.
Pierwsza warstwa jest odpowiedzialna za bezpośrednie udowodnienie samego EVM, co wymaga dużej ilości obliczeń w celu wygenerowania dowodu. Dlatego wymagany jest system sprawdzający pierwszego poziomu, który będzie obsługiwał niestandardowe bramki i tabele przeglądowe, był przyjazny dla akceleracji sprzętowej, generował obliczenia równolegle przy małej pamięci szczytowej i miał mały obwód weryfikacyjny, który można szybko zweryfikować. Obiecujące alternatywy obejmują Plonky2, Starky i eSTARK. Wszystkie zasadniczo korzystają z Plonka w interfejsie, ale mogą używać FRI w tylnej części i wszystkie spełniają powyższe cztery cechy. Innym rodzajem alternatywnych rozwiązań jest Halo2 opracowane przez firmę Zcash oraz wersja Halo2 KZG.
Istnieje również kilka nowych systemów dowodowych, które są obiecujące, takie jak HyperPlonk, który niedawno usunął FFT, oraz system dowodowy NOVA, który może uzyskać mniejsze dowody rekurencyjne. Ale wspierają R1CS tylko w badaniach. Jeśli będą w stanie wesprzeć Plonkisha w przyszłości i zastosować go w praktyce, będzie to bardzo praktyczne i wydajne.
System sprawdzający drugiego poziomu służy do sprawdzania poprawności dowodu pierwszego poziomu i musi zostać skutecznie zweryfikowany w EVM. W idealnym przypadku powinien być przyjazny dla akceleracji sprzętowej i zapewniać przejrzystą lub uniwersalną konfigurację. Obiecujące alternatywy obejmują Groth16 i bezkolumnowy system dowodu Plonka. Groth16 jest nadal przedstawicielem niezwykle wysokiej wydajności dowodu w bieżących badaniach, a system dowodu Płońskiego może również osiągnąć wysoką skuteczność dowodu nawet przy małej liczbie kolumn.
W Scroll używamy systemu proofów Halo2-KZG w obu naszych dwuwarstwowych systemach proofów. Ponieważ Halo2-KZG może obsługiwać niestandardowe bramki i tabele przeglądowe, dobrze radzi sobie z akceleracją sprzętową GPU, a obwód weryfikacyjny jest niewielki i można go szybko zweryfikować. Różnica polega na tym, że używamy skrótu Poseidon w systemie dowodu pierwszej warstwy, aby jeszcze bardziej poprawić skuteczność dowodu, podczas gdy system dowodu drugiej warstwy nadal korzysta z mieszania Keccak, ponieważ jest on weryfikowany bezpośrednio w Ethereum. Scroll bada także możliwość zastosowania wielowarstwowego systemu dowodowego w celu dalszej agregacji zagregowanych dowodów wygenerowanych przez system dowodowy drugiego poziomu.
W obecnej implementacji obwód EVM systemu sprawdzającego pierwszego poziomu firmy Scroll ma 116 kolumn, 2496 bramek niestandardowych, 50 tabel przeglądowych, najwyższy rząd to 9 i wymaga 2^18 linii przy 1M gazu, podczas gdy system sprawdzający drugiego poziomu ma The obwód agregacji ma tylko 23 kolumny, 1 niestandardową bramkę, 7 tabel przeglądowych, a najwyższy rząd to 5. Aby zagregować obwód EVM, obwód pamięci i obwód pamięci, potrzebnych jest 2^25 wierszy.
Scroll wykonał także wiele prac badawczych i optymalizacyjnych nad akceleracją sprzętową GPU. W przypadku obwodów EVM zoptymalizowany tester GPU zajmuje tylko 30 sekund, czyli jest 9 razy bardziej wydajny niż tester CPU w przypadku obwodów agregacyjnych, po optymalizacji Tylko GPU zajmuje 149 s, czyli 15 razy wydajniej niż procesor. W obecnych warunkach optymalizacji system sprawdzający pierwszego poziomu 1M Gas zajmuje około 2 minut, a system sprawdzający drugiego poziomu zajmuje około 3 minut.
W trzeciej części Zhang Ye opowiedział o kilku interesujących zagadnieniach badawczych w procesie budowania zkEVM przez Scroll, od front-endowego obwodu arytmetycznego po implementację Provera.
okrążenie
Pierwszą z nich jest losowość w obwodzie. Ponieważ pole EVM ma 256 bitów, musimy je podzielić na 32 8-bitowe pola, aby efektywniej przeprowadzić kontrolę zasięgu. Następnie używamy metody Random Linear Combination (RLC), aby zakodować 32 pola w 1 przy użyciu liczb losowych. Musimy jedynie zweryfikować to pole, aby zweryfikować oryginalne 256-bitowe pole. Problem polega jednak na tym, że po podzieleniu pól należy wygenerować liczbę losową, aby mieć pewność, że nie zostanie ona naruszona. Dlatego Scroll i zespół PSE zaproponowali wieloetapowe rozwiązanie sprawdzające, które zapewni, że po podziale pól do wygenerowania RLC zostaną użyte liczby losowe. Rozwiązanie to jest zawarte w interfejsie API Challenge. RLC ma wiele scenariuszy zastosowań w zkEVM. Może nie tylko kompresować pole EVM w jedno pole, ale także szyfrować dane wejściowe o zmiennej długości lub optymalizować układ tabeli przeglądowej. Jednak nadal istnieje wiele otwartych problemów, które należy rozwiązać.
Drugim interesującym pytaniem badawczym dotyczącym obwodów jest układ obwodów. Powodem, dla którego front-end Scroll korzysta z języka Plonkish, jest to, że ślad wykonania EVM zmienia się dynamicznie i musi być w stanie obsługiwać różne ograniczenia i zmieniające się testy równoważności, a znormalizowana bramka R1CS wymaga do wdrożenia większej skali obwodów. Jednakże firma Scroll korzysta obecnie z ponad 2000 niestandardowych bramek, aby sprostać dynamicznie zmieniającym się śladom wykonania, a także bada możliwości dalszej optymalizacji układu obwodów, w tym dzielenia kodu operacji na kod operacji Micro lub ponownego wykorzystania komórek w tej samej tabeli.
Trzecim interesującym pytaniem badawczym w obwodach jest skalowanie dynamiczne. Ponieważ skala obwodu różnych kodów operacji jest inna, ale aby sprostać dynamicznie zmieniającemu się śladowi wykonania, kod operacji każdego kroku musi spełniać maksymalną skalę obwodu, taką jak mieszanie Keccaka, więc w rzeczywistości płacimy dodatkowe koszty ogólne. Zakładając, że uda nam się sprawić, że zkEVM będzie dynamicznie dostosowywał się do dynamicznie zmieniających się śladów wykonania, zaoszczędzi to niepotrzebnych kosztów ogólnych.
udowodnić
Jeśli chodzi o dowody, Scroll dokonał wielu optymalizacji dla MSM i NTT pod względem akceleracji GPU, ale teraz wąskie gardło przesunęło się w stronę generowania i kopiowania danych w trybie monitorowania. Ponieważ zakłada się, że MSM i NTT zajmują 80% czasu sprawdzania, nawet jeśli przyspieszenie sprzętowe może poprawić tę wydajność o kilka rzędów wielkości, pierwotny czas sprawdzania wynoszący 20% generowania i kopiowania danych stanie się nowym wąskim gardłem. Innym problemem związanym z dowodem jest to, że wymaga on dużej ilości pamięci, dlatego należy zbadać tańsze i bardziej zdecentralizowane rozwiązania sprzętowe.
Jednocześnie Scroll bada także algorytmy przyspieszania sprzętowego i sprawdzania, aby poprawić wydajność programów sprawdzających. Obecnie istnieją dwa główne kierunki: albo przejście na mniejszą domenę, na przykład użycie 64-bitowej domeny Goldilocks, 32-bitowej domeny Mersenne Prime itp., albo trzymanie się nowego systemu sprawdzającego opartego na krzywych eliptycznych (EC), na przykład SuperNova . Oczywiście istnieją inne możliwe ścieżki, a znajomych mających pomysły zapraszamy do bezpośredniego kontaktu ze Scrollem.
bezpieczeństwo
Podczas budowania zkEVM bezpieczeństwo jest najważniejsze. ZkEVM zbudowany wspólnie przez PSE i Scroll zawiera około 34 000 linii kodu. Z punktu widzenia inżynierii oprogramowania nie jest możliwe, aby te złożone podstawy kodu były przez długi czas wolne od luk. Scroll obecnie dokonuje przeglądu bazy kodu zkEVM poprzez dużą liczbę audytów, w tym przeprowadzonych przez czołowe firmy audytorskie w branży.
Część 4 omawia inne aplikacje korzystające z zkEVM.
W architekturze zkRollup weryfikujemy, czy n transakcji na L2 jest ważnych poprzez inteligentny kontrakt na L1.
Jeśli bezpośrednio zweryfikujemy blok L1, to węzeł L1 nie musi wielokrotnie wykonywać transakcji, a jedynie musi zweryfikować ważność każdego certyfikatu bloku. Takie rozwiązanie architektoniczne nazywa się Enshrine Blockchain. Obecnie bardzo trudno jest wdrożyć to bezpośrednio na Ethereum, ponieważ trzeba zweryfikować cały blok Ethereum, co będzie obejmować weryfikację dużej liczby podpisów, co spowoduje dłuższy czas weryfikacji i mniejsze bezpieczeństwo. Oczywiście istnieją już inne sieci publiczne, które wykorzystują dowody rekurencyjne do weryfikacji całego łańcucha bloków za pomocą jednego dowodu, np. Mina.
Ponieważ zkEVM może udowodnić zmiany stanu, może być również wykorzystywane przez białe kapelusze, aby udowodnić, że znają luki w zabezpieczeniach niektórych inteligentnych kontraktów i ubiegają się o nagrody od stron projektu.
Ostatnim przypadkiem użycia jest udowodnienie twierdzeń dotyczących danych historycznych za pomocą dowodu z wiedzą zerową i wykorzystanie ich jako wyroczni. Obecnie firma Axiom tworzy produkty w tym obszarze. Podczas niedawnego hackatonu ETHBeijing Hackathon zespół GasLockR wykorzystał tę funkcję, aby udowodnić historyczny narzut związany z gazem.
Wreszcie Scroll buduje uniwersalne rozwiązanie skalujące zkRollup dla Ethereum, wykorzystując bardzo zaawansowane obwody arytmetyczne i systemy dowodowe oraz budując szybkie weryfikatory poprzez przyspieszenie sprzętowe w celu udowodnienia rekurencji. Obecnie sieć testów alfa jest dostępna online i działa stabilnie przez długi czas.
Oczywiście nadal istnieje kilka interesujących problemów, które wymagają rozwiązania, w tym projekt protokołu i projekt mechanizmu, inżynieria oparta na wiedzy zerowej i rzeczywista wydajność. Każdy może dołączyć do Scroll, aby wspólnie budować!
