Статус клієнтів для «Протокол Solana: клієнти, консенсус, MEV та економіка мережі» перевірено 2 серпня 2026 року. Frankendancer — гібрид Agave/Firedancer — працює на mainnet-beta щонайменше з 2025 року: офіційна програма делегування повідомляла майже про 200 валідаторів у вересні 2025 року. Повний Firedancer є окремою реалізацією мовою C; його поточне впровадження та частку валідаторів потрібно звіряти з офіційним звітом, а не з давніми твердженнями про «лише testnet».
Протокол Solana — це не лише швидкий ланцюжок, а складна система з кількома реалізаціями клієнтів валідатора, специфічним консенсусом, що еволюціонує, та економікою комісій, де MEV відіграє структурну роль. Ця сторінка дає структуроване розуміння того, як мережа функціонує на протокольному рівні: від обробки транзакцій до формування доходу валідатора. Операційні налаштування серверів розглядаються в розділі валідаторів, а користувацький стейкінг — у відповідному розділі.
Клієнти та різноманітність реалізацій
Навіщо Solana кілька клієнтів валідатора
Блокчейн із єдиним клієнтом валідатора несе системний ризик: баг у коді може зупинити всю мережу або створити вектор для атаки. Різноманітність реалізацій (client diversity) знижує цей ризик, оскільки критична вада в одному клієнті не обов'язково зачіпає інший. У Solana перехід до мультиклієнтного середовища є свідомим інженерним пріоритетом, а не маркетинговим кроком.
Agave, Frankendancer і Firedancer: порівняння клієнтів валідатора
Станом на сьогодні в екосистемі існують три основні напрямки реалізації клієнта валідатора. Agave — поточний робочий клієнт, що є форком оригінальної реалізації Solana Labs. Firedancer — повна альтернативна реалізація від Jump Crypto, написана мовою C. Frankendancer — гібридний підхід, який інтегрує окремі компоненти Firedancer у навколишню інфраструктуру Agave. Кожен із цих клієнтів має різну архітектурну базу, різний набір залежностей і різний профіль продуктивності.
Agave: архітектура, історія розвитку та поточний статус
Agave — це форк оригінального клієнта валідатора Solana Labs, написаного мовою Rust. Він успадкував всю архітектуру пайплайну обробки транзакцій: від прийому через TPU (Transaction Processing Unit) до Banking Stage та включення в блок. Agave є клієнтом, на якому зараз працює переважна більшість мережі. Його статус і актуальну версію слід перевіряти в офіційному репозиторії на GitHub, оскільки ця інформація змінюється з кожним релізом.
Firedancer: архітектура від Jump Crypto та етапи реалізації
Firedancer розробляється як повна реалізація клієнта валідатора з нуля мовою C. Архітектурно це принципово інший підхід: замість моделі з shared state і мьютексами, що характерна для Agave, Firedancer використовує модель з чітким розподілом потоків, власними аллокаторами та мінімізацією спільного стану. Реалізація планується у двох етапах: перший — заміна лише мережевого шару (net-utils), другий — повний валідаторний клієнт (FD ledger). Поточний статус кожного етапу варто перевіряти безпосередньо в репозиторії проєкту, оскільки він активно розвивається.
Frankendancer: гібридний підхід до клієнта валідатора
Frankendancer — це проміжний крок між Agave і повним Firedancer. Замість заміни всього клієнта, окремі високонавантажені компоненти з Firedancer (наприклад, мережевий шар) підключаються до решти інфраструктури Agave. Це дозволяє тестувати продуктивність окремих модулів Firedancer в реальному мережевому середовищі без необхідності повної реалізації ledger-частини. Для валідатора це означає можливість запустити гібридну конфігурацію, але таке рішення потребує уважного моніторингу сумісності.
Conformance testing: як перевіряється сумісність клієнтів Solana
Щоб різні клієнти могли безпечно працювати в одній мережі, Solana використовує підхід conformance testing — набір тестів, які верифікують, що різні реалізації виробляють ідентичні результати на однакових вхідних даних. Тести охоплюють криптографічні примітиви, обробку транзакцій, станні переходи та формування блоків. Успішне проходження conformance tests є обов'язковою умовою для того, щоб альтернативний клієнт вважався сумісним з мережею. Актуальний набір тестів і їхній статус доступні в репозиторії Solana.
Ризик єдиного клієнта: уроки з інших блокчейнових мереж
Досвід Ethereum та інших мереж наочно демонструє наслідки залежності від єдиної реалізації. Зупинки мережі через баги в клієнті (Geth у випадку Ethereum), затримки оновлень, які створюють вікна вразливості, та централізація розробки — все це реальні сценарії. У Solana, де лідерський розклад ротації створює додатковий тиск на продуктивність клієнта, наявність альтернативної реалізації є не просто страховкою, а необхідністю для довгострокової стабільності.
Мультиклієнтне середовище: Gossip, Banking та Turbine між різними реалізаціями
Коли в мережі працюють різні клієнти, вони повинні узгоджено взаємодіяти на кожному етапі пайплайну. Протокол Gossip (обмін інформацією про піри та лідерський розклад) використовує стандартизовані повідомлення, тому різні клієнти можуть виявляти одне одного. Banking Stage повинен обробляти транзакції однаково, що верифікується через conformance testing. Turbine (протокол розповсюдження блоків) працює на рівні пакетів даних і також залежить від бінарної сумісності форматів. Ключове питання для валідатора, який розглядає альтернативний клієнт: чи пройшов цей клієнт повний цикл conformance testing на поточній версії мережі.
Консенсус, Alpenglow і SIMD
Як працює поточний консенсус Solana
Консенсус Solana базується на моделі Proof of Stake з фіксованим лідерським розкладом (leader schedule). Кожен епоха (epoch) генерується розклад, який визначає, який валідатор є лідером для кожного слоту. Лідер має ексклюзивне право пропонувати блоки у своєму слоті. Інші валідатори голосують за блоки, і ці голоси формують ланцюжок підтверджень. Консенсус досягається, коли супермажоритарність стейку голосує за певний форк.
Tower Babel: механізм голосування та лідерства у Solana
Tower Babel — це конкретна реалізація консенсусу в Solana, натхненна алгоритмом Tower BFT. Кожен валідатор веде локальну «вежу» голосів: за кожен блок, за який він проголосував, валідатор записує висоту та форк. Правила вежі забороняють голосувати за конфліктні форки на тій самій висоті, що забезпечує безпеку. Лідерський розклад визначає, хто має право пропонувати блоки, а голоси інших валідаторів підтверджують ці блоки. Важливий нюанс: голосування коштує (vote costs), тому валідатор повинен балансувати між активною участю в консенсусі та витратами на голосування.
Що змінює Alpenglow
Alpenglow — це пропозиція щодо зміни механізму консенсусу Solana, яка знаходиться на стадії обговорення та розробки. Основна ідея — перехід від моделі з фіксованим лідерським розкладом до більш гнучкого підходу, де лідер обирається динамічно на основі попередніх голосів. Це потенційно дозволяє зменшити затримки, пов'язані з пропусканням слотів недоступним лідером, та покращити латентність підтвердження транзакцій. Alpenglow наразі не є активним консенсусом мережі — це пропозиція, статус якої варто перевіряти в актуальних SIMD-документах.
Що таке SIMD у Solana
SIMD (Solana Improvement Document) — це механізм формалізації пропозицій щодо змін у протоколі Solana, аналогічний EIP у Ethereum або BIP у Bitcoin. Кожен SIMD проходить визначений життєвий цикл: від ідеї (Draft) до обговорення, рецензування, прийняття та впровадження. SIMD не є автоматично активованою функцією — це документ, що описує пропоновану зміну, її мотивацію, технічні деталі та вплив на мережу.
Як відстежувати статус SIMD-пропозицій
Актуальний статус кожного SIMD можна перевірити в офіційному репозиторії SIMD на GitHub. Пропозиції мають чіткі маркери статусу: Draft, Review, Final, Implemented, Rejected тощо. Для валідатора критично важливо розуміти різницю між «Final» (схвалено до впровадження) та «Implemented» (вже працює в мережі). Деякі пропозиції можуть залишатися в статусі Review тривалий час або бути відхилені після тривалого обговорення.
SIMD-пропозиції, що впливають на валідаторів: огляд ключових
Серед SIMD-пропозицій, які безпосередньо зачіпають валідаторів, варто виділити кілька напрямків. Пропозиції щодо змін у механізмі голосування та комісіях за голоси впливають на економіку валідатора. Пропозиції щодо змін у пайплайні транзакцій можуть вимагати оновлення інфраструктури. Пропозиції щодо консенсусу (включно з Alpenglow) змінюють саму логіку участі валідатора в мережі. Конкретні номери SIMD та їхній поточний статус варто перевіряти в репозиторії, оскільки ця інформація змінюється.
Пайплайн обробки транзакцій: від TPU до включення в блок
Транзакція в Solana проходить кілька етапів обробки. Спочатку вона потрапляє через TPU (Transaction Processing Unit) — мережевий інтерфейс, оптимізований для прийому великої кількості транзакцій. Далі транзакція потрапляє у Fetch Stage, де вона десеріалізується та верифікується (перевірка підпису, перевірка формату). Після цього — Signature Stage, де підписи верифікуються паралельно на GPU. Далі — Banking Stage, де транзакція виконується (змінюється стан), і нарешті — Blocktree Stage, де сформований блок записується в локальне сховище. Розуміння цього пайплайну важливе для діагностики проблем: затримка на будь-якому етапі впливає на загальну продуктивність вузла.
Forks та rollback: як консенсус вирішує конфлікти ланцюжків
Оскільки мережа асинхронна, різні валідатори можуть бачити різні версії ланцюжка (форки). Консенсус вирішує конфлікти через механізм голосування: коли супермажоритарність стейку голосує за певний форк, інший форк вважається відкинутим (orphaned). Валідатор, який працював на «програному» форку, виконує rollback — відкочує свій стан до спільного предка і перемикається на переможний форк. Це означає, що деякі транзакції, які валідатор вже обробив, можуть бути скасовані на рівні ланцюжка (хотя самі транзакції залишаються валідними і можуть бути повторно включені).
Комісії, Jito та MEV
Як працюють priority fees
У Solana існує двокомпонентна модель комісій за транзакцію: base fee (базова комісія, що спалюється) та priority fee (пріоритетна комісія, що йде лідеру слота). Base fee є фіксованою мінімальною комісією за одиницю обчислювального бюджету. Priority fee — це добровільна надбавка, яку відправник транзакції вказує, щоб підвищити ймовірність включення свій транзакції в блок під час навантаження. Лідер сортує транзакції у своєму пулі за співвідношенням priority fee до обчислювального бюджету, віддаючи пріоритет більш прибутковим. Для валідатора-лідера priority fees є прямим джерелом доходу.
Що таке Jito bundles
Jito bundles — це механізм, який дозволяє відправнику групувати кілька транзакцій в атомарний пакет із вказаною tip-комісією (винагородою для валідатора). Ключова особливість: bundle є атомарним — або всі транзакції включаються в блок послідовно, або жодна. Це дозволяє будувати складні багатокрокові стратегії (наприклад, арбітраж між DEX), які не можуть бути перехоплені на проміжних етапах. Валідатор, який використовує Jito, отримує tip-комісію поверх стандартних priority fees за включення bundle.
MEV у Solana: користь і ризики
MEV (Maximal Extractable Value) — це значення, яке може бути екстрактоване шляхом включення, виключення або переставляння транзакцій у блоці. У Solana MEV існує структурно через механізм лідерства: лідер слота має дискреційне право порядку транзакцій. Позитивний аспект: MEV стимулює розвиток інфраструктури (Jito, блок-двигуни) і може збільшувати доходи валідаторів. Негативний аспект: шкідливий MEV (sandwich attacks, front-running) створює витрати для кінцевих користувачів. Розмежування між «корисним» і «шкідливим» MEV є предметом активних дискусій в екосистемі.
Як працює Jito Block Engine
Jito Block Engine — це окрема інфраструктура, яка працює паралельно з стандартним пайплайном лідера. Валідатор, який підключений до Jito Block Engine, отримує доступ до потоку bundles від пошуковиків MEV. Блок-двигун агрегує bundles та звичайні транзакції, формує оптимальний блок і передає його лідеру для підписання та трансляції. Валідатор отримує tip-комісії від bundles як додатковий дохід. Важливо розуміти: підключення до Jito Block Engine є добровільним і вимагає додаткового налаштування інфраструктури.
Як працює Jito StakeNet
Jito StakeNet — це пропозиція щодо децентралізованого розподілу MEV-доходів між стейкерами. Ідея полягає в тому, щоб tip-комісії від bundles розподілялися пропорційно стейку делегаторів, а не залишалися виключно у валідатора. Це змінює економічні стимули: делегатор обирає валідатора не лише за комісією та надійністю, а й за доступом до MEV-доходів. Статус та етапи впровадження StakeNet варто перевіряти в актуальних джерелах проєкту Jito, оскільки ця інфраструктура активно розвивається.
Шкідливий MEV у Solana: sandwich attacks та front-running
Sandwich attack — це стратегія, де атакуючий розміщує транзакцію перед цільовою (front-running) і після неї (back-running), витискаючи цінову різницю. Front-running — це включення власної транзакції перед цільовою на основі знань про її вміст. У Solana ці атаки технічно можливі через лідерський порядок транзакцій, але їхня ефективність залежить від конкретного типу транзакції та ліквідності пулу. Jito bundles частково пом'якшують цю проблему для складних стратегій, оскільки bundle є атомарним, але не усувають її повністю для окремих транзакцій.
Політики stake pools щодо MEV: стратегії та підходи
Stake pools (наприклад, Sanctum, Jito Pool) мають різні підходи до MEV-доходів. Деякі пули повністю передають MEV-доходи делегаторам пропорційно їхній частці. Інші утримують частину MEV для покриття операційних витрат або як додаткову комісію пулу. Для делегатора професійного рівня важливо розуміти не лише заявлену APY пулу, а й структуру цієї доходності: яка частка приходить від інфляції, яка — від транзакційних комісій, а яка — від MEV, і як ці потоки розподіляються.
Економіка та управління мережею
З чого складається дохід валідатора
Дохід валідатора в Solana має три основні компоненти. Перший — інфляційна винагорода (inflation reward), яка генерується протоколом і розподіляється пропорційно стейку. Другий — транзакційні комісії (base fee + priority fee), які лідер отримує за включення транзакцій у блок під час свого слота. Третій — MEV-доходи (tip-комісії від Jito bundles та інші форми екстракції), які залежать від інфраструктури, яку валідатор використовує. Чистий дохід валідатора — це сума цих компонентів мінус витрати (vote costs, інфраструктура, комісія пулу якщо застосовується).
Vote costs: скільки коштує голосування валідатора
Голосування валідатора — це транзакція, і як будь-яка транзакція в Solana, вона має комісію. Vote cost складається з base fee (спалюється) та обчислювального бюджету, необхідного для обробки голосу. Оскільки валідатор голосує за кожен блок, який бачить, ці витрати накопичуються протягом епохи. Розмір vote cost залежить від поточного рівня навантаження мережі та налаштувань базової комісії. Для розрахунку чистого доходу валідатора необхідно віднімати сумарні vote costs за епоху від сумарного доходу. Конкретні цифри варто розраховувати на основі актуальних даних мережі на дату розрахунку.
Block revenue: як формується винагорода за створення блоку
Коли валідатор є лідером слота, він формує блок і отримує пов'язані з цим доходи. Block revenue включає: суму всіх priority fees від транзакцій у блоці, суму всіх tip-комісій від Jito bundles (якщо валідатор використовує Jito Block Engine), та частину спалюваних base fees у певних конфігураціях. Інфляційна винагорода не прив'язана безпосередньо до створення блоку — вона розподіляється пропорційно стейку незалежно від того, чи був валідатор лідером. Тому block revenue — це переважно комісійний дохід, тоді як інфляційна винагорода — це пасивний дохід від стейку.
Як інфляція SOL впливає на стейкінг
Solana використовує модель дисконтної інфляції: початковий відсоток інфляції знижується з часом за заданим графіком (зниження на 15% щорічно) до фінального рівня. Інфляційні токени розподіляються між стейкерами пропорційно їхній частці. Це означає, що unstaked токени розбавляються, тоді як staked токени зберігають свою частку в загальній пропорції. Для розуміння реального доходу від стейкінгу необхідно розрізняти номінальний дохід (у токенах SOL) та реальний дохід (з урахуванням розведення). Конкретний відсоток інфляції на будь-яку дату можна розрахувати за формулою протоколу з використанням початкових параметрів та часу, що минув від запуску мережі.
Foundation Delegation: програма делегування Solana Foundation
Solana Foundation має програму делегування стейку валідаторам, яка виконує дві функції: підтримку нових валідаторів на етапі входу в мережу та стимулювання децентралізації. Делегування не є постійним — воно переглядається на основі критеріїв ефективності, надійності та внеску в екосистему. Для валідатора отримання делегування від Foundation є сигналом довіри, але не є гарантією доходу: делегування може бути відкликане, а його розмір не фіксується публічно наперед. Умови та критерії програми варто перевіряти безпосередньо в офіційних джерелах Foundation.
Як валідатори беруть участь в управлінні
Валідатори в Solana беруть участь в управлінні через кілька механізмів. По-перше, голосування в консенсусі є формою участі: відмовившись голосувати, валідатор втрачає частину інфляційної винагороди, що створює економічний стимул брати участь. По-друге, валідатори можуть брати участь в обговоренні SIMD-пропозицій, надаючи технічну експертизу. По-третє, делеговані токени дають валідаторам опосередкований голос у питаннях управління, оскільки делегатори обирають валідаторів, які відповідають їхнім поглядам. Проте варто розуміти: Solana не має формалізованого механізму on-chain голосування за протокольні зміни на рівні Ethereum — більшість рішень приймається через off-chain консенсус розробників та валідаторів.
Децентралізація мережі Solana: метрики та поточний стан
Оцінка децентралізації Solana вимагає багатовимірного підходу. Основні метрики: розподіл стейку серед валідаторів (Nakamoto coefficient — мінімальна кількість валідаторів, які разом контролюють 33% стейку), географічний розподіл вузлів, різноманітність клієнтів валідатора, розподіл делегування між незалежними валідаторами та stake pools, та концентрація стейку у великих інституційних холдерів. Кожна з цих метрик розкриває різний аспект децентралізації. Актуальні значення цих метрик варто перевіряти в незалежних моніторингових інструментах (наприклад, Solana Beach, Validator.app), оскільки вони змінюються з кожною епохою. Жодна окрема метрика не дає повної картини — децентралізацію слід оцінювати комплексно.