Цей маршрут — практична послідовність кроків для того, щоб перейти від базового розуміння блокчейну до самостійної розробки та розгортання програм на Solana. Solana.org.ua — незалежний український освітній хаб і не є офіційним представництвом Solana Foundation. Усі матеріали формуються на основі відкритої документації та досвіду розробників-практиків.

Передумови та цільова аудиторія

Маршрут розрахований на людей із базовою технічною підготовкою, які готові системно опановувати розробку на Solana. Це не вступний огляд для новачків без жодного досвіду програмування.

Обовʼязкові передумови:

  • впевнене володіння хоча б однією мовою програмування (бажано — зрозумілі основи типізації, функцій, структур даних);
  • базове розуміння того, як працює блокчейн загалом: транзакції, блоки, консенсус, гаманці, підписи;
  • вміння працювати в командному рядку (терміналі): навігація по директоріях, запуск команд, змінні середовища;
  • встановлене середовище: Node.js (перевірте актуальну версію на офіційному сайті), Git, редактор коду.

Цільова аудиторія:

  • бекенд-розробники, які хочуть додати блокчейн-навички до свого стеку;
  • фронтенд-розробники, що вже інтегрували Web3-гаманці і готові писати серверну логіку на ланцюжку;
  • DevOps-інженери, яким потрібне глибоке розуміння архітектури для розгортання та інфраструктури;
  • студенти старших курсів з міцною базою програмування.

Типова помилка на цьому етапі: намагатися одразу писати смарт-контракти без розуміння моделі акаунтів Solana. Це призводить до фрустрації, бо архітектура суттєво відрізняється від EVM-мереж.

Етап 1 — основи розробки на Solana

Мета етапу — зрозуміти архітектурні принципи Solana, які визначають усе подальше написання коду. Без цього етапу будь-який фреймворк буде чорною скринькою.

Що треба опанувати:

  • Модель акаунтів. У Solana акаунт — це не гаманець, а одиниця зберігання даних із власником, балансом SOL для оренди простору (rent-exempt) та даними. Розуміння цього різнобічного поняття — фундамент.
  • Транзакції та інструкції. Транзакція містить одну чи кілька інструкцій. Кожна інструкція вказує, яка програма виконується, які акаунти передаються та які дані містяться.
  • Підписання та авторизація. Різниця між signer та writable акаунтом. Чому неправильна розмітка призводить до помилок під час виконання.
  • Рuntime та BPF. Solana виконує скомпільований код у форматі Berkeley Packet Filter — це означає специфічні обмеження на розмір програми та доступну памʼять.
  • Робота з CLI. Встановлення та базові команди Solana CLI: створення ключів, запит балансу, розгортання локального кластеру (localnet).

Практичний крок: розгорнути локальний кластер (localnet) на своїй машині, створити пару ключів, переказати SOL між акаунтами через CLI, переглянути транзакцію в експлорері локальної мережі.

Середовище для практики: локальний кластер через solana-test-validator — це безпечне ізольоване середовище. Не використовуйте mainnet для навчальних експериментів.

Перевірка результату: ви можете пояснити, чому транзакція з трьома інструкціями коштує більше, ніж з однією, і де саме в структурі транзакції знаходяться підписи.

Етап 2 — смарт-контракти, програми та Anchor

У термінології Solana те, що в інших мережах називають смарт-контрактом, є програмою — скомпільованим байт-кодом, який виконується на ланцюжку. Anchor — це фреймворк, який спрощує розробку, додаючи перевірки безпеки, серіалізацію та структурування коду.

Що треба опанувати:

  • Rust для Solana. Базовий синтаксис Rust: власність (ownership), посилання (references), обробка помилок через Result, макроси. Не потрібно знати весь Rust — але без розуміння borrow checker писати на Solana буде неможливо.
  • Структура Anchor-проєкту. Каталоги programs/, tests/, migrations/. Файл Cargo.toml, конфігурація Anchor.toml.
  • Акаунти в Anchor. Макрос #[account], автоматична серіалізація та десеріалізація, перевірка власника програми, обмеження розміру.
  • Інструкції в Anchor. Макрос #[instruction], контекст виконання, валідація акаунтів через constraints.
  • PDA (Program Derived Address). Детерміновані адреси, які генеруються програмою і не мають відповідного приватного ключа. PDA — основний механізм для зберігання стану програми.
  • CPI (Cross-Program Invocation). Як одна програма викликає іншу. Передача акаунтів між програмами, підписання від імені PDA через invoke_signed.

Практичний крок: написати Anchor-програму, яка створює акаунт з даними (наприклад, запис нотатки з автором та текстом), зчитує ці дані та оновлює їх. Розгорнути на localnet, написати базовий тест на TypeScript за допомогою Anchor тест-рунеру.

Типова помилка: ігнорування обмежень на розмір акаунта (зараз — 10 КБ). Якщо ваша структура даних перевищує цей ліміт, програма не буде працювати в продакшені. Перевіряйте розмір ще на етапі проєктування.

Ризик: використання unwrap() у програмному коді замість коректної обробки помилок. У продакшні це призводить до паніки програми та втрати коштів користувача на комісіях за невдалі транзакції.

Перевірка результату: ви можете написати програму з двома інструкціями (створення та оновлення стану), протестувати її через Anchor тест-рунер і пояснити, чому кожен акаунт у контексті інструкції є обовʼязковим.

Етап 3 — продакшн, розгортання та тестування

Перехід від localnet до реального розгортання — це не просто зміна URL RPC-вузла. Продакшн на Solana має специфічні вимоги до безпеки, стабільності та інфраструктури.

Що треба опанувати:

  • Тестування. Одиничні тести через Anchor тест-рунер. Інтеграційні тести на devnet. Перевірка граничних випадків: що відбувається, якщо акаунт вже існує, якщо передано недостатньо SOL, якщо signer відсутній.
  • Devnet та airdrop. Робота з devnet-кластером: отримання тестового SOL через airdrop, розгортання програми, перевірка в devnet-експлорері. Перевірте актуальну процедуру airdrop в офіційній документації — ліміти та умови змінюються.
  • розгортання програми. Команда anchor deploy, розуміння того, що програма стає незмінною (immutable) за замовчуванням. Різниця між immutable та upgradeable програмами (Program Upgrade Authority).
  • Безпека ключів. Program Upgrade Authority — це ключ, який дозволяє змінювати код програми. Втрата цього ключа означає неможливість оновлення. Компрометація — можливість довільного зміну логіки. Зберігайте цей ключ офлайн.
  • RPC-провайдери. Вибір та налаштування RPC-вузла для продакшну: затримки, ліміти запитів, доступність історичних даних. Публічні RPC-вузли не підходять для серйозних проєктів.
  • Оптимізація обчислювальних витрат. Кожна транзакція має ліміт compute units. Профілювання через solana compute-budget, оптимізація циклів та аллокаций памʼяті.

Практичний крок: розгорнути свою програму на devnet, написати повний набір тестів, що покриває всі інструкції та граничні випадки, перевірити використання compute units через логи, налаштувати окремий RPC-ендпоінт для тестування.

Безпечний відкат: якщо після розгортання на devnet виявлена критична помилка, програму можна оновити через anchor upgrade за наявності Program Upgrade Authority. На mainnet ця процедура аналогічна, але кожне оновлення — це ризик довіри користувачів. Фіксуйте кожне оновлення публічно.

Типова помилка: розгортання на mainnet без повного тестування на devnet з реальними умовами (розмір транзакцій, кількість акаунтів, compute units). Локальний кластер не відтворює всі обмеження mainnet.

Перевірка результату: ваша програма розгорнута на devnet, має мінімум пʼять тестів з перевіркою позитивних та негативних сценаріїв, ви можете показати лог виконання транзакції та пояснити кожен рядок.

Критерії переходу на маршрут фаундера

Розробницький маршрут закінчується тоді, коли технічна компетенція дозволяє зосередитися на побудові продукту. Перехід на маршрут фаундера має сенс за таких умов:

  • Ви можете самостійно написати та задеплоїти програму на Solana — від ідеї до працюючого коду на devnet без постійного звертання до зовнішніх допоміжних матеріалів.
  • Ви розумієте архітектурні компроміси: коли використовувати PDA, коли — кілька інструкцій в одній транзакції, коли краще розділити логіку на дві програми.
  • Ви вмієте тестувати системно: не лише «працює — не працює», а перевіряти граничні випадки, безпеку авторизації та стійкість до некоректних вхідних даних.
  • Ви розрізняєте технічне завдання від продуктової: розумієте, що написана програма — це ще не продукт, і готові думати про користувача, ринок, юніт-економіку та дистрибуцію.
  • Ви маєте конкретну ідею проєкту, який вирішує визначену проблему, а не просто технічний концепт «для практики».

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

Якщо ж хоча б один пункт викликає сумніви — краще повернутися до відповідного етапу розробницького маршруту і закрити прогалину. Спроба стартувати як фаундер без міцної технічної бази в Solana призводить до залежності від підрядників, яких ви не можете якісно контролювати.

Джерела