Когда про Jito говорят, как про основную MEV-инфраструктуру, это мешает понять суть архитектурного решения. Потому что в общем случае Jito выходит за рамки MEV. И если прорваться через некоторый объем документации, становится понятно, что основная “killer-feature”, которую дает Jito-клиент - это возможность АТОМАРНО исполнить пачку транзакций (до 5 транзакций).

Примечание: “атомарно” значит исполнить или все транзакции из пачки, или ни одной. В классической реализации Solana-ноды такого нет, и, например, отправив Лидеру слота с Agave-клиентом 5 транзакций, вы никак не сможете гарантировать, что они исполнятся последовательно в одном блоке. Между ними всегда могут вклиниться транзакции с повышенной priority fee.

А вот Jito дает прям надежный способ атомарно исполнить пачку транзакций. Именно возможность исполнить пачку транзакций атомарно и открывает большие возможности для извлечения выгоды из ончейн состояния. Например: разного вида ликвидации, backrunning, frontrunning, сэндвич-атаки. Про то, как именно пачка транзакций позволяет извлечь выгоду в каждом из этих случаев, нужно говорить отдельно. Пока просто достаточно понимать, что извлечение MEV становится КАРДИНАЛЬНО эффективней, если у вас есть гарантия свойств атомарности исполнения пачки транзакций.

Как работает Jito

В тезисах рассмотрим, какую архитектуру предложила команда Jito:

1) Валидаторы поднимают 2 сущности: релеера и рядом с ним Jito-валидатора. Все обычные транзакции (которые “вне пачек/bundles”) идут на Jito-валидатора только через релеера. Это как SQWoS транзакции, так и open connection транзакции. По сути, его можно воспринимать как обычную proxy, которая делает какие-то предварительные проверки входящих транзакций вне пачек. Каких-то отличий явных с классической реализацией нет.

Но в Jito появляется еще один дополнительный поток транзакций на валидатора, которые идут по другому каналу (и как раз тут и лежит та самая game-changing логика Jito)!

2) Jito Labs держит Block Engine инфраструктуру, которая принимает бандлы транзакций от участников, которые по какой-то своей внутренней причине (очевидно, жажда денег?), отправляют пачки транзакций. К каждому такому бандлу отправитель прикладывает tips в SOL. На этой централизованной (!) инфраструктре постоянно происходит аукцион: Block Engine умным образом отбирает наиболее выгодные бандлы для Jito-валидаторов, приоритезирует их в очереди обработки и отправляет на текущего Leader.

То есть Block Engine постоянно в реальном времени стримит “бандлы-победители” текущим Лидерам с Jito-клиентом.

3) Валидатор-лидер с Jito-клиентом принимает бандлы от Block Engine и последовательно их исполняет. Если бандлов нет, то исполняются транзакции, поступающие через релеера (самый обычный канал с самыми обычными транзакциями вне пачек от кого-угодно).

4) За каждый добавленный в блокчейн бандл Leader зарабатывает приложенные отправителем tips, что ощутимо увеличивает его доход и доход его делегаторов.

Вывод

Таким образом, самое важное, что нужно осознать, что в Jito-имплементации на текущего Лидера транзакции идут по двум потокам:

1) Через Relayer: с этих транзакций валидатор зарабатывает priority fee.

2) Через централизованную инфраструктуру Jito, которая называется Block Engine: с добавления бандлов в блок валидатор зарабатывает tips и минимальный приложенный priority fee.Обработка бандлов в общем случае приоритетней.

Всегда держим в голове, что каждый валидатор может каким-то образом изменить логику своего валидатора, чтобы еще как-то найти способ заработать :) Даже серым образом. И никто ему в этом помешать не может.

Ссылки

1. https://www.eclipse.xyz/articles/how-jito-works--on-solana-deep-dive

2. https://jito-foundation.gitbook.io/mev/solana-mev/birds-eye-view

3. https://www.youtube.com/watch?v=owLlIRXQvo8&pp=ygULaml0byBzb2xhbmHSBwkJAwoBhyohjO8%3D

4. https://www.youtube.com/watch?v=wXBWb2LrD08