Що таке Jito bundles

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

Концепція Jito bundles

Визначення: група транзакцій, що виконуються атомарно

У стандартній моделі Solana кожна транзакція подається окремо через gossip-мережу та потрапляє до черги лідера. Лідер самостійно визначає порядок виконання, зазвичай керуючись рівнем priority fees. Це означає, що між двома вашими транзакціями можуть опинитися транзакції інших користувачів, що робить багатокрокові операції вразливими до фронтранінгу.

Bundle вирішує цю проблему: ви подаєте не окремі транзакції, а зв'язаний набір із жорстко заданим порядком. Лідер зобов'язаний або включити весь bundle без змін у послідовності, або відхилити його цілком.

Чому bundles потрібні в Solana

Solana обробляє транзакції паралельно завдяки Sealevel, але для багатьох стратегій критична саме послідовність. Типовий приклад: арбітраж між двома DEX вимагає купити токен на одній платформі та продати на іншій без можливості для стороннього учасника вклинитися між цими кроками. Без bundle інший учасник із вищою комісією може побачити вашу першу транзакцію в мемпулі та виконати свій арбітраж раніше.

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

Як працюють bundles технічно

Процес подачі bundle через Jito Block Engine

Bundles не подаються через стандартні RPC-вузли чи gossip-мережу. Вони направляються безпосередньо до Jito Block Engine — окремої інфраструктури, яка агрегує bundles та передає їх поточному лідеру. Block Engine підтримує власний API для прийому bundles, що ізолює цей трафік від звичайних транзакцій.

Потік виглядає так: клієнт формує bundle із впорядкованим масивом підписаних транзакцій і надсилає його на ендпоінт Block Engine. Block Engine виконує базову валідацію (перевірка підписів, структура), після чого передає bundle поточному лідеру через виділений канал.

Виконання лідером: all-or-nothing семантика

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

Важливо розуміти: all-or-nothing стосується лише включення до блоку, а не класичної атомарності бази даних. Якщо третя транзакція з п'яти впаде під час виконання, перші дві не відкотяться автоматично — просто весь bundle не буде включено до блоку. Тому коректна обробка помилок у логіці програм залишається на боці розробника.

Роль tips: винагорода лідеру за включення

Разом із bundle подається tip — додаткова винагорода лідеру за те, що він включає bundle у блок. Tip не є комісією за обробку в звичайному розумінні; це економічний стимул, який конкурує з priority fees звичайних транзакцій. Лідер обирає, що йому вигідніше: взяти bundle із певним tip або заповнити цей простір звичайними транзакціями з високими комісіями.

Tip сплачується окремою транзакцією, яка зазвичай додається до кінця bundle. Розмір tip визначає конкурентоспроможність вашого bundle відносно інших bundles та звичайних транзакцій у тому ж слоті. Конкретні мінімальні та рекомендовані значення tip змінюються залежно від кон'юнктури мережі — їх варто перевіряти в актуальній документації Jito перед інтеграцією.

Використання та обмеження

Типові сценарії: arbitrage, liquidation, DEX агенти

Арбітраж. Найпоширеніший випадок. Бот виявляє цінову різницю між двома або більше DEX і подає bundle, де перша транзакція купує на дешевшій платформі, а друга — продає на дорожчій. Атомарність гарантує, що ніхто не зможе скористатися вашою ціновою інформацією між цими кроками.

Ліквідації в кредитних протоколах. Коли позиція боржника стає підлягаючою ліквідації, кілька ботів зазвичай намагаються ліквідувати її одночасно. Bundle дозволяє поєднати перевірку стану та саму ліквідацію в один незалежний від сторонніх втручань пакет.

DEX-агенти та багатокрокові операції. Складні маршрутизації через кілька пулів, зворотні свопи, підготовка акаунтів і виконання основної транзакції — усе це може бути упаковане в один bundle, що усуває ризики на кожному проміжному кроці.

Обмеження: розмір, час життя, сумісність

Розмір bundle. Існують обмеження на кількість транзакцій та загальний обсяг даних у одному bundle. Ці ліміти залежать від поточної конфігурації Jito Block Engine і можуть змінюватися. Перевірайте актуальні значення в документації перед розробкою.

Час життя (TTL). Bundle має обмежений термін валідності. Якщо поточний лідер не зміг включити bundle, він передається наступному лідеру, але лише протягом визначеного часу. Після закінчення TTL bundle відхиляється незалежно від його коректності. Це означає, що стратегії, чутливі до затримок, повинні враховувати ротацію лідерів.

Сумісність із програмами. Не всі транзакції підходять для bundle. Транзакції, які залежать від зовнішнього стану, що може змінитися між моментом формування bundle та моментом виконання, з високою ймовірністю призведуть до відхилення всього пакета. Також слід враховувати, що деякі програми можуть мати внутрішні обмеження на частоту викликів з одного підписанта, що впливає на можливість упаковки кількох викликів в один bundle.

Залежність від інфраструктури Jito. Використання bundles означає залежність від доступності та стабільності Jito Block Engine. Якщо інфраструктура недоступна, bundle не буде подано. Для критичних систем варто передбачити fallback-механізми або альтернативні шляхи подачі транзакцій.