Oryginalna analiza badań Web3.com Ventures
0xFishylosopher
Wstęp
„zk-Rollups” to prawdopodobnie najgorętsze hasło roku w Web 3. Wraz z uruchomieniem sieci głównej ZK-Sync w wersji 2.0 „baby alpha” w ciągu zaledwie kilku dni, emocje sięgnęły zenitu [1]. Ale za tymi wszystkimi modnymi hasłami, co tak naprawdę oznacza „zk-Rollups”? A gdzie w grę wchodzi zk-Sync? W tym artykule postaram się zgłębić zasady i praktykę zk-Rollups, wyjaśnić kluczowe cechy techniczne zk-Sync v2.0 jako projektu i zbadać potencjalne przyszłe implikacje dla tej długo oczekiwanej technologii.
Zasady zk-Rollups
Dlaczego w ogóle potrzebujemy zk-Rollups? Jasne, Ethereum jest świetne. Ale w obecnym stanie sieć jest zasadniczo nieekonomią skali. Wraz ze wzrostem aktywności sieciowej ceny gazu stają się niebotycznie wysokie, szczególnie jeśli nastąpi nagły wzrost aktywności sieciowej. Wraz ze wzrostem popularności Ethereum w użytkowaniu i trakcji w ciągu ostatnich kilku lat, jego obecna ograniczona skalowalność stała się piętą achillesową sieci.
Tutaj wkraczają „rollupy” — Ethereum rollupy są w zasadzie „wtyczką”, która zapewnia Ethereum dodatkowe wielkości skalowalności, a tym samym naprawia jego wrodzoną nieekonomię skali. Intuicja stojąca za tym pomysłem jest prosta. Wyobraź sobie, że masz 5 przedmiotów, które musisz przenieść z punktu A do punktu B. „Zwykłym” sposobem zrobienia tego byłoby przeniesienie Przedmiotu 1, przeniesienie Przedmiotu 2 itd. jeden po drugim. Ale jest to oczywiście powolne i uciążliwe. „Rollup” to w zasadzie „zwinięcie” wszystkich 5 przedmiotów do jednej torby, co pozwala na odbycie jednej podróży zamiast 5.
Istnieją jednak dwa zastrzeżenia:
Jak upewnić się, że w rollup'ie zmieści się wszystko?
Jak upewnić się, że plik rollup nie jest sfałszowany?
zk-Rollups to jeden z wiodących typów technologii rollup (drugim są Optimistic Rollups) wykorzystujący „dowody zerowej wiedzy” do rozwiązania tych dwóch problemów. Aby rozwiązać te problemy, zk-Rollup połączy pewną liczbę transakcji, wykona obliczenia na poziomie L2 i prześle zarówno zmiany stanu, jak i „dowód ważności” do weryfikatora na poziomie L1, pokazując, że obliczenia zostały wykonane z integralnością. Ten „dowód ważności” odbywa się w formie „dowodu zerowej wiedzy”, matematycznego sposobu powiedzenia komuś, że coś wiesz, bez mówienia mu, co wiesz.
Prostym przykładem dowodu zerowej wiedzy jest autograder kodu (do zadań domowych z informatyki). Autograder to „weryfikator”, który daje Ci mnóstwo losowo generowanych przypadków testowych, a Ty jesteś „dowodzącym”, który musi być w stanie przejść wszystkie przypadki testowe, aby udowodnić, że masz poprawny kod. Przez cały czas nie udostępniasz swojego kodu bezpośrednio autograderowi. I voila, właśnie przeprowadziłeś „dowód zerowej wiedzy”, udowadniając, że wiesz coś, nie mówiąc, co wiesz. [2]
Powyższy autograder kodu używa „interaktywnego dowodu zerowej wiedzy”, w którym autograder i dostawca kodu bezpośrednio „oddziałują” na siebie. W przeciwieństwie do tego większość zk-Rollupów używa bardziej skomplikowanego matematycznie dowodu nieinteraktywnego (takiego jak zk-SNARK, czyli Zero Knowledge Succinct Noninteractive ARgument of Knowledge), co oszczędza zarówno czas, jak i miejsce w porównaniu z dowodem interaktywnym. Chociaż szczegóły techniczne zk-SNARKów wykraczają poza zakres tego artykułu, podstawowa zasada przekazywania przypadków testowych jest taka sama.
Świętym Graalem zk-Rollups jest Zero-Knowledge Ethereum Virtual Machine (zk-EVM), która pozwala deweloperom na przenoszenie dowolnego inteligentnego kontraktu Ethereum bez modyfikacji na łańcuch zk-Rollup. Ale to jest trudne. Ponieważ każdy „problem” wymaga różnych zestawów „przypadków testowych”, opracowanie „algorytmu dowodowego”, który może rozwiązać każdy możliwy przypadek testowy, jest technicznym wąskim gardłem Zero-Knowledge Proofs i zk-Rollups.
Jak stwierdza sam Vitalik Buterin:
Ogólnie rzecz biorąc, moim zdaniem w krótkiej perspektywie optymistyczne podsumowania prawdopodobnie wygrają w obliczeniach EVM ogólnego przeznaczenia, a podsumowania ZK prawdopodobnie wygrają w prostych płatnościach, wymianie i innych przypadkach użycia specyficznych dla aplikacji, ale w średniej i długiej perspektywie podsumowania ZK wygrają we wszystkich przypadkach użycia, w miarę jak technologia ZK-SNARK będzie się rozwijać. [3]
Zatem historycznie rzecz biorąc, zk-Rollups były technologiami ustalonymi wyłącznie dla przypadków użycia specyficznych dla aplikacji, w których „przypadki testowe” były dobrze zdefiniowane i miały ograniczony zakres. Jednak kilka projektów szybko zmierza w kierunku „zamku na wzgórzu” — ogólnego algorytmu zk-Rollup zgodnego z EVM. [4]
zk-Sync v2.0
zk-Sync v2.0 to tylko jeden z wielu projektów aktualnie realizowanych w ramach rozwijania zk-EVM (inne to StarkNet, Polygon Hermez i Scroll). W przeciwieństwie do zk-Sync v1.0, który wymagał od użytkowników przebudowania dużych sekcji ich baz kodu w celu przeniesienia z EVM do zk-Sync, w zk-Sync v2.0 programiści mogą wdrażać swoje aplikacje z niewielkimi lub żadnymi zmianami — lub jak twierdzi zk-Sync.
W praktyce nie wszystkie zk-EVM są sobie równe. Istnieje wyraźny kompromis między możliwością kompozycji (jak blisko jest do oryginalnych kontraktów EVM) a wydajnością (jak szybko będą działać zk-Rollups) [6]. W ramach tego kompromisu zk-Sync zdecydował się na całkowitą optymalizację pod kątem wydajności, poświęcając w ten sposób możliwość kompozycji.
Z perspektywy Vitalika Buterina istnieją cztery odrębne typy zk-EVM, podsumowane na poniższym wykresie:
Jak stwierdza Vitalik, w obecnym stanie zk-Sync v2.0 jest zk-EVM typu 4, który jest w stanie kompilować kontrakty napisane w Solidity i językach wysokiego poziomu przy użyciu własnego kompilatora, który jest odrębny od EVM. Ponieważ zk-Sync ma pełną kontrolę nad projektem swojego kompilatora, jest w stanie agresywnie optymalizować pod kątem szybkości i przepustowości. Kosztem tego jest to, że niektóre łańcuchy narzędzi do debugowania DApps i EVM mogą być niezgodne z zk-Sync v2.0. Zasadniczo zk-Sync jest tą samą powłoką samochodową co Ethereum, ale z zamienionym silnikiem [5].
Rzeczywiście, w swojej dokumentacji dla deweloperów Matter Labs twierdzi, że podczas gdy operacje „odczytu” inteligentnych kontraktów mogą być zintegrowane bez żadnych zmian w kodzie, operacje „zapisu” inteligentnych kontraktów wymagają „dodatkowego kodu” ze względu na „fundamentalne różnice między L1 i L2” [6]. W rzeczywistości jest to nieco mylące. Nie jest to tak bardzo spowodowane „fundamentalną różnicą” między L1 i L2, ale bardziej ze względu na typ zk-Rollup, który Matter Labs zdecydowało się zrealizować — rollup typu 4. Ponieważ zk-Sync jest zasadniczo rollupem typu 4, który używa innego kompilatora i bajtkodu, oznacza to, że inteligentne kontrakty mają różne adresy, a infrastruktura debugera, która polega na analizie bajtkodu, może nie być w stanie działać w zk-Sync v2.0 [7].
W przyszłości zk-Sync może dodać więcej natywnego wsparcia dla bajtkodu EVM, umożliwiając systemowi powolne przejście do rollupu typu 3, który obsługuje szerszy zakres tych „przypadków brzegowych”. Jednak aby zk-Rollup typu 4 lub typu 3 zk-Sync odniósł sukces w porównaniu z rollupem typu 2 Polygon Hermez i Scroll Labs, który zasadniczo wymienia prędkość na szerszą kompatybilność, muszą być spełnione dwa ważne warunki wstępne. Po pierwsze, istnieje tylko niewielka część nieistotnych projektów, które są niezgodne z niestandardowym kompilatorem zk-Sync. Po drugie, istnieje jakościowa różnica w szybkości wykonywania zk-Sync w porównaniu z zk-EVM typu 2.
Niestety, osobiście uważam, że jest to mało prawdopodobne. Każdy zaawansowany ekosystem programistyczny opiera się na dojrzałej infrastrukturze „rusztowania”, w tym wygodnych, modułowych narzędziach do debugowania i testowania. Jeśli, jak postuluje Vitalik, duża część natywnych narzędzi do debugowania EVM nie będzie w stanie przenieść się do zk-Sync z powodu różnic w kodzie bajtowym, wówczas zk-Sync będzie musiał opracować własny zestaw narzędzi do testowania i debugowania. Jest to dodatkowy narzut, który może ostatecznie utrudnić szybkość adopcji zk-Sync jako rozwiązania L2 w porównaniu z bardziej kompozycyjnymi konkurentami zk-EVM typu 2, takimi jak Polygon Hermez i Scroll.
Przyszłość zk-Rollups
Biorąc pod uwagę wielu konkurencyjnych graczy w bitwie o zk-EVM, można by rzec, że to tylko kwestia czasu, zanim zobaczymy w pełni funkcjonalne zk-EVM. Ale co dalej? Droga jest użyteczna tylko tak długo, jak są na niej budynki; długoterminowa siła zk-Rollup pochodzi z projektów wykorzystujących to rozwiązanie.
Obecnie głównymi beneficjentami infrastruktury zk-Rollup są DeFi, GameFi i aplikacje mobilne. Zarówno DeFi, jak i GameFi są zasadniczo ekonomią skali, ponieważ rozwijają się w środowisku, w którym korzysta z nich wiele osób. Aplikacje mobilne, takie jak portfele mobilne, otwierają również wrota dla masowego konsumenta, który jest zbyt leniwy (lub nie stać go) na komputer stacjonarny. Korzystanie z zk-Rollups w takich sytuacjach ma zatem wiele sensu.
Ale to w żadnym wypadku nie jest granica przydatności zk-Rollups. Jeśli już, to jest to dopiero początek. zk-Rollups są dla Ethereum tym, czym 5G jest dla Internetu. Tak jak 5G może umożliwić nowy świat aplikacji i systemów IoT, zk-Rollups może również otworzyć wrota do „Blockchain of Things”, umożliwiając integrację cyfrowych urządzeń naszego fizycznego świata — lodówek, zegarków, sygnalizacji świetlnej i wszystkiego innego — z inteligentnymi kontraktami zabezpieczonymi w Ethereum.
Jednym z największych argumentów przeciwko IoT jest to, że pozwoli on Big Tech wkroczyć w nasze codzienne życie. Ale dzięki „Blockchain of Things” możemy cieszyć się wygodami IoT bez obaw, że nasze inteligentne urządzenia zostaną naruszone w scentralizowanej bazie danych. Zamiast wygody LUB prywatności możemy mieć wygodę I prywatność. To świat, który zk-Rollups może nam obiecać.
🐦 @0xfishylosopher
📅 31 października 2022
Informacje te mają charakter czysto edukacyjny i nie należy ich traktować jako porady finansowej. Wszystkie wyrażone poglądy są poglądami autora i nie są koniecznie popierane przez Web3.com Ventures.
Odniesienia
[1] https://blog.matter-labs.io/baby-alpha-has-arrived-5b10798bc623
[2] Adaptacja z https://pages.cs.wisc.edu/~mkowalcz/628.pdf
[3] https://vitalik.ca/general/2021/01/05/rollup.html
[4] https://www.coindesk.com/tech/2022/07/20/the-sudden-rise-of-evm-kompatybilny-zk-rollups/
[5] https://cryptobriefing.com/the-race-scale-ethereum-zkevm-rollups/
[6] https://docs.zksync.io/dev/contracts/#porting-smart-contracts
[7] https://vitalik.ca/general/2022/08/04/zkevm.html