Autor: Kernel Ventures Turbo Guo

Redaktorzy: Kernel Ventures Rose, Kernel Ventures Mandy, Kernel Ventures Joshua

TLDR: Koprocesor ZK to rozwiązanie dla dApps umożliwiające wykorzystanie zasobów obliczeniowych poza łańcuchem. W artykule omówiono istniejące rozwiązania, różne zastosowania i przyszły rozwój koprocesorów. Główne poruszane tematy są następujące:

  1. ZkVM firmy RISC Zero to rozwiązanie koprocesora ZK, które umożliwia kontraktom w łańcuchu, które wywołują zkVM poza łańcuchem, w celu uruchomienia określonego kodu Rusta i zwrócenia wyników do łańcucha, zapewniając jednocześnie zkp do weryfikacji poprawności obliczeń w łańcuchu.

  2. Istnieją różne rozwiązania dla koprocesorów ZK. Oprócz ZkVM użytkownicy mogą także pisać niestandardowe obwody ZK dla swoich programów lub używać gotowych frameworków do pisania obwodów, umożliwiając w ten sposób kontraktom wykorzystanie zasobów obliczeniowych poza łańcuchem.

  3. Koprocesor ZK może odgrywać rolę w DeFi, na przykład odciążając obliczenia AMM poza łańcuchem w celu przechwytywania wartości podobnej do MEV lub umożliwiając złożoną i intensywną obliczeniowo logikę dla AMM. Koprocesor ZK może także ułatwić kalkulację stóp procentowych w czasie rzeczywistym dla protokołów kredytowych, zapewniając m.in. przejrzystość kalkulacji marży. zkAMM ma dwa podejścia do implementacji, jedno wykorzystujące zkVM, a drugie wykorzystujące zkOracle.

  4. Koprocesor ZK ma także inne potencjalne zastosowania, np. portfele wykorzystują go do weryfikacji tożsamości poza łańcuchem. Może między innymi umożliwić bardziej złożone obliczenia w grach on-chain i zmniejszyć zużycie gazu wymaganego do zarządzania DAO.

  5. Sytuacja koprocesorów ZK jest nadal niepewna, ale w porównaniu z użytkownikami piszącymi własne obwody, korzystanie z rozwiązania do łączenia zasobów poza łańcuchem jest bardziej przyjazne dla użytkownika. Jednakże kwestia, którzy dostawcy usług obliczeniowych są zintegrowani z tym rozwiązaniem „interfejsowym”, niezależnie od tego, czy są to tradycyjni dostawcy usług w chmurze, czy zdecentralizowane sieci współdzielenia zasobów, to kolejny ważny temat do dyskusji.

1. Cel i zastosowanie koprocesorów ZK

Źródło: Kernel Ventures

Rdzeniem koprocesora ZK jest przeniesienie obliczeń w łańcuchu poza łańcuch, przy użyciu dowodów ZK w celu zapewnienia niezawodności obliczeń poza łańcuchem, umożliwiając inteligentnym kontraktom łatwą obsługę dużej ilości obliczeń przy jednoczesnej weryfikacji wiarygodności obliczeń. Jest to podobne do idei zkRollups, ale Rollupy wykorzystują zasoby obliczeniowe poza łańcuchem w warstwie protokołu łańcucha, podczas gdy koprocesory ZK są używane przez dApps do wykorzystania zasobów poza łańcuchem.

Używając RISC Zero jako przykładu do wyjaśnienia jednego z rozwiązań koprocesorów ZK, RISC Zero opracowało architekturę koprocesora Bonsai ZK, której rdzeniem jest zkVM RISC Zero. Programiści mogą generować zkp na zkVM dla „poprawnego wykonania określonego kodu Rust”. W przypadku zkVM specyficzny proces wdrażania koprocesora ZK jest następujący:

  1. Programiści wysyłają prośbę do Bonsai o umowę przekaźnikową, czyli o uruchomienie wymaganego przez dewelopera programu w zkVM.

  2. Kontrakt przekaźnika wysyła żądanie do puli żądań poza łańcuchem.

  3. Bonsai wykonuje żądanie w zkVM poza łańcuchem, wykonuje obliczenia na dużą skalę, a następnie generuje potwierdzenie.

  4. Dowody te, zwane również „paragonami”, są publikowane z powrotem do sieci przez Bonsai w ramach umowy sztafetowej.

Źródło: RISC Zero

W Bonsai sprawdzony program nazywa się Programem Gościa, a paragon służy do potwierdzenia, że ​​program gościa został poprawnie wykonany. Paragon zawiera dziennik i pieczęć. W szczególności dziennik zawiera publiczne dane wyjściowe aplikacji zkVM, a pieczęć służy do potwierdzenia ważności pokwitowania, tj. do potwierdzenia, że ​​program gościa został poprawnie wykonany. Sama pieczęć to zkSTARK wygenerowany przez dowódcę. Sprawdzenie paragonu gwarantuje, że dziennik jest zbudowany przy użyciu prawidłowego obwodu itp.

Bonsai upraszcza programistom proces kompilowania kodu Rusta do kodu bajtowego ZkVM, przesyłania programów, wykonywania ich na maszynie wirtualnej i otrzymywania informacji zwrotnych weryfikacyjnych, umożliwiając programistom skupienie się bardziej na projektowaniu logicznym. Umożliwia nie tylko częściową logikę kontraktu, ale całą logikę kontraktu na działanie poza łańcuchem. RISC Zero wykorzystuje również kontynuacje, dzieląc generację dużego dowodu na mniejsze części, umożliwiając generowanie dowodu dla dużych programów bez zużywania nadmiernej pamięci. Oprócz RISC Zero istnieją inne projekty, takie jak IronMill, =nil; Foundation i Marlin, które zapewniają podobne ogólne rozwiązania.

2. Zastosowanie koprocesorów ZK w DeFi

2.1 AMM – Bonsai jako koprocesor

zkUniswap to AMM, który wykorzystuje zasoby obliczeniowe poza łańcuchem. Jego podstawową cechą jest odciążenie części obliczeń swapu poza łańcuchem przy użyciu Bonsai. Użytkownicy inicjują żądanie wymiany w łańcuchu. Kontrakt przekaźnikowy Bonsai otrzymuje żądanie, inicjuje obliczenia poza łańcuchem, a po ich zakończeniu zwraca wynik obliczeń i dowód do funkcji wywołania zwrotnego EVM. Jeśli dowód zostanie pomyślnie zweryfikowany, nastąpi zamiana.

Jednak zamiana nie zostanie zakończona za jednym razem. Procesy żądania i wykonania dotyczą różnych transakcji, co niesie ze sobą pewne ryzyko. Oznacza to, że pomiędzy złożeniem wniosku a zakończeniem swapu stan puli może ulec zmianie. Ponieważ weryfikacja odbywa się na podstawie stanu puli w momencie złożenia wniosku, jeśli żądanie nadal oczekuje na realizację, a stan puli ulegnie zmianie, weryfikacja będzie nieważna. Jest to ważny czynnik przy projektowaniu i bezpieczeństwie takich systemów.

Aby rozwiązać ten problem, programiści zaprojektowali blokadę basenu. Kiedy użytkownik inicjuje żądanie, wszystkie operacje inne niż rozliczanie zamiany są tymczasowo blokowane do czasu, aż przetwarzanie poza łańcuchem pomyślnie wyzwoli zamianę w łańcuchu lub upłynie limit czasu wymiany (limit czasu zostanie ustawiony). Przy obowiązującym limicie czasowym, nawet jeśli wystąpią problemy ze sztafetą lub zkp, basen nie będzie zamykany na czas nieokreślony. Konkretny limit czasu może wynosić kilka minut.

zkUniswap ma unikalny projekt przechwytywania MEV, ponieważ programiści chcą, aby protokół czerpał korzyści z MEV. Teoretycznie zkAMM mają również MEV, ponieważ pierwsza osoba, która zgłosi zamianę, może ją zablokować i wyprzedzić innych, co prowadzi do wojen gazowych, a konstruktorzy nadal mogą ustalać priorytety sekwencjonowania transakcji. Jednakże zkUniswap przejmuje zyski z MEV dla siebie, stosując metodę znaną jako stopniowa aukcja holenderska o zmiennej stopie procentowej (VRGDA). Takie podejście pozwala zkUniswap wyodrębnić wartość MEV dla protokołu.

Koncepcja zkUniswap jest dość interesująca. Polega na obniżeniu ceny zablokowanych aktywów na aukcji, a jeśli zablokowane aktywa zostaną szybko sprzedane, protokół rozpoznaje duży popyt i automatycznie podnosi cenę. Jeżeli sprzedaż zablokowanych aktywów ulegnie spowolnieniu, protokół obniża cenę. To innowacyjne podejście może potencjalnie stać się nowym źródłem przychodów. Zasadniczo protokół wprowadza unikalny mechanizm priorytetyzacji transakcji, a konkurencja cenowa przynosi korzyść projektowi bezpośrednio poprzez ten mechanizm.

2.2 AMM - zkOracle jako koprocesor

Oprócz używania zkVM, niektórzy proponowali użycie zkOracle do wykorzystania zasobów obliczeniowych poza łańcuchem, warto zauważyć, że zkOracle jest wyrocznią I/O (wejścia i wyjścia), która obsługuje zarówno wejście, jak i wyjście. Ogólnie rzecz biorąc, istnieją dwa typy wyroczni, jedna to wyrocznia wejściowa, a druga to wyrocznia wyjściowa. Wyrocznia wejściowa przetwarza (oblicza) dane poza łańcuchem i umieszcza je w łańcuchu, podczas gdy wyrocznia wyjściowa przetwarza (oblicza) dane w łańcuchu i dostarcza je poza łańcuchem. Wyrocznia I/O (zkOracle) najpierw wykonuje dane wyjściowe, a następnie wprowadza dane, umożliwiając łańcuchowi wykorzystanie zasobów obliczeniowych poza łańcuchem.

ZkOracle z jednej strony wykorzystuje dane on-chain jako źródło danych, a z drugiej strony wykorzystuje ZK, aby zapewnić rzetelność obliczeń węzłów Oracle, osiągając w ten sposób funkcję koprocesora. Dlatego też podstawowe obliczenia AMM można umieścić w zkOracle, umożliwiając tradycyjną funkcjonalność AMM, a jednocześnie umożliwiając bardziej złożone i wymagające obliczeniowo operacje przy użyciu zkOracle.

Źródło: github kilkawwww/zkAMM

2.3 Obliczanie oprocentowania kredytu, obliczanie marży i inne zastosowania

Pomijając sposób implementacji, dodając koprocesory ZK, można uzyskać wiele funkcjonalności. Na przykład protokoły kredytowe mogą dostosowywać stopy procentowe zgodnie z parametrami w czasie rzeczywistym, a nie z góry określonymi warunkami. Na przykład podniesienie stopy procentowej, aby przyciągnąć podaż, gdy popyt na pożyczkę jest duży, i obniżenie stopy procentowej, gdy popyt maleje. Wymaga to od protokołu pożyczkowego uzyskania dużej ilości danych w łańcuchu w czasie rzeczywistym, wstępnego przetworzenia danych i obliczenia parametrów poza łańcuchem (chyba że koszt w łańcuchu jest wyjątkowo niski).

Złożone obliczenia, takie jak określanie salda marży, niezrealizowanych zysków/strat itp., mogą również wykorzystywać do wykonania koprocesory. Zaletą stosowania koprocesorów jest to, że czynią te aplikacje bardziej przejrzystymi i weryfikowalnymi. Logika silnika marży nie jest już tajną czarną skrzynką. Mimo że obliczenia wykonywane są poza łańcuchem, użytkownicy mogą w pełni ufać poprawności ich wykonania. Podejście to ma również zastosowanie do kalkulacji opcji.

3. Inne zastosowania koprocesorów ZK

3.1 Portfel — używanie Bonsai jako koprocesora

Bonfire Wallet wykorzystuje zkVM do odciążenia obliczeń związanych z weryfikacją tożsamości poza łańcuchem. Celem tego portfela jest umożliwienie użytkownikom tworzenia portfeli nagrywających przy użyciu informacji biometrycznych (odcisków palców) lub zaszyfrowanego sprzętowego klucza yubikey. W szczególności Bonfire Wallet wykorzystuje WebAuthn, powszechny standard uwierzytelniania internetowego, aby umożliwić użytkownikom dokończenie weryfikacji tożsamości internetowej bezpośrednio za pomocą urządzeń bez hasła. Zatem w Bonfire Wallet użytkownicy generują klucz publiczny za pomocą WebAuthn (nie w łańcuchu, ale dla WebAuthn), a następnie używają go do utworzenia portfela. Każdy portfel Burner ma kontrakt w łańcuchu, który zawiera klucz publiczny WebAuthn. Umowa musi weryfikować podpis WebAuthn użytkownika. Ale te obliczenia są duże, więc Bonsai służy do odciążenia tych obliczeń poza łańcuchem, za pośrednictwem programu gościa zkVM w celu sprawdzenia podpisu poza łańcuchem i wygenerowania zkp do weryfikacji w łańcuchu.

Źródło: Portfel ogniskowy

3.2 Pobieranie danych w łańcuchu – obwody ZK zapisywane przez użytkowników

Axiom to aplikacja, która nie korzysta z ZKVM, ale korzysta z innego rozwiązania koprocesorowego. Najpierw przedstawmy, co ma na celu Axiom. Wykorzystuje koprocesory ZK, aby umożliwić kontraktom dostęp do historycznych informacji w łańcuchu. W rzeczywistości umożliwienie kontraktom odczytu danych historycznych jest dość trudne, ponieważ inteligentne kontrakty zazwyczaj uzyskują dane w czasie rzeczywistym w łańcuchu, co może być bardzo kosztowne. Kontraktom trudno jest uzyskać dostęp do cennych danych w łańcuchu, takich jak historyczne salda kont lub zapisy transakcji.

Źródło: Demo Axiom

Węzły aksjomatu uzyskują dostęp do wymaganych danych w łańcuchu i wykonują określone obliczenia poza łańcuchem, a następnie generują dowód o wiedzy zerowej dla obliczeń, potwierdzając, że wynik został poprawnie obliczony na podstawie prawidłowych danych w łańcuchu. Dowód ten jest weryfikowany w łańcuchu, co gwarantuje, że kontrakt może zaufać temu wynikowi.

Aby wygenerować zkp do obliczeń poza łańcuchem, konieczne jest skompilowanie programów w obwody ZK. Wcześniej wspominaliśmy również o użyciu do tego celu zkVM, ale Axiom zasugerował, że istnieje wiele rozwiązań w tym zakresie i konieczne jest zrównoważenie wydajności, elastyczności i doświadczenia programistycznego:

  1. Niestandardowe obwody: jeśli programiści dostosują obwody do swoich programów, wydajność będzie z pewnością najlepsza, ale opracowanie wymaga czasu;

  2. eDSL/DSL: programiści nadal piszą swoje obwody, ale istnieją pewne opcjonalne frameworki, które pomagają programistom rozwiązywać problemy związane z ZK, równoważąc w ten sposób wydajność i doświadczenie programistyczne.

  3. zkVM: programiści uruchamiają ZK bezpośrednio na istniejącej maszynie wirtualnej, co jest bardzo wygodne, ale Axiom uważa, że ​​jest to nieefektywne.

Dlatego Axiom wybrał drugą opcję i udostępnia użytkownikom zestaw zoptymalizowanych modułów ZK, pozwalających na projektowanie własnych obwodów.

Projekty podobne do Axiom obejmują Herodotus, który ma być oprogramowaniem pośredniczącym do przesyłania wiadomości między łańcuchami. Ponieważ przetwarzanie informacji odbywa się poza łańcuchem, rozsądne jest umożliwienie różnym łańcuchom uzyskiwania przetworzonych danych. Inny projekt, Space and Time, wykorzystuje podobną architekturę do implementacji indeksowania danych.

3.3 Gry w sieci, zarządzanie DAO i inne aplikacje

Oprócz powyższego, gry on-chain, zarządzanie DAO mogą również korzystać z koprocesorów ZK. RISC Zero uważa, że ​​wszelkie obliczenia wymagające więcej niż 250 tys. gazu byłyby tańsze przy użyciu koprocesora ZK, ale sposób obliczania tego wymaga dalszych badań. Zarządzanie DAO może również wykorzystywać koprocesory ZK, ponieważ angażuje wiele osób i wiele umów, co wymaga dużej mocy obliczeniowej. RISC Zero twierdzi, że korzystanie z Bonsai może obniżyć opłaty za gaz o 50%. Wiele projektów ZKML, takich jak Modulus Labs i Giza, wykorzystuje to samo rozwiązanie, co koprocesory ZK, ale koncepcja koprocesorów ZK jest szersza.

Warto wspomnieć, że istnieją projekty pomocnicze w dziedzinie koprocesorów ZK, takie jak ezkl, który zapewnia kompilatory dla obwodów ZK, zestawy narzędzi do wdrażania ZK i narzędzia do odciążania obliczeń on-chain poza łańcuchem.

4. Perspektywy na przyszłość

Koprocesory zapewniają aplikacjom działającym w łańcuchu zewnętrzne zasoby obliczeniowe podobne do „chmury”, oferując ekonomiczne i obfite obliczenia, podczas gdy przetwarzanie w łańcuchu koncentruje się na niezbędnych obliczeniach. W praktyce zkVM może działać także w chmurze. Zasadniczo koprocesory ZK to podejście architektoniczne, które przenosi obliczenia w łańcuchu poza łańcuch, z nieograniczonym źródłem zasobów obliczeniowych poza łańcuchem.

Zasadniczo zasoby obliczeniowe poza łańcuchem mogą być zapewniane przez tradycyjnych dostawców usług w chmurze, a nawet przez zdecentralizowane udostępnianie zasobów obliczeniowych i urządzenia lokalne. Każdy z tych trzech kierunków ma swoją charakterystykę. Tradycyjni dostawcy usług w chmurze mogą zapewniać stosunkowo dojrzałe rozwiązania obliczeniowe poza łańcuchem, „solidność” przyszłych zdecentralizowanych zasobów obliczeniowych może być większa, a przetwarzanie lokalne również ma duży potencjał. Jednak obecnie wiele projektów koprocesorów ZK znajduje się na etapie dostawcy usług o zamkniętym kodzie źródłowym, ponieważ ekosystem tych usług nie został w pełni ukształtowany i nie została jeszcze zdefiniowana specjalizacja usług w ramach różnych projektów. Możliwe są dwa scenariusze na przyszłość:

  1. Każda część koprocesora ZK ma dużą liczbę konkurujących ze sobą projektów.

  2. Pojedynczy projekt z doskonałym doświadczeniem serwisowym może zdominować rynek.

Z punktu widzenia programisty, korzystając z koprocesorów ZK, mogą one wchodzić w interakcję tylko z jednym projektem „interfejsu”. Jest to podobne do powodu, dla którego Amazon Web Services ma znaczny udział w rynku, ponieważ programiści mają tendencję do przyzwyczajania się do określonej metody wdrażania. Jednakże kwestia, którzy dostawcy usług obliczeniowych (tradycyjne firmy działające w chmurze, zdecentralizowane udostępnianie zasobów) są zintegrowani w ramach tego projektu „interfejsu” zasobów obliczeniowych poza łańcuchem, to kolejny temat warty omówienia.

Kernel Ventures to fundusz VC działający na rzecz społeczności badawczo-programistycznej, posiadający ponad 70 inwestycji na wczesnym etapie, skupiający się na infrastrukturze, oprogramowaniu pośrednim, dAppach, zwłaszcza ZK, Rollup, DEX, Modular Blockchain i branżach, które wdrożą kolejny miliard użytkowników w branży kryptowalut takie jak abstrakcja kont, dostępność danych, skalowalność itp. Przez ostatnie siedem lat angażowaliśmy się we wspieranie rozwoju głównych społeczności programistów i uniwersyteckich stowarzyszeń Blockchain na całym świecie.

ODNIESIENIE:

  1. Przewodnik po koprocesorach ZK pod kątem skalowalności: https://www.risczero.com/news/a-guide-to-zk-coprocessors-for-scalability

  2. Definiowanie zkOracle dla Ethereum: https://ethresear.ch/t/defining-zkoracle-for-ethereum/15131

  3. zkUniswap: pierwszy w swoim rodzaju zkAMM: https://ethresear.ch/t/zkuniswap-a-first-of-its-kind-zkamm/16839

  4. Co to jest koprocesor ZK?: https://blog.axiom.xyz/what-is-a-zk-coprocessor/

  5. Krótkie wprowadzenie do koprocesorów: https://crypto.mirror.xyz/BFqUfBNVZrqYau3Vz9WJ-BACw5FT3W30iUX3mPlKxtA

  6. Najnowsze aplikacje oparte na Hyper Oracle (bonus: rzeczy, które możesz zbudować teraz): https://mirror.xyz/hyperoracleblog.eth/Tik3nBI9mw05Ql_aHKZqm4hNxfxaEQdDAKn7JKcx0xQ

  7. Portfel Bonfire: https://ethglobal.com/showcase/bonfire-wallet-n1dzp