Polkadot Deployment Portal: Bakit pinipili ng mga proyekto na mag-deploy sa Polkadot imbes na maging isang L2?

Noong nakaraan, ang pag-deploy ng isang Rollup sa Polkadot ay hindi kailanman naging madaling gawain. Sapagkat habang mas flexible ang isang sistema, kadalasan ay mas kumplikado rin ang proseso ng deployment: mula sa pag-update ng SDK, sa slot auction, hanggang sa governance at runtime upgrade, bawat hakbang ay maaaring maging hamon para sa isang team.

Upang baguhin ang kalagayang ito, inilunsad ng Parity ngayong taon ang Polkadot Deployment Portal (PDP) — isang "one-stop entry" mula sa pagbuo, pag-deploy hanggang sa pag-access. Malinaw ang layunin nito: babaan ang hadlang, gawing simple ang proseso, at bigyang-daan ang anumang team na mabilis at matatag na makapagpatakbo ng sarili nilang Rollup sa Polkadot.

Sa artikulong ito, dadalhin tayo ni Santi Balaguer, ang pinuno ng product development ng Parity, sa isang pagbalik-tanaw sa ebolusyon ng deployment experience sa Polkadot nitong mga nakaraang taon, ipapaliwanag ang disenyo sa likod ng PDP, at ibabahagi kung paano unti-unting binabago ng tool na ito ang paraan ng paglulunsad ng Rollup.

Deployment Experience sa Polkadot: Mas Flexible, Mas Kumplikado

Jay: Maligayang pagdating sa Space Monkeys, ngayong araw ay inimbitahan natin si Santi Balaguer na responsable sa product development ng Parity. Pag-uusapan natin ngayon ang PDP, ano ang buong pangalan ng PDP?

Santi: Ito ay Polkadot Deployment Portal — Polkadot Deployment Portal.

Jay: Bago ka nagsimulang gumawa ng PDP, ano ang mga pangunahing responsibilidad mo sa Parity nitong apat o limang taon?

Santi: Palagi akong malapit sa developer community, pangunahing tumutulong sa kanila na maglunsad ng parachains at Rollups sa Polkadot. Tulad ng sinabi mo, nasa Parity na ako bago pa man nailunsad ang parachains.

Jay: Sa mga proyektong madalas mong nakakasalamuha, alin ang pamilyar kami?

Santi: Dati akong namamahala sa Substrate Builders project, na may maraming kilalang proyekto. Pinaka-natatandaan ko ang Hydration team. Naalala ko noong nag-demo si Jakub, ipinakilala niya ang ideya ng Omnipool at ang mga problemang nilulutas ng Hydration. Nagpakita siya ng isang klasikong meme na “money printer goes brrrr” para ipaliwanag kung bakit sila nagmungkahi ng bagong solusyon. Hanggang ngayon, madalas pa rin naming biruin iyon ni Jakub.

Jay: Haha, ang saya. Siguradong marami kang nakitang matagumpay na proyekto sa Polkadot, at narinig mo rin ang mga pain points nila. Maaari mo bang ibahagi kung ano ang pinakamalaking sakit ng ulo sa pag-deploy ng proyekto sa Polkadot nitong mga nakaraang taon?

Santi: Siyempre. Ang Polkadot mismo ay isang napaka-kumplikadong sistema, kailangan mo talagang maintindihan ito para gumana nang maayos ang proyekto. Ang complexity na ito ay galing sa flexibility nito — mas flexible ang sistema, mas kumplikado ito.

Noong unang panahon, para makapagpatakbo ng parachain sa Polkadot, kailangan mo munang harapin ang iba't ibang "breaking updates" ng SDK. Noon, wala pang Polkadot SDK, Substrate lang, at iba pa ito sa ngayon. Pagkatapos mong ayusin ang development environment, kailangan mo pang mangampanya sa komunidad, sumali sa slot auction. Ang auction mismo ay isang hamon, kailangan mo ng sapat na suporta, at malalaman mo lang ang resulta sa huling sandali. Kahit manalo ka, kailangan mong maghintay ng tatlong buwan bago tuluyang ma-online ang parachain. At ang slot ay nirentahan lang sa iyo ng dalawang taon. Kaya noon, kailangan mong magpursige sa parehong technical development at community mobilization para makakuha ng puwesto sa Polkadot.

Jay: Oo nga. Pero nitong mga nakaraang taon, gumanda na ang experience. Maaari mo bang ikuwento ang prosesong ito ng pagbabago?

Santi: Siyempre. Sa tingin ko, malaki ang naging effort ng Parity, lalo na sa pagbawas ng breaking updates ng Polkadot SDK.

Bagamat may updates pa rin ngayon, mas stable na kumpara dati, at mas compatible na ang mga versions. Ngayon, mas kampante na ang mga developer na umasa sa SDK version na gamit nila. May mga parachain pa ngang gumagamit pa ng lumang Substrate version, pero gumagana pa rin sa Polkadot.

Isa pa ay ang pagpasok ng Coretime (kahit may complexity din ito), pero talagang bumaba ang hadlang para sa mga developer. Mas madali na ngayong sumubok at mas mababa na ang barrier to entry sa Polkadot, kaya dapat nating samantalahin ito.

Bakit Dapat Mag-deploy ng Project sa Polkadot, Hindi sa Ethereum L2?

Jay: Kahit maraming hamon noon, marami na ang naresolba. Sa tingin mo, bakit ngayon pipili ang isang proyekto na mag-deploy sa Polkadot? Bakit hindi na lang sa Ethereum L2 o gumawa ng sariling L1? Ano ang dahilan?

Santi: Magandang tanong ito. Una, sa tingin ko, bilang komunidad, dapat pa tayong mag-promote at magpaliwanag tungkol dito. Sa personal kong pananaw, ang Polkadot lang ang blockchain na mula simula ay dinisenyo para natively mag-host ng Rollup. Nagbibigay ito ng maraming infrastructure na wala sa iba.

• Halimbawa, ang Polkadot ay may malaking data availability layer para sa Rollup, samantalang sa Ethereum L2, kailangan mong umasa sa external systems o "blob" para dito.

• Isa pa, ang native message passing sa pagitan ng parachains (cross-chain communication), na wala sa ibang Rollup. Ang kakulangan nito ay nagpapababa ng security ng system.

• Sa performance naman, napatunayan na ng Spamming na ang Rollup TPS ng Polkadot ay nangunguna sa buong industriya.

• At ang elastic scaling, Polkadot lang ang system na kayang mag-expand o mag-shrink ng infrastructure ayon sa demand. Halimbawa, kung biglang maglulunsad ng bagong laro ang Mythical at inaasahang tataas ng 10x ang users sa unang linggo, halos wala silang kailangang baguhin para suportahan ang traffic na iyon.

Sa tingin ko, sa mga nakaraang diskusyon tungkol sa "parachain at Rollup", hindi natin naipuwesto ang Polkadot bilang bida, kaya may na-miss tayong pagkakataon. Pero hindi pa huli ang lahat, may tsansa pa tayong ibalik ito sa sentro ng entablado.

Jay: Oo, nabanggit mo rin sa akin dati na ang Polkadot ay mula pa sa design ay para sa Rollup. Hindi lang natin ito tinawag na Rollup noon.

Santi: Tama, at isa pang madalas nating hindi napapansin ay ang shared security. Balikan natin ang kasaysayan ng blockchain: nagsimula sa Bitcoin, tapos nagkaroon ng Ethereum. Pagkatapos, nagsulputan ang iba't ibang "bagong Ethereum", ipinagmamalaki ang mga bagong features. Pero ang problema, napakahirap tiyakin ang seguridad ng isang bagong chain. Kailangan mo ng malaking validator set, at hindi ito madali.

Noon, naisip ni Gavin: bakit hindi gawing serbisyo ang security at i-integrate sa base layer? Dito natatangi ang Polkadot. Hindi lang ito nagbibigay ng shared security, kundi pati efficient communication sa pagitan ng mga Rollup — dito magaling ang Polkadot.

Paano Nabuo ang Ideya ng PDP?

Jay: Ang galing. Kung ang isang Rollup ay gustong magkaroon ng native data availability (at malakihan pa), hindi umaasa sa ibang proyekto, gusto ng mataas na TPS at throughput, at seamless na komunikasyon sa ibang Rollup, talagang attractive ang Polkadot. Pero bago lumabas ang PDP, napaka-komplikado at matagal pa rin mag-deploy ng parachain. Bakit nabuo ang ideya ng PDP?

Santi: Matagal nang nabubuo ang ideyang ito, kahit nagsimula lang kaming aktwal na gumawa noong Nobyembre ng nakaraang taon.

Mga Marso o Abril ngayong taon, full-time nang nagtatrabaho ang team sa proyektong ito, at mabilis ang progreso. Matagal nang may mga katulad na solusyon sa industriya. Halimbawa, sa Ethereum ecosystem may Conduit, Gelato; sa Polkadot naman dati ay may Tanssi, pero lumipat na rin sila sa Ethereum, pareho ang ideya.

Nakita naming walang gumagawa nito sa Polkadot, kaya kami na mismo ang kumilos para matiyak na magtatagumpay ito. Mas malalim ang aming kaalaman sa Polkadot, kaya alam naming paano gawing mas madali para sa mga developer ang pag-deploy ng proyekto — ito ang layunin ng PDP.

Hindi Kami Nagpapasya Para sa Developer, Nagbibigay Kami ng Gabay at Pagpipilian

Jay: Para kanino talaga ang PDP? Naalala ko, may problema noon sa Polkadot na may mga proyektong agad na gumagawa ng Rollup, pero sapat na sana kung smart contract lang. Sa tingin mo, anong klaseng proyekto ang talagang dapat may sariling Rollup?

Santi: Magandang tanong, pero sa tingin ko, walang iisang sagot. Hanggang ngayon, may mga proyektong mas okay sana kung contract lang. Pero minsan, kailangan ng team ng independence, ayaw nilang umasa sa ibang chain; minsan, inaasahan nilang lalaki nang husto ang throughput, kaya mas gusto nilang mag-Rollup agad, at iba pang dahilan para kailanganin nila ng sariling chain o mas mataas na independence sa infrastructure.

Halimbawa, ang Omnipool ng Hydration, puwede nating pagtalunan kung contract lang ba dapat ito, pero para sa akin, tama lang na chain ito. Sa kabilang banda, tingnan natin ang Uniswap ng Ethereum, nagsimula bilang contract, tapos gumawa ng sariling chain, pero kailangan ba talaga nila ng chain? Siguro hindi, pero may sarili silang business considerations.

Kaya walang absolute dito, kombinasyon ito ng teknikal at business na dahilan. Para sa akin, ang mahalaga: hindi kami ang magpapasya para sa developer, kundi magbibigay kami ng gabay at pagpipilian. Kung gusto nilang mag-Rollup o contract, dapat madali para sa kanila ang sumubok at mag-experiment.

Pagbubunyag ng Buong PDP Experience: Mula Build, Deploy Hanggang Access, Ganoon Kadali ang Rollup Launch

Jay: Sige, kung magpasya ang isang team — sariling desisyon man o may guidance mula Magenta Labs o BD team — na mag-deploy ng Rollup sa Polkadot, ano ang experience nila sa PDP? Ano ang proseso ng deployment ngayon?

Santi: Sa disenyo ng PDP, hinati namin ang proseso sa tatlong pangunahing yugto: Build (Pagbuo) — Deploy (Pag-deploy) — Access (Pag-access), magkakaugnay ang tatlong ito.

Sa "Build" stage, ang pangunahing tanong ay "Paano ako magsisimula". Sa tingin namin, ang pinakamainam ay sa pamamagitan ng runtime templates. Sa ngayon, ang OpenZeppelin ay gumagawa ng mga template, pati na rin ang Pop CLI team at ROG team. Ang Pop CLI ay isang tool na puwede mong gamitin sa iyong computer para gumawa ng Rollup. Nakipagtulungan kami sa kanila para i-integrate ito sa dalawang susunod na yugto ng PDP (deploy at access).

Halimbawa, matapos kang mag-build ng Rollup sa Pop CLI, puwede mo itong direktang i-connect sa PDP para i-deploy ang Rollup — ganito namin ito dinisenyo at ipinatupad. Sa ganitong paraan, puwedeng gamitin ng developer ang CLI para tapusin ang buong proseso, parang Heroku o Vercel sa Web2 na may sariling CLI. Kung sanay ka sa ganitong paraan, puwede kang mag-CLI; puwede rin namang gumamit ng graphical interface. Parehong puwede.

Jay: Ibig sabihin, bukod sa pag-build gamit ang template, puwede ring mag-build gamit ang Pop CLI, tapos mag-deploy. Tinutulungan ba ng PDP mismo ang developer na pumili, o tool lang ito na team ang bahala?

Santi: Pareho. Gusto naming maging self-service tool ang PDP para magamit ng developer. Pero kung may critical na problema, nandiyan kami para tumulong. Siyempre, kung gusto lang nilang subukan mag-isa, okay lang din haha.

Jay: Nakakatuwa. Puwede ka bang magbigay ng ilang template na paborito mo?

Santi: Halimbawa, may Pilot Revive template ang ROG team na puwede mong gamitin agad. Sa OpenZeppelin, may Frontier template para sa chain na may EVM functionality.

Jay: Astig, parang iba't ibang smart contract options.

Santi: Oo. May mga template din na walang smart contract. Halimbawa, kung gusto mo lang ng chain para sa asset custody, lalo na para sa real world asset (RWA) projects, may template din para diyan. Sa simula, maraming pagpipilian, tapos puwede mo pang i-expand.

Jay: Puwede bang magdagdag ng bagong Pallet sa template?

Santi: Sa simula, hindi pa. Ang design ay magsisimula ka sa template, tapos step-by-step naming igu-guide ka sa runtime upgrade. Gusto naming sa ganitong paraan, matulungan ang team na mahanap ang product-market fit. Interesting ang design na ito, at isa ito sa mga focus namin ngayon. Gumagamit kami ng tool mula sa Puppet team na kayang i-compare ang bagong runtime na i-upgrade mo at ang kasalukuyang deployed runtime, at mag-generate ng report kung ano ang nagbago, ano ang posibleng makaapekto sa developer, at ano ang dapat bantayan.

Jay: Oo, nakita ko nga na kakaintegrate n'yo lang nito, ang galing.

Santi: Oo, ngayong linggo lang natapos. Makakakuha ka ng runtime upgrade report para matiyak na tugma ang ipu-push mong content sa inaasahan mo. Gusto pa naming magdagdag ng feature: tulungan kang mag-simulate ng ilang blocks sa backend gamit ang bagong runtime. Kung okay lahat, sasabihin naming "puwede nang i-launch"; kung may problema, sasabihin naming "hindi pasado sa test, mas mabuting i-check mo ulit". Makakaiwas ito sa pagkakamali ng team sa upgrade. Isa sa mga advantage ng Polkadot ay ang flexible runtime upgrade, kaya puwedeng gamitin ito ng team para mabilis mag-iterate at mahanap ang product-market fit.

Jay: Sandali, bahagi na ba ito ng "deploy" stage? Ang pinag-usapan natin mula build hanggang runtime, kasama na ba ito sa deployment?

Santi: Oo, medyo nag-o-overlap. Ganito: ang build ay nagsisimula sa template; ang deploy ay tungkol sa underlying infrastructure. Dati, kailangan mo ng sariling DevOps team para mag-set up ng collator nodes at iba pang maintenance, pero sa simula, hindi mo na kailangang isipin ito. Kung lumaki ang proyekto at may pondo na, puwede kang magbuo ng sariling ops team, at tutulungan ka naming mag-migrate. Pero sa simula, kami ang bahala.

Jay: Sino ang gumagawa nito ngayon?

Santi: Sa ngayon, Parity ang nagpo-provide. Pero sa hinaharap, papayagan naming pumili ang developer kung saang cloud platform mag-deploy, o kahit IBP (infrastructure provider). Kailangan lang ng oras para i-abstract ang layer na ito, kaya ngayon, para sa magandang experience, Parity infrastructure muna ang gamit, pero bubuksan namin ito sa mas maraming pagpipilian.

May inilunsad din kaming konsepto na tinatawag na BDU (Basic Deployment Unit), basta gusto mong mag-deploy ng Rollup sa production network, magse-set up kami ng standardized infrastructure para sa iyo, kabilang ang tatlong collator nodes, isa rito ay puwedeng maging RPC endpoint, at bibigyan ka rin namin ng indexer.

Ngayon, nakikipagtulungan kami sa Subscan, may open-source solution sila na plano naming i-integrate sa PDP. Sa ganitong paraan, hindi lang indexer ang meron ka, kundi pati block explorer. Dati, kailangan ng team ng mahabang panahon para mag-set up nito, ngayon, kami na ang bahala — one-stop solution, maganda ang design.

Jay: Wow, ang ganda pakinggan. Bahagi ba ito ng build?

Santi: Ito ay deployment.

Jay: Gets, so sa puntong ito, tumatakbo na ang Rollup? Nagpo-produce na ng blocks? Puwede na ring mag-runtime upgrade ang team para mag-iterate at mahanap ang product-market fit? Ang susunod ay "Access", tama ba? Ano naman ito?

Santi: Tama! Ang Access ang highlight ng Polkadot, dito talaga nagkakaroon ng unique value para sa Rollup teams. Ang build at deploy, tungkol sa runtime at infrastructure, madaling matutunan ng lahat, pero ang tunay na gamit ng Polkadot ay dito lumalabas. Halimbawa, ang Coretime ay bahagi ng Access, at sa PDP, pre-purchase na namin ang Coretime, kaya kapag gusto ng developer na mag-deploy ng Rollup, agad na itong magagamit, hindi na kailangang maghintay ng 28 araw bago makapag-produce ng blocks — malaking improvement ito sa user experience.

Jay: Kung gusto kong mag-deploy, ako ba ang bibili ng Coretime sa PDP?

Santi: Kami ang bibili para sa iyo, tapos sisingilin ka namin. May iba't ibang pagpipilian para sa Coretime. Halimbawa, kung gusto mong mag-all in agad, puwede kang gumamit ng buong core. Pero may "sliced core" din kami, bahagi lang ng core, para kung gusto mo munang sumubok nang hindi gumagastos ng malaki, puwede kang gumamit ng maliit na bahagi lang.

Jay: Available na ba ang feature na ito?

Santi: Sa PDP, magagamit na ito. Tumakbo na ito sa Westend at Paseo network. Kamakailan lang inilunsad ang sliced core sa Paseo, at sa Westend, puwede kang mag-trade ng bahagi ng core, ang downside ay mas mahaba ang block time, pero malaking bawas sa hadlang — halos libre na ang pagsubok. Kung maganda ang resulta, puwede kang mag-upgrade sa buong core at makuha ang six-second block time, at lahat ng ito ay magagawa sa PDP. Pero kailangan pa ng mas magandang access mechanism para masulit ang Polkadot. Malapit nang ilunsad ang Polkadot Hub bilang mahalagang feature module, at excited kami dito.