JAM dostarczony w ciągu 12-20 miesięcy? Trzech kluczowych deweloperów ujawnia szczegóły dotyczące M1, modelu ekonomicznego PoP oraz przyszłości ZK!

JAM, ta nazwa była już od dawna tematem dyskusji w społeczności Polkadot. Po tym, jak Gavin Wood ogłosił szereg ważnych informacji podczas Web3 Summit, oczekiwania i pytania dotyczące JAM osiągnęły nowy poziom – czym właściwie jest JAM? Jakie zmiany przyniesie Polkadot? Jak daleko jesteśmy od oficjalnego uruchomienia?

Aby społeczność mogła lepiej zrozumieć temat, PolkaWorld zaprosiło trzech gości bezpośrednio zaangażowanych w rozwój JAM – Bryana z zespołu Acala, Junhę, dewelopera implementacji JAM w Rust o nazwie „FastRoll”, oraz Boya Maasa, dewelopera implementacji JAM w Zig „JAMZig” i współzałożyciela projektu Polona.

Ci trzej goście nie tylko głęboko uczestniczą w technicznym wdrażaniu JAM, ale także eksplorują jego potencjał w różnych kierunkach: od implementacji klientów w wielu językach, przez migrację narzędzi cross-chain, aż po przyszłe zastosowania PVM – są najlepszymi reprezentantami obecnego postępu JAM.

W tym wywiadzie, z pierwszej ręki zabiorą nas do świata JAM:

• Co oznaczają ważne aktualizacje JAM ogłoszone przez Gavina?
• Jak limit tokenów JAM (π × 1,000,000,000) i mechanizm PoP (Proof of Personhood) zmienią model ekonomiczny Polkadot?
• Jakie są cele techniczne i postępy Milestone 1? Kiedy wystartuje testnet?
• Jak ZK (zero-knowledge proofs) połączą się z JAM w przyszłości?
• Jak mechanizm zarządzania JAM i komitet redakcyjny Gray Paper wpłyną na długoterminową ewolucję protokołu?

Jeśli chcesz poznać przyszłość JAM i dowiedzieć się, jak przekształci on infrastrukturę ekosystemu Polkadot – tego odcinka nie możesz przegapić.

Poznanie trzech zespołów deweloperskich JAM

Kristen: Cześć wszystkim, jestem Kristen. Dziś zaprosiliśmy trzech kluczowych deweloperów JAM, którzy bezpośrednio uczestniczą w jego rozwoju. Jeśli śledzisz PolkaWorld lub najnowsze wydarzenia w Polkadot, zapewne wiesz, że obecnie trwa Web3 Summit, a Gavin podczas konferencji ogłosił ważne wiadomości dotyczące JAM. Społeczność zaczęła nas zasypywać pytaniami, więc zorganizowaliśmy ten live, aby dzięki naszym gościom pomóc społeczności lepiej zrozumieć, co Gavin ogłosił na Web3 Summit w kontekście JAM.

Na początek chciałabym poprosić naszych gości o krótkie przedstawienie się, opowiedzenie, za co odpowiadają w projekcie JAM i na jakim etapie są ich prace. Choć niektórzy z was są już naszymi stałymi gośćmi, zawsze pojawiają się nowi widzowie, więc proszę, przedstawcie się jeszcze raz. Zacznijmy od Junhy.

Junha: Dziękuję za zaproszenie, Kristen. Cześć wszystkim, jestem Junha i to mój pierwszy raz w tym programie.

Obecnie rozwijam implementację protokołu JAM w języku Rust, projekt nazywa się „FastRoll”. W tej chwili jestem jedyną osobą w zespole, więc można powiedzieć, że jestem niezależnym deweloperem.

Pracuję nad tym projektem od około roku, obecnie przygotowuję się do przeglądu pierwszego etapu (milestone), a jednocześnie rozpocząłem już prace nad niektórymi zadaniami drugiego etapu.

Kristen: Witaj, Junha! Teraz poprosimy Bryana o przedstawienie się.

Bryan: Cześć wszystkim, jestem Bryan z zespołu Acala. Obecnie prowadzę mały zespół, który rozwija inną implementację protokołu JAM, projekt nazywa się „Boka”.

• Obecnie kończymy pierwszy etap i jednocześnie aktualizujemy niektóre komponenty off-chain, przygotowując się do drugiego etapu.
• Ponadto, właśnie rozpoczęliśmy prace nad rekompilatorem PVM, ale jesteśmy jeszcze na bardzo wczesnym etapie, więc do ukończenia jeszcze daleko.

Kristen: Dziękuję, Bryan, za ponowną wizytę w naszym programie. Bryan był pierwszym gościem, którego zaprosiliśmy, by opowiedział o projekcie JAM, cieszę się, że znów jesteś z nami. Na koniec powitajmy Boya Maasa, z którym już wcześniej przeprowadziliśmy wywiad.

Boy Maas: Tak, tak, cześć wszystkim, jestem Boy Maas. Jestem niezależnym deweloperem implementacji protokołu JAM w języku Zig, nasz klient nazywa się „JAMZig”.

Jestem też współzałożycielem projektu w ekosystemie JAM, którego celem jest pełna migracja narzędzi i maszyny wirtualnej Solana (SVM) na JAM. Udało nam się już ukończyć wstępny proof-of-concept, co oznacza, że podstawowe funkcje już działają.

Czy JAM zostanie oficjalnie dostarczony w ciągu 12–20 miesięcy?

Kristen: Witaj, Boy Maas, Polona to rzeczywiście pionierski projekt, który ma na celu przyciągnięcie deweloperów Solana do ekosystemu Polkadot – świetny pomysł! Witam wszystkich gości.

Pierwsze pytanie chciałabym zadać Boyowi Maasowi. Uczestniczyłeś w Web3 Summit, widzieliśmy już sporo wiadomości o wystąpieniu Gavina na Twitterze, ale chciałabym, żebyś z własnej perspektywy opowiedział nam o swoich wrażeniach. Czy oglądałeś wystąpienie Gavina? Czy możesz podzielić się najważniejszymi informacjami?

Boy Maas: Oczywiście, to było naprawdę świetne doświadczenie. Możesz spotkać wielu członków społeczności Polkadot, wiele ciekawych prezentacji pozwala poczuć dynamikę całej społeczności, atmosfera jest bardzo pozytywna i pełna energii, co daje nadzieję na przyszłość. Dziś jest ostatni dzień, nie mogę się doczekać, by wrócić i dalej rozwijać nasz projekt.

Kristen: Oglądałeś wystąpienie Gavina?

Boy Maas: Tak, oglądałem.

Kristen: Czy jest coś, co szczególnie zapadło ci w pamięć? Widzieliśmy już trochę informacji na Twitterze, ale chcielibyśmy usłyszeć to z perspektywy dewelopera, w prostszy sposób.

Boy Maas: Jasne. Gavin podczas wystąpienia poruszył wiele tematów. Jest osobą bardzo wizjonerską i doświadczoną, więc jego decyzje i nowe pomysły mają duży wpływ na przyszłość społeczności.

Najważniejsze jest to, że ogłosił twardy limit podaży tokenów JAM na poziomie „π razy 1,000,000,000” (π × 1,000,000,000), co jest bardzo istotne i będzie miało wiele konsekwencji.

Kolejnym kluczowym punktem było to, że starał się jasno przekazać społeczności Polkadot, czym właściwie jest JAM. JAM zasadniczo ma wzmocnić i wspierać ekosystem Polkadot, jego rola to napędzanie infrastruktury całego ekosystemu. Wszyscy teraz próbują zrozumieć i dostosować się: czym jest JAM? Co potrafi? Jak współpracuje z główną siecią Polkadot? Jak to działa?

Jako deweloperzy znamy techniczne szczegóły JAM, ale rozumiem, że dla większości ludzi to wciąż etap „nie do końca wiadomo, co JAM zmieni”. Wszyscy próbują wyobrazić sobie, jak będzie wyglądał świat napędzany przez JAM.

Kristen: Brzmi bardzo ciekawie. Zauważyłam też, że Gavin wspomniał, iż JAM zostanie oficjalnie dostarczony w ciągu 12–20 miesięcy. Wasz projekt Polona chyba mocno polega na tym harmonogramie? Czy wasze tempo rozwoju będzie zsynchronizowane z JAM?

Boy Maas: Tak, Kristen, masz całkowitą rację. Nie planowaliśmy być gotowi na start testnetu, ale według obecnego harmonogramu nasze plany idealnie się pokrywają – gdy tylko JAM testnet wystartuje, możemy od razu zacząć korzystać. Gdy sieć ruszy oficjalnie, natychmiast się dostosujemy.

Czym jest M1 JAM?

Kristen: Świetnie, cieszę się z tych postępów. Teraz chciałabym zadać pytanie Junhy.

JAM niedawno ogłosił ważną aktualizację techniczną i jasno określił cele pierwszego etapu (milestone 1). Jednak niektórzy słuchacze nie do końca rozumieją, czym dokładnie jest milestone 1 i na jakim jest etapie. Czy możesz nam wyjaśnić, co obejmuje milestone 1? Jak postępują prace nad testnetem? Kiedy przewidujesz jego uruchomienie?

Junha: Oczywiście. Jak wspomniałaś, Gray Paper JAM został niedawno zaktualizowany do wersji 0.7.0. Gavin podczas wystąpienia powiedział też, że od tej wersji Polkadot Fellowship może zacząć oceniać milestone 1. Większość zespołów pracujących nad klientami JAM przygotowuje się właśnie do tej oceny.

Celem milestone 1 jest dostarczenie klienta węzła, który potrafi „prawidłowo importować bloki”, czyli weryfikować podstawową logikę działania JAM.

Konkretnie chodzi o to, by klient, otrzymując serię bloków (zarówno poprawnych, jak i niepoprawnych), potrafił rozpoznać, które z nich mają prawidłowy format. Dla poprawnych bloków klient musi odczytać dane zewnętrzne, wykonać logikę transformacji stanu (czyli rdzeń działania blockchaina) i wygenerować nowy stan łańcucha. Blockchain to w istocie maszyna stanów: mając stan początkowy, importując bloki i wykonując odpowiednią logikę, uzyskujemy kolejny stan.

Ocena milestone 1 polega na sprawdzeniu, czy implementacja klienta po zaimportowaniu tych bloków generuje prawidłowy kolejny stan.

Metoda oceny jest prosta: przygotowujemy zestaw bloków testowych i porównujemy, czy różne implementacje generują identyczny stan końcowy. Wynik stanu można podsumować tzw. „vertical root”, więc porównanie jest bardzo wygodne. Istnieje już narzędzie testowe JAM Conformance Fuzzer, które automatycznie generuje wiele bloków z losowymi danymi i sprawdza, czy różne implementacje uzyskują ten sam stan końcowy.

To świetna okazja, by znaleźć i naprawić kluczowe błędy oraz przygotować się do bardziej złożonych etapów.

Kristen: Rozumiem, a kiedy przewidujesz uruchomienie testnetu?

Junha: Masz na myśli testnet JAM? Niektóre zespoły już próbują interoperacji między własnymi binarkami, ale moim zdaniem prawdziwy, działający testnet będzie gotowy dopiero po milestone 2.

Milestone 1 weryfikuje głównie logikę transformacji stanu węzła, co nie wystarcza do działania pełnego testnetu. Dopiero milestone 2 oceni, czy implementacje ukończyły całą specyfikację protokołu sieciowego (networking spec). Ta część protokołu nie jest jeszcze stabilna, nawet nie została opisana w Gray Paper. Gdy tylko specyfikacja sieciowa się ustabilizuje i implementacje ją ukończą, będzie można testować interoperacyjność węzłów.

Wtedy będzie odpowiedni moment, by przygotować oficjalny testnet. Oczywiście niektóre zespoły mogą próbować wcześniej, ale ja planuję dołączyć do testnetu dopiero po milestone 2.

Kristen: Rozumiem. Czy uważasz, że nowe ogłoszenia Gavina podczas szczytu wpłyną na tempo twoich prac?

Junha: Myślę, że większość z tych ogłoszeń dotyczy długoterminowej wizji, więc w krótkim terminie nie wpłyną znacząco na moje plany. Obecnie skupiam się na ukończeniu milestone 1, co zajmie jeszcze kilka tygodni, może miesiąc, zanim dostarczę w pełni zgodną implementację klienta. Na razie nie zmieniam strategii rozwoju.

Oczywiście, w perspektywie 1–3 lat te nowe kierunki mogą mieć wpływ, ale na razie skupiam się na milestone 1.

Jakie skutki przyniesie zastąpienie NPoS przez PoP?

Kristen: Rozumiem, dziękuję za twoje odpowiedzi! Teraz mam „twarde” pytanie do Bryana, dotyczące ekonomii tokenów. Wiemy, że deweloperzy niechętnie oceniają modele ekonomiczne, ale to jeden z najważniejszych tematów dla społeczności. Gavin ogłosił, że PoP (Proof of Personhood) zastąpi NPoS, nagrody dla walidatorów będą stałe, a podaż DOT zostanie ograniczona przez mechanizm halvingu. Jako deweloper, co o tym sądzisz? Jakie będą największe skutki? Czy popierasz te zmiany? Masz jakieś obawy lub sugestie?

Bryan: To rzeczywiście duża zmiana.

Pokrótce przypomnę tło: niezależnie czy to proof-of-work (PoW), proof-of-stake (PoS), czy teraz proponowany Proof of Personhood (PoP), te mechanizmy mają na celu zabezpieczenie sieci przed atakami typu double-spend czy rozgałęzieniem łańcucha.

Każdy mechanizm ma swoje koszty – PoW to koszt nagród blokowych i ogromnego zużycia energii, PoS wymaga nagradzania stakerów.

Nowy Proof of Personhood bardzo różni się pod względem mechanizmu nagród. Polkadot używał NPoS (Nominated Proof of Stake), który nie był tak kosztowny jak PoW, ale wciąż wymagał emisji nowych tokenów, by nagradzać walidatorów i nominatorów, co prowadziło do inflacji.

Wprowadzenie PoP ma na celu obniżenie kosztów zabezpieczenia sieci, odejście od ekonomicznych zachęt i kar na rzecz nowego podejścia – szczegóły nie są jeszcze znane, ale kluczową ideą jest „jeden człowiek, jeden głos”. Jeśli to się uda, oszukiwanie będzie znacznie trudniejsze, a bezpieczeństwo sieci łatwiejsze do zapewnienia, bez konieczności wypłacania dużych nagród w tokenach.

Z punktu widzenia sieci to duża oszczędność kosztów, co jest pozytywne. Ale są też skutki uboczne – wielu ludzi polegało na stakingu, by zdobywać więcej tokenów, a ten model zniknie. Nadal będą sposoby zdobywania tokenów, ale w znacznie mniejszej ilości. Z drugiej strony, jeśli wydatki sieci spadną, wartość twoich tokenów wzrośnie, więc ogólnie oceniam to pozytywnie.

To może też pobudzić DeFi – gdy staking stanie się mniej opłacalny, użytkownicy mogą przenieść środki do innych protokołów DeFi, np. pożyczek czy dostarczania płynności, co ożywi ekosystem DeFi.

Oczywiście, szczegóły trzeba jeszcze poznać, a nawet wtedy trudno przewidzieć wszystkie skutki. Osobiście patrzę na te zmiany pozytywnie.

Kristen: W krótkim terminie może to być duży cios dla walidatorów, bo ich dochody spadną. Czy sądzisz, że początkowo pojawią się problemy?

Bryan: To zależy od sposobu przejścia. Zmiana nie nastąpi z dnia na dzień, tylko stopniowo, jak halving podaży tokenów – nie zetniemy inflacji do zera od razu, tylko będziemy ją stopniowo zmniejszać, dając czas na dostosowanie się do nowych warunków.

Musimy zapewnić bezpieczeństwo sieci, walidatorzy muszą pokryć koszty i mieć zysk, a użytkownicy muszą mieć motywację do nominowania i wybierania dobrych walidatorów. Te założenia się nie zmienią, po prostu nie chcemy już płacić tak wysokich nagród. Zmiany będą, ale mamy nadzieję, że nowy model ekonomiczny zminimalizuje ich negatywny wpływ.

Czym jest zkJAM?

Kristen: Rzeczywiście, opinie społeczności są podzielone. Na początku wszyscy domagali się „zmniejszenia inflacji”, a teraz, gdy przechodzimy do deflacji, pojawiają się narzekania. Uważam, że to dobry kierunek, dziękuję za twoje pogłębione spojrzenie.

Porozmawiajmy teraz o temacie technicznym – ZKJAM. To pojęcie zobaczyłam na slajdzie Gavina, wygląda na dość koncepcyjne. Ale „zero-knowledge proofs” (ZK) są ostatnio bardzo popularne w Web3, wielu uważa, że ZK to ostateczne rozwiązanie dla rollupów i skalowalności. Jak może wyglądać połączenie ZK i JAM w przyszłości? Chciałabym poznać wasze opinie. Junha, zacznij proszę.

Junha: Jasne. Gavin porównał JAM do zdecentralizowanego „super bare-metal computer”, a usługi na nim działające do systemów operacyjnych na sprzęcie, jak Windows czy macOS.

Jeśli w przyszłości ZK zostanie zintegrowane z JAM, z punktu widzenia deweloperów i użytkowników nie będzie to rewolucyjna zmiana – doświadczenie deweloperskie i użytkowe pozostanie zasadniczo takie samo.

Nawet jeśli mechanizm bezpieczeństwa JAM przejdzie z obecnego „audytowanego modelu re-execution” na model „oparty na dowodach ZK”, jeśli upgrade będzie dobrze przetestowany i skuteczniejszy, warto go wdrożyć.

Więc jeśli ZK i JAM będą dobrze współpracować i przyniosą korzyści, upgrade jest możliwy, a doświadczenie użytkownika nie zmieni się znacząco.

Kristen: Dziękuję za odpowiedź. Może niektórzy słuchacze pogubili się w technicznych terminach, ale nie martwcie się, przygotujemy polską wersję artykułu, którą można będzie przeczytać i przemyśleć. Teraz poproszę Bryana o twoją opinię.

Bryan: Myślę, że trzeba rozróżnić dwa pojęcia: jedno to JAM jako infrastruktura dla rollupów zabezpieczanych przez ZK, drugie to JAM sam w sobie zabezpieczany przez ZK. To zupełnie różne rzeczy.

Dzięki PVM w JAM można wdrożyć dowolne algorytmy lub architektury związane z ZK, np. nowe protokoły ZK-Rollup, jako usługi na JAM. To jest stosunkowo łatwe.

Ale jeśli JAM sam w sobie ma być zabezpieczany przez ZK, to wymaga ogromnych badań i optymalizacji istniejących algorytmów. Obecnie to bardzo „frontierowy” temat. Wszystko zależy od stanu obecnego – obecne algorytmy są zbyt wolne i drogie, ale może jutro ktoś wymyśli algorytm 100 razy szybszy i wszystko się zmieni.

Więc jeśli pojawi się naprawdę użyteczna integracja ZK, która zwiększy bezpieczeństwo JAM, oczywiście będę za jej wdrożeniem.

Kristen: Mam nadzieję, że w tej dziedzinie rzeczywiście nastąpi przełom. Boy Maas, jako doświadczony deweloper, co sądzisz o tym temacie?

Boy Maas: Myślę, że Bryan i Junha już wyczerpująco to opisali. Jednym z powodów, dla których lubię JAM, jest jego pragmatyzm. Wszystkie decyzje projektowe mają na celu uruchomienie systemu i umożliwienie obliczeń. Jak powiedział Bryan, obecnie ZK jest zbyt drogie i nierealistyczne. Wyobrażam sobie, że w przyszłości można będzie zastosować „model hybrydowy”, czyli tradycyjny audyt i ZK równolegle.

Na razie ZK jest zbyt kosztowne i niepraktyczne, ale w ciągu 12 miesięcy do 5 lat w tej dziedzinie na pewno nastąpią zmiany. Jeśli ZK stanie się wydajne, będzie to bardzo atrakcyjna technologia, mogąca zdefiniować na nowo model bezpieczeństwa i architekturę systemu.

Na razie jednak model hybrydowy jest bardziej praktyczny: zachowuje użyteczność, a aplikacje wymagające bezpieczeństwa ZK mogą z niego korzystać.

JAM powoła komitet redakcyjny Gray Paper

Kristen: Dziękuję za wasze odpowiedzi. Przejdźmy do kolejnego tematu: mechanizmu zarządzania JAM.

Gavin nadal będzie głównym redaktorem Gray Paper, a jednocześnie ogłosił powołanie „komitetu redakcyjnego Gray Paper”, złożonego z zaangażowanych technicznie kontrybutorów JAM, którzy będą wspólnie decydować o aktualizacjach, priorytetach i kluczowych decyzjach dotyczących protokołu. Jako deweloperzy, czy uważacie, że taki sposób zarządzania protokołem jest wykonalny? Czy może dojść do „odejścia od pierwotnych założeń”? Jak sobie z tym radzić? Zacznijmy od Boya Maasa.

Boy Maas: To bardzo ważne pytanie. W tak zaawansowanej i specjalistycznej dziedzinie komitet odpowiedzialny za aktualizacje Gray Paper jest bardzo rozsądnym i koniecznym rozwiązaniem. Decyzje muszą podejmować osoby z głęboką wiedzą i doświadczeniem praktycznym w JAM, by były mądre. Prowadzenie komitetu przez Gavina jest bardzo logiczne, więc w pełni popieram taki model zarządzania.

Kristen: Czyli uważasz, że decyzje podejmowane przez profesjonalny zespół to dobra rzecz?

Boy Maas: Tak, całkowicie się zgadzam.

Kristen: Dobrze, Bryan, a ty co sądzisz?

Bryan: W zasadzie każdy projekt jest zarządzany przez jakiś „komitet”, różni się tylko skala i skład. Różnica polega na tym, czy proces zarządzania jest jasno zdefiniowany.

Uważam, że spisanie procesu zarządzania to postęp – wszyscy wiedzą, jak podejmowane są decyzje, co zwiększa przejrzystość i ułatwia przyszłą optymalizację. Bez zasad nie ma czego poprawiać.

Zawartość Gray Paper jest bardzo złożona, prawie wszyscy deweloperzy JAM czytali ją wielokrotnie w różnych wersjach. Szczerze mówiąc, może tylko Gavin rozumie ją w 100%, a nawet on nie zna każdego szczegółu. Wiele osób uczestniczy w poprawkach, np. literówek, wzorów, logiki – to proces współpracy.

Moim zdaniem tylko osoby z wieloletnim doświadczeniem w tej dziedzinie powinny uczestniczyć w edycji Gray Paper. Nawet drobna zmiana może mieć ogromne konsekwencje. To kwestia przyszłości Web3, a nawet internetu, i bezpieczeństwa dużych aktywów – trzeba być bardzo ostrożnym. Przejrzystość i otwartość są kluczowe. Każdy może zgłaszać sugestie, ale musi udowodnić, że je rozumie, inaczej wartościowe opinie zginą w szumie.

Kristen: Czyli uważasz, że komitet powinien mieć mechanizm określający, kto może do niego dołączyć i jak organizować członków? Bo bez zasad łatwo o rozbieżności i odejście od pierwotnych założeń.

Bryan: Dlatego potrzebujemy smart kontraktów i jasnych procedur, wszystko powinno być spisane. Jeśli zasady są czarno na białym, każdy może je nadzorować, a cały proces jest przejrzysty – wtedy ryzyko odejścia od założeń jest znacznie mniejsze. Jeśli wszystko dzieje się za zamkniętymi drzwiami, łatwo o błędy. Przejrzystość jest kluczowa, zwłaszcza jeśli proces można wymusić smart kontraktem – to daje szansę na długoterminowe przetrwanie mechanizmu.

Kristen: Rozumiem, pamiętam, że społeczność bitcoinowa ma podobny komitet deweloperów.

Bryan: Tak, społeczność bitcoinowa ma grupę kluczowych deweloperów, ale ostateczne decyzje podejmowane są przez forki – wygrywa łańcuch z największą mocą obliczeniową.

Kristen: Rozumiem, dziękuję za wyjaśnienie. Na koniec posłuchajmy opinii Junhy.

Junha: Uważam, że powołanie komitetu redakcyjnego to bardzo naturalny i sensowny krok. JAM to wyjątkowy projekt: zanim powstało w pełni działające oprogramowanie, najpierw opublikowano kompletną specyfikację techniczną (Gray Paper). Zawiera ona wiele wzorów matematycznych, które definiują zachowanie systemu. Najpierw dokumentacja, potem rozwój – to dążenie do większej decentralizacji i odporności systemu.

Dlatego Gray Paper była już wielokrotnie poprawiana i nawet po wydaniu wersji 1.0 będzie dalej ewoluować.

Wraz z pojawieniem się kolejnych zespołów wdrażających JAM i budujących testnety, na pewno znajdziemy obszary do optymalizacji, by protokół był wydajniejszy i łatwiejszy do wdrożenia. Ze względu na charakter projektu, Gray Paper będzie ewoluować nawet po uruchomieniu mainnetu, a nawet może dojść do hard forka.

W takiej sytuacji lepiej, by za rozwój specyfikacji odpowiadała grupa osób, a nie tylko autor.

Jak powiedział Bryan, przejrzystość jest bardzo ważna, proces decyzyjny komitetu musi być jawny. Mam też nadzieję, że więcej zespołów korzystających z JAM będzie aktywnie uczestniczyć w przeglądzie dokumentacji, korektach i feedbacku, a nie tylko „ufać, że Gavin ma rację”. Taka aktywna partycypacja pozwoli znaleźć miejsca do poprawy. To dobry początek, na który warto czekać. W kontekście JAM taki model ciągłego ulepszania specyfikacji jest naturalny i sensowny.

Możliwe, że nie doceniamy, co JAM wniesie do blockchaina

Kristen: To rzeczywiście dobry początek. Jeśli cały proces będzie przejrzysty, to świetnie. Dziękuję za wasze odpowiedzi, myślę, że omówiliśmy już wszystkie przygotowane tematy.

Na koniec, czy ktoś chciałby coś dodać? O JAM, o Web3 Summit, coś, czego nie zdążyliście powiedzieć? Zacznijmy od Bryana.

Bryan: Nie mam nic szczególnego do dodania. JAM to infrastruktura bazowa – jest ważna, ale nie najważniejsza. Najważniejsze są usługi i aplikacje budowane na JAM – użytkownicy nie korzystają bezpośrednio z JAM, tylko z usług na nim opartych.

Więc uruchomienie JAM to dopiero pierwszy krok do osiągnięcia celu. Powinniśmy bardziej skupiać się na usługach i aplikacjach działających na JAM, bo to one mają realny wpływ na użytkowników. Przed nami jeszcze wiele pracy, nie możemy ograniczać się tylko do protokołu JAM, musimy patrzeć szerzej.

Kristen: Dziękuję. Boy Maas, czy chcesz coś dodać o Polona lub JAM?

Boy Maas: Oczywiście. Przede wszystkim o JAM. Pamiętam, jak Gavin prezentował JAM w Lizbonie. Już wtedy miałem silne przeczucie, że możemy nie doceniać, co ta platforma wniesie do społeczności blockchain.

JAM oferuje „przepustowość” i elastyczność, jakiej nie miała żadna wcześniejsza blockchain. To już można uznać za ważny kamień milowy w rozwoju blockchaina, zwłaszcza jeśli chodzi o nowe aplikacje, które może obsłużyć – to naprawdę wyjątkowe.

Dodam jeszcze, że nasz projekt Polona szybko się rozwija, mamy już proof-of-concept na JAM. Przenieśliśmy SVM z Solana na PVM, co oznacza, że można uruchamiać bytecode Solana bezpośrednio na JAM, włącznie z wywołaniami między kontraktami – wszystko już działa, to naprawdę niesamowite. To pokazuje siłę usług JAM.

Kristen: Świetnie, dziękuję! Na koniec poproszę Junhę o podsumowanie.

Junha: Mam nadzieję, że więcej osób zainteresuje się JAM, Polkadot i Gray Paper. Chciałbym nawiązać kontakt z większą liczbą osób i dzielić się pomysłami.

Klient JAM jest wciąż w fazie rozwoju, więc nie ma jeszcze wielu „gotowych” przykładów aplikacji. Zespół Gavina pokazał kilka demo, ale nie ma jeszcze wystarczająco dużo rzeczywistych przypadków, które przekonałyby ludzi, co ten system naprawdę potrafi.

Jednak jeśli interesuje cię idea stojąca za Web3 i chcesz przesuwać granice tej branży, JAM to projekt wart głębszego poznania. Pracuję nad nim samodzielnie, więc bardzo chciałbym poznać więcej osób o podobnych zainteresowaniach, nawet jeśli tylko wspólnie czytać Gray Paper i dyskutować. Mam nadzieję, że będziemy mogli wymieniać się pomysłami, a nawet wspólnie tworzyć nowe rzeczy, zwłaszcza po ukończeniu klienta węzła.

Kristen: Dziękuję za twoje słowa i dziękuję wszystkim gościom za dzisiejsze świetne opinie i spostrzeżenia! Dziękuję wszystkim słuchaczom za udział, zachęcam do śledzenia Twitterów naszych gości – znajdziecie je w ogłoszeniach PolkaWorld. Niezależnie czy jesteś zwykłym użytkownikiem, czy deweloperem, warto śledzić najnowsze postępy JAM. Dziękuję za wysłuchanie, do zobaczenia następnym razem! Do widzenia!