Przemówienie Gavina Wooda: postępy w realizacji JAM oraz średnio- i długoterminowa strategia wprowadzania ZK do JAM!

To polska wersja przemówienia Gavina Wooda z zeszłego miesiąca na Web3 Summit! Ze względu na obszerność materiału, publikujemy go w czterech częściach – to jest część pierwsza, obejmująca główne tematy:

• Status wdrożenia JAM
• Choć wydajność ZK się poprawiła, wciąż daleko jej do komercjalizacji
• 33-krotne powtórzenie obliczeń vs matematyczny dowód: rzeczywisty koszt dwóch trybów bezpieczeństwa
• Ile kosztuje węzeł ZK-JAM? Odpowiedź: 10 razy więcej niż myślisz!
• Krótko-, średnio- i długoterminowa ścieżka rozwoju ZK w JAM

Zobaczmy, jakie ciekawe poglądy przedstawił Gavin!

Bez zbędnej zwłoki – o czym będę mówił podczas tego wystąpienia?

Na początek chciałbym podzielić się moim ogólnym spojrzeniem na Polkadot, czyli miejscem, w którym obecnie się znajduję w swoich przemyśleniach – można to uznać za „migawkę obecnej sytuacji”. Być może słyszeliście już o JAM – to projekt, nad którym pracuję od dawna i który jest ściśle powiązany z Polkadot. Mamy nadzieję, że ostatecznie stanie się on fundamentem kolejnego etapu rozwoju Polkadot. Poza tym poruszę temat technologii zero-knowledge (ZK), zwłaszcza jej zastosowań w skalowaniu funkcjonalności blockchaina.

Poruszę także temat modelu ekonomicznego tokena DOT. Następnie przedstawię niektóre z moich najnowszych badań, które mają na celu ulepszenie obecnych możliwości, a nawet otwarcie zupełnie nowych perspektyw dla Polkadot i szerszego świata Web3. Ta część będzie obejmować różne aspekty – niektóre szczegółowo, inne tylko sygnalizując. Dobrze, zaczynajmy oficjalnie.

Aktualny status wdrożenia JAM

Pierwsza wersja JAM to 0.1, obecnie zbliżamy się do wersji 1.0. Gdy osiągniemy 1.0, oznaczać to będzie, że protokół JAM jest gotowy do wdrożenia w Polkadot. Wraz ze stabilizacją protokołu, nasz nacisk przesuwa się na optymalizację, zwłaszcza modelowania gas. Wcześniej tego roku wygłosiłem na ten temat prezentację podczas konferencji Ethereum w Pradze (East Prague). Samo modelowanie gas to bardzo interesujący, ale i niezwykle złożony temat.

JAM planuje w tym roku rozpocząć audyt protokołu. W serii wersji 0.7 nie pozostało wiele do zrobienia; natomiast w wersji 0.8 oficjalnie wprowadzimy modelowanie gas, co znacznie zwiększy zakres prac. Przewiduję, że w tym roku osiągniemy wersję 0.9 i wtedy oficjalnie rozpoczniemy audyt.

Oczywiście, posiadanie rdzeniowego protokołu to jedno, a możliwość rozwoju na jego bazie to drugie. Potrzebujesz SDK, dokumentacji i innych narzędzi deweloperskich. Ta część jest obecnie na wczesnym etapie. Choć już teraz można rozwijać oprogramowanie na JAM, w Parity głównie ja napędzam budowę i wydanie SDK. Jednak w praktyce wymaga to jeszcze miesięcy, a nawet lat ciągłego zaangażowania i dopracowywania. Oczywiście, rozwój SDK nie ograniczy się do Parity. Spodziewam się, że więcej zespołów dołączy, tworząc własne SDK dla JAM.

Rozpoczęliśmy już opracowywanie standardu przekazywania wiadomości między usługami, który można uznać za wersję JAM XCM/XCMP. Jednocześnie CoreVM stopniowo staje się częścią SDK i będzie w nadchodzących miesiącach stale ulepszany. CoreVM już obsługuje wiele funkcji, takich jak wyjście audio, wideo, wejście/wyjście danych, przetwarzanie transakcji oraz nadchodzące usługi wewnętrzne. Obecnie nie obsługuje jeszcze EVM, ale planujemy dodać tę funkcję. Ponadto, mechanizm, który wcześniej nazywałem coreplay (koordynacja rdzeniowa), planujemy wdrożyć w ciągu najbliższych 12–24 miesięcy.

Ostatnio na czacie JAM pojawiło się ciekawe pytanie: jak uniknąć sytuacji, w której ja sam stanę się pojedynczym punktem awarii (single point of failure) dla JAM? Obecnie rozwój protokołu JAM całkowicie zależy od tego, co napisałem w Gray Paper. Oznacza to, że jeśli coś mi się stanie, cały projekt może utknąć w martwym punkcie. Oczywiście, to nie jest dobre ani dla JAM, ani dla mnie.

Dlatego traktujemy treść Gray Paper jako specyfikację techniczną JAM. Najnowsza wersja Gray Paper to najnowszy JAM. Jeśli jakaś wersja Gray Paper została już poddana audytowi, to zdefiniowany przez nią protokół JAM osiągnął poziom dojrzałości produkcyjnej – to proste.

Jak więc w przyszłości będzie ewoluować Gray Paper, jeśli nie będę już jedyną osobą decydującą o jego aktualizacjach?

Moim pomysłem jest powołanie komitetu redakcyjnego. Początkowi członkowie będą wywodzić się spośród tych, którzy rzeczywiście uczestniczyli w pisaniu Gray Paper, mają dogłębną wiedzę i wnieśli istotny wkład. Oczekuję, że ci członkowie utrzymają wysoki poziom zaangażowania technicznego w realizację JAM. Sam nie zamierzam całkowicie się wycofać – pozostanę głównym redaktorem, ale chcę zmniejszyć swój wkład i przekazać innym prawo do proponowania, przeglądania i scalania zmian.

Wraz z przekroczeniem przez JAM wersji 1.0, komitet redakcyjny przejmie wyższy poziom odpowiedzialności:

• Nie tylko wprowadzanie drobnych zmian, ale także decydowanie o kierunku rozwoju i priorytetach JAM;
• W przypadku rozbieżności zdań, kolektywna decyzja komitetu powinna być najważniejszym głosem.

Planuję wyznaczyć zastępcę, który przejmie obowiązki podczas mojej nieobecności, urlopu lub w innych sytuacjach. W dłuższej perspektywie zastępcy będą również odpowiedzialni za wybór, zapraszanie i decydowanie o nowych członkach komitetu redakcyjnego, aby zapewnić samodzielne funkcjonowanie całego mechanizmu. Ostatecznie chciałbym, aby ten system zarządzania stopniowo się usamodzielnił, a nawet włączył udział zewnętrznych organizacji, takich jak Polkadot Fellowship.

Rzeczywiście planuję objąć Gray Paper otwartą licencją, choć jeszcze nie zdecydowałem, którą dokładnie, ale najprawdopodobniej będzie to licencja copyleft z dodatkowymi klauzulami zapobiegającymi nadużyciom patentowym.

Jeśli chodzi o zarządzanie Polkadot, ma ono pełne prawo decydować, który protokół wdrożyć. Polkadot to suwerenny protokół, a mechanizm zarządzania jest wyrazem tej suwerenności. Obecnie zarządzanie Polkadot jasno deklaruje: chce wdrożyć JAM. To dobrze. Jednocześnie inne sieci również mogą wybrać JAM, ponieważ jest to otwarty protokół.

Jeśli w przyszłości JAM będzie się rozwijać, Polkadot może zdecydować się na synchronizację i podążanie za najnowszą wersją; jeśli nie będzie zadowolony z kierunku rozwoju JAM, może pozostać przy wybranej wersji, a nawet zmodyfikować rdzeń protokołu lub rozwidlić Gray Paper. To pokazuje, że JAM jest niezależnym systemem, a ja osobiście mam nadzieję, że utrzyma długoterminową, wzajemnie korzystną relację z Polkadot. Oczywiście, jeśli kiedyś się rozdzielą i będą się rozwijać niezależnie, to też jest możliwe.

Dopóki obie strony są zgodne, spodziewam się, że zarządzanie Polkadot będzie aktywnie uczestniczyć i wspierać działalność komitetu redakcyjnego Gray Paper. Jeśli w przyszłości inne protokoły wdrożą JAM, również chciałbym, aby uczestniczyły w podobny sposób.

To tyle, jeśli chodzi o obecny postęp JAM, lub raczej etap, do którego się zbliża. Teraz chciałbym porozmawiać o zero-knowledge proofs (ZK).

Choć wydajność ZK się poprawiła, wciąż daleko jej do komercjalizacji

Wielu ludzi pyta mnie: kiedy ZK (zero-knowledge proofs) będą naprawdę gotowe do zastosowań komercyjnych?

Ethereum jest bardzo entuzjastycznie nastawione do ZK, ich roadmap praktycznie w całości opiera się na ZK. W JAM używamy ZK tylko w niektórych specjalnych mechanizmach konsensusu podczas budowania bloków, ogólnie nie jesteśmy od nich zależni. Mimo to, to wciąż temat, nad którym trzeba się poważnie zastanowić:

• Kiedy ZK stanie się technologią, która rzeczywiście pozwala skalować moc obliczeniową i jest komercyjnie opłacalna?
• Czy już nadszedł ten moment?
• Jeśli nie, to ile jeszcze trzeba poczekać?

Jeśli spojrzysz na materiały z ekosystemu Ethereum (np. ethprovers.com), zobaczysz imponujące liczby, sugerujące, że ZK jest już opłacalne ekonomicznie. Jednak nasze badania wykazały, że te liczby nie są prawdziwe. Dobra wiadomość jest taka, że choć jeszcze nie jest to w pełni opłacalne, różnica w porównaniu do sytuacji sprzed 18 miesięcy znacznie się zmniejszyła.

Na przykład: obecnie maszyna wirtualna JAM, PVM (odpowiednik EVM w JAM), podczas wykonywania kodu jest wolniejsza od natywnego wykonania o około 34%. Innymi słowy, jeśli program w środowisku natywnym działa 34 minuty, na PVM zajmie to około 100 minut.

To już całkiem niezły wynik, jesteśmy zadowoleni i widzimy jeszcze potencjał do poprawy.

Oczywiście w niektórych przypadkach różnica jest większa, np. 50% lub więcej. Zwłaszcza przy zadaniach takich jak SHA-1 hash, wykonanie na PVM jest wolniejsze. Może to wynikać z tego, że w środowisku natywnym kompilator może używać instrukcji SIMD lub innych optymalizacji, a PVM jeszcze tego nie potrafi.

Przejdźmy do kolejnej kluczowej liczby: to koszt generowania dowodu wykonania przy użyciu obecnie najlepszego dostępnego proveru, Succinct SP1 – czyli dodatkowy narzut w porównaniu do bezpośredniego uruchomienia na PVM. Uwaga, porównujemy do PVM, nie do środowiska natywnego. PVM już jest wolniejszy od natywnego o około 34%.

Obecne wyniki testów są następujące: użyliśmy najnowszej wersji oprogramowania i założyliśmy użycie tylko jednej karty GPU (bo publiczne repozytorium obsługuje tylko pojedynczą GPU). Wersje komercyjne mogą obsługiwać klastry GPU, ale w open source – tylko tyle. Test dotyczył tego samego zadania, co wcześniej, czyli SHA-1 hash, dla zachowania porównywalności.

Co się zmieniło?

18 miesięcy temu przeprowadziliśmy podobny eksperyment, wtedy liczby były znacznie większe – rzędu 60 do 64 milionów. Teraz koszt jest znacznie niższy.

Prawdopodobnie z dwóch powodów:

• Z jednej strony ceny wynajmu GPU spadły;
• Z drugiej strony oprogramowanie zostało znacznie zoptymalizowane, być może nawet o rząd wielkości lub więcej.

Warto dodać, że 18 miesięcy temu używaliśmy proveru RISC-0, nie SP1. Tak czy inaczej, wyniki pokazują jedno: najnowsze technologie szybko się rozwijają, a postęp jest znaczący.

Na lipiec 2025 roku, używając SP1 (prover od Succinct) do wygenerowania dowodu dla ścieżki wykonania (execution trace), koszt jest 306 451 razy wyższy niż bezpieczne wykonanie tego samego obliczenia bezpośrednio na PVM. W ciągu ostatnich 18 miesięcy koszt dowodu spadł około 200-krotnie, ale to wciąż ogromna liczba. Technologia ZK rzeczywiście szybko się rozwija, ale nadal jest znacznie droższa niż bezpośrednie wykonanie.

Przejdźmy teraz do pomiaru Gas.

Szybkość działania kodu to jedno, ale kluczowe jest, by można było mu zaufać. Co jeśli ktoś celowo napisze kod, który „spowalnia” system? W mechanizmach konsensusu, jeśli system musi osiągnąć zgodę w określonym czasie, a kod został złośliwie zaprojektowany, by działać powoli, cały system może się zablokować lub nawet zawiesić.

W Polkadot problem ten nie jest tak poważny, bo mamy aukcje slotów parachainów. Oznacza to, że tożsamość osób wprowadzających kod do systemu jest zasadniczo znana – zapłacili prawdziwe pieniądze za slot, więc raczej nie będą działać na własną szkodę.

Jednak w bardziej otwartym, uniwersalnym środowisku problem staje się poważniejszy.

Jakie jest rozwiązanie?

Musisz być w stanie z góry oszacować górny limit czasu wykonania kodu – czyli ile maksymalnie może zająć w najgorszym przypadku. Następnie upewnić się, że bez względu na wszystko, czas wykonania nie przekroczy tej wartości. W przeciwnym razie, jeśli ktoś sprawi, że kod będzie 10 razy wolniejszy niż przewidywaliśmy, to poważny problem.

Jak dokładne są nasze obecne szacunki najgorszego przypadku?

Na przykładzie SHA-1 hash: obecnie, by zapewnić bezpieczeństwo, musimy założyć, że może być on 4,5 razy wolniejszy niż normalnie. Czyli jeśli kod normalnie działa 1 sekundę, w najgorszym przypadku musimy założyć 4,5 sekundy. Tylko wtedy nawet najbardziej złośliwy atakujący nie spowolni go bardziej.

Takie „kilkukrotne zawyżanie” to konieczność w mechanizmach konsensusu z ograniczeniem czasowym.

W przyszłości ten współczynnik powinien spaść, czyli szacunki staną się dokładniejsze i wydajniejsze. Obecnie 4,5 to najlepszy wynik po tygodniu lub dwóch pracy. Optymistycznie patrząc, może uda się zejść do około 3, ale nie dużo niżej.

33-krotne powtórzenie obliczeń vs matematyczny dowód: rzeczywisty koszt dwóch trybów bezpieczeństwa

W Polkadot i JAM używamy protokołu o nazwie elves, by zapewnić bezpieczeństwo obliczeń. Jego zadaniem jest upewnienie się, że dane obliczenie zostało wykonane poprawnie.

Zasadniczo elves i zero-knowledge proofs (ZK) są do siebie podobne:

• ZK opiera się na matematycznym dowodzie, daje „żelazny” dowód;
• Elves to bardziej gra kryptograficzno-ekonomiczna: uczestnicy używają podpisów i reguł, by udowodnić poprawność wyniku, zakładając, że „złych” nie będzie więcej niż jedna trzecia.

Podczas działania elves obliczenia są powtarzane. Uczestnicy losowo decydują, czy powtórzyć dane obliczenie.

W efekcie, w tym trybie praca jest średnio powtarzana około 33 razy. Czyli kosztuje to około 33 razy więcej niż pojedyncze wykonanie.

W ten sposób możemy porównać koszty ZK i elves. Wynik: ZK jest około 4000 razy droższe niż elves. Innymi słowy, użycie zero-knowledge proofs do weryfikacji poprawności jest znacznie droższe niż użycie systemu kryptograficzno-ekonomicznego elves. Możesz to porównać do różnych rozwiązań Rollup pod względem kosztów.

PolkaWorld Note: Można sobie wyobrazić, że elves to jakby 33 uczniów przepisywało zadanie domowe i na końcu porównywało odpowiedzi, by upewnić się, że wszystko się zgadza; ZK to jakby poprosić doktora matematyki o napisanie „absolutnie nieomylnego dowodu”, ale doktorowi zajmie to kilka dni.

Różnica 4000 razy jest ogromna – by ZK stało się opłacalne w praktyce, koszt musi drastycznie spaść. Oczywiście, możemy też dalej optymalizować elves, by było jeszcze wydajniejsze.

Jednak problem kosztów to nie tylko sprzęt. Są jeszcze inne kluczowe kwestie:

• Koszty utrzymania (sysadmin): niezależnie od sprzętu, pensje administratorów są podobne. W wielu przypadkach koszty utrzymania przewyższają koszty sprzętu.
• Koszty stakingu: by zapewnić, że „złych” nie będzie więcej niż jedna trzecia, system potrzebuje mechanizmu filtrującego. W Polkadot to „staking + mechanizm kar”. Uczestnicy muszą zdeponować część środków (kapitał ryzyka), by odróżnić „dobrych walidatorów” od potencjalnie złych.

Problem w tym, że staking sam w sobie jest kosztowny – to kolejny dodatkowy koszt (o tym za chwilę).

Dla porównania, ZK nie wymaga stakingu. Logika ZK jest prosta: albo dowód jest poprawny, albo nie – widać to od razu.

Ale problem w tym, że generowanie dowodu ZK jest bardzo wolne. Na pojedynczej GPU może to zająć kilka godzin; na PVM (lub zwykłym CPU) to samo obliczenie trwa milisekundy lub sekundy. Różnica jest ogromna.

Jednak pokazano już, że można skrócić opóźnienie przez równoległe użycie klastrów GPU. Jeśli wystarczająco dużo GPU jest połączonych, opóźnienie można zmniejszyć. Problem w tym, że:

Współczynnik efektywności równoległości jest nieznany: nie wiadomo, o ile wzrosną koszty. Osoby, które robiły takie eksperymenty, nie ujawniają tych danych – być może nie chcą. Musimy więc sami projektować eksperymenty, pisać kod lub szukać nieodkrytych badań.

Poza tym są jeszcze kwestie weryfikacji i rozliczeń.

Na przykład na Ethereum L1 koszt weryfikacji jest nawet wyższy niż generowania dowodu. Szacujemy, że wygenerowanie dowodu kosztuje około 1–1,20 USD, ale weryfikacja na Ethereum L1 to już 1,25 USD. Oczywiście, na własnym łańcuchu koszt weryfikacji może być dużo niższy, ale nadal potrzebujesz:

• weryfikacji (verification)
• rozliczenia (settlement)
• finalności (finality)
• przechowywania (storage)

ZK nie eliminuje tych etapów. Ostatecznie nadal musisz zapewnić, że złośliwi uczestnicy nie przekroczą jednej trzeciej – czyli wracamy do stakingu, jak na Ethereum L1, Polkadot i większości łańcuchów.

Ile kosztuje węzeł ZK-JAM? Odpowiedź: 10 razy więcej niż myślisz!

Spójrzmy na to z innej perspektywy: ile kosztuje utrzymanie węzła gwaranta ZK-JAM (guarantor node)?

Krótko wyjaśnię: w JAM istnieje rola gwaranta (guarantor) – to tacy „strażnicy” systemu. Wszystkie transakcje lub zadania trafiają najpierw do nich, oni wykonują obliczenia, pakują wyniki i przekazują je dalej walidatorom. Walidatorzy mogą, ale nie muszą, sprawdzać ich wyniki.

Załóżmy teraz taki scenariusz:

• usuwamy etap powtórnej weryfikacji (nikt nie sprawdza pracy gwaranta);
• obniżamy wymagania stakingowe (bo nie polegamy całkowicie na zaufaniu do gwaranta);
• ale wymagamy, by gwarant uruchamiał klaster GPU i generował dowody ZK.

Ile to kosztuje?

Według szacunków: wygenerowanie dowodu ZK kosztuje około 1,18 USD (na przykładzie SHA-1, odpowiadającego 6 sekundom obliczeń i 12MB I/O). To mniej więcej tyle, ile jeden JAM core może wykonać w jednym slocie. JAM ma 341 core’ów, a to koszt pojedynczego core’a.

Oczywiście to tylko szacunkowa wartość. Dla innych zadań koszt może się różnić – być wyższy lub niższy, ale rząd wielkości jest podobny.

Rocznie daje to koszt około 9,5 miliona USD za jeden core.

Zakładamy tu, że równoległość klastra GPU generuje 50% dodatkowych kosztów, głównie by zmniejszyć opóźnienia. Ten 50% to tylko szacunek – w rzeczywistości może to być 5%, a może 200%. Wiadomo jedno – dodatkowe koszty na pewno będą i mogą być znaczne.

Jak to się ma do obecnego mechanizmu stakingu w Polkadot?

Obecnie, by zapewnić bezpieczeństwo na poziomie elves (lub około 80% bezpieczeństwa elves), koszt jednego core’a to mniej niż 1 milion USD.

80% dlatego, że nawet przy ZK nadal potrzebujesz pewnego poziomu stakingu, by zabezpieczyć inne kluczowe elementy, takie jak:

• prawidłowe działanie głównego łańcucha
• rozliczenia
• finalność
• przechowywanie

To wszystko jest ważne, ale poprawność obliczeń to klucz, stanowiący około 80% kosztów stakingu.

Załóżmy, że uruchamiamy 341 core’ów i utrzymujemy obecny model ekonomiczny stakingu Polkadot – koszt wygląda tak. Jeśli liczba core’ów spadnie, koszt pojedynczego core’a wzrośnie, bo „cały pulę” stakingu dzieli się na mniej uczestników.

Podsumowując: obecnie koszt ZK to około 10 razy więcej niż elves.

Oczywiście, jeśli uda się obniżyć koszty bezpieczeństwa (uważam, że to możliwe), np. z 9,16 miliona USD do 2,7 miliona, a nawet, z pomocą nowych mechanizmów, do 1,44 miliona – różnica między ZK a elves się zmniejszy. Ale 1,44 miliona to już bardzo optymistyczny szacunek.

Jaki jest więc ostateczny wniosek?

Koszt ZK rzeczywiście spada, ale nawet teraz jest 10–100 razy wyższy niż elves. Do tego dochodzą dodatkowe, niepewne koszty, jak rozliczenia, przechowywanie i finalność – JAM już to obsługuje, elves może z tego korzystać, ale ZK nie.

Elves ma jeszcze jedną zaletę: skalowanie ponadliniowe. Oznacza to, że można połączyć kilka sieci JAM i współdzielić ten sam zestaw walidatorów, co zwiększa efektywność. ZK tego nie potrafi – rośnie liniowo: by wygenerować dowód dla kolejnego core’a, trzeba ponieść taki sam koszt, nie da się tego połączyć ani wykorzystać ponownie.

Krótko-, średnio- i długoterminowa ścieżka rozwoju ZK w JAM

Z perspektywy strategicznej, wybór ścieżki zależy od sytuacji.

Uważam, że rozsądną strategią jest:

• Obniżenie kosztu dowodu: potrzeba jeszcze spadku o 1–2 rzędy wielkości. Z dotychczasowych doświadczeń wynika, że może to potrwać od 18 miesięcy do 5 lat.
• Potrzebne są narzędzia open source: umożliwiające efektywne, rozproszone generowanie dowodów na klastrach GPU. Obecnie nie ma dojrzałych narzędzi, a jeśli są, to nie są najszybsze. Bez takich narzędzi nasze obecne szacunki kosztów są niepewne.
• Kwestia ceny core’a: jeśli cena rynkowa core’a już mieści się w zakresie, w którym tryb elves jest opłacalny, ZK traci przewagę.
• Wybór bezpieczeństwa: rynek musi rozróżniać dwa rodzaje bezpieczeństwa: ZK daje „perfekcyjne bezpieczeństwo”, elves – „bezpieczeństwo warunkowane ekonomicznie”. Pytanie, czy rynek naprawdę się tym przejmuje, pozostaje otwarte.
• Odejście od wysokiego stakingu: musimy być w stanie realizować inne zadania JAM/elves (przechowywanie, rozliczenia, finalność) bez polegania na dużym stakingu. Jeśli nadal trzeba będzie polegać na dużym stakingu, nie ma żadnej przewagi – ZK będzie tylko droższe.

Na tej podstawie sugeruję strategię ZK:

• Zacząć od łatwiejszych kierunków: np. opracować framework usług ZK-JAM, ale nadal korzystać z obecnego mechanizmu kryptograficzno-ekonomicznego JAM (elves) dla bezpieczeństwa.
• Wykorzystać zalety JAM: jeden JAM core ma dużą moc obliczeniową (CPU) i niezłe I/O (12MB), a wydajność PVM jest wysoka. Oznacza to, że można bezpośrednio weryfikować wiele dowodów ZK w JAM core, bez konieczności korzystania z kosztownych i złożonych zewnętrznych procesów dowodowych.
• Optymalizować etap dowodu: tradycyjny proces dowodu ZK zwykle składa się z kilku etapów, na końcu jest „kompresja dowodu”, by go zmniejszyć i ułatwić weryfikację. W JAM core, dzięki dużej mocy obliczeniowej, być może nie będzie to potrzebne, co pozwoli zaoszczędzić koszty.
• Priorytet dla dowodów przechowywania: ponieważ JAM core ma dużą moc obliczeniową, ale ograniczone I/O, dowody przechowywania mogą zrekompensować tę słabość i pozwolić na szybkie przetwarzanie dużej liczby transakcji.
• Inne proste zadania: np. weryfikacja podpisów – to nie jest wąskie gardło.

Innymi słowy, prawdziwym wyzwaniem jest zapewnienie, że dane, na których opierają się transakcje, są poprawne. To jest kluczowy problem do rozwiązania.

W średnim terminie rozsądnym podejściem jest:

Mamy już nową wizję Kusama – stworzenie sieci wspierającej ZK. Wykorzystanie tego budżetu i współpraca z innymi zespołami, by zainwestować w wydajne, rozproszone narzędzia do generowania dowodów, to bardzo dobry pomysł.

• Jeśli nikt jeszcze tego nie robi, należy rozpocząć nowy projekt;
• Jeśli już ktoś to robi lub chce się tym zająć, należy z nimi współpracować i wspierać ich działania.

Szczególną uwagę należy zwrócić na dowody wykonania PVM, bo to klucz do przyszłej kompatybilności ZK-JAM ze zwykłym JAM, a rozproszone generowanie dowodów jest niezbędne.

Celem jest zachowanie modułowości i otwartości systemu, by nadążać za najnowszymi badaniami. Tylko podążając za postępem technologicznym, możemy obniżyć koszt dowodu o kolejne rzędy wielkości i uczynić go naprawdę opłacalnym komercyjnie.

W dłuższej perspektywie, jeśli naprawdę chcemy, by ZK stało się głównym rozwiązaniem, musimy znaleźć sposób na zastąpienie stakingu. Dopóki staking istnieje, koszty będą bardzo wysokie.

Jak więc zbudować w pełni ZK-based JAM?

Po pierwsze, to ma sens tylko wtedy, gdy koszt ZK wystarczająco spadnie, a wykorzystanie core’a w obecnym modelu nie będzie już ekonomicznie uzasadnione. Na razie nie jest to pewne, więc to warunkowe założenie.

Gdy warunki będą spełnione, JAM może ewoluować w kierunku modelu bezpieczeństwa wielotrybowego:

• Z jednej strony oferować tanie, ale ograniczone bezpieczeństwo (jak elves, niskie koszty);
• Z drugiej – drogie, ale silniejsze, perfekcyjne bezpieczeństwo (oparte na ZK, koszt rośnie liniowo).

Kluczowe jest znalezienie sposobu na osiągnięcie finalności (finality) i przechowywania (storage) bez stakingu.

Jednym z możliwych kierunków jest Proof of Personhood. Jeśli uda się zintegrować taki mechanizm z protokołem, można znacznie zwiększyć efektywność i wykorzystanie kapitału.

Jednak by to osiągnąć, potrzebny jest bardzo silny mechanizm antysybilski (anti-sybil mechanism). Obecnie większość rozwiązań nie jest wystarczająco mocna – albo polegają na jakimś organie centralnym, albo organizacja zbiera dane użytkowników, by określić, kto jest prawdziwą osobą. To oczywiście prowadzi do centralizacji, a tylko nieliczne rozwiązania są bliskie realizacji.