Визначення

Consensus (консенсус) — це механізм, за якого незалежні вузли мережі Solana досягають єдиної згоди щодо поточного стану блокчейну без центрального арбітра. У Solana консенсус реалізовано через алгоритм Tower BFT, який працює поверх Proof of History.

Як працює

Solana поєднує Proof of History як криптографічний годинник із Tower BFT — варіацією класичного алгоритму Byzantine Fault Tolerance. Практична послідовність виглядає так:

  • Proof of History створює впорядковану хронологію подій, тому вузлам не треба витрачати час на узгодження часових міток між собою.
  • Tower BFT використовує цю хронологію для голосування за блоки: кожен валідатор голосує за конкретний слот, і його голоси утворюють ланцюжок «голосувальних блоків».
  • Якщо валідатор проголосував за блок у слоті N, він не може голосувати за конфліктний блок у тому ж слоті — це криптографічний захист від подвійних витрат.
  • Коли за блок проголосувала супербільшість стейку, він отримує рівень confirmed. Рівень finalized настає пізніше, коли блок досягає максимального lockout і стає кореневим (root) для кластера.

Такий підхід дозволяє швидко отримати оптимістичне підтвердження. За звичайних умов confirmed з’являється приблизно за 1–2 секунди, а finalized — типово близько 13 секунд.

Приклад

Уявіть сто валідаторів, кожен із яких утримує різну кількість SOL у стейку. Валідатор А створює блок у слоті 1000 і транслює його в мережу. Інші валідатори перевіряють PoH-послідовність, підтверджують коректність транзакцій і голосують «за». Коли сукупна частка стейку, що проголосувала за блок, перевищує поріг супербільшості, блок отримує рівень confirmed. Остаточний рівень finalized настає після подальшого нарощування lockout, коли цей блок стає root.

Типова помилка

Плутати консенсус із порядком транзакцій усередині блоку. Consensus визначає, який блок є правильним і фіналізованим, але порядок транзакцій у ньому формується на етапі, пов'язаному з MEV. Тобто консенсус відповідає на запитання «який блок є істинним?», а не «яка транзакція має бути першою в блоці?».

Пов'язані матеріали

Внутрішні переходи

  • SIMD — пропозиції щодо покращення протоколу Solana, зокрема зміни в механізмі консенсусу
  • Client diversity — різноманітність клієнтів мережі та їхня роль у стабільності досягнення консенсусу

Джерела