У Solana форки — це не екзотична аномалія, а штатний робочий механізм. Мережа створює їх постійно, а консенсус на базі Tower BFT щомиті вирішує, яка гілка стає канонічною. Розуміння цього процесу критично важливе для валідаторів, які обробляють конфлікти в реальному часі, і для делегаторів, що оцінюють надійність інфраструктури.

Природа форків у Solana

Чому виникають форки та як часто

Solana генерує блоки кожні ~400 мілісекунд. За такої швидкості двоє або більше валідаторів, обраних лідерами на один і той самий слот, можуть одночасно створити різні блоки. Це стається через мережеву затримку: валідатор А не встигає отримати блок від валідатора Б до моменту власного виробництва й формує альтернативний блок із частково перетинаючим набором транзакцій.

Інший сценарій — часткове поширення. Лідер створив блок і розіслав його частині мережі, але певні валідатори отримали його з запізненням або з пропущеними транзакціями. У результаті виникає тимчасовий розбіжний стан (fork): частина мережі вважає одним канонічним блоком, інша частина — іншим.

На відміну від блокчейнів із тривалим часом блоку, де форки трапляються рідко, у Solana вони є природним наслідком високої пропускної здатності. Протокол спроєктований так, щоб швидко й детерміновано їх вирішувати, а не запобігати їм повністю.

Відмінність від форків у Ethereum

Ethereum використовує механізм LMD-GHOST (Latest Message Driven Greedy Heaviest Observed Subtree), де кожен валідатор подає атестацію за конкретний блок, а fork choice обирає гілку з найбільшою сукупною вагою атестацій. Атестації не мають жорсткого періоду блокування — валідатор може змінити думку між голосуваннями в межах епохи.

Solana застосовує Tower BFT — модифікацію класичного PBFT із концепцією зростаючих періодів блокування (lockout). Кожен наступний голос валідатора блокує його на довший термін: 2, 4, 8, 16, 32 слоти й далі. Це означає, що голос, поданий за блок на глибині 32 слотів, є значно «важчим» і дорожчим для відкликання, ніж свіжий голос на глибині 2 слоти. Консенсус стимулює валідаторів накопичувати голоси на одній гілці й штрафує часту зміну позиції.

Ще одна фундаментальна різниця — наявність єдиного лідера на слот. У Ethereum пропозиція блоку відбувається через випадковий вибір із комітету, тоді як у Solana лідерство визначається детерміновано на основі черги (leader schedule), що формується заздалегідь на кожну епоху. Це спрощує атрибуцію блоків, але створює вектор для форків саме на межі зміни лідерів.

Механізм вибору правильного гілки

Роль stake-weighted голосування

Кожен голос валідатора в Tower BFT має вагу, пропорційну його стейку. Канонічна гілка визначається сукупною вагою stake, що проголосувала за кожен блок у ланцюжку. Не кількість валідаторів, а саме сума делегованого SOL визначає переможця.

Процес виглядає так:

  1. Лідер створює блок і транслює його мережею.
  2. Валідатори отримують блок, перевіряють його і подають голос (vote transaction).
  3. Голоси накопичуються на кожному блоці ланцюжка.
  4. Коли виникає форк, кожна гілка має власну сукупну вагу голосів.
  5. Гілка з найбільшою stake-weighted сумою голосів стає канонічною.

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

Fork choice rule: найважчий ланцюжок

Solana реалізує варіацію принципу «найважчого ланцюжка» (heaviest chain), адаптовану для Tower BFT. Правило вибору гілки (fork choice rule) працює за такими критеріями:

  • Сукупна вага stake — первинний критерій. Гілка, де сумарний стейк валідаторів, що проголосували за кожен блок послідовно від кореня, є найбільшою, перемагає.
  • Глибина lockout — при рівній сукупній вазі пріоритет має гілка з голосами на більших глибинах, оскільки вони свідчать про довшу стабільну історію.
  • Хеш блоку як тайбрейкер — якщо всі числові критерії рівні, використовується лексикографічне порівняння хешів блоків для детермінованого вибору.

Коли валідатор виявляє, що існує важча гілка, ніж та, за яку він голосував, він ініціює rollback — відкочування свого стану до спільного предка двох гілок і перемикання на важчу. Цей процес автоматизований у реалізації консенсусу (validator client), але має операційні наслідки, про які далі.

Вплив на користувачів та валідаторів

Ризики для транзакцій під час форку

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

  • Транзакція отримала статус confirmed, але згодом зникла з експлорера.
  • Баланс тимчасово змінився, а потім повернувся до попереднього значення.
  • У гаманці транзакція може відображатися як невідправлена або з невизначеним статусом.

Сама транзакція при цьому не знищується — вона залишається в мемпулі (або повертається туди після rollback) і може бути включена в наступний блок канонічної гілки, якщо ще не застаріла. Проте це не гарантовано: якщо транзакція мала обмеження за часом (recent blockhash) або її логіка залежала від стану, який змінився на важчій гілці, вона може стати недійсною.

Практичне правило: для транзакцій із високою вартістю помилки варто чекати не просто одного підтвердження, а перевіряти, чи блок отримав optimistic confirmation — стан, коли за нього проголосувало понад 2/3 загального stake. Хоча теоретично навіть optimistic confirmation може бути відкликане (що траплялося в історії мережі), на практиці це вимагає одночасної відмови значної частини валідаторів, що є вкрай малоймовірним за нормальних умов.

Як валідатори обробляють форки

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

  1. Зберігає обидві гілки в пам'яті — принаймні на кілька слотів углиб. Це означає, що під час активних форків споживання RAM зростає, оскільки AccountsDB утримує паралельні стани.
  2. Оцінює вагу кожної гілки — шляхом підрахунку stake-weighted голосів, отриманих від інших валідаторів.
  3. Виконує rollback — якщо його поточна гілка виявилася легшою, валідатор відкочує стан до останнього спільного предка (common ancestor) і перемикається на важчу гілку.
  4. Подає нові голоси — починаючи з поточної позиції у вежі Tower BFT на новій гілці. При цьому lockout періоди зберігаються: валідатор не може просто «забути» свої попередні голоси, він продовжує вежу з урахуванням історії.

Типова помилка операторів — недооцінка навантаження на підсистему зберігання під час масових форків. Якщо мережа переживає період нестабільності з частими форками, валідатор із обмеженим обсягом RAM може опинитися в ситуації, коли він фізично не здатний тримати обидві гілки й починає відставати (desync). Це призводить до пропуску голосів і втрати reward.

Ще один аспект — правильність налаштування forks-параметрів у конфігурації валідатора. Занадто агресивне перемикання на нові гілки (низькі пороги) створює нестабільність і може призвести до cascade-ефекту, коли валідатор постійно скасовує свої голоси. Занадто консервативне перемикання (високі пороги) означає, що валідатор довго тримається за меншу гілку, втрачаючи reward на канонічній гілці й ризикуючи бути відсіченим епохальним голосуванням.

Для моніторингу стану форків варідатори зазвичай використовують логи консенсусу (рівень trace або debug), де фіксуються події типу bank_fork_utils та reset_forks. Аналіз цих логів дозволяє визначити частоту форків, глибину rollback та час відновлення синхронізації — ключові метрики операційної ефективності вузла.

Факт: Solana не має механізму «наказового» фінальності (finality gadget у стилі Casper FFG). Канонічність — це завжди ймовірнісна оцінка на основі накопичених голосів. Чим більше stake проголосувало за ланцюжок, тим нижча ймовірність його відкликання, але нульової вона не буває.

Джерела