Тестування оновлення валідатора на тестових кластерах перед застосуванням на mainnet — це не формальність, а єдиний надійний спосіб виявити регресії, зміни в поведінці консенсусу та проблеми сумісності конфігурації. Нижче — повний операційний цикл від розгортання до фіксації результатів.
Операційні вимоги для «Як тестувати оновлення на testnet та devnet» перевірено 2 серпня 2026 року. Для production використовуйте тільки реліз Agave, рекомендований для конкретного кластера, і звіряйте параметри з agave-validator --help . Офіційні вимоги Anza на цю дату орієнтують операторів на Ubuntu 24.04, щонайменше 12 ядер/24 потоки, 256 ГБ RAM, окремі швидкі NVMe та симетричний канал від 2 Гбіт/с; це рекомендації, а не гарантія достатньої продуктивності.
Середовище перевірки: клієнт Agave (офіційний валідатор Solana), Ubuntu 24.04 LTS, кластери testnet та devnet. Конкретні версії та хеші релізів змінюються часто — перед кожним тестом перевіряйте актуальні дані в офіційному репозиторії Agave на GitHub.
Різниця між testnet та devnet
Обидва кластери служать для тестування, але мають принципово різне призначення та характеристики навантаження.
| Параметр | testnet | devnet |
|---|---|---|
| Призначення | Тестування оновлень клієнта, консенсусу, валідаторної інфраструктури | Тестування dApps, смарт-контрактів, інтеграцій розробників |
| Токени | Не мають реальної цінності, але видаються через faucet | Не мають реальної цінності, видаються через faucet у значно більших обсягах |
| Навантаження | Близьке до mainnet за структурою транзакцій і кількістю валідаторів | Нестабільне, зі сплесками через airdrop-активність та масовані розгортання |
| Стабільність | Відносно стабільний, перезапуски рідші | Часті перезапуски, скидання стану, можливі довгі зупинки |
| Корисність для валідатора | Висока — перевірка консенсусу, пропускної здатності, оновлень | Низька — середовище надто мінливе для інфраструктурних тестів |
Практичне правило: для тестування оновлення валідатора завжди обирайте testnet. Devnet підходить лише як додаткова перевірка, якщо оновлення стосується RPC-шару або взаємодії з програмами, і ви хочете перевірити поведінку саме під час масового смарт-контрактного навантаження.
Розгортання валідатора на testnet
Передумови: сервер із мінімум 16 ядрами CPU, 128 ГБ RAM, NVMe SSD від 1 ТБ (повні вимоги до залежності від поточного розміру леджера — перевіряйте в документації), відкриті порти 8000–8020 (UDP/TCP), встановлені `solana-cli` та `agave-validator`.
Очікуваний результат: валідатор синхронізований з testnet, має статус `Validator` у `solana validator-info`, бере участь у консенсусі.
Ризики: мінімальні, оскільки testnet не несе фінансових наслідків. Проте некоректна конфігурація може призвести до бану IP або марної витрати ресурсів.
- Створіть окрему директорію та ідентичність:
Ніколи не використовуйте ключі від mainnet-валідатора на testnet. Згенеруйте нову пару ключів:
solana-keygen new -o /testnet/validator-keypair.json
- Отримайте testnet-SOL для стейкінгу:
Використовуйте faucet для testnet. Перевірте баланс:
solana balance /testnet/validator-keypair.json --url https://api.testnet.solana.com
- Створіть стейк-акаунт і делегуйте:
solana create-stake-account /testnet/stake-account.json /testnet/validator-keypair.json 50 --url https://api.testnet.solana.com
solana delegate-stake /testnet/stake-account.json /testnet/validator-keypair.json --url https://api.testnet.solana.com
- Запустіть валідатор:
agave-validator --identity /testnet/validator-keypair.json --vote-account /testnet/vote-account.json --ledger /testnet/ledger --known-validator 7Np41oeYjPp3sU7bTTt6mK3d4z3L1GbgDkuspPbFqKFZ --known-validator CY7opG5MNM9kCkPvZU6qA2N7EyekiC3mPmhJZJD5qTmS --known-validator DtZqDSCGMADPiS4rePjvGCuRiZqLHt8mzJC8sJmVcukP --entrypoint entrypoint.testnet.solana.com:8001 --expected-genesis-hash 4nY6VDW9e5kPJoGxVBkC8AuZUkkGzbsJ1UK2siqfFz4w --limit-ledger-size 50000000
Список `--known-validator` оновлюється — перевіряйте актуальні значення в репозиторії перед запуском.
- Перевірте статус:
solana validator-info --url https://api.testnet.solana.com
Статус має змінитися з `None` на `Validator` після того, як вузол досягне достатнього стейку та синхронізації.
Симуляція оновлення
Мета: перевірити, що нова версія Agave успішно стартує на існуючому леджері, не ламає консенсус і не викликає відставання (delinquency).
Передумови: валідатор на testnet повністю синхронізований і активно голосує.
Очікуваний результат: валідатор оновлений, продовжує голосувати, відставання не перевищує нормальних значень.
Ризики: на testnet — нульові фінансові, але ви можете втратити час на повторну синхронізацію, якщо леджер буде пошкоджено.
- Зафіксуйте поточний стан:
solana slot --url https://api.testnet.solana.com
agave-validator --version
solana validators --url https://api.testnet.solana.com | grep <ваш-identity-pubkey>
- Зупиніть валідатор коректно:
Використовуйте `systemctl stop agave-validator` або `Ctrl+C` у сесії. Не вбивайте процес через `kill -9` — це може пошкодити леджер.
- Зробіть резервну копію леджера (обов'язково):
cp -r /testnet/ledger /testnet/ledger.backup-pre-upgrade
Якщо леджер великий, скопіюйте лише останні snapshot-файли та `rocksdb` — це значно швидше і достатньо для відкату.
- Встановіть цільову версію:
Завантажте бінарний файл цільової версії з релізу в репозиторії Agave. Перевірте хеш суми (sha256sum) з офіційним релізом.
sha256sum agave-install.tar.gz
# порівняйте з хешем із GitHub Release- Запустіть валідатор на тій самій конфігурації:
Використовуйте ідентичні прапорці запуску. Додайте `--no-snapshot-fetch` лише якщо ви хочете примусово перевірити відновлення з банківських файлів без snapshot — це повільніше, але дає глибшу перевірку.
- Спостерігайте за логами:
journalctl -u agave-validator -f --no-pager
Шукайте: `voted for slot`, відсутність `bank frozen` або `fatal error`, нормальний прогрес слотів.
Відкат: якщо валідатор не стартує або логи показують помилки, зупиніть процес, видаліть оновлений леджер і відновіть з резервної копії:
rm -rf /testnet/ledger
mv /testnet/ledger.backup-pre-upgrade /testnet/ledger
Поверніть попередню версію бінарного файлу та запустіть валідатор.
Моніторинг метрик після оновлення
Після успішного старту валідатора на новій версії необхідно контролювати ключові метрики протягом щонайменше 2–4 годин (на testnet) або повного епохального циклу.
Ключові метрики для відстеження:
- Root slot vs. slot height кластера: різниця не має перевищувати 50–100 слотів на testnet. Більше — ознака відставання.
- Vote latency: час між отриманням слота та голосуванням. Норма на testnet — до 200 мс.
- Skipped slots: частка пропущених слотів. Значення вище 5% сигналізує про проблему.
- Пам'ять (RSS): різкий стрибок порівняно з попередньою версією може вказувати на витік.
- CPU utilization: стабільність навантаження, відсутність шпилів.
- Довжина черги транзакцій (transaction queue): зростання без відповідного зростання TPS — потенційний регрес.
Інструменти:
solana show-validators --url https://api.testnet.solana.com— перевірка delinquency статусу.solana block-production --url https://api.testnet.solana.com— статистика виробництва блоків.- Prometheus + Grafana з експортером метрик Agave — для трендового моніторингу.
watch -n 5 "solana slot --url https://api.testnet.solana.com"— швидка перевірка прогресу слотів.
Типові аномалії та їхнє значення:
- Валідатор голосує, але не виробляє блоки — можливо, змінилися критерії лідерства в новій версії. Перевірте release notes.
- Періодичні паузи в логах на 10–30 секунд — можливий проблемний GC або блокування в новому коді.
- Різке зростання розміру snapshot — зміна в стратегії компакції. Не є помилкою, але важливо для планування дискового простору на production.
Фіксація результатів тестування
Без письмової фіксації тест не є завершеним. Запишіть наступне:
- Версія «звідки» і «куди»: точні хеші комітів або теги релізів.
- Кластер: testnet (або devnet, якщо використовувався).
- Час тесту: дата, час UTC, тривалість спостереження.
- Стартові метрики: root slot, delinquency статус, розмір RSS на момент старту.
- Метрики після оновлення: максимальна vote latency, середня різниця root-slot, пікове RSS, відсоток skipped slots.
- Аномалії: що спостерігалося, чи відтворюється, чи впливає на production-випадок.
- Вердикт: «Схвалено для production», «Схвалено з умовами», «Не схвалено» з обґрунтуванням.
Приклад формату вердикту:
Версія: v1.18.x → v1.19.y. Кластер: testnet. Тривалість: 3 години. Vote latency: 80–140 мс (норма). Skipped slots: 0.3%. RSS: зріс на 8% (очікувано з release notes). Аномалій не виявлено. Вердикт: схвалено для production.
Зберігайте ці записи в системі змін (change management) або внутрішньому runbook-репозиторії команди. Це критично для постмортему, якщо щось піде не так на mainnet.
Перехід від тесту до production
Успішне тестування на testnet не означає автоматичного застосування на mainnet. Дотримуйтесь послідовності:
- Перевірте release notes повністю. Зверніть увагу на розділи «Breaking Changes», «Migration», «Configuration». Інформація, не проявлена на testnet через відмінності навантаження, може бути описана саме там.
- Перевірте сумісність конфігурації. Деякі оновлення додають нові обов'язкові прапорці або змінюють значення за замовчуванням. Порівняйте `--help` старої та нової версій.
- Перевірте залежності. Нова версія може вимагати оновленого `solana-cli`, змінених системних бібліотек або іншої версії Rust toolchain для локальних збірок.
- Сплануйте вікно оновлення на mainnet. Враховуйте поточну епоху — не оновлюйте в останні слоти епохи, коли відбувається обчислення винагород. Оптимально — на початку нової епохи.
- Застосуйте ту саму процедуру резервування. Повна копія snapshot-файлів та rocksdb перед оновленням на production є обов'язковою.
- Майте готовий відкат. Попередня версія бінарного файлу має бути збережена на диску. Час відкату на production має бути не більшим за 5 хвилин — кожна хвилина delinquency на mainnet означає втрату винагород.
Якщо ваша інфраструктура передбачає резервний вузол, логіка оновлення змінюється: спочатку оновлюється резервний вузол, він проходить перевірку на mainnet-навантаженні, і лише після підтвердження його стабільності оновлюється основний. Цей підхід детально розглянуто в окремому матеріалі про роботу з резервним вузлом під час оновлення.