Консенсус Solana — це комбінація двох механізмів: Proof of History (PoH) створює криптографічний часовий ряд, а Proof of Stake (PoS) визначає, хто має право генерувати блоки та підтверджувати їх. Разом вони забезпечують порядок транзакцій, швидке фінальне підтвердження та економічну безпеку мережі без залежності від зовнішніх джерел часу.
Основи консенсусу Proof of History + Proof of Stake
Proof of History: криптографічний годинник
Proof of History — це послідовність хешів SHA-256, де кожен наступний хеш обчислюється з попереднього. Формально: hashi = SHA-256(hashi-1 || datai). Цей ланцюжок неможливо підробити заднім числом: щоб згенерути хеш із номером N, обов'язково треба обчислити всі попередні N-1 хешів, а це вимагає фіксованого обчислювального часу.
PoH не є консенсусом сам по собі. Це годинник, який дає всім валідаторам спільне уявлення про те, коли відбулася подія, без необхідності синхронізувати системні таймери через мережу. Кожен запис у цьому ланцюжку називається entry і містить хеш попереднього entry, хеш транзакцій та кількість пройдених хешів (tick count).
Практичний наслідок: коли валідатор отримує блок від лідера, він може криптографічно перевірити, що транзакції впорядковані в часі, не звіряючись з іншими вузлами. Це усуває цілий клас атак на порядок транзакцій на етапі прийняття.
Роль лідерського графіка (leader schedule)
Proof of Stake в Solana реалізується через лідерський графік — детермінований розподіл слотів між валідаторами на основі їхньої частки стейку. Графік обчислюється на початку кожної епохи і є відомим усім мережі заздалегідь.
Кожен слот має рівно одного лідера. Чим більша частка стейку валідатора від загального стейку мережі, тим частіше він стає лідером. Це означає, що PoS у Solana безпосередньо визначає не лише право голосу, а й право продукувати блоки — без додаткових виборів чи лотерей у межах слота.
Важливий нюанс: лідерський графік фіксований на всю епоху. Це дозволяє валідаторам готуватися до свого слота, але водночас означає, що зміна складу валідаторів (додаткове делегування або зняття стейку) впливає на графік лише з наступної епохи.
Життєвий цикл блоку
Прийняття транзакцій через TPU
TPU (Transaction Processing Unit) — це конвеєр обробки транзакцій у клієнті валідатора, оптимізований для мінімізації затримки. Транзакції надходять через UDP, а не TCP, що усуває накладні витрати на встановлення з'єднання та повторну передачу на транспортному рівні.
Конвеєр TPU складається з кількох стадій: прийом пакетів, перевірка підписів (зазвичай на GPU), фільтрація дублікатів, групування у batches та передання до banking stage. Коли валідатор є лідером, його TPU приймає транзакції від користувачів та інших валідаторів і готує їх до включення в блок. Коли валідатор не є лідером, його TPU все одно працює — він перенаправляє транзакції поточному лідеру.
Формування блоку лідером та підписання
Лідер бере накопичені транзакції, впорядковує їх, обчислює PoH-хеші та формує entries. Ці entries утворюють блок, який лідер підписує своїм ключем. Підпис гарантує цілісність блоку та авторство лідера у конкретному слоті.
Ключовий момент: лідер має монопольне право на запис у свій слот. Інші валідатори не можуть генерувати блоки в цей слот. Якщо лідер виходить з ладу або не генерує блок, слот просто залишається порожнім — мережа переходить до наступного слота без блокування.
Розповсюдження через Turbine та підтвердження валідаторами
Після підписання блок розбивається на фрагменти (chunks) і розповсюджується через протокол Turbine за деревоподібною топологією. Валідатори отримують фрагменти, відновлюють повний блок, перевіряють PoH-ланцюжок, підписи транзакцій та підпис лідера.
Якщо блок валідний, валідатор формує голос (vote) — криптографічне підтвердження, що цей блок є коректним і є наступним у ланцюжку після попереднього підтвердженого блоку. Голоси розповсюджуються через gossip-мережу. Блок вважається фінально підтвердженим (finalized), коли за нього проголосувала супер-більшість стейку.
Механізми безпеки консенсусу
Слоти, епохи та супер-majority stake
Слот — це мінімальний часовий інтервал консенсусу, приблизно 400 мілісекунд. Епоха — це фіксоване число слотів (432 000), що становить близько двох днів. На межі епох оновлюється лідерський графік, обчислюються винагороди та оновлюється стан стейкінгу.
Основна гарантія безпеки — вимога супер-більшості: для фінального підтвердження блоку потрібно, щоб за нього проголосували валідатори, які разом контролюють не менше ніж 2/3 від загального стейку мережі. Якщо цей поріг не досягнутий, блок залишається непідтвердженим, і мережа може обрати альтернативну гілку в наступних слотах.
Це означає, що атакувальнику потрібно контролювати більше ніж 1/3 стейку, щоб системно блокувати фінальність, і більше ніж 2/3 — щоб одноосібно переписати історію. Економічна нездійсненність такої атаки за умови достатньої децентралізації стейку — головний захисний механізм.
Санкції за подвійне підписання (slashability)
Подвійне підписання (double signing) — це ситуація, коли валідатор підписує два різні блоки на одному й тому ж висоті слота. Це пряме порушення консенсусу, оскільки лідер має право на єдиний блок у своєму слоті.
Концептуально механізм slashability передбачає, що будь-який учасник мережі може подати доказ подвійного підписання (два підписані блоки з однаковим слотом та висотою від одного валідатора), після чого частина стейку цього валідатора конфіскується на користь мережі. Це створює економічний дисконтитив для такої поведінки.
Станом нині активне slashing на mainnet-beta не реалізоване. Цей механізм обговорюється в рамках SIMD-пропозицій, і його статус, умови активації та конкретні параметри конфіскації можуть змінюватися. Рекомендуємо перевіряти актуальний статус відповідних SIMD безпосередньо перед прийняттям операційних рішень щодо делегування чи інфраструктури.
За відсутності активного slashing економічний захист від подвійного підписання спирається на репутаційні механізми: делегатори можуть перевести свій стейк від валідатора, доведеного в подвійному підписанні, що призводить до втрати комісій та позиції в лідерському графіку.