Когда про 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.Обработка бандлов в общем случае приоритетней.
Всегда держим в голове, что каждый валидатор может каким-то образом изменить логику своего валидатора, чтобы еще как-то найти способ заработать 🙂 Даже серым образом. И никто ему в этом помешать не может.
Ссылки
ссылка на оригинал статьи https://habr.com/ru/articles/1026006/