На цій сторінці зібрані інструменти для операторів валідаторів та делегаторів у мережі Solana. Кожен ресурс має чітке призначення: розрахунок, перевірку або алгоритм дій у конкретній ситуації. Усі інструменти нижче доступні як готові текстові моделі, формули та контрольні списки. Перед фінансовим або операційним рішенням підставляйте власні актуальні дані й звіряйте параметри з офіційною документацією.
Калькулятор стейкінгу
Призначення калькулятора
Калькулятор допомагає делегатору оцінити очікувану кількість токенів SOL від стейкінгу за заданий період на основі поточних параметрів мережі та обраного валідатора. Інструмент не дає фінансових гарантій і не є інвестиційною порадою.
Вхідні параметри
- Сума делегування у SOL
- Комісія валідатора (validator fee, відсоток від винагороди)
- Поточна інфляційна винагорода епохи (epoch reward) — значення, яке читач має взяти з дашборда мережі на момент розрахунку
- Загальний стейк мережі (total stake) — актуальне значення з on-chain даних
- Кількість епох у розрахунковому періоді (одна епоха в Solana триває приблизно два-три дні, точне значення треба перевіряти в дашборді)
Методика розрахунку
Планована методика базується на пропорційному розподілі інфляційної винагороди епохи між усіма делегованими токенами. Частка делегатора обчислюється як відношення його стейку до загального стейку мережі. З отриманої суми вираховується комісія валідатора. Результат множиться на кількість епох. Складні відсотки не враховуються, оскільки реальний APY (annual percentage yield) коливається від епохи до епохи залежно від змін загального стейку та інфляційного графіка.
Обмеження точності
- Розрахунок є оцінкою на основі поточного зрізу параметрів мережі й не враховує майбутніх змін інфляції, відключень валідатора або skip-rate
- Не враховується MEV-винагорода, оскільки її розподіл залежить від реалізації конкретного валідатора й не стандартизований
- Часова прив'язка епохи змінюється, тому календарний період може відрізнятися від розрахованого
Версія ресурсу
Статична версія 1.0. Остання редакційна перевірка: 2 серпня 2026 року.
Калькулятор беззбитковості валідатора
Призначення калькулятора
Калькулятор визначає мінімальний обсяг делегованого стейку, за якого валідатор покриває свої операційні витрати на інфраструктуру. Інструмент орієнтований на осіб, які планують запуск валідатора, і допомагає прийняти рішення про економічну доцільність.
Вхідні параметри
- Щомісячні витрати на інфраструктуру (сервер, хмарні ресурси, моніторинг) у фіатній валюті
- Курс SOL до обраної фіатної валідоти — значення, яке читач має перевірити на момент розрахунку
- Комісія валідатора (відсоток)
- Середня інфляційна винагорода епохи на один делегований SOL — береться з дашборда мережі
- Тривалість епохи в годинах — актуальне значення
Методика розрахунку
Планова методика: спочатку обчислюється середньодобова винагорода валідатора з одного делегованого SOL (інфляційна винагорода епохи, помножена на комісію валідатора, поділена на кількість годин в епохах за добу). Потім щомісячні витрати у фіаті переводяться у SOL за вказаним курсом. Мінімальний стейк дорівнює відношенню місячних витрат у SOL до середньодобової винагороди, помноженому на кількість днів у місяці.
Обмеження точності
- Курс SOL волатильний, тому розрахунок актуальний лише на момент введення даних
- Не враховується MEV-дохід, який може становити значну частку доходу валідатора
- Не враховуються одноразові витрати на початкове налаштування, депозит резервного стейку та можливі штрафи (slash) за подвійне підписання
- Середня винагорода епохи може суттєво змінюватися протягом місяця
Версія ресурсу
Статична версія 1.0. Остання редакційна перевірка: 2 серпня 2026 року.
Чек-лист оновлення валідатора
Призначення чек-листа
Чек-лист забезпечує контрольоване оновлення програмного забезпечення валідатора (Solana Validator CLI, агента) без простою та втрати делегованого стейку. Оновлення валідатора — це рутинна, але небезпечна процедура: помилка на будь-якому етапі може призвести до пропуску слотів і зниження репутації.
Етапи оновлення
- Моніторинг релізу. Отримати офіційне повідомлення про нову версію з GitHub-репозиторію Solana. Перевірити, чи є реліз обов'язковим (hard fork) чи рекомендованим.
- Перевірка сумісності. Ознайомитися з release notes: зміни в форматі snapshot, вимоги до версії Rust, сумісність з поточною версією мережі.
- Резервне копіювання. Зберегти поточну конфігурацію, identity ключі та путь до snapshot-директорії. Переконатися, що резервна копія знаходиться на окремому носії або сервері.
- Тестове середовище. За наявності — перевірити оновлення на тестовій машині з тією ж конфігурацією.
- Оновлення бінарного файлу. Зупинити сервіс валідатора, завантажити нову версію, перевірити контрольні суми (checksums), замінити бінарний файл.
- Запуск і перевірка. Запустити валідатор, перевірити логи на відсутність помилок, переконатися, що валідатор підписує слоти (перевіряється через дашборд або CLI-команду).
Критерії успішного оновлення
- Валідатор підписує слоти протягом перших трьох епох після оновлення
- У логах відсутні критичні помилки (panic, consensus failure)
- Версія у відповіді на RPC-запит відповідає очікуваній
- Skip-rate не перевищує попередні показники більш ніж на прийнятну межу (конкретне значення кожен оператор визначає самостійно)
Обмеження чек-листа
- Чек-лист не замінює офіційну документацію до конкретного релізу, де можуть бути унікальні кроки міграції
- Не охоплює оновлення супутнього ПЗ: моніторингу, автоматизації, фаєрволів
- Не враховує специфічні конфігурації хмарних провайдерів (bare metal, спеціальні образи)
Версія ресурсу
Статична версія 1.0. Остання редакційна перевірка: 2 серпня 2026 року.
Чек-лист підготовки сервера валідатора
Призначення чек-листа
Чек-лист забезпечує повну готовність фізичного або хмарного сервера до запуску вузла Solana. Це початковий етап, який визначає стабільність усієї подальшої роботи валідатора. Пропущений крок на етапі підготовки часто призводить до складнощів, які важко діагностувати в робочому середовищі.
Етапи підготовки
- Вибір та замовлення сервера. Перевірити відповідність мінімальним апаратним вимогам: кількість ядер CPU, обсяг RAM, швидкість дискового вводу-виводу (IOPS), пропускна здатність мережі. Конкретні цифри змінюються з розвитком мережі — актуальні вимоги треба перевіряти в офіційній документації Solana.
- Операційна система. Встановити підтримувану версію Linux (Ubuntu, Debian або іншу з офіційного списку). Налаштувати автоматичні оновлення безпеки.
- Мережеві налаштування. Налаштувати статичну IP-адресу, відкрити необхідні порти (UDP та TCP для трафіку валідатора), перевірити MTU, налаштувати фаєрвол (UFW або аналоги).
- Дискова підсистема. Налаштувати розділи: окремий розділ для snapshot-даних з відповідною файловою системою (зазвичай XFS або ext4 з конкретними параметрами монтування). Перевірити швидкість запису/читання бенчмарком.
- Встановлення ПЗ. Встановити Solana CLI, перевірити версію, налаштувати змінні середовища.
- Генерація ключів. Згенерувати identity ключі, надійно зберегти приватний ключ (offline, на окремому носії).
- Моніторинг. Встановити та налаштувати агент моніторингу (Prometheus node exporter або аналоги), перевірити відправку метрик.
- Синхронізація. Запустити синхронізацію з snapshot або від genesis (залежно від обраного підходу), переконатися в стабільному завантаженні слотів.
Критерії готовності сервера
- Сервер безперервно синхронізується без помилок у логах протягом щонайменше кількох годин
- Дискова підсистема забезпечує необхідну швидкість IOPS під навантаженням
- Мережеві порти доступні для вхідних з'єднань з інших вузлів мережі
- Моніторинг фіксує та передає метрики (CPU, RAM, дискове місце, мережевий трафік)
- Identity ключі згенеровані, приватний ключ надійно збережений поза сервером
Обмеження чек-листа
- Не охоплює налаштування high-availability конфігурацій (hot spare, автоматичне перемикання)
- Не містить специфічних команд для кожного хмарного провайдера — читач має адаптувати етапи до свого середовища
- Не замінює офіційний гід із запуску валідатора, де можуть бути додаткові або змінені кроки
Версія ресурсу
Статична версія 1.0. Остання редакційна перевірка: 2 серпня 2026 року.
Аварійний runbook валідатора
Призначення runbook
Runbook забезпечує валідатора готовим алгоритмом дій у типових аварійних ситуаціях. Головна мета — мінімізувати час простою та уникнути поспішних рішень під стресом. Це не довідник з усіх можливих помилок, а набір чітких процедур для найпоширеніших інцидентів.
Типи аварійних сценаріїв
- Зупинка валідатора (crash). Процес валідатора завершився неочікувано або не запускається.
- Відставання за слотами (lagging). Валідатор синхронізується, але відстає від поточного слота мережі.
- Дискове місце. Закінчується вільне місце на розділі зі snapshot-даними або логами.
- Мережева втрата зв'язку. Валідатор не отримує та не відправляє трафік мережі.
- Підозра на компрометацію ключів. Є підстави вважати, що приватний identity ключ скомпрометовано.
Порядок дій для кожного сценарію
Зупинка валідатора. Перевірити логи на наявність panic-повідомлень або out-of-memory помилок. Перевірити наявність вільного місця та RAM. Спробувати перезапуск сервісу. Якщо проблема повторюється — перевірити цілісність snapshot-даних, за потреби завантажити свіжий snapshot. Якщо причину не виявлено — зафіксувати логи та звернутися до спільноти валідаторів.
Відставання за слотами. Перевірити завантаження CPU та дискову підсистему під час синхронізації. Перевірити мережеву затримку до інших вузлів. Якщо відставання значне — розглянути завантаження свіжого snapshot замість поступальної синхронізації. Перевірити, чи не змінилися апаратні вимоги мережі з останнього оновлення.
Дискове місце. Визначити, який саме розділ заповнений. Очистити старі логи (зберігши останні для діагностики). Перевірити налаштування обмеження розміру snapshot (якщо застосовне). Якщо місця критично мало — розглянути розширення диска або міграцію на більший обсяг до повного заповнення, оскільки повний диск може пошкодити файлову систему під час запису.
Мережева втрата зв'язку. Перевірити статус мережевого інтерфейсу сервера. Перевірити правила фаєрвола — чи не змінилися вони внаслідок оновлення ОС. Перевірити доступність портів ззовні (з іншого вузла). Зв'язатися з провайдером, якщо проблема на його стороні.
Підозра на компрометацію ключів. Негайно зупинити валідатор. Не видаляти файли — зберегти їх для аналізу. Використати резервну копію ключів для перевірки. Якщо компрометація підтверджена — виконати процедуру зміни identity ключа згідно з офіційною документацією (залучається ключ облікового запису для авторизованої зміни). Усі дії фіксувати для подальшого розслідування.
Обмеження runbook
- Runbook не є вичерпним переліком усіх можливих інцидентів — він охоплює лише типові сценарії
- Не містить специфічних діагностичних команд для кожної версії ПЗ — точні команди залежать від встановленої версії
- Сценарій компрометації ключів вимагає індивідуального підходу та може потребувати залучення юридичних або комунікаційних кроків, які виходять за межі технічного runbook
- Не замінює експертну діагностику в разі нетипової поведінки вузла
Версія ресурсу
Статична версія 1.0. Остання редакційна перевірка: 2 серпня 2026 року.