Введение

Адресация MEV (Maximal Extractable Value) является постоянной проблемой для Ethereum; цепь поставки ценности стимулирует постоянную активность арбитражистов с различными стратегиями различного уровня сложности, часто за счет розничных пользователей. Многие исследователи пытались решить MEV через изменения на уровне протокола, но эти усилия пока не привели к удовлетворительному решению. Каноническая инфраструктура и механизмы аукциона, используемые в настоящее время, способны конкурентно захватывать суммарный MEV в блоке, но захват без справедливого распределения является недостаточным: почему стоит накапливаться MEV стоимости у сетевых валидаторов, когда его можно более эффективно захватить и внутренне реализовать на приложениях по отдельности?

Введите Application-Specific Sequencing (ASS). Вместо того, чтобы пытаться переписать правила на уровне протокола, ASS дает отдельным приложениям возможность контролировать последовательность своих транзакций. Таким образом, ASS позволяет ончейн-приложениям защищать своих пользователей и ликвидность от вредного воздействия MEV, а также дает им возможность получить ценность, которая в противном случае была бы потеряна для валидаторов Ethereum.

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

Фон

Концепция за Application-Specific Sequencing (ASS) происходит от работы Матеуса над Правило верифицируемой последовательности (VSR) для децентрализованных бирж (DEXes). Матеус продемонстрировал, что VSR может улучшить исполнение сделок и смягчить MEV, снижая влияние майнеров на порядок транзакций. Тарун позже развил эту идеюпоказывая, как правила последовательности, специфичные для приложения, могут значительно влиять на функции вознаграждения для участников протокола, таких как пользователи, валидаторы и последователи.

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

1. Негладкие выплаты: Небольшие изменения в порядке могут привести к большим изменениям в MEV.
2. Не монотонные выплаты: Небольшие изменения в порядке могут как увеличить, так и уменьшить MEV, но не последовательно в одном направлении.

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

Как работает АСС?

Для понимания ASS давайте сначала рассмотрим существующую цепочку поставки транзакций.

В текущей системе:

1. Транзакции отправляются в общедоступные или частные мемпулы.
2. Строители собирают эти транзакции и упаковывают их в блоки.
3. Затем строители конкурируют в блочном аукционе.
4. Выигравший строительный блок включается в блокчейн, и выбранный заявитель для данного блока получает выплату за предложенную им стоимость.

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

Диаграмма текущей цепочки поставок транзакций

Приложения, активируемые с помощью ASS, с другой стороны, обладают следующими свойствами:

1. Ограниченные права последовательности: Это ограничение гарантирует, что только назначенный последователь или ставшие в залог валидаторы могут взаимодействовать с контрактом приложения на цепочке, к которой оно урегулировано, предотвращая коварное обходное движение логики приложения для внутреннего перераспределения ценности.
2. App-Specific Mempools: Вместо отправки транзакций в общедоступную пул транзакций пользователи отправляют подписанные сообщения, выражающие их намерения, в специальный пул транзакций для приложений. Эти намерения затем собираются и обрабатываются специальным последователем для приложений.
3. Результаты, не зависящие от порядка: для обеспечения соблюдения правила последовательности и доставки оптимальных экономических выплат целевым пользователям транзакции ASS должны быть нечувствительны к порядку транзакций строителей для остальной части блока. Это достигается путем обеспечения того, чтобы состояние приложения было ограничено его механизмом консенсуса. Затем заказы ASS объединяются в один пакет, который отправляется строителям для включения. Учитывая, что этот пакет не является конфликтным со состоянием, к которому обращаются другие приложения, он нечувствителен к своему положению в блоке.

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

Исходя из этих основных принципов, давайте рассмотрим Angstrom как практический пример суверенного приложения. Angstrom - это крючок UniswapV4, который защищает своих поставщиков ликвидности от неблагоприятного подбора арбитражников CEX-DEX, а также защищает меняющихся от атаки бутерброда. Сеть узлов Angstrom достигает консенсуса, параллельно с Ethereum, относительно набора транзакций, которые будут выполнены в следующем блоке. Общий поток следующий:

1. Арбитражеры CEX-DEX претендуют на право быть первой сделкой свопа через AMM (без комиссии). Между тем, пользователи отправляют свои предполагаемые свопы в виде подписанных лимитных ордеров в мемпул Angstrom.
2. Сеть Angstrom запускает свой протокол консенсуса и формирует пакет, в котором первая замена - это транзакция арбитражера с наивысшей ставкой. Сумма ставки последовательно распределяется пропорционально обеспечению ликвидности AMM в диапазоне замены. Все остальные действительные лимитные ордера, вместе с базовой ликвидностью AMM, выполняются по одной и той же равномерной цене.
3. Затем этот пакет отправляется на Ethereum-строителей и общедоступный mempool предлагающим узлом Angstrom для слота.
4. Строители могут включить пакет Ангстрема в любую позицию в блоке. Пакету просто нужно оплатить базовую плату за включение из-за его порядково-агностической конструкции.

Следующая диаграмма иллюстрирует действие суверенного приложения.

Цепочка поставок транзакций в Ангстреме

Предположение о живучести и доверии

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

Предположение о живучести

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

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

Доверие Предположение

Для обеспечения соблюдения последовательности предписанных правил суверенные приложения могут использовать криптоэкономические решения (например, PoS) или криптографические методы (например, TEE или MPC). Конкретный подход может значительно различаться в зависимости от потребностей приложения; некоторые могут требовать согласования оптимальности выполнения, в то время как другие могут сосредоточиться на обеспечении конфиденциальности предварительного выполнения с помощью криптографических механизмов. Существует множество инструментов, доступных для снижения доверительных накладных расходов последователей и достижения уникальных целей каждого суверенного приложения.

Сопротивление цензуре

Существуют различные виды цензуры, от которых страдает экосистема Ethereum:

1. Регулятивная цензура: Строители и ретрансляторы цензурируют транзакции на основе списка санкций OFAC. Это одна из самых ярких форм цензуры, присутствующих на Ethereum сегодня.преимущественно осуществляется ретрансляторами.
2. Экономическая цензура: Мотивированный атакующий можетПодкуп инициатора блока, чтобы подвергнуть цензуре транзакции жертвы.
3. Цензура на уровне узла: Узлы в сети P2P могут отказываться распространять входящие транзакции. Это может быть серьезной проблемой, если протокол работает оптимально в предположении, что большинство узлов разделяют одинаковое мнение о входящих транзакциях. Кроме того, в таких протоколах злоумышленник может получить стимул разделить локальные представления честных узлов (отправив транзакцию только половине узлов в самом конце слота) и остановить протокол в результате.

Многие исследователи высказали необходимость более эффективного механизма устойчивости к цензуре на Ethereum. Некоторые предложения, например, Multiple Concurrent Proposer (MCP)иСписок принудительного выбора вилки (FOCIL), появились и стали центром продолжающегося обсуждения.

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

Одним из примеров механизма сопротивления цензуре для ASS является Angstrom. Чтобы гарантировать, что все действительные ордера будут включены в предстоящий слот, узлы Angstrom должны транслировать любые проверенные входящие ордера и достигать консенсуса по их включению в предлагаемый пакет транзакций. Если в пакете отсутствуют ордера, наблюдаемые большей частью сети, инициатор будет оштрафован. Вот иллюстрация механизма сопротивления цензуре для Ангстрема.

Сопротивление цензуре в децентрализованном суверенном приложении

Дилемма комбинируемости

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

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

Предварительное подтверждение включения

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

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

Иллюстрация включения preconf с ASS

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

Общие прикладные специфичные последователи и обязательства строителя

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

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

Иллюстрация обязательства строителя для атомной композиции между суверенными и недуверенными dApps (справа) и общего приложения-специфического последователя для атомной композиции между суверенными приложениями (слева)

Несмотря на то, что остаются вопросы об экономической динамике обязательств застройщиков, осуществимости предварительного подтверждения включения и потенциальных эффектах второго порядка, мы уверены, что проблемы компонуемости ASS будут решены со временем. Такие команды, как AstriaиPrimevактивно исследуют и разрабатывают усовершенствованные структуры для общей последовательности и обязательств строителя. По мере продвижения этих достижений, комбинируемость больше не будет проблемой для суверенных приложений.

ASS против App-specific L2s и L1s

В настоящее время dApps должны создавать цепочки, специфические для приложений, если они хотят контролировать последовательность своих транзакций. Концепции, такие как Протокол Owned Builder (PoB)позволяет Cosmos L1 иметь более выразительные правила секвенирования, которые помогают захватывать и перераспределять MEV для своих приложений. Аналогично, секвенсор L2 с VSR также может выполнять такие операции. Обе эти решения позволяют более выразительное секвенирование и захват MEV его приложениями, но ASS уникален благодаря следующим характеристикам.

1. Нет дополнительных накладных расходов на доверие от исполнения транзакции - ASS не выполняет или урегулирует упорядоченную транзакцию. Только последовательность делегирована. Базовое доверие предполагается в среде нативного выполнения, такой как Ethereum или другие L2.
2. Доступ к ликвидности и потоку ордеров – Пользователям не нужно строить мост. dApps могут напрямую использовать поток и ликвидность в сети.
3. Актив остается в нативной среде исполнения и не может быть заморожен — в отличие от L2, большинство ASS не требует от пользователей блокировки своих средств в промежуточных контрактах. Такой выбор конструкции обеспечивает лучшую безопасность: если секвенсор для конкретного приложения выходит из строя, потенциальный ущерб ограничен, поскольку секвенсор может контролировать транзакции только в границах, установленных смарт-контрактом. В то время как в некоторых решениях L2 реализованы функции безопасности, такие как аварийные люки и принудительное включение - эти меры часто сложно использовать на практике. Пользователям может потребоваться несколько дней, прежде чем они смогут активировать аварийный выход после потери соединения с обновлениями L2. Аналогично, принудительное включение через L1 обычно требует как минимум в деньзадержка. Возможно, самое важное, эти меры безопасности обычно требуют технических навыков, которыми большинство пользователей не обладает, что делает их непрактичными для обычного человека.
4. Предположение о высокой живучести - живучесть L2 зависит от узлов выполнения, которые обычно являются последовательными агрегаторами, если не основаны на последовательности. Живучесть L1 зависит от честного большинства узлов, повторно выполняющих соответствующие функции перехода состояния. Живучесть суверенного приложения в основном зависит от базовой среды выполнения, и умные контракты могут указывать части, которые должны полагаться на приложение-специфические агрегаторы.

Таблица сравнения суверенных приложений, L2, Based L2 и L1

Заключение

ASS дает приложениям полную суверенитет над последовательностью транзакций, что позволяет им определять пользовательские правила без сложностей выполнения. Этот суверенитет позволяет приложениям контролировать свое выполнение для оптимизации результатов для своих пользователей. Например, на Angstrom LP и обменники рассматриваются как участники первого класса, их экономический выигрыш напрямую увеличивается благодаря пользовательским правилам последовательности.

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

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

Мы здесь, чтобы сделать DeFi более устойчивым, один ASS за раз.

Отказ от ответственности:

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