MEV (7): Более справедливая экосистема MEV (Заключение)

Средний1/14/2024, 6:19:20 PM
Эта статья знакомит с амбициозным SUAVE — дизайном рынка MEV, обеспечивающим программную конфиденциальность, большую эффективность, справедливость и межцепочность.

Эта статья познакомит вас с функцией «Программируемая конфиденциальность», которая обеспечивает более продвинутые транзакции и кросс-чейн, более открытый и справедливый дизайн рынка MEV - SUAVE. Прежде чем перейти к основной теме объяснения SUAVE, пожалуйста, сначала поймите концепцию Намерения.

Намерение

Текущий опыт использования транзакций блокчейн

Возьмем транзакции Ethereum в качестве примера. Предположим, пользователь хочет обменять свои USDT на ETH. Он может перейти на веб-страницу Uniswap, чтобы проверить цену, и после установки допустимого ценового проскальзывания подписать и отправить транзакцию, а затем дождаться результата транзакции.

Его транзакция, вероятно, будет выглядеть примерно так: «Я подписываю и отправляю эту транзакцию со значением Nonce 23 и комиссией за газ 30 Гвей. Она выполнит контракт Uniswap для обмена моих 1000 USDT на 0,5 ETH с максимальным проскальзыванием 1%.

△ Нонс? Гвей? Источник изображения:https://www.reddit.com/r/MemeRestoration/comments/ejcvd3/confused_math_lady_4080x2663px

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

  • Первое - найти канал обмена. Предположим, она ищет в Google и находит страницу Uniswap (по крайней мере, там есть понятное меню цифровых активов и кнопка Swap), а затем ей нужно понять и установить проскальзывание (или использовать значение по умолчанию).
  • После нажатия кнопки Обмен, появляется экран подписи транзакции, который содержит Nonce и Gwei комиссии за обработку.
  • Наконец, она отправляет транзакцию, но, вероятно, ничего не происходит, и Алиса может только ждать в замешательстве и молиться, чтобы транзакция была успешно выполнена.

Каждый уровень - это вопрос, который начинающим пользователям на самом деле не нужно понимать, но им приходится делать выбор: Где осуществить погашение? Хотите установить slippage? Какой процент следует установить для slippage? Хотите отрегулировать газовый сбор (комиссию)? На какое количество Gwei его нужно отрегулировать? Почему транзакция не удалась? Почему транзакция застряла там настолько долго (может быть, проблема с Nonce или комиссией)? Что мне делать?

Опыт использования транзакций намерений

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

В намерении Алиса указала, что 1000 USDT должны быть обменяны на 0.5 ETH, но с учетом комиссии за обработку цена была скорректирована до 0.495 ETH, после чего заказ был подписан и отправлен. Транзакция Алисы будет выглядеть так: "Я подписываю и отправляю этот заказ. Я хочу обменять 1000 USDT на 0.495 ETH. Этот заказ действителен до тех пор, пока я не получу 0.495 ETH."

Это очень просто, верно? Это опыт использования лимитного ордера (Limit Order), а также общий опыт использования DEX Агрегаторов (таких как 1inch и Tokenlon).

△ Разница между Транзакцией (вверху) и Намерением (внизу). С Намерением пользователи должны только указать условия и не беспокоиться о том, как их достичь. Подпись:https://www.paradigm.xyz/2023/06/intents

Через Intent пользователям больше не нужно иметь дело и беспокоиться о различных утомительных и запутанных деталях между генерацией, подписанием и выполнением транзакций. Они даже не должны разбираться в проблеме и продолжать пытаться, когда транзакция не удается. Более того, у разных цепочек будут различные процессы и подводные камни транзакций!

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

Намерение значительно улучшит опыт блокчейн.

Совет по чтению 1: На самом деле уже существует много примеров использования Намерения, таких как подпись кошелька с мультиподписью, концепция Ключа Сеанса, предоставляющего третьей стороне конкретные права на выполнение и временные ограничения, или механизм пакетного соответствия транзакций, например CowSwap. Даже в мире Web2 есть следы Намерения, такие как поисковые системы (я ввожу то, что хочу запросить, и поисковая система находит для меня соответствующую информацию через различные каналы) или электронная коммерция онлайн-съемка (я ввожу то, что хочу купить) что-то, компания по электронной коммерции нашла это через различные каналы и доставила мне). Просто слово Намерение только недавно стало популярным в мире Web3.

Совет по чтению 2: На английском языке слово Imperative («императив») используется для описания опыта использования транзакции, которая заключается в выдаче полной команды для достижения цели; тогда как слово Declarative («утвердительное») используется для описания опыта использования намерения. Описательное, указывая, что оно используется путем указания условий выполнения и результатов выполнения.

Намерение в мире кросс-цепочек

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

Исключая кросс-цепочечные приложения через мультиподпись проектной стороны, это может обеспечить лучший пользовательский опыт (например, после того, как пользователь отправит транзакцию на исходной цепочке, мультиподпись проектной стороны автоматически отправит активы пользователю на целевой цепочке). Указанный адрес не требует от пользователя выполнения каких-либо операций на целевой цепочке). Другие более децентрализованные кросс-цепочечные приложения, такие как Nomad и Succinct, не обладают таким хорошим опытом. Пользователям может потребоваться отправлять транзакции на целевую цепочку для завершения операции.

Поэтому улучшение пользовательского опыта, которое может принести Intent, становится еще более важным и срочным в мире кросс-цепочек.

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

СУАВЭ

Полное название SUAVE - Single Unifying Auction for Value Expression, целью является стать унифицированным рынком MEV через несколько цепей. На этом рынке пользователи могут выражать условия закрытия и вознаграждения сделки эффективным способом. В то же время исполнители (Executors) будут конкурировать друг с другом и эффективно сотрудничать для выполнения запросов пользователей.

SUAVE может служить пулом транзакций для блокчейна, а также выступать в качестве роли Builder, ответственной за создание содержимого блоков этого блокчейна. Тем не менее, SUAVE не предназначен для замены существующего пула транзакций и функциональности Builder блокчейна, а скорее для беспрепятственного подключения к существующему блокчейну в режиме plug and play.

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

От Flashbot до MEV-Boost до SUAVE

От Flashbot до MEV-Boost, дух, которым они руководствуются, заключается в признании существования MEV и стремлении вывести скрытую экономическую деятельность на первый план. Они стремятся создать публичный рынок, в котором может участвовать любой, чтобы избежать ситуации, в которой некоторые лица молча контролируют и доминируют в этом огромном экономическом интересе, что постепенно приводит к концентрации ресурсов в их руках и в конечном итоге влияет на децентрализацию и безопасность всей сети блокчейн.

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

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

Еще одним явлением, которое повлияет на централизацию и безопасность, является Частный Порядок Потока: транзакции пользователей больше не попадают в общий пул транзакций, а напрямую поступают к Искателю или Строителю. Частный Порядок Потока может происходить от Искателя или Строителя, покупающих право на получение дохода от транзакций пользователей, или Строителя, предоставляющего привлекательные услуги, такие как (1) бесплатная отмена транзакций или ордеров на DEX, отправленных пользователями, или (2) предоставление Предварительного Подтверждения, до получения транзакции пользователь уверен, насколько быстро будет получена транзакция, чтобы пользователю не приходилось беспокоиться о том, будет ли транзакция получена и сколько времени займет ее получение.

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

Почему блоки от транзакций пользователей к Bundle, созданному Searcher, должны собираться через Private Order Flow? Это связано с тем, что содержимое транзакции и Bundle является публичным и незашифрованным. Если они увидены и получены другими, это может причинить вред пользователю или Searcher. Например, другие могут извлечь MEV из транзакции пользователя через атаку щипцами или разобрать Bundle, вырвав MEV. Поэтому пользователи и Searchers в настоящее время должны доверять Builder, поскольку им необходимо передавать оригинальное содержимое транзакции и Bundle Builder и доверять, что Builder не причинит вреда.

Появление SUAVE направлено на решение рисков централизации, вызванных международным MEV и частным потоком ордеров.

Во-первых, установив публичный рынок, который обслуживает MEV межцепочку, пользователи или искатели могут выразить свои доходные условия для транзакций или пакетов на этом рынке. Например, если у пользователя есть две транзакции, которые должны быть направлены соответственно на Ethereum и Arbitrum, и обе транзакции должны быть включены и выполнены до определенного времени, они могут указать эти условия на рынке. Исполнители на рынке (которые могут быть искателями или строителями) будут конкурировать, чтобы выполнить эти запросы и заработать награды. Но как пользователи или искатели могут доверять тому, что они бросают свои транзакции или пакеты на этот публичный рынок? Вот где вступает технология конфиденциальности. Зашифровав транзакции, пользователи или искатели больше не должны беспокоиться о потенциальном вреде, причиненном другими просмотром их транзакций. Только с конфиденциальностью транзакций возможен открытый поток заказов.

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

По сравнению с полностью зашифрованными транзакциями, транзакции, которые раскрывают конкретную информацию, могут быть включены в пакеты или блоки более эффективно и быстро, и даже получать откаты, как подробно описано в разделе четвертой статьи «MEV-Share». Раскрывая конкретную информацию, пользователи могут даже сотрудничать друг с другом. Поисковик Б может строиться на связке Поисковика А: связка Поисковика А следует за транзакцией пользователя для арбитража, а связка Искателя Б следует за связкой Искателя А для арбитража. Конфиденциальность имеет важное значение для потока открытых ордеров. Конфиденциальность позволяет пользователям иметь возможность сотрудничать друг с другом, принося пользу друг другу, а не конкурируя за возможности MEV.

Другие преимущества SUAVE

  • Через SUAVE кросс-цепочечные транзакции DEX могут получить лучшие цены, а кросс-цепочечные намерения могут быть выполнены более эффективно.
  • Если SUAVE рассматривать как огромного, но децентрализованного строителя, у него будет больше преимуществ, чем у централизованного строителя, потому что он собирает больше потоков заказов, что также может привлечь больше строителей, чтобы присоединиться к SUAVE, и далее снизить риски, вызванные централизацией строителей.
  • Через SUAVE каждая цепь не должна строить свой собственный частный пул транзакций и свой собственный рынок MEV цепи и может сосредоточить свои ресурсы и энергию на решении других проблем или предоставлении лучших услуг.

архитектура SUAVE

Доска объявлений для пользовательских предпочтений

SUAVE можно описать как «доску объявлений пользовательских предпочтений». Термин «Пользователь» здесь не обязательно относится к общим пользователям блокчейна, но Поисковики также могут быть Пользователями SUAVE. В дальнейшем термин «Пользователь» будет относиться к общим пользователям блокчейна, а «Пользователь SUAVE» будет относиться к пользователям SUAVE.

Предпочтение пользователей SUAVE похоже на специализированный интент, сосредоточенный на сортировке транзакций. Это не похоже на общие интенты, которые читатели могут видеть в других местах и которые могут указывать различные условия. Подобно тому, как пользователи указывают предпочтения и условия в интентах, в Предпочтении пользователи SUAVE указывают предпочтения или условия для «транзакций или дохода от пакетов, поступающих в блок», такие как:

  • «Я хочу, чтобы моя транзакция была отсортирована перед транзакцией 0xabcd и была включена до блока 110050». Фактически, это похоже на условия, указанные в Bundle of Searcher при использовании Flashbot.
  • “Я хочу, чтобы мой пакет был включен и принес мне 0.05 ETH дохода.”
  • "Я хочу, чтобы Намерение A и Намерение B были включены в блок 1001 цепочки X и блок 50900 цепочки Y соответственно." \

Совет по чтению: Пользователи также могут отправлять общие транзакции блокчейна (без указания каких-либо предпочтений) в SUAVE, то есть просто использовать SUAVE в качестве общего торгового пула или Flashbot, например, напрямую отправлять свои транзакции по переводу ETH или транзакции Uniswap в SUAVE.

Конечно, если вы просто укажете условия, нет необходимости разрабатывать новую архитектуру для этого, просто используйте оригинальный Flashbot. Так что на самом деле Предпочтения, указанные в SUAVE, должны соответствовать вознаграждениям, в противном случае никто не будет готов выполнить ваши Предпочтения безусловно. Конечно, предпосылкой для оплаты должно быть то, что Предпочтения были достигнуты.

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

  • «Я хочу, чтобы моя транзакция была отсортирована до транзакции 0xabcd и была включена до блока 110050. Если это будет достигнуто, я дам вам 3 ETH».
  • «Я хочу, чтобы мой пакет был включен и принес мне доход в размере 0,05 ETH. Если это будет достигнуто, я дам вам 0,02 ETH».
  • «Я хочу, чтобы Намерение A и Намерение B были включены в 1001-й блок цепи X и 50900-й блок цепи Y соответственно. Если это будет достигнуто, я дам вам 1.8 ETH».

Архитектура

SUAVE можно рассматривать как состоящий из трех компонентов: Среда Предпочтений, Рынок Исполнения и Децентрализованное Формирование Блоков.

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

△ ПЕ слева собирает намерения и арбитражные транзакции на различных цепях, а затем Исполнители посередине пытаются удовлетворить эти Предпочтения и упаковать их в Бандлы, передавая эти Бандлы роли справа, которая имеет право на производство блоков, чтобы собрать блоки. Источник изображения:https://writings.flashbots.net/the-future-of-mev-is-suave

SUAVE будет иметь свою собственную цепочку и пул транзакций. SUAVE называет цепочку Уровнем Расчетов и пул транзакций Уровнем Сообщений.

Смарт-контракты могут быть развернуты на цепочке для установления контрактов между Preference и rewards. Пул транзакций будет заполнен транзакциями, в которых пользователь SUAVE объявляет Preference, а Executor получает вознаграждение.

Жизненный цикл транзакции SUAVE

  1. Выражение предпочтения: Пользователь SUAVE указывает предпочтение и делает ставку на один или несколько своих намерений/транзакций.
  2. Оптимизация выполнения: исполнитель находит путь выполнения, который удовлетворяет пользовательские предпочтения, и даже может найти оптимальный путь для этого.
  3. Расчет предпочтений: Пакет(ы) исполнителя успешно включены в блок целевой цепи и соответствуют предпочтениям, указанным пользователем SUAVE.
  4. Расчет платежей: Оракул возвращает статус целевой цепи на цепь SUAVE, и Исполнитель выполняет смарт-контракт. После того как контракт подтверждает, что Предпочтение было удовлетворено, Награда SUAVE User передается Исполнителю.

△ Предпочтение четыре шага от создания до исполнения до урегулирования. Источник изображения:https://dba.mirror.xyz/NTg5FSq1o_YiL_KJrKBOsOkyeiNUPobvZUrLBGceagg

MEVM

SUAVE должен иметь возможность писать Предпочтение на языке программирования и преобразовывать его в смарт-контракт, чтобы выполнить контракт между Пользователем SUAVE и Исполнителем. Ожидается, что SUAVE разработает специфический для MEV EVM на основе EVM - MEVM.

MEVM добавит новый контракт предварительной компиляции и тип транзакции специально для MEV. Предпочтения пользователя, Упаковка пакета и Функции построения блока могут быть легко выполнены в MEVM.

Приведенный ниже образец программного кода записывает алгоритм построения блока с использованием эффективной цены газа (EGP) с использованием языка Solidity и контрактов MEVM Precompile.

EGP Block Building сортирует пакеты в соответствии с ценой газа, указанной для каждого пакета. Пакеты с более высокой ценой газа будут расположены в начале блока:

△ Розовая функция на картинке - это предварительная функция MEVM, специально разработанная для использования MEV. Источник изображения:https://writings.flashbots.net/mevm-suave-centauri-and-beyond

Совет по чтению: Выполнение алгоритма построения блока на самом деле не происходит на цепи SUAVE Chain, но Block Builder имитирует выполнение вне цепи (как узел будет имитировать выполнение транзакции локально), поэтому этот процесс выполнения на самом деле не станет транзакцией, занимающей блочное пространство и вычислительные ресурсы SUAVE Chain, и не будет ограничен производительностью цепи SUAVE.

Через композицию контракта EVM Searcher и Searcher или Searcher и Builder смогут сотрудничать через контракты, заменяя исходное одностороннее доверие. Сотрудничество также дополнительно улучшит эффективность Bundle и извлечет больше MEV, что может принести пользу каждому участнику цепочки поставок MEV. Кроме того, участники могут напрямую использовать инструменты разработки на основе EVM и инфраструктуру, такие как RPC Provider, тестовые инструменты, такие как Foundry и т.д., а опыт разработки будет очень хорошим.

Более того, MEVM предоставит функцию конфиденциальности транзакций, потому что без конфиденциальности нет возможности сотрудничества. Без конфиденциальности поисковики должны беспокоиться о том, что их MEV могут быть украдены. На раннем этапе эта конфиденциальность будет достигнута благодаря доверенному аппаратному обеспечению SGX. Транзакции будут зашифрованы, а затем отправлены в SGX для выполнения. Предполагается, что SGX будет выполнять свои назначенные программные коды, не воруя MEV по своему усмотрению. В будущем, когда другие передовые криптографические технологии постепенно станут зрелыми, криптография сможет заменить доверенное аппаратное обеспечение. Для получения дополнительной информации обратитесь к предыдущей статье наЗашифрованные Mempools.

Совет по чтению: Однако есть и недостатки, основанные на EVM, такие как EVM слишком выразителен: на самом деле для написания функций, необходимых для MEV, в EVM не требуется много операций. Разрешение использовать эти операции может позволить людям, готовым писать очень сложные исполнения, а затем позволить транзакции завершиться неудачно в конце исполнения, вызвав потерю узлом множества вычислительных ресурсов, что является атакой DoS. Проект Anoma перерабатывает язык программирования и среду выполнения специально для выражения и выполнения намерений. В будущем SUAVE также может использовать архитектуру Anoma для замены MEVM.

Подключение и использование SUAVE

Если разработчик блока или валидатор цепи знает о существовании SUAVE и намерен использовать SUAVE, то он будет рассматривать SUAVE как строителя блоков. Если SUAVE предоставляет более высокую цену на торги за построенные им блоки, то майнеры или валидаторы будут использовать блоки SUAVE. Возьмем текущий MEV-Boost на Ethereum в качестве примера: блоки, составленные SUAVE, будут преобразованы в формат, соответствующий механизму торгов MEV-Boost через плагин, предоставленный SUAVE. Предлагающему не нужно вносить изменения, чтобы использовать блоки SUAVE.

Если разработчик блока или проверяющий цепи не знает о существовании SUAVE, тогда Исполнитель SUAVE сделает ставку, чтобы получить свой Bundle в соответствии с правилами комиссии цепи.

Проблемы кроссчейн MEV

У каждой цепи свой блок разработчик и валидатор. Прием блока B1 SUAVE цепью X не означает, что блок B2 будет успешно получен валидатором цепи Y. Механизмы производства блоков и рынки цепи X и цепи Y независимы. Если только цепи X и Y используют Общий Последователь, и тот же Последователь производит блоки для обеих цепей одновременно, то только объединяя SUAVE мы можем обеспечить Атомарное Включение: две цепи не должны «собирать определенные транзакции (или блоки) вместе». Юань)», или «вообще нет дохода».

Даже если Shared Sequencer может гарантировать Атомное Включение, это не означает, что транзакция будет "успешно" выполнена после включения. Если обе транзакции не были выполнены "успешно", это означает, что межцепочная MEV не удалась. Предположим, что пользователь SUAVE хочет завершить межцепочную арбитражную сделку, транзакции на обеих цепях должны быть сгенерированы в реальном времени и успешно выполнены, прежде чем он сможет получить выгоду:

  • Если Пользователь SUAVE не готов нести риск неудачного выполнения транзакции, то его Предпочтение потребует, чтобы обе транзакции были успешно выполнены, прежде чем они будут завершены, и затем Исполнитель будет оплачен, а Риск будет нести Исполнитель. Он может ограничить «результат успешного выполнения», указав статус на цепи, например, указав, что контракт должен излучать определенное Событие, или указав, насколько баланс токенов определенного адреса должен быть больше. Затем Исполнитель, готовый рисковать, попытается сделать обе транзакции реальными и успешно выполненными в реальном времени. Если только одна из них окажется полученной или выполнение одной из транзакций «неудачно», Исполнитель не получит вознаграждение.
  • Если пользователь SUAVE готов к риску, то его Предпочтение может требовать только получение обеих транзакций, и также допускается неудачное выполнение транзакции (т. е. откат транзакции). Исполнитель все равно будет стараться выполнить обе транзакции успешно (успешное выполнение может привести к большему вознаграждению), но пока есть доход, вы можете получить вознаграждение.

Взяв нижеприведенное изображение в качестве примера, пользователь SUAVE хочет выполнить арбитраж транзакций между цепями Rollup 1 и Rollup 2: купить один ETH по более низкой цене на Rollup 1 и продать один ETH по более высокой цене на Rollup 2.

Если обе сделки оплачиваются в реальном времени и успешно исполняются, Пользователь SUAVE может заработать разницу в цене. Сценарии 1 и 2 в таблице на изображении соответствуют «Пользователь SUAVE готов самостоятельно нести риск» и «Исполнитель готов нести риск» соответственно.

Нижние три столбца таблицы - «награды за оба успешных», «награды за только один успех» и «окончательный результат за только один успех»:

  • Вознаграждения за обе успешные транзакции (Пользователь SUAVE зарабатывает разницу в цене):
    • Сценарий 1: Пользователь SUAVE платит исполнителю $50 комиссию за обработку.
    • Сценарий 2: Пользователь SUAVE платит Исполнителю комиссию за обработку в размере 70 долларов США (дороже, потому что Исполнитель несет риск).
  • Есть только одно вознаграждение за успех (пользователь SUAVE не заработал спред):
    • Сценарий 1: Пользователь SUAVE выплачивает исполнителю плату в размере 25 долларов. Пользователи SUAVE несут риски сами.
    • Сценарий 2: Пользователь SUAVE не должен платить комиссии или рисковать.
  • Есть только один успешный результат (SUAVE User не заработал спред):
    • Сценарий 1: Пользователь SUAVE платит исполнителю комиссию в размере $25 и имеет дополнительные ETH в наличии.
    • Сценарий 2: Пользователю SUAVE не нужно платить комиссию за обработку Исполнителю и не будет иметь на руках лишнего ETH. А у Executor в руке еще один ETH.

△ Разные результаты выполнения в различных ситуациях. Источник изображения:https://dba.mirror.xyz/NTg5FSq1o_YiL_KJrKBOsOkyeiNUPobvZUrLBGceagg

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

Почему SUAVE нужен собственный блокчейн?

Почему мы не можем просто передавать и делиться настройками через сеть P2P? Потому что чистая сеть P2P не может предотвратить заполнение сети бесчисленными настройками (т.е. атаками DoS). Если это цепочка, атаки DoS можно предотвратить через комиссии за обработку.

Почему SUAVE не использует существующую цепочку? Потому что SUAVE нужна собственная функция (MEV) и собственные настройки цепочки, такие как время блока и размер блока. Если вы создадите его непосредственно на Ethereum, вы столкнетесь с такими проблемами, как слишком высокая стоимость, слишком долгое время блока и ограниченные функции.

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

Однако у SUAVE есть своя собственная цепочка, что также означает, что (1) Пользователю SUAVE может потребоваться перевести активы с других цепочек на цепочку SUAVE для использования SUAVE, и (2) SUAVE должен полагаться на Oracle, чтобы сообщать информацию с других цепочек. Это означает, что самому SUAVE требуется дополнительное доверие к Oracle. Если Oracle небезопасен, это повлияет на безопасность контракта на SUAVE.

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

Дизайн и модель безопасности самой цепи SUAVE все еще обсуждаются. Если SUAVE Chain является Rollup на Ethereum, то вы можете непосредственно использовать собственный механизм Rollup для передачи активов и чтения другой информации Rollup. Это будет лучше, чем полагаться на другие роллапы. Технология межцепочечных и оракульных сервисов приносят много безопасности.

Если валидатор цепи SUAVE можно объединить с Eigenlayer, то будет безопаснее и надежнее использовать валидатор Ethereum непосредственно в качестве валидатора цепи SUAVE, чем создавать набор валидаторов самим SUAVE. Но, конечно, у этих конструкций также есть соответствующие недостатки. Для более подробного обсуждения дизайна цепи SUAVE обратитесь к этой статье.

Обзор вызовов SUAVE

  • Время блока SUAVE Chain: Время блока SUAVE Chain должно быть достаточно коротким, чтобы Пользователь SUAVE мог заявить о своих предпочтениях для Исполнителя. Если время SUAVE Chain больше, чем цепочка, к которой она подключена (например, Solana или другой Rollup), Пользователь SUAVE может не успеть сообщить Исполнителю SUAVE о том, что он хочет, чтобы транзакция была включена в следующий блок определенной цепочки. Произведен блок.
  • Риск оракула: Оракул отвечает за предоставление информации о других цепях и также может быть ответственен за передачу активов пользователей SUAVE на цепочку SUAVE, поэтому важность оракула нельзя недооценивать.
  • Опыт использования кросс-цепочки: Пользователь SUAVE должен перевести активы на цепочку SUAVE, что также является недостатком в опыте использования.
  • Экономическая модель: Нужно ли SUAVE выпускать собственные активы, как стимулировать валидатора SUAVE, как предотвратить влияние экономического стимулирования SUAVE на экономическую безопасность других цепей и т. д.
  • Технология конфиденциальности: В краткосрочной перспективе SUAVE должен будет полагаться на доверенное аппаратное обеспечение, такое как SGX, для обеспечения функций конфиденциальности транзакций, но в долгосрочной перспективе ему придется перейти к более децентрализованному и безопасному подходу для снижения рисков.
  • Подходящий язык предпочтений: подходит ли EVM как средство выражения и выполнения предпочтений?

Резюме и основные моменты

  • Появление SUAVE направлено на (1) устранение риска централизации, вызванного различием в преимуществах Строителей, которое может возникнуть из-за Cross Domain MEV, и (2) открытие двери для сотрудничества между Поисками/Строителями через внедрение программной конфиденциальности, сокращение риска централизации, который может возникнуть из-за Private Order Flow.
  • Полностью приватные транзакции усложняют работу искателей, поскольку они не могут эффективно обратно запускать пользовательские транзакции, что приводит к снижению эффективности on-chain. Однако пользователи не обязаны выбирать между «конфиденциальностью» и «эффективностью». Вместо этого они могут использовать программируемую конфиденциальность, чтобы выбирать, какую часть информации раскрывать, что облегчит работу искателей и улучшит эффективность on-chain и вознаграждения за обратный запуск.
  • С SUAVE пользователи могут указать свои предпочтения и различные условия для своих намерений/транзакций, в то время как все остальное обрабатывается профессиональными исполнителями для достижения условий и получения обещанных вознаграждений от пользователей SUAVE по достижении.
  • SUAVE будет иметь собственную цепочку, потому что чистый P2P не может предотвратить атаки DoS, и SUAVE будет иметь собственные уникальные особенности и настройки для цепочки (MEV), поэтому существующие цепочки не могут быть непосредственно использованы. Эта цепочка будет основана на модификации EVM, добавляя необходимые функциональные возможности для MEV, называемой MEVM.
  • Кроссчейн MEV — это очень сложная операция, поскольку она требует обеспечения атомарного включения и гарантии «успешного выполнения» транзакций. Пользователи SUAVE могут указать состояния, требующие, чтобы транзакции были успешно выполнены, прежде чем вознаграждать Исполнителя, тем самым перекладывая риск на Исполнителя. Общий секвенсор может обеспечить атомарное включение, но не гарантирует, что транзакции будут выполнены «успешно».
  • SUAVE, будучи собственной цепочкой, также означает, что Пользователям SUAVE необходимо перевести активы на цепочку SUAVE, прежде чем они смогут использовать SUAVE. Более того, для проверки удовлетворения Предпочтений требуется безопасный Оракул, который будет передавать информацию с других цепочек на цепочку SUAVE.
  • SUAVE все еще сталкивается с многими техническими и дизайнерскими вызовами, такими как безопасный Оракул, безопасные техники конфиденциальности, язык предпочтений и экономические модели, среди прочего.

Отказ:

  1. Эта статья взята из [ imToken Labs]. Все авторские права принадлежат оригинальному автору [Nic]. Если есть возражения по поводу этого повторного издания, пожалуйста, свяжитесь с Gate Learnкоманда, и они оперативно решат эту проблему.
  2. Отказ от ответственности: Мнения и взгляды, высказанные в этой статье, являются исключительно мнением автора и не являются инвестиционным советом.
  3. Переводы статьи на другие языки выполняются командой Gate Learn. Если не указано иное, запрещается копирование, распространение или плагиатство переведенных статей.

MEV (7): Более справедливая экосистема MEV (Заключение)

Средний1/14/2024, 6:19:20 PM
Эта статья знакомит с амбициозным SUAVE — дизайном рынка MEV, обеспечивающим программную конфиденциальность, большую эффективность, справедливость и межцепочность.

Эта статья познакомит вас с функцией «Программируемая конфиденциальность», которая обеспечивает более продвинутые транзакции и кросс-чейн, более открытый и справедливый дизайн рынка MEV - SUAVE. Прежде чем перейти к основной теме объяснения SUAVE, пожалуйста, сначала поймите концепцию Намерения.

Намерение

Текущий опыт использования транзакций блокчейн

Возьмем транзакции Ethereum в качестве примера. Предположим, пользователь хочет обменять свои USDT на ETH. Он может перейти на веб-страницу Uniswap, чтобы проверить цену, и после установки допустимого ценового проскальзывания подписать и отправить транзакцию, а затем дождаться результата транзакции.

Его транзакция, вероятно, будет выглядеть примерно так: «Я подписываю и отправляю эту транзакцию со значением Nonce 23 и комиссией за газ 30 Гвей. Она выполнит контракт Uniswap для обмена моих 1000 USDT на 0,5 ETH с максимальным проскальзыванием 1%.

△ Нонс? Гвей? Источник изображения:https://www.reddit.com/r/MemeRestoration/comments/ejcvd3/confused_math_lady_4080x2663px

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

  • Первое - найти канал обмена. Предположим, она ищет в Google и находит страницу Uniswap (по крайней мере, там есть понятное меню цифровых активов и кнопка Swap), а затем ей нужно понять и установить проскальзывание (или использовать значение по умолчанию).
  • После нажатия кнопки Обмен, появляется экран подписи транзакции, который содержит Nonce и Gwei комиссии за обработку.
  • Наконец, она отправляет транзакцию, но, вероятно, ничего не происходит, и Алиса может только ждать в замешательстве и молиться, чтобы транзакция была успешно выполнена.

Каждый уровень - это вопрос, который начинающим пользователям на самом деле не нужно понимать, но им приходится делать выбор: Где осуществить погашение? Хотите установить slippage? Какой процент следует установить для slippage? Хотите отрегулировать газовый сбор (комиссию)? На какое количество Gwei его нужно отрегулировать? Почему транзакция не удалась? Почему транзакция застряла там настолько долго (может быть, проблема с Nonce или комиссией)? Что мне делать?

Опыт использования транзакций намерений

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

В намерении Алиса указала, что 1000 USDT должны быть обменяны на 0.5 ETH, но с учетом комиссии за обработку цена была скорректирована до 0.495 ETH, после чего заказ был подписан и отправлен. Транзакция Алисы будет выглядеть так: "Я подписываю и отправляю этот заказ. Я хочу обменять 1000 USDT на 0.495 ETH. Этот заказ действителен до тех пор, пока я не получу 0.495 ETH."

Это очень просто, верно? Это опыт использования лимитного ордера (Limit Order), а также общий опыт использования DEX Агрегаторов (таких как 1inch и Tokenlon).

△ Разница между Транзакцией (вверху) и Намерением (внизу). С Намерением пользователи должны только указать условия и не беспокоиться о том, как их достичь. Подпись:https://www.paradigm.xyz/2023/06/intents

Через Intent пользователям больше не нужно иметь дело и беспокоиться о различных утомительных и запутанных деталях между генерацией, подписанием и выполнением транзакций. Они даже не должны разбираться в проблеме и продолжать пытаться, когда транзакция не удается. Более того, у разных цепочек будут различные процессы и подводные камни транзакций!

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

Намерение значительно улучшит опыт блокчейн.

Совет по чтению 1: На самом деле уже существует много примеров использования Намерения, таких как подпись кошелька с мультиподписью, концепция Ключа Сеанса, предоставляющего третьей стороне конкретные права на выполнение и временные ограничения, или механизм пакетного соответствия транзакций, например CowSwap. Даже в мире Web2 есть следы Намерения, такие как поисковые системы (я ввожу то, что хочу запросить, и поисковая система находит для меня соответствующую информацию через различные каналы) или электронная коммерция онлайн-съемка (я ввожу то, что хочу купить) что-то, компания по электронной коммерции нашла это через различные каналы и доставила мне). Просто слово Намерение только недавно стало популярным в мире Web3.

Совет по чтению 2: На английском языке слово Imperative («императив») используется для описания опыта использования транзакции, которая заключается в выдаче полной команды для достижения цели; тогда как слово Declarative («утвердительное») используется для описания опыта использования намерения. Описательное, указывая, что оно используется путем указания условий выполнения и результатов выполнения.

Намерение в мире кросс-цепочек

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

Исключая кросс-цепочечные приложения через мультиподпись проектной стороны, это может обеспечить лучший пользовательский опыт (например, после того, как пользователь отправит транзакцию на исходной цепочке, мультиподпись проектной стороны автоматически отправит активы пользователю на целевой цепочке). Указанный адрес не требует от пользователя выполнения каких-либо операций на целевой цепочке). Другие более децентрализованные кросс-цепочечные приложения, такие как Nomad и Succinct, не обладают таким хорошим опытом. Пользователям может потребоваться отправлять транзакции на целевую цепочку для завершения операции.

Поэтому улучшение пользовательского опыта, которое может принести Intent, становится еще более важным и срочным в мире кросс-цепочек.

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

СУАВЭ

Полное название SUAVE - Single Unifying Auction for Value Expression, целью является стать унифицированным рынком MEV через несколько цепей. На этом рынке пользователи могут выражать условия закрытия и вознаграждения сделки эффективным способом. В то же время исполнители (Executors) будут конкурировать друг с другом и эффективно сотрудничать для выполнения запросов пользователей.

SUAVE может служить пулом транзакций для блокчейна, а также выступать в качестве роли Builder, ответственной за создание содержимого блоков этого блокчейна. Тем не менее, SUAVE не предназначен для замены существующего пула транзакций и функциональности Builder блокчейна, а скорее для беспрепятственного подключения к существующему блокчейну в режиме plug and play.

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

От Flashbot до MEV-Boost до SUAVE

От Flashbot до MEV-Boost, дух, которым они руководствуются, заключается в признании существования MEV и стремлении вывести скрытую экономическую деятельность на первый план. Они стремятся создать публичный рынок, в котором может участвовать любой, чтобы избежать ситуации, в которой некоторые лица молча контролируют и доминируют в этом огромном экономическом интересе, что постепенно приводит к концентрации ресурсов в их руках и в конечном итоге влияет на децентрализацию и безопасность всей сети блокчейн.

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

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

Еще одним явлением, которое повлияет на централизацию и безопасность, является Частный Порядок Потока: транзакции пользователей больше не попадают в общий пул транзакций, а напрямую поступают к Искателю или Строителю. Частный Порядок Потока может происходить от Искателя или Строителя, покупающих право на получение дохода от транзакций пользователей, или Строителя, предоставляющего привлекательные услуги, такие как (1) бесплатная отмена транзакций или ордеров на DEX, отправленных пользователями, или (2) предоставление Предварительного Подтверждения, до получения транзакции пользователь уверен, насколько быстро будет получена транзакция, чтобы пользователю не приходилось беспокоиться о том, будет ли транзакция получена и сколько времени займет ее получение.

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

Почему блоки от транзакций пользователей к Bundle, созданному Searcher, должны собираться через Private Order Flow? Это связано с тем, что содержимое транзакции и Bundle является публичным и незашифрованным. Если они увидены и получены другими, это может причинить вред пользователю или Searcher. Например, другие могут извлечь MEV из транзакции пользователя через атаку щипцами или разобрать Bundle, вырвав MEV. Поэтому пользователи и Searchers в настоящее время должны доверять Builder, поскольку им необходимо передавать оригинальное содержимое транзакции и Bundle Builder и доверять, что Builder не причинит вреда.

Появление SUAVE направлено на решение рисков централизации, вызванных международным MEV и частным потоком ордеров.

Во-первых, установив публичный рынок, который обслуживает MEV межцепочку, пользователи или искатели могут выразить свои доходные условия для транзакций или пакетов на этом рынке. Например, если у пользователя есть две транзакции, которые должны быть направлены соответственно на Ethereum и Arbitrum, и обе транзакции должны быть включены и выполнены до определенного времени, они могут указать эти условия на рынке. Исполнители на рынке (которые могут быть искателями или строителями) будут конкурировать, чтобы выполнить эти запросы и заработать награды. Но как пользователи или искатели могут доверять тому, что они бросают свои транзакции или пакеты на этот публичный рынок? Вот где вступает технология конфиденциальности. Зашифровав транзакции, пользователи или искатели больше не должны беспокоиться о потенциальном вреде, причиненном другими просмотром их транзакций. Только с конфиденциальностью транзакций возможен открытый поток заказов.

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

По сравнению с полностью зашифрованными транзакциями, транзакции, которые раскрывают конкретную информацию, могут быть включены в пакеты или блоки более эффективно и быстро, и даже получать откаты, как подробно описано в разделе четвертой статьи «MEV-Share». Раскрывая конкретную информацию, пользователи могут даже сотрудничать друг с другом. Поисковик Б может строиться на связке Поисковика А: связка Поисковика А следует за транзакцией пользователя для арбитража, а связка Искателя Б следует за связкой Искателя А для арбитража. Конфиденциальность имеет важное значение для потока открытых ордеров. Конфиденциальность позволяет пользователям иметь возможность сотрудничать друг с другом, принося пользу друг другу, а не конкурируя за возможности MEV.

Другие преимущества SUAVE

  • Через SUAVE кросс-цепочечные транзакции DEX могут получить лучшие цены, а кросс-цепочечные намерения могут быть выполнены более эффективно.
  • Если SUAVE рассматривать как огромного, но децентрализованного строителя, у него будет больше преимуществ, чем у централизованного строителя, потому что он собирает больше потоков заказов, что также может привлечь больше строителей, чтобы присоединиться к SUAVE, и далее снизить риски, вызванные централизацией строителей.
  • Через SUAVE каждая цепь не должна строить свой собственный частный пул транзакций и свой собственный рынок MEV цепи и может сосредоточить свои ресурсы и энергию на решении других проблем или предоставлении лучших услуг.

архитектура SUAVE

Доска объявлений для пользовательских предпочтений

SUAVE можно описать как «доску объявлений пользовательских предпочтений». Термин «Пользователь» здесь не обязательно относится к общим пользователям блокчейна, но Поисковики также могут быть Пользователями SUAVE. В дальнейшем термин «Пользователь» будет относиться к общим пользователям блокчейна, а «Пользователь SUAVE» будет относиться к пользователям SUAVE.

Предпочтение пользователей SUAVE похоже на специализированный интент, сосредоточенный на сортировке транзакций. Это не похоже на общие интенты, которые читатели могут видеть в других местах и которые могут указывать различные условия. Подобно тому, как пользователи указывают предпочтения и условия в интентах, в Предпочтении пользователи SUAVE указывают предпочтения или условия для «транзакций или дохода от пакетов, поступающих в блок», такие как:

  • «Я хочу, чтобы моя транзакция была отсортирована перед транзакцией 0xabcd и была включена до блока 110050». Фактически, это похоже на условия, указанные в Bundle of Searcher при использовании Flashbot.
  • “Я хочу, чтобы мой пакет был включен и принес мне 0.05 ETH дохода.”
  • "Я хочу, чтобы Намерение A и Намерение B были включены в блок 1001 цепочки X и блок 50900 цепочки Y соответственно." \

Совет по чтению: Пользователи также могут отправлять общие транзакции блокчейна (без указания каких-либо предпочтений) в SUAVE, то есть просто использовать SUAVE в качестве общего торгового пула или Flashbot, например, напрямую отправлять свои транзакции по переводу ETH или транзакции Uniswap в SUAVE.

Конечно, если вы просто укажете условия, нет необходимости разрабатывать новую архитектуру для этого, просто используйте оригинальный Flashbot. Так что на самом деле Предпочтения, указанные в SUAVE, должны соответствовать вознаграждениям, в противном случае никто не будет готов выполнить ваши Предпочтения безусловно. Конечно, предпосылкой для оплаты должно быть то, что Предпочтения были достигнуты.

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

  • «Я хочу, чтобы моя транзакция была отсортирована до транзакции 0xabcd и была включена до блока 110050. Если это будет достигнуто, я дам вам 3 ETH».
  • «Я хочу, чтобы мой пакет был включен и принес мне доход в размере 0,05 ETH. Если это будет достигнуто, я дам вам 0,02 ETH».
  • «Я хочу, чтобы Намерение A и Намерение B были включены в 1001-й блок цепи X и 50900-й блок цепи Y соответственно. Если это будет достигнуто, я дам вам 1.8 ETH».

Архитектура

SUAVE можно рассматривать как состоящий из трех компонентов: Среда Предпочтений, Рынок Исполнения и Децентрализованное Формирование Блоков.

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

△ ПЕ слева собирает намерения и арбитражные транзакции на различных цепях, а затем Исполнители посередине пытаются удовлетворить эти Предпочтения и упаковать их в Бандлы, передавая эти Бандлы роли справа, которая имеет право на производство блоков, чтобы собрать блоки. Источник изображения:https://writings.flashbots.net/the-future-of-mev-is-suave

SUAVE будет иметь свою собственную цепочку и пул транзакций. SUAVE называет цепочку Уровнем Расчетов и пул транзакций Уровнем Сообщений.

Смарт-контракты могут быть развернуты на цепочке для установления контрактов между Preference и rewards. Пул транзакций будет заполнен транзакциями, в которых пользователь SUAVE объявляет Preference, а Executor получает вознаграждение.

Жизненный цикл транзакции SUAVE

  1. Выражение предпочтения: Пользователь SUAVE указывает предпочтение и делает ставку на один или несколько своих намерений/транзакций.
  2. Оптимизация выполнения: исполнитель находит путь выполнения, который удовлетворяет пользовательские предпочтения, и даже может найти оптимальный путь для этого.
  3. Расчет предпочтений: Пакет(ы) исполнителя успешно включены в блок целевой цепи и соответствуют предпочтениям, указанным пользователем SUAVE.
  4. Расчет платежей: Оракул возвращает статус целевой цепи на цепь SUAVE, и Исполнитель выполняет смарт-контракт. После того как контракт подтверждает, что Предпочтение было удовлетворено, Награда SUAVE User передается Исполнителю.

△ Предпочтение четыре шага от создания до исполнения до урегулирования. Источник изображения:https://dba.mirror.xyz/NTg5FSq1o_YiL_KJrKBOsOkyeiNUPobvZUrLBGceagg

MEVM

SUAVE должен иметь возможность писать Предпочтение на языке программирования и преобразовывать его в смарт-контракт, чтобы выполнить контракт между Пользователем SUAVE и Исполнителем. Ожидается, что SUAVE разработает специфический для MEV EVM на основе EVM - MEVM.

MEVM добавит новый контракт предварительной компиляции и тип транзакции специально для MEV. Предпочтения пользователя, Упаковка пакета и Функции построения блока могут быть легко выполнены в MEVM.

Приведенный ниже образец программного кода записывает алгоритм построения блока с использованием эффективной цены газа (EGP) с использованием языка Solidity и контрактов MEVM Precompile.

EGP Block Building сортирует пакеты в соответствии с ценой газа, указанной для каждого пакета. Пакеты с более высокой ценой газа будут расположены в начале блока:

△ Розовая функция на картинке - это предварительная функция MEVM, специально разработанная для использования MEV. Источник изображения:https://writings.flashbots.net/mevm-suave-centauri-and-beyond

Совет по чтению: Выполнение алгоритма построения блока на самом деле не происходит на цепи SUAVE Chain, но Block Builder имитирует выполнение вне цепи (как узел будет имитировать выполнение транзакции локально), поэтому этот процесс выполнения на самом деле не станет транзакцией, занимающей блочное пространство и вычислительные ресурсы SUAVE Chain, и не будет ограничен производительностью цепи SUAVE.

Через композицию контракта EVM Searcher и Searcher или Searcher и Builder смогут сотрудничать через контракты, заменяя исходное одностороннее доверие. Сотрудничество также дополнительно улучшит эффективность Bundle и извлечет больше MEV, что может принести пользу каждому участнику цепочки поставок MEV. Кроме того, участники могут напрямую использовать инструменты разработки на основе EVM и инфраструктуру, такие как RPC Provider, тестовые инструменты, такие как Foundry и т.д., а опыт разработки будет очень хорошим.

Более того, MEVM предоставит функцию конфиденциальности транзакций, потому что без конфиденциальности нет возможности сотрудничества. Без конфиденциальности поисковики должны беспокоиться о том, что их MEV могут быть украдены. На раннем этапе эта конфиденциальность будет достигнута благодаря доверенному аппаратному обеспечению SGX. Транзакции будут зашифрованы, а затем отправлены в SGX для выполнения. Предполагается, что SGX будет выполнять свои назначенные программные коды, не воруя MEV по своему усмотрению. В будущем, когда другие передовые криптографические технологии постепенно станут зрелыми, криптография сможет заменить доверенное аппаратное обеспечение. Для получения дополнительной информации обратитесь к предыдущей статье наЗашифрованные Mempools.

Совет по чтению: Однако есть и недостатки, основанные на EVM, такие как EVM слишком выразителен: на самом деле для написания функций, необходимых для MEV, в EVM не требуется много операций. Разрешение использовать эти операции может позволить людям, готовым писать очень сложные исполнения, а затем позволить транзакции завершиться неудачно в конце исполнения, вызвав потерю узлом множества вычислительных ресурсов, что является атакой DoS. Проект Anoma перерабатывает язык программирования и среду выполнения специально для выражения и выполнения намерений. В будущем SUAVE также может использовать архитектуру Anoma для замены MEVM.

Подключение и использование SUAVE

Если разработчик блока или валидатор цепи знает о существовании SUAVE и намерен использовать SUAVE, то он будет рассматривать SUAVE как строителя блоков. Если SUAVE предоставляет более высокую цену на торги за построенные им блоки, то майнеры или валидаторы будут использовать блоки SUAVE. Возьмем текущий MEV-Boost на Ethereum в качестве примера: блоки, составленные SUAVE, будут преобразованы в формат, соответствующий механизму торгов MEV-Boost через плагин, предоставленный SUAVE. Предлагающему не нужно вносить изменения, чтобы использовать блоки SUAVE.

Если разработчик блока или проверяющий цепи не знает о существовании SUAVE, тогда Исполнитель SUAVE сделает ставку, чтобы получить свой Bundle в соответствии с правилами комиссии цепи.

Проблемы кроссчейн MEV

У каждой цепи свой блок разработчик и валидатор. Прием блока B1 SUAVE цепью X не означает, что блок B2 будет успешно получен валидатором цепи Y. Механизмы производства блоков и рынки цепи X и цепи Y независимы. Если только цепи X и Y используют Общий Последователь, и тот же Последователь производит блоки для обеих цепей одновременно, то только объединяя SUAVE мы можем обеспечить Атомарное Включение: две цепи не должны «собирать определенные транзакции (или блоки) вместе». Юань)», или «вообще нет дохода».

Даже если Shared Sequencer может гарантировать Атомное Включение, это не означает, что транзакция будет "успешно" выполнена после включения. Если обе транзакции не были выполнены "успешно", это означает, что межцепочная MEV не удалась. Предположим, что пользователь SUAVE хочет завершить межцепочную арбитражную сделку, транзакции на обеих цепях должны быть сгенерированы в реальном времени и успешно выполнены, прежде чем он сможет получить выгоду:

  • Если Пользователь SUAVE не готов нести риск неудачного выполнения транзакции, то его Предпочтение потребует, чтобы обе транзакции были успешно выполнены, прежде чем они будут завершены, и затем Исполнитель будет оплачен, а Риск будет нести Исполнитель. Он может ограничить «результат успешного выполнения», указав статус на цепи, например, указав, что контракт должен излучать определенное Событие, или указав, насколько баланс токенов определенного адреса должен быть больше. Затем Исполнитель, готовый рисковать, попытается сделать обе транзакции реальными и успешно выполненными в реальном времени. Если только одна из них окажется полученной или выполнение одной из транзакций «неудачно», Исполнитель не получит вознаграждение.
  • Если пользователь SUAVE готов к риску, то его Предпочтение может требовать только получение обеих транзакций, и также допускается неудачное выполнение транзакции (т. е. откат транзакции). Исполнитель все равно будет стараться выполнить обе транзакции успешно (успешное выполнение может привести к большему вознаграждению), но пока есть доход, вы можете получить вознаграждение.

Взяв нижеприведенное изображение в качестве примера, пользователь SUAVE хочет выполнить арбитраж транзакций между цепями Rollup 1 и Rollup 2: купить один ETH по более низкой цене на Rollup 1 и продать один ETH по более высокой цене на Rollup 2.

Если обе сделки оплачиваются в реальном времени и успешно исполняются, Пользователь SUAVE может заработать разницу в цене. Сценарии 1 и 2 в таблице на изображении соответствуют «Пользователь SUAVE готов самостоятельно нести риск» и «Исполнитель готов нести риск» соответственно.

Нижние три столбца таблицы - «награды за оба успешных», «награды за только один успех» и «окончательный результат за только один успех»:

  • Вознаграждения за обе успешные транзакции (Пользователь SUAVE зарабатывает разницу в цене):
    • Сценарий 1: Пользователь SUAVE платит исполнителю $50 комиссию за обработку.
    • Сценарий 2: Пользователь SUAVE платит Исполнителю комиссию за обработку в размере 70 долларов США (дороже, потому что Исполнитель несет риск).
  • Есть только одно вознаграждение за успех (пользователь SUAVE не заработал спред):
    • Сценарий 1: Пользователь SUAVE выплачивает исполнителю плату в размере 25 долларов. Пользователи SUAVE несут риски сами.
    • Сценарий 2: Пользователь SUAVE не должен платить комиссии или рисковать.
  • Есть только один успешный результат (SUAVE User не заработал спред):
    • Сценарий 1: Пользователь SUAVE платит исполнителю комиссию в размере $25 и имеет дополнительные ETH в наличии.
    • Сценарий 2: Пользователю SUAVE не нужно платить комиссию за обработку Исполнителю и не будет иметь на руках лишнего ETH. А у Executor в руке еще один ETH.

△ Разные результаты выполнения в различных ситуациях. Источник изображения:https://dba.mirror.xyz/NTg5FSq1o_YiL_KJrKBOsOkyeiNUPobvZUrLBGceagg

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

Почему SUAVE нужен собственный блокчейн?

Почему мы не можем просто передавать и делиться настройками через сеть P2P? Потому что чистая сеть P2P не может предотвратить заполнение сети бесчисленными настройками (т.е. атаками DoS). Если это цепочка, атаки DoS можно предотвратить через комиссии за обработку.

Почему SUAVE не использует существующую цепочку? Потому что SUAVE нужна собственная функция (MEV) и собственные настройки цепочки, такие как время блока и размер блока. Если вы создадите его непосредственно на Ethereum, вы столкнетесь с такими проблемами, как слишком высокая стоимость, слишком долгое время блока и ограниченные функции.

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

Однако у SUAVE есть своя собственная цепочка, что также означает, что (1) Пользователю SUAVE может потребоваться перевести активы с других цепочек на цепочку SUAVE для использования SUAVE, и (2) SUAVE должен полагаться на Oracle, чтобы сообщать информацию с других цепочек. Это означает, что самому SUAVE требуется дополнительное доверие к Oracle. Если Oracle небезопасен, это повлияет на безопасность контракта на SUAVE.

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

Дизайн и модель безопасности самой цепи SUAVE все еще обсуждаются. Если SUAVE Chain является Rollup на Ethereum, то вы можете непосредственно использовать собственный механизм Rollup для передачи активов и чтения другой информации Rollup. Это будет лучше, чем полагаться на другие роллапы. Технология межцепочечных и оракульных сервисов приносят много безопасности.

Если валидатор цепи SUAVE можно объединить с Eigenlayer, то будет безопаснее и надежнее использовать валидатор Ethereum непосредственно в качестве валидатора цепи SUAVE, чем создавать набор валидаторов самим SUAVE. Но, конечно, у этих конструкций также есть соответствующие недостатки. Для более подробного обсуждения дизайна цепи SUAVE обратитесь к этой статье.

Обзор вызовов SUAVE

  • Время блока SUAVE Chain: Время блока SUAVE Chain должно быть достаточно коротким, чтобы Пользователь SUAVE мог заявить о своих предпочтениях для Исполнителя. Если время SUAVE Chain больше, чем цепочка, к которой она подключена (например, Solana или другой Rollup), Пользователь SUAVE может не успеть сообщить Исполнителю SUAVE о том, что он хочет, чтобы транзакция была включена в следующий блок определенной цепочки. Произведен блок.
  • Риск оракула: Оракул отвечает за предоставление информации о других цепях и также может быть ответственен за передачу активов пользователей SUAVE на цепочку SUAVE, поэтому важность оракула нельзя недооценивать.
  • Опыт использования кросс-цепочки: Пользователь SUAVE должен перевести активы на цепочку SUAVE, что также является недостатком в опыте использования.
  • Экономическая модель: Нужно ли SUAVE выпускать собственные активы, как стимулировать валидатора SUAVE, как предотвратить влияние экономического стимулирования SUAVE на экономическую безопасность других цепей и т. д.
  • Технология конфиденциальности: В краткосрочной перспективе SUAVE должен будет полагаться на доверенное аппаратное обеспечение, такое как SGX, для обеспечения функций конфиденциальности транзакций, но в долгосрочной перспективе ему придется перейти к более децентрализованному и безопасному подходу для снижения рисков.
  • Подходящий язык предпочтений: подходит ли EVM как средство выражения и выполнения предпочтений?

Резюме и основные моменты

  • Появление SUAVE направлено на (1) устранение риска централизации, вызванного различием в преимуществах Строителей, которое может возникнуть из-за Cross Domain MEV, и (2) открытие двери для сотрудничества между Поисками/Строителями через внедрение программной конфиденциальности, сокращение риска централизации, который может возникнуть из-за Private Order Flow.
  • Полностью приватные транзакции усложняют работу искателей, поскольку они не могут эффективно обратно запускать пользовательские транзакции, что приводит к снижению эффективности on-chain. Однако пользователи не обязаны выбирать между «конфиденциальностью» и «эффективностью». Вместо этого они могут использовать программируемую конфиденциальность, чтобы выбирать, какую часть информации раскрывать, что облегчит работу искателей и улучшит эффективность on-chain и вознаграждения за обратный запуск.
  • С SUAVE пользователи могут указать свои предпочтения и различные условия для своих намерений/транзакций, в то время как все остальное обрабатывается профессиональными исполнителями для достижения условий и получения обещанных вознаграждений от пользователей SUAVE по достижении.
  • SUAVE будет иметь собственную цепочку, потому что чистый P2P не может предотвратить атаки DoS, и SUAVE будет иметь собственные уникальные особенности и настройки для цепочки (MEV), поэтому существующие цепочки не могут быть непосредственно использованы. Эта цепочка будет основана на модификации EVM, добавляя необходимые функциональные возможности для MEV, называемой MEVM.
  • Кроссчейн MEV — это очень сложная операция, поскольку она требует обеспечения атомарного включения и гарантии «успешного выполнения» транзакций. Пользователи SUAVE могут указать состояния, требующие, чтобы транзакции были успешно выполнены, прежде чем вознаграждать Исполнителя, тем самым перекладывая риск на Исполнителя. Общий секвенсор может обеспечить атомарное включение, но не гарантирует, что транзакции будут выполнены «успешно».
  • SUAVE, будучи собственной цепочкой, также означает, что Пользователям SUAVE необходимо перевести активы на цепочку SUAVE, прежде чем они смогут использовать SUAVE. Более того, для проверки удовлетворения Предпочтений требуется безопасный Оракул, который будет передавать информацию с других цепочек на цепочку SUAVE.
  • SUAVE все еще сталкивается с многими техническими и дизайнерскими вызовами, такими как безопасный Оракул, безопасные техники конфиденциальности, язык предпочтений и экономические модели, среди прочего.

Отказ:

  1. Эта статья взята из [ imToken Labs]. Все авторские права принадлежат оригинальному автору [Nic]. Если есть возражения по поводу этого повторного издания, пожалуйста, свяжитесь с Gate Learnкоманда, и они оперативно решат эту проблему.
  2. Отказ от ответственности: Мнения и взгляды, высказанные в этой статье, являются исключительно мнением автора и не являются инвестиционным советом.
  3. Переводы статьи на другие языки выполняются командой Gate Learn. Если не указано иное, запрещается копирование, распространение или плагиатство переведенных статей.
Розпочати зараз
Зареєструйтеся та отримайте ваучер на
$100
!