Автор: Павел Парамонов Источник: X, @paramonoww Перевод: Шан Оуба, Golden Finance
Многие считают, что "ASS - это все, что вам нужно", считая его полным решением, почти не требующим улучшений. Однако ASS не может решить все проблемы, и он также имеет некоторые предположения о доверии.
1. Самопроизвольная dApp - это часть Блок построителя
Когда пакет транзакций входит в Блок, dApp имеет право извлекать свою MEV (максимально извлекаемую стоимость) из него, получая свою собственную ценность от других «членов» Блокчейна поставок MEV, таких как предложители, искатели и строители. Однако этот концепт не является идеальным (ничто в мире шифрования не идеально), и он также может иметь некоторые доверительные предположения.
2. Игра с открытым миром
Одной из сложностей, с которой сталкиваются dApp, работающие на принципе самосинтеза, является то, что чем выше связанная с ними стоимость, тем больше требований они предъявляют к Блоку, чтобы убедиться, что в него включены. Если транзакции, содержащие MEV, не включены в Блок, то они могут стать абсолютно неприбыльными. Это наносит ущерб не только другим транзакциям, которые не могут генерировать MEV, но и пользователям.
Это интересная сцена для размышлений:
dApp имеет способность захватывать всю MEV, созданную им
Но если мы не только упускаем возможность получить выгоду от MEV, но и рискуем потерять пользователей, которые могут принести ценность платформе (например, если AMM продолжает терпеть неудачи, кто еще будет ее использовать), тогда такие действия лишены смысла.
Самое интересное заключается в том, что предложивший также должен получать прибыль, что создает ситуацию двойного проигрыша:
Децентрализованные приложения (dApp), которые не учитывают упаковку в блок, теряют MEV
Предложивший потерял MEV из-за невозможности разблокировки и пересортировки связанных атомов (хотя они могли бы выбрать другие сделки)
3.ASS dApp не должен наносить вред обычным пользователям и поставщикам ликвидности (LP) путем извлечения MEV
Как известно, MEV в основном генерируется и извлекается через токсичный трафик. LP теряют большую часть дохода, получаемого от неинформированного трафика, из-за MEV. Привлечение Ликвидность на платформу является одной из самых сложных задач в области шифрования, а AMM должны следовать справедливому распределению MEV для LP, что может помочь снизить Непостоянные потери.
В современной реальности активное управление позициями LP (даже несколькими LP-позициями) может рассматриваться как полноценная работа. Если произошло атака типа сэндвич, то ценность должна быть возвращена трейдеру; если произошел Арбитраж между централизованной биржей и DEX, то ценность должна быть возвращена LP. Таким образом, вопрос заключается в том, сколько вознаграждения они должны получить, а сколько ценности должно быть сохранено dApp?
4. Что делать, если размер пакета конфликтует с размером Блока базовой цепи?
Очевидно, не все dApp будут автоматически сериализованы (по крайней мере, в ближайшем будущем). Размер блока (или пакета транзакций) ограничен; без ограничений нет блокчейна или «блокчейна». Предположим, что блок может вместить не более 100 транзакций, могут возникнуть следующие ситуации:
dApp отправил связку из 100 транзакций, заполнившую весь блок. Для других «участников» Блокчейн поставок MEV, включение, предложение блока и его выполнение приносят какую прибыль?
DApp отправил связку с 99 транзакциями, осталось 1 место. Есть ли достаточный стимул у инициатора, чтобы включить эту связку? (Если они не сотрудничают, например, с предварительным подтверждением)
Две dApp отправили связанные транзакции. Первый пакет содержит 60 транзакций, второй - 50 транзакций. Очевидно, что может быть только один связанный пакет.
Важно отметить, что первая связанная сделка MEV даёт больше, чем вторая, но с другой стороны, включение второй связанной сделки более выгодно, поскольку 50 транзакций других несериализуемых dApp, объединенных в одну Блок, могут создать большую ценность.
Так кто должен быть включен? Кто в Блоке наиболее выгоден, а не просто связан внутри?
Возможное решение - FCFS (первым пришел, первым получил), но оно не гарантирует точности, потому что задержка все еще существует.
Как гарантировать, что сериализация выгодна для всех, а не только для одного участника, в то время как другие участники (LP, пользователи) лишаются ценности?
Потенциальным решением является установка конкретных правил сериализации, и только следуя этим правилам, можно иметь право на упорядочивание пакетов. Это очень важно, потому что неправильная сериализация может привести к уязвимостям.
Для торговых пар AMM использование жадной проверки правил может предотвратить фронтраннинг сделок в конкретном пуле AMM. Однако большинство сделок на DEX являются многосторонними обменами, поэтому требуются другие методы обеспечения защиты от MEV.
Еще ранний этап!
В настоящее время существует несколько способов автоматической сериализации, и я вдохновлен методом @SorellaLabs по этой теме. Мы все еще находимся в ранней стадии реализации автоматической сериализации (или ASS, как упоминал @ballsyalchemist), и различные инфраструктуры имеют свои особенности.
Цель ASS заключается в том, чтобы дать ответственность за сериализацию dApp, а не беспокоиться о выполнении (которое обрабатывается цепочкой). Хотя ASS на L1 относительно ясный, он более привлекателен на L2, так как требуется только один сериализатор, и L2 может добавить больше возможностей, реализуя локальные правила сериализации.
рост пространства огроменz！（Блок пространство исключено）
Содержание носит исключительно справочный характер и не является предложением или офертой. Консультации по инвестициям, налогообложению или юридическим вопросам не предоставляются. Более подробную информацию о рисках см. в разделе «Дисклеймер».
Действительно ли специфическая сортировка может решить все проблемы?
Автор: Павел Парамонов Источник: X, @paramonoww Перевод: Шан Оуба, Golden Finance
Многие считают, что "ASS - это все, что вам нужно", считая его полным решением, почти не требующим улучшений. Однако ASS не может решить все проблемы, и он также имеет некоторые предположения о доверии.
1. Самопроизвольная dApp - это часть Блок построителя
Когда пакет транзакций входит в Блок, dApp имеет право извлекать свою MEV (максимально извлекаемую стоимость) из него, получая свою собственную ценность от других «членов» Блокчейна поставок MEV, таких как предложители, искатели и строители. Однако этот концепт не является идеальным (ничто в мире шифрования не идеально), и он также может иметь некоторые доверительные предположения.
2. Игра с открытым миром
Одной из сложностей, с которой сталкиваются dApp, работающие на принципе самосинтеза, является то, что чем выше связанная с ними стоимость, тем больше требований они предъявляют к Блоку, чтобы убедиться, что в него включены. Если транзакции, содержащие MEV, не включены в Блок, то они могут стать абсолютно неприбыльными. Это наносит ущерб не только другим транзакциям, которые не могут генерировать MEV, но и пользователям.
Это интересная сцена для размышлений:
Самое интересное заключается в том, что предложивший также должен получать прибыль, что создает ситуацию двойного проигрыша:
3.ASS dApp не должен наносить вред обычным пользователям и поставщикам ликвидности (LP) путем извлечения MEV
Как известно, MEV в основном генерируется и извлекается через токсичный трафик. LP теряют большую часть дохода, получаемого от неинформированного трафика, из-за MEV. Привлечение Ликвидность на платформу является одной из самых сложных задач в области шифрования, а AMM должны следовать справедливому распределению MEV для LP, что может помочь снизить Непостоянные потери.
В современной реальности активное управление позициями LP (даже несколькими LP-позициями) может рассматриваться как полноценная работа. Если произошло атака типа сэндвич, то ценность должна быть возвращена трейдеру; если произошел Арбитраж между централизованной биржей и DEX, то ценность должна быть возвращена LP. Таким образом, вопрос заключается в том, сколько вознаграждения они должны получить, а сколько ценности должно быть сохранено dApp?
4. Что делать, если размер пакета конфликтует с размером Блока базовой цепи?
Очевидно, не все dApp будут автоматически сериализованы (по крайней мере, в ближайшем будущем). Размер блока (или пакета транзакций) ограничен; без ограничений нет блокчейна или «блокчейна». Предположим, что блок может вместить не более 100 транзакций, могут возникнуть следующие ситуации:
Важно отметить, что первая связанная сделка MEV даёт больше, чем вторая, но с другой стороны, включение второй связанной сделки более выгодно, поскольку 50 транзакций других несериализуемых dApp, объединенных в одну Блок, могут создать большую ценность.
Так кто должен быть включен? Кто в Блоке наиболее выгоден, а не просто связан внутри?
Возможное решение - FCFS (первым пришел, первым получил), но оно не гарантирует точности, потому что задержка все еще существует.
Как гарантировать, что сериализация выгодна для всех, а не только для одного участника, в то время как другие участники (LP, пользователи) лишаются ценности?
Потенциальным решением является установка конкретных правил сериализации, и только следуя этим правилам, можно иметь право на упорядочивание пакетов. Это очень важно, потому что неправильная сериализация может привести к уязвимостям.
Для торговых пар AMM использование жадной проверки правил может предотвратить фронтраннинг сделок в конкретном пуле AMM. Однако большинство сделок на DEX являются многосторонними обменами, поэтому требуются другие методы обеспечения защиты от MEV.
Еще ранний этап!
В настоящее время существует несколько способов автоматической сериализации, и я вдохновлен методом @SorellaLabs по этой теме. Мы все еще находимся в ранней стадии реализации автоматической сериализации (или ASS, как упоминал @ballsyalchemist), и различные инфраструктуры имеют свои особенности.
Цель ASS заключается в том, чтобы дать ответственность за сериализацию dApp, а не беспокоиться о выполнении (которое обрабатывается цепочкой). Хотя ASS на L1 относительно ясный, он более привлекателен на L2, так как требуется только один сериализатор, и L2 может добавить больше возможностей, реализуя локальные правила сериализации.
рост пространства огроменz！（Блок пространство исключено）