Статус клієнтів для «Мультиклієнтне середовище: Gossip, Banking та Turbine між різними реалізаціями» перевірено 2 серпня 2026 року. Frankendancer — гібрид Agave/Firedancer — працює на mainnet-beta щонайменше з 2025 року: офіційна програма делегування повідомляла майже про 200 валідаторів у вересні 2025 року. Повний Firedancer є окремою реалізацією мовою C; його поточне впровадження та частку валідаторів потрібно звіряти з офіційним звітом, а не з давніми твердженнями про «лише testnet».
Мультиклієнтне середовище Solana означає, що в мережі одночасно працюють різні реалізації валідаторного ПЗ — наприклад, Agave (форк оригінального клієнта на Rust) та Firedancer (клієнт від Jump Crypto, написаний на C). Щоб ці вузли могли досягати консенсусу, вони мають спілкуватися через три ключові мережеві протоколи: Gossip, Banking Stage та Turbine. Нижче розглянуто, як саме відбувається ця взаємодія, де виникають межі сумісності та які механізми забезпечують коректну роботу.
Мережеві протоколи Solana
Архітектура мережевого рівня Solana побудована навколо трьох протоколів, кожен із яких виконує чітку функцію в життєвому циклі блоку. Для мультиклієнтного середовища критично важливо, що ці протоколи визначені специфікацією, а не прив'язані до конкретної кодової бази.
Gossip Protocol: виявлення вузлів та обмін інформацією
Gossip — це протокол виявлення вузлів (peer discovery) та поширення метаданих мережі. Кожен валідатор підтримує набір сусідів (peers) і періодично обмінюється з ними повідомленнями, що містять:
- CRDS (Credit-Scoped Replicated Data Store) — структура, у якій кожен запис має кредитний рейтинг (weight). Чим довше запис циркулює без спростування, тим вищий його пріоритет.
- Contact Info — публічні дані вузла: IP-адреса, порт Gossip, порт Turbine, публічний ключ, версія клієнта.
- Vote — підписані голоси валідатора за конкретні слоти та банківські хеші.
- Snapshot Hashes — хеші доступних снепшотів для швидкої синхронізації.
Формат повідомлень Gossip визначено на рівні бінарної серіалізації. Будь-який клієнт, який коректно серіалізує та десеріалізує ці повідомлення й дотримується правил CRDS, може брати участь у мережі незалежно від мови реалізації.
Banking Stage: обробка транзакцій та формування блоків
Banking Stage — це внутрішній конвеєр валідатора, де транзакції проходять перевірку підписів, перевірку балансів, виконання смарт-контрактів та обчислення стану. На цьому етапі відбувається формування так званого banking hash — криптографічного зрізу стану, який потім потрапляє у Gossip як об'єкт голосування.
У мультиклієнтному контексті Banking Stage є найбільш ізольованою частиною: кожна реалізація виконує транзакції власним кодом. Проте результат має бути детерміновано ідентичним для всіх клієнтів при однаковому вхідному наборі транзакцій та початковому стані. Саме ця детермінованість, а не спільний код, є умовою консенсусу.
Turbine: розповсюдження блоків між валідаторами
Turbine — це протокол розповсюдження блоків, оптимізований для високої пропускної здатності. Лідер слота ділить блок на фрагменти (data shards), додає кодування Ерлюра (Reed–Solomon erasure coding) і розсилає їх по деревоподібній топології. Кожен валідатор-отримувач відновлює повний блок із підмножини фрагментів.
Формат фрагментів Turbine, порядок їхньої нумерації, розмір та механізм Ерлюра визначені протоколом. Це дозволяє вузлу на Agave отримувати фрагменти від лідера на Firedancer і навпаки — за умови, що обидва дотримуються специфікації фрагментації та дерева сусідів.
Взаємодія різних клієнтів у мережі
Практична сумісність різних реалізацій залежить від того, наскільки точно кожен клієнт реалізує спільну специфікацію. Розглянемо ключові аспекти цієї взаємодії.
Як Agave та Firedancer спілкуються через Gossip
Коли вузол Firedancer підключається до мережі, він починає з набору енtripoint-вузлів (bootnodes), отриманих поза протоколом Gossip. Після встановлення TCP-з'єднання відбувається обмін повідомленнями у форматі, визначеному специфікацією CRDS. Firedancer розкриває своє Contact Info, отримує Contact Info сусідів, починає поширювати свої голоси та отримувати голоси інших.
Agave-вузли сприймають Firedancer як звичайного учасника мережі, оскільки рішення про включення вузла до набору сусідів базується на криптографічних підписах та кредитній системі CRDS, а не на ідентифікаторі клієнта. Версія клієнта передається в Contact Info, але на рівні протоколу Gossip вона є інформаційним полем, а не фільтром.
Сумісність на рівні серіалізації та протоколів
Основний інструмент сумісності — спільна специфікація серіалізації. У Solana використовується фіксований бінарний формат: кожне повідомлення має чітку послідовність полів із визначеними розмірами. Це виключає неоднозначності, притаманні текстовим форматам на кшталт JSON.
Критичні точки сумісності:
- Серіалізація транзакцій — формат підпису, масиву інструкцій, адрес та останніх блоків (recent_blockhash) має бути байт-ідентичним у всіх клієнтах.
- Серіалізація голосів — голос (Vote) містить підпис, слот, банківський хеш та індикатори (is_skip, lockout). Будь-яка відмінність у порядку полів або інтерпретації бітів призведе до відхилення голосу іншими вузлами.
- Формат фрагментів Turbine — розмір фрагмента, кількість паритетних шматків Ерлюра, порядок байтів у заголовку фрагмента.
- Обробка snapshot-хешів — формат повідомлення про доступність снепшоту та хеш-дерева рахунків.
Якщо обидва клієнти серіалізують та десеріалізують ці структури однаково, вони можуть взаємодіяти на рівні мережі, навіть якщо внутрішня реалізація Banking Stage принципово відрізняється.
Виклики та рішення
Перехід від моноклієнтного до мультиклієнтного середовища неминуче створює інженерні виклики. Нижче наведено ті, що вже спостерігалися в тестових мережах, та підходи до їхнього вирішення.
Несумісності, що виникали в тестнетах
У тестнетах із одночасною роботою Agave та Firedancer фіксувалися такі типи розбіжностей:
- Розбіжності банківського хешу (banking hash divergence) — ситуація, коли два клієнти, отримавши однаковий набір транзакцій, обчислюють різний хеш стану. Це може бути спричинено різною обробкою крайових випадків у BPF-віртуальній машині, різною інтерпретацією помилок виконання або різним порядком обробки транзакцій у межах одного блоку.
- Невідповідність у розмірах фрагментів Turbine — якщо один клієнт використовує дещо іншу логіку розбиття блоку на шматки, отримувач не зможе відновити повний блок навіть за наявності достатньої кількості фрагментів.
- Поведінка при перевантаженні Gossip — різні клієнти можуть по-різному реалізовувати механізми обмеження частоти (rate limiting) та відкидання повідомлень при сплесках трафіку, що призводить до асиметричного виявлення вузлів.
Важливо: конкретні інциденти та їхні деталі варто перевіряти в офіційних звітах з тестнетів, оскільки статус усунення кожної з проблем змінюється з релізами.
Механізми перевірки та усунення розбіжностей
Для виявлення та діагностики несумісностей у мультиклієнтному середовищі використовуються кілька підходів:
- Паралельне виконання (shadow running) — запуск обох клієнтів на однакових даних з порівнянням результатів без впливу на мережу. Це дозволяє виявити розбіжності банківських хешів до того, як вони потраплять у Gossip.
- Фазовані тестнети — поступове збільшення частки не-Agave вузлів у тестовій мережі: від одиничних вузлів до значної частки стейку. На кожному етапі моніторяться показники консенсусу (skipped slots, orphan blocks, голосування).
- Формальні специфікації — розробка незалежних від реалізації описів протоколів (наприклад, у формальних мовах або псевдокоді), які слугують арбітром у спорних ситуаціях між реалізаціями.
- Моніторинг розбіжностей голосів — якщо валідатори на різних клієнтах систематично голосують за різні банківські хеші в одному слоті, це сигнал про наявну несумісність. Такі аномалії відстежуються через інфраструктуру моніторингу мережі.
Ключовий принцип: у мультиклієнтному середовищі специфікація протоколу є єдиним джерелом істини, а не код жодного з клієнтів. Будь-яка розбіжність між реалізаціями трактується як баг реалізації, а не як допустима варіативність.
Для валідаторів та інженерів, які планують працювати з не-Agave клієнтами, наступний логічний крок — ознайомитися з тим, як працює поточний консенсус Solana, щоб зрозуміти, де саме в ланцюгу обробки блоку виникають точки контакту між різними реалізаціями.