Текущее состояние и будущее MEV на Sui

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

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

Принципы проектирования и соображения

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

• Механизм отправки MEV-транзакций

• Механизм публикации MEV-возможностей

• Механизм распределения доходов MEV

• Механизм защиты пользовательских транзакций

Наши общие приоритеты следующие:

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

• Прозрачность сети предпочтительнее офлайн-транзакций с валидаторами или релейерами (relayers).

• Содействие конкуренции через аукционы приоритетного газа (priority gas auctions, PGA), подавление спам-поведения, приводящего к неэффективности системы: мы стремимся к тому, чтобы доминирующей стратегией поисковиков была отправка транзакции, приоритетная комиссия которой определяется извлекаемой стоимостью.

• Поощрение распределения вознаграждений среди участников, согласованных с экосистемой: валидаторов, стейкеров, приложений и пользователей.

Отправка транзакций

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

Ключевым драйвером аукционов приоритетного газа является квантование исполнения:

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

• Это отличается от маркетмейкеров на CEX, где приоритет исполнения полностью зависит от скорости, обеспечиваемой сетями с низкой задержкой и алгоритмами.

• Более высокая частота отправки в консенсус уменьшает эффект квантования, делая исполнение DEX более эффективным, но также сужает окно PGA.

• В настоящее время PGA для не перегруженных объектов наиболее важна для самых быстрых поисковиков. При скорости Sui 15 отправок в секунду преимущество скорости отправки транзакции в 70 миллисекунд может определить, будет ли сделка совершена.

• Перегруженные объекты могут отложить исполнение транзакции, что дополнительно усиливает важность PGA, поскольку окно конкуренции транзакций может быть в 10 раз больше обычной отправки в консенсус.

Существует два механизма для направления транзакций в конкретную предстоящую отправку Sui:

1 Отправка пакета транзакций через мягкую связку: SIP-19

🌟 SIP-19: https://github.com/sui-foundation/sips/blob/main/sips/sip-19.md

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

• На практике этот механизм позволяет проводить внецепочечные аукционы для оригинальной транзакции и ее последующих транзакций, например, транзакций, запускаемых Shio (https://www.getshio.com/explorer).

2 Усиление приоритетных транзакций через консенсус: SIP-45

🌟 SIP-45: https://github.com/sui-foundation/sips/blob/main/sips/sip-45.md

• SIP-45 решает проблему потенциального джиттера в отправке консенсуса, избегая ситуации, когда транзакции с более низкой ценой газа, отправленные в одно и то же время, оказываются после транзакций с более высокой ценой газа.

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

• SIP-45 усиливает отправку в консенсус, увеличивая цену газа выше k x RGP (k — системный параметр, в текущей конфигурации установлен на 5, RGP — справочная цена газа). Транзакция с ценой газа n x RGP будет усилена в n раз.

• Широкое применение SIP-45 создаст более эффективную и справедливую систему. Следует отметить, что SIP-45 не меняет базовые свойства системы с точки зрения клиента: она подавляет спам-поведение, предоставляя более эффективную альтернативу.

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

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

1 Аукцион приоритетного газа

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

2 Усиление отправки в консенсус

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

3 Избегание задержек и отмен из-за перегрузки

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

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

Публикация информации о транзакциях

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

1. Клиент отправляет транзакцию: Клиент отправляет транзакцию на полный узел RPC (обычно выбирается приложением).

2. Узел RPC транслирует транзакцию: Узел RPC транслирует транзакцию валидаторам, валидаторы проверяют действительность транзакции и подписывают ее, узел RPC собирает сертификат транзакции из коллективных подписей валидаторов.

3. Узел RPC транслирует сертификат транзакции: Узел RPC транслирует сертификат транзакции валидаторам.

4. Валидатор отправляет транзакцию в консенсус: Детерминированно выбранный валидатор отправляет транзакцию в консенсус. Консенсус Mysticeti транслирует блоки между валидаторами, в течение 3 раундов консенсуса блок, содержащий эту транзакцию, будет отправлен. Исполнение транзакции: Транзакция исполняется на каждом валидаторе.

5. Сертификат эффекта транзакции отправляется обратно на узел RPC и клиенту: Сертификат эффекта после исполнения транзакции возвращается на узел RPC и клиенту.

6. Генерация чекпоинта: В течение 1 до 3 раундов консенсуса каждый валидатор формирует и подписывает чекпоинт (чекпоинт — это пакет нескольких отправок в консенсус).

7. Трансляция подписи чекпоинта: Подписи чекпоинта будут транслироваться между валидаторами, каждый валидатор формирует сертификат чекпоинта.

8. Протокол синхронизации состояния распространяет чекпоинты: Протокол синхронизации состояния отвечает за распространение сертифицированных чекпоинтов через одноранговый способ. Обычно у каждого валидатора есть прямой пир, не предоставляющий RPC-запросы — полный узел синхронизации состояния, получающий чекпоинты этого валидатора.

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

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

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

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

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

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

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

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

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

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

Защита пользовательских транзакций

Пользовательские транзакции нуждаются в защите от фронтраннинга, сэндвич-атак и невольных задержек отправки.

Управление со стороны внешних участников

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

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

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

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

Быстрый путь Mysticeti

Мы в настоящее время проводим проект по изменению отправки транзакций на протокол быстрого пути, описанный в статье Mysticeti. Согласно этому протоколу, пользовательские транзакции могут быть отправлены单个 валидатору, валидатор будет использовать Mysticeti для сбора и исполнения сертификатов транзакций. Хотя это значительно повышает эффективность системы, это также предоставляет валидаторам возможность获取 пользовательские транзакции для фронтраннинга.

🌟 Статья Mysticeti: https://arxiv.org/abs/2310.14821

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

Эволюция MEV в Sui

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