Голосування валідатора в Solana — це не абстракція, а реальні транзакції, за кожну з яких сплачується комісія. Ці витрати (vote costs) є постійним операційним навантаженням, що прямо зменшує чистий дохід валідатора незалежно від розміру стейку. Нижче — механіка розрахунку, поточні обмеження та пропозиції щодо зниження навантаження.

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

Що таке vote costs

Визначення: ресурси, витрачені на відправку vote-транзакцій

Vote costs — це сукупність обчислювальних ресурсів та комісій, які валідатор витрачає на відправку vote-транзакцій у рамках консенсусу Tower BFT. Кожна vote-транзакція є звичайною транзакцією в мережі Solana, яка проходить через стандартний пайплін обробки: отримання, десеріалізація, перевірка підпису, виконання у Vote program, запис у банк та гешування.

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

Чому голосування коштує: compute units та комісії

Кожна vote-транзакція споживає два типи ресурсів:

  • Compute Units (CU) — обчислювальні одиниці, виділені на виконання Vote program. Кількість CU на один голос залежить від версії клієнта та оптимізацій у Vote program. Зміни в цьому параметрі відбуваються через оновлення клієнта agave (раніше — validator).
  • Базова комісія за підпис (signature fee) — фіксована сума в lamports за кожен підпис у транзакції. Станом на поточну специфікацію протоколу ця величина становить 5000 lamports за підпис. Оскільки vote-транзакція містить один підпис, це мінімальна неминуча витрата за кожен голос.

Додатково, у періоди високого завантаження мережі до базової комісії додається плата за compute units, розрахована за поточною ціною compute unit price (пріоритетна комісія). У спокійні періоди ця складова мінімальна або відсутня.

Як розраховуються vote costs

Кількість голосів за слот та епоху

Механіка голосування визначається алгоритмом Tower BFT:

  • Валідатор відправляє один голос на кожен слот, який він успішно обробив і вважає валідним продовженням канонічного ланцюжка.
  • У нормальних умовах валідатор голосує на переважну більшість слотів. Пропуски можливі під час пропуску слотів (skipped slots), рестарту ноди або коротких відключень.
  • Кількість слотів в одній епосі в Solana — фіксована величина: 432 000 слотів.
  • Тривалість епохи становить приблизно 2–3 доби (залежить від фактичного часу обробки слотів мережею).

Таким чином, за одну епоху валідатор відправляє порядку сотень тисяч vote-транзакцій. Точна кількість залежить від аптайму ноди та стану мережі в конкретну епоху.

Залежність від кількості валідаторів та активності мережі

Формула вартості одного голосу:

Vote cost = (CU per vote × compute unit price) + base signature fee

Де:

  • CU per vote — кількість обчислювальних одиниць, споживаних Vote program за один виклик. Цей параметр визначається реалізацією Vote program у поточній версії клієнта. Для отримання актуального значення слід звертатися до вихідного коду agave або вимірювати експериментально на тестовій мережі.
  • Compute unit price — динамічна ціна за один CU у lamports, що формується ринком транзакцій у поточному слоті. У слотах з низьким завантаженням наближається до нуля.
  • Base signature fee — 5000 lamports (протокольна константа).

Залежність від кількості валідаторів опосередкована: більше валідаторів означає вищу загальну активність мережі, що може підвищувати compute unit price. Проте базова складова (5000 lamports за підпис) незмінна незалежно від кількості учасників.

Для розрахунку сумарних vote costs за епоху:

Total vote costs per epoch = votes cast × vote cost

Оскільки точна кількість відправлених голосів варіюється, оператори валідаторів зазвичай оцінюють цей показник емпірично — за даними власних логів або через аналіз історії транзакцій vote-акаунта за допомогою RPC-викликів.

Вплив на економіку

Яку частку доходу поглинають vote costs

Vote costs є витратою, що вираховується з валового доходу валідатора до розподілу між делегаторами. Структура впливу нерівномірна:

  • Для великих валідаторів (високий стейк): відносна частка vote costs у загальному доході менша, оскільки інфляційна винагорода та block revenue масштабуються зі стейком, а vote costs — ні. Голосування коштує однаково незалежно від того, чи за вами стоїть 100 SOL чи 1 000 000 SOL.
  • Для малих валідаторів (низький стейк): vote costs становлять значно більшу частку доходу, що створює економічний бар'єр входу та підвищує порог рентабельності.
  • Для делегаторів: vote costs непрямо впливають на їхню чисту прибутковість, оскільки валідатор знижує комісію або зберігає менший маржинальний дохід.

Важливо розуміти: vote costs не є додатковим податком поверх інфляційної емісії. Це частина інфляційних SOL, що повертається в мережу через механізм спалювання комісій (fee burn). Ці SOL вилучаються з обігу, що впливає на загальну динаміку пропозиції токена.

Пропозиції щодо зменшення vote costs (SIMD)

Проблема vote costs є предметом активних обговорень у рамках Solana Improvement Proposals (SIMD). Станом нині жодна з наведених нижче пропозицій не є остаточно активованою в mainnet-beta без застережень. Статус кожної пропозиції треба перевіряти безпосередньо в репозиторії SIMD перед прийняттям операційних рішень:

  • SIMD-0096 (Vote Transaction Cost Reduction) — пропонує знизити кількість compute units, що споживаються Vote program за один виклик. Це прямо зменшить змінну складову vote cost, особливо в періоди високого завантаження мережі.
  • Обговорення нульового тарифу для vote-транзакцій — концептуальна пропозиція повністю звільнити vote-транзакції від сплати комісій, оскільки голосування є критичною інфраструктурною функцією, а не комерційною транзакцією. Ця ідея має значні наслідки для моделі стимулів та безпеки мережі й залишається на стадії дискусії.
  • Оптимізація частоти голосування — альтернативний підхід, що полягає не у зменшенні вартості одного голосу, а у зменшенні кількості голосів без втрати безпеки консенсусу (наприклад, голосування не на кожен слот, а з певним кроком за умови збереження властивостей Tower BFT).

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

Для практичної оцінки vote costs вашого валідатора рекомендується використовувати експорт історії транзакцій vote-акаунта з подальшим агрегуванням комісій за епохи. Це дасть точну емпіричну картину, незалежну від теоретичних оцінок.

Джерела