Почему Solana заполнена Prop AMM, а в EVM их до сих пор нет?

Оригинальное название статьи: Must-Watch dApps After Monad Mainnet Launch

Автор оригинальной статьи: @0xOptimus

Перевод оригинальной статьи: Dingdang, Odaily Planet Daily

Proprietary AMM быстро захватили 40% общего объема торгов в сети Solana. Почему они до сих пор не появились в EVM?

Proprietary Automated Market Makers (Prop AMM) быстро становятся доминирующей силой в DeFi экосистеме Solana, в настоящее время обеспечивая более 40% объема торгов по основным парам. Эти площадки ликвидности, управляемые профессиональными маркет-мейкерами, могут обеспечить глубокую ликвидность и более конкурентное ценообразование. Основная причина заключается в том, что они значительно снижают риск использования маркет-мейкеров для «устаревших котировок» с целью проведения арбитража с опережением (front-running).

Источник изображения: dune.com

Однако их успех был практически полностью ограничен Solana. Даже в быстрых и недорогих сетях Layer 2, таких как Base или Optimism, присутствие Prop AMM в экосистеме EVM встречается редко. Почему они не прижились в EVM?

В этой статье рассматриваются три основных вопроса: что такое Prop AMM, с какими техническими и экономическими барьерами они сталкиваются в цепочке EVM, и какие перспективные новые архитектуры могут в конечном итоге вывести их на передний план DeFi в EVM.

Что такое Prop AMM?

Proprietary AMM — это тип автоматизированного маркет-мейкера, где один профессиональный маркет-мейкер активно управляет ликвидностью и ценообразованием, а не просто предоставляет средства пассивно, как в традиционных AMM.

Традиционные AMM (например, Uniswap v2) обычно используют формулу x * y = k для определения цены, где x и y представляют количество двух активов в пуле, а k — константа. В Prop AMM формула ценообразования не является фиксированной, а часто обновляется (зачастую несколько раз в секунду). Поскольку внутренняя механика большинства Prop AMM считается «черным ящиком», внешний мир не знает точного алгоритма, который они используют. Однако код смарт контракта Prop AMM в сети Sui от Obric является публичным (благодаря открытию @markoggwp), где инвариант k зависит от внутренних переменных mult_x, mult_y и концентрации. На изображении ниже показано, как маркет-мейкер постоянно обновляет эти переменные.

Один момент, требующий уточнения: формула на левой стороне кривой ценообразования Obric сложнее, чем просто x*y. Однако ключ к пониманию Prop AMM заключается в том, что она всегда равна переменному инварианту k, и поставщики ликвидности постоянно обновляют этот k, чтобы корректировать ценовую кривую.

Обзор: Как AMM определяет цены?

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

Возьмем пример пула WETH-USDC на Uniswap v2 (предполагая отсутствие комиссий). Цена пассивно определяется формулой x * y = k. Предположим, что в пуле 100 WETH и 400 000 USDC, текущая точка кривой x = 100, y = 400 000, что соответствует начальной цене 400 000 / 100 = 4 000 USDC/WETH. Это дает константу k = 100 * 400 000 = 40 000 000.

Если трейдер хочет купить 1 WETH, ему нужно добавить USDC в пул, уменьшив количество WETH в пуле до 99. Чтобы сохранить постоянное произведение k, новая точка (x, y) должна по-прежнему лежать на кривой, поэтому y должен стать 40 000 000 / 99 ≈ 404 040,40. Это означает, что трейдер заплатил около 4 040,40 USDC за 1 WETH, что немного выше начальной цены. Это явление известно как «проскальзывание цены». Вот почему x*y=k называют «ценовой кривой»: любая торгуемая цена должна попадать на эту кривую.

Почему поставщики ликвидности выбирают дизайн AMM вместо централизованной книги ордеров (CLOB)?

Давайте объясним, почему поставщики ликвидности хотят использовать дизайн AMM для предоставления ликвидности. Представьте, что вы маркет-мейкер, выставляющий котировки в ончейн централизованной книге лимитных ордеров (CLOB). Если вы хотите обновить свою котировку, вам нужно будет отменить и заменить тысячи лимитных ордеров. Если у вас N ордеров, стоимость обновления — это операция O(N), которая является медленной и дорогой в блокчейне.

Но что, если бы вы могли представить все котировки с помощью математической кривой? Просто обновляя несколько ключевых параметров, определяющих эту кривую, вы можете превратить операцию O(N) в постоянную сложность O(1).

Чтобы визуально продемонстрировать, как «ценовая кривая» соответствует различным эффективным ценовым диапазонам, мы можем обратиться к SolFi, созданному Ellipsis Labs — Prop AMM на базе Solana. Хотя его конкретная ценовая кривая неизвестна и скрыта, Ghostlabs создал график, показывающий эффективную цену при обмене различного количества SOL на USDC в рамках определенного слота Solana (период времени блока). Каждая линия представляет собой отдельный пул WSOL/USDC, иллюстрируя, что могут сосуществовать несколько ценовых уровней. По мере того как поставщик ликвидности обновляет ценовую кривую, этот график эффективной цены также будет меняться между разными слотами.

Источник изображения: GitHub

Ключевой момент здесь заключается в том, что обновляя лишь несколько параметров ценовой кривой, поставщики ликвидности могут динамически изменять распределение эффективной цены в любое время, не изменяя каждый из N ордеров по отдельности. Это именно то, в чем заключается основное ценностное предложение Prop AMM — он позволяет поставщикам ликвидности предлагать динамическую и глубокую ликвидность с более высокой капитальной и вычислительной эффективностью.

Почему архитектура Solana идеально подходит для Prop AMM?

Prop AMM — это система с «активным управлением», что означает, что она требует двух ключевых условий:

1. Низкие затраты на обновление

2. Приоритетное исполнение

В Solana эти два аспекта переплетены: Низкая стоимость обновлений часто означает, что обновления могут иметь приоритетное исполнение.

Но почему поставщикам ликвидности нужны эти два пункта? Во-первых, они будут постоянно обновлять ценовую кривую на основе изменений инвентаря или колебаний индексных цен активов (например, цен на криптобиржах) со скоростью блокчейна. В высокочастотной сети, такой как Solana, если затраты на обновление слишком высоки, достижение высокочастотных корректировок было бы затруднительным.

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

Используя пример Prop AMM HumidiFi на Solana, согласно данным @SliceAnalytics, поставщик ликвидности обновляет свою котировку до 74 раз в секунду.

Игроки, приходящие из EVM, могут спросить: «Слот Solana составляет примерно 400 мс, как Prop AMM может обновлять цену несколько раз в течение одного слота?»

Ответ кроется в непрерывной архитектуре Solana, которая фундаментально отличается от дискретной модели блоков EVM.

· EVM: Транзакции обычно выполняются последовательно после того, как предложен и окончательно подтвержден полный блок. Это означает, что обновления, отправленные в середине, вступают в силу в следующем блоке.

· Solana: Узлы-валидаторы (Leader) не ждут полного блока; вместо этого они разбивают транзакции на небольшие пакеты данных (называемые «shreds») и непрерывно транслируют их в сеть. Внутри слота может быть несколько обменов, но обновление цены в shred #1 влияет на своп #1, а обновление цены в shred #2 влияет на своп #2.

Примечание: Flashblocks похожи на shreds в Solana. По словам @Ashwinningg из Anza Labs на конференции CBER, лимит слота в 32 000 shreds каждые 400 мс эквивалентен 80 shreds в миллисекунду. Являются ли Flashblocks по 200 мс достаточно быстрыми, чтобы соответствовать требованиям поставщиков ликвидности, остается открытым вопросом по сравнению с непрерывной архитектурой Solana.

Итак, почему обновления в Solana такие дешевые? И что приводит к их приоритетному исполнению?

Во-первых, хотя реализация Prop AMM в Solana — это черный ящик, существует библиотека, такая как Pinocchio, которая оптимизирует способ написания CU в программах Solana. Блог Helius дает замечательное объяснение. С этой библиотекой потребление CU программами Solana может быть сокращено с примерно 4000 CU до примерно 100 CU.

Источник изображения: github

Теперь давайте посмотрим на вторую часть. На более высоком уровне Solana приоритизирует транзакции, выбирая те, у которых самое высокое соотношение Fee / Compute Units (Compute Units похожи на Gas в EVM), аналогично EVM.

· В частности, если используется Jito, формула — Jito Tip / Compute Units

· В противном случае: Priority = (Tip + Base Fee) / (1 + CU Limit + Signature CU + Write Lock CU)

Сравнивая Compute Units обновления Prop AMM с Jupiter Swap, становится очевидно, что обновление чрезвычайно дешево, с соотношением 1:1000.

Обновление Prop AMM: Простое обновление кривой очень недорогое. Обновление Wintermute составляет всего 109 CU, при общей стоимости всего 0,000007506 SOL

Jupiter Swap: Своп через маршрут Jupiter может достигать ~100 000 CU, при общей стоимости 0,000005 SOL

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

Почему Prop AMM еще не появился в EVM?

Предположим, что обновление Prop AMM включает запись в переменную, которая определяет ценовую кривую пары активов. Хотя код Prop AMM в Solana — это «черный ящик», а поставщики ликвидности хотят сохранить конфиденциальность своих стратегий, мы можем использовать это предположение, чтобы понять, как Obric реализовал Prop AMM в Sui: переменная, определяющая цену пары активов, записывается в смарт контракт через функцию обновления.

Спасибо @markoggwp за это открытие!

С этим предположением мы обнаружили значительный барьер в архитектуре EVM, который делает модель Prop AMM Solana невыполнимой в EVM.

Напомним, что в блокчейнах Layer 2 на базе OP-Stack (таких как Base и Unichain) транзакции приоритизируются на основе комиссий за Gas (аналогично сортировке Fee/CU в Solana).

В EVM стоимость Gas для операций записи чрезвычайно высока. По сравнению с обновлениями в Solana, стоимость записи значения в EVM через опкод SSTORE ошеломляет:

· SSTORE (0 → non-0): ~22 100 gas

· SSTORE (non-0 → non-0): ~5 000 gas

· Типичный своп AMM: ~200 000–300 000 gas

Примечание: Gas в EVM похож на Computational Units (CU) в Solana. Приведенные выше цифры Gas для SSTORE предполагают, что каждая транзакция имеет только одну запись (холодная запись), что разумно, так как несколько обновлений обычно не отправляются в рамках одной транзакции.

Хотя обновления все еще дешевле, чем свопы, эффективность Gas составляет всего около 10x (обновления могут включать несколько SSTORE), тогда как в Solana это соотношение составляет около 1000x.

Это приводит к двум выводам, которые делают ту же модель Prop AMM Solana более рискованной в EVM:

1. Высокие затраты на Gas затрудняют обеспечение приоритета обновления: Более низкие комиссии за Gas не могут обеспечить высокое соотношение комиссии к Gas. Чтобы гарантировать, что обновления не будут опережены и будут помещены в начало блока, требуются более высокие комиссии за Gas, что увеличивает затраты.

2. Более высокий риск арбитража в EVM: Соотношение Gas обновления к Gas свопа в EVM составляет всего 1:10, тогда как в Solana — 1:1000. Это означает, что арбитражникам нужно увеличить комиссии всего в 10 раз, чтобы опередить обновление поставщика ликвидности, по сравнению с 1000 раз в Solana. В этом сценарии с более низким соотношением арбитражники с большей вероятностью будут опережать обновления цен, чтобы захватить устаревшие котировки из-за низкой стоимости.

Некоторые инновации (например, TSTORE в EIP-1153 для временного хранения) обеспечивают стоимость записи около 100 gas, но это хранилище является эфемерным, действительным только в рамках одной транзакции и не может быть использовано для сохранения обновлений цен для последующего использования в деривативной торговле (например, в течение всего периода блока).

Как внедрить Prop AMM в EVM?

Прежде чем отвечать, давайте разберемся, «зачем это делать»: Пользователи всегда хотят лучших торговых котировок, что означает больше выгоды за свои деньги. Prop AMM в Ethereum и Layer 2 могут предоставить пользователям конкурентные котировки, которые ранее были доступны только в Solana или на централизованных биржах.

Чтобы сделать Prop AMM осуществимым в EVM, давайте рассмотрим одну из причин его успеха в Solana:

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

Итак, как мы можем внедрить обновления Prop AMM в начале блока в блокчейн EVM Layer 2? Есть два подхода: либо снизить стоимость записи, либо создать приоритетный канал для обновлений Prop AMM.

Из-за проблемы роста состояния (state growth) EVM, подход со снижением стоимости записи менее жизнеспособен, так как дешевые SSTORE привели бы к атакам на раздувание состояния.

Мы предлагаем создать приоритетный канал для обновлений Prop AMM. Это жизнеспособное решение и фокус данной статьи.

@MarkToda из Uniswap предложил новый подход, использующий Смарт контракт глобального хранилища + Стратегию выделенного строителя блоков:

Вот как это работает:

· Контракт глобального хранилища: Разверните простой смарт контракт в качестве публичного хранилища «ключ-значение». Поставщики ликвидности записывают параметры ценовой кривой в этот контракт (например, set(ETH-USDC_CONCENTRATION, 4000)).

· Стратегия строителя: Это ключевой оффчейн компонент. Строитель блоков идентифицирует транзакции, отправленные в контракт глобального хранилища, выделяет 5–10% Gas блока на эти транзакции обновления, приоритизирует их по комиссии и сортирует, чтобы предотвратить спам-транзакции.

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

Примеры алгоритмов построения пользовательских блоков можно найти в rblib.

Интеграция Prop AMM: Контракт Prop AMM поставщиков ликвидности считывает данные ценовой кривой из контракта глобального хранилища во время свопов для предоставления котировок.

Эта архитектура умело решает две проблемы:

1. Защита: Стратегия строителя создает «быструю полосу», чтобы гарантировать, что все обновления цен в блоке выполняются перед транзакциями, устраняя риск опережения.

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

Транзакции пользователей будут выполняться на основе ценовой кривой, установленной поставщиком ликвидности в начале того же блока, обеспечивая свежесть и безопасность котировок. Эта модель воспроизводит среду обновлений с низкими затратами и высоким приоритетом в Solana внутри EVM, прокладывая путь для Prop AMM в EVM.

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

Заключение

Осуществимость Prop AMM зависит от решения основной экономической проблемы: дешевое и приоритетное исполнение для предотвращения опережения.

Хотя стандартная архитектура EVM делает такие операции дорогостоящими и рискованными, новые проекты предлагают различные подходы для решения этой проблемы. Комбинируя ончейн смарт контракты глобального хранилища и оффчейн стратегию строителя в новом дизайне, можно создать выделенную «быструю полосу», чтобы обеспечить исполнение обновлений в начале блока, одновременно создавая локальный, контролируемый рынок комиссий. Это не только делает Prop AMM жизнеспособным в EVM, но и может революционизировать весь DeFi в EVM, полагающийся на обновления оракулов в начале блока.

Открытые вопросы

· Достаточно ли скорости Flashblock в 200 мс для Prop AMM в EVM, чтобы конкурировать с непрерывной архитектурой Solana?

· В Solana большая часть трафика AMM поступает от одного агрегатора под названием Jupiter, который предоставляет SDK для легкой интеграции AMM. Однако в Layer 2 EVM трафик рассредоточен по нескольким агрегаторам без публичного SDK. Создает ли это проблему для Prop AMM?

· В Solana обновления Prop AMM потребляют всего около 100 CU. Каков механизм реализации, стоящий за этой эффективностью?

· Модель быстрого пути гарантирует обновления только в начале блока. Если внутри Flashblock есть несколько обменов, как поставщики ликвидности обновляют цены между этими обменами?

· Можно ли писать оптимизированные программы EVM, используя языки, такие как Yul или Huff, аналогично подходу оптимизации Pinocchio в Solana?

· Как Prop AMM сравнивается с RFQ?

· Как мы можем предотвратить ситуацию, когда поставщики ликвидности предлагают конкурентные котировки в блоке N, чтобы привлечь пользователей, а затем обновляют их до неконкурентных котировок в блоке N+1? Как Jupiter смягчает этот риск?

· Функция Ultra Signaling в Jupiter Ultra V3 позволяет Prop AMM различать вредоносный и доброкачественный трафик, предоставляя более узкие котировки. Насколько важны эти функции агрегатора для Prop AMM в EVM?

Ссылка на оригинальный пост