Глубокое погружение в тему App-Specific Sequencing и как она позволяет создавать суверенные приложения
Отдельное спасибо @0xtaetaehoho, @ThogardPvP, @dex_chen_V, @Jskybowen, @visavishesh, @TrustlessState, @RyanSAdams, @FrankieIsLost, @0xnagu for the feedback, and credit to @tarunchitra and @matheusVXF за то, что в очередной раз на годы опередили игру.
Решение проблемы MEV (Maximal Extractable Value) является постоянной проблемой для Ethereum; цепочка поставок стоимости стимулирует постоянную активность арбитражников с различными стратегиями разной степени сложности, часто в ущерб розничным пользователям. Хотя многие исследователи пытались решить проблему MEV с помощью изменений на уровне протокола, эти усилия пока не привели к удовлетворительному решению. Каноническая инфраструктура и аукционные механизмы, используемые в настоящее время, способны конкурентно захватить единовременный MEV в блоке, но захват без справедливого перераспределения неадекватен: почему ценность MEV должна доставаться сетевым валидаторам, когда ее можно более эффективно захватить и интернализировать на основе каждого приложения?
Появилась система Application-Specific Sequencing (ASS). Вместо того чтобы пытаться переписать правила на уровне протокола, ASS дает отдельным приложениям возможность контролировать последовательность транзакций. Таким образом, ASS позволяет ончейн-приложениям защитить своих пользователей и ликвидность от пагубного влияния MEV, а также дает им возможность получить прибыль, которая в противном случае была бы потеряна для валидаторов Ethereum.
Представьте себе потенциал: вместо того чтобы высокочастотные трейдеры соревновались в максимальном арбитраже каждого пользователя (при этом почти вся арбитражная стоимость утекала к валидаторам и, следовательно, к базовым цепочкам), каждое приложение могло бы определить свои собственные правила упорядочивания транзакций, создавая более адаптированную, эффективную и справедливую систему для своих пользователей. Это знаменует собой переход от попыток решить проблему MEV на сетевом уровне к ее решению там, где она важнее всего - в самом приложении.
Концепция Application-Specific Sequencing (ASS) возникла благодаря работе Матеуса над Verifiable Sequencing Rule (VSR) для децентрализованных бирж (DEXes). Матеус продемонстрировал, что VSR может улучшить исполнение сделок и смягчить MEV за счет уменьшения влияния майнеров на порядок транзакций. Позднее Тарун развил эту идею, показав, как специфические для приложений правила секвенирования могут существенно повлиять на функции вознаграждения участников протокола, таких как пользователи, валидаторы и секвенсоры.
Здесь функция вознаграждения представляет собой экономическую ценность определенного порядка транзакций. Эта величина отражает прибыль или полезность, получаемую участниками протокола, показывая, как упорядочивание транзакций влияет на их финансовые результаты. Есть две важные характеристики функций вознаграждения:
Негладкие выплаты: Небольшие изменения в упорядочивании могут привести к большим изменениям в MEV. Немонотонные выплаты: Небольшие изменения в упорядочивании могут либо увеличить, либо уменьшить MEV, но не постоянно в одном направлении. Если функции вознаграждения обладают обеими этими характеристиками, оптимизация стратегии последовательности становится очень сложной. В таких случаях необходимы более сложные и индивидуальные подходы на уровне приложений, чтобы обеспечить справедливые результаты для пользователей и устойчивую экосистему DeFi.
Чтобы понять принцип работы ASS, давайте сначала рассмотрим существующую цепочку поставок транзакций.
В текущей системе:
Транзакции отправляются в публичные или частные мемпулы.
Строители собирают эти транзакции и упаковывают их в блоки.
Затем строители соревнуются на аукционе блоков.
Блок победившего строителя включается в блокчейн, а стоимость, которую он предложил, выплачивается выбранному участнику аукциона за данный блок.
На рисунке ниже показано, как транзакции поступают из мемпулов в блокчейн через строителей и доверенные ретрансляторы.
С другой стороны, приложения, разрешенные ASS, обладают следующими свойствами:
Ограниченные права секвенирования: Это ограничение гарантирует, что только назначенный секвенсор или валидаторы со ставкой могут взаимодействовать с контрактом приложения на цепочке, в которую он зачисляется, что предотвращает недобросовестный обход логики приложения для внутреннего перераспределения стоимости.
Мемпулы для конкретных приложений: Вместо того чтобы отправлять транзакции в публичный мемпул, пользователи отправляют подписанные сообщения, выражающие их намерения, в мемпул, предназначенный для конкретного приложения. Затем эти намерения собираются и обрабатываются секвенсором конкретного приложения.
Агнозируемые результаты: Чтобы обеспечить соблюдение правила последовательности и доставить оптимальные экономические выплаты целевым пользователям, транзакции ASS должны быть не зависящими от порядка транзакций строителей в оставшейся части блока. Это достигается за счет того, что состояние приложения контролируется его механизмом консенсуса. Ордера ASS затем объединяются в один пакет, который отправляется строителям для включения. Учитывая, что этот пучок не вступает в спор с состоянием, к которому обращаются другие приложения, он не зависит от их положения в блоке.
ASS позволяет приложениям на любой цепочке вернуть суверенитет над своим состоянием исполнения и контрактов, что позволяет создавать суверенные приложения.
Учитывая эти основополагающие принципы, давайте рассмотрим Angstrom в качестве практического примера суверенного приложения. Angstrom - это крючок UniswapV4, который защищает поставщиков ликвидности от неблагоприятного отбора арбитражерами CEX-DEX, а также защищает свопперов от сэндвич-атак. Сеть узлов Angstrom параллельно с Ethereum приходит к консенсусу по набору транзакций, которые должны быть выполнены в следующем блоке. Общий процесс происходит следующим образом:
Арбитражники CEX-DEX торгуются за право быть первой транзакцией, совершающей своп через AMM (без комиссии). Тем временем пользователи отправляют в мемпул Angstrom свои предполагаемые свопы в виде подписанных лимитных ордеров.
Сеть Angstrom запускает свой протокол консенсуса и формирует пул, в котором первым свопом становится сделка арбитражера с наибольшей ставкой. Сумма заявки впоследствии распределяется пропорционально между базовыми LP в диапазоне свопа. Все остальные действительные лимитные ордера вместе с базовой ликвидностью AMM исполняются по единой клиринговой цене.
Затем этот пакет отправляется строителям Ethereum и публичному мемпулу узлом, предлагающим слот Angstrom.
Строители включают пучок Angstrom в любую позицию в блоке. Благодаря своей конструкции, не зависящей от порядков, пучок просто должен заплатить базовую плату за включение.
Следующая диаграмма иллюстрирует суверенное приложение в действии.
По своей сути ASS - это форма частичного построения блоков, в которой суверенное приложение делегирует права на установление очередности децентрализованной сети операторов, следующих предписанным правилам установления очередности. Следовательно, в ASS неизбежно участвуют внешние стороны, которые вводят дополнительные предположения об оперативности и доверии.
Суверенные приложения зависят от секвенсоров конкретных приложений, которые должны правильно следовать протоколу и своевременно обновлять состояние. В случае нарушения надежности, например разрыва сети, пользователи могут не иметь возможности взаимодействовать с частями приложения до тех пор, пока не будет восстановлен действительный консенсус.
Суверенные приложения также могут ограничить область действия состояния контракта, обновления которого зависят от их секвенсоров. Это позволяет минимизировать внешние зависимости контракта, чтобы критически важные состояния, такие как депонированная ликвидность, оставались доступными даже в случае отказа секвенсора.
Для обеспечения соблюдения секвенсорами предписанных правил секвенирования суверенные приложения могут использовать криптоэкономические решения (например, PoS) или криптографические методы (например, TEE или MPC). Конкретный подход может существенно различаться в зависимости от потребностей приложения; некоторые из них могут требовать консенсуса по поводу оптимальности выполнения, в то время как другие могут сосредоточиться на обеспечении конфиденциальности перед выполнением с помощью криптографических механизмов. Существует множество инструментов, позволяющих снизить накладные расходы на доверие к секвенсорам и удовлетворить уникальные цели каждого суверенного приложения.
В экосистеме Ethereum существуют различные виды цензуры:
Регулятивная цензура: Сборщики и ретрансляторы цензурируют транзакции на основании санкционного списка OFAC. Это одна из наиболее заметных форм цензуры, присутствующих в Ethereum на сегодняшний день, которая применяется преимущественно ретрансляторами.
Экономическая цензура: Мотивированный злоумышленник может подкупить организатора блокчейна, чтобы тот подверг цензуре транзакции жертвы.
Цензура на уровне узлов: Узлы в P2P-сети могут отказываться распространять входящие транзакции. Это может стать серьезной проблемой, если протокол работает оптимально в предположении, что большинство узлов одинаково смотрят на входящие транзакции. Кроме того, в таких протоколах у противника может появиться стимул разделить локальные представления честных узлов (отправив транзакцию только половине узлов в самом конце слота) и в результате остановить протокол. Многие исследователи заявляли о необходимости создания более совершенного механизма противодействия цензуре в Ethereum. Некоторые предложения, такие как Multiple Concurrent Proposer (MCP) и Fork-Choice enforced Inclusion List (FOCIL), всплыли и стали центром непрекращающейся дискуссии.
Устойчивость к цензуре также является одной из главных проблем для суверенных приложений. Секвенсоры для конкретных приложений, скорее всего, являются внешними сущностями с различными интересами в получении дополнительных частных транзакций и потока заказов. Например, специфический валидатор приложения, являющийся маркет-мейкером, имеет стимул цензурировать транзакции, отправленные конкурирующими маркет-мейкерами. Таким образом, суверенное приложение может подвергаться локальной цензуре, даже если базовый протокол не подвергается цензуре.
Одним из примеров механизма противодействия цензуре для ASS является Angstrom. Чтобы гарантировать, что все действительные ордера будут включены в предстоящий слот, узлы Angstrom должны транслировать все проверенные входящие ордера и достигать консенсуса по их включению в предлагаемый пучок транзакций. Если в пакете отсутствуют ордера, наблюдаемые большинством сети, предлагающий транзакцию будет наказан. Вот иллюстрация механизма противодействия цензуре для Angstrom.
Одна из основных проблем, с которой сталкиваются суверенные приложения, - обеспечение совместимости с транзакциями, взаимодействующими с внешними состояниями контрактов. Простое объединение транзакций, специфичных для приложения, с произвольными внешними транзакциями подрывает свойство диагностики порядка, которое необходимо для защиты суверенного приложения и его пользователей. Одна недействительная транзакция, не относящаяся к АСС, в сочетании с транзакцией, относящейся к конкретному приложению, может иметь эффект второго порядка - отменить всю связку. В этом случае суверенное приложение не сможет выполнить заказы своих пользователей в отведенном слоте (несмотря на достижение действительного консенсуса), что негативно скажется на опыте пользователей и общем благосостоянии.
Однако существуют потенциальные решения проблемы композитности, и некоторые из них изучаются различными командами. К ним относятся такие концепции, как предварительное подтверждение включения, общие секвенсоры для конкретных приложений и обязательства строителей, каждая из которых предлагает компромисс между степенью совместимости и доверительными расходами.
Чтобы объяснить, что такое предварительное подтверждение включения, важно сначала понять, как работает основанное предварительное подтверждение. Основанное предварительное подтверждение использует криптоэкономическую безопасность, гарантируя, что участники предложения внесли залог в виде ставки, чтобы гарантировать включение определенного набора транзакций в слот в текущей эпохе. Эта гарантия ограничена размером залога, внесенного участниками.
Предварительные подтверждения включения являются специализированной формой основанных предварительных подтверждений, в которых включение транзакций не зависит от состояния контракта. Транзакции, запрашивающие предварительное подтверждение включения, должны быть независимыми от состояния контракта и неконфликтными, то есть на их выполнение не влияет их положение в блоке. Используя предварительные подтверждения включения, участники могут взять на себя обязательство включить транзакцию, не относящуюся к ASS, только если пакет ASS включен в тот же блок. Такой подход обеспечивает криптоэкономическую совместимость между неконфликтными транзакциями и пакетами ASS.
Однако, учитывая ограниченную композитность, обеспечиваемую этим решением, дополнительная сложность и накладные расходы на доверие могут перевесить его преимущества для некоторых суверенных приложений. Поэтому важно изучить альтернативные подходы, которые могли бы предложить более эффективный баланс между простотой и функциональностью.
Вместо того, чтобы полагаться на обязательства разработчика, суверенные приложения могут использовать секвенсоры для конкретных приложений, чтобы управлять упорядочиванием транзакций в нескольких приложениях. Например, секвенсор, обрабатывающий транзакции для нескольких суверенных приложений, может облегчить атомарную компоновку между ними, если он следует правилам последовательности каждого из них. Такой подход к секвенсорам, ориентированным на конкретные приложения, обеспечивает беспрепятственную совместимость и координацию между суверенными приложениями.
Однако для несуверенных приложений требуется другое решение. Обязательства по включению транзакций от строителей блоков, которые участвуют в секвенсировании для суверенных приложений, могут создать атомарную совместимость между несуверенными и суверенными приложениями. Строитель обеспечивает заданный порядок транзакций в обоих типах приложений. Такие обязательства строителей могут устранить разрыв в совместимости для ASS.
Хотя остаются вопросы об экономической динамике обязательств строителей, целесообразности предварительного подтверждения включения и потенциальных эффектах второго порядка, мы уверены, что со временем проблемы композитности ASS будут решены. Такие команды, как Astria и Primev, активно исследуют и разрабатывают улучшенные структуры для совместной последовательности и обязательств строителей. По мере продвижения этих разработок композитность перестанет быть проблемой для суверенных приложений.
В настоящее время dApp вынуждены создавать специфические для приложений цепочки, если они хотят взять под контроль последовательность своих транзакций. Такие концепции, как Protocol Owned Builder (PoB), позволяют Cosmos L1 иметь более выразительные правила секвенирования, которые помогают перехватывать и перераспределять MEV для своего приложения. Аналогично, секвенсор L2 с VSR также может выполнять подобные операции. Хотя оба решения позволяют более выразительно выстраивать последовательность и перехватывать MEV для своих приложений, ASS является уникальным благодаря следующим характеристикам.
Отсутствие накладных расходов на доверие при выполнении транзакций - ASS не выполняет и не завершает секвенированную транзакцию. Делегируется только секвенирование. Базовое предположение о доверии исходит от родной среды исполнения, такой как Ethereum или другие L2.
Доступ к ликвидности и потоку ордеров - Пользователям не нужно устанавливать мост. dApps могут напрямую использовать поток и ликвидность в цепочке.
Активы остаются в родной среде исполнения и не могут быть заморожены - в отличие от L2, большинство ASS не требуют от пользователей блокировать свои средства в мостовых контрактах. Такой выбор дизайна обеспечивает лучшую безопасность: если секвенсор, специфичный для приложения, выйдет из строя, потенциальный ущерб будет ограничен, поскольку секвенсор может контролировать транзакции только в границах, установленных смарт-контрактом. Хотя в некоторых решениях L2 реализованы функции безопасности - такие как аварийные люки и принудительное включение, - эти меры часто сложно использовать на практике. Пользователям может потребоваться несколько дней, прежде чем они смогут активировать аварийный люк после потери связи с обновлениями L2. Аналогично, принудительное включение через L1 обычно требует не менее суток задержки. Пожалуй, самое главное, что эти меры безопасности обычно требуют технических знаний, которыми большинство пользователей не обладают, что делает их непрактичными для обычного человека.
Сильное предположение о живучести - живучесть L2 зависит от узлов выполнения, которые обычно являются секвенсорами сворачивания, если только они не основаны на секвенсорах. Жизнеспособность L1 зависит от честного большинства узлов, повторно выполняющих соответствующие функции перехода состояний. Живучесть суверенного приложения в основном зависит от базовой среды выполнения, и смарт-контракты могут определять части, которые должны полагаться на секвенсоры, специфичные для приложения.
ASS предоставляет приложениям полный суверенитет над последовательностью транзакций, позволяя им определять пользовательские правила без сложностей управления выполнением. Такой суверенитет позволяет приложениям контролировать выполнение транзакций, чтобы оптимизировать результаты для своих пользователей. Например, в Angstrom LP и свопперы рассматриваются как первоклассные участники, а их экономическая выгода напрямую повышается благодаря пользовательским правилам последовательности.
Кроме того, ASS может использовать ряд криптоэкономических и криптографических инструментов для обеспечения оптимальности пользовательских выплат и реализации надежных механизмов защиты от цензуры. Криптоэкономические решения, такие как стакинг и слэш, стимулируют честное поведение секвенсоров, а криптографические методы, такие как TEE и MPC, повышают уровень конфиденциальности и безопасности. Благодаря этим инструментам потенциал разработки ASS огромен и позволяет создавать более безопасные, эффективные и ориентированные на пользователя суверенные приложения.
Несмотря на возможности, которые открывает ASS, все еще существуют такие проблемы, как отсутствие встроенной композитности. Однако такие решения, как предварительное подтверждение инклюзии, совместное использование ASS и обязательства строителей, представляют собой многообещающие способы преодоления этих препятствий. Несмотря на то что некоторые вопросы остаются нерешенными, мы стремимся усовершенствовать эти подходы, чтобы обеспечить более плавный и композитный опыт использования ASS.
Мы здесь, чтобы сделать DeFi более устойчивой, по одному ASS за раз.