Від Solana до EVM: новий шлях для пропрієтарних AMM

Пропрієтарні AMM вже забезпечують 40% всього торгового обсягу на Solana. Чому їх немає на EVM?

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

https://dune.com/the_defi_report/prop-amms

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

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

Що таке Prop AMM?

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

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

Варто уточнити, що ліва частина формули цінової кривої Obric складніша за x * y, але головне — вона дорівнює інваріанту k, який маркет-мейкер змінює для коригування цінової кривої.

Нагадування: Як визначаються ціни в AMM?

Термін "цінова крива" буде часто згадуватися у цій статті, оскільки саме вона визначає ціну, яку користувач сплачує за трейд через AMM, і саме її оновлює маркет-мейкер у своєму Prop AMM. Перш ніж детальніше розглядати Prop AMM, корисно зрозуміти механізм ціноутворення в AMM. Наприклад, пул Uniswap v2 для WETH-USDC без комісій: ціна визначається формулою x * y = k, де x і y — кількості двох активів у пулі, а k — константа. Лише точки на цій кривій — це можливі ціни для трейду.

Наприклад, якщо в пулі WETH-USDC 100 WETH і 400 000 USDC, то x = 100 WETH, y = 400 000 USDC, початкова ціна — 400 000 USDC / 100 WETH = 4 000 USDC за WETH. Константний добуток k: xy = k = 40 000 000. Якщо трейдер купує 1 WETH, він додає USDC у пул, а баланс WETH зменшується до 99. Щоб зберегти k, нові x і y мають бути на кривій, тому баланс USDC має стати 40 000 000 / 99 ≈ 404 040,40 USDC. Трейдер сплачує 4 040,40 USDC за 1 WETH — це ефективна ціна, вища за початкову $4 000 через ціновий імпакт (slippage). Саме тому формула x y = k — це цінова крива: будь-яка ціна для цього пулу має бути точкою на кривій.

Чому маркет-мейкер обирає AMM, а не CLOB?

Чому маркет-мейкеру вигідно використовувати AMM? Уявіть, що ви працюєте на ончейн Central Limit Order Book (CLOB). Щоб оновити котирування, потрібно скасувати й замінити тисячі лімітних ордерів — це O(N) операція, що повільно й дорого, особливо ончейн.

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

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

https://github.com/tryghostxyz/solfi-sim/blob/main/static/curves_333436948.png

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

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

Prop AMM потребують активного керування, тобто дешевих оновлень і пріоритетного виконання. На Solana дешеві оновлення автоматично отримують пріоритет.

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

Друге — якщо оновлення не потрапляє на початок блоку, застарілі котирування забирають арбітражери, що веде до гарантованих втрат.

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

Наприклад, Prop AMM Solana, такі як HumidiFi, оновлюють котирування 74 рази на секунду (подяка @ SliceAnalytics), як видно нижче:

https://dune.com/queries/5980584/9644764

Для тих, хто знайомий із EVM, питання: "Як Prop AMM може оновити ціну кілька разів у одному слоті Solana (~400 мс)?"

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

• EVM: Транзакції виконуються послідовно, коли формується й фіналізується блок. Оновлення, надіслане в середині блоку, буде враховано лише в наступному блоці.
• Solana: Лідер-валідатор не чекає повного блоку, а розбиває транзакції на пакети ("shreds") й транслює їх у мережу безперервно. Може бути кілька свопів у слоті, але оновлення ціни в shred #1 впливає на swap #1, а в shred #2 — на swap #2.

Примітка: Flashblocks аналогічні shred'ам Solana. За словами @ Ashwinningg (Anza Labs, CBER), верхня межа — 32 000 shred'ів на 400 мс слот, тобто до 80 shred'ів на мс! Чи достатньо швидкі 200 мс Flashblocks для маркет-мейкерів порівняно з Solana — питання відкрите.

Чому оновлення на Solana такі дешеві й пріоритетні?

Хоча реалізація Prop AMM на Solana — "чорна скринька", є бібліотеки, як Pinocchio, для CU-оптимізації Solana-програм. У блозі Helius (тут) показано, як програми оптимізуються з ~4000 CU до ~100 CU.

https://github.com/febo/p-token?tab=readme-ov-file#compute-units

На високому рівні Solana пріоритизує транзакції за коефіцієнтом Fee / Computer Units (Compute Units — аналог Gas в EVM), подібно до EVM.

• З Jito: формула — Jito Tip / Compute Units,
• без Jito: Priority = (Prioritization fee + Base fee) / (1 + CU limit + Signature CUs + Write lock CUs) (https://solana.com/docs/core/fees)

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

Оновлення Prop AMM: просте оновлення кривої — 109 CU, загальна комісія — 0,000007506 SOL

https://orb.helius.dev/tx/325EwPasEyXYuVqow9aGT44i17cZzd9G5GYPHxJr1JmLKwyWTS6rJgV6EP1svqExo9TnoqqmMF15si17x2s7wnSu?cluster=mainnet-beta&advanced=true&tab=summary

Jupiter Swap: своп через Jupiter — понад ~100 000 CU, комісія — 0,000005 SOL.

https://orb.helius.dev/tx/4SbYyAEq6QBNv5YW517fLRatEPvBvh1kDit3C8NL84uBRXuE7FFEsVuX6BDG44reXtMt5WZCGxN7rS38jt4RSNY9?cluster=mainnet-beta&advanced=true&tab=summary)

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

Чому Prop AMM ще не працюють на EVM?

Оновлення Prop AMM — це запис змінних, які визначають криву ціни пари. Хоча код Prop AMM Solana — "чорна скринька", ми робимо це припущення на основі реалізації Prop AMM Obric на Sui, де змінні для котирувань записуються у смарт-контракт через функції оновлення.

https://suiscan.xyz/mainnet/object/0xb84e63d22ea4822a0a333c250e790f69bf5c2ef0c63f4e120e05a6415991368f/contracts

Подяка @ markoggwp!

Архітектура EVM створює серйозний бар’єр, що робить модель Prop AMM Solana непридатною для EVM.

На OP-Stack Layer 2, таких як Base і Unichain, транзакції впорядковуються за Priority Fee per Gas, аналогічно Fee / CU на Solana.

На EVM запис у сховище через SSTORE дуже дорогий порівняно з оновленням на Solana.

• SSTORE (з нуля до ненульового): ~22 100 gas
• SSTORE (з ненульового до ненульового): ~5 000 gas
• Своп на AMM: ~200 000 – 300 000 gas

Gas на EVM — аналог Compute Units на Solana.

Наведені значення — для одного запису на транзакцію (cold writes), що логічно, бо не варто надсилати більше одного оновлення за раз.

Оновлення дешевше за своп, але співвідношення gas — лише ~10x (оновлення може містити кілька SSTORE), порівняно з ~1000x на Solana.

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

1. Високе споживання gas означає, що невелика пріоритетна комісія не забезпечує високий Priority Fee / Gas. Для гарантії, що оновлення не буде фронтранене й буде на початку блоку, потрібна більша комісія, що дорожче.
2. Співвідношення між gas для оновлення й свопу на EVM — 1:10, а не 1:1000. Арбітражер може підвищити Priority Fee у 10 разів і перебити оновлення маркет-мейкера, на відміну від 1000x на Solana. У такому середовищі арбітражер легше фронтранить оновлення ціни, використовуючи застарілі котирування.

EIP-1153 (TSTORE) пропонує записи за 100 gas, але це ефемерне сховище — лише на одну транзакцію, не для збереження ціни для наступного свопу.

Як перенести Prop AMM на EVM?

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

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

• Оновлення Prop AMM на початку блоку Solana захищають маркет-мейкера від фронтранінгу, бо використовують мало Compute Units, і низька комісія дає високий Fee / CU.

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

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

Рішення — створити пріоритетний lane для оновлень Prop AMM.

Оригінальний підхід, запропонований @ MarkToda (Uniswap), — використання Global Storage смарт-контракту (репозиторій) у комбінації зі спеціальною політикою builder'а.

https://github.com/flashbots/global-storage-smart-contract

Як це працює:

• Global Storage Contract: простий смарт-контракт — публічне key-value сховище. Маркет-мейкери записують параметри цінової кривої (наприклад, set(ETH-USDC_CONCENTRATION, 4000)).

Builder Policy: offchain-компонент. Block builder'и впроваджують політику, що розпізнає транзакції на адресу Global Storage. Політика резервує перші 5–10% gas блоку для цих оновлень, впорядковуючи їх за пріоритетною комісією — для запобігання спаму.

Важливо, щоб транзакція адресувалась Global Storage, інакше не слід дозволяти їй бути на початку блоку.

• Приклад алгоритму побудови блоку з rblib:

• Інтеграція Prop AMM: смарт-контракт Prop AMM зчитує дані кривої з Global Storage під час свопу, визначаючи котирування для користувача.

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

• Захист: builder policy створює "швидку смугу", що гарантує виконання всіх оновлень цін у блоці до будь-яких свопів, усуваючи ризик фронтранінгу.
• Ефективність: маркет-мейкери конкурують лише з іншими оновленнями, а не з усіма DeFi-користувачами, що суттєво знижує витрати на пріоритетне виконання.

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

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

Висновок

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

Стандартна архітектура EVM робить це дорогим і ризикованим, але новий дизайн пропонує альтернативу. Поєднання ончейн Global Storage контракту з offchain builder policy створює виділену "швидку смугу" для оновлень цін. Модель гарантує виконання oracle-оновлень на початку блоку й формує локальний fee-ринок, вирішуючи основні бар’єри та відкриваючи можливості не лише для Prop AMM, а й для всіх типів DeFi на EVM, що залежать від oracle-оновлень на початку блоку.

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

• Чи достатньо швидкі Prop AMM на EVM із 200 мс Flashblock, щоб конкурувати з безперервною архітектурою Solana?
• На Solana більшість orderflow для AMM йде через одного агрегатора — Jupiter, який надає SDK для інтеграції AMM. На Layer 2 EVM orderflow розпорошений між кількома агрегаторами без публічного SDK. Чи є це проблемою для Prop AMM на EVM?
• Як реалізовано Prop AMM, що їхні оновлення на Solana використовують лише ~100 CU?
• Запропонована модель швидкої смуги має лише оновлення Prop AMM на початку блоку. Якщо Flashblock має лише 200 мс, може бути кілька свопів у одному Flashblock, і маркет-мейкер може захотіти оновити ціну між ними. Як це реалізувати?
• Чи можна використовувати Yul або Huff для оптимізації EVM-програм, аналогічно Pinocchio для Solana?
• Як Prop AMM порівнюються з RFQ?
• Як запобігти ситуації, коли маркет-мейкер дає гарне котирування на блоці N, щоб заманити користувача, а потім оновлює котирування на блоці N+1 на невигідне? Як Jupiter це запобігає?
• Jupiter Ultra V3 впроваджує "Ultra Signaling", що дозволяє Prop AMM розрізняти токсичний і нетоксичний потік, щоб давати котирування, що на 3 бпс кращі. Наскільки важливі такі функції для перенесення Prop AMM на EVM?

P.S: Я шукаю можливості для виступу на конференціях з цієї теми. Якщо ви маєте контакти щодо подій під час Devconnect, буду радий поспілкуватися про можливість виступу!

Відмова від відповідальності:

1. Ця стаття передрукована з [0xOptimus]. Всі авторські права належать оригінальному автору [0xOptimus]. Якщо у вас є заперечення щодо передруку, зверніться до команди Gate Learn, і вони оперативно розглянуть питання.
2. Відмова від відповідальності: думки й погляди, висловлені в цій статті, належать лише автору й не є інвестиційною порадою.
3. Переклади статті іншими мовами виконані командою Gate Learn. Якщо не зазначено інше, копіювання, розповсюдження чи плагіат перекладених статей заборонено.