Деплой смарт-контрактов в Solana

Деплой смарт-контрактов в 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 больше нескольких килобайт деплоится в несколько этапов через буферный аккаунт:

1. Создаётся buffer account
2. Bytecode загружается частями через solana program write-buffer
3. 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

Upgradeable 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 на критичные инструкции