Portal wdrożeniowy Polkadot: dlaczego projekty wybierają wdrożenie na Polkadot zamiast zostania L2?

W przeszłości wdrożenie Rollup na Polkadot nigdy nie było łatwym zadaniem. Im bardziej elastyczny system, tym bardziej skomplikowany proces wdrożenia: od aktualizacji SDK, przez aukcje slotów, po zarządzanie i aktualizacje runtime – każdy z tych etapów mógł stanowić wyzwanie dla zespołu.

Aby zmienić tę sytuację, Parity w tym roku wprowadziło Polkadot Deployment Portal (PDP) – „jedno miejsce” od budowy, przez wdrożenie, aż po integrację. Cel jest jasny: obniżyć próg wejścia, uprościć procesy i umożliwić każdemu zespołowi szybkie i stabilne uruchomienie własnego Rollup na Polkadot.

W tym artykule Santi Balaguer, szef rozwoju produktu w Parity, przeprowadzi nas przez ewolucję doświadczeń związanych z wdrażaniem na Polkadot w ostatnich latach, wyjaśni koncepcję stojącą za PDP oraz podzieli się, jak to narzędzie krok po kroku zmienia sposób uruchamiania Rollup.

Doświadczenie wdrażania na Polkadot: Im większa elastyczność systemu, tym większa złożoność

Jay: Witaj w Space Monkeys, dziś naszym gościem jest Santi Balaguer, odpowiedzialny za rozwój produktu w Parity. Dziś porozmawiamy o PDP, czyli…?

Santi: To Polkadot Deployment Portal – portal wdrożeniowy Polkadot.

Jay: Zanim zaczęliście pracę nad PDP, czym zajmowałeś się przez ostatnie cztery, pięć lat w Parity?

Santi: Przez cały czas byłem blisko społeczności deweloperów, głównie pomagając im uruchamiać parachainy i Rollups na Polkadot. Tak jak wspomniałeś, byłem w Parity jeszcze zanim parachainy zostały uruchomione.

Jay: Wśród projektów, z którymi miałeś kontakt, są jakieś, które dobrze znamy?

Santi: Wcześniej prowadziłem projekt Substrate Builders, w którym było wiele znanych projektów. Najbardziej zapadł mi w pamięć zespół Hydration. Pamiętam, jak Jakub prezentował ich pomysł na Omnipool i problemy, które Hydration miało rozwiązać. Pokazał wtedy kultowy mem „money printer goes brrrr”, żeby wyjaśnić, dlaczego potrzebują nowego rozwiązania. Do dziś często żartuję z Jakubem na ten temat.

Jay: Haha, świetnie. Na pewno widziałeś wiele projektów, które odniosły sukces na Polkadot, ale też słyszałeś o ich bolączkach. Czy możesz opowiedzieć, co było największym wyzwaniem przy wdrażaniu projektów na Polkadot w ostatnich latach?

Santi: Oczywiście. Polkadot to bardzo złożony system – trzeba go naprawdę zrozumieć, żeby projekt działał płynnie. Ta złożoność wynika z elastyczności – im bardziej elastyczny system, tym większa złożoność.

Na początku, żeby uruchomić parachain na Polkadot, trzeba było radzić sobie z różnymi „breaking changes” w SDK. Wtedy nie było jeszcze Polkadot SDK, tylko Substrate, co było inne niż dziś. Po skonfigurowaniu środowiska deweloperskiego trzeba było zdobyć poparcie społeczności i wziąć udział w aukcji slotów. Sama aukcja była wyzwaniem – trzeba było zdobyć wystarczająco dużo wsparcia, a wynik był znany dopiero w ostatniej chwili. Nawet jeśli się wygrało, trzeba było czekać trzy miesiące na uruchomienie parachainu. Slot był przyznawany tylko na dwa lata. Trzeba było więc działać na pełnych obrotach zarówno technicznie, jak i w społeczności, żeby zdobyć miejsce na Polkadot.

Jay: Tak. Ale w ostatnich latach doświadczenie znacznie się poprawiło. Możesz opowiedzieć o tej zmianie?

Santi: Oczywiście. Uważam, że Parity wykonało ogromną pracę, zwłaszcza w ograniczaniu breaking changes w Polkadot SDK.

Chociaż aktualizacje nadal się zdarzają, są znacznie bardziej stabilne niż kiedyś, a kompatybilność między wersjami jest dużo lepsza. Teraz deweloperzy mogą spokojnie polegać na wybranej wersji SDK. Niektóre parachainy nadal używają starej wersji Substrate, ale nadal działają poprawnie na Polkadot.

Kolejna sprawa to wprowadzenie Coretime (choć samo w sobie jest złożone), ale znacznie obniżyło próg wejścia dla deweloperów. Ułatwiło eksperymentowanie i znacznie obniżyło barierę wejścia na Polkadot – powinniśmy to jak najlepiej wykorzystać.

Dlaczego dziś projekty wybierają wdrożenie na Polkadot, a nie jako L2 na Ethereum?

Jay: Mimo wielu wyzwań, dziś wiele z nich zostało rozwiązanych. Dlaczego więc projekt miałby dziś wybrać wdrożenie na Polkadot? Dlaczego nie zrobić L2 na Ethereum albo własnego L1? Jaka jest tego przyczyna?

Santi: To bardzo ciekawe pytanie. Uważam, że jako społeczność powinniśmy więcej o tym mówić i promować te zalety. Moim zdaniem Polkadot to jedyny blockchain, który od początku został zaprojektowany do natywnego wsparcia Rollup. Daje deweloperom infrastrukturę, której nie znajdą nigdzie indziej.

• Na przykład Polkadot oferuje bardzo dużą warstwę dostępności danych (data availability) dla Rollup, podczas gdy na Ethereum L2 trzeba polegać na zewnętrznych systemach lub „blobach”.

• Kolejny przykład to natywna komunikacja między parachainami (cross-chain messaging), czego nie ma na innych Rollup. Brak tej funkcji obniża bezpieczeństwo systemu.

• Jeśli chodzi o wydajność, Spamming już udowodnił, że TPS Rollup na Polkadot jest jednym z najwyższych w branży.

• Elastyczne skalowanie – Polkadot to jedyny system, który może dynamicznie zwiększać lub zmniejszać infrastrukturę w zależności od potrzeb. Na przykład, jeśli Mythical nagle uruchomi nową grę i spodziewa się 10-krotnego wzrostu użytkowników w pierwszym tygodniu, praktycznie bez zmian mogą obsłużyć ten ruch.

Myślę, że w poprzednich dyskusjach o „parachainach i Rollup” nie udało się uczynić z Polkadot głównego bohatera – to była stracona szansa. Ale nadal mamy czas, by przywrócić go na centralną scenę.

Jay: Tak, wspominałeś mi wcześniej, że Polkadot od samego początku był projektowany z myślą o Rollup, tylko na początku nie nazywaliśmy tego Rollup.

Santi: Dokładnie. Jest jeszcze jedna rzecz, o której często zapominamy – wspólne bezpieczeństwo (shared security). Patrząc na historię blockchain: najpierw był bitcoin, potem Ethereum. Potem pojawiło się wiele nowych „Ethereum”, które reklamowały się jako „lepsze, bo mają cechy A, B, C”. Problem w tym, że zapewnienie bezpieczeństwa nowego łańcucha jest bardzo trudne. Potrzebujesz dużego, silnego zestawu walidatorów, a to nie jest łatwe.

Wtedy Gavin pomyślał: dlaczego nie udostępnić bezpieczeństwa jako usługi, wbudowanej w warstwę bazową? To właśnie wyróżnia Polkadot. Nie tylko zapewnia wspólne bezpieczeństwo, ale także umożliwia efektywną komunikację między Rollup – to coś, w czym Polkadot jest naprawdę dobry.

Jak powstał pomysł na PDP?

Jay: Świetnie. Jeśli Rollup chce mieć natywną dostępność danych (i to na dużą skalę), nie polegać na innych projektach, mieć wysokie TPS i przepustowość oraz bezproblemową komunikację z innymi Rollup, to Polkadot jest naprawdę atrakcyjny. Ale przed PDP wdrożenie parachainu było bardzo skomplikowane i czasochłonne. Skąd więc wziął się pomysł na PDP?

Santi: Tak naprawdę ten pomysł dojrzewał od jakiegoś czasu, choć faktycznie zaczęliśmy działać w listopadzie zeszłego roku.

Od marca-kwietnia tego roku nasz zespół pracuje nad tym projektem na pełen etat i postępy są szybkie – krok po kroku realizujemy ten pomysł. Pomysł dojrzewał długo, a w branży pojawiły się podobne rozwiązania. W ekosystemie Ethereum są Conduit i Gelato; na Polkadot wcześniej był Tanssi, ale potem skupili się na Ethereum, choć koncepcja była podobna.

Zauważyliśmy, że na Polkadot nadal nie ma takiego rozwiązania, więc postanowiliśmy zrobić to sami, by mieć pewność, że się uda. Znamy Polkadot najlepiej i wiemy, jak ułatwić deweloperom wdrażanie projektów – to właśnie cel PDP.

Nie podejmujemy decyzji za deweloperów, lecz dajemy wskazówki i wybór

Jay: Do kogo właściwie skierowany jest PDP? Pamiętam, że na początku Polkadot był problem, że niektóre projekty od razu robiły Rollup, choć wystarczyłby smart contract. Jakie projekty naprawdę potrzebują własnego Rollup?

Santi: To dobre pytanie, ale nie ma jednej odpowiedzi. Nadal zdarzają się projekty, dla których smart contract byłby wystarczający. Czasem jednak zespół potrzebuje niezależności i nie chce polegać na infrastrukturze innych łańcuchów; czasem przewidują ogromną przepustowość w przyszłości, więc wolą od razu zrobić Rollup – takie powody sprawiają, że potrzebują własnego łańcucha lub większej niezależności infrastrukturalnej.

Na przykład Omnipool Hydration – można się spierać, czy nie wystarczyłby smart contract, ale moim zdaniem nie, własny łańcuch ma sens. Z drugiej strony Uniswap na Ethereum – zaczęli od smart contract, potem zrobili własny łańcuch, ale czy naprawdę go potrzebują? Może nie, ale mają własne powody biznesowe.

Nie ma więc jednej reguły – to efekt połączenia technologii i biznesu. Najważniejsze dla mnie jest to, by nie podejmować decyzji za deweloperów, tylko dawać im wskazówki i wybór. Niezależnie od tego, czy chcą zrobić Rollup czy smart contract, powinni mieć możliwość łatwego eksperymentowania.

Odkrywamy cały proces PDP: od budowy, przez wdrożenie, po dostęp – uruchomienie Rollup jest tak proste

Jay: Załóżmy więc, że zespół podjął decyzję – samodzielnie lub z pomocą Magenta Labs czy zespołu BD – i chce wdrożyć Rollup na Polkadot. Jakie doświadczenie czeka ich w PDP? Jak wygląda obecnie proces wdrożenia?

Santi: W PDP podzieliliśmy proces na trzy główne etapy: Build (budowa) – Deploy (wdrożenie) – Access (dostęp), które są ze sobą powiązane.

W fazie „budowy” kluczowe pytanie brzmi: „Od czego zacząć?”. Nasz pomysł to: najlepiej zacząć od szablonów runtime (runtime templates). Obecnie OpenZeppelin pracuje nad odpowiednimi szablonami, a zespoły Pop CLI i ROG również działają w tym kierunku. Pop CLI to narzędzie, którego możesz używać na swoim komputerze do pisania Rollup. Współpracujemy z nimi, by zintegrować Pop CLI z pozostałymi etapami PDP (wdrożenie i dostęp).

Na przykład, jeśli zbudujesz Rollup w Pop CLI, możesz bezpośrednio połączyć się z PDP i wdrożyć Rollup – tak to zaprojektowaliśmy i wdrożyliśmy. Dzięki temu deweloperzy mogą przejść cały proces przez CLI, podobnie jak w Heroku czy Vercel w Web2, które mają własne CLI. Jeśli preferujesz tę metodę, możesz korzystać z CLI; oczywiście możesz też wybrać interfejs graficzny. Obie opcje są dostępne.

Jay: Czyli oprócz budowania na szablonach, można też użyć Pop CLI, a potem wdrożyć. Czy PDP pomaga deweloperom w podejmowaniu decyzji, czy to tylko narzędzie i zespół sam musi działać?

Santi: Obie opcje. Chcemy, by PDP było narzędziem samoobsługowym, ale jeśli pojawią się kluczowe problemy, oczywiście wspieramy i pomagamy. Jeśli ktoś chce sam spróbować – nie ma problemu, haha.

Jay: Fajne. Możesz podać kilka przykładów szablonów? Które lubisz najbardziej?

Santi: Na przykład zespół ROG ma gotowy szablon Pilot Revive, który możesz od razu użyć do uruchomienia. OpenZeppelin ma szablon Frontier – jeśli chcesz uruchomić łańcuch z funkcjonalnością EVM, możesz go użyć.

Jay: Super, czyli są różne opcje związane ze smart contract.

Santi: Tak. Są też szablony bez smart contract. Jeśli ktoś chce zrobić łańcuch do przechowywania aktywów, zwłaszcza projekt związany z real world assets (RWA), też znajdzie odpowiedni szablon. Na początek jest wiele opcji, a potem można je rozwijać.

Jay: Czy można dodać własny Pallet do szablonu?

Santi: Na początku nie. Najpierw startujesz z szablonu, a potem krok po kroku przechodzisz przez aktualizacje runtime. Chcemy, by zespoły stopniowo znajdowały product-market fit. To bardzo ciekawe rozwiązanie, nad którym teraz pracujemy – korzystamy z narzędzia zespołu Puppet, które porównuje nowy runtime z obecnym, generuje raport, wskazuje zmiany, potencjalny wpływ na deweloperów i na co trzeba uważać.

Jay: Tak, widziałem, że właśnie to zintegrowaliście – świetna sprawa.

Santi: Tak, skończyliśmy to w tym tygodniu. Dzięki temu dostajesz raport z aktualizacji runtime, by upewnić się, że wszystko jest zgodne z oczekiwaniami. Chcemy dodać jeszcze jedną funkcję: symulację kilku bloków w tle, by przetestować nowy runtime. Jeśli wszystko działa, dostajesz komunikat „możesz wdrożyć”; jeśli są problemy, informujemy „testy nie przeszły, sprawdź jeszcze raz”. To pozwala uniknąć błędów przy aktualizacjach. Jedną z zalet Polkadot jest elastyczne wsparcie dla aktualizacji runtime – zespoły mogą szybko iterować i szukać product-market fit.

Jay: Czyli to już etap „wdrożenia”? Czy od budowy do runtime to już wdrożenie?

Santi: Tak, tu się to trochę zazębia. Budowa to start od szablonu; wdrożenie to infrastruktura. Kiedyś trzeba było mieć własny zespół DevOps do uruchamiania collatorów i zarządzania infrastrukturą – teraz na początku nie musisz się tym przejmować. Jeśli projekt się rozwinie i pojawią się środki, możesz zbudować własny zespół, a my pomożemy w migracji. Na początku wszystko robimy za ciebie.

Jay: Kto teraz to robi?

Santi: Obecnie robi to Parity. W przyszłości deweloperzy będą mogli wybrać dowolną chmurę, a nawet IBP (infrastructure provider), ale wymaga to czasu, więc na razie, by zapewnić jakość, korzystamy z własnej infrastruktury, ale docelowo będzie więcej opcji.

Wprowadziliśmy też pojęcie BDU (Basic Deployment Unit) – jeśli chcesz wdrożyć Rollup na sieci produkcyjnej, dostajesz standardową infrastrukturę: trzy węzły collator, z których jeden działa jako endpoint RPC, a do tego indexer.

Współpracujemy z Subscan, mają open source’owe rozwiązanie, które planujemy zintegrować z PDP. Dzięki temu masz nie tylko indexer, ale i block explorer – kiedyś zespoły musiały to budować samodzielnie, teraz dostajesz to w pakiecie. To świetne rozwiązanie.

Jay: Wow, brzmi świetnie. To jeszcze budowa?

Santi: To już wdrożenie.

Jay: Rozumiem, czyli na tym etapie Rollup już działa, produkuje bloki, zespół może robić aktualizacje runtime, testować i iterować, by znaleźć product-market fit? A potem zostaje ostatni etap – „dostęp (Access)”, tak? Co to jest?

Santi: Tak! Access to wyróżnik Polkadot – to właśnie tu Polkadot daje unikalną wartość zespołom Rollup. Budowa i wdrożenie – runtime i infrastruktura – są dość proste, ale prawdziwa przewaga Polkadot ujawnia się w Access. Na przykład Coretime – to część Access, PDP wcześniej kupuje Coretime, więc deweloper, wdrażając Rollup, może od razu zacząć produkować bloki, bez czekania 28 dni. To ogromna poprawa doświadczenia użytkownika.

Jay: Jeśli chcę wdrożyć, muszę sam kupić Coretime w PDP?

Santi: Kupujemy to za ciebie, a potem pobieramy opłatę. Oferujemy różne opcje Coretime. Jeśli chcesz od razu pełną moc, możesz wziąć cały rdzeń. Ale mamy też „sliced core” – część rdzenia. Jeśli chcesz tylko przetestować, nie wydawać dużo, możesz zacząć od małego kawałka rdzenia.

Jay: Ta funkcja już działa?

Santi: Już działa na PDP. Obecnie funkcjonuje na sieciach Westend i Paseo. Paseo właśnie uruchomiło sliced core, a na Westend możesz handlować częścią rdzenia – minusem jest dłuższy czas produkcji bloków, ale zaletą bardzo niski próg wejścia, możesz tanio przetestować. Jeśli wszystko działa, możesz przejść na pełny rdzeń i mieć bloki co sześć sekund – wszystko przez PDP. Nadal musimy rozwiązać kwestię efektywnego wykorzystania Polkadot. Polkadot Hub jako kluczowy moduł wkrótce zostanie uruchomiony i bardzo na to czekamy.