Деплойментт смарт-контрактів в Solana
Деплойментт на Solana принципово відрізняється від Ethereum. Тут немає поняття "контракт" у EVM-сенсі — є programs (виконувані аккаунти) та accounts (дані). Program не зберігає стан всередині себе: весь стан живе в окремих data accounts, власником яких є program. Це змінює підхід до деплойменту та потребує планування структури аккаунтів заранее.
Інструменти: Anchor Framework
Anchor — стандартний фреймворк для Solana-розробки. Якщо писати нативний Rust без Anchor, множите час розробки на 3 та додавайте ручну десеріалізацію інструкцій. Anchor бере на себе більшість boilerplate та генерує IDL (Interface Definition Language) — аналог ABI для EVM.
# Збірка
anchor build
# Деплойментт в mainnet-beta
anchor deploy --provider.cluster mainnet-beta \
--provider.wallet ~/.config/solana/deployer-keypair.json
Вартість деплойменту: rent-exemption
У Solana зберігання даних в аккаунті коштує SOL через rent. Щоб аккаунт не був видалений, потрібно утримувати мінімальний баланс (rent-exemption). Розмір program account пропорційний розміру bytecode:
# Оцінка вартості до деплойменту
solana rent <bytes>
# Приклад: program 200KB ≈ 1.4 SOL rent-exemption
Це важливо планувати: при бюджеті на деплойментт потрібно враховувати не тільки transaction fees (~0.00025 SOL), але й rent-exemption за зберігання program account.
Buffer account та двохетапний деплойментт
Solana обмежує розмір однієї транзакції. Program більше кількох кілобайт деплоюється в кілька етапів через буферний аккаунт:
- Створюється buffer account
- Bytecode завантажується частинами через
solana program write-buffer - Program деплоюється з buffer'а атомарно
Anchor робить це автоматично. При ручному деплойменті через CLI:
solana program deploy \
--program-id target/deploy/my_program-keypair.json \
--buffer /path/to/buffer-keypair.json \
target/deploy/my_program.so
Апгрейдуємі programs
За замовчуванням Anchor створює upgradeable program з upgrade authority рівним deployer keypair. Це правильно для розробки, але не для production:
# Дивимо поточний upgrade authority
solana program show <PROGRAM_ID>
# Передаємо authority на multisig (Squads Protocol — стандартний multisig на Solana)
solana program set-upgrade-authority <PROGRAM_ID> \
--new-upgrade-authority <SQUADS_MULTISIG_ADDRESS>
Після передачі authority на multisig будь-яке оновлення program потребує M-of-N підписів. Це критично для mainnet — одиночний ключ як upgrade authority — це single point of failure.
Immutable program — якщо логіка фінальна та оновлення не плануються:
solana program set-upgrade-authority <PROGRAM_ID> --final
Це необоротно. Після цього program неможливо обновити або закрити.
Верифікація та IDL
Після деплойменту завантажуємо IDL on-chain — це дозволяє іншим розробникам та інструментам (Explorer, Anchor clients) автоматично знати інтерфейс програми:
anchor idl init --filepath target/idl/my_program.json <PROGRAM_ID> \
--provider.cluster mainnet-beta
Верифікація вихідного коду — через solana-verify (OtterSec). Публікує доказ, що on-chain bytecode відповідає конкретному Git commit:
solana-verify verify-from-repo \
--program-id <PROGRAM_ID> \
https://github.com/yourorg/yourrepo
Чеклист перед mainnet-деплойментом
- Повне тестове покриття на localnet та devnet
- Аудит (OtterSec, Neodyme, Trail of Bits — спеціалізуються на Solana)
- Program derived addresses (PDA) перевірені на колізії
- Перевірка integer overflow (Solana використовує checked arithmetic, але переконайтесь що
overflow-checks = trueвCargo.toml) - Upgrade authority передан на multisig
- Достатньо SOL на deployer wallet з урахуванням rent-exemption
- Моніторинг через Helius webhooks або Shyft на критичні інструкції