Нижче зібрані робочі чек-листи та шаблони, які охоплюють повний цикл створення Solana-програми: від безпеки й code review до розгортання на mainnet і налагодження. Кожен ресурс містить конкретні кроки, критерії завершення та обмеження. Усі п’ять ресурсів подано нижче як готові текстові шаблони й контрольні списки. Їх можна копіювати до робочої документації та адаптувати під конкретний репозиторій.
Чек-лист security review програми
Призначення чек-листа
Системна перевірка Solana-програми (smart contract) на вразливості перед розгортанням або передачею зовнішньому аудитору. Орієнтований на програми, написані на Rust з використанням фреймворку Anchor, але застосовний і до нативних програм на Rust.
Етапи перевірки
- Контроль доступу та авторизація. Перевірте, чи кожен instruction має коректні обмеження: перевірка підписувача (signer), валідація authority, перевірка належності акаунта через seeds у PDA (Program Derived Address — деривований адрес програми).
- Обробка акаунтів. Перевірте, чи всі акаунти, що передаються в instruction, мають правильні типи (AccountInfo vs. специфічні типи Anchor), чи не пропущені перевірки owner (власник акаунта має збігатися з адресою програми), чи коректно встановлені mutable/immutable.
- Математичні операції та переповнення. Знайдіть усі операції з числами та переконайтеся, що використовуються типи, стійкі до переповнення (u64, u128, checked_add, checked_sub), або що Anchor автоматично додає перевірки через обмеження типів.
- Перехресні виклики (CPI — Cross-Program Invocation). Для кожного CPI перевірте: наявність правильних seeds при ініціалізації акаунтів, коректність переданих акаунтів у виклик, відсутність можливості підміни програми через зловмисний CPI.
- Керування станом. Перевірте, чи ініціалізуються акаунти до запису даних, чи не можна повторно ініціалізувати вже існуючий акаунт (перевірка прапорця init у Anchor), чи коректно закриваються акаунти (close) з поверненням lamports.
- Механіки токенів. Якщо програма працює з SPL Token, перевірте коректність передачі токенів (transfer, transfer_checked), наявність перевірки mint-адреси, правильну роботу з Token Account та асоційованими токен-акаунтами (ATA).
- Органіка обчислювального бюджету. Оцініть, чи не перевищує програма ліміт обчислювальних одиниць (compute units) у типових сценаріях, чи немає циклів із невизначеною кількістю ітерацій.
Критерії завершення перевірки
- Усі пункти чек-листа мають статус «пройдено» або «не застосовується» з письмовим обґрунтуванням.
- Знайдені вразливості зафіксовані з рівнем критичності (critical / high / medium / low) і прив'язані до конкретного рядка коду.
- Виправлення підтверджені повторним проходженням чек-листа.
Обмеження чек-листа
- Не замінює повноцінний зовнішній аудит безпеки — це інструмент внутрішньої превентивної перевірки.
- Не охоплює вразливості на рівні клієнтської частини (frontend, wallet connection).
- Не перевіряє економічну модель токеноміки та механіки MEV (Maximal Extractable Value — максимальна цінність, яку можна вилучити).
Версія ресурсу
Статична текстова версія 1.0. Розділ «Чек-лист security review програми» готовий до практичного використання. Перед виконанням команд звірте версії інструментів з офіційною документацією.
Шаблон README для open-source проєкту
Призначення шаблону
Уніфікована структура README-файлу для Solana-програм з відкритим кодом. Забезпечує швидке розуміння проєкту контриб'юторами, валідаторами та користувачами.
Структура README
- Назва та короткий опис. Одне речення: що робить програма і для якої аудиторії.
- Статус проєкту. Вказівка стадії (prototype / testnet / mainnet) і попередження про використання на реальних коштах, якщо застосовно.
- Передумови (Prerequisites). Версія Rust, версія Solana CLI, версія Anchor, Node.js (якщо є TypeScript-клієнт), операційна система.
- Встановлення та збірка. Конкретні команди: anchor build, cargo build-sbf або еквівалентні.
- Розгортання (Deployment). Команди для devnet і mainnet з приміткою про необхідність налаштування RPC-провайдера.
- Використання. Мінімальний приклад виклику instruction з CLI або TypeScript-клієнта.
- Архітектура. Опис ключових акаунтів (PDA-схеми), основних instructions та зв'язків між модулями.
- Тестування. Як запустити тести: anchor test, покриття, де знаходяться інтеграційні тести.
- Внесок (Contributing). Короткі правила: гілкування, форматування коду, обов'язковість тестів для PR.
- Ліцензія. Точна назва ліцензії з посиланням на повний текст.
Порядок заповнення
- Копіюйте структуру як каркас.
- Заповніть кожен розділ конкретними даними вашого проєкту — не залишайте порожні секції або службові позначки замість змісту.
- Перевірте, що команди з розділів «Збірка» і «Тестування» реально виконуються у чистому середовищі.
- Додайте посилання на deployed-адресу програми на devnet/mainnet, якщо є.
Обмеження шаблону
- Не містить секції для документування токеноміки чи економічної моделі — це окремий документ.
- Не адаптований для проєктів без CLI-інтерфейсу (наприклад, виключно програмних бібліотек).
- Не включає секцію CHANGELOG — її ведуть окремо.
Версія ресурсу
Статична текстова версія 1.0. Розділ «Шаблон README для open-source проєкту» готовий до практичного використання. Перед виконанням команд звірте версії інструментів з офіційною документацією.
Чек-лист code review
Призначення чек-листа
Структурована перевірка pull request (PR) у репозиторії Solana-програми. Фокус — на коректності бізнес-логіки, дотриманні конвенцій Anchor/Rust та уникненні типових помилок.
Блоки перевірки
- Структура та організація коду. Чи відповідає розмір файлів прийнятним межам (до 300–400 рядків), чи логічно розділені модулі, чи немає дублювання логіки між instructions.
- Типи та серіалізація. Чи всі структури даних мають правильні анотації Anchor (#[account]), чи коректно вказані space (розмір) для акаунтів, чи немає зайвих полів, що збільшують rent.
- Обробка помилок. Чи використовуються кастомні error-коди замість generic-помилок, чи кожна гілка логіки має обробку помилок, чи повідомлення про помилки є зрозумілими для зовнішнього клієнта.
- Тести. Чи покритий новий функціонал тестами (щонайменше: happy path, один негативний сценарій), чи тести ізольовані (не залежать від стану попередніх тестів), чи використовуються окремі акаунти для кожного тесту.
- Міграції та сумісність. Чи не ламає зміна існуючу структуру даних акаунтів (зміна порядку полів, зміна типів), чи передбачена міграція, якщо зміна несумісна.
- Логування та метрики. Чи додано msg! для ключових точок виконання (без надлишковості), чи не логуються чутливі дані (приватні ключі, seed-фрази).
Критерії затвердження PR
- Усі блоки перевірки мають статус «ок» або «не застосовується».
- Усі тести проходять у CI-середовищі (не лише локально).
- Кожне відкладене завдання має посилання на issue та зрозуміле обґрунтування.
- Зміни не порушують backward compatibility без явної згоди команди.
Обмеження чек-листа
- Не замінює автоматизовані інструменти (cargo clippy, cargo fmt, anchor test) — доповнює їх.
- Не охоплює перевірку frontend-коду, що взаємодіє з програмою.
- Не містить критеріїв оцінки продуктивності (benchmarking) — це окремий процес.
Версія ресурсу
Статична текстова версія 1.0. Розділ «Чек-лист code review» готовий до практичного використання. Перед виконанням команд звірте версії інструментів з офіційною документацією.
Чек-лист deployment на mainnet
Призначення чек-листа
Покрокова перевірка готовності Solana-програми до розгортання в основній мережі. Мінімізує ризики втрати коштів, блокування програми або некоректної роботи після розгортання.
Етапи розгортання
- Фінальна збірка. Збірка в режимі release (cargo build-sbf --release або anchor build -- --release), перевірка розміру бінарного файлу (не перевищує ліміт у 200 КБ для однієї програми).
- Верифікація на devnet. Розгортання на devnet, прогон усіх інтеграційних тестів у devnet-середовищі, перевірка розміру акаунта програми та rent-exempt статусу.
- Підготовка ключів. Перевірка, що keypair для розгортання не є devnet-ключем, що ключ зберігається в безпечному місці (не у файлі системи без шифрування), що є резервна копія ключа.
- Бюджет розгортання. Розрахунок вартості: rent для акаунта програми + комісія за транзакцію розгортання. Перевірка, що на розгортання-акаунті достатньо SOL з запасом.
- RPC-провайдер. Налаштування надійного RPC-ендпоінту для mainnet (не публічний за замовчуванням, якщо можливе перевантаження), перевірка доступності та затримки.
- розгортання. Виконання solana program deploy або anchor deploy --provider.cluster mainnet, фіксація program ID після розгортання.
- Верифікація після розгортання. Перевірка program ID через solana program show, тестовий виклик instruction з реальним кошельком, перевірка логів через solana logs.
- Фіксація артефактів. Збереження: program ID, хеш коміту, бінарний файл (.so), ключ розгортання, дата й час розгортання.
Критерії готовності до релізу
- Усі тести пройдені на devnet із тими самими бінарними файлами, що деплояться на mainnet.
- Security review завершено без незакритих critical/high-вразливостей.
- Клієнтська частина оновлена з правильним program ID для mainnet.
- Є план відкату: або upgradeable-програма з Buffer-акаунтом, або задокументована процедура повідомлення користувачів про зупинку.
Обмеження чек-листа
- Не охоплює процес отримання program ID через Immutable Authority (застарілий підхід) — орієнтований на сучасний deploy з upgradeable authority.
- Не містить інструкцій для мультиподпису (multisig) розгортання — це залежить від обраного інструменту (Squads, реєстр Anchor тощо) і потребує окремого чек-листа.
- Не регулює питання ліцензування програми в контексті мережі.
Версія ресурсу
Статична текстова версія 1.0. Розділ «Чек-лист deployment на mainnet» готовий до практичного використання. Перед виконанням команд звірте версії інструментів з офіційною документацією.
Чек-лист debugging Solana-програми
Призначення чек-листа
Послідовна діагностика помилок під час розробки та тестування Solana-програми. Допомагає системно підійти до аналізу невдалої транзакції замість хаотичного перегляду логів.
Етапи діагностики
- Фіксація помилки. Запишіть: текст помилки, signature транзакції, програмний ID, середовище (localnet / devnet / mainnet), версія Solana CLI та Anchor.
- Аналіз signature. Отримайте детальний лог транзакції через solana confirm -v <signature> або через блокчейн-експлорер. Знайдіть, який саме instruction завершився помилкою і який код помилки повернуто.
- Декодування помилки. Якщо це Anchor-програма — розшифруйте error code за допомогою anchor idl parse або вручну за IDL. Якщо нативна Rust-програма — перевірте визначені error-коди у вихідному коді.
- Перевірка передумов транзакції. Перевірте: чи акаунт існує і чи rent-exempt, чи підписувач дійсно підписав транзакцію, чи достатньо SOL для комісій, чи не застаріла транзакція (blockhash).
- Перевірка стану перед викликом. За допомогою solana account <address> перевірте поточний стан акаунтів, що передаються в instruction: дані, owner, lamports.
- Изоляція проблеми. Спробуйте відтворити помилку в мінімальному тесті з одним instruction і мінімальним набором акаунтів. Якщо помилка зникає — проблема в контексті (попередній стан, порядок instructions).
- Локальне налагодження. Використовуйте solana-test-validator з фіксованими акаунтами (параметр --account), додайте msg! у підозрілі місця коду, перезбірте й повторіть тест.
Інструменти для налагодження
| Інструмент | Призначення | Обмеження |
|---|---|---|
| solana logs | Потокове читання логів програми в реальному часі | Працює лише з локальним validator; для devnet/mainnet потрібен власний RPC-вузол |
| solana-test-validator | Локальна тестова мережа з можливістю завантаження стану акаунтів | Не відтворює поведінку мережі при високому навантаженні та конкурентних транзакціях |
| msg! макрос | Вивід діагностичних повідомлень з програми | Збільшує розмір програми та споживає compute units; не підходить для масового логування |
| Блокчейн-експлорери | Візуальний перегляд транзакцій, акаунтів та інструкцій | Не показують внутрішній стан програми між instructions; залежать від індексатора |
| Anchor test з --verbose | Детальний вивід результатів тестів включно з логами програми | Застосовується лише в рамках тестового фреймворку Anchor |
Обмеження чек-листа
- Не охоплює налагодження клієнтської частини (TypeScript/JavaScript) — лише програму на ланцюгу.
- Не містить інструкцій для використання зовнішніх дебагерів (lldb, gdb) з бінарними файлами BPF — це окрема тема, що вимагає специфічного середовища.
- Не призначений для діагностики проблем із консенсусом мережі (наприклад, пропущені слоти) — такі випадки вимагають звернення до статусу мережі.
Версія ресурсу
Статична текстова версія 1.0. Розділ «Чек-лист debugging Solana-програми» готовий до практичного використання. Перед виконанням команд звірте версії інструментів з офіційною документацією.