Адресация 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, снижая влияние майнеров на порядок транзакций. Тарун позже развил эту идеюпоказывая, как правила последовательности, специфичные для приложения, могут значительно влиять на функции вознаграждения для участников протокола, таких как пользователи, валидаторы и последователи.
Здесь функция выплат представляет экономическую ценность конкретного порядка сделок. Эта стоимость отражает прибыль или полезность, полученную участниками протокола, показывая, как порядок сделок влияет на их финансовые результаты. Существуют две ключевые характеристики функций выплат:
Когда функции погашения обладают обоими этими характеристиками, оптимизация стратегии последовательности становится чрезвычайно сложной. В таких случаях требуются более сложные и индивидуальные подходы на уровне приложения, чтобы обеспечить справедливые результаты для пользователей и устойчивую экосистему DeFi.
Для понимания ASS давайте сначала рассмотрим существующую цепочку поставки транзакций.
В текущей системе:
На рисунке ниже показан этот процесс, демонстрирующий, как транзакции переходят от mempools к блокчейну через builders и доверенные ретрансляторы.
Диаграмма текущей цепочки поставок транзакций
Приложения, активируемые с помощью ASS, с другой стороны, обладают следующими свойствами:
ASS позволяет приложениям в любой цепочке восстановить суверенитет над своим исполнением и состоянием контракта, тем самым позволяя суверенным приложениям.
Исходя из этих основных принципов, давайте рассмотрим Angstrom как практический пример суверенного приложения. Angstrom - это крючок UniswapV4, который защищает своих поставщиков ликвидности от неблагоприятного подбора арбитражников CEX-DEX, а также защищает меняющихся от атаки бутерброда. Сеть узлов Angstrom достигает консенсуса, параллельно с Ethereum, относительно набора транзакций, которые будут выполнены в следующем блоке. Общий поток следующий:
Следующая диаграмма иллюстрирует действие суверенного приложения.
Цепочка поставок транзакций в Ангстреме
По своей сути, ASS является формой частичного блочного строительства, где суверенное приложение делегирует права на последовательность децентрализованной сети операторов, следуя предписанному правилу последовательности. Следовательно, ASS неизбежно включает внешние стороны, которые вносят дополнительные предположения о живучести и доверии.
Суверенные приложения зависят от специфичных для приложений секвенсоров, чтобы правильно следовать протоколу и обеспечивать своевременные обновления состояния. В случае нарушения живости, такого как сетевое разделениеПользователи могут быть не в состоянии взаимодействовать с частями приложения, пока не будет восстановлено действительное согласие.
Суверенные приложения также могут ограничить область состояния контракта, обновления которого зависят от их последователей. Это помогает минимизировать внешние зависимости контракта таким образом, что критические состояния, такие как депозитная ликвидность, остаются доступными даже в случае сбоя последователя.
Для обеспечения соблюдения последовательности предписанных правил суверенные приложения могут использовать криптоэкономические решения (например, PoS) или криптографические методы (например, TEE или MPC). Конкретный подход может значительно различаться в зависимости от потребностей приложения; некоторые могут требовать согласования оптимальности выполнения, в то время как другие могут сосредоточиться на обеспечении конфиденциальности предварительного выполнения с помощью криптографических механизмов. Существует множество инструментов, доступных для снижения доверительных накладных расходов последователей и достижения уникальных целей каждого суверенного приложения.
Существуют различные виды цензуры, от которых страдает экосистема Ethereum:
Многие исследователи высказали необходимость более эффективного механизма устойчивости к цензуре на Ethereum. Некоторые предложения, например, Multiple Concurrent Proposer (MCP)иСписок принудительного выбора вилки (FOCIL), появились и стали центром продолжающегося обсуждения.
Сопротивление цензуре также является серьезной проблемой для суверенного применения. Специфичные для приложения секвенсоры, скорее всего, являются внешними сущностями, заинтересованными в получении дополнительных частных транзакций и потока заказов. Например, валидатор для конкретного приложения, который является маркет-мейкером, имеет стимул подвергать цензуре транзакции, отправленные конкурирующими маркет-мейкерами. Таким образом, суверенное приложение сверху может подвергнуться локальной цензуре, даже если базовый протокол не поддерживает цензуру.
Одним из примеров механизма сопротивления цензуре для ASS является Angstrom. Чтобы гарантировать, что все действительные ордера будут включены в предстоящий слот, узлы Angstrom должны транслировать любые проверенные входящие ордера и достигать консенсуса по их включению в предлагаемый пакет транзакций. Если в пакете отсутствуют ордера, наблюдаемые большей частью сети, инициатор будет оштрафован. Вот иллюстрация механизма сопротивления цензуре для Ангстрема.
Сопротивление цензуре в децентрализованном суверенном приложении
Одной из основных проблем, с которыми сталкиваются суверенные приложения, является обеспечение комбинируемости с транзакциями, взаимодействующими с состояниями внешних контрактов. Простое объединение специфичных для приложения транзакций с произвольными внешними транзакциями подрывает свойство агностики порядка, которое необходимо для защиты суверенного приложения и его пользователей. Одна недействительная транзакция, не относящаяся к ASS, при объединении с приложением-специфичным может иметь вторичный эффект отката всей группы. Когда это происходит, суверенное приложение не может выполнять заказы своих пользователей в выделенном слоте (несмотря на достижение действительного согласия), что вредит пользовательскому опыту и общему благополучию.
Однако есть потенциальные решения проблемы композиции, несколько из которых исследуются различными командами. Они включают концепции, такие как предварительные подтверждения включения, общие последовательности приложений и обязательства строителя, каждое из которых предлагает компромиссы между степенью композиции и накладными расходами на доверие.
Для объяснения предварительных подтверждений включения важно сначала понять, как работают основанные предварительные подтверждения. Основанные предварительные подтверждения используют криптоэкономическую безопасность, гарантируя, что предлагающие вложили заложенные залоги, чтобы гарантировать включение определенного набора транзакций перед слотом в текущей эпохе. Эта гарантия ограничена размером облигации, размещенной участвующими предлагающими.
Предварительные подтверждения включения — это специализированная форма предварительных подтверждений на основе, в которой включение транзакции не зависит от какого-либо состояния контракта. Транзакции, запрашивающие предварительные подтверждения включения, должны быть независимыми от штата и неконфликтными, то есть на их выполнение не влияет их положение в блоке. Используя предварительные подтверждения включения, инициаторы могут взять на себя обязательство включить транзакцию, не относящуюся к ASS, только в том случае, если пакет ASS включен в тот же блок. Такой подход обеспечивает криптоэкономически обусловленную компонуемость между неконфликтными транзакциями и пакетами ASS.
Иллюстрация включения preconf с ASS
Однако, учитывая ограниченную комбинируемость, предоставляемую этим решением, дополнительная сложность и накладные расходы на доверие могут перевесить его преимущества для определенных суверенных приложений. В результате важно исследовать альтернативные подходы, которые могли бы предложить более эффективное сочетание простоты и функциональности.
Вместо полагания на обязательства инициатора, суверенные приложения могут использовать специфичные для приложения последовательности для управления упорядочением транзакций между несколькими приложениями. Например, последовательность, обрабатывающая транзакции для нескольких суверенных приложений, может обеспечивать атомарную компонуемость между ними, при условии, что она следует правилам упорядочения каждого из них. Этот подход общих специфичных для приложения последовательностей обеспечивает безупречную компонуемость и координацию между суверенными приложениями.
Однако для приложений, не относящихся к суверенным, требуется другое решение. Обязательства включения транзакций от строителей блоков, которые участвуют в последовательности для суверенных приложений, могут создавать атомарную компонуемость между суверенными и несуверенными приложениями. Строитель гарантирует указанный порядок транзакций в обоих типах приложений. Такое обязательство строителя может преодолеть проблему компонуемости для ASS.
Иллюстрация обязательства строителя для атомной композиции между суверенными и недуверенными dApps (справа) и общего приложения-специфического последователя для атомной композиции между суверенными приложениями (слева)
Несмотря на то, что остаются вопросы об экономической динамике обязательств застройщиков, осуществимости предварительного подтверждения включения и потенциальных эффектах второго порядка, мы уверены, что проблемы компонуемости ASS будут решены со временем. Такие команды, как AstriaиPrimevактивно исследуют и разрабатывают усовершенствованные структуры для общей последовательности и обязательств строителя. По мере продвижения этих достижений, комбинируемость больше не будет проблемой для суверенных приложений.
В настоящее время dApps должны создавать цепочки, специфические для приложений, если они хотят контролировать последовательность своих транзакций. Концепции, такие как Протокол Owned Builder (PoB)позволяет Cosmos L1 иметь более выразительные правила секвенирования, которые помогают захватывать и перераспределять MEV для своих приложений. Аналогично, секвенсор L2 с VSR также может выполнять такие операции. Обе эти решения позволяют более выразительное секвенирование и захват MEV его приложениями, но ASS уникален благодаря следующим характеристикам.
Таблица сравнения суверенных приложений, L2, Based L2 и L1
ASS дает приложениям полную суверенитет над последовательностью транзакций, что позволяет им определять пользовательские правила без сложностей выполнения. Этот суверенитет позволяет приложениям контролировать свое выполнение для оптимизации результатов для своих пользователей. Например, на Angstrom LP и обменники рассматриваются как участники первого класса, их экономический выигрыш напрямую увеличивается благодаря пользовательским правилам последовательности.
Кроме того, ASS может использовать ряд криптоэкономических и криптографических инструментов для обеспечения оптимальности вознаграждений для пользователей и реализации надежных механизмов сопротивления цензуре. Криптоэкономические решения, такие как стейкинг и сокращение, могут стимулировать честное поведение среди последователей, а криптографические методы, такие как TEE и MPC, повышают конфиденциальность и безопасность. С помощью этих инструментов потенциал дизайна ASS огромен, что позволяет создавать более безопасные, эффективные и ориентированные на пользователей суверенные приложения.
Несмотря на предоставляемые возможности ASS, по-прежнему существуют вызовы, такие как отсутствие родной совместимости. Однако решения, такие как предварительное подтверждение включения, общий ASS и обязательство строителя, представляют собой многообещающие способы преодоления этих препятствий. Хотя остаются некоторые вопросы, мы готовы совершенствовать эти подходы, чтобы обеспечить более гладкое, более совместимое ASS.
Мы здесь, чтобы сделать DeFi более устойчивым, один ASS за раз.
Адресация 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, снижая влияние майнеров на порядок транзакций. Тарун позже развил эту идеюпоказывая, как правила последовательности, специфичные для приложения, могут значительно влиять на функции вознаграждения для участников протокола, таких как пользователи, валидаторы и последователи.
Здесь функция выплат представляет экономическую ценность конкретного порядка сделок. Эта стоимость отражает прибыль или полезность, полученную участниками протокола, показывая, как порядок сделок влияет на их финансовые результаты. Существуют две ключевые характеристики функций выплат:
Когда функции погашения обладают обоими этими характеристиками, оптимизация стратегии последовательности становится чрезвычайно сложной. В таких случаях требуются более сложные и индивидуальные подходы на уровне приложения, чтобы обеспечить справедливые результаты для пользователей и устойчивую экосистему DeFi.
Для понимания ASS давайте сначала рассмотрим существующую цепочку поставки транзакций.
В текущей системе:
На рисунке ниже показан этот процесс, демонстрирующий, как транзакции переходят от mempools к блокчейну через builders и доверенные ретрансляторы.
Диаграмма текущей цепочки поставок транзакций
Приложения, активируемые с помощью ASS, с другой стороны, обладают следующими свойствами:
ASS позволяет приложениям в любой цепочке восстановить суверенитет над своим исполнением и состоянием контракта, тем самым позволяя суверенным приложениям.
Исходя из этих основных принципов, давайте рассмотрим Angstrom как практический пример суверенного приложения. Angstrom - это крючок UniswapV4, который защищает своих поставщиков ликвидности от неблагоприятного подбора арбитражников CEX-DEX, а также защищает меняющихся от атаки бутерброда. Сеть узлов Angstrom достигает консенсуса, параллельно с Ethereum, относительно набора транзакций, которые будут выполнены в следующем блоке. Общий поток следующий:
Следующая диаграмма иллюстрирует действие суверенного приложения.
Цепочка поставок транзакций в Ангстреме
По своей сути, ASS является формой частичного блочного строительства, где суверенное приложение делегирует права на последовательность децентрализованной сети операторов, следуя предписанному правилу последовательности. Следовательно, ASS неизбежно включает внешние стороны, которые вносят дополнительные предположения о живучести и доверии.
Суверенные приложения зависят от специфичных для приложений секвенсоров, чтобы правильно следовать протоколу и обеспечивать своевременные обновления состояния. В случае нарушения живости, такого как сетевое разделениеПользователи могут быть не в состоянии взаимодействовать с частями приложения, пока не будет восстановлено действительное согласие.
Суверенные приложения также могут ограничить область состояния контракта, обновления которого зависят от их последователей. Это помогает минимизировать внешние зависимости контракта таким образом, что критические состояния, такие как депозитная ликвидность, остаются доступными даже в случае сбоя последователя.
Для обеспечения соблюдения последовательности предписанных правил суверенные приложения могут использовать криптоэкономические решения (например, PoS) или криптографические методы (например, TEE или MPC). Конкретный подход может значительно различаться в зависимости от потребностей приложения; некоторые могут требовать согласования оптимальности выполнения, в то время как другие могут сосредоточиться на обеспечении конфиденциальности предварительного выполнения с помощью криптографических механизмов. Существует множество инструментов, доступных для снижения доверительных накладных расходов последователей и достижения уникальных целей каждого суверенного приложения.
Существуют различные виды цензуры, от которых страдает экосистема Ethereum:
Многие исследователи высказали необходимость более эффективного механизма устойчивости к цензуре на Ethereum. Некоторые предложения, например, Multiple Concurrent Proposer (MCP)иСписок принудительного выбора вилки (FOCIL), появились и стали центром продолжающегося обсуждения.
Сопротивление цензуре также является серьезной проблемой для суверенного применения. Специфичные для приложения секвенсоры, скорее всего, являются внешними сущностями, заинтересованными в получении дополнительных частных транзакций и потока заказов. Например, валидатор для конкретного приложения, который является маркет-мейкером, имеет стимул подвергать цензуре транзакции, отправленные конкурирующими маркет-мейкерами. Таким образом, суверенное приложение сверху может подвергнуться локальной цензуре, даже если базовый протокол не поддерживает цензуру.
Одним из примеров механизма сопротивления цензуре для ASS является Angstrom. Чтобы гарантировать, что все действительные ордера будут включены в предстоящий слот, узлы Angstrom должны транслировать любые проверенные входящие ордера и достигать консенсуса по их включению в предлагаемый пакет транзакций. Если в пакете отсутствуют ордера, наблюдаемые большей частью сети, инициатор будет оштрафован. Вот иллюстрация механизма сопротивления цензуре для Ангстрема.
Сопротивление цензуре в децентрализованном суверенном приложении
Одной из основных проблем, с которыми сталкиваются суверенные приложения, является обеспечение комбинируемости с транзакциями, взаимодействующими с состояниями внешних контрактов. Простое объединение специфичных для приложения транзакций с произвольными внешними транзакциями подрывает свойство агностики порядка, которое необходимо для защиты суверенного приложения и его пользователей. Одна недействительная транзакция, не относящаяся к ASS, при объединении с приложением-специфичным может иметь вторичный эффект отката всей группы. Когда это происходит, суверенное приложение не может выполнять заказы своих пользователей в выделенном слоте (несмотря на достижение действительного согласия), что вредит пользовательскому опыту и общему благополучию.
Однако есть потенциальные решения проблемы композиции, несколько из которых исследуются различными командами. Они включают концепции, такие как предварительные подтверждения включения, общие последовательности приложений и обязательства строителя, каждое из которых предлагает компромиссы между степенью композиции и накладными расходами на доверие.
Для объяснения предварительных подтверждений включения важно сначала понять, как работают основанные предварительные подтверждения. Основанные предварительные подтверждения используют криптоэкономическую безопасность, гарантируя, что предлагающие вложили заложенные залоги, чтобы гарантировать включение определенного набора транзакций перед слотом в текущей эпохе. Эта гарантия ограничена размером облигации, размещенной участвующими предлагающими.
Предварительные подтверждения включения — это специализированная форма предварительных подтверждений на основе, в которой включение транзакции не зависит от какого-либо состояния контракта. Транзакции, запрашивающие предварительные подтверждения включения, должны быть независимыми от штата и неконфликтными, то есть на их выполнение не влияет их положение в блоке. Используя предварительные подтверждения включения, инициаторы могут взять на себя обязательство включить транзакцию, не относящуюся к ASS, только в том случае, если пакет ASS включен в тот же блок. Такой подход обеспечивает криптоэкономически обусловленную компонуемость между неконфликтными транзакциями и пакетами ASS.
Иллюстрация включения preconf с ASS
Однако, учитывая ограниченную комбинируемость, предоставляемую этим решением, дополнительная сложность и накладные расходы на доверие могут перевесить его преимущества для определенных суверенных приложений. В результате важно исследовать альтернативные подходы, которые могли бы предложить более эффективное сочетание простоты и функциональности.
Вместо полагания на обязательства инициатора, суверенные приложения могут использовать специфичные для приложения последовательности для управления упорядочением транзакций между несколькими приложениями. Например, последовательность, обрабатывающая транзакции для нескольких суверенных приложений, может обеспечивать атомарную компонуемость между ними, при условии, что она следует правилам упорядочения каждого из них. Этот подход общих специфичных для приложения последовательностей обеспечивает безупречную компонуемость и координацию между суверенными приложениями.
Однако для приложений, не относящихся к суверенным, требуется другое решение. Обязательства включения транзакций от строителей блоков, которые участвуют в последовательности для суверенных приложений, могут создавать атомарную компонуемость между суверенными и несуверенными приложениями. Строитель гарантирует указанный порядок транзакций в обоих типах приложений. Такое обязательство строителя может преодолеть проблему компонуемости для ASS.
Иллюстрация обязательства строителя для атомной композиции между суверенными и недуверенными dApps (справа) и общего приложения-специфического последователя для атомной композиции между суверенными приложениями (слева)
Несмотря на то, что остаются вопросы об экономической динамике обязательств застройщиков, осуществимости предварительного подтверждения включения и потенциальных эффектах второго порядка, мы уверены, что проблемы компонуемости ASS будут решены со временем. Такие команды, как AstriaиPrimevактивно исследуют и разрабатывают усовершенствованные структуры для общей последовательности и обязательств строителя. По мере продвижения этих достижений, комбинируемость больше не будет проблемой для суверенных приложений.
В настоящее время dApps должны создавать цепочки, специфические для приложений, если они хотят контролировать последовательность своих транзакций. Концепции, такие как Протокол Owned Builder (PoB)позволяет Cosmos L1 иметь более выразительные правила секвенирования, которые помогают захватывать и перераспределять MEV для своих приложений. Аналогично, секвенсор L2 с VSR также может выполнять такие операции. Обе эти решения позволяют более выразительное секвенирование и захват MEV его приложениями, но ASS уникален благодаря следующим характеристикам.
Таблица сравнения суверенных приложений, L2, Based L2 и L1
ASS дает приложениям полную суверенитет над последовательностью транзакций, что позволяет им определять пользовательские правила без сложностей выполнения. Этот суверенитет позволяет приложениям контролировать свое выполнение для оптимизации результатов для своих пользователей. Например, на Angstrom LP и обменники рассматриваются как участники первого класса, их экономический выигрыш напрямую увеличивается благодаря пользовательским правилам последовательности.
Кроме того, ASS может использовать ряд криптоэкономических и криптографических инструментов для обеспечения оптимальности вознаграждений для пользователей и реализации надежных механизмов сопротивления цензуре. Криптоэкономические решения, такие как стейкинг и сокращение, могут стимулировать честное поведение среди последователей, а криптографические методы, такие как TEE и MPC, повышают конфиденциальность и безопасность. С помощью этих инструментов потенциал дизайна ASS огромен, что позволяет создавать более безопасные, эффективные и ориентированные на пользователей суверенные приложения.
Несмотря на предоставляемые возможности ASS, по-прежнему существуют вызовы, такие как отсутствие родной совместимости. Однако решения, такие как предварительное подтверждение включения, общий ASS и обязательство строителя, представляют собой многообещающие способы преодоления этих препятствий. Хотя остаются некоторые вопросы, мы готовы совершенствовать эти подходы, чтобы обеспечить более гладкое, более совместимое ASS.
Мы здесь, чтобы сделать DeFi более устойчивым, один ASS за раз.