Парадигма: архітектура, заснована на намірах, і її ризики

Автор: Квінтус Кілборн, Георгіос Константопулос. Упорядник: Кейт, Марсбіт

представити

Дискусії навколо «намірів» та їх застосування нещодавно стали гарячою темою в спільноті Ethereum.

Якщо транзакції прямо вказують на те, «як» має бути виконана дія, намір вказує на те, яким має бути очікуваний результат цієї дії. Якщо зміст транзакції такий: «Спочатку зробіть A, потім B, заплатите C, щоб отримати X», тоді намір такий: «Я хочу X, і я готовий заплатити C».

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

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

Що таке намір?

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

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

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

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

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

минуле і майбутнє - це наміри

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

Ви можете помітити, що багато з цих ідей відповідають системам, які працюють багато років:

• Лімітне замовлення: 100X може бути списано з мого рахунку, якщо я отримаю принаймні 200Y.
• Аукціони в стилі CowSwap: те саме, що й вище, але покладайтеся на третю сторону чи механізм, щоб узгодити багато замовлень, щоб максимізувати якість виконання.
• Спонсорство газу: оплачуйте газ USDC замість ETH. Цей намір може бути виконано лише за допомогою відповідного наміру, який сплачує комісію ETH.
• Авторизація: дозволяйте взаємодію лише з певними обліковими записами певними попередньо авторизованими способами. Намір може бути виконано, лише якщо кінцева транзакція підпорядковується списку контролю доступу, зазначеному в намірі.
• Групування транзакцій: дозволяє групувати наміри для підвищення ефективності та зменшення плати за газ.
• Агрегатори: працюють, використовуючи лише «найкращу» ціну/прибуток. Цього наміру можна досягти, довівши, що виконується агрегація кількох місць і обрано найкращий шлях.

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

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

Посередник і його mempool

Найбільш очевидним каналом є мемпул Ethereum. На жаль, поточний дизайн не підтримує поширення намірів. Занепокоєння щодо DoS-атак може означати, що загальна підтримка повністю загального наміру в мемпулі Ethereum неможлива, навіть у довгостроковій перспективі. Як ми побачимо нижче, відкритий і бездозвільний характер мемпулу Ethereum є додатковою перешкодою для намірів впровадження.

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

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

Неліцензований пул пам'яті

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

• Стійкість до DoS: може знадобитися обмежити функціональність намірів, щоб уникнути векторів атак (див. пропозицію ER C4337 для подальшого обговорення)
• Поширення стимулів: для багатьох додатків реалізація намірів є прибутковою діяльністю. Таким чином, вузли, які керують пулом намірів, мають стимул не поширювати наміри, щоб зменшити суперечність під час виконання намірів.
• MEV: Наміри залежать від належної поведінки учасників поза ланцюгом для покращення якості виконання, що може бути складно при використанні загальнодоступних пулів намірів без дозволу. Якщо погане виконання є прибутковим, пули намірів без дозволу, ймовірно, призведуть до такого результату. Це схоже на сьогоднішні mempool Ethereum і, як очікується, стане загальною проблемою, пов’язаною з DeFi. Можливим шляхом тут можуть бути зашифровані пули намірів без дозволу.

Дозволені "пули пам'яті"

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

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

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

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

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

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

Де я можу помилитися?

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

Потік замовлення

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

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

Переважна більшість виробництва блоків в Ethereum наразі відбувається через MEV-Boost, позапротокольну реалізацію розділення пропозицій і конструкторів (PBS), і поточна дорожня карта не вказує на те, що цей інтерфейс скоро зміниться. PBS покладається на існування конкурентного ринку для розробників блоків, щоб направляти MEV до набору валідатора. Основна проблема з PBS полягає в тому, що розробники блоків отримують ексклюзивний доступ до сировини, необхідної для виробництва цінних блоків — транзакцій і намірів, також відомого як «потік замовлень». На мові PBS дозволений доступ до намірів відомий як ексклюзивний потік замовлень (EOF). Як обговорювалося в цьому документі, EOF в руках не тієї сторони загрожує ринковій структурі, на яку покладається PBS, оскільки ексклюзивність потоку замовлень передбачає боротьбу з конкурентними силами.

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

довіра

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

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

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

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

Формат намірів EIP4337 надає ще один приклад можливого механізму. Розглянемо світ, де надійні архітектури підтримують 4337 намірів. Якби був запропонований інший формат намірів, він міг би служити іншим варіантам використання, як-от функціональність перехресного походження, але відомі довірені посередники не приймають цей новий формат (зрештою, він не отримує широкого застосування та конкурує з їхньою бізнес-моделлю), реалізації нового формату потрібно буде встановити довіру до нової організації. Знову ми опиняємося в ситуації, коли інновації та виклик статус-кво стикаються з бар’єрами для входу, заснованого на довірі.

Непрозорість

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

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

Ситуації, коли MEV негативно впливає на виконання користувачами, часто пов’язані з тим, що транзакції надають високий ступінь свободи своїм виконавцям (наприклад, ліміти прослизання). Тож не є великим стрибком у логіці стверджувати, що додатки на основі намірів, які відмовляються від більшого ступеня свободи, повинні ретельніше проектувати свої системи для виконання. Найгіршим результатом у цьому відношенні є те, що використання програми на основі намірів вимагає підписання зникаючого наміру (у темний ліс, якщо хочете), який потім якимось чином реалізується як транзакція, незрозуміло, як і ким Створено. Звичайно, можливість моніторингу таких екосистем також пов’язана з проблемами щодо EOF і захисту на основі довіри. Якщо ця екосистема є туманною для найприскіпливіших спостерігачів, як спільнота Ethereum має стежити за загрозами здоров’ю своєї екосистеми виробництва блоків?

Зменшити ризик

Мемпул Ethereum обмежений. Для деяких програм це пов’язано з недостатньою конфіденційністю (затисненою посередині), а для інших – через нездатність підтримувати більший діапазон форматів повідомлень. Це ставить розробників гаманців і додатків у безвихідне становище, оскільки вони повинні знайти спосіб підключити користувачів до блокчейну, уникаючи при цьому вищезгаданих небезпек.

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

Без дозволу, тому будь-хто може зіставляти та виконувати наміри, не жертвуючи надто високою якістю виконання

Загальний, щоб розгортання нових програм не потребувало створення нових пулів пам’яті,

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

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

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

на завершення

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

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

У цій парадигмі транзакцій, що зароджується, і в тих областях, які ми не охопили в цьому документі, як-от розробка мови вираження намірів, яка забезпечує конфіденційність, ще потрібно зробити багато досліджень і розробок. Якщо ви вважаєте цю чи інші теми дослідження, пов’язані з наміром, цікавими, будь ласка, зв’яжіться з 0xquintus georgios@paradigm.xyz.

• Велике спасибі Дену Робінсону, Чарлі Ноєсу, Метту Хуангу, Джону Гу, Сіньюаню Суню та Елайджі Фоксу за відгуки про цю статтю, а також Ачалу Срінівасану за розробку графіки. *