Tekst oryginalny: „Tygodniowe podsumowanie IOSG | Jak przetrwać ZKVM, szczegółowe wyjaśnienie sporów frakcyjnych #159”

Autor: Bryan, IOSG Ventures

Spis treści

Implementacja obwodowa systemu dowódowego ZKP - oparta na obwodach VS na maszynie wirtualnej (w oparciu o vm)

Zasady projektowania ZKVM

Porównanie maszyn wirtualnych opartych na STARK

Dlaczego Risc0 jest ekscytujący

Wydaje się, że główny nacisk w dyskusjach na temat rollupów w ubiegłym roku 2022 skupiał się na ZkEVM, ale nie zapominaj, że ZkVM to także kolejny sposób na ekspansję. Chociaż ZkEVM nie jest tematem tego artykułu, warto przypomnieć różnice między ZkVM i ZkEVM w kilku wymiarach:

Kompatybilność: Chociaż oba są rozszerzeniami, ich cele są różne. ZkEVM koncentruje się na bezpośrednim osiągnięciu kompatybilności z istniejącymi EVM, podczas gdy ZkVM jest nastawiony na osiągnięcie pełnej rozbudowy, to znaczy optymalizacji logiki i wydajności dappów, kompatybilność nie jest priorytetem. Po skonfigurowaniu dolnej warstwy można również osiągnąć kompatybilność z EVM. Wydajność: Obydwa mają stosunkowo przewidywalne wąskie gardła w wydajności. Głównym wąskim gardłem ZkEVM są dodatkowe koszty ponoszone, gdy kompatybilność z EVM nie jest odpowiednia do pakowania w systemie certyfikacji ZK. Wąskim gardłem ZkVM jest to, że w związku z wprowadzeniem zestawu instrukcji ISA ograniczenia dotyczące końcowego wyniku są bardziej złożone. Doświadczenie programisty: Typ II ZkEVM (taki jak Scroll, Taiko) koncentruje się na zgodności z kodem bajtowym EVM. Innymi słowy, kody EVM na poziomie kodu bajtowego i wyższym mogą generować odpowiednie dowody z wiedzą zerową za pośrednictwem ZkEVM. W przypadku ZkVM istnieją dwa kierunki. Jeden kierunek to stworzenie własnego DSL (np. Cairo), a drugi to zapewnienie kompatybilności z istniejącymi, bardziej dojrzałymi językami, takimi jak C++/Rust (np. Risc0). Oczekujemy, że w przyszłości programiści Ethereum zajmujący się natywną solidnością będą mogli migrować do ZkEVM bez żadnych kosztów, a nowsze i wydajniejsze aplikacje będą działać na ZkVM. Wiele osób powinno nadal pamiętać ten obraz. CairoVM nie ma nic wspólnego z ZkEVM. Zasadniczym powodem walki frakcyjnej jest różnica w pomysłach projektowych.

Zanim omówimy ZkVM, najpierw zastanawiamy się, jak wdrożyć system dowodu ZK w blockchainie. Ogólnie rzecz biorąc, istnieją dwa sposoby wdrażania obwodów – systemy oparte na obwodach i systemy oparte na maszynach wirtualnych (oparte na maszynach wirtualnych).

Przede wszystkim funkcją systemu opartego na obwodach jest bezpośrednie przekształcenie programu w ograniczenia i przesłanie ich do systemu sprawdzającego; system oparty na maszynie wirtualnej wykonuje program poprzez zestaw instrukcji (ISA). namierzać. Ten ślad wykonania zostanie następnie zmapowany na ograniczenia, a następnie przesłany do systemu sprawdzającego.

W przypadku systemu opartego na obwodach obliczanie programu jest ograniczone przez każdą maszynę, która wykonuje program. W przypadku systemów opartych na maszynach wirtualnych ISA jest wbudowany w generator obwodów i generuje ograniczenia programowe. Jednocześnie generator obwodów ma ograniczenia dotyczące zestawu instrukcji, cyklu wykonywania, pamięci itp. Maszyny wirtualne zapewniają wszechstronność, to znaczy, że każda maszyna może uruchomić program, jeśli warunki działania programu mieszczą się w powyższych ograniczeniach.

Program zkp na maszynie wirtualnej prawdopodobnie przechodzi następujący proces:

Źródło zdjęcia: Bryan, IOSG Ventures

Zalety i wady:

Z perspektywy programisty tworzenie systemów opartych na obwodach często wymaga głębokiego zrozumienia kosztów każdego ograniczenia. Jednakże w przypadku pisania programów na maszynach wirtualnych obwód jest statyczny i programiści muszą bardziej skupiać się na instrukcjach. Z perspektywy weryfikatora systemy oparte na obwodach i maszyny wirtualne różnią się znacznie pod względem ogólności obwodów, zakładając, że jako backend używany jest ten sam czysty SNARK. System obwodów tworzy inny obwód dla każdego programu, podczas gdy maszyna wirtualna tworzy ten sam obwód dla różnych programów. Oznacza to, że w ramach pakietu zbiorczego system obwodów musi wdrożyć wiele kontraktów weryfikatorów na L1. Z punktu widzenia aplikacji maszyna wirtualna komplikuje logikę aplikacji, osadzając model pamięci w projekcie, a celem wykorzystania układu obwodów jest poprawa wydajności programu. Z punktu widzenia złożoności systemu maszyny wirtualne obejmują większą złożoność systemu, na przykład modele pamięci, komunikację między hostem a gościem itp. Dla porównania system obwodów jest prostszy.

Poniżej znajduje się podgląd różnych projektów opartych na obwodach i maszynach wirtualnych znajdujących się obecnie w L1/L2:

Zdjęcie: Bryan, Zasady projektowania maszyn wirtualnych IOSG Ventures

W maszynach wirtualnych obowiązują dwie kluczowe zasady projektowania. Najpierw upewnij się, że program działa poprawnie. Innymi słowy, dane wyjściowe (tj. ograniczenie) i dane wejściowe (tj. program) powinny być poprawnie dopasowane. Zwykle odbywa się to za pomocą zestawu instrukcji ISA. Po drugie, upewnij się, że kompilator działa poprawnie podczas konwersji z języka wysokiego poziomu do odpowiedniego formatu ograniczenia.

1. Zestaw instrukcji ISA

Określa sposób działania generatora obwodu. Jego głównym zadaniem jest prawidłowe mapowanie instrukcji na ograniczenia, które następnie są wprowadzane do systemu sprawdzającego. Wszystkie systemy zk korzystają z RISC (zredukowanego zestawu instrukcji). Istnieją dwie opcje ISA:

Pierwsza polega na zbudowaniu niestandardowego ISA (custom ISA), co widać w projekcie Cairo. Ogólnie rzecz biorąc, istnieją cztery typy logiki ograniczeń, jak poniżej.

Podstawowym założeniem projektowym niestandardowego programu ISA jest zapewnienie jak najmniejszej liczby ograniczeń, tak aby zarówno wykonanie, jak i weryfikacja programu przebiegały szybko.

Drugim jest wykorzystanie istniejącego ISA (istniejącego ISA), który został przyjęty w projekcie Risc0. Oprócz ukierunkowania na czas czystego wykonania, istniejące ISA, takie jak Risc-V, oferują dodatkowe korzyści, takie jak łatwość obsługi języków front-endu i sprzętu backendu. Jedno (możliwe, że jeszcze nie rozwiązane) pytanie dotyczy tego, czy istniejące ISA będą opóźnione w czasie weryfikacji (ponieważ czas weryfikacji nie jest głównym celem projektu Risc-V).

2. Kompilator

Ogólnie rzecz biorąc, kompilator stopniowo tłumaczy język programowania na kod maszynowy. W kontekście ZK odnosi się do reprezentacji kodu niskiego poziomu wkompilowanej w system ograniczeń (R1CS, QAP, AIR itp.) przy użyciu języków wysokiego poziomu, takich jak C, C++, Rust itp. Istnieją dwie metody,

Zaprojektuj kompilator w oparciu o istniejące reprezentacje obwodów w ZK - na przykład w ZK reprezentacje obwodów zaczynają się od bezpośrednio wywoływalnych bibliotek, takich jak Bellman i języków niskiego poziomu, takich jak Circom. Aby agregować różne reprezentacje, kompilator taki jak Zokrates (sam będący DSL) ma na celu zapewnienie warstwy abstrakcji, którą można skompilować w dowolne reprezentacje niższego poziomu. Opieraj się na (istniejącej) infrastrukturze kompilatora. Podstawową logiką jest wykorzystanie pośredniej reprezentacji dla wielu frontendów i backendów.

Kompilator Risc0 opiera się na wielopoziomowej reprezentacji pośredniej (MLIR) i może generować wiele IR (podobnie jak LLVM). Różne IR zapewniają programistom elastyczność, ponieważ różne IR mają własne priorytety projektowe. Na przykład niektóre z nich są zoptymalizowane specjalnie pod kątem sprzętu, więc programiści mogą wybierać według własnych życzeń. Podobne pomysły można zobaczyć w vnTinyRAM i TinyRAM korzystających z GCC. ZkSync to kolejny przykład wykorzystania infrastruktury kompilatora.

Ponadto można również zobaczyć infrastrukturę kompilatora dla ZK, taką jak CirC, która również zapożycza pewne pomysły projektowe od LLVM.

Oprócz dwóch najważniejszych etapów projektowania opisanych powyżej, należy wziąć pod uwagę kilka innych kwestii:

1. Kompromis pomiędzy bezpieczeństwem systemu a kosztem weryfikacji

Im większa liczba bitów wykorzystywanych przez system (czyli większe bezpieczeństwo), tym wyższy koszt weryfikacji. Bezpieczeństwo jest odzwierciedlone w generatorze kluczy (takim jak reprezentowane w SNARK przez krzywą eliptyczną).

2. Kompatybilność z front-endem i back-endem

Zgodność zależy od dostępności pośredniej reprezentacji obwodu. IR wymaga równowagi pomiędzy poprawnością (czy wyjście programu pasuje do wejścia + czy wyjście jest zgodne z systemem sprawdzającym) i elastycznością (obsługuje wiele front-endów i back-endów). Jeśli technologia IR została pierwotnie zaprojektowana do rozwiązywania systemów ograniczeń niskiego stopnia, takich jak R1CS, zgodność z innymi systemami ograniczeń wyższego stopnia, takimi jak AIR, byłaby trudna.

3. Aby poprawić wydajność, wymagane są obwody wykonane ręcznie

Wadą stosowania modelu ogólnego przeznaczenia jest to, że jest on mniej wydajny w przypadku niektórych prostych operacji, które nie wymagają skomplikowanych instrukcji.

Opiszmy pokrótce kilka wcześniejszych teorii,

Przed protokołem Pinokia: Wdrożono weryfikowalne obliczenia, ale czas weryfikacji był bardzo długi. Protokół Pinokio: Zapewniono teoretyczną wykonalność pod względem sprawdzalności i wskaźnika powodzenia weryfikacji (tj. czas weryfikacji jest krótszy niż czas wykonania programu) i jest oparty. w systemie Circuit Protokół TinyRAM: W porównaniu z protokołem Pinocchio, TinyRAM bardziej przypomina maszynę wirtualną, wprowadzając ISA, więc pozbywa się pewnych ograniczeń, takich jak dostęp do pamięci (RAM), przepływ sterowania (przepływ sterowania) itp. Protokół vnTinyRAM : umożliwia generowanie klucza (generowanie klucza) nie jest zależne od każdego programu, zapewniając dodatkową wszechstronność. Rozbuduj generator obwodów, czyli będziesz w stanie obsłużyć większe programy.

Wszystkie powyższe modele używają SNARK jako systemu sprawdzającego backend, ale szczególnie w przypadku maszyn wirtualnych STARK i Plonk wydają się być bardziej odpowiednim backendem, zasadniczo dlatego, że ich systemy ograniczeń są bardziej odpowiednie do implementowania logiki podobnej do procesora.

Następnie w tym artykule zostaną przedstawione trzy maszyny wirtualne oparte na STARK — Risc0, MidenVM i CairoVM. W skrócie, z wyjątkiem tego, że obaj używają STARK jako systemu dowodowego, każdy z nich ma pewne różnice:

Risc0 wykorzystuje Risc-V dla uproszczenia zestawu instrukcji. R0 kompiluje się w MLIR, wariancie LLVM-IR zaprojektowanym do obsługi wielu istniejących języków programowania ogólnego przeznaczenia, takich jak Rust i C++. Risc-V ma również kilka dodatkowych zalet, takich jak większa przyjazność dla sprzętu.

Miden ma być kompatybilny z maszyną wirtualną Ethereum (EVM) i zasadniczo jest pakietem zbiorczym EVM. Miden ma teraz własny język programowania, ale pracuje także nad obsługą Move w przyszłości.

Cairo VM został opracowany przez Starkware. System sprawdzający STARK używany w tych trzech systemach został wynaleziony przez Eli Ben-Sassona, obecnie prezesa Starkware.

Przyjrzyjmy się bliżej różnicom między nimi:

* Jak czytać powyższą tabelę? Kilka notatek...

Rozmiar słowa — ponieważ system ograniczeń, na którym oparte są te maszyny wirtualne, to środowisko AIR, działa ono podobnie do architektury procesora. Dlatego bardziej właściwe jest wybranie długości słowa procesora (32/64 bity).

Dostęp do pamięci - Risc0 używa rejestrów głównie dlatego, że zestaw instrukcji Risc-V jest oparty na rejestrach. Miden używa głównie stosów do przechowywania danych, ponieważ środowisko AIR działa podobnie jak stosy. CairoVM nie używa rejestrów ogólnego przeznaczenia, ponieważ koszt dostępu do pamięci (pamięci głównej) w modelu Cairo jest niski.

Kanał programu (wykonanie programu) — istnieją kompromisy między różnymi metodami. Na przykład w przypadku metody korzenia masztu należy ją zdekodować w trakcie przetwarzania instrukcji, więc koszt sprawdzenia jest wyższy w programach z większą liczbą kroków wykonawczych. Metody ładowania początkowego mają na celu osiągnięcie równowagi między kosztem dowodu a kosztem weryfikatora, przy jednoczesnym zachowaniu prywatności.

Niedeterminizm - Niedeterminizm jest ważną właściwością problemów NP-zupełnych. Wykorzystanie niedeterminizmu pomaga szybko zweryfikować wcześniejsze egzekucje. Z drugiej strony dodaje więcej ograniczeń, a co za tym idzie, pewne kompromisy w walidacji.

Przyspieszenie złożonych operacji — niektóre obliczenia przebiegają bardzo wolno na procesorze. Na przykład operacje bitowe, takie jak XOR i AND, programy mieszające, takie jak ECDSA i sprawdzanie zakresu… głównie natywne dla technologii blockchain/szyfrowania, ale nie operacje natywne dla procesora (z wyjątkiem operacji bitowych). Implementacja tych operacji bezpośrednio przez DSL może łatwo doprowadzić do wyczerpania cykli sprawdzających.

Permutacja/zestaw wielokrotny — szeroko stosowany w większości maszyn zkVM z dwóch powodów: 1. Zmniejsz koszt weryfikatora, zmniejszając potrzebę przechowywania pełnego śladu wykonania 2. Udowodnij, że weryfikator zna pełny ślad wykonania

Na koniec artykułu chciałbym porozmawiać o obecnym rozwoju Risc0 i dlaczego mnie to ekscytuje.

Obecny rozwój R0:

a. Opracowana samodzielnie infrastruktura kompilatora „Zirgen” jest w fazie rozwoju. Byłoby interesujące porównać wydajność Zirgena z niektórymi istniejącymi kompilatorami specyficznymi dla ZK.

b. Niektóre interesujące innowacje, takie jak rozszerzenie pola, pozwalają uzyskać solidniejsze parametry bezpieczeństwa i działać na większych liczbach całkowitych.

c. Będąc świadkiem wyzwań związanych z integracją firm ZK Hardware i ZK Software, Risc0 wykorzystuje warstwę abstrakcji sprzętu, aby umożliwić lepszy rozwój po stronie sprzętu.

d.Nadal praca w toku. Wciąż w fazie rozwoju!

Obsługuje ręcznie wykonane obwody i obsługuje wiele algorytmów mieszania. Obecnie zaimplementowano dedykowane układy SHA256, jednak nie spełniają one wszystkich potrzeb. Autor uważa, że ​​konkretny wybór typu obwodu do optymalizacji zależy od przypadku użycia dostarczonego przez Risc0. SHA256 to bardzo dobry punkt wyjścia. Z drugiej strony ZKVM jest w stanie zapewnić ludziom elastyczność, aby na przykład nie musieli się martwić o Keccaka, jeśli nie chcą :)

Rekurencja: to obszerny temat i wolę nie zagłębiać się w niego w tym raporcie. Ważne jest, aby wiedzieć, że ponieważ Risc0 ma tendencję do obsługi bardziej złożonych przypadków/programów użycia, potrzeba rekurencji staje się bardziej nagląca. Aby jeszcze bardziej wspierać rekurencję, obecnie pracują nad rozwiązaniem sprzętowej akceleracji GPU.

Obsługa niedeterminizmu: Jest to właściwość, z którą musi sobie poradzić ZKVM, podczas gdy tradycyjne maszyny wirtualne nie mają tego problemu. Niedeterminizm może pomóc maszynom wirtualnym działać szybciej. MLIR stosunkowo lepiej radzi sobie z zagadnieniami związanymi z tradycyjnymi maszynami wirtualnymi i warto poczekać, jak Risc0 osadza niedeterminizm w projekcie systemu ZKVM.

CO MNIE PODNIECA:

a. Proste i sprawdzalne!

W systemie rozproszonym PoW wymaga wysokiego poziomu redundancji, ponieważ ludzie nie ufają innym i dlatego muszą wielokrotnie wykonywać te same obliczenia, aby osiągnąć konsensus. A dzięki wykorzystaniu dowodów o wiedzy zerowej uświadomienie sobie stanu powinno być tak proste, jak przyjęcie, że 1+1=2.

b. Bardziej praktyczne przypadki użycia:

Oprócz najbardziej bezpośredniej ekspansji możliwe staną się bardziej interesujące przypadki użycia, takie jak uczenie maszynowe o wiedzy zerowej, analiza danych itp. W porównaniu z określonymi językami ZK, takimi jak Cairo, Rust/C++ ma bardziej uniwersalne i wydajne funkcje, a na maszynie wirtualnej Risc0 działa więcej przypadków użycia web2.

c. Bardziej włączająca/dojrzała społeczność programistów:

Programiści zainteresowani STARK i blockchainem nie muszą już na nowo uczyć się DSL, mogą po prostu używać Rust/C++.

Dziękujemy Xin Gao, Boyuanowi z p0xeidon, Danielowi z Taiko i Sin7Y za wsparcie i sugestie dotyczące rewizji tego artykułu!