Розгортання на Devnet — це обов'язковий етап підготовки submission. Журі оцінює робочі демо, а не локальні збірки, тому ваш проєкт має бути доступний у тестовій мережі Solana. Нижче — покрокова послідовність від налаштування середовища до перевірки, що все працює для стороннього користувача.
Що таке Devnet і чому він потрібен для хакатону
Devnet — це повноцінна тестова мережа Solana, яка дублює поведінку основної мережі (Mainnet-Beta), але працює з тестовими токенами, що не мають грошової вартості. Усі смарт-контракти, транзакції, PDA (Program Derived Addresses) та CPI (Cross-Program Invocations) функціонують тут так само, як на Mainnet.
Для хакатону Devnet потрібен з трьох причин:
- Журі перевіряє проєкт самостійно. Члени журі клонують ваш репозиторій, запускають розгортання або підключаються до вже розгорнутої програми — і все це має спрацювати без ваших локальних файлів.
- Безпека. Ви не ризикуєте справжніми коштами під час тестування транзакцій, міграцій або фронтенд-інтеграцій.
- Відтворюваність. Будь-хто з команди або ментор може повторити розгортання з чистої машини і отримати ідентичний результат.
Послідовність розгортання
Налаштування середовища та гаманця
Передумови: встановлені Node.js (версію перевірте в офіційному пакет першоджерел поточного хакатону), Rust, Solana CLI та Anchor. Усі інструменти мають бути стабільних версій — не використовуйте нічні збірки (nightly) під час хакатону.
Кроки:
- Перевірте версію Solana CLI:
solana --version - Перемкніть CLI на Devnet:
solana config set --url devnet - Перевірте поточну конфігурацію:
solana config get
Поле RPC URL має показуватиhttps://api.devnet.solana.com. - Згенеруйте нову пару ключів для хакатону (не використовуйте гаманець з Mainnet):
solana-keygen new --outfile ~/hackathon-devnet.json - Вкажіть цей файл як ключовий для CLI:
solana config set --keypair ~/hackathon-devnet.json
Ризик: якщо ви випадково вкажете ключ від Mainnet-гаманця, тестові транзакції не пройдуть (інша мережа), але сам ключ залишиться в безпеці — Devnet-транзакції не валідуються Mainnet-валідаторами. Проте для дисципліни краще мати окремий файл ключа.
Отримання тестованих SOL на Devnet
Для розгортання програми та виконання транзакцій вашому гаманцю потрібні тестові SOL. Два способи:
1. Через CLI (до 2 SOL за запит):
solana airdrop 2
2. Через веб-фацет: знайдіть офіційний faucet для Devnet (адресу перевірте в пакет першоджерел поточного хакатону) і вставте адресу вашого гаманця.
Перевірте баланс:
solana balance
Типова проблема: faucet може мати ліміт за IP або за часом. Якщо CLI-airdrop повертає помилку, спробуйте faucet або зачекайте кілька хвилин. Не створюйте кілька гаманців «про запас» — це ускладнить відстеження транзакцій.
Розгортання смарт-контракту
Якщо ви використовуєте Anchor:
- Збірка:
anchor build - У файлі
Anchor.tomlпереконайтеся, що рядокcluster = "devnet"розкоментовано, аmainnet— закоментовано. - Розгортання:
anchor deploy - CLI виведе Program ID щойно розгорнутої програми. Скопіюйте його — він знадобиться для фронтенду та для журі.
Якщо ви розгортаєте без Anchor (чистий Rust + BPF):
- Збірка:
cargo build-sbf - Розгортання:
solana program deploy ./target/deploy/your_program.so
Очікуваний результат: у терміналі з'являється Program ID (рядок у форматі Base58, 32–44 символи), а транзакція розгортання фіксується в мережі.
Безпечний відкат: збережіть попередній Program ID (якщо він був) і стан Anchor.toml у git-коміт перед розгортанням. Якщо щось пішло не так, ви зможете повернутися до попереднього стану.
Перевірка транзакцій у експлорері
Після розгортання відкрийте Solana Explorer для Devnet (точну URL-адресу перевірте в пакет першоджерел) і вставте ваш Program ID у рядок пошуку. Ви маєте побачити:
- Статус програми — Active
- Транзакцію розгортання з підтвердженням
- Акаунт програми з відображенням балансу (у ламports)
Якщо експлорер показує помилку або програму не знайдено — розгортання не завершилося. Поверніться до термінала і прочитайте лог помилки.
Типові помилки розгортання та їх вирішення
| Помилка | Причина | Вирішення |
|---|---|---|
Insufficient funds |
На гаманці менше SOL, ніж потрібно для розгортання (зазвичай від 0.5 до 3 SOL залежно від розміру програми) | Зробіть ще один airdrop або оптимізуйте розмір .so файлу |
Error: RPC response error -32002: Transaction simulation failed |
Логіка програми не проходить симуляцію транзакції | Додайте прапорець --with-compute-unit-price або перевірте логіку ініціалізації акаунтів |
| Program ID у фронтенді не збігається з розгорнутим | Після повторного розгортання Program ID змінився, але у фронтенді залишився старий | Оновіть Anchor.toml (розділ [programs.devnet]) та відповідні константи у фронтенді |
Account not found при виклику з фронтенду |
PDA не ініціалізовано або насіння (seeds) відрізняються від тих, що використовуються при розгортанні | Перевірте порядок і склад seeds у коді програми та у фронтенд-виклику |
| Фронтенд підключається до Mainnet замість Devnet | У конфігурації фронтенду (наприклад, у .env або провайдері) вказано неправильний RPC endpoint |
Перевірте, що використовується саме https://api.devnet.solana.com |
Як переконатися, що журі зможе запустити проєкт
Журі не має часу розбиратися у вашому локальному налаштуванні. Щоб демо спрацювало з першого разу, перевірте таке:
- Фронтенд підключений до Devnet. Відкрийте консоль браузера на розгорнутій версії (Vercel, Netlify, GitHub Pages) і переконайтеся, що RPC-запити йдуть на devnet-endpoint, а не на localhost.
- Program ID зашитий коректно. У коміті, який ви подаєте, не повинно залишатися службового коментаря із вимогою пізніше замінити Program ID.
- Є .env.example без секретів. У файлі мають бути лише назви змінних і приклади значень. Справжні ключі ніколи не комітіть.
- Є скрипт для розгортання. Додайте до
package.jsonабо окремий файл (наприклад,scripts/deploy-devnet.sh) команди, які журі або ментор може виконати послідовно. - Тестовий гаманець із балансом. Якщо для демо потрібен попередньо створений акаунт із токенами або NFT, додайте інструкцію, як його створити, або передбачте скрипт ініціалізації.
- Запустіть демо з чистої машини. Клонуйте власний репозиторій на інший комп'ютер або у чисту папку і виконайте всі кроки з README. Якщо щось ламається — ви знайдете проблему раніше за журі.
Наступний крок: оформлення GitHub
Після успішного розгортання на Devnet і перевірки в експлорері ваш репозиторій має стати самодостатнім посібником для журі. Це означає: актуальний README з інструкцією запуску, правильна структура гілки, відсутність секретів у історії комітів та чітко вказаний Program ID. Про те, як правильно оформити репозиторій для submission, читайте в наступному матеріалі — Як перевірити submission перед відправленням.