Jito Block Engine — це позамережева інфраструктура, яка приймає згруповані транзакції (bundles) від пошуковиків MEV і передає їх поточному лідеру Solana через виділений канал зв'язку. Її головне завдання — забезпечити атомарне виконання пакетів транзакцій і створити прозорий механізм аукціону за право включення до блоку.

Архітектура Jito Block Engine

Компоненти: Block Engine, Relayer, Searchers

Система складається з трьох логічних ролей, кожна з яких виконує чітко визначену функцію в конвеєрі обробки MEV.

  • Searchers — незалежні учасники або сервіси, які аналізують стан мемпулу та ланцюга, знаходять можливості для MEV (арбітраж, ліквідації в DeFi, спам-атаки) і формують bundles. Кожен bundle — це впорядкований набір транзакцій, який має бути виконаний атомарно: якщо хоча одна транзакція з пакету не проходить валідацію, відхиляється весь bundle.
  • Block Engine — серверна інфраструктура, яка приймає bundles від пошуковиків, виконує їхню попередню симуляцію (simulated execution) і проводить аукціон. Block Engine не створює блоки самостійно — він лише готує відібрані пакети для передачі лідеру.
  • Relayer — компонент, який підтримує постійне з'єднання з валідаторами та передає переможні bundles безпосередньо поточному лідеру. Зв'язок відбувається через виділений gRPC-канал, окремий від стандартної gossip-мережі Solana, що зменшує затримки та уникає конкуренції з регулярними транзакціями.

Як Block Engine взаємодіє з валідаторами

Валідатор, який бажає отримувати bundles через Jito, запускає на своїй машині додатковий процес — Jito-Solana. Це форк стандартного клієнта агвальда (agave), який додатково слухає вхідні підключення від Relayer. Коли валідатор стає лідером, Relayer передає йому відібрані bundles. Валідатор симулює їх локально і, якщо симуляція успішна, включає транзакції з bundle до блоку.

Важливий нюанс: валідатор зберігає повний контроль над тим, які bundles включати. Він може відхилити пакет, якщо вважає його ризиковим, або змінити порядок транзакцій у межах власної логіки. Block Engine не може змусити лідера прийняти bundle — він лише забезпечує доставку та пропонує економічний стимул у вигляді tip.

Потік роботи

Searcher подає bundle → Block Engine → Relayer → Лідер

Повний цикл обробки виглядає так:

  1. Формування bundle. Searcher збирає набір транзакцій, впорядковує їх і додає tip — додаткову комісію, яка виплачується валідатору-лідеру за включення. Tip вказується в окремій інструкції всередині bundle.
  2. Подача до Block Engine. Searcher надсилає bundle через gRPC-API до Block Engine. Одночасно може надходити багато bundle від різних пошуковиків.
  3. Симуляція та аукціон. Block Engine симулює кожен bundle проти поточного стану ланцюга. Ті, що не проходять симуляцію, відкидаються. Серед тих, що пройшли, проводиться аукціон: bundle з найвищим tip отримує пріоритет.
  4. Передача через Relayer. Переможний bundle (або кілька, якщо вони не конфліктують між собою) передається Relayer-у, який доставляє його поточному лідеру.
  5. Включення до блоку. Лідер отримує bundle, повторно симулює його локально і, за успішного результату, додає транзакції до блока-кандидата. Tip-інструкція виконується як звичайна транзакція, і комісія надходить на рахунок валідатора.

Увесь процес від подачі bundle до включення в кандидат-блок зазвичай займає сотні мілісекунд, що критично для стратегій, чутливих до затримок.

Механізм аукціону та розподілу tips

Аукціон у Jito Block Engine є простим порівнянням tip-ів серед валідних bundle. Це не складний комбінаторний аукціон і не sealed-bid механізм — пошуковики бачать поточні умови й можуть адаптувати свої пропозиції в реальному часі.

Розподіл tip-ів прямолінійний: вся сума tip-у з bundle надходить валідатору-лідеру, який включив цей пакет. Jito Labs як інфраструктурний провайдер наразі не стягує відсоток з tip-ів — це підтверджується відкритим кодом протоколу. Проте ця модель може змінюватися, тому актуальні умови варто перевіряти безпосередньо в репозиторії Jito та офіційній документації.

Для делегаторів це означає, що валідатори, які інтегровані з Jito, отримують додатковий дохід від tip-ів поверх стандартних комісій транзакцій. Цей дохід розподіляється між делегаторами пропорційно їхнім часткам згідно з налаштуваннями комісії валідатора.

Вплив на екосистему

Яка частка блоків обробляється через Jito

Точна частка блоків, що обробляються через Jito Block Engine, змінюється від слоту до слоту і залежить від того, які саме валідатори є лідерами в цей момент. Оскільки інтеграція з Jito є добровільною, блоки створюються валідаторами як з Jito-Solana, так і зі стандартним клієнтом. Актуальну статистику частки блоків варто перевіряти в дашбордах моніторингу (наприклад, Jito Dashboard або сторонні аналітичні платформи), оскільки цей показник чутливий до часу й не є сталим.

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

Код Jito Block Engine та Jito-Solana публічно доступні на GitHub під відповідною ліцензією. Будь-хто може запустити власний Block Engine або Relayer, проте на практиці пошуковики орієнтуються на інстанси з найбільшим покриттям лідерів, щоб максимізувати ймовірність включення bundle.

Станом на зараз Jito є домінуючим, але не єдиним рішенням для MEV у Solana. Існують альтернативні підходи:

  • Пряме підключення пошуковиків до валідаторів. Деякі великі пошуковики встановлюють прямі gRPC-з'єднання з лідерами, оминаючи Block Engine. Це зменшує залежність від сторонньої інфраструктури, але вимагає індивідуальних домовленостей із валідаторами.
  • Стандартна подача транзакцій через gossip. Пошуковики можуть подавати транзакції звичайним шляхом, покладаючись на пріоритезацію за розміром комісії. Цей метод не забезпечує атомарності bundle, тому придатний лише для простих стратегій.
  • Інші блок-движки. Екосистема продовжує розвиватися, і можуть з'являтися нові реалізації з іншими моделями аукціону чи розподілу доходу. Їхній статус і рівень прийняття варто перевіряти актуально.

Для протокольних інженерів та дослідників ключове значення має те, що Jito Block Engine не змінює консенсус Solana. Він працює як додатковий шар інфраструктури поверх існуючого лідерського розкладу, використовуючи стандартні механізми виконання транзакцій. Розуміння цієї межі необхідне для коректної оцінки ризиків: якщо Block Engine вийде з ладу, мережа продовжить працювати, але MEV-стратегії, що залежать від нього, тимчасово втратять ефективність.

Детальніше про те, чому MEV є двостороннім явищем для мережі, читайте у матеріалі MEV у Solana: користь і ризики. Якщо вас цікавить розподіл стейку та інфраструктура делегування в контексті Jito — перейдіть до Як працює Jito StakeNet.