Ця інструкція описує, як підтвердити, що три критичні адреси вашого валідатора — identity, vote account та authorized voter — належать саме вам, правильно налаштовані та готові до роботи в мережі. Перевірка виконується через CLI до першого підключення ноди до кластера і виключає ризик запуску з чужими або некоректними ключами.

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

Середовище перевірки: клієнт — Agave (перевірте актуальну стабільну версію у репозиторії проєкту перед виконанням команд); кластер — mainnet-beta; ОС — Ubuntu 24.04 LTS (адаптуйте шляхи під своє середовище); актуальність команд — верифікуйте самостійно, оскільки інтерфейс CLI може змінюватися між релізами.

Які адреси й ролі потрібно звірити

Перед запуском валідатора ви маєте чітко розрізняти чотири ключові сутності та знати, які саме публічні адреси відповідають кожній з них:

  • Identity (identity keypair) — головний ключ валідатора. Це адреса, під якою нода представляється в мережі. Вона фігурує в gossip, у списку валідаторів і в усіх зовнішніх реєстрах. Втрата цього ключа означає втрату контролю над нодою.
  • Vote account — спеціалізований рахунок, який фіксує голоси вашого валідатора за слоти та епохи. Створюється окремо і прив'язується до identity. Саме за цим рахунком відстежується ваша активність як валідатора.
  • Authorized voter — адреса, яка має право підписувати голоси від імені vote account. За замовчуванням це може бути той самий identity keypair, але ви можете делегувати це окремому ключу для підвищення безпеки.
  • Withdraw authority — адреса, яка має право виводити SOL з vote account. Цей ключ має зберігатися офлайн і ніколи не потрапляти на сервер валідатора.

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

Перевірка identity та vote account через CLI

Усі перевірки виконуються через solana-cli. Перед початком переконайтеся, що CLI вказує на правильний кластер:

solana config get

Очікуваний результат: поле RPC URL має вказувати на mainnet-beta. Якщо це не так, встановіть правильне значення:

solana config set --url mainnet-beta

Визначення адреси identity

Вкажіть CLI на файл вашого identity keypair і отримайте публічну адресу:

solana address -k /path/to/identity-keypair.json

Очікуваний результат: CLI виведе публічний ключ у форматі Base58 (рядок із літер і цифр). Запишіть цю адресу — вона є вашим identity у мережі.

Ризик: якщо ви вкажете неправильний файл ключа, усі подальші перевірки будуть проведені щодо чужого identity. Переконайтеся, що шлях до файлу точний.

Перевірка стану vote account

Вкажіть CLI на файл vote-account keypair і отримайте його адресу:

solana address -k /path/to/vote-account-keypair.json

Тепер запитайте мережу про стан цього vote account:

solana vote-account VOTE_ACCOUNT_ADDRESS

Очікуваний результат — структурований вивід із такими полями, які потрібно звірити:

  • Account — має збігатися з адресою, яку ви отримали на попередньому кроці.
  • Identity — має збігатися з адресою вашого identity keypair.
  • Authorized Voter — має збігатися з ключем, який ви призначили для голосування.
  • Withdraw Authority — має збігатися з вашим офлайн-ключем виведення.
  • Node — має бути порожнім або містити вашу адресу identity (якщо нода вже реєструвалася).

Якщо поле Identity не збігається з вашим identity keypair — vote account прив'язаний до іншого валідатора. Це критична невідповідність, яку треба вирішити до запуску.

Перевірка authorized voter та withdraw authority

Ці дві ролі безпосередньо впливають на безпеку вашого стейкінгу та можливість керувати коштами на vote account.

Authorized voter

Отримайте адресу ключа, який ви плануєте використовувати як authorized voter:

solana address -k /path/to/authorized-voter-keypair.json

Звіріть цю адресу з полем Authorized Voter у виводі команди solana vote-account. Якщо адреси не збігаються, ваш валідатор не зможе підписувати голоси, і нода не буде брати участь у консенсусі.

Типова конфігурація: для першого запуску authorized voter часто збігається з identity keypair. Це спрощує налаштування, але знижує безпеку — якщо identity скомпрометовано, атакуючий отримує і право голосу. Розділення цих ключів рекомендується для продакшн-нод.

Withdraw authority

Отримайте адресу ключа withdraw authority:

solana address -k /path/to/withdraw-authority-keypair.json

Звіріть її з полем Withdraw Authority у виводі solana vote-account.

Критичне правило: файл withdraw-authority-keypair.json ніколи не має знаходитися на сервері валідатора. Зберігайте його на зашифрованому офлайн-носії. Якщо цей ключ потрапить на сервер, скомпрометування сервера означатиме втрату коштів з vote account.

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

solana vote-authorize-withdrawer VOTE_ACCOUNT_ADDRESS --new-withdraw-authority /path/to/new-withdraw-keypair.json

Резервний шлях: перед виконанням обов'язково перевірте адресу нового ключа командою solana address -k і переконайтеся, що маєте надійну резервну копію як старого, так і нового ключа. Після підтвердження транзакції відкат неможливий.

Типові помилки перед першим запуском

  • Використання ключів від testnet або devnet на mainnet-beta. Ключі, згенеровані в тестових кластерах, технічно можуть існувати в mainnet, але vote account, створений в іншому кластері, не буде існувати в mainnet-beta. Результат — нода не зможе голосувати. Завжди створюйте окремі ключі для кожного кластера.
  • Збіг імен файлів, але різний вміст. Якщо ви перейменували файл ключа або скопіювали його в іншу директорію без перевірки контрольної суми, ви можете працювати з неправильним ключем. Порівняйте хеші файлів (sha256sum) між оригіналом і копією.
  • Authorized voter не збігається з жодним доступним ключем. Це трапляється, коли vote account створювався з одним authorized voter, а на сервер потрапив інший файл ключа. Нода запуститься, але в журналах з'являться помилки підпису голосів.
  • Withdraw authority на сервері. Навіть якщо ви не плануєте виводити кошти, наявність цього ключа на сервері створює вектор атаки. Перевірте, що цей файл відсутній у файловій системі ноди.
  • Ігнорування поля Node у виводі vote-account. Якщо поле Node вже містить якусь адресу, відмінну від вашого identity, це означає, що vote account вже прив'язаний до іншої ноди. Вам потрібен окремий vote account.
  • Права доступу до файлів ключів. Якщо identity-keypair.json чи authorized-voter-keypair.json читаються іншими користувачами системи, будь-який процес на сервері може викрасти ключ. Перевірте права командою ls -la і встановіть chmod 600 з правильним власником.

Контрольний список перед підключенням до mainnet-beta

Пройдіть за кожним пунктом і підтвердіть виконання. Жоден пункт не можна пропускати.

  1. Кластер CLI — solana config get показує RPC URL mainnet-beta.
  2. Identity адреса — solana address -k identity-keypair.json повертає очікуваний публічний ключ.
  3. Vote account адреса — solana address -k vote-account-keypair.json повертає очікуваний публічний ключ.
  4. Vote account у мережі — solana vote-account VOTE_ACCOUNT_ADDRESS повертає валідний результат, а не помилку "Account not found".
  5. Identity у vote account — поле Identity у виводі vote-account збігається з адресою вашого identity keypair.
  6. Authorized voter — поле Authorized Voter збігається з адресою ключа, який є на сервері.
  7. Withdraw authority — поле Withdraw Authority збігається з адресою вашого офлайн-ключа, і цей файл відсутній на сервері.
  8. Поле Node — порожнє або містить вашу адресу identity. Якщо містить чужу — зупиніться і створіть новий vote account.
  9. Права доступу — права до identity-keypair.json та authorized-voter-keypair.json обмежені (600), власник — користувач, від імені якого запускається валідатор.
  10. Резервні копії — всі ключові файли (identity, vote account, authorized voter, withdraw authority) мають зашифровані резервні копії на окремому носії, незалежному від сервера валідатора.

Після підтвердження всіх пунктів ваші ключі звірені з мережею, ролі розподілені коректно, і ви можете переходити до встановлення та запуску ноди валідатора.

Джерела