MEV на Solana, Jito и локальные рынки комиссий

В Solana нет «публичного мемпула» в классическом смысле — транзакции попадают прямо к лидеру слота. Это не отменяет MEV (Maximum/Maximal Extractable Value): ценность, извлекаемая за счёт порядка включения, вставок и исключений транзакций внутри слота. Экосистема Jito формализует этот рынок через bundles (пакеты), чаевые (tips) и block engine, а «локальные рынки комиссий» распределяют нагрузку по аккаунтам, снижая взаимное «выдавливание» транзакций по всей сети.

Ниже — как это работает, какие риски возникают (например, «сэндвичи» на DEX) и что делать разработчикам/пользователям, чтобы повышать предсказуемость и снижать издержки.

Что такое MEV на Solana (и чем он отличается от EVM)

MEV — это прибыль от влияния на порядок исполнения транзакций. На Solana основные источники:

Арбитраж DEX/AMM. Быстрые ребалансы цен между пулами.
Ликвидации. Закрытие недообеспеченных позиций в лендингах.
NFT/мем-монеты. Горячие минта/аукционы с конкурирующими заявками.
Сэндвич-атаки. Вставка заявок до/после большого свопа пользователя, чтобы извлечь спред.

Особенности Solana:

Лидерство по слотам. Билдером блока выступает текущий лидер; нет общего открытого мемпула, но есть приватные каналы доставки заявок (в том числе через Jito).
Compute Units (CU). Каждая транзакция определяет лимит CU и может задать цену за CU (priority fee).
Локальные рынки комиссий. Комиссии частично «локализуются» на уровень конкретных аккаунтов, по которым идёт конкуренция за write-lock.

Вывод: к классическим MEV-практикам добавляются нюансы CU-приоритизации, write-lock contention и «локальных» аукционов на уровне аккаунтов.

Локальные рынки комиссий: идея и практика

Проблема. В Solana многие транзакции конфликтуют за write-lock одних и тех же аккаунтов (пулы, мейн-программы, «горячие» PDA). Если все конкурируют глобально, комиссия всплесками растёт для *всех*.

Решение — локализация. Вместо единого аукциона «кто больше заплатит», сеть формирует отдельные микро-аукционы по «горячим» аккаунтам. Ключевые элементы:

Priority fee = цена за CU (*micro-lamports per CU*). Транзакция добавляет инструкцию ComputeBudget.setComputeUnitPrice, по сути «чаевые» лидеру за приоритет.
Write-lock стоимость. Чем выше недавняя загрузка конкретного аккаунта (EMA по CU), тем дороже его «записать» в ближайшие слоты.
Динамика по аккаунту. Стоимость «пишущей» блокировки для «горячего» аккаунта повышается/понижается автоматически, по сути формируя локальный рынок вокруг этого ресурса.

Что это даёт:

Меньше «перекрёстного шума»: горячий пул DEX не разгоняет комиссии для транзакций, которые не пишут в его аккаунты.
Более предсказуемая конкуренция: вы понимаете, где именно возник «бутылочное горлышко» (какие аккаунты), и платите там, где нужно.

Важно: локальные рынки не «магия стабилизации», а механизм сигналов. Если архитектура dApp концентрирует все записи в один аккаунт, локальный аукцион всё равно будет нагрет — просто локально, а не для всей сети.

Priority fees и CU: как считать «приоритет»

Комиссия Solana складывается из:

Базовой части (lamports per signature).
Приоритизационной (tip per CU) — задаётся setComputeUnitPrice(microLamports).

Итого priority fee ≈ CU_used × CU_price (упрощённо). На практике в расчёт вмешиваются лимиты/параметры клиента и конкретного пайплайна, но для оценки UX это рабочая модель.

Практика для разработчиков/пользователей:

Ставьте разумный CU-лимит (setComputeUnitLimit) — недооценка ломает tx, завышение удорожает.
Калибруйте CU_price динамически: читайте сетевые подсказки RPC/релейера, чтобы не переплачивать.
Понимайте где «пишете»: если список writable-аккаунтов содержит «горячие», закладывайте повышенный приоритет адресно.

См. также Транзакция и нашу базовую заметку MEV.

Jito: как устроен «рынок пакетов»

Что такое Jito. Это альтернативный клиент и инфраструктура для формализации MEV на Solana:

Block Engine. Получает транзакции и bundles от поисковиков, симулирует и ранжирует пакеты по прибыли/надежности.
Bundles. Пакеты нескольких транзакций, которые должны исполниться атомарно в одном слоте («всё или ничего»). Это нужно для арбитража, ликвидаций и защищённых последовательностей.
Tips. Чаевые, прикладываемые к бандлам/транзакциям, — экономический сигнал лидеру включить пакет.
Private orderflow / Protect. Отправка tx вне публичных очередей, чтобы снизить фронт-раннинг и «утечки» намерений.

Как проходит жизненный цикл бандла (упрощённо): 1) Поисковик собирает бандл (набор транзакций), прикладывает tip. 2) Block Engine симулирует, выбирает конфликтно-чистые/прибыльные бандлы. 3) Победившие бандлы отправляются лидеру на включение в слот; валидаторы получают чаевые, райд-шеря их со стейкерами. 4) При конфликте и/или неудаче — бандл отклоняется целиком (атомарность).

Идея похожа на «PBS/аукционы блоков» в эфириум-мире, но адаптирована к слотовой модели Solana и её сетевому стеку.

MEV-риски и защита пользователей

Сэндвич-атаки. Когда крупный своп предсказуем, MEV-бот вставляет заявку до (двигает цену) и после (фиксация прибыли), ухудшая цену пользователю.

Как защищаться (практики UX и протокола):

Приватная подача (Jito Protect, приватные RPC) — снижаем видимость до публикации.
Жёсткая slippage и дедлайны. Консервативные параметры свопа, отображаемые пользователю.
Тайм-распыление заявок. Разбивка объёма и рандомизация отправки (с учётом риска недовыполнения).
Симуляция и превью. Кошелёк показывает ожидаемую цену до отправки, учитывая текущий стакан/пул.

Ликвидации и «гонки». Для лендингов — атомарные бандлы с предфинансированием (JIT-ликвидность) и приватной доставкой снижают риск утечек.

NFT-минты/аукционы. «Горячие» минта — локальные рынки на конкретных аккаунтах. Помогают allowlist/квоты, рандомизация, мультиподписные подтверждения.

Что означают локальные рынки для архитектуры dApp

Разработчики программ:

Деконцентрируйте записи. Не заставляйте всех писать в один PDA — по возможности используйте пер-пользовательские/пер-ордерные PDA, шардируйте состояние.
Минимизируйте writable-список. Всё, что можно читать — помечайте как read-only.
Оптимизируйте CU. Лишние вычисления = лишние приоритетные лямпорты.
Сигнальте приоритет адресно. Если есть «горячий» аккаунт, закладывайте приоритет там, а не «поднимая» весь tx.

Фронтенд/кошельки:

Показывайте разложение комиссии: базовая часть, приоритет за CU, «локальные» надбавки из-за write-lock.
Давайте подсказки по рекомендуемой CU_price и «горячим» аккаунтам из RPC.
Включайте приватные отправки как опцию по умолчанию в чувствительных сценариях (крупные свопы).

Поисковики/арбитражёры:

Сшивайте цепочки в bundles: меньше утечек, выше атомарность.
Каллибруйте tip vs CU_price: чаевые — сигнал лидеру, CU-цена — сигнал «локальному рынку».
Уважайте политику протоколов (анти-сэндвич, минимальные выходы, защита пользователей): долгосрочно тактика «хищнических» бандлов токсична для экосистемы.

Валидаторы и Jito: экономика и операционные заметки

Почему подключают Jito-инфраструктуру:

Дополнительная выручка от tips и бандлов.
Более заполненные слоты при высокой нагрузке (эффективная упаковка).
Приватная доставка, снижающая «дребезг» сети.

На что смотреть в продакшене:

Задержки сетевого стека (QUIC), насыщение ingress у лидера.
Доли tips в общей комиссии, стабильность block engine.
Совместимость с альтернативными клиентами (см. Firedancer): цель — диверсификация клиентов, без «монокультуры».

Распределение вознаграждений. В экосистеме Jito предусмотрены механизмы делиться доходом со стейкерами. Политики по пулам и делегации зависят от валидатора/сервиса.

Частые вопросы (FAQ)

Есть ли в Solana «мемпул», как в Ethereum? Не в классическом виде. Транзакции идут к лидеру, но существуют приватные очереди (в том числе у Jito), где формируются пакеты и ранжирование.

Зачем платить priority fee, если базовая комиссия низкая? Чтобы обогнать конкурентов за те же ресурсы (CU и write-lock «горячих» аккаунтов). Это «локализованный аукцион» — вы платите там, где узкое место.

Bundles — это гарантированная защита от сэндвича? Нет. Бандл даёт атомарность и снижает утечки, но политика протокола (слепые аукционы, приватные каналы) и слippage-ограничения по-прежнему нужны.

Jito — это «централизация»? Это рынок и инструменты поверх сети. Риски концентрации снижают: альтернативные клиенты, прозрачные правила, опции отказа/фоллбека к обычной доставке.

Почему мои комиссии «скачут»? Скорее всего вы пишете в «горячий» аккаунт в момент нагрузки (локальный аукцион). Снизьте объём/частоту, оптимизируйте CU, используйте подсказки RPC по CU_price.

Чек-лист для команд

Проанализируйте «горячие» аккаунты: где write-lock и почему.

Шардируйте состояние и уменьшайте список writable аккаунтов.

Включите динамический расчёт CU_price в SDK/фронтенде.

Дайте пользователям «private send» и жёсткие параметры slippage/deadline.

Для арбитража/ликвидаций переходите на bundles; балансируйте tip vs CU_price.

Валидаторам — мониторить долю tips и стабильность block engine; план отката.

Сравнение подходов упорядочивания и оплаты

Механизм	Где сигнал приоритета	Плюсы	Минусы	Кому подходит
Только priority fee (CU_price)	На уровне транзакции (за CU)	Просто, «в лоб»	Утечки намерений, сложно при сложных цепочках	Розничные пользователи, простые dApp
Локальные рынки комиссий	На уровне «горячих» аккаунтов	Изоляция аукционов, меньше глобальных всплесков	Требует правильной архитектуры аккаунтов	Любые dApp c write-lock «очагами»
Bundles + tips (Jito)	На уровне пакетов/лидера	Атомарность, меньше утечек, высокая эффективность	Сложнее DevOps, экономическая дисциплина	Поисковики, арбитраж, ликвидации
Private orderflow	В релейерах/протектах	Защита от фронт-раннинга	Доверие к провайдеру, политика включения	Крупные свопы, чувствительные операции