Портал розгортання Polkadot: чому проєкти обирають розгортання на Polkadot, а не стають L2?

У минулому розгортання Rollup на Polkadot ніколи не було легкою справою. Адже чим гнучкіша система, тим складніший процес розгортання: від оновлення SDK, до аукціону слотів, а потім — до управління та оновлення runtime, кожен етап міг стати викликом для команди.

Щоб змінити цю ситуацію, Parity цього року запустила Polkadot Deployment Portal (PDP) — «єдине вікно» для всього процесу: від створення, розгортання до підключення. Його мета дуже чітка: знизити поріг входу, спростити процеси, щоб будь-яка команда могла швидко й стабільно запустити та керувати власним Rollup на Polkadot.

У цій статті керівник розробки продукту Parity Санті Балагер розповість про еволюцію досвіду розгортання на Polkadot за останні роки, пояснить ідеї, що стоять за PDP, і поділиться, як цей інструмент крок за кроком змінює спосіб запуску Rollup.

Досвід розгортання на Polkadot: чим гнучкіша система, тим вона складніша

Jay: Ласкаво просимо до Space Monkeys, сьогодні з нами Санті Балагер, керівник розробки продукту в Parity. Сьогодні ми поговоримо про PDP, повна назва PDP — це?

Santi: Це Polkadot Deployment Portal — портал розгортання Polkadot.

Jay: До того, як ви почали працювати над PDP, чим ти займався у Parity останні чотири-п’ять років?

Santi: Я завжди був у тісному контакті зі спільнотою розробників, головно допомагав їм запускати парачейни та Rollups на Polkadot. Як ти казав, я був у Parity ще до запуску парачейнів.

Jay: Які з проектів, з якими ти часто працював, нам знайомі?

Santi: Я раніше відповідав за проєкт Substrate Builders, там багато відомих проектів. Найбільше запам’ятався колектив Hydration. Пам’ятаю, як Jakub під час демонстрації розповідав про ідею Omnipool і проблеми, які Hydration хоче вирішити. Він показав класичний мем “money printer goes brrrr” (друкарський верстат шалено працює), щоб пояснити, чому вони пропонують нове рішення. Я досі часто жартую з Jakub про це.

Jay: Ха-ха, чудово. Ти, напевно, бачив багато проектів, які успішно запустилися на Polkadot, і чув про їхні болючі точки. Можеш розповісти, що було найскладнішим у розгортанні проектів на Polkadot за останні роки?

Santi: Звісно. Polkadot — це дуже складна система, її треба справді розуміти, щоб проект працював добре. Ця складність походить від гнучкості — чим гнучкіша система, тим вона складніша.

На початку, щоб запустити парачейн на Polkadot, спочатку треба було впоратися з різними «руйнівними оновленнями» SDK. Тоді ще не було Polkadot SDK, був лише Substrate, і це було зовсім інакше, ніж зараз. Коли ти налаштував середовище розробки, треба було йти до спільноти, залучати голоси, брати участь в аукціоні слотів. Сам аукціон був складним: потрібно було багато підтримки, а результат ставав відомий лише в останню мить. Навіть якщо ти виграв, доводилося чекати три місяці, поки парачейн реально запуститься. І слот давався лише на два роки. Тож тоді треба було одночасно повністю викладатися і в технічній розробці, і в роботі зі спільнотою, щоб отримати місце на Polkadot.

Jay: Так. Але за останні роки досвід значно покращився. Можеш розповісти про ці зміни?

Santi: Звісно. Я вважаю, що Parity доклала багато зусиль, особливо щодо зменшення руйнівних оновлень Polkadot SDK.

Хоча оновлення все ще бувають, але зараз усе набагато стабільніше, і сумісність між версіями значно краща. Тепер розробники можуть спокійніше покладатися на свою версію SDK. Деякі парачейни досі працюють на старих версіях Substrate, але все одно нормально функціонують на Polkadot.

Ще важливою стала поява Coretime (хоча вона теж має певну складність), але це справді знизило поріг для розробників. Це дозволило багатьом легше спробувати, значно знизило бар’єр входу в Polkadot, і я вважаю, що ми маємо максимально це використовувати.

Чому зараз проекти обирають розгортання на Polkadot, а не створюють L2 на Ethereum?

Jay: Хоча тоді було багато викликів, зараз багато з них вирішено. Як ти вважаєш, чому сьогодні проект обирає розгортання на Polkadot? Чому не піти на Ethereum і не зробити L2, або не запустити власний L1? Які причини?

Santi: Це дуже цікаве питання. Я вважаю, що як спільнота, ми маємо більше комунікувати й розповідати про це. На мою думку, Polkadot — це наразі єдиний блокчейн, який з самого початку був спроєктований для нативної підтримки Rollup. Він дає розробникам інфраструктуру, якої немає в інших місцях.

• Наприклад, Polkadot надає Rollup дуже потужний шар доступності даних (data availability), а якщо ти на L2 Ethereum, то доводиться покладатися на зовнішні системи чи «blob» для цього.

• Ще приклад — нативна передача повідомлень між парачейнами (кросчейн-комунікація), чого немає в інших Rollup. Відсутність цієї функції знижує безпеку системи.

• Щодо продуктивності, Spamming вже довів, що TPS Rollup на Polkadot — одні з найкращих у галузі.

• Ще одна перевага — еластичне масштабування. Polkadot — це наразі єдина система, яка може розширювати або скорочувати інфраструктуру за потребою. Наприклад, якщо Mythical раптом запускає нову гру і очікує 10-кратне зростання користувачів у перший тиждень, їм майже нічого не треба змінювати, щоб одразу підтримати цей трафік.

Я вважаю, що в минулих дискусіях про «парачейни та Rollup» ми не змогли зробити Polkadot головним героєм і трохи втратили можливість. Але ще не пізно, у нас є шанс повернути його в центр уваги.

Jay: Так, ти раніше казав мені, що Polkadot ще на рівні архітектури був створений для Rollup. Просто спочатку ми не називали це Rollup.

Santi: Саме так, і ще одна річ, яку ми часто ігноруємо — це спільна безпека. Якщо подивитися на історію блокчейнів: спочатку був bitcoin, потім з’явився Ethereum. Потім усі почали запускати свої «нові Ethereum», рекламуючи, що «мій ланцюг кращий, бо має A, B, C властивості». Але проблема в тому, що забезпечити безпеку нового ланцюга дуже складно. Потрібно мати достатньо велику й сильну групу валідаторів, а це непросто.

Тоді Gavin подумав: чому б не зробити безпеку як сервіс, вбудувати її в базовий рівень? Ось у чому унікальність Polkadot. Він не лише забезпечує спільну безпеку, а й дозволяє ефективно комунікувати між Rollup — це сильна сторона Polkadot.

Як виникла ідея PDP?

Jay: Чудово. Якщо Rollup хоче мати нативну доступність даних (і ще й у великому масштабі), не покладаючись на інші проекти, хоче мати високу TPS і пропускну здатність, а також безшовно комунікувати з іншими Rollup, то Polkadot справді дуже привабливий. Але до появи PDP розгортання парачейну було дуже складним і тривалим. Чому виникла ідея створити PDP?

Santi: Насправді ця ідея визрівала певний час, хоча реально ми почали працювати над нею минулого листопада.

Потім наша команда з березня-квітня цього року повністю зосередилася на цьому проєкті, зараз прогрес дуже швидкий, ідея поступово стає реальністю. Це питання давно назріло, і в галузі вже є схожі рішення. Наприклад, в екосистемі Ethereum є Conduit, Gelato; у Polkadot раніше був Tanssi, але потім вони теж перейшли на Ethereum, ідея схожа.

Ми побачили, що на Polkadot це досі не реалізовано, тож вирішили взятися самі, щоб це сталося. Адже ми краще розуміємо Polkadot і знаємо, як зробити розгортання проектів для розробників простішим — це і є мета PDP.

Ми не приймаємо рішення за розробників, а даємо їм орієнтири та вибір

Jay: На кого орієнтований PDP? Я пам’ятаю, що на ранньому етапі Polkadot була проблема: деякі проекти одразу робили Rollup, хоча їм вистачило б і смарт-контракту. Як ти вважаєш, які проекти справді потребують власного Rollup?

Santi: Це гарне питання, але я не думаю, що є однозначна відповідь. Досі трапляються проекти, для яких і контракт був би достатнім. Але іноді команда хоче незалежності, не хоче залежати від інфраструктури інших ланцюгів; іноді вони очікують дуже великого навантаження в майбутньому, тому одразу обирають Rollup — такі причини змушують їх мати власний ланцюг або більшу незалежність в інфраструктурі.

Наприклад, Omnipool від Hydration — можна сперечатися, чи міг би це бути просто контракт, але я вважаю, що ні, окрема ланцюг — це логічно. З іншого боку, подивіться на Uniswap на Ethereum: спочатку це був контракт, а потім вони зробили власний ланцюг, але чи справді їм потрібен ланцюг? Можливо, ні, але у них свої бізнес-міркування.

Тож тут немає абсолюту, це завжди поєднання технічних і бізнесових причин. Для мене головне: ми не повинні приймати рішення за розробників, ми маємо дати їм орієнтири, щоб вони самі обирали. І незалежно від того, чи хочуть вони Rollup чи контракт, вони мають мати змогу легко спробувати й поекспериментувати.

Весь досвід PDP: від створення, розгортання до доступу — запуск Rollup став таким простим

Jay: Добре, припустимо, команда прийняла рішення — чи самостійно, чи за допомогою Magenta Labs або BD-команди. Врешті вони вирішили розгорнути rollup на Polkadot. Який досвід чекає їх у PDP? Який зараз процес розгортання?

Santi: У PDP ми розділили процес на три основні етапи: Build (створення) — Deploy (розгортання) — Access (доступ), і ці три частини взаємопов’язані.

На етапі «створення» головне питання — «з чого почати». Ми вважаємо, що найкращий спосіб — це runtime templates (шаблони виконання). Зараз OpenZeppelin розробляє відповідні шаблони, Pop CLI та ROG команди також працюють у цьому напрямку. Pop CLI — це інструмент, який можна використовувати на своєму комп’ютері для написання Rollup. Ми співпрацюємо з ними, щоб інтегрувати його з двома іншими етапами PDP (розгортання і доступ).

Наприклад, якщо ти створив Rollup у Pop CLI, можна напряму підключитися до PDP і розгорнути Rollup — саме так ми це й реалізували. Тепер розробник може пройти весь процес через CLI, як у Web2 на Heroku чи Vercel, у яких теж є свої CLI. Якщо тобі зручно так, користуйся CLI; або можеш працювати через графічний інтерфейс. Обидва варіанти доступні.

Jay: Тобто, окрім створення через шаблони, можна ще й через Pop CLI, а потім розгорнути. Чи PDP сам допомагає розробникам робити вибір, чи це просто інструмент, і все залежить від команди?

Santi: І те, і те. Ми хочемо, щоб PDP був самообслуговуючим інструментом, щоб розробники самі ним користувалися. Але якщо виникнуть критичні питання, ми, звісно, підтримаємо й допоможемо. Але якщо хтось хоче спробувати сам — теж без проблем, ха-ха.

Jay: Цікаво. Можеш навести приклади шаблонів, які тобі подобаються?

Santi: Наприклад, у ROG є готовий шаблон Pilot Revive, його можна одразу використати для запуску. У OpenZeppelin є шаблон Frontier — якщо хочеш запустити ланцюг з EVM-функціоналом, можеш використати його.

Jay: Круто, тобто це кілька варіантів, пов’язаних зі смарт-контрактами.

Santi: Саме так. Є й шаблони без смарт-контрактів. Наприклад, якщо хтось хоче зробити ланцюг лише для зберігання активів, особливо для проектів, пов’язаних із реальними активами (RWA), для цього теж є шаблони. Загалом, на старті буде багато варіантів, а далі можна розширювати функціонал.

Jay: Чи можна додати нові Pallet до шаблону за потреби?

Santi: Спочатку — ні. Ідея така: ти стартуєш із шаблону, а далі ми крок за кроком ведемо тебе до оновлення runtime. Ми хочемо, щоб команда поступово знаходила product-market fit. Це дуже цікава ідея, і зараз ми активно працюємо над цим функціоналом. Зараз ми використовуємо дуже цікавий інструмент від Puppet-команди, який порівнює твій майбутній runtime з уже розгорнутим, створює звіт про зміни, що може вплинути на розробників і на що слід звернути увагу.

Jay: Так-так-так, я бачив, що ви щойно це інтегрували, чудово.

Santi: Так, ми завершили це цього тижня. Тепер ти отримуєш звіт про оновлення runtime, щоб переконатися, що все відповідає очікуванням. Далі ми хочемо додати функцію: симулювати кілька блоків у бекграунді з новим runtime. Якщо все добре — повідомляємо, що можна запускати; якщо є проблеми — кажемо, що тест не пройдено, краще перевірити ще раз. Це допоможе уникнути помилок під час оновлення. Ми вважаємо, що одна з переваг Polkadot — це підтримка гнучких оновлень runtime, і команди можуть швидко ітеративно шукати product-market fit.

Jay: Зачекай, це вже етап «розгортання»? Те, що ми щойно обговорювали — від створення до runtime — це вже розгортання?

Santi: Так, тут є певне перетинання. Можна сказати так: створення — це старт із шаблону; розгортання — це вже інфраструктура. Раніше треба було мати власну DevOps-команду для налаштування collator-нод, обслуговування тощо, а тепер на старті про це не треба думати. Якщо проект розвивається, з’являються ресурси — можна створити свою команду, і ми допоможемо з міграцією. Але на початку ми все це беремо на себе.

Jay: Хто зараз цим займається?

Santi: Зараз це забезпечує Parity. Але в майбутньому розробники зможуть самі обирати, на якій хмарній платформі розгортати, можливо навіть IBP (інфраструктурний провайдер), але абстрагування цього шару потребує часу, тому зараз для кращого досвіду ми використовуємо власну інфраструктуру Parity, але згодом буде більше вибору.

Ми також запровадили концепцію BDU (Basic Deployment Unit, базова одиниця розгортання): якщо ти розгортаєш Rollup у продакшн-мережі, ми надаємо стандартну інфраструктуру — три collator-ноди, одна з яких може бути RPC-ендпоінтом, а також індексатор.

Зараз ми співпрацюємо з Subscan, у них є open-source рішення, яке ми плануємо інтегрувати в PDP. Тепер у тебе буде не лише індексатор, а й блок-експлорер — раніше на це йшло багато часу, а тепер усе в одному місці, це дуже зручно.

Jay: Вау, звучить чудово. Це ще етап створення?

Santi: Це вже розгортання.

Jay: Зрозуміло, тобто на цьому етапі Rollup вже працює? Починає виробляти блоки? Команда може робити оновлення runtime, щоб експериментувати й шукати product-market fit? А далі останній крок — «доступ (Access)», так? Що це таке?

Santi: Так! Access — це родзинка Polkadot, саме тут Polkadot дає Rollup-командам унікальну цінність. Створення й розгортання — це runtime та інфраструктура, це можна швидко освоїти, але справжня відмінність — у використанні особливостей Polkadot. Наприклад, Coretime — це частина Access, PDP заздалегідь купує Coretime, тож як тільки розробник хоче розгорнути Rollup, він може одразу почати, не чекаючи 28 днів на старт виробництва блоків — це величезне покращення для користувачів.

Jay: Якщо я хочу розгорнути, мені треба самому купувати Coretime у PDP?

Santi: Ми купуємо для тебе, а потім виставляємо рахунок. Насправді ми пропонуємо різні варіанти Coretime. Якщо хочеш одразу на повну — бери повний core. Але є й «sliced core» — частина core, якщо хочеш спочатку спробувати, не витрачати багато грошей, подивитися на результат — можна взяти лише частину core.

Jay: Ця функція вже доступна?

Santi: У PDP вже можна користуватися. Зараз працює на мережах Westend і Paseo. Paseo нещодавно запустив sliced core, а на Westend можна напряму торгувати частиною core — мінус у тому, що час виробництва блоків буде довшим, але поріг входу дуже низький, можна майже безкоштовно спробувати. Якщо все добре, можна перейти на повний core і мати шість секунд на блок — усе це можна зробити через PDP. Але механізм підключення ще потребує вирішення питання ефективного використання Polkadot. Polkadot Hub як важливий функціональний модуль скоро буде запущено, ми з нетерпінням цього чекаємо.