Чому на Solana повно Prop AMM, а на EVM все ще пусто?

Оригінальна назва: Обов'язкові до перегляду dApps після запуску основної мережі Monad

Оригінальний автор: Optimus

Оригінальне джерело:

Переклад: Mars Finance

Проп AMM швидко зайняли 40% всього обсягу торгівлі на Solana. Чому їх ще не з'явилися на EVM?

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

Проте їхній успіх майже повністю обмежений Solana. Навіть на таких швидких і низькозатратних мережах другого рівня, як 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 на ланцюзі Sui Obric є відкритим (дякуючи відкриттю @markoggwp), його інваріант k залежить від внутрішніх змінних mult_x, mult_y та concentration. На нижчевказаному малюнку показано, як маркетмейкери постійно оновлюють ці змінні.

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

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

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

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

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

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

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

Prop AMM є системою «активного управління», що означає, що вона потребує двох ключових умов:

1. Низькі витрати на оновлення (cheap updates)

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

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

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

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

Наприклад, на Solana, згідно з даними @SliceAnalytics, цей маркетмейкер оновлює ціни до 74 разів на секунду.

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

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

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

· Solana: Лідерські верифікаційні вузли не чекають на повний блок, а розділяють транзакції на маленькі пакети даних (які називаються «shred») і безперервно транслюють їх у мережу. У одному слоті може бути кілька обмінів, але shred #1 的价格更新影响 swap #1, shred #2 的价格更新影响 swap #2.

Примітка: Flashblocks подібні до shred в Solana. За словами @Ashwinningg з Anza Labs на конференції CBER, максимальна кількість shred за кожен слот тривалістю 400 мс становить 32 000 shred, що відповідає 80 shred за мілісекунду. Що стосується того, чи достатньо швидкі Flashblocks тривалістю 200 мс для задоволення потреб маркет-мейкерів, це все ще відкрите питання в порівнянні з безперервною архітектурою Solana.

Отже, чому оновлення на Solana настільки дешеві? І як це призводить до пріоритетного виконання?

По-перше, хоча реалізація Prop AMM на Solana є чорним ящиком, існує бібліотека, така як Pinocchio, яка дозволяє оптимізувати спосіб написання програм Solana з CU. Блог Helius має чудове введення в це, за допомогою цієї бібліотеки споживання CU програмами Solana можна знизити з приблизно 4000 CU до приблизно 100 CU.

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

· Конкретно, якщо використовувати Jito, формула буде Jito Tip / Compute Units

· Не використовувати: Пріоритет = ( пріоритетний збір + базовий збір ) / (1 + межа CU + підпис CU + записування блокування 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: змінні, що визначають报价 торгової пари, записуються в смарт-контракт за допомогою функції update.

Дякую @markoggwp за виявлення!

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

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

На EVM вартість газу для операцій запису дуже висока. У порівнянні з оновленнями Solana, вартість запису значення за допомогою коду операції SSTORE на EVM вражає:

· SSTORE（0 → не 0）：~22,100 газ

· SSTORE (не 0 → не 0): ~5,000 газ

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

Зверніть увагу: Gas на EVM подібний до обчислювальної одиниці (CU) на Solana. Наведене вище число газу SSTORE припускає, що кожна транзакція має лише одне записування (холодне записування), що є розумним, оскільки зазвичай не відправляються кілька оновлень в одній транзакції.

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

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

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

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

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

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

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

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

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

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

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

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

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

Його принцип роботи такий:

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

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

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

Приклад алгоритму побудови блоків за замовчуванням можна знайти в rblib.

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

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

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

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

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

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

Висновок

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

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

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

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

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

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

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

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

· Яке порівняння між Prop AMM та RFQ?

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

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