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

Якщо транзакція явно вказує на те, як виконується певна поведінка, тоді намір відноситься до очікуваного результату такої поведінки.

Наприклад, якщо інструкції транзакції:

«Зробіть A, потім B, а потім сплатіть C, щоб отримати D».

Відповідним наміром було б:

«Я можу дозволити собі заплатити, і я хочу отримати D».

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

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

Як працює намір

Наразі стандартний метод взаємодії користувачів з Ethereum передбачає формулювання та підписання транзакцій і повідомлень у певному форматі, який надає EVM всю необхідну інформацію для виконання переходів між станами. Однак створення транзакцій може включати досить складні операції, які вимагають суттєвих заплутаних операцій, пов’язаних із смарт-контрактами та неуправлінським управлінням, утримуючи певні активи для сплати зборів за газ. Ці хитромудрості призводять до поганої взаємодії з користувачем і зниження ефективності, оскільки користувачам потрібно приймати рішення без достатньої інформації або залучення складних стратегій виконання.

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

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

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

Поточні застосування намірів

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

Лімітні замовлення: якщо користувач отримує принаймні 200 токенів B, він може зняти 100 токенів A зі свого рахунку.

Аукціон у стилі Cowswap: подібний до лімітованих замовлень, але покладається на треті сторони або механізми для підбору кількох замовлень для оптимізації якості виконання.

Спонсорство газу: користувачі можуть сплачувати комісії за трансакції в USDC замість ETH, а на рахунку є USDC для оплати зборів за газ.

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

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

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

Наразі інтент знайшов нові застосування в міжланцюжкових MEV (таких як SUAVE), абстракціях облікових записів ERC4337 і сценаріях замовлень у морських портах. У міру розвитку ERC4337 також ведеться дослідження інших нових програм, наприклад міждоменного наміру.

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

Посередники та Mempool

Найбільш очевидний спосіб отримати наміри в руки добровільних посередників – Ethereum Mempool. Однак поточний дизайн Mempool не підтримує поширення намірів. Довгострокові перспективи передбачають мінімальну ймовірність широкої підтримки наміру в Ethereum Mempool, враховуючи вразливість DOS-атак. Відкритий характер Ethereum Mempool без дозволу є перешкодою для прийняття наміру.

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

Як показано на малюнку вище, намір спочатку надходить від користувача до дозволеного/недозволеного, загальнодоступного/приватного пулу намірів, а потім перетворює його на транзакцію за допомогою підбірника і, нарешті, перетворює його на загальнодоступний Mempool або безпосередньо відображає на через аукціони MEV Boost.

Mempool без дозволу

Однією з проектів, що експериментують, є децентралізований API, який дозволяє різним вузлам у системі транслювати наміри через плітки, таким чином надаючи бездозвільний доступ виконавцям.

Наприклад, у ретрансляторах протоколу 0x трансляція пліток полегшується для лімітованих замовлень, надсилаючись у ланцюжок після виявлення збігів. Цей підхід також вивчається в контексті спільного ERC4337 Mempool для боротьби з ризиками централізації та цензури. Однак дизайн цього Intentpool без дозволу також стикається з деякими проблемами, зокрема:

Стійкість до DoS: розробникам, можливо, доведеться обмежити функціональність намірів, щоб уникнути потенційних атак DoS.

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

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

Дозволений Mempool

Надійні централізовані API більш стійкі до атак DOS і не потребують поширення намірів. Ця модель довіри дає певну основу для занепокоєння MEV. Поки виконується припущення про довіру, можна гарантувати якість виконання. Довірені посередники також можуть мати пов’язану з ними репутацію, що стимулює серйозне виконання.

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

Гібридні рішення

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

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

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

Ризики та стратегії пом'якшення

Хоча наміри є цікавою новою парадигмою для транзакцій, їх широке впровадження може означати прискорення більшої тенденції переходу активності користувачів на альтернативні мемпули. У разі неправильного управління цим переходом може зашкодити децентралізації Ethereum і призвести до надмірної влади довірених сторін. Потенційні ризики включають наступне:

Потік замовлень: якщо дозволено виконання наміру, але користувачі вибирають його недбало та переносять із загальнодоступного Mempool, виробництво блоків Ethereum може стати централізованим.

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

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

Отже, як зменшити ці ризики? Ми знаємо, що простір Ethereum Mempool обмежений. Для деяких програм ризики виникають через відсутність конфіденційності, що не дозволяє їм підтримувати більший діапазон форматів повідомлень. Це ставить розробників гаманців і додатків у складне становище, оскільки вони повинні знайти якийсь спосіб дозволити користувачам підключатися до блокчейну, уникаючи при цьому ризиків, згаданих вище. Ідеальна система має бути без дозволів, щоб будь-хто міг зіставляти та виконувати наміри, не жертвуючи надто високою якістю виконання. Система має бути універсальною, щоб можна було розгортати нові додатки без необхідності створення нових mempool-ів. Системи мають бути прозорими, дозволяючи публічно звітувати про процес виконання намірів і надавати дані для проведення перевірок якості, коли це дозволяють гарантії конфіденційності.

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

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

Висновок

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

Офіційний сайт Ebunker:https://www.ebunker.io

Щоб отримати більше обговорень, приєднуйтеся: https://t.me/ebunkerio

Ebunker Twitter: https://twitter.com/ebunker_eth

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

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