Эта статья познакомит вас с функцией «Программируемая конфиденциальность», которая обеспечивает более продвинутые транзакции и кросс-чейн, более открытый и справедливый дизайн рынка 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, но ей придется пройти через множество порогов, чтобы осуществить этот маленький желание:
Каждый уровень - это вопрос, который начинающим пользователям на самом деле не нужно понимать, но им приходится делать выбор: Где осуществить погашение? Хотите установить 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, дух, которым они руководствуются, заключается в признании существования 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. В дальнейшем термин «Пользователь» будет относиться к общим пользователям блокчейна, а «Пользователь SUAVE» будет относиться к пользователям SUAVE.
Предпочтение пользователей SUAVE похоже на специализированный интент, сосредоточенный на сортировке транзакций. Это не похоже на общие интенты, которые читатели могут видеть в других местах и которые могут указывать различные условия. Подобно тому, как пользователи указывают предпочтения и условия в интентах, в Предпочтении пользователи SUAVE указывают предпочтения или условия для «транзакций или дохода от пакетов, поступающих в блок», такие как:
Совет по чтению: Пользователи также могут отправлять общие транзакции блокчейна (без указания каких-либо предпочтений) в SUAVE, то есть просто использовать SUAVE в качестве общего торгового пула или Flashbot, например, напрямую отправлять свои транзакции по переводу ETH или транзакции Uniswap в SUAVE.
Конечно, если вы просто укажете условия, нет необходимости разрабатывать новую архитектуру для этого, просто используйте оригинальный Flashbot. Так что на самом деле Предпочтения, указанные в SUAVE, должны соответствовать вознаграждениям, в противном случае никто не будет готов выполнить ваши Предпочтения безусловно. Конечно, предпосылкой для оплаты должно быть то, что Предпочтения были достигнуты.
Преобразуя назначение предпочтений и вознаграждения в смарт-контракты для выполнения, стороны, нуждающиеся в услугах (такие как пользователи или Поисковики), смогут выдвигать более детальные и разнообразные требования к Предпочтениям, и эти требования будут удовлетворяться экономическими стимулами, а не полагаться на доброту Строителя.
SUAVE можно рассматривать как состоящий из трех компонентов: Среда Предпочтений, Рынок Исполнения и Децентрализованное Формирование Блоков.
△ ПЕ слева собирает намерения и арбитражные транзакции на различных цепях, а затем Исполнители посередине пытаются удовлетворить эти Предпочтения и упаковать их в Бандлы, передавая эти Бандлы роли справа, которая имеет право на производство блоков, чтобы собрать блоки. Источник изображения:https://writings.flashbots.net/the-future-of-mev-is-suave
SUAVE будет иметь свою собственную цепочку и пул транзакций. SUAVE называет цепочку Уровнем Расчетов и пул транзакций Уровнем Сообщений.
Смарт-контракты могут быть развернуты на цепочке для установления контрактов между Preference и rewards. Пул транзакций будет заполнен транзакциями, в которых пользователь SUAVE объявляет Preference, а Executor получает вознаграждение.
△ Предпочтение четыре шага от создания до исполнения до урегулирования. Источник изображения:https://dba.mirror.xyz/NTg5FSq1o_YiL_KJrKBOsOkyeiNUPobvZUrLBGceagg
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. Возьмем текущий MEV-Boost на Ethereum в качестве примера: блоки, составленные SUAVE, будут преобразованы в формат, соответствующий механизму торгов MEV-Boost через плагин, предоставленный SUAVE. Предлагающему не нужно вносить изменения, чтобы использовать блоки SUAVE.
Если разработчик блока или проверяющий цепи не знает о существовании SUAVE, тогда Исполнитель SUAVE сделает ставку, чтобы получить свой Bundle в соответствии с правилами комиссии цепи.
У каждой цепи свой блок разработчик и валидатор. Прием блока B1 SUAVE цепью X не означает, что блок B2 будет успешно получен валидатором цепи Y. Механизмы производства блоков и рынки цепи X и цепи Y независимы. Если только цепи X и Y используют Общий Последователь, и тот же Последователь производит блоки для обеих цепей одновременно, то только объединяя SUAVE мы можем обеспечить Атомарное Включение: две цепи не должны «собирать определенные транзакции (или блоки) вместе». Юань)», или «вообще нет дохода».
Даже если Shared Sequencer может гарантировать Атомное Включение, это не означает, что транзакция будет "успешно" выполнена после включения. Если обе транзакции не были выполнены "успешно", это означает, что межцепочная MEV не удалась. Предположим, что пользователь SUAVE хочет завершить межцепочную арбитражную сделку, транзакции на обеих цепях должны быть сгенерированы в реальном времени и успешно выполнены, прежде чем он сможет получить выгоду:
Взяв нижеприведенное изображение в качестве примера, пользователь SUAVE хочет выполнить арбитраж транзакций между цепями Rollup 1 и Rollup 2: купить один ETH по более низкой цене на Rollup 1 и продать один ETH по более высокой цене на Rollup 2.
Если обе сделки оплачиваются в реальном времени и успешно исполняются, Пользователь SUAVE может заработать разницу в цене. Сценарии 1 и 2 в таблице на изображении соответствуют «Пользователь SUAVE готов самостоятельно нести риск» и «Исполнитель готов нести риск» соответственно.
Нижние три столбца таблицы - «награды за оба успешных», «награды за только один успех» и «окончательный результат за только один успех»:
△ Разные результаты выполнения в различных ситуациях. Источник изображения:https://dba.mirror.xyz/NTg5FSq1o_YiL_KJrKBOsOkyeiNUPobvZUrLBGceagg
Перекрестный MEV требует, чтобы Исполнители имели капитал, были готовы к риску и имели достаточную технологию для обеспечения мгновенного, атомарного дохода и успешного выполнения. Это может быть прибыльной, но относительно высокозатратной работой.
Почему мы не можем просто передавать и делиться настройками через сеть 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 обратитесь к этой статье.
Partilhar
Эта статья познакомит вас с функцией «Программируемая конфиденциальность», которая обеспечивает более продвинутые транзакции и кросс-чейн, более открытый и справедливый дизайн рынка 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, но ей придется пройти через множество порогов, чтобы осуществить этот маленький желание:
Каждый уровень - это вопрос, который начинающим пользователям на самом деле не нужно понимать, но им приходится делать выбор: Где осуществить погашение? Хотите установить 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, дух, которым они руководствуются, заключается в признании существования 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. В дальнейшем термин «Пользователь» будет относиться к общим пользователям блокчейна, а «Пользователь SUAVE» будет относиться к пользователям SUAVE.
Предпочтение пользователей SUAVE похоже на специализированный интент, сосредоточенный на сортировке транзакций. Это не похоже на общие интенты, которые читатели могут видеть в других местах и которые могут указывать различные условия. Подобно тому, как пользователи указывают предпочтения и условия в интентах, в Предпочтении пользователи SUAVE указывают предпочтения или условия для «транзакций или дохода от пакетов, поступающих в блок», такие как:
Совет по чтению: Пользователи также могут отправлять общие транзакции блокчейна (без указания каких-либо предпочтений) в SUAVE, то есть просто использовать SUAVE в качестве общего торгового пула или Flashbot, например, напрямую отправлять свои транзакции по переводу ETH или транзакции Uniswap в SUAVE.
Конечно, если вы просто укажете условия, нет необходимости разрабатывать новую архитектуру для этого, просто используйте оригинальный Flashbot. Так что на самом деле Предпочтения, указанные в SUAVE, должны соответствовать вознаграждениям, в противном случае никто не будет готов выполнить ваши Предпочтения безусловно. Конечно, предпосылкой для оплаты должно быть то, что Предпочтения были достигнуты.
Преобразуя назначение предпочтений и вознаграждения в смарт-контракты для выполнения, стороны, нуждающиеся в услугах (такие как пользователи или Поисковики), смогут выдвигать более детальные и разнообразные требования к Предпочтениям, и эти требования будут удовлетворяться экономическими стимулами, а не полагаться на доброту Строителя.
SUAVE можно рассматривать как состоящий из трех компонентов: Среда Предпочтений, Рынок Исполнения и Децентрализованное Формирование Блоков.
△ ПЕ слева собирает намерения и арбитражные транзакции на различных цепях, а затем Исполнители посередине пытаются удовлетворить эти Предпочтения и упаковать их в Бандлы, передавая эти Бандлы роли справа, которая имеет право на производство блоков, чтобы собрать блоки. Источник изображения:https://writings.flashbots.net/the-future-of-mev-is-suave
SUAVE будет иметь свою собственную цепочку и пул транзакций. SUAVE называет цепочку Уровнем Расчетов и пул транзакций Уровнем Сообщений.
Смарт-контракты могут быть развернуты на цепочке для установления контрактов между Preference и rewards. Пул транзакций будет заполнен транзакциями, в которых пользователь SUAVE объявляет Preference, а Executor получает вознаграждение.
△ Предпочтение четыре шага от создания до исполнения до урегулирования. Источник изображения:https://dba.mirror.xyz/NTg5FSq1o_YiL_KJrKBOsOkyeiNUPobvZUrLBGceagg
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. Возьмем текущий MEV-Boost на Ethereum в качестве примера: блоки, составленные SUAVE, будут преобразованы в формат, соответствующий механизму торгов MEV-Boost через плагин, предоставленный SUAVE. Предлагающему не нужно вносить изменения, чтобы использовать блоки SUAVE.
Если разработчик блока или проверяющий цепи не знает о существовании SUAVE, тогда Исполнитель SUAVE сделает ставку, чтобы получить свой Bundle в соответствии с правилами комиссии цепи.
У каждой цепи свой блок разработчик и валидатор. Прием блока B1 SUAVE цепью X не означает, что блок B2 будет успешно получен валидатором цепи Y. Механизмы производства блоков и рынки цепи X и цепи Y независимы. Если только цепи X и Y используют Общий Последователь, и тот же Последователь производит блоки для обеих цепей одновременно, то только объединяя SUAVE мы можем обеспечить Атомарное Включение: две цепи не должны «собирать определенные транзакции (или блоки) вместе». Юань)», или «вообще нет дохода».
Даже если Shared Sequencer может гарантировать Атомное Включение, это не означает, что транзакция будет "успешно" выполнена после включения. Если обе транзакции не были выполнены "успешно", это означает, что межцепочная MEV не удалась. Предположим, что пользователь SUAVE хочет завершить межцепочную арбитражную сделку, транзакции на обеих цепях должны быть сгенерированы в реальном времени и успешно выполнены, прежде чем он сможет получить выгоду:
Взяв нижеприведенное изображение в качестве примера, пользователь SUAVE хочет выполнить арбитраж транзакций между цепями Rollup 1 и Rollup 2: купить один ETH по более низкой цене на Rollup 1 и продать один ETH по более высокой цене на Rollup 2.
Если обе сделки оплачиваются в реальном времени и успешно исполняются, Пользователь SUAVE может заработать разницу в цене. Сценарии 1 и 2 в таблице на изображении соответствуют «Пользователь SUAVE готов самостоятельно нести риск» и «Исполнитель готов нести риск» соответственно.
Нижние три столбца таблицы - «награды за оба успешных», «награды за только один успех» и «окончательный результат за только один успех»:
△ Разные результаты выполнения в различных ситуациях. Источник изображения:https://dba.mirror.xyz/NTg5FSq1o_YiL_KJrKBOsOkyeiNUPobvZUrLBGceagg
Перекрестный MEV требует, чтобы Исполнители имели капитал, были готовы к риску и имели достаточную технологию для обеспечения мгновенного, атомарного дохода и успешного выполнения. Это может быть прибыльной, но относительно высокозатратной работой.
Почему мы не можем просто передавать и делиться настройками через сеть 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 обратитесь к этой статье.