Операційні вимоги для «Чому валідатор став delinquent: причини та рішення» перевірено 2 серпня 2026 року. Для production використовуйте тільки реліз Agave, рекомендований для конкретного кластера, і звіряйте параметри з agave-validator --help . Офіційні вимоги Anza на цю дату орієнтують операторів на Ubuntu 24.04, щонайменше 12 ядер/24 потоки, 256 ГБ RAM, окремі швидкі NVMe та симетричний канал від 2 Гбіт/с; це рекомендації, а не гарантія достатньої продуктивності.

Що таке delinquent статус

Delinquent — це стан валідатора в мережі Solana, за якого він перестає голосувати за слоти протягом певного періоду (історично — близько 150 епох, точне значення залежить від поточної конфігурації кластера) і тимчасово виключається з активного набору. Валідатор залишається в реєстрі, його стейк не конфіскується, але він не бере участі в консенсусі й не отримує винагород.

Це не остаточне покарання, а захисний механізм мережі: якщо нода не підтверджує слоти, її усувають від прийняття рішень, щоб не гальмувати фіналізацію.

Як delinquent впливає на rewards

Поки валідатор у статусі delinquent, він не отримує інфляційних винагород. Стейк делегаторів і власна частка оператора не зменшуються — вони просто не зростають. Після відновлення голосування винагороди поновлюються, але втрачений період не компенсується.

Додатковий наслідок — делегатори бачать нульову або від'ємну APY у дашбордах і можуть почати відстегувати токени. Чим довше валідатор проводить у delinquent, тим вищий ризик відтоку делегованого стейку.

Основні причини delinquent

Недостатня потужність сервера

Solana генерує слоти кожні ~400 мілісекунд. Якщо процесор не встигає обробляти транзакції, валідатор починає пропускати голоси. Типові ознаки: стабільно високе навантаження CPU (понад 80–90% протягом тривалого часу), зростання черги потоків у журналі.

Щоб перевірити гіпотезу, проаналізуйте метрики CPU за останні години перед переходом у delinquent. Якщо сервер відповідає мінімальним вимогам, але навантаження хронічно високе — причини може бути дві: або обчислювальна ємності дійсно мало для поточного розміру кластера, або щось споживає ресурси поза процесом валідатора.

Мережеві проблеми

Валідатор має отримувати та відправляти голоси в межах одного слота. Якщо джиттер або втрати пакетів перевищують допустимі пороги, голоси не фіналізуються вчасно. Це може бути спричинено перевантаженням комутатора, проблемами на стороні хостинг-провайдера, неправильною конфігурацією MTU або навмисним обмеженням трафіку.

Для діагностики збережіть результати тривалого пінгу до кількох відомих нод кластера та перевірте, чи є періодичні сплески затримки.

Диск повний або NVMe зносився

Леджер і accounts-база зростають. Якщо розділ із ledger заповнюється, валідатор не може записувати нові слоти і зупиняє голосування. Якщо NVMe-накопичувач вичерпав ресурс перезапису (SMART-атрибут Percentage Used наближається до 100%), швидкість запису різко падає, що також призводить до пропусків.

Перевірте вільне місце на розділі з ledger та стан SMART для NVMe. Якщо диск заповнений — це пряма причина. Якщо SMART показує критичний знос — диск потребує заміни, інакше проблеми повторюватимуться.

Затримка оновлення

Кластер Solana оновлюється. Якщо валідатор працює на версії, яка вже не сумісна з поточним форком, він не зможе синхронізуватися й голосувати. Оновлення зазвичай анонсуються заздалегідь, але пропущене вікно оновлення призводить до автоматичного переходу в delinquent.

Перевірте актуальну версію на офіційних каналах оголошень кластера та порівняйте з версією на вашому сервері.

Як перевірити delinquent статус

Передумови: встановлений CLI-клієнт solana, доступ до інтернету, identity-публічний ключ валідатора.

Очікуваний результат: ви отримаєте підтвердження статусу та епоху, з якої валідатор перестав голосувати.

Основна команда:

solana validators --url <your-rpc-endpoint> | grep <your_identity_pubkey></your_identity_pubkey></your-rpc-endpoint>

У виводі зверніть увагу на стовпець Delinquent. Якщо значення Yes — статус підтверджено. Також зафіксуйте значення у стовпці Last Vote — це останній слот, за який валідатор проголосував, і він допоможе зрозуміти, коли саме почалася проблема.

Додатково перевірте локальні журнали валідатора за ознаками помилок:

journalctl -u agave-validator --since "2 days ago" | grep -iE "error|warn|skip|vote"

Ризики: команда лише читає дані з кластера, не змінює стан.

Кроки для виходу з delinquent

Передумови: ви визначили причину (розділи вище) і усунули її — сервер має достатні ресурси, мережа стабільна, на диску є вільне місце, версія клієнта актуальна.

Очікуваний результат: валідатор відновлює голосування і повертається до активного набору.

  1. Зупиніть процес валідатора, якщо він ще працює:
    sudo systemctl stop agave-validator
  2. Перевірте цілісність леджера (безпечна операція, лише читання):
    solana-ledger-tool verify --ledger /path/to/ledger
    Якщо верифікація не проходить — можливо, леджер пошкоджено. У такому разі потрібна відновна синхронізація з моменту останнього валідного слота. Дивіться окремий матеріал про міграцію ledger та accounts між клієнтами для детального покрокового опису.
  3. Запустіть валідатор:
    sudo systemctl start agave-validator
  4. Спостерігайте за журналами:
    journalctl -u agave-validator -f
    Шукайте повідомлення про початок голосування (voting) та відсутність критичних помилок.
  5. Дочекайтеся виходу з delinquent. Це не миттєвий процес: після відновлення стабільного голосування кластер переведе валідатор назад в активний набір. Час очікування залежить від поточної конфігурації кластера — перевірайте актуальні параметри в документації.

Попередження щодо руйнівних дій: якщо ви припускаєте, що леджер пошкоджено і плануєте видалити його для повної ресинхронізації — спочатку створіть резервну копію поточного стану. Видалення леджера без резерву означає, що відновлення займе значний час і залежить від доступності снепшотів та архівних нод.

Резервний шлях: якщо після усунення причини та перезапуску валідатор не виходить з delinquent протягом розумного часу — зупиніться, зафіксуйте журнали та зверніться до операційної спільноти кластера з конкретними даними: версія клієнта, ОС, останній проголосований слот, фрагменти журналів.

Запобігання повторному delinquent

Одноразове усунення причини не гарантує, що проблема не повернеться. Системний підхід до запобігання включає кілька рівнів.

  • Моніторинг ресурсів. Налаштуйте алерти на CPU, використання диска та мережеву затримку. Алерт має спрацьовувати до того, як параметр досягне критичного значення — наприклад, при 70% використання диска, а не при 99%.
  • Моніторинг голосування. Відстежуйте останній проголосований слот і порівнюйте з поточним слотом кластера. Розрив, що зростає — це пряма ознака майбутнього delinquent.
  • Автоматизація оновлень. Відстежуйте анонси оновлень кластера та готуйте реліз заздалегідь на тестовому стенді. Не чекайте на останню хвилину.
  • Резервування дискового простору. Тримайте запас не менше 20–30% від об'єму розділу з ledger. Зростання леджера непередбачуване і залежить від активності кластера.
  • Періодична перевірка SMART. Для NVMe-накопичувачів налаштуйте регулярне зчитування SMART-атрибутів і алерт на наближення критичного зносу.

Наступний логічний крок після стабілізації валідатора — детальний аналіз skip rate, який допоможе виявити приховані проблеми продуктивності ще до того, як вони призведуть до повторного delinquent. Це розглядається в окремому матеріалі.

Джерела