Розділ збирає ключові терміни, які описують, як Solana досягає консенсусу, поширює блоки та обробляє MEV (Maximal Extractable Value). Тут знайдете короткі пояснення кожного поняття з практичним прикладом і вказівкою на глибший матеріал.
MEV
Визначення
MEV (Maximal Extractable Value) — це прибуток, який валідатор або сторонній учасник може отримати, змінюючи порядок, включення або виключення транзакцій у блоці. Термін замінив стару назву «Miner Extractable Value», оскільки в Solana блоки створює лідер-валідатор, а не майнер.
Як працює
Коли лідер отримує транзакції з пулу, він бачить їхній зміст до того, як сформує блок. Це дає змогу вставити власні транзакції перед або після користувацьких, щоб скористатися ціновою різницею на DEX, арбітражем або ліквідаціями. В Solana MEV частіше реалізується через окремі інфраструктурні рішення (наприклад, Jito), а не безпосередньо в коді вузла.
Приклад
Користувач відправляє великий своп на Raydium. Бот помічає цю транзакцію, формує bundle зі своєю транзакцією арбітражу й передає лідеру через Jito. Лідер включає обидві транзакції разом: спочатку своп користувача зсуває ціну, потім бот забирає різницю.
Типова помилка
Вважати, що MEV — це виключно шкода для користувача. Насправді MEV також фінансує інфраструктуру (наприклад, Jito розподіляє частину прибутку між стейкерами), а деякі форми MEV (арбітраж між DEX) допомагають вирівнювати ціни.
Пов'язані матеріали
Докладніше про механіку MEV на Solana та інструменти захисту читайте в окремому гіді про MEV.
Bundle
Визначення
Bundle — це набір транзакцій, які подаються лідеру як єдина атомарна одиниця: або всі транзакції включаються в блок, або жодна.
Як працює
Пошуковики MEV формують bundle і надсилають його через block engine (наприклад, Jito). Block engine передає bundle поточному лідеру. Лідер оцінює, чи приносить bundle достатньо комісії, і приймає рішення про включення цілком. Атомарність гарантує, що проміжний стан не потрапить в окремий блок.
Приклад
Арбітражний бот створює bundle із трьох транзакцій: своп на DEX A, своп на DEX B, повернення прибутку. Якщо хоча б один свап не увійде, бот втратить кошти, тому подає їх лише як bundle.
Типова помилка
Плутати bundle із звичайною чергою транзакцій. Звичайні транзакції обробляються незалежно, тоді як bundle — це контракт «все або нічого» між пошуковиком і лідером.
Пов'язані матеріали
Детальніше про формування та подачу bundle читайте в матеріалі про Jito.
Leader
Визначення
Leader (лідер) — це валідатор, якому на поточному слоті належить право сформувати й транслювати блок.
Як працює
Solana розбиває час на слоти (близько 400 мс кожен). Для кожного слота алгоритм визначає одного лідера з урахуванням його стейку. Лідер збирає транзакції, упорядковує їх (зокрема приймає bundle), створює блок і транслює його мережі через протокол Turbine. Після завершення слота роль переходить до наступного валідатора.
Приклад
Валідатор із 2% стейку буде лідером приблизно у 2% слотів. За один слот він може обробити тисячі транзакцій і кілька bundle від Jito.
Типова помилка
Вважати, що лідер обирається голосуванням на кожен слот. Насправді розподіл слотів детермінований і залежить від стейку та криптографічної послідовності Proof of History.
Пов'язані матеріали
Про те, як розподіляються слоти й формується черга лідерів, читайте в матеріалі про Tower BFT.
Block engine
Визначення
Block engine — це окремий сервіс, який приймає bundle від пошуковиків MEV і передає їх поточному лідеру для включення в блок.
Як працює
Пошуковик MEV надсилає bundle до block engine. Block engine тримає постійне з'єднання з поточним лідером (і часто з кількома наступними) і переадресовує bundle з найвищою пропонованою комісією. Лідер вирішує, прийняти чи відхилити. На Solana найвідоміший block engine — від Jito.
Приклад
Jito block engine отримує десятки bundle за секунду під час активного ринку. Він передає лідеру лише ті, що пропонують найвищу премію, і повертає пошуковикам підтвердження включення.
Типова помилка
Вважати, що block engine сам формує блок. Насправді він лише агрегує та передає bundle; блок завжди створює лідер-валідатор.
Пов'язані матеріали
Детальніше про архітектуру block engine читайте в матеріалі про Jito.
SIMD
Визначення
SIMD (Solana Improvement Document) — це пропозиція щодо зміни протоколу, консенсусу чи інфраструктури Solana, аналогічна EIP у Ethereum.
Як працює
Будь-хто може подати SIMD у відповідний репозиторій. Пропозиція проходить обговорення в спільноті, технічний аудит та голосування. Після затвердження зміни реалізуються в клієнтах (Agave, Firedancer) й активуються на мережі.
Приклад
SIMD-0096 описує зміни в обробці транзакцій для покращення досвіду користувачів за високого навантаження. Обговорення триває у відкритих репозиторіях.
Типова помилка
Вважати, що прийнятий SIMD автоматично активується в мережі. Насправді після затвердження потрібна реалізація в коді клієнта, тестування на testnet і координована активація валідаторами.
Пов'язані матеріали
Про поточні SIMD та їхній статус можна дізнатися в розділі про управління мережею.
Consensus
Визначення
Consensus (консенсус) — це механізм, за допомогою якого розподілені вузли мережі доходять єдиної думки про поточний стан блокчейну.
Як працює
Solana використовує алгоритм Tower BFT, який будує на Proof of History. Валідатори голосують за конкретні форки ланцюга, і кожен голос має вагу, пропорційну стейку. Коли сукупна вага голосів за певний блок перевищує поріг, блок вважається фіналізованим.
Приклад
Після того як лідер транслює блок, інші валідатори перевіряють його і надсилають голоси. Коли достатньо валідаторів (понад дві третини від загального стейку) проголосували за цей блок, він стає частиною фіналізованого ланцюга.
Типова помилка
Плутати консенсус із механізмом вибору лідера. Consensus — це процес узгодження стану між всіма валідаторами, тоді як вибір лідера — лише один із його елементів.
Пов'язані матеріали
Детальний опис алгоритму читайте в матеріалі про Tower BFT.
Client diversity
Визначення
Client diversity (різноманітність клієнтів) — це наявність кількох незалежних реалізацій клієнта валідатора, написаних різними командами на різних стеках.
Як працює
Якщо всі валідатори працюють на одному клієнті, баг у ньому може зупинити всю мережу. Наявність альтернативних клієнтів (Firedancer, інші майбутні реалізації) поруч із основним (Agave) знижує цей ризик. Валідатори можуть вільно обирати клієнт, поки він коректно реалізує протокол.
Приклад
Станом на зараз основний клієнт — Agave (Rust), а Firedancer (C) проходить тестування на mainnet. Якщо в Agave з'явиться критичний баг, частина валідаторів на Firedancer зможе підтримувати мережу.
Типова помилка
Вважати, що client diversity потрібен лише для продуктивності. Головна мета — безпека: різні клієнти рідко мають однакові баги, що ускладнює цілеспрямовану атаку на кодову базу.
Пов'язані матеріали
Про конкретні реалізації читайте в матеріалах про Agave та Firedancer.
Fork
Визначення
Fork (форк) — це ситуація, коли мережа тимчасово або постійно розходиться на два або більше альтернативних ланцюги блоків.
Як працює
У нормальному режимі форки виникають короткочасно, коли два валідатори одночасно пропонують різні блоки на одному слоті. Консенсус (Tower BFT) швидко вирішує, який форк продовжити, а інший відкидається. Довготривалі форки можливі лише за серйозних розбіжностей у спільноті (наприклад, навмисний хард-форк).
Приклад
Під час короткого збою зв'язку частина валідаторів може не побачити блок поточного лідера й продовжити ланцюг від попереднього слота. Через кілька слотів консенсус обере найдовший форк із найбільшою вагою голосів.
Типова помилка
Плутати тимчасовий форк (нормальне явище для будь-якого блокчейну) із навмисним хард-форком (свідоме розгалуження протоколу). У Solana тимчасові форки трапляються щодня й не є проблемою.
Пов'язані матеріали
Про те, як консенсус вирішує форки, читайте в матеріалі про Tower BFT.
Turbine
Визначення
Turbine — це протокол розповсюдження блоків у Solana, який передає дані між валідаторами за допомогою дерева, а не послідовно від одного до всіх.
Як працює
Лідер ділить блок на невеликі шматки (data shards) і надсилає їх першому шару валідаторів-сусідів. Ті, у свою чергу, передають шматки наступному шару. Завдяки деревоподібній структурі блок досягає всієї мережі за частки секунди навіть за великого розміру.
Приклад
Блок розміром 250 КБ ділиться на 32 шматки. Лідер передає їх 8 сусідам, кожен із яких передає далі. Уся мережа отримує блок приблизно за 200–300 мс.
Типова помилка
Вважати, що Turbine передає цілий блок кожному валідатору окремо. Саме поділ на шматки й паралельна передача забезпечують швидкість, яка неможлива при послідовному мовленні.
Пов'язані матеріали
Про повний цикл життя блоку читайте в матеріалі про Proof of History.
Gulf Stream
Визначення
Gulf Stream — це механізм Solana, який пересилає транзакції безпосередньо до наступних лідерів, уникаючи традиційного mempool.
Як працює
Замість того щоб зберігати транзакції в спільній черзі (mempool), клієнти та RPC-вузли надсилають транзакції безпосередньо лідерам майбутніх слотів. Це дозволяє лідеру мати транзакції «під рукою» ще до початку свого слота, що зменшує затримку підтвердження.
Приклад
Ви відправляєте транзакцію. Замість потрапляння в глобальну чергу, вона пересилається до валідатора, який буде лідером через два слоти (~800 мс). Коли його слот настає, транзакція вже готова до включення.
Типова помилка
Шукати в Solana класичний mempool, як у Ethereum. Gulf Stream свідомо усуває цей рівень, тому інструменти аналізу mempool з інших мереж тут не працюють.
Пов'язані матеріали
Про те, як Gulf Stream взаємодіє з іншими рівнями мережі, читайте в матеріалі про Turbine.
Proof of History
Визначення
Proof of History (PoH) — це криптографічний годинник, який дозволяє вузлам перевіряти хронологічний порядок подій без додаткового узгодження часу.
Як працює
PoH використовує послідовну функцію хешування (SHA-256), де кожен вихід є входом для наступного. Цей ланцюжок хешів створює незмінну тимчасову мітку: щоб обчислити хеш №1000, обов'язково треба послідовно обчислити всі попередні. Будь-хто може перевірити, що події відбулися в правильному порядку.
Приклад
Транзакцію А включено до хешу №500, транзакція Б — у хеш №502. Навіть без зв'язку з мережею можна довести, що А відбулася раніше за Б, бо хеш із Б неможливо обчислити без попередніх хешів.
Типова помилка
Вважати PoH механізмом консенсусу. PoH — це годинник; консенсусом займається Tower BFT, який використовує PoH як основу для часових міток голосів.
Пов'язані матеріали
Про те, як PoH інтегрований у консенсус, читайте в матеріалі про Tower BFT.
Tower BFT
Визначення
Tower BFT — це алгоритм консенсусу Solana, адаптація класичного pBFT, що використовує Proof of History як годинник.
Як працює
Кожен валідатор голосує за конкретний блок на конкретному слоті. Голоси прив'язані до ланцюжка PoH, тому їхній порядок гарантований криптографічно. Валідатори накопичують «вежі» голосів: чим більше голосів зібрано за форк, тим вище його довіра. Фіналізація відбувається, коли сукупний стейк голосувальників перевищує дві третини від загального.
Приклад
Валідатор бачить блок на слоті 100, перевіряє його і додає голос у свою вежу. На наступних слотах він продовжує голосувати за цей форк. Коли достатньо валідаторів побудували вежі на одному форку, блок стає фіналізованим.
Типова помилка
Порівнювати Tower BFT з Proof of Stake як рівнозначні механізми. PoS у Solana — це система стейкінгу та покарання, тоді як Tower BFT — алгоритм досягнення консенсусу, який працює поверх PoS і PoH.
Пов'язані матеріали
Про криптографічну основу алгоритму читайте в матеріалі про Proof of History.
Firedancer
Визначення
Firedancer — це альтернативний клієнт валідатора Solana, що розробляється компанією Jump Crypto мовою C.
Як працює
Firedancer реалізує весь стек валідатора від нуля: від мережевого рівня до консенсусу та виконання транзакцій. Архітектура орієнтована на максимальну продуктивність та ізоляцію компонентів. Клієнт проходить поетапне тестування: спочатку лише мережевий рівень, потім повний стек на testnet, далі — на mainnet поруч із Agave.
Приклад
Валідатор налаштовує Firedancer як основний клієнт. У разі виявлення бага в Agave цей валідатор продовжує працювати, оскільки його кодова база повністю незалежна.
Типова помилка
Вважати, що Firedancer замінить Agave. Обидва клієнти розробляються паралельно; мета — співіснування для підвищення client diversity, а не заміна.
Пов'язані матеріали
Про поточний статус та етапи впровадження читайте в матеріалі про client diversity.
Agave
Визначення
Agave — це основний клієнт валідатора Solana, написаний мовою Rust, який раніше називався «Solana Labs validator».
Як працює
Agave реалізує повний стек: прийом транзакцій, створення блоків, консенсус Tower BFT, виконання програм і трансляцію через Turbine. Більшість валідаторів мережі працюють саме на Agave. Код відкритий і розвивається через SIMD-пропозиції.
Приклад
Оператор валідатора встановлює Agave, підключається до mainnet-beta, налаштовує стейк-акаунт і починає брати участь у консенсусі, створюючи блоки на своїх слотах.
Типова помилка
Вважати Agave єдиним «офіційним» клієнтом. Зміна назви на Agave мала на меті підкреслити, що це одна з реалізацій, а не єдиний стандарт. Протокол — окремий специфікаційний документ, клієнт — його реалізація.
Пов'язані матеріали
Про альтернативну реалізацію читайте в матеріалі про Firedancer.
Jito
Визначення
Jito — це інфраструктура для MEV на Solana, що включає block engine, модифікований клієнт валідатора та механізм розподілу MEV-прибутку між стейкерами.
Як працює
Пошуковики MEV подають bundle до Jito block engine. Block engine передає їх лідерам, які працюють на Jito-версії клієнта. Після включення bundle частина MEV-прибутку (премія) спрямовується на спеціальний tip-акаунт і розподіляється між усіма стейкерами Jito пропорційно їхній частці. Це стимулює делегаторів обирати Jito-валідаторів.
Приклад
Ви делегуєте SOL до Jito-валідатора. Коли цей валідатор стає лідером і включає прибутковий bundle, частина премії автоматично потрапляє на ваш акаунт як додаткова винагорода поверх стандартного інфляційного стейкінгу.
Типова помилка
Вважати, що Jito контролює лідерство або консенсус. Jito не змінює порядок слотів і не впливає на Tower BFT — він лише надає інфраструктуру для прийому bundle та розподілу премій.
Пов'язані матеріали
Детальніше про механіку bundle та block engine читайте в відповідних розділах цього словника.