Намір (Intents): Потенційні рішення проблеми складності DeFi

Перед крахом Luna я управляв стратегією доходу від стейблкоїнів для друга, який хотів пережити ті неймовірно високі процентні ставки січня 2020 року. Мій друг не дуже добре розбирається в криптовалютах, раніше він навіть ніколи не здійснював жодної транзакції в ланцюгу. Наша співпраця була дуже простою: він вкладав кошти в апаратний гаманець, ми зустрічалися через Zoom раз чи два на тиждень, і я поетапно пояснював йому, що робити.

Ми розподіляємо кошти на практично всі доступні протоколи Децентралізованих фінансів на різних блокчейнах. Протягом 2-4 годинної сесії ми здійснюємо десятки транзакцій, включаючи затвердження, перекази, обміни, депозити, отримання і зняття коштів. Кошти переводяться в кастомізовані торгові пари Uniswap LP, голосування Curve та інше, усі кошти розподіляються для отримання стимулів. Ми використали практично всі кросчейн мости, основні DEX та агрегатори прибутку для переміщення нашого портфеля стейблкоїнів. У світі криптовалют ми практично стикалися з усіма способами отримання прибутку.

Сказати, що я змусив його сліпо слідувати, трохи занадто м'яко.

Найскладніша частина моєї роботи – це спроба детально пояснити всі кроки, які нам потрібно здійснити. Я віддаю інструкції, він їх виконує, при цьому ще й намагається зрозуміти інтерфейси всіх цих складних інструментів Децентралізовані фінанси. Наші зустрічі наповнені такими інструкціями, як "натисніть тут", "перейдіть туди", "обміняйте це". Наприклад, щоб обміняти USDC на FRAX/DAI LP на Polygon:

1. Обміняти USDC на DAI( на певному DEX, затвердити + обміняти )
2. Перенос USDC та DAI на Polygon(4 транзакції, затвердження + перенесення )
3. Об'єднайте USDC та DAI(4 угоду на Polygon DEX, схвалення + мости)
4. Помістіть LP в сховище для отримання винагороди (2 схвалення транзакцій + міст )

Лише для цього простого руху коштів нам потрібно ініціювати 12 транзакцій! Ми повинні використовувати інформацію, надану специфічним інтерфейсом протоколу, щоб безпосередньо шукати, створювати та виконувати окремі транзакції в EVM. Цей процес є ручним, трудомістким і складним, особливо у випадку великих портфелів. Оглядаючись назад, ці завдання лише імітували кілька DApp для дохідного фермерства, але ручне виконання є дуже складним.

З більш високого рівня, всі процеси, які ми виконуємо, мають чітко визначені очікувані результати. У нас є активи, які ми хочемо використовувати для виконання завдань X, Y, Z. Як у наведеному вище прикладі, ми маємо USDC( на Ethereum ) і хочемо надати ліквідність у формі FRAX/DAI( на Polygon ), а потім внести їх до стейкінг-скарбнички. Це "зміст" нашої операції, а 12 транзакцій, які ми повинні виконати, є конкретним "способом дій". Від початку до кінця необхідна серія чітких, обґрунтованих кроків, і всі ці кроки є кількісними.

Потужний алгоритм, створений для обробки маршрутизації транзакцій, спростить цей процес до всього лише 1-2 кроків. Ми ділимося бажаним результатом, і алгоритм повертає нам найкращий шлях, можливо, навіть обробляє транзакцію. Ця структура картографування шляхів називається "наміром", і вона є частиною швидко розвиткує середнього програмного забезпечення Ethereum. Хоча у нас є широке уявлення про намір, ще не досягнуто консенсусу щодо визначення. Наразі існує кілька загальних ідей. Визначення одного дослідницького інституту звучить так: "Намір - це підписаний набір декларативних обмежень, що дозволяє користувачам делегувати створення транзакцій третім особам, не відмовляючись від повного контролю над контрагентом". Визначення іншого експерта звучить так: "Транзакція є обов'язковою, тоді як намір є декларативним. Іншими словами, транзакція - це чітко визначене повідомлення, що вказує, як виконати EVM для внесення змін у стан, тоді як намір вказує на бажані зміни стану, не зосереджуючи уваги на процесі реалізації."

У цих двох визначеннях намір є "декларативним", тобто він прагне отримати зовнішню допомогу через обмін даними між користувачем і "розв'язувачем". Користувачі заявляють про бажаний результат, а розв'язувач надає їм спосіб його досягнення. На відміну від операцій з конкретними параметрами, наміри повинні бути відображені третьою стороною. Крім того, існують обмеження, які можуть обмежити набір можливих шляхів. Це допомагає зосередити загальну кількість можливостей у меншу, фільтрувану групу, з якої користувачі можуть вибрати. Наприклад, у випадку з моїм другом, намір дозволяє нам транслювати фінальну мету групі розв'язувачів, а потім вони обчислюють найкращий шлях. Потім ми виберемо маршрут з найкращою ціною і виконаємо угоду. Усі проміжні кроки будуть оброблені маршрутом, наданим розв'язувачем, залишаючи 1-2 угоди, які потрібно підтвердити користувачу.

Базова архітектура, що ґрунтується на "намірі", вже побудована на EVM. Коли ви використовуєте будь-який DEX, він знайде найкращий маршрут для виконання угоди. У інтерфейсі Curve, після вибору активів для купівлі-продажу, інтерфейс автоматично знаходить найкращого LP для маршрутизації. Оскільки немає USDT/frxETH LP, замовлення проходить через кілька LP, щоб отримати найкращий шлях виконання: USDT > sUSD > sETH > ETH > frxETH, все завершено в одній угоді. Він також приблизно вказує на вплив на ціну, а також на заходи, які може вжити користувач, щоб обмежити сліпий рух. Як тільки вибрано правильні параметри, інтерфейс також може допомогти побудувати сирі дані EVM для трансляції.

Ця торговельна намір на Curve є лише дуже базовим прикладом. Інтерфейс є лише корисним інструментом для побудови обмінних угод за наступною логікою:

FRAX торгівля: використання 5bps FRAX/USDC Curve LP для обміну 100,000 FRAX на щонайменше 999,000 USDC, термін дії до X блоку. З іншого боку, намір поділитися очікуваним результатом ( отримати максимальну кількість USDC ) і обмеження ( лише продати 100,000 FRAX ). Визначити, яким є найкращий курс обміну, покликаний розв'язувач.

Якщо ви коли-небудь користувалися певними агрегаторами торгівлі, ви побачите систему намірів для побудови обмінних угод. Використовуючи ці платформи, ви все ще надаєте всі параметри виконання, а потім отримуєте набір потенційних посередників для виконання угоди. Усі потенційні обміни все ще працюють на певному DEX, з окремими винятками (, але в залежності від посередника угоди вони мають різні збори та витрати на газ. В кінцевому підсумку користувач вибирає найкращу ціну/вартість.

Окрім агрегаторів交易, на Ethereum також існує кілька інших типів "намірів":

1. Лімітне замовлення: якщо умови виконуються, дозволяє витягувати активи з рахунку.

2. Специфічні аукціони: виконання замовлень третьої сторони на основі неліквідності DEX.

3. Спонсорство газу: дозволяє використовувати токени, такі як FRAX, для виконання третіх сторін угод, що підходить для абстрактних гаманців.

4. Делегування: білий список відноситься до цього випадку, перевірка бази даних перед виконанням угоди.

5. Пакетна обробка транзакцій: дозволяє пакетну обробку намірів щодо ефективності Gas.

6. Крос-чейн обмін: див. деякі крос-чейн мости.

Хоча типи замовлень стають дедалі різноманітнішими, я бачив найпростіший спосіб описати намір як "лімітне замовлення", але з новою маркетинговою термінологією. Ліміте замовлення означає, що ви хочете купити певну кількість активу за певною ціною, і замовлення буде виконано лише після того, як інша сторона з'явиться і прийме його.

Як і з лімітними ордерами, намір складається з двох частин угоди. Перша частина – це очікуваний кінцевий стан користувача. Друга частина – це угода, ініційована розв'язувачем. Коли ви об'єднуєте обидві частини, ви врешті-решт отримуєте те, що потрібно для виконання угоди.

![Чому наміри (Intents) можуть бути відповіддю на проблему складності DeFi?])https://img-cdn.gateio.im/webp-social/moments-b3db327fe5a421e6947dd89721ee21de.webp(

Продаж MEV

Спосіб побудови на основі архітектури намірів майже не має ризику. По-перше, розв'язувач має мотив не поширювати MEV-намір, що містить те, з чого вони можуть отримати прибуток. "У багатьох випадках, для витягування MEV необхідно виконати замовлення користувача в ланцюзі. У таких випадках виконання замовлення користувача відкриває стан блокчейну, і витягувачі можуть скористатися цим станом для отримання прибутку. Зворотні та сендвіч-угоди є деякими з поширених прикладів."

Основною характеристикою наміру є виявлення даних. Підписуючи повідомлення про намір, ви вказуєте на готовність витягувати MEV за рахунок зручності. Оскільки намір не може бути безпосередньо транслітерований у пам'яті Ethereum, де транзакції ) ставляться в чергу перед виконанням (, вони заповнюються в приватному міжмережному Interpool. Ці Interpool можуть бути з дозволом, без дозволу або комбінацією обох.

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

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

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

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

![Чому інтенції (Intents) можуть бути відповіддю на проблему складності DeFi?])https://img-cdn.gateio.im/webp-social/moments-e236765e6a4558a5c6049dbdc8ddb341.webp(

Ризик проміжного програмного забезпечення

Коли ми розглядаємо намір як лімітне замовлення, ми можемо чітко порівняти його з потоком замовлень деяких традиційних фінансових компаній, сплачуючи )PFOF(.

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

Інтенція є формою арбітражу PFOF, яку ми називаємо MEV. Довгострокові відкриті ордери ) частини ордерів ( створюють арбітражні можливості, які можуть бути ціннішими, ніж ручне додавання до мемпулу Ethereum, оскільки розв'язувач може визначити маршрут, а не змагатися з трисандвічними угодами за MEV до або після угоди в даному блоці.

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

Деякі торгові протоколи використовують цей дизайн, який застосовує пакетні аукціони для знаходження найкращої ціни розрахунку для трейдерів. У цих протоколах замовлення не виконуються негайно, а збираються та розраховуються пакетно. Ця система не використовує центрального оператора, а натомість застосовує публічну конкуренцію розв'язувачів для узгодження замовлень. Як тільки пакет завершено, ці розв'язувачі подають рішення для розрахунку замовлень.

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

![Чому намір（