Операційні вимоги для «Tower Babel: механізм голосування та лідерства у Solana» перевірено 2 серпня 2026 року. Для production використовуйте тільки реліз Agave, рекомендований для конкретного кластера, і звіряйте параметри з agave-validator --help . Офіційні вимоги Anza на цю дату орієнтують операторів на Ubuntu 24.04, щонайменше 12 ядер/24 потоки, 256 ГБ RAM, окремі швидкі NVMe та симетричний канал від 2 Гбіт/с; це рекомендації, а не гарантія достатньої продуктивності.
Tower Babel — це реалізація алгоритму Tower BFT у кодовій базі Solana, яка відповідає за формування голосів валідаторів, управління періодами блокування (lockout) та визначення лідерського графіка. Цей компонент безпосередньо визначає, як мережа досягає згоди щодо стану ланцюжка, не зупиняючи обробку транзакцій.
Що таке Tower Babel
Походження назви та зв'язок з Tower BFT
Назва складається з двох частин. Tower BFT — це теоретичний консенсусний протокол, запропонований розробниками Solana як адаптація класичного PBFT (Practical Byzantine Fault Tolerance) для середовища з високою пропускною здатністю. Ключова відмінність від PBFT полягає у відмові від багаторазових раундів обміну повідомленнями між усіма валідаторами: натомість кожен вузол локально накопичує «вежу» голосів із зростаючими періодами блокування.
Babel — це назва конкретного програмного модуля (crate) у репозиторії агента валідатора, який інкапсулює всю логіку Tower BFT: зберігання голосів, обчислення lockout, перевірку сумісності нових голосів із поточною вежею. Тобто Tower BFT — це специфікація, а Tower Babel — її робоча реалізація на Rust.
Роль у поточному консенсусі
Tower Babel не є повним консенсусом сам по собі. Він виконує дві чіткі функції в межах ширшого механізму: по-перше, визначає правила, за якими валідатор формує та відправляє голоси; по-друге, вирішує, який форк ланцюжка вважається найкращим на основі накопичених stake-зважених голосів. Інші компоненти (Proof of History, турбінна передача блоків, банківська стадія) забезпечують порядок транзакцій і їх доставку, але саме Tower Babel перетворює цей порядок на фіналізований стан.
Як працює голосування валідаторів
Голосування за блоки та накопичення lockout
Кожен голос валідатора у Solana — це підписане повідомлення, що вказує на хеш конкретного форку (а не на індекс окремого блоку). Голоси складаються у локальну структуру, яку називають вежею. Кожен наступний рівень вежі подвоює період блокування попереднього.
Базова логіка lockout виглядає так:
- Рівень 0 — голос заблокований на мінімальний період (базове значення слотів)
- Рівень 1 — блокування подвоюється
- Рівень 2 — блокування подвоюється знову
- І так далі — експоненційне зростання
Це означає, що чим вище голос у вежі, тим дорожче валідатору змінити свою позицію: щоб проголосувати за альтернативний форк на високому рівні, потрібно дочекатися закінчення тривалого lockout-періоду, під час якого валідатор фактично втрачає можливість впливати на консенсус і, відповідно, отримувати винагороду. Економічний стимул працює прямо: подвійне голосування (equivocation) на високих рівнях призводить до слешингу — часткової конфіскації stake.
Важливий технічний нюанс: валідатор не голосує за кожен блок. Голосування відбувається періодично, і частота залежить від конфігурації мережі та відстані між слотами, де цей валідатор є лідером. Це зменшує навантаження на мережу від голосувальних повідомлень.
Формування лідерського графіка на основі stake
Лідерський графік (leader schedule) — це заздалегідь обчислений розподіл слотів між валідаторами. Tower Babel безпосередньо не обчислює цей графік, але використовує його як вхідні дані для прийняття рішень.
Алгоритм формування графіка:
- Береться поточний розподіл stake (сукупність делегованих токенів за кожним валідатором)
- Використовується детермінована псевдовипадкова функція, яка на основі seed-значення епохи розподіляє слоти пропорційно stake
- Результат — послідовність пар (слот, публічний ключ валідатора), яка є однаковою для всіх чесних вузлів
Чим більший stake у валідатора, тим частіше він стає лідером і тим більше блоків може створити. Оскільки графік відомий заздалегідь, валідатори можуть планувати свою роботу: підготовку блоків, взаємодію з турбіною тощо. Tower Babel використовує цей графік для визначення того, коли саме валідатор має можливість пропонувати блоки і коли йому слід голосувати за блоки інших лідерів.
Взаємодія з іншими компонентами
Зв'язок з Proof of History
Proof of History (PoH) забезпечує криптографічний часомір — послідовність хешів, кожен з яких доводить, що минув певний час після попереднього. Tower Babel спирається на цей часомір як на координатну сітку для всіх операцій.
Конкретні точки взаємодії:
- Прив'язка голосів до слотів. Кожен голос містить посилання на конкретний слот PoH. Це дозволяє однозначно визначити хронологічну позицію голосу без додаткового узгодження годинників між вузлами.
- Обчислення lockout у слотах. Періоди блокування вимірюються не в секундах, а в кількості слотів PoH. Це робить lockout детермінованим незалежно від коливань часу генерації блоків.
- Визначення застарілих голосів. Якщо голос відноситься до слота, який значно відстає від поточного кінця вежі, він відкидається як неактуальний навіть без перевірки lockout.
По суті, PoH дає Tower Babel спільну вісь часу, на якій розміщуються всі голоси та блоки. Без цього компоненту довелося б вирішувати проблему упорядкування повідомлень у мережі з різними затримками, що суттєво ускладнило б консенсус.
Вплив на безпеку та фіналізацію
Безпека Tower Babel ґрунтується на економічній моделі: атакуючий повинен володіти значною часткою stake, щоб вплинути на результат голосування, а спроба подвійного голосування на високих рівнях вежі призводить до втрати коштів. Експоненційне зростання lockout робить пізню зміну форку дорогою в термінальному вимірі — навіть якщо атакувальник має достатньо stake, йому доведеться чекати закінчення блокування, під час якого чесні валідатори продовжать будувати вежу на легітимному форку.
Щодо фіналізації, варто чітко розділити два рівні:
- Оптимістичне підтвердження (optimistic confirmation). Блок вважається підтвердженим, коли його накопичена stake-вага голосів перевищує поріг (зазвичай >2/3 від загального stake). Це не математична фіналізація, а практичне припущення, що зворотне малоймовірне.
- Рутинна фіналізація (root). Блок стає root (незворотним) у локальному стані валідатора, коли вежа голосів досягає достатньої висоти, і lockout-періоди роблять зміну форку неможливою без економічних втрат. Root-блоки не можуть бути відкинуті навіть теоретично в межах моделі безпеки протоколу.
Tower Babel не надає класичної фіналізації в стилі Casper FFG (де існують явні епохи фіналізації з окремими голосами). Натомість фіналізація є наслідком накопичення lockout-вежі і є поступовою: різні валідатори можуть вважати різні блоки root-ами в різні моменти, хоча в стабільній мережі ці розбіжності мінімальні. Цей підхід є свідомим компромісом між швидкістю підтвердження та суворістю фіналізації.
Для валідаторів практичний наслідок полягає в тому, що стан Tower Babel (висота вежі, поточний root, lockout-графік) є критичним локальним станом. Його втрата означає, що валідатор не зможе продовжити голосування без ризику equivocation, і відновлення вимагає обережного підходу — зазвичай відновлення знімка стану та очікування синхронізації з мережею перед відновленням голосування.