Przewodnik programisty po zkGalaxy

Jest to niezwykle przydatna heurystyka do różnicowania podejść do obsługi zkEVM. Jednak zkEVM są podzbiorem wszystkich możliwych sposobów budowania aplikacji o zerowej wiedzy. Dla programisty, który chce wykorzystać unikalne właściwości obliczeń zk, a mianowicie zwięzłość, zero wiedzy i poprawność, zkEVM może nie być najlepszym wyborem. Mam nadzieję, że przedstawiając cały zestaw narzędzi programistycznych, zapewnię przewodnik, który pomoże w procesie podejmowania decyzji dotyczących odpowiedniego stosu ZK dla Twojej aplikacji.

W ciągu ostatniego roku lub dwóch nastąpił ogromny postęp w narzędziach zk. Zbliżają się do punktu, w którym zwykli programiści mogą wykorzystać potężne właściwości zk bez głębokiego zrozumienia zastraszającej matematyki i inżynierii. Z drugiej strony pojawiło się wiele narzędzi dla zaawansowanych użytkowników, które dają ekspertom zk niezwykle precyzyjną kontrolę nad stosem zk.

Nowoczesne oprogramowanie jest zbudowane na niezliczonych warstwach abstrakcji, aby zmaksymalizować produktywność specjalistów. Istnieje wiele zalet abstrakcji w inżynierii, które są nieco intuicyjne — programista stron internetowych nie musi dogłębnie rozumieć, jak działają systemy operacyjne. 

Kluczem do zbudowania dobrych warstw abstrakcji wielokrotnego użytku jest hermetyzacja złożoności warstwy, a następnie zapewnienie prostych, ale wyrazistych interfejsów dla warstw znajdujących się wyżej w stosie. Prawidłowo wykonane, umożliwia to programistom z różnymi obszarami wiedzy i doświadczenia tworzenie przydatnych narzędzi w całym stosie.

Nic dziwnego, że te same zasady dotyczą systemów zk, a te warstwy abstrakcji stają się na tyle dojrzałe, że nowicjusz zk może już dziś zacząć ich używać i tworzyć aplikacje.

Arkworks-rs to ekosystem bibliotek Rust, który zapewnia wydajne i bezpieczne implementacje podkomponentów aplikacji zkSNARK. Arkworks zapewnia interfejsy niezbędne programistom do dostosowania stosu oprogramowania dla aplikacji ZK bez konieczności ponownego wdrażania podobieństw z innymi istniejącymi bibliotekami.

Przed Arkworks jedynym sposobem na stworzenie nowej aplikacji ZK było zbudowanie wszystkiego od podstaw. Kluczowe zalety Arkworks-rs w porównaniu z niestandardowymi, zintegrowanymi pionowo narzędziami to poziom elastyczności, ograniczenie powielania inżynierii oraz zmniejszenie nakładów pracy związanych z audytem. Rozsądne linie interfejsów między komponentami Arkworks pozwalają na tempo aktualizacji, które może utrzymać stos na odpowiednim poziomie pośród zawrotnego tempa innowacji w technologiach zk, bez zmuszania zespołów do przebudowywania wszystkiego od zera.

Arkworks jest przeznaczony dla projektów, które wymagają dokładnej kontroli nad całym stosem oprogramowania ZK, ale nie chcą budować od zera wszystkich zbędnych elementów. Jeśli rozważasz niestandardową wersję obwodu DSL, ponieważ na przykład tworzysz prototyp nowego systemu dowodowego, ale nie masz pewności co do schematu zobowiązań lub odpowiedniej krzywej eliptycznej, arkworks pozwoli ci szybko przełączać się między kilkoma opcjami ze współdzielonymi interfejsami, a nie niż zaczynać od zera.

Aby stworzyć dowód na temat niektórych obliczeń, najpierw obliczenia te muszą być wyrażone w formie zrozumiałej dla systemu zkSNARK. Kilka języków specyficznych dla domeny stworzyło języki programowania, które umożliwiają twórcom aplikacji wyrażanie swoich obliczeń w taki sposób. Obejmują one Czarny Aztek, Starkneta Kair, Okrąg, ZoKratesi Aleo Lew pośród innych. Podstawowy system dowodowy i szczegóły matematyczne na ogół nie są ujawniane twórcy aplikacji.

Deweloperzy zkApp muszą być biegli w pisaniu swoich programów w językach specyficznych dla domeny. Niektóre z tych języków bardzo przypominają znane języki programowania, podczas gdy inne mogą być dość trudne do nauczenia. Podzielmy kilka z nich:

Kair – Starkware DSL niezbędny do tworzenia aplikacji w Starknet. Kompiluje się do specyficznego dla Kairu języka asemblera, który może być interpretowany przez Cairo zkVM.

ZoKrates — ZoKrates to zestaw narzędzi do typowych potrzeb SNARK, w tym języka wysokiego poziomu do pisania obwodów. ZoKrates ma również pewną elastyczność w zakresie krzywych, schematu sprawdzania i zaplecza, umożliwiając programistom wymianę na gorąco za pomocą prostego argumentu CLI.

Okrąg — Circom to specjalnie zaprojektowany język do konstruowania obwodów. Obecnie jest to de facto język dla obwodów w produkcji. Język nie jest szczególnie ergonomiczny. Sam język sprawia, że ​​jesteś świadomy faktu, że piszesz obwody.

Lew — Leo został opracowany jako język dla łańcucha bloków Aleo. Leo ma pewną składnię podobną do Rust i jest specjalnie stworzony do przejść między stanami wewnątrz łańcucha bloków.

Noir – Składnia inspirowana rdzą. Zbudowany wokół IR, a nie samego języka, co oznacza, że ​​może mieć dowolny interfejs. 

Każdy twórca aplikacji, który chce wykorzystać unikalne właściwości zk w swojej aplikacji. Niektóre z tych języków zostały przetestowane w walce z miliardami dolarów przepływającymi między nimi za pośrednictwem sieci takich jak ZCash i Starknet. Chociaż niektóre projekty, które omówimy, nie są jeszcze gotowe do użytku produkcyjnego, pisanie obwodów w jednym z tych języków jest obecnie najlepszą strategią, chyba że potrzebujesz dokładniejszego sterowania, które zapewnia zestaw narzędzi, taki jak Arkworks.

Głównym celem zkEVM jest dokonanie zmiany stanu Ethereum i udowodnienie jej ważności za pomocą zwięzłego dowodu poprawności z wiedzą zerową. Jak wspomniano w poście Vitalika, istnieje wiele sposobów na zrobienie tego z subtelnymi różnicami i odpowiednimi kompromisami. 

Główna różnica techniczna między nimi polega na tym, gdzie w stosie językowym obliczenia są konwertowane na formę (arytmetykę), którą można wykorzystać w systemie dowodzenia. W niektórych zkEVM dzieje się tak w językach wysokiego poziomu (Solidity, Vyper, Yul), podczas gdy inne podejścia próbują udowodnić EVM aż do poziomu kodu operacji. Kompromisy między tymi podejściami zostały szczegółowo omówione w poście Vitalika, ale podsumuję to w jednym zdaniu: im niższa konwersja/arytmetyka w stosie, tym większy spadek wydajności.

Głównym wyzwaniem przy tworzeniu dowodów dla maszyny wirtualnej jest to, że rozmiar obwodu rośnie proporcjonalnie do rozmiaru WSZYSTKICH możliwych instrukcji dla każdej wykonanej instrukcji. Dzieje się tak, ponieważ obwód nie wie, jakie instrukcje zostaną wykonane w każdym programie, więc musi obsługiwać je wszystkie.

W praktyce oznacza to, że płacisz (w kosztach wykonania) za najdroższą możliwą instrukcję, nawet jeśli wykonujesz tylko najprostszą instrukcję. Prowadzi to do bezpośredniego kompromisu między możliwością uogólnienia a wydajnością — dodając więcej instrukcji dotyczących możliwości uogólnienia, płacisz za to każdy instrukcja, którą udowodnisz!

Jest to podstawowy problem z obwodami uniwersalnymi, ale z nowe osiągnięcia w technologiach podobnie jak IVC (przyrostowe weryfikowalne obliczenia), to ograniczenie można złagodzić, dzieląc obliczenia na mniejsze części, z których każda ma wyspecjalizowane, mniejsze podukłady.

Dzisiejsze implementacje zkEVM wykorzystują różne strategie, aby złagodzić wpływ tego problemu… Na przykład zkSync usuwa droższe operacje (głównie wstępne kompilacje kryptograficzne, takie jak skróty i ECDSA) z głównego obwodu potwierdzającego wykonanie do osobnych obwodów, które są agregowane razem na koniec przez rekurencję snark. Firma zkSync przyjęła to podejście, gdy zdała sobie sprawę, że większość ich kosztów pochodzi z kilku skomplikowanych instrukcji.

Zasadniczo powodem, dla którego udowodnienie zestawu instrukcji bardziej równoważnego EVM jest droższe, jest to, że EVM nie został zaprojektowany do obliczeń zk. Porzucenie EVM wcześniej na stosie pozwala zkEVM działać na zestawach instrukcji, które są bardziej zoptymalizowane pod kątem zk, a tym samym tańsze do udowodnienia.

Idealnymi klientami dla zkEVM są inteligentne aplikacje kontraktowe, które wymagają transakcji o rząd wielkości tańszych niż te dostępne w L1 Ethereum. Ci programiści niekoniecznie mają wiedzę ani przepustowość, aby pisać aplikacje ZK od podstaw. Dlatego wolą pisać swoje aplikacje w znanych im językach wyższego poziomu, takich jak Solidity. 

Skalowanie Ethereum jest obecnie najbardziej pożądanym zastosowaniem technologii zk.

ZkEVM to skalowalne rozwiązanie Ethereum, które bezproblemowo łagodzi problem przeciążenia, który ogranicza programistów L1 dApp.

Celem zkEVM jest wspieranie doświadczenia programisty, które jest jak najbardziej zbliżone do obecnego rozwoju Ethereum. Pełna obsługa Solidity oznacza, że ​​zespoły nie muszą budować i utrzymywać wielu baz kodu. Jest to nieco niepraktyczne, aby zrobić to doskonale, ponieważ zkEVM muszą zrezygnować z pewnej kompatybilności, aby móc generować dowody o rozsądnej wielkości w rozsądnym czasie.

Podstawowa różnica między zkSync i Scroll polega na tym, gdzie/kiedy w stosie wykonują arytmetykę — to znaczy, gdzie konwertują normalne konstrukcje EVM na reprezentację przyjazną dla SNARK. W przypadku zkSync dzieje się tak, gdy konwertują kod bajtowy YUL na własny niestandardowy zestaw instrukcji zk. W przypadku Scroll dzieje się to na końcu, kiedy rzeczywisty ślad wykonania jest generowany z rzeczywistymi kodami operacyjnymi EVM.

Tak więc w przypadku zkSync wszystko jest takie samo, jak interakcja z EVM, dopóki nie zostanie wygenerowany kod bajtowy zk. W przypadku Scroll wszystko jest takie samo, dopóki nie zostanie wykonany rzeczywisty kod bajtowy. Jest to subtelna różnica, która zamienia wydajność na wsparcie. Na przykład zkSync nie obsługuje narzędzi kodu bajtowego EVM, takich jak debugger po wyjęciu z pudełka, ponieważ jest to zupełnie inny kod bajtowy. Podczas gdy Scroll będzie miał większe trudności z uzyskaniem dobrej wydajności z zestawu instrukcji, który nie został zaprojektowany dla zk. Obie strategie mają zalety i wady, a ostatecznie istnieje wiele czynników egzogenicznych, które będą miały wpływ na ich względny sukces.

💡 Pomimo swojej nazwy LLVM nie jest maszyną wirtualną (VM). LLVM to nazwa zestawu narzędzi kompilatora, który jest zakotwiczony przez reprezentację pośrednią (IR), która jest niezależna od języka.

= zero; Fundacja (jeśli chodzi o nazwę, to a Żart z iniekcji SQL jeśli się zastanawiasz) buduje kompilator, który może przekonwertować dowolny język frontendu LLVM na pośrednią reprezentację, którą można udowodnić w SNARK. ZkLLVM jest zaprojektowany jako rozszerzenie istniejącej infrastruktury LLVM, standardowego w branży łańcucha narzędzi, który obsługuje wiele języków wysokiego poziomu, takich jak Rust, C, C++ itp.

Użytkownik, który chce udowodnić pewne obliczenia, po prostu zaimplementowałby to obliczenie w C++. ZkLLVM bierze ten wysokopoziomowy kod źródłowy, który jest obsługiwany przez ich zmodyfikowany kompilator clang (obecnie C++) i generuje pośrednią reprezentację obwodu. W tym momencie obwód jest gotowy do udowodnienia, ale użytkownik może chcieć udowodnić obwód na podstawie niektórych dynamicznych danych wejściowych. Aby obsłużyć dynamiczne dane wejściowe, zkLLVM ma dodatkowy komponent określany jako przypisujący, który generuje tabelę przypisań ze wszystkimi wejściami i świadkami w pełni wstępnie przetworzonymi i gotowymi do udowodnienia wraz z obwodem.

Te 2 elementy to wszystko, co jest potrzebne do wygenerowania dowodu. Użytkownik może teoretycznie sam wygenerować dowód, ale ponieważ jest to nieco wyspecjalizowane zadanie obliczeniowe, może chcieć zapłacić komuś innemu, kto ma sprzęt, aby zrobił to za nich. Dla tego mechanizmu wykrywania kontrahentów =nil; Fundacja ustanowiła również „rynek prób”, na którym osoby dowodzące walczą o udowodnienie obliczeń dla użytkowników, którzy zapłacą im za to. Ta wolnorynkowa dynamika doprowadzi do optymalizacji najbardziej wartościowych zadań.

Ponieważ każde zadanie obliczeniowe, które ma zostać udowodnione, jest unikalne i generuje inny obwód, istnieje nieskończona liczba obwodów, z którymi osoby dowodzące będą musiały sobie poradzić. Ta wymuszona uogólnienie utrudnia optymalizację poszczególnych obwodów. Wprowadzenie rynku próbnego umożliwia specjalizację w obwodach, które rynek uznaje za wartościowe. Bez tego rynku trudno byłoby przekonać eksperta do optymalizacji tego obwodu ze względu na ten naturalny problem z zimnym startem.

Innym kompromisem jest klasyczna abstrakcja kontra kontrola. Użytkownicy, którzy chcą skorzystać z tego łatwego w użyciu interfejsu, rezygnują z kontroli nad kryptograficznymi prymitywami. Dla wielu użytkowników jest to bardzo ważny kompromis, ponieważ często lepiej jest pozwolić ekspertom od kryptografii podejmować te decyzje za Ciebie.

ZkVM opisuje nadzbiór wszystkich maszyn wirtualnych zk, podczas gdy zkEVM to specyficzny typ zkVM, który warto omówić jako osobny temat ze względu na jego powszechność w dzisiejszych czasach. Istnieje kilka innych projektów, które pracują nad budowaniem bardziej uogólnionych maszyn zkVM, które są oparte na ISA, oprócz niestandardowych maszyn kryptograficznych.

Zamiast sprawdzać EVM, system mógłby udowodnić inną architekturę zestawu instrukcji (ISA), taką jak RISC-V lub WASM w nowej maszynie wirtualnej. Dwa projekty, które pracują nad tymi uogólnionymi maszynami zkVM, to RISC Zero i zkWASM. Zanurzmy się tutaj trochę w RISC Zero, aby zademonstrować, jak działa ta strategia i niektóre z jej zalet i wad. 

RISC Zero jest w stanie udowodnić dowolne obliczenia wykonywane w architekturze RISC-V. RISC-V to standard architektury zestawu instrukcji (ISA) typu open source, który zyskuje na popularności. Filozofia RISC (komputer o zredukowanym zestawie instrukcji) polega na zbudowaniu niezwykle prostego zestawu instrukcji przy minimalnej złożoności. Oznacza to, że programiści na wyższych warstwach stosu biorą na siebie większe obciążenie implementacją instrukcji przy użyciu tej architektury, jednocześnie upraszczając implementację sprzętową.

Ta filozofia ma zastosowanie również do ogólnych obliczeń, układy ARM wykorzystują zestawy instrukcji w stylu RISC i zaczęły dominować na rynku układów mobilnych. Okazuje się, że prostsze zestawy instrukcji mają również większą wydajność energetyczną i obszarową matrycy.

Ta analogia całkiem dobrze pasuje do wydajności generowania dowodów zk. Jak omówiono wcześniej, udowadniając ślad wykonania w zk, płacisz za sumę kosztów wszystkich instrukcji za każdy element w śladzie, więc im prostsza i mniejsza liczba całkowitych instrukcji, tym lepiej.

Z perspektywy programisty używanie RISC Zero do obsługi dowodów ZK jest bardzo podobne do używania funkcji AWS Lambda do obsługi architektury serwera zaplecza. Deweloperzy współpracują z RISC Zero lub AWS Lambda, po prostu pisząc kod, a usługa obsługuje całą złożoność zaplecza.

Dla RISC Zero programiści piszą Rust lub C++ (ostatecznie wszystko, co jest ukierunkowane na RISC-V). Następnie system bierze plik ELF wygenerowany podczas kompilacji i używa go jako kodu wejściowego dla obwodu VM. Deweloperzy po prostu wywołują Prove, który zwraca obiekt pokwitowania (zawierający dowód ZK śladu wykonania), który każdy może wywołać „verify” z dowolnego miejsca. Z punktu widzenia programisty nie ma potrzeby rozumienia, jak działa zk, system bazowy obsługuje całą tę złożoność.

W przypadku niektórych podstawowych i wielokrotnego użytku obwodów, które są szczególnie przydatne w aplikacjach blockchain lub gdzie indziej, zespoły mogły już zbudować i zoptymalizować te obwody. Możesz po prostu podać dane wejściowe dla konkretnego przypadku użycia. Na przykład dowód włączenia Merkle jest czymś, co jest powszechnie potrzebne w aplikacjach kryptograficznych (listy zrzutów, Tornado Cash itp.). Jako twórca aplikacji zawsze możesz ponownie wykorzystać te sprawdzone w boju kontrakty i po prostu zmodyfikować warstwy na wierzchu, aby stworzyć unikalną aplikację.

Na przykład obwody Tornado Cash mogą być ponownie wykorzystane do prywatna aplikacja zrzutu lub prywatna aplikacja do głosowania. Manta i Semaphore budują cały zestaw narzędzi wspólnych gadżetów obwodów, takich jak ten, które mogą być używane w kontraktach Solidity z niewielkim lub żadnym zrozumieniem leżącej u podstaw matematyki ZK Moon.

Jak szczegółowo omówiono, istnieje mnóstwo różnych opcji tworzenia aplikacji ZK, z których każda ma własny, unikalny zestaw kompromisów. Ten wykres pomoże podsumować tę macierz decyzyjną, tak aby w oparciu o poziom wiedzy specjalistycznej ZK i potrzeby w zakresie wydajności można było wybrać najlepsze narzędzie do danego zadania. To nie jest wyczerpująca lista, planuję ją uzupełnić w przyszłości, gdy dowiem się o kolejnych narzędziach pojawiających się w przestrzeni.

zk znajduje się w czołówce kilku technologii, a jego zbudowanie wymaga głębokiego zrozumienia matematyki, kryptografii, informatyki i inżynierii sprzętowej. Jednak przy coraz większej liczbie warstw abstrakcji dostępnych każdego dnia twórcy aplikacji mogą wykorzystać moc zk bez doktoratu. Ponieważ ograniczenia czasu sprawdzania są powoli znoszone w miarę upływu czasu poprzez optymalizacje na wszystkich poziomach stosu, prawdopodobnie zobaczymy jeszcze prostsze narzędzia dla przeciętnego programisty.

Mam nadzieję, że przekonałem cię, ciekawskiego programistę, że już dziś możesz zacząć używać zk w swoich aplikacjach. Miłego hakowania 🙂

Ujawnienia: Blockchain Capital jest inwestorem w kilka z wyżej wymienionych protokołów.

Poglądy wyrażone w każdym poście na blogu mogą być osobistymi poglądami każdego autora i niekoniecznie odzwierciedlają poglądy Blockchain Capital i jej podmiotów stowarzyszonych. Ani Blockchain Capital, ani autor nie gwarantują dokładności, adekwatności ani kompletności informacji zawartych w każdym poście na blogu. Żadne oświadczenie ani gwarancja, wyraźna lub dorozumiana, nie jest składana ani udzielana w imieniu Blockchain Capital, autora lub jakiejkolwiek innej osoby co do dokładności, kompletności lub rzetelności informacji zawartych w jakimkolwiek poście na blogu i nie przyjmuje się żadnej odpowiedzialności ani odpowiedzialności za wszelkie tego typu informacje. Żadne informacje zawarte w każdym poście na blogu nie stanowią porady inwestycyjnej, regulacyjnej, prawnej, zgodności, podatkowej ani innej ani nie należy na nich polegać przy podejmowaniu decyzji inwestycyjnych. Wpisów na blogu nie należy postrzegać jako obecnych lub przeszłych rekomendacji lub propozycji kupna lub sprzedaży jakichkolwiek papierów wartościowych lub przyjęcia jakiejkolwiek strategii inwestycyjnej. Posty na blogu mogą zawierać prognozy lub inne stwierdzenia dotyczące przyszłości, które są oparte na przekonaniach, założeniach i oczekiwaniach, które mogą ulec zmianie w wyniku wielu możliwych zdarzeń lub czynników. Jeśli nastąpi zmiana, rzeczywiste wyniki mogą znacznie różnić się od tych przedstawionych w stwierdzeniach dotyczących przyszłości. Wszystkie stwierdzenia dotyczące przyszłości są aktualne wyłącznie w dniu ich złożenia i ani Blockchain Capital, ani żaden z autorów nie przyjmuje na siebie żadnego obowiązku aktualizowania takich oświadczeń, z wyjątkiem przypadków wymaganych przez prawo. W zakresie, w jakim jakiekolwiek dokumenty, prezentacje lub inne materiały wyprodukowane, opublikowane lub w inny sposób dystrybuowane przez Blockchain Capital są przywoływane w jakimkolwiek poście na blogu, takie materiały należy czytać ze szczególną uwagą na wszelkie zawarte w nich zastrzeżenia.