Identity та vote account — це два окремі ключові записи, без яких валідатор Solana не може приєднатися до кластера та отримувати винагороди. Помилка на етапі їх створення або витік приватних ключів означає втрату контролю над нодою без можливості відновлення. Нижче — покрокова інструкція з генерації, захисту та прив’язки цих облікових записів.

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

Що таке identity account та vote account

Identity account — це ключова пара (public key + private key), що слугує унікальним ідентифікатором вашого валідатора в кластері. Всі інші учасники бачать саме цю публічну адресу у списку валідаторів. Приватний ключ identity обов’язково має бути на сервері, де працює нода, оскільки солана-клієнт підписує ним блоки та голоси в реальному часі.

Vote account — це окремий програмний обліковий запис (Vote Program), який фіксує історію голосування вашого валідатора: за які слоти ви проголосували, скільки кредитів накопичено в кожну епоху. Саме за цими кредитами розраховуються винагороди. Vote account не підписує блоки — він лише отримує та зберігає інформацію про голоси.

Розділення цих двох записів дає можливість делегувати право голосу (authorized voter) іншому ключу, не розкриваючи identity-ключ ноди, та змінювати авторизованого голосувальника без перезапуску валідатора.

Генерація ключових пар

Передумови: сервер із попередньо налаштованим середовищем (див. Як підготувати Linux для валідатора Solana), встановлений solana-cli. Перевірте версію клієнта командою solana --version та переконайтеся, що вона відповідає версії кластера, до якого ви підключаєтесь (mainnet-beta, testnet або devnet).

Генеруйте обидві ключові пари на безпечній машині, а не на продакшн-сервері валідатора. Ідеально — на повністю відключеному від мережі пристрої (air-gapped). Якщо це неможливо, мінімум — на ізольованій машині, яка не має доступу до інтернету під час генерації.

Генерація identity keypair:

  1. Створіть каталог для ключів:
    mkdir -p ~/validator-keys
  2. Згенеруйте ключову пару:
    solana-keygen new -o ~/validator-keys/identity.json
  3. Клієнт запропонує ввести парольну фразу (bip39 mnemonic) або використовувати випадковий seed. Виберіть mnemonic і надійно запишіть 24 слова на паперовий носій.

Генерація ключової пари для vote account:

  1. solana-keygen new -o ~/validator-keys/vote-account.json
  2. Аналогічно запишіть mnemonic для цієї ключової пари. Використовуйте інший seed, ніж для identity.

Очікуваний результат: у каталозі ~/validator-keys/ з’являться два файли .json, кожен із яких містить 64 байти приватного ключа. Публічні адреси можна переглянути командами:

  • solana-keygen pubkey ~/validator-keys/identity.json
  • solana-keygen pubkey ~/validator-keys/vote-account.json

Запишіть обидві публічні адреси — вони знадобляться на наступних етапах.

Захист ключів: offline, hardware wallet, vault

Offline-генерація (air-gapped)

Найнадійніший підхід. Використовується чиста машина (Live USB із Ubuntu або аналогічним дистрибутивом) без мережевого інтерфейсу. Після генерації ключі записуються на зашифрований USB-накопичувач або друкуються у вигляді QR-кодів. Приватні ключі у цифровому вигляді ніколи не потрапляють на машину, підключену до інтернету.

Hardware wallet (Ledger)

Використання Ledger як identity-ключа усуває ризик витоку приватного ключа з файлової системи сервера. Солана-клієнт взаємодіє з Ledger через HID, підписуючи транзакції на самому пристрої.

Обмеження: Ledger має підтримувати дериваційний шлях Solana (m/44'/501'/...'). Перевірте актуальну сумісність вашої версії прошивки Ledger та solana-cli у офіційній документації, оскільки ці параметри змінюються.

Публічну адресу Ledger можна отримати командою (пристрій має бути підключений та розблокований):
solana-keygen pubkey usb://ledger

Vault-рішення

Організації з інфраструктурними стандартами можуть використовувати HashiCorp Vault, AWS KMS або аналогічні HSM-сервіси для зберігання приватних ключів. У цьому випадку ключ ніколи не існує у вигляді файлу на диску — клієнт звертається до vault за підписом. Це вимагає кастомної інтеграції або використання відповідних плагінів до солана-клієнта. Конкретна конфігурація залежить від обраного vault-провайдера та виходить за межі цієї інструкції.

Створення vote account через CLI

Vote account створюється транзакцією в мережі. Для цього потрібна машина з доступом до RPC-вузла кластера та ключова пара, що сплачує комісію за створення обліковогоого запису (rent-exempt minimum).

Передумови:

  • Публічний ключ identity (з файлу або Ledger)
  • Файл ключової пари vote account (vote-account.json)
  • Фінансовий ключ (keypair, з якого сплачуватиметься створення vote account) із достатнім балансом SOL
  • Доступ до RPC-кластера (mainnet-beta, testnet або devnet)

Базова команда для створення vote account:

solana create-vote-account ~/validator-keys/vote-account.json IDENTITY_PUBKEY --fee-payer ~/validator-keys/funding.json

Замість IDENTITY_PUBKEY підставте публічну адресу вашого identity. Якщо identity зберігається на Ledger:

solana create-vote-account ~/validator-keys/vote-account.json usb://ledger --fee-payer ~/validator-keys/funding.json

Клієнт виведе деталі транзакції, включно з вартістю створення облікового запису (rent-exempt reserve). Переконайтеся, що сума коректна, перед тим як підтверджувати на Ledger (якщо використовується).

Очікуваний результат: у журналі з’явиться підпис транзакції (signature), а vote account стане видимим у кластері.

Авторизація vote account для identity

Після створення vote account потрібно вказати, хто має право голосувати від його імені (authorized voter). За замовчуванням це ключ, з якого створювався vote account, але для правильної архітектури варто призначити identity як authorized voter.

Попередження: команда vote-authorize-voter є руйнівною в тому сенсі, що вона миттєво відкликає попередній авторизований ключ. Якщо ви помилково вкажете неправильну адресу, ви втратите можливість голосувати, поки не призначите новий дійсний ключ.

Команда авторизації:

solana vote-authorize-voter VOTE_ACCOUNT_PUBKEY CURRENT_VOTER_PUBKEY NEW_VOTER_PUBKEY --fee-payer ~/validator-keys/funding.json

Якщо vote account щойно створено і authorized voter збігається з ключем у vote-account.json:

solana vote-authorize-voter VOTE_ACCOUNT_PUBKEY $(solana-keygen pubkey ~/validator-keys/vote-account.json) IDENTITY_PUBKEY --fee-payer ~/validator-keys/funding.json

Резервний шлях (відкат): якщо ви помилилися з адресою нового voter, використайте той самий ключ, який щойно став authorized voter, щоб призначити правильний. Тобто відкат виконується тією ж командою, але з поточним авторизованим ключем як CURRENT_VOTER_PUBKEY. Саме тому завжди переконуйтеся, що ви контролюєте новий ключ до виконання команди.

Перевірка прив’язки identity → vote account

Після створення та авторизації переконайтеся, що vote account коректно прив’язаний до вашого identity:

solana vote-account VOTE_ACCOUNT_PUBKEY

Очікуваний вивід містить такі поля:

  • Account Balance: баланс vote account (має дорівнювати rent-exempt minimum)
  • Validator Identity: ваша публічна адреса identity
  • Authorized Voter: має збігатися з identity (якщо ви виконали попередній крок)
  • Epoch Credits: 0 (ще не голосували)
  • Recent Votes: порожній масив

Якщо поле Validator Identity не збігається з вашим identity — vote account створено з неправильним параметром. Такий vote account не можна виправити: його треба залишити (кошти не повертаються) і створити новий з правильною адресою identity.

Додатково перевірте стан через RPC-запит, якщо CLI недоступний:

curl -s -X POST http://RPC_ENDPOINT:8899 -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1,"method":"getVoteAccounts","params":[{"votePubkey":"VOTE_ACCOUNT_PUBKEY"}]}' | python3 -m json.tool

У відповіді перевірте, що поле nodePubkey збігається з вашим identity.

Резервне копіювання ключів

Файли .json із приватними ключами — єдиний спосіб відновити доступ до вашого валідатора у разі виходу сервера з ладу. Без них ноду неможливо перезапустити з тим самим identity.

Правила резервного копіювання:

  • Мінімум дві копії на різних фізичних носіях у різних локаціях.
  • Шифрування обов’язкове. Використовуйте GPG з симетричним шифруванням або age:
    age -p -o identity.json.age ~/validator-keys/identity.json
    age -p -o vote-account.json.age ~/validator-keys/vote-account.json
  • Mnemonic-фрази (24 слова для кожної ключової пари) зберігайте окремо від зашифрованих файлів — на папері або металевій плиті у фізично захищеному місці.
  • Не зберігайте незашифровані .json у хмарних сховищах, на робочих станціях чи в системах контролю версій.
  • Перевірте відновлення: після створення резервної копії розшифруйте її на іншій машині та порівняйте публічний ключ з оригіналом:
    age -d identity.json.age | solana-keygen pubkey

Якщо ви використовуєте Ledger як identity, резервна копія — це seed-фраза Ledger (24 слова), з якої можна відновити пристрій. У цьому випадку файлу identity.json не існує, але mnemonic Ledger має бути збережений з тією ж суворістю.

Наступний крок — повна перевірка створених облікових записів перед запуском ноди. Перейдіть до Як перевірити identity, vote account та authorized voter перед запуском, щоб переконатися, що всі параметри відповідають очікуваним.

Джерела