Portal Deployment Polkadot: Mengapa proyek memilih untuk melakukan deployment di Polkadot, bukan menjadi L2?

Dulu, melakukan deployment Rollup di Polkadot bukanlah hal yang mudah. Karena semakin fleksibel suatu sistem, biasanya proses deployment-nya juga semakin kompleks: mulai dari update SDK, lelang slot, hingga tata kelola dan upgrade runtime, setiap tahap bisa menjadi tantangan bagi tim.

Untuk mengubah situasi ini, Parity tahun ini meluncurkan Polkadot Deployment Portal (PDP) — sebuah “one-stop portal” dari pembangunan, deployment hingga integrasi. Tujuannya sangat jelas: menurunkan ambang masuk, menyederhanakan proses, sehingga tim mana pun dapat dengan cepat dan stabil meluncurkan serta menjalankan Rollup mereka sendiri di Polkadot.

Pada artikel ini, Kepala Pengembangan Produk Parity, Santi Balaguer, akan membawa kita meninjau evolusi pengalaman deployment Polkadot selama beberapa tahun terakhir, mengupas filosofi desain di balik PDP, dan berbagi bagaimana alat ini secara bertahap mengubah cara peluncuran Rollup.

Pengalaman Deployment di Polkadot: Semakin Fleksibel Sistemnya, Semakin Kompleks

Jay: Selamat datang di Space Monkeys, hari ini kami mengundang Santi Balaguer dari Parity yang bertanggung jawab atas pengembangan produk. Hari ini kita akan membahas PDP, apa kepanjangan dari PDP?

Santi: Itu adalah Polkadot Deployment Portal — Portal Deployment Polkadot.

Jay: Sebelum mulai mengerjakan PDP, apa saja yang kamu tangani di Parity selama empat-lima tahun terakhir?

Santi: Selama ini saya selalu berhubungan erat dengan komunitas developer, terutama membantu mereka meluncurkan parachain dan Rollups di Polkadot. Seperti yang kamu bilang, saya sudah di Parity sejak sebelum parachain diluncurkan.

Jay: Dari beberapa proyek yang sering kamu tangani, mana saja yang cukup dikenal oleh kita?

Santi: Saya sebelumnya bertanggung jawab atas proyek Substrate Builders, di dalamnya ada banyak proyek yang sudah dikenal banyak orang. Yang paling berkesan adalah tim Hydration. Saya masih ingat saat Jakub melakukan demo, memperkenalkan ide Omnipool mereka dan masalah yang ingin diselesaikan Hydration. Dia menampilkan meme klasik “money printer goes brrrr” untuk menjelaskan mengapa mereka mengusulkan solusi baru. Sampai sekarang saya masih sering bercanda dengan Jakub soal itu.

Jay: Haha, keren sekali. Kamu pasti sudah melihat banyak proyek sukses di Polkadot, dan juga mendengar banyak keluhan mereka. Bisa ceritakan, apa saja yang paling bikin pusing saat melakukan deployment proyek di Polkadot beberapa tahun terakhir?

Santi: Tentu saja. Polkadot sendiri adalah sistem yang sangat kompleks, kamu harus benar-benar memahaminya agar proyek bisa berjalan lancar. Kompleksitas ini sebenarnya berasal dari fleksibilitasnya — semakin fleksibel sistem, biasanya juga semakin kompleks.

Pada awalnya, untuk menjalankan parachain di Polkadot, kamu harus menghadapi berbagai “update destruktif” pada SDK. Saat itu belum ada Polkadot SDK, hanya ada Substrate, dan itu berbeda dengan sekarang. Setelah mengatur lingkungan pengembangan, kamu juga harus menggalang dukungan komunitas untuk ikut lelang slot. Proses lelang sendiri cukup menantang, kamu butuh dukungan banyak orang, dan hasil lelang baru diketahui di detik terakhir. Bahkan jika menang, kamu masih harus menunggu tiga bulan sebelum parachain benar-benar online. Selain itu, slot hanya disewa selama dua tahun. Jadi saat itu, kamu harus berjuang keras di sisi teknis dan mobilisasi komunitas agar bisa mendapatkan tempat di Polkadot.

Jay: Benar juga. Tapi beberapa tahun terakhir, pengalamannya sudah jauh membaik. Bisa ceritakan proses perubahan itu?

Santi: Tentu. Saya rasa Parity sudah berusaha keras, terutama dalam mengurangi update destruktif pada Polkadot SDK.

Walaupun sekarang masih ada update, tapi jauh lebih stabil dibanding dulu, dan kompatibilitas antar versi juga jauh lebih baik. Sekarang developer bisa lebih percaya diri menggunakan versi SDK yang mereka pilih. Bahkan ada beberapa parachain yang masih memakai versi Substrate lama, tapi tetap bisa berjalan normal di Polkadot.

Selain itu, masuknya Coretime (meski juga cukup kompleks), benar-benar menurunkan ambang masuk bagi developer. Ini membuat orang lebih mudah mencoba, dan menurunkan barrier to entry ke Polkadot secara signifikan. Saya rasa kita harus memanfaatkan hal ini sebaik mungkin.

Mengapa Proyek Sekarang Memilih Deployment di Polkadot, Bukan di Ethereum L2?

Jay: Walaupun dulu banyak tantangan, sekarang sudah banyak yang teratasi. Menurutmu, kenapa hari ini sebuah proyek memilih deployment di Polkadot? Kenapa tidak di Ethereum L2, atau langsung membuat L1 sendiri? Apa alasannya?

Santi: Ini pertanyaan yang sangat menarik. Pertama, menurut saya, sebagai komunitas, kita harus lebih banyak berkomunikasi dan mempromosikan hal ini. Dari pemahaman dan sudut pandang saya, Polkadot adalah satu-satunya blockchain yang sejak awal didesain untuk secara native mendukung Rollup. Ia menyediakan infrastruktur yang tidak tersedia di tempat lain bagi developer.

• Misalnya, Polkadot menyediakan lapisan data availability yang sangat besar untuk Rollup, sedangkan di Ethereum L2, kamu harus mengandalkan sistem eksternal atau “blob” untuk menyelesaikannya.

• Contoh lain adalah native message passing antar parachain (komunikasi cross-chain), yang tidak ada di Rollup lain. Tanpa fitur ini, sistem akan berkurang keamanannya.

• Dari sisi performa, Spamming sudah membuktikan bahwa TPS Rollup di Polkadot sangat menonjol di industri ini.

• Juga soal elastic scaling, Polkadot saat ini adalah satu-satunya sistem yang bisa memperluas atau mengurangi infrastruktur sesuai kebutuhan. Misalnya, jika Mythical tiba-tiba meluncurkan game baru dan memperkirakan pengguna naik 10x di minggu pertama, mereka hampir tidak perlu mengubah apapun untuk langsung mendukung lonjakan traffic tersebut.

Saya rasa dalam diskusi kita sebelumnya soal “parachain dan Rollup”, kita belum berhasil menjadikan Polkadot sebagai tokoh utama, sehingga sedikit kehilangan momentum. Tapi sekarang masih ada waktu, kita masih punya kesempatan untuk mengembalikannya ke panggung utama.

Jay: Benar, kamu juga pernah bilang ke saya, Polkadot dari desain arsitektur dasarnya memang disiapkan untuk Rollup. Hanya saja dulu kita belum menyebutnya Rollup.

Santi: Betul, ada satu hal lagi yang sering kita abaikan, yaitu shared security. Kalau kita lihat sejarah perkembangan blockchain: awalnya ada Bitcoin, lalu Ethereum. Setelah itu, banyak orang mulai membuat “Ethereum baru” dan mengklaim “chain saya lebih baik karena punya fitur A, B, C”. Tapi masalahnya, menjamin keamanan chain baru itu sangat sulit. Kamu harus punya validator set yang cukup besar dan kuat, dan itu tidak mudah.

Saat itu Gavin berpikir: kenapa tidak menjadikan keamanan sebagai layanan, dibangun di layer dasar? Inilah keunikan Polkadot. Ia tidak hanya menyediakan shared security, tapi juga komunikasi efisien antar Rollup, dan ini adalah keahlian khusus Polkadot.

Bagaimana Ide PDP Muncul?

Jay: Keren sekali. Jika sebuah Rollup ingin data availability yang native (dan dalam skala besar), bukan mengandalkan proyek lain, juga ingin TPS dan throughput tinggi, serta bisa berkomunikasi seamless dengan Rollup lain, maka Polkadot memang sangat menarik. Tapi sebelum ada PDP, deployment parachain tetap sangat kompleks dan memakan waktu. Lalu kenapa awalnya muncul ide membuat PDP?

Santi: Sebenarnya ide ini sudah lama dipikirkan, meski kami baru benar-benar mulai mengerjakannya pada November tahun lalu.

Lalu tim kami sejak sekitar Maret atau April tahun ini mulai fokus penuh pada proyek ini, dan sekarang progresnya sangat cepat, semua orang sedang mewujudkan ide ini langkah demi langkah. Ide ini sudah lama dipikirkan, dan di industri juga sudah ada beberapa solusi serupa. Misalnya di ekosistem Ethereum ada Conduit, Gelato; di Polkadot dulu juga ada Tanssi, tapi sekarang mereka lebih fokus ke Ethereum, konsepnya mirip.

Kami melihat di Polkadot belum ada yang benar-benar berhasil, jadi kami memutuskan untuk turun tangan sendiri, memastikan ini bisa terwujud. Karena kami lebih memahami Polkadot, dan tahu bagaimana membuat deployment proyek jadi lebih mudah bagi developer, inilah tujuan PDP.

Kami Tidak Membuat Keputusan untuk Developer, Tapi Memberikan Panduan dan Pilihan

Jay: Jadi, siapa sebenarnya target PDP? Saya ingat dulu di Polkadot ada masalah, beberapa proyek langsung membuat Rollup, padahal cukup dengan smart contract saja. Menurutmu, proyek seperti apa yang benar-benar cocok punya Rollup sendiri?

Santi: Ini pertanyaan bagus, tapi menurut saya tidak ada jawaban pasti. Sampai sekarang kami masih menemukan beberapa proyek yang sebenarnya cukup jadi kontrak saja. Tapi kadang tim proyek butuh independensi, mereka tidak ingin bergantung pada infrastruktur chain lain; kadang mereka memperkirakan throughput di masa depan akan sangat besar, jadi lebih memilih Rollup sejak awal, dan alasan lain yang membuat mereka butuh chain sendiri atau independensi lebih tinggi di infrastruktur.

Contohnya Omnipool dari Hydration, kita bisa berdebat apakah cukup jadi kontrak, tapi menurut saya tidak, membuatnya jadi chain adalah keputusan yang masuk akal. Di sisi lain, lihat Uniswap di Ethereum, awalnya hanya kontrak, lalu membuat chain sendiri, tapi apakah mereka benar-benar butuh chain? Mungkin tidak, tapi mereka punya pertimbangan bisnis sendiri.

Jadi ini tidak mutlak, lebih merupakan hasil dari kombinasi teknis dan bisnis. Bagi saya, yang terpenting adalah: kami tidak membuat keputusan untuk developer, kami memberikan panduan agar mereka bisa memilih sendiri. Apapun pilihan mereka, Rollup atau kontrak, harus bisa dicoba dan dieksperimen dengan mudah.

Mengungkap Pengalaman Lengkap PDP: Dari Build, Deploy hingga Access, Peluncuran Rollup Jadi Sangat Mudah

Jay: Oke, misalkan sebuah tim sudah memutuskan, baik keputusan sendiri atau dibantu Magenta Labs atau tim BD. Akhirnya mereka memutuskan untuk deployment rollup di Polkadot. Setelah masuk ke PDP, pengalaman apa yang akan mereka dapatkan? Bagaimana alur deployment sekarang?

Santi: Dalam desain PDP, kami membagi proses menjadi tiga tahap utama: Build (membangun) — Deploy (deployment) — Access (akses), ketiganya saling terkait.

Pada tahap “Build”, inti masalahnya adalah “bagaimana saya memulai”. Ide kami: cara terbaik adalah melalui runtime templates. Saat ini OpenZeppelin sedang mengembangkan template terkait, tim Pop CLI dan ROG juga mengerjakan hal serupa. Pop CLI pada dasarnya adalah alat yang bisa kamu gunakan di komputer sendiri untuk menulis Rollup. Kami bekerja sama dengan mereka, menghubungkan Pop CLI dengan dua tahap lain PDP (deployment dan akses).

Misalnya, setelah kamu membangun Rollup di Pop CLI, kamu bisa langsung menghubungkannya ke PDP untuk deployment, dan memang seperti itulah desain dan implementasinya. Dengan begitu, developer bisa menjalani seluruh proses lewat CLI, seperti Heroku atau Vercel di Web2 yang juga punya CLI sendiri. Kalau kamu terbiasa dengan cara ini, bisa langsung pakai CLI; tentu saja, kamu juga bisa lewat antarmuka grafis. Keduanya bisa.

Jay: Jadi, selain membangun dengan template, bisa juga pakai Pop CLI, lalu deployment. Apakah PDP akan membantu developer membuat beberapa pilihan? Atau hanya alat, dan lebih banyak tergantung tim sendiri?

Santi: Keduanya. Kami ingin PDP jadi alat mandiri, developer bisa menggunakannya sendiri. Tapi jika ada masalah penting, tentu kami akan mendukung, memastikan mereka mendapat bantuan yang dibutuhkan. Tapi kalau ada yang ingin coba sendiri, juga tidak masalah haha.

Jay: Menarik juga. Bisa kasih contoh template yang kamu suka?

Santi: Misalnya, tim ROG punya template Pilot Revive yang siap pakai untuk memulai. OpenZeppelin punya template Frontier, kalau kamu ingin chain dengan fitur EVM, bisa langsung pakai itu.

Jay: Keren, jadi ada beberapa pilihan terkait smart contract.

Santi: Betul. Ada juga template tanpa smart contract. Misalnya ada yang hanya ingin chain untuk custodial asset, terutama proyek terkait real world asset (RWA), juga ada template-nya. Intinya, pada tahap awal sudah ada banyak opsi, lalu bisa dikembangkan lebih lanjut.

Jay: Apakah template bisa ditambah Pallet baru sesuai kebutuhan?

Santi: Awalnya tidak bisa. Desainnya adalah kamu mulai dari template, lalu kami akan membimbing kamu melakukan upgrade runtime secara bertahap. Kami ingin dengan cara ini, tim bisa menemukan product market fit secara bertahap. Desain ini cukup menarik, dan saat ini jadi salah satu fitur utama yang kami kembangkan. Sekarang kami memakai alat dari tim Puppet yang sangat menarik, alat ini bisa membandingkan runtime yang akan kamu upgrade dengan runtime yang sudah dideploy, lalu menghasilkan laporan tentang apa saja yang berubah, apa yang bisa mempengaruhi developer, dan apa yang perlu diperhatikan.

Jay: Benar, saya lihat kalian baru saja mengintegrasikan ini, keren banget.

Santi: Ya, baru selesai minggu ini. Jadi kamu akan mendapat laporan upgrade runtime, memastikan konten yang akan kamu push sesuai dengan ekspektasi. Selanjutnya kami ingin menambah fitur: membantu kamu mensimulasikan beberapa blok di backend untuk menguji runtime baru. Jika semuanya normal, kami akan memberi tahu “bisa online”; jika ada masalah, kami akan bilang “tes kami gagal, sebaiknya cek lagi”. Ini bisa mencegah tim melakukan kesalahan saat upgrade. Kami percaya salah satu keunggulan Polkadot adalah mendukung upgrade runtime yang fleksibel, tim bisa memanfaatkannya untuk iterasi cepat dan menemukan product market fit.

Jay: Tunggu, jadi bagian ini sudah masuk tahap “deployment”? Tadi kita bicara dari build ke runtime, apakah ini sudah deployment?

Santi: Ya, di sini memang ada irisan. Bisa dibilang: build lebih ke mulai dari template; deployment terkait infrastruktur dasar. Dulu kamu butuh tim DevOps sendiri untuk membangun node collator dan berbagai urusan operasional, sekarang saat baru mulai, semua itu tidak perlu dipikirkan. Jika proyek berkembang baik dan punya dana serta sumber daya, kamu bisa membentuk tim operasional sendiri, dan kami bisa membantu migrasi. Tapi di awal, semua itu kami yang urus.

Jay: Sekarang siapa yang mengurus semua ini?

Santi: Saat ini Parity yang menyediakan. Tapi ke depan kami akan membiarkan developer memilih sendiri ingin deployment di cloud mana, bahkan mungkin IBP (infrastructure provider), hanya saja membuat lapisan abstraksi ini butuh waktu, jadi sekarang demi memastikan pengalaman, kami pakai infrastruktur Parity sendiri, tapi nantinya akan dibuka lebih banyak pilihan.

Kami juga memperkenalkan konsep BDU (Basic Deployment Unit), selama kamu ingin deployment Rollup di jaringan produksi, kami akan menyediakan satu set infrastruktur standar, termasuk tiga node collator, salah satunya bisa jadi endpoint RPC untukmu, dan kami juga akan menyediakan indexer.

Sekarang kami bekerja sama dengan Subscan, mereka punya solusi open source, dan kami berencana mengintegrasikannya ke PDP. Jadi kamu tidak hanya punya indexer, tapi juga block explorer, yang dulu butuh waktu lama untuk dibangun oleh tim, sekarang kami sediakan secara one-stop, desain ini sangat bagus.

Jay: Wah, keren banget. Apakah ini bagian dari build?

Santi: Ini deployment.

Jay: Paham, jadi sampai tahap ini Rollup sudah berjalan? Sudah mulai memproduksi blok? Tim juga bisa melakukan upgrade runtime untuk terus bereksperimen dan menemukan product market fit? Selanjutnya adalah tahap terakhir “Access”, benar? Apa itu?

Santi: Benar! Access adalah keunggulan Polkadot, menurut saya inilah nilai unik yang bisa diberikan Polkadot untuk tim Rollup. Build dan deployment itu soal runtime dan infrastruktur, semua orang bisa cepat belajar, tapi memanfaatkan fitur Polkadot secara penuh, di sinilah perbedaannya. Misalnya Coretime, itu bagian dari Access, PDP akan membeli Coretime terlebih dahulu, sehingga begitu developer ingin deployment Rollup, bisa langsung digunakan, tidak perlu menunggu 28 hari untuk mulai memproduksi blok, ini peningkatan besar untuk pengalaman pengguna.

Jay: Kalau saya ingin deployment, apakah harus beli Coretime sendiri di PDP?

Santi: Kami akan membelikan untukmu, lalu menagih biayanya. Sebenarnya, kami menyediakan beberapa pilihan Coretime. Misalnya kamu ingin langsung all-out, bisa pakai satu core penuh. Tapi kami juga menyediakan “core slice”, yaitu sebagian core, misalnya kamu ingin coba dulu tanpa keluar banyak biaya, ingin lihat hasilnya, bisa pakai sebagian kecil core saja.

Jay: Fitur ini sudah bisa digunakan?

Santi: Sudah bisa di PDP. Saat ini sudah berjalan di jaringan Westend dan Paseo. Paseo baru saja meluncurkan core slice, sedangkan di Westend kamu bisa langsung trading sebagian core, kekurangannya waktu produksi blok jadi lebih lama, tapi keuntungannya ambang masuk jauh lebih rendah, kamu bisa mencoba dengan biaya sangat kecil. Jika hasilnya bagus, kamu bisa upgrade ke core penuh, menikmati kecepatan blok enam detik, dan semua ini bisa dilakukan di PDP. Namun, mekanisme akses masih perlu solusi agar bisa memanfaatkan Polkadot secara efektif. Saat ini Polkadot Hub sebagai modul fungsional penting akan segera diluncurkan, kami sangat menantikan hal ini.