Чому на Solana так багато Prop AMM, але на EVM досі порожньо?

Оригінальна назва: Must-Watch dApps After Monad Mainnet Launch

Оригінальний автор: Optimus, засновник Waterloo Blockchain

Переклад: Діндан, Odaily

Prop AMMs вже швидко займають 40% всього обсягу торгів на Solana. Чому вони досі не з’явилися в EVM?

Професійні автоматизовані маркет-мейкери (Proprietary AMMs, скорочено Prop AMMs) швидко стають домінуючою силою в DeFi-екосистемі Solana, наразі вони забезпечують понад 40% обсягу торгів по основних торгових парах. Такі спеціалізовані платформи ліквідності, керовані професійними маркет-мейкерами, можуть забезпечувати глибоку ліквідність і більш конкурентне ціноутворення, головна причина чого — значне зниження ризику арбітражу через «застарілі котирування» (stale quotes) та фронт-ранінг.

Джерело зображення: dune.com

Проте їхній успіх майже повністю обмежується Solana. Навіть на таких швидких і дешевих Layer 2 мережах, як Base чи Optimism, у EVM-екосистемі Prop AMM зустрічаються рідко. Чому вони не прижилися на EVM?

У цій статті розглядаються три питання: що таке Prop AMM, з якими технічними та економічними бар’єрами вони стикаються на EVM-ланцюгах, а також які перспективні нові архітектури можуть вивести їх на передній план EVM DeFi.

Що таке Prop AMM?

Prop AMM — це автоматизований маркет-мейкер, у якому ліквідність і ціноутворення активно керуються одним професійним маркет-мейкером, а не пасивно надаються широкою аудиторією, як у традиційних AMM.

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

Варто уточнити: формула ліворуч від цінової кривої Obric складніша за просту x*y, але ключ до розуміння Prop AMM — вона завжди дорівнює змінному інваріанту 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. Тобто трейдер заплатив за 1 WETH приблизно 4,040.40 USDC, що трохи вище за початкову ціну. Це явище називається «ковзанням ціни» (slippage). Саме тому x*y=k називають «ціновою кривою»: будь-яка торгова ціна повинна лежати на цій кривій.

Чому маркет-мейкери обирають AMM, а не централізовану книгу ордерів (CLOB)?

Пояснимо, чому маркет-мейкери хочуть використовувати AMM для маркет-мейкінгу. Уявіть, що ви маркет-мейкер, який виставляє котирування на централізованій лімітній книзі ордерів (CLOB) на блокчейні. Щоб оновити свої котирування, вам потрібно скасувати й замінити тисячі ордерів. Якщо у вас N ордерів, оновлення — це операція рівня O(N), що на блокчейні повільно й дорого.

А якщо всі котирування можна виразити однією математичною кривою? Тоді потрібно оновити лише кілька параметрів цієї кривої, перетворюючи O(N) на O(1) — сталу складність.

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

Джерело зображення: github

Ключовий момент тут: оновлюючи лише кілька параметрів цінової кривої, маркет-мейкер може в будь-який момент змінити розподіл ефективних цін, не змінюючи кожен із N ордерів окремо. Це і є основна цінність Prop AMM — вони дозволяють маркет-мейкерам забезпечувати динамічну й глибоку ліквідність із вищою капітальною та обчислювальною ефективністю.

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

Prop AMM — це «активно керована» система, тобто їй потрібні дві ключові умови:

1. Дешеві оновлення (cheap updates)

2. Пріоритетне виконання (priority execution)

На Solana ці дві умови взаємопов’язані: дешеві оновлення зазвичай означають, що оновлення отримують пріоритет виконання.

Чому маркет-мейкерам це потрібно? По-перше, вони постійно оновлюють цінову криву відповідно до змін інвентарю або індексної ціни активу (наприклад, ціни на централізованій біржі) з частотою, що відповідає швидкості блокчейну. На високочастотних ланцюгах, як Solana, якщо оновлення дорогі, реалізувати часті зміни неможливо.

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

Наприклад, Prop AMM HumidiFi на Solana, за даними @SliceAnalytics, оновлює котирування до 74 разів на секунду.

Користувачі EVM можуть запитати: «Slot Solana триває близько 400 мс, як Prop AMM може кілька разів оновити ціну в одному slot?»

Відповідь — у безперервній архітектурі Solana, яка принципово відрізняється від дискретної блочної моделі EVM.

· EVM: Транзакції виконуються послідовно після пропозиції й фіналізації цілого блоку. Оновлення, надіслані в середині блоку, набирають чинності лише в наступному блоці.

· Solana: Лідер-валідатор не чекає на цілий блок, а розбиває транзакції на невеликі пакети даних («shred») і безперервно транслює їх у мережу. В одному slot може бути кілька обмінів, але оновлення ціни в shred #1 впливає на swap #1, а в shred #2 — на swap #2.

Примітка: Flashblocks схожі на shred Solana. За словами @Ashwinningg з Anza Labs на конференції CBER, ліміт — 32,000 shred на slot (400 мс), тобто 80 shred на мілісекунду. Чи вистачає 200 мс Flashblocks для маркет-мейкерів у порівнянні з безперервною архітектурою 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

· Без Jito: Priority = (пріоритетна комісія + базова комісія) / (1 + ліміт CU + підпис CU + write-lock CU)

Порівняння Compute Units для оновлення Prop AMM і Jupiter Swap показує, що оновлення надзвичайно дешеві — співвідношення 1:1000.

Оновлення Prop AMM: Просте оновлення кривої дуже дешеве. Оновлення Wintermute — лише 109 CU, загальна комісія — 0.000007506 SOL

Jupiter Swap: Swap через Jupiter може досягати ~100,000 CU, загальна комісія — 0.000005 SOL

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

Чому Prop AMM досі не реалізовані на EVM?

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

Дякуємо @markoggwp за знахідку!

Виходячи з цього, архітектура EVM має серйозні обмеження, які роблять модель Prop AMM Solana непридатною для EVM.

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

У EVM запис (write) дуже дорогий за Gas. Порівняно з оновленням на Solana, запис одного значення через SSTORE у EVM коштує надзвичайно дорого:

· SSTORE (0 → не 0): ~22,100 gas

· SSTORE (не 0 → не 0): ~5,000 gas

· Типовий AMM swap: ~200,000–300,000 gas

Примітка: Gas у EVM — аналог Compute Units у Solana. Наведені значення SSTORE — для одного запису (cold write), що логічно, оскільки зазвичай не надсилають кілька оновлень за одну транзакцію.

Хоча оновлення все ще дешевші за swap, співвідношення gas — лише близько 10 разів (оновлення може містити кілька SSTORE), тоді як на Solana це співвідношення — близько 1000 разів.

Це призводить до двох висновків, які роблять модель Prop AMM Solana ризикованішою на EVM:

1. Високе споживання Gas ускладнює забезпечення пріоритету оновлення, низька пріоритетна комісія не забезпечує високого співвідношення комісія/Gas. Щоб гарантувати, що оновлення не буде випереджене й опиниться на початку блоку, потрібна вища комісія, що підвищує витрати.

2. Вищий ризик арбітражу на EVM, співвідношення Gas для оновлення й swap на EVM — лише 1:10, тоді як на Solana — 1:1000. Це означає, що арбітражеру достатньо підвищити пріоритетну комісію в 10 разів, щоб випередити оновлення маркет-мейкера, тоді як на Solana потрібно підвищити її в 1000 разів. За такого низького співвідношення арбітражери частіше випереджатимуть оновлення ціни для використання застарілих котирувань, оскільки це дешево.

Деякі інновації (наприклад, EIP-1153 TSTORE для тимчасового зберігання) дозволяють записувати за ~100 gas, але таке зберігання короткочасне й діє лише в межах однієї транзакції, тому не підходить для збереження оновлень ціни для наступних swap (наприклад, протягом цілого блоку).

Як впровадити Prop AMM у EVM?

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

Щоб зробити Prop AMM життєздатними на EVM, згадаємо одну з причин їхнього успіху на Solana:

· Захист оновлень на початку блоку: На Solana оновлення Prop AMM розміщуються на початку блоку, що захищає маркет-мейкерів від фронт-ранінгу. Оновлення опиняються на початку завдяки надзвичайно низькому споживанню Compute Units, навіть за низької комісії, що забезпечує високе співвідношення комісія/CU, особливо порівняно зі swap.

Як впровадити оновлення Prop AMM на початку блоку в Layer 2 EVM? Є два шляхи: або знизити вартість запису, або створити пріоритетний канал для оновлень Prop AMM.

Через проблему зростання стану EVM зниження вартості запису малоймовірне, оскільки дешевий SSTORE призведе до атак на стан.

Ми пропонуємо створити пріоритетний канал для оновлень Prop AMM. Це реалістичний підхід і основна ідея цієї статті.

Команда Uniswap (@MarkToda) запропонувала новий метод — глобальний смарт-контракт сховища + спеціальна стратегія блок-білдера:

Як це працює:

· Глобальний контракт сховища: Розгортається простий смарт-контракт як публічне key-value сховище. Маркет-мейкер записує параметри цінової кривої в цей контракт (наприклад, set(ETH-USDC_CONCENTRATION, 4000)).

· Стратегія білдера: Це ключовий off-chain компонент. Блок-білдер розпізнає транзакції, надіслані в глобальний контракт сховища, виділяє перші 5–10% Gas блоку для цих оновлень і сортує їх за комісією, щоб уникнути спаму.

Зверніть увагу: транзакції мають бути надіслані безпосередньо на адресу глобального сховища, інакше немає гарантії їхнього розміщення на початку блоку.

Приклад кастомного алгоритму білдингу блоку — rblib.

Інтеграція Prop AMM: Контракт Prop AMM маркет-мейкера під час swap зчитує дані цінової кривої з глобального контракту сховища для формування котирування.

Ця архітектура елегантно вирішує дві проблеми:

1. Захист: Стратегія білдера створює «швидкий канал», гарантуючи виконання всіх оновлень цін на початку блоку, усуваючи ризик фронт-ранінгу.

2. Економічна ефективність: Маркет-мейкерам більше не потрібно конкурувати з усіма DeFi-користувачами за високу ціну Gas для потрапляння на початок блоку — достатньо конкурувати лише в локальному ринку комісій для оновлень, що значно знижує витрати.

Транзакції користувачів виконуватимуться за ціновою кривою, встановленою маркет-мейкером на початку цього ж блоку, що гарантує актуальність і безпеку котирувань. Така модель відтворює на EVM середовище дешевих і пріоритетних оновлень, як на Solana, і відкриває шлях для Prop AMM у EVM.

Однак ця модель має і певні недоліки, які я залишаю для обговорення наприкінці статті.

Висновок

Життєздатність Prop AMM залежить від вирішення ключової економічної проблеми: дешеві й пріоритетні оновлення для запобігання фронт-ранінгу.

Хоча стандартна архітектура EVM робить такі операції дорогими й ризикованими, нові підходи пропонують різні способи вирішення цієї проблеми. Поєднання глобального смарт-контракту сховища на ланцюгу та стратегії білдера поза ланцюгом дозволяє створити спеціальний «швидкий канал», що гарантує виконання оновлень на початку блоку й формує локальний, контрольований ринок комісій. Це не лише робить Prop AMM можливими на EVM, а й може змінити всі EVM DeFi, які залежать від оновлень ораклів на початку блоку.

Відкриті питання

· Чи достатньо швидкості 200 мс Flashblock для Prop AMM на EVM, щоб конкурувати з безперервною архітектурою Solana?

· На Solana більшість обсягу AMM проходить через єдиний агрегатор Jupiter, який надає SDK для інтеграції AMM. Але на Layer 2 EVM обсяг розподілений між багатьма агрегаторами й немає загального SDK — чи стане це викликом для Prop AMM?

· Оновлення Prop AMM на Solana споживає лише близько 100 CU — як це реалізовано?

· Модель швидкого каналу гарантує лише оновлення на початку блоку. Якщо в одному Flashblock кілька swap, як маркет-мейкер може оновити ціну між цими swap?

· Чи можна написати оптимізовану програму EVM мовами Yul або Huff, подібно до оптимізації Pinocchio на Solana?

· Як Prop AMM порівнюється з RFQ?

· Як запобігти ситуації, коли маркет-мейкер у блоці N дає гарне котирування для залучення користувачів, а в блоці N+1 оновлює його на гірше? Як це вирішує Jupiter?

· Функція Ultra Signaling у Jupiter Ultra V3 дозволяє Prop AMM розрізняти шкідливий і нешкідливий трафік і надавати більш вузькі котирування. Наскільки важливі такі функції агрегатора для Prop AMM на EVM?

Оригінал