Розробка смарт-контрактів на Rust (Solana)

Ми розробляємо смарт-контракти на Rust для Solana під ключ — від проектування accounts model до деплою з multisig. Solana приваблює розробників субсекундними фінальностями та вартістю транзакції в $0.00025. Але за цією швидкістю стоїть принципово інша модель виконання: accounts model замість contract storage, stateless programs, PDA-деривати замість mapping. Розробник, який прийшов з EVM, перші два тижні думає, що Solana зламана — тому що звичні паттерни Solidity тут або не працюють, або призводять до вразливостей іншого класу. Ми навчилися обходити ці граблі за 5 років практики.

Чому Solana-програми ламають EVM-розробника

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

Missing signer check — розробка смарт контрактів

Перша грабля: missing signer check. Програма отримує account через AccountInfo, але не перевіряє, що переданий authority дійсно підписав транзакцію. В Anchor це ловиться через атрибут #[account(signer)] або тип Signer<'info>. У нативному Rust — через явну перевірку if !authority.is_signer { return Err(...) }. Пропустити це легко, коли пишеш перші програми.

Account substitution

Друга класична вразливість — account substitution. Програма приймає token_account і authority, але не перевіряє, що token_account.owner збігається з переданим authority. Атакуючий передає свій token_account і чужий authority — програма виконується без помилок і дренує чужі токени.

PDA derivation mismatch

Третя біль — PDA derivation mismatch. Program Derived Address обчислюється з seeds + program_id. Якщо seeds не перевірені явно через find_program_address з constraint-ом в Anchor (seeds = [b"vault", user.key().as_ref()]), атакуючий може передати довільний account, який випадково збігається з PDA за адресою, але не є легітимним.

Як Anchor змінює рівняння безпеки?

Працюємо переважно через Anchor framework (поточна версія 0.30.x). Anchor генерує discriminator для кожного account type і перевіряє його при десеріалізації — це автоматично закриває цілий клас type confusion атак, де атакуючий передає account не того типу.

Типова структура інструкції в нашій кодовій базі:

#[derive(Accounts)] pub struct Deposit<'info> { #[account( mut, seeds = [b"vault", user.key().as_ref()], bump, constraint = vault.authority == user.key() @ ErrorCode::Unauthorized )] pub vault: Account<'info, VaultState>, #[account( mut, associated_token::mint = mint, associated_token::authority = user )] pub user_token_account: Account<'info, TokenAccount>, pub user: Signer<'info>, pub mint: Account<'info, Mint>, pub token_program: Program<'info, Token>, pub system_program: Program<'info, System>, } 

Constraint-и в #[account(...)] — це не просто цукор. Вони компілюються в явні перевірки перед виконанням інструкції. Якщо constraint порушено — транзакція реверт-иться до того, як логіка інструкції виконалася.

Як тестувати Solana-програми без запуску валідатора?

Для більшості unit-тестів використовуємо solana-bankrun — він підіймає синтетичний runtime в пам'яті без запуску validator-а. Тест, який на localnet зайняв би 3 секунди (слот кожні 400 мс), виконується за 50 мс — у 60 разів швидше. Це критично для fuzzing-а.

Інтеграційні тести — на localnet через anchor test. Додаємо --skip-local-validator там, де тестовий сценарій вимагає реальних програм (Associated Token Program, Metaplex) — клонуємо їх стан з mainnet через --clone.

Для фаззингу SPL-програм використовуємо Trident (Ackee Blockchain's fuzzer). Він генерує випадкові послідовності інструкцій і шукає panics, unexpected account state, integer overflow. На одному з проєктів Trident за 4 години знайшов сценарій, де послідовність init → close → reinit призводила до повторної ініціалізації account з чужими даними — Anchor discriminator при цьому проходив, тому що reinit використовував той самий тип.

Оптимізація compute units

Solana обмежує кожну транзакцію в 1.4M compute units за замовчуванням (запросити можна до 1.4M через SetComputeUnitLimit). Serialization/deserialization через Borsh — дороге задоволення для великих структур.

Практика: розбиваємо великі state структури на кілька account-ів. Замість одного ProgramState з 50 полями — кілька спеціалізованих account-ів. Менше даних десеріалізується на кожен виклик — менше CU витрачається.

Другий прийом: zero_copy акаунти через #[account(zero_copy)] в Anchor. Дані читаються напряму з пам'яті без Borsh-десеріалізації. На структурах >1KB економія 30-50% CU.

Процес розробки

Аналітика та проектування (2-5 днів). Розбираємо accounts model під задачу: які PDA потрібні, які seeds, де потрібен CPI в Token Program або Associated Token Program. Проектуємо state до написання коду — переробка accounts структури на етапі тестування коштує дорого.

Розробка (3-10 днів залежно від складності). Anchor + Rust stable. Покриваємо кожну інструкцію тестами через Bankrun. Складні сценарії (PDA lifecycle, CPI chains) — на localnet.

Security review. Проганяємо через Soteria (статичний аналіз Solana-програм) і ручний review за чеклистом: missing signer, ownership checks, PDA validation, integer arithmetic (використовуємо checked_add, checked_mul всюди).