Развитие и будущее MEV в сети Sui

MEV (максимально извлекаемая ценность) стал одной из наиболее обсуждаемых тем в индустрии блокчейна, касающейся сортировки транзакций и арбитражных возможностей. Для повышения прозрачности, защиты транзакций, поддержания здоровья сети и вознаграждения участников сеть Sui последовательно внедряет целевую реализацию предложений по улучшению и других механизмов для управления развитием MEV в сети.

Помимо существующих механизмов, Sui планирует создать больше механизмов, чтобы обеспечить руководство своим основным принципам в эволюции MEV в сети.

Принципы проектирования и факторы, которые необходимо учитывать

Каждая транзакция в сети Sui вводит новую информацию, создавая потенциальные возможности для арбитража. Экосистема MEV на Sui формируется через несколько механизмов:

• Механизм подачи заявок на MEV-трейдинг
• Механизм публикации возможностей MEV
• Механизм распределения прибыли MEV
• Механизм защиты сделок пользователей

Общие приоритеты Sui следующие:

• Защита сделок пользователей имеет приоритет перед извлечением ценности. Предпочтение отдается меньшему проскальзыванию, а не большему извлечению ценности. Избегайте протокольных аукционов с увеличением задержки и без опции выхода.
• Прозрачность сети имеет приоритет над внебиржевыми сделками с узлами проверки или ретрансляторами.
• С помощью приоритетного аукциона газа (PGA) стимулировать конкуренцию, сдерживать мусорные действия, приводящие к неэффективности системы: в идеале оптимальная стратегия искателя заключается в отправке транзакции, приоритетная плата за которую определяется извлеченной ценностью.
• Поощрение распределения вознаграждений среди участников, чьи интересы соответствуют интересам экосистемы: узлы проверки, ставщики, приложения и пользователи.

Подтверждение сделки

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

Ключевым фактором PGA является количественная оценка выполнения:

• Транзакции, отсортированные по консенсусу, обрабатываются в блоке. Трейдеры конкурируют за приоритет через аукцион газа, как внутри одной подачи, так и между различными подачами.
• Это отличается от маркетмейкеров централизованных бирж, чья приоритетность выполнения полностью зависит от скорости, достигаемой за счет низколатентных сетей и алгоритмов.
• Более высокая скорость подачи консенсуса уменьшила количественный эффект, сделав децентрализованные сделки более эффективными, но также сузила окно PGA.
• В настоящее время PGA для незащищенных объектов наиболее важен для самых быстрых искателей. При скорости 15 подтверждений в секунду в Sui, преимущество в скорости подтверждения транзакции в 70 миллисекунд может определить, будет ли сделка завершена.
• Объекты перегрузки могут задерживать выполнение транзакций, что еще больше подчеркивает важность PGA, поскольку окно конкурирующих транзакций может быть в 10 раз больше, чем обычные подтверждения консенсуса.

Существует два механизма, которые могут направить транзакции на конкретные предстоящие提交 Sui:

1. Подайте партию транзакций через мягкую привязку

• Сделанные через мягкую упаковку транзакции имеют высокую вероятность быть включенными в одно и то же подтверждение консенсуса с действующей упаковкой. Условие действительности упаковки требует, чтобы цена газа всех транзакций была одинаковой.
• На практике этот механизм позволяет проводить аукционы вне цепи как для оригинальных транзакций, так и для последующих.

2. Увеличение приоритетных транзакций через консенсус

• Этот механизм решает потенциальные проблемы дрожания при подаче консенсуса, предотвращая ситуацию, когда сделки с более низкой ценой газа, поданные одновременно, ставятся после сделок с более высокой ценой газа.
• Два естественных источника колебаний в процессе консенсуса: (1) узлы верификации отстают на несколько раундов консенсуса: транзакции, отправленные другим узлом верификации, могут сначала сортироваться. (2) лидер раунда консенсуса имеет преимущество перед другими узлами верификации при отправке.
• Этот механизм увеличивает выше k x RGP(, где k является системным параметром, текущая настройка равна 5. RGP - это справочная цена газа, а ) цена газа для усиления подачи консенсуса. Транзакции с ценой газа n x RGP будут увеличиваться в n раз.
• Широкое применение этого механизма создаст более эффективную и честную конкурентную систему. Следует отметить, что этот механизм не изменит основные свойства системы с точки зрения клиента: он сдерживает мусорное поведение, предоставляя более эффективные альтернативы.

Выбор подходящей цены за газ для торговли

Клиент должен учитывать следующие основные факторы для определения цены газа при отправке транзакции:

1. Приоритетный аукцион газа

В рамках подачи консенсуса транзакции, изменяющие один и тот же объект, сортируются по цене газа, что предоставляет искателям равные возможности для конкуренции.

2. Увеличение подачи консенсуса

Как упоминалось выше, сделки с ценой газа выше 5 x RGP отправляются на консенсус через n верификационных узлов для увеличения консенсуса. Любая цена газа, превышающая порог увеличения, уменьшит колебания неэффективных подач. На практике множитель 5 достаточно для устранения колебаний, в то время как цена газа 100 x RGP с высокой вероятностью разблокирует подачу следующего лидера.

3. Избегайте задержек и отмен.

Sui ограничивает время выполнения контрольных точек, контролируя скорость транзакций для одного и того же общего объекта. Транзакции, модифицирующие объекты с перегрузкой, сортируются по цене газа, и транзакции с более низкой ценой откладываются и в конечном итоге отменяются, чтобы ограничить самую длинную последовательную цепь выполнения для каждой контрольной точки. Это механизм, известный как основанный на объекте локальный рынок сборов. ( Обратите внимание, что хотя общие объекты могут предоставить высокие арбитражные возможности, цена газа может резко вырасти, но другие части системы остаются неизменными. )

Полные узлы отслеживают выполнение и отмену транзакций с ценой газа, особенно в случае транзакций, связанных с изменением объектов перегрузки. Результаты тестирования транзакций могут предоставить информацию о ценах газа для выполненных транзакций с самой низкой ценой и отмененных транзакций с самой высокой ценой. Используя эту информацию, клиент может определить необходимую цену газа, чтобы с высокой вероятностью избежать задержек в транзакциях. ( Обратите внимание, что эта функция в настоящее время реализована лишь частично и ожидается, что будет выпущена как часть SDK в течение следующих двух месяцев. )

Публикация информации о сделках

Каждая транзакция в Sui создает потенциальные возможности для арбитража. Рассмотрим жизненный цикл транзакции с общим объектом, начиная с момента отправки клиента до того, как третья сторона увидит ее эффект:

1. Клиент отправляет транзакцию: Клиент отправляет транзакцию на RPC полное узло (, обычно выбираемое приложением ).
2. RPC-узел транслирует транзакцию: RPC-узел транслирует транзакцию проверочным узлам, проверочные узлы подтверждают действительность транзакции и подписывают её, RPC-узел собирает сертификат транзакции из коллективной подписи проверочных узлов.
3. Шифрование транзакционных сертификатов RPC: узлы RPC транслируют сертификаты транзакций узлам проверки.
4. Подтверждение узлов о подаче транзакций: определенный детерминированный узел подтверждения подает транзакцию для консенсуса. Консенсус транслирует блоки между узлами подтверждения, и блок, содержащий эту транзакцию, будет подан в течение 3 раундов консенсуса.
5. Исполнение сделки: Сделка выполняется на каждом узле проверки.
6. Сертификат результата транзакции отправляется обратно на RPC-узел и клиент: сертификат результата, полученный после выполнения транзакции, будет возвращен на RPC-узел и клиент.
7. Генерация контрольной точки: в течение 1-3 раундов консенсуса каждый узел-валидатор формирует и подписывает контрольную точку (, контрольная точка является пакетной обработкой нескольких консенсусных заявок ).
8. Распространение подписи контрольной точки: подпись контрольной точки будет распространяться между узлами верификации, каждый узел верификации формирует сертификат контрольной точки.
9. Проверка распространения контрольных точек протокола синхронизации состояния: протокол синхронизации состояния отвечает за распространение проверенных контрольных точек посредством одноранговой связи. Обычно каждый валидирующий узел имеет прямой пир, который не предоставляет RPC-запросы — полный узел синхронизации состояния, который получает контрольные точки от этого валидирующего узла.
10. Проверка контрольной точки для узлов третьих сторон: узлы третьих сторон, подключенные к полному узлу синхронизации состояния, получают контрольную точку и загружают ее содержимое. В этот момент мы предполагаем, что третья сторона, подключенная непосредственно к полному узлу, может обработать эффекты транзакции и отреагировать на них.

Распространение информации о сделке перед ее отправкой

Как упоминалось ранее, Sui имеет внецепочечную систему аукционов для подачи мягкой упаковки. Эти аукционы перехватывают подачу транзакций через внецепочечный протокол между приложением и системой аукционов.

Это предположение о распространении информации предполагает, что аукционная система работает хорошо и может защищать транзакции пользователей от потенциальных атак с夹击. Аукционная система мотивирована защищать транзакции пользователей, чтобы поддерживать свой бизнес, поэтому она использует некоторые аукционные приемы, такие как ( приманочные сделки, случайные задержки ), чтобы ослабить финансовые выгоды от потенциальных夹击-ботов.

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

Консенсус Блокчейн Потоковая передача

Для обеспечения низкой задержки доступа пользователей к транзакциям Sui разрабатывает систему прямой потоковой передачи блоков консенсуса. В целом, полные узлы смогут напрямую подписываться на блоки консенсуса.

Таким образом, полные узлы могут спекулятивно уведомлять о транзакциях, которые с высокой вероятностью будут подтверждены. Сетевая топология использует стандартный протокол обнаружения пиров с открытым состоянием синхронизации.

Это уведомление о спекуляции может значительно сократить задержку распространения сделок, всего около 160 миллисекунд ( два раунда консенсуса ), после того как узлы-валидаторы отправят свои данные.

Проект потоковой передачи блоков консенсуса в настоящее время находится на стадии проектирования, и ожидается, что в течение следующих 1-2 месяцев будет представлен улучшенный проект.

Защита торговых операций пользователей

Пользовательские сделки должны быть защищены от влияния фронт-раннинга, ловушек и задержек непроизвольной подачи.

Внешние члены приводят в действие

Отправка транзакции Sui требует внешнего участия, обычно выполняется полными узлами.

Если проверяющий узел получает запрос на отправку транзакции t и хочет инициировать новую транзакцию t', он будет отставать от оригинального драйвера участников в процессе сборки сертификатов. Если только поданный полный узел не имеет плохого соединения с участниками Sui, проверяющий узел будет отставать от t в процессе сборки сертификатов для t'.

Кроме того, поскольку подача консенсуса t децентрализована, как только сертификат t достигает консенсуса, его невозможно надежно отложить. Таким образом, если сертификат t достигает консенсуса Sui до t', то t с высокой вероятностью будет урегулирован до t'.

Таким образом, внешний членский драйв обеспечивает естественную предварительную защиту, предположим, что доверие к полным узлам, отвечающим за отправку транзакций (, из-за предварительных атак можно легко обнаружить в цепочке, эти атаки будут зарегистрированы клиентом и подорвут репутацию операторов RPC ).

Быстрый путь

Sui в настоящее время реализует проект, который изменяет подачу транзакций на протокол быстрого пути. Согласно этому протоколу, пользовательские транзакции могут быть поданы одному верификатору, который будет использовать механизм консенсуса для сбора и выполнения сертификатов транзакций. Хотя это значительно повышает эффективность системы, это также предоставляет верификаторам возможность получить предварительные транзакции пользователей.

Этот риск чисто теоретический, так как в настоящее время нет доказательств того, что на Sui произошла атака с предварительной транзакцией. В новой системе вероятность предварительных транзакций выше, но с другой стороны, из-за определенности в отношении валидирующих узлов легче привлечь их к ответственности.

Эволюция MEV на Sui

Экосистема MEV Sui все еще формируется, и в конце этого года будут представлены новые механизмы. В настоящее время приоритетные аукционы газа и увеличение консенсуса определяют текущую систему, в то время как предстоящие инновации, такие как шифрование с временной блокировкой и быстрый путь, изменят исполнение сделок и безопасность. С запуском этих механизмов MEV на Sui будет продолжать развиваться, создавая более динамичную и прозрачную экосистему.