Обіцянка блокчейна завжди полягала у тому, щоб зробити фінанси та координацію більш доступними. Але будь-хто, хто намагався зробити простий крос-чейн своп токенів, знає реальність: множинні взаємодії з гаманцем, токени газу, специфічні для ланцюга, обчислення прослизання та постійна загроза невдалих транзакцій, які виснажують ваші кошти. Розрив між потенціалом блокчейну та його зручністю залишився наполегливо широким.
Вводиться дизайн, орієнтований на наміри, новий підхід, який може радикально змінити те, як користувачі взаємодіють з Web3. Замість того, щоб змушувати користувачів визначати кожен крок транзакції - який ланцюг, який протокол, яку саме послідовність викликів смарт-контрактів - архітектури, орієнтовані на наміри, дозволяють користувачам просто визначити, чого вони хочуть досягти. Інфраструктура бере на себе все інше.
Цей зсув відображає ширшу модель в історії обчислень. Ранні користувачі комп'ютерів програмували на мові асемблера, визначаючи точні інструкції машини. Сучасні користувачі просто клацнуть, напишуть або скажуть бажаний результат. Дизайн, орієнтований на наміри, обіцяє подібну трансформацію для блокчейну: від імперативного програмування («зроби це, потім це, потім це») до декларативного вираження («зроби це»).
Модель, базована на транзакціях, яка домінувала в Web3 з часів запуску Ethereum, вимагає від користувачів розуміння технічних деталей, які повинні бути абстрактовані. Якщо ви хочете свопувати токени між ланцюгами, вам потрібно мостити активи, переконатись, що у вас є правильний токен газу, перейти до відповідної децентралізованої біржі, встановити параметри прослизання і сподіватись, що жодний MEV-бот не обжене вашу транзакцію. Кожен крок представляє фрикцію та потенційну невдачу.
Такі проекти, як Anoma, SUAVE від Flashbots і CoW Protocol пропонують різний підхід. Ці архітектури, орієнтовані на наміри, вводять мережі вирішувачів, які змагаються за досягнення цілей користувачів оптимальним чином. Користувачі виражають бажані результати; вирішувачі беруть на себе всю складність виконання. Результат може бути тим Web3, яке більше не відчувається як програмування, а як просте досягнення цілей.
Ця трансформація має глибокі наслідки для звичайних користувачів, розчарованих у складності, розробників, які втомилися від інтеграції між ланцюгами, та здатності криптоекосистеми масштабуєтися поза поточними обмеженнями. Але дизайн, орієнтований на наміри, також вводить нові ризики, пов'язані з централізацією, приватністю та відповідальністю вирішувачів. Розуміння як обіцянок, так і підводних каменів важливе зараз, коли ця архітектура починає рухатися від теорії до виробництва.
Що таке дизайн, орієнтований на наміри?
В основі свого, намір представляє бажаний кінцевий стан користувача замість запрограмованого шляху виконання. В технічних термінах, намір - це підписане повідомлення, яке виражає, якого результату користувач хоче досягти, разом із обмеженнями, які визначають прийнятні шляхи досягнення цього результату.
Розрізнення між транзакційно-орієнтованими і наміро-орієнтованими взаємодіями ілюструє цей зсув парадигми. В системах, базованих на транзакціях, таких як Ethereum, користувачі складають конкретні інструкції: «Виконати функцію X в контракті Y з параметрами Z». Блокчейн детермінованим чином обробляє ці інструкції. Користувачі несуть відповідальність за розуміння інтерфейсів контракті, управління nonces, володіння токенами газу і передбачення зміни стану.
Намір-орієнтовані системи перевертають цю модель. Користувачі заявляють: «Я хочу закінчити з активом B, починаючи з активу A, з обмеженнями C». Декларація може визначати максимальну допустиму неузгодженість, часові рамки або приватні переваги, але не диктує шлях виконання. Треті сторони вирішують ці наміри та змагаються на знаходження оптимальних стратегій виконання, торкаючись будь-якої комбінації on-chain ліквідності, крос-чейн мостів, оф-чейн маркетмейкерів або peer-to-peer матчів.
Розгляньте конкретний приклад. У моделі транзакцій, користувач, що бажає обміняти 100 USDC на ETH на Ethereum, повинен:
- Забезпечити наявність ETH для газу
- Перейти до специфічної DEX
- Затвердити контракт токену USDC
- Обчислити допустиме прослизання
- Відправити транзакцію на обмін
- Слідкувати за потенційними атаками MEV
- Очікувати підтвердження
У моделі намірів, користувач просто підписує: «Я хочу принаймні X ETH за 100 USDC протягом наступних 10 хвилин». Вирішувачі потім змагаються за забезпечення найкращого виконання, потенційно:
- Узгодження з іншим користувачем, що бажає протилежної торгівлі (peer-to-peer розрахунок)
- Маршрутизація через множинні джерела ліквідності одночасно
- Виконання через множинні DEX для мінімізації цінового впливу
- Використання оф-чейн маркетмейкерської ліквідності
- Управління всіма газовими платіжами і логістикою затвердження
Архітектура Anoma описує це як «узагальнені наміри» – наміри, що працюють між будь-якими типами додатків, не тільки при торгівлі. Ігровий намір може бути «придбати цей предмет в грі за найкращою ціною». DeFi-намір може бути «підтримувати позицію з певними кольтерными коефіцієнтами серед будь-якого ланцюга, де це найвигідніше для капіталу». Система стає орієнтованою на результат, а не на процес.
Ця абстракція забезпечує кілька миттєвих переваг. Користувачі більше не потребують глибокого технічного знання для навігації в складнощах блокчейну. Вони уникають зберігання множинних токенів газу. Вони захищені від поширених підводних каменів, як фронт-рання, оскільки їх намір оптимально виконують конкуренти, а не просто виконуються в загальнодоступному мемпулі. Когнітивне навантаження взаємодії з Web3 значно зменшується.
Архітектури, орієнтовані на наміри, розглядають додатки як координаційні системи де фундаментальною одиницею не є транзакція, а бажана зміна стану. Це уявлення має подальші наслідки для того, як будуються протоколи, як структурується ліквідність, та як цінність протікає через екосистему. Це представлено як «третє покоління» блокчейн-архітектури, що слідує за скриптовими розрахунками Bitcoin та програмованими розрахунками Ethereum.
Як проекти будують шари намірів
Декілька великих проектів піонерять інфраструктуру для архітектур, орієнтованих на наміри, кожен приймає різні підходи до технічних викликів.
Anoma: Операційна система намірів
Anoma позиціонує себе як розподілена операційна система для додатків, орієнтованих на наміри. Замість того, щоб будуватися на існуючих блокчейнах як шар додатку, Anoma переосмислює весь стек з перспективи, орієнтованої на наміри. Архитектура проекту зосереджена на кількох ключових компонентах:
Машина Намірів обробляє наміри користувачів і координує їх виконання. Подібно до того, як віртуальна машина Ethereum обробляє транзакції у зміни стану, Машина Намірів Anoma обробляє наміри у зміни стану. Користувачі виражають бажані результати через додатки, які транслюють ці наміри в децентралізовану мережу пліток. Це фундаментально відрізняється від традиційних мемпулів, які транслюють виконувані транзакції.
Вирішувачі в мережі Anoma - це спеціалізовані вузли, які слухають трансляцію намірів і визначають сумісні матчі. Якщо Аліса хоче купити NFT, а Боб хоче його продати, вирішувачі зустрічають їхні наміри і пропонують збалансовані транзакції, що автоматично осідають торгівлю між будь-якими підключеними ланцюгами. Важливо, що Anoma підтримує узагальнені наміри - архітектура може обробляти будь-який тип запиту, від фінансових свапів до складної багато-партійної координації.
Anoma Resource Machine (ARM) забезпечує дії для валідного оновлення стану. Цей компонент аналогічний EVM, але спеціально розроблений для обчислень, орієнтованих на наміри. ARM використовує модель стану, основану на ресурсах, де ресурси представляють будь-який актив разом з логікою, що керує їх створенням та споживанням. Ця абстракція забезпечує більш гнучку композиційність, ніж традиційні моделі записів або UTXO.
Архітектура Anoma вибивається з обмежень, центрованих на блокчейнах, ставлячи під сумнів потребу в блокчейнах взагалі, більш за settlement. Дизайн об'єднує підлеглі блокчейни в єдине середовище розробки, закінчуючи фрагментацію стану та користувачів, що обмежує програми сьогодні. Розробники можуть розгортати один раз та доступати користувачів, стан і виконання на будь-якому підключеному ланцюгу.
Проект зібрав понад 60 мільйонів доларів від головних інвесторів, включаючи Polychain Capital, Coinbase Ventures та Electric Capital, сигналізуючи про інституціональну впевненість в ініціативі, орієнтованій на наміри. Anoma готується до запуску основної мережі з планами спочатку розгорнутись на Ethereum, перед тим як розширитися в інші екосистеми.
SUAVE: Шар намірів від Flashbots для МЕВ
Flashbots, дослідницька організація, спрямована на пом'якшення МЕВ, розробляє SUAVE (Single Unifying Auction for Value Expression), щоб служити спільним мемпулом і шаром послідовності для кількох блокчейнів. SUAVE обирає інший архітектурний підхід від Anoma, зосереджуючись конкретно на транспортному ланцюгу MEV та порядку. SUAVE діє як спеціалізований блокчейн. блок будівельника ролей з існуючих ланцюгів. Замість того, щоб користувачі надсилали конкретні транзакції до окремих пулів пам'яті ланцюга, вони подають уподобання – наміри – на універсальний аукціон SUAVE. Ці уподобання можуть варіюватися від простих ("обміняти A на B") до складних ("збалансувати мій портфель між ланцюгами, максимізуючи дохідність").
Архітектура вводить кілька нових компонентів. SUAVE використовує конфіденційні обчислення через Intel SGX, щоб дозволити обчислення на потік замовлень чутливих користувачів без розкриття інформації потенційним експлуататорам. Це вирішує основну напругу: вирішувачам потрібна інформація для оптимального виконання, але надмірна інформація дозволяє екстракцію MEV.
Будівельники блоків, які працюють лише на одному ланцюзі, опиняються в невигідному становищі через крос-доменний MEV. SUAVE дозволяє будівельникам захоплювати цінність між декількома ланцюгами одночасно. Валідатори максимізують дохід на своїй блоковій області. Користувачі здійснюють приватні транзакції з кращим виконанням і мінімальними комісіями. Дизайн має на меті запобігти централізації, викликаній екстракцією MEV між ланцюгами.
Дорожня карта SUAVE включає прогресивні етапи децентралізації. Ранні версії використовують довірені обчислювальні середовища з припущеннями щодо Flashbots, тоді як пізніші версії переходять до повністю децентралізованої операції. Проект відкрито запрошує конкурентів до участі, визнаючи, що розподіл інфраструктури MEV служить довгостроковому здоров'ю екосистеми краще, ніж контроль однією сутністю.
Хоча SUAVE зараз більше зосереджений на намірах пошуковиків, ніж на загальних намірах користувачів, інфраструктура забезпечує базу для ширших додатків на основі намірів. З плином часу система може розширюватися, щоб обробляти більш різноманітні типи намірів, крім оптимізації потоку замовлень.
Протокол CoW: Практична торгівля на основі намірів
Протокол CoW став піонером у торгівлі на основі намірів у 2021 році, роблячи його одним із перших впроваджень цих концепцій у виробництво. Назва протоколу посилається на "Збіг Бажань" – економічну концепцію, де дві сторони бажають товари один одного та можуть торгувати безпосередньо без посередників.
Протокол CoW працює, збираючи торги з часом у пакети. Користувачі підписують позаланцюгові замовлення, виражаючи свій торговий намір: бажані активи, допустимі цінові діапазони, часові обмеження. Ці наміри надходять у мережу вирішувачів, які змагаються на аукціонах, щоб забезпечити найкраще виконання для всього пакета.
Вирішувачі можуть виконувати наміри за допомогою кількох методів:
- Пряме зіставлення: коли двоє користувачів хочуть протилежні торги, вирішувачі поєднують їх під час торгівлі без використання ліквідності в ланцюзі
- Кільцеві торги: багатосторонні кругові торги, що оптимізують кілька одночасних намірів
- Агрегація DEX: маршрутизація через існуючі AMM, поєднуючи джерела ліквідності
- Приватні маркет-мейкери: використання позаланцюгової ліквідності, коли це вигідно
Механізм пакетних аукціонів забезпечує природний захист від MEV. Усі торги в пакеті виконуються за однаковими цінами очищення, усуваючи динаміку "перший приходить, перший обслуговується", яка дозволяє фронтранінг. Вирішувачі несуть витрати на газ, а отже користувачі не платять нічого, якщо торги не відповідають їхнім специфікованим мінімумам.
CoW Swap обробив понад 30 мільярдів доларів обсягу, зекономивши користувачам понад 82 мільйони доларів надлишку через оптимальне виконання і займаючи 63% частку на ринку серед аграгаторів DEX на основі намірів. Протокол демонструє, що архітектури на основі намірів можуть працювати в великих масштабах вже сьогодні, а не тільки в майбутніх системах.
Інші значні проекти
Кілька інших проектів роблять свій внесок у екосистему, орієнтовану на наміри:
- Essential: Створення протоколів тільки для намірів з нуля, де не існує транзакцій, поданих користувачами – лише пакетні рішення намірів
- UniswapX: Маршрутизація на основі намірів від Uniswap із використанням голландських аукціонів і сіток наповнювачів з можливостями міжланцюгового запуску в 2024-2025 роках
- Протокол Across: Пропонує стандарти для міжланцюгової інтероперабельності намірів разом з UniswapX
- 1inch Fusion: маршрутинг обміну на основі намірів від відомого аграгатора DEX
- DappOS: Інфраструктура для взаємодії додатків, орієнтованих на наміри, включно із активами намірів і виконанням намірів
Ці проекти мають спільні технічні шаблони: позаланцюгове транслювання намірів, конкурентні мережі вирішувачів, перевірку розрахунків в ланцюзі та координацію між ланцюгами. Різноманітність підходів свідчить про те, що простір все ще досліджує, які архітектурні вибори будуть найбільш ефективними.
Чому архітектури, орієнтовані на наміри, важливі
Дизайн, орієнтований на наміри, вирішує кілька фундаментальних проблем, що заважають прийняттю та ефективності Web3. Переваги охоплюють користувальницький досвід, економічну оптимізацію та системну стійкість.
Радикальне покращення користувацького досвіду
Найпомітніша безпосередня перевага – це радикальне спрощення користувацької подорожі. Сучасні системи Web3 складні і створюють бар'єри до входу, вимагаючи від користувачів навігації по фрагментованій інфраструктурі. Користувач, який бажає брати участь у DeFi на кількох ланцюгах, стикається зі значною складністю: управління кількома гаманцями, утримання різних токенів для газу, розуміння інтерфейсів специфічних для протоколу, моніторинг для оптимального часу та постійна турбота про експлуатацію MEV.
Системи, орієнтовані на наміри, спрощують цю складність. Користувачі вказують бажані результати природними термінами. Система може навіть використовувати інтерфейси штучного інтелекту, щоб перекласти просту англійську на формальні наміри: "Я хочу збалансувати свій портфель до 60% ETH, 30% стабільних монет, 10% LINK" стає структурованим наміром, який вирішувачі виконують автоматично.
Ця абстракція особливо корисна для менш досвідчених користувачів. Сьогодні середній користувач DeFi бореться, щоб отримати доступ до типів виконань та ціноутворення, які доступні лише добре капіталізованим фірмам з внутрішніми технічними командами. Архітектури на основі намірів демократизують доступ до виконання інституційного рівня.
Невдалі транзакції не коштують користувачам нічого в газі з системами намірів – вирішувачі несуть ці витрати. Користувачам не потрібно тримати ланцюгоспецифічні газові токени; вирішувачі збирають комісії в токенах, що торгуються. Тертя, пов'язане з управлінням технічними деталями, знижується, тоді як упевненість в оптимальному виконанні зростає.
Зменшення MEV і повернення вартості
Майнінг/максимально екстрагується вартість становить мільярди витягнутих щорічно з користувачів блокчейну. Традиційні моделі транзакцій піддають користувачів фронтранінгу, сандвіч-атакам та іншим видам хижацьких екстракцій. Публічні пулі пам'яті транслюють наміри користувачів перед їх виконанням, даючи досвідченим акторам час на їх експлуатацію.
Архітектури, орієнтовані на наміри, фундаментально змінюють ці динаміки. Оскільки користувачі підписують наміри, а не виконувані транзакції, фактично немає способу фронтранити намір. Вирішувачі змагаються, щоб забезпечити найкращий результат для підписаної зміни стану, але шлях виконання залишається гнучким. Це усуває передбачуваність, яку використовують боти MEV.
Механізми пакетних аукціонів, такі як ті, що використовуються протоколом CoW, агрегують замовлення протягом вікон часу, ще більше зменшуючи можливості MEV. Коли декілька угод виконуються одночасно за однаковими цінами, традиційні вектори екстракції MEV зникають. Та вартість, яка існує, змагається мережами вирішувачів, а не захоплюється зловмисними акторами.
Важливо, що системи намірів не усувають MEV повністю – вони трансформують його з видобувного на продуктивне. Вирішувачі в конкурентних мережах повертають вартість користувачам, а не видобувають її. Критерій для перемоги стає максимізацією задоволеності користувачів, а не використанням інформаційних асиметрій.
Крос-ланцюгова взаємодія та комбінування
Можливо, найглибший вплив має те, як архітектури, орієнтовані на наміри, вирішують багатоланцюгову реальність Web3. Сучасна екосистема фрагментована між Layer 1, Layer 2 та бічними ланцюгами, кожен з яких має ізольовану ліквідність та базу користувачів. Переміщення вартості між ланцюгами вимагає мостів, обгорнутих активів та складних довірчих припущень.
Архітектури, орієнтовані на наміри, дозволяють комбінування на рівні намірів, а не на рівні транзакцій, об'єднуючи стан між підключеними ланцюгами. Користувачі висловлюють наміри, не уточнюючи, який ланцюг їх виконує. Вирішувачі визначають оптимальні місця виконання, можливо, діліючи великі замовлення між кількома ланцюгами або маршрутизуючи через той майданчик, який в даний момент пропонує найкращу ліквідність.
Ця абстракція приносить користь розробникам стільки ж, скільки й користувачам. Замість того, щоб розгортати окремі смарт-контракти для кожного ланцюга та управляти складністю міжланцюгових повідомлень, розробники можуть створювати децентралізовані додатки, орієнтовані на наміри, з меншою мережею. Застосунки стають дійсно портативними, слідуючи за ліквідністю та користувачами, а не залишаючись прив'язаними до конкретних блокчейнів.
Шар намірів може агрегірувати ліквідність у всіх підключених доменах, вирішуючи проблему "курки та яйця", коли нові блокчейни зіштовхуються з труднощами в залученні користувачів без наявної ліквідності. Якщо користувачі та розв'язувачі беруть участь у об'єднаній мережі намірів, фрагментація ліквідності стає менш критичною. Замовлення прямують туди, де їх можна оптимально виконати.
Капітальна ефективність та інновації
Моделі, засновані на намірах, дозволяють нові форми капітальної ефективності. Коли розв'язувачі можуть використовувати свої власні резерви для полегшення торгів, капітал більше не потрібно зберігати бездіяльним у ліквідних пулах. Професійні маркет-мейкери можуть надавати ліквідність динамічно, залучаючи капітал лише тоді, коли з'являються прибуткові можливості.
Система відкриває можливості, які не могли існувати в традиційних моделях транзакцій. Стає можливим складне багатостороннє кооперування, коли виражаються результати замість хореографії точних послідовностей виконання. Програми, що були непрактичними через високі затрати на газ або складність координації, стають життєздатними, коли мережі намірів ефективно керують виконанням.
Як виглядає перехід: від смарт-контрактів до шарів намірів
Розуміння, де дизайн, орієнтований на намір, вписується в еволюцію блокчейнів, дає уявлення про його значення та імовірний напрямок розвитку.
Еволюція веб-архітектур
Web1 був лише для читання: статичні сторінки, що обслуговувалися з централізованих серверів. Користувачі споживали контент, але рідко брали участь у його створенні. Архітектура відображала цю пасивність – прості HTML-сторінки з мінімальною інтерактивністю.
Web2 представив користувацький контент та динамічні застосунки, але зберігав централізований контроль. Платформи на кшталт Facebook та Google дозволяли участь, залишаючи дані і вартість у центрі. Користувачі змінили контроль на зручність, створюючи модель капіталізму спостереження, яку Web3 прагне зруйнувати.
Перше покоління Web3, на прикладі Bitcoin, ввело програмовані розрахунки. Користувачі могли програмувати гроші з базовою логікою умов, але мова сценаріїв залишалася навмисно обмеженою. Bitcoin демонстрував, що блокчейни можуть працювати, але пропонував обмежену виразність.
Ethereum проклав шлях до архітектури другого покоління з повністю програмованими розрахунками. EVM дозволив довільні обчислення, що спричинили вибух застосунків: токени, DAO, протоколи DeFi, ринки NFT. Але така програмованість створювала складність. Користувачі ставали де факто програмістами, створюючи транзакції з викликів смарт-контрактів.
Обмеження архітектур другого покоління стали очевидними в міру ускладнення застосунків. Складні застосунки, як ринкові платформи NFT та ордербук DEX, вимагають централізованих компонентів для пошуку контрагентів та оптимізації – функцій, які блокчейн не забезпечує ефективно. Ці архітектури Gen 2.5 працюють, але компрометують децентралізацію.
Архітектури третього покоління, орієнтовані на намір, прагнуть забезпечити децентралізацію від початку до кінця для довільних типів застосунків. Створюючи наміри фундаментальною примітивою, ці системи пропонують загальну реалізацію намірів, пошук контрагентів, вирішення та розрахунки – усе, що потрібно застосункам, без примушення їх до дизайну, орієнтованого на блокчейн.
Що змінюється для розробників
Перехід до архітектур, орієнтованих на наміри, фундаментально трансформує досвід розробника. Сьогоднішні розробники блокчейнів повинні:
- Володіти кількома мовами програмування (Solidity, Rust, Move)
- Розуміти специфічні особливості кожного ланцюга та моделі газу
- Будувати користувальницькі мости та міжланцюгове повідомлення
- Реалізувати свій захист від MEV
- Обробляти крайові випадки при реорганізаціях ланцюга
- Оптимізувати дорогі обчислення на ланцюгу
Розробка, орієнтована на наміри, абстрагує багато з цих питань. Розробники визначають мови намірів – словник бажань, які розуміють їх застосунки. Підпільна інфраструктура обробляє деталі виконання. Замість написання окремих реалізацій для кожного ланцюга, застосунки за замовчуванням стають портативними.
Це нагадує попередні переходи в розробці програмного забезпечення. Колись розробники керували розподілом пам’яті вручну; тепер це здійснюють збирачі сміття. Колись розробники писали платформо-залежний код; тепер фреймворки надають кросплатформні абстракції. Дизайн, орієнтований на наміри, приносить подібні абстракції в розробку блокчейнів.
Перехід не відбудеться за одну ніч. Існуючі смарт-контракти представляють значні інвестиції та ефекти мережі. Повинні існувати шляхи міграції для поточних застосунків, щоб поступово інтегрувати взаємодії на основі намірів. Гібридні архітектури, імовірно, домінуватимуть в перехідний період, з шарами намірів, що охоплюють традиційні системи транзакцій.
Що змінюється для інфраструктури
Інфраструктурний шар переходить від ланцюгів, що змагаються за застосунки, до мереж розв’язувачів, які змагаються за потік замовлень. Ланцюги стають шарами розрахунків, а не середовищами виконання. Цінна нерухомість пересувається вгору по стеку до оркестрації намірів та мереж розв’язувачів.
Цій переорієнтації вартості та влади притаманні важливі наслідки. Пошуковці MEV можуть перейти на роль розв’язувачів, використовуючи подібні навички, але в ціннісно-позитивному, а не ціннісно-екстрактивному контексті. Постачальники ліквідності можуть працювати по-іншому, забезпечуючи ліквідність за запитом, а не ставлячи капітал в пулах. Роль валідацій стає перевіркою виконання намірів, а не упорядкування транзакцій.
Виникають нові потреби в інфраструктурі: мережі госсіпу намірів, системи репутацій для розв’язувачів, движки задоволення обмежень, протоколи міжланцюгових розрахунків. Екосистема потребує стандартів для вираження намірів, що дозволяють різним системам взаємодіяти. Без стандартів існує ризик фрагментації простору в несумісні сектори намірів.
Що може піти не так? Ризики та компроміси
Як і будь-який архітектурний зсув, дизайн, орієнтований на намір, вводить нові вектори атак, ризики централізації та непередбачувані наслідки поряд з перевагами.
Ценралізація розв’язувачів
Мабуть, найбільший ризик полягає в централізації мережі розв’язувачів. Запуск конкурентної інфраструктури розв’язувачів вимагає складних технічних можливостей та значного капіталу. Розв’язувачі повинні підтримувати інвентарі на кількох ланцюгах, виконувати складні алгоритми оптимізації, керувати витратами на газ та відповідати з мінімальною затримкою.
Ці вимоги створюють бар'єри для входу. Якщо лише кілька організацій можуть ефективно вирішити завдання, система вводить централізацію під новим ім'ям. Кілька домінуючих розв’язувачів можуть зговоритися, щоб запропоновати неповноцінне виконання, витягуючи цінність аналогічно до того, як боти MEV експлуатують традиційні системи. Користувачі отримують спрощені інтерфейси, але втрачають децентралізацію, яка робила блокчейн привабливим.
Деякі протоколи починають з використанням дозволених мереж розв’язувачів, вимагаючи білий список для участі. Це забезпечує якість виконання, але суперечить бездозвільній етиці Web3. Вирішання цього виклику полягає в розробці механізмів, що підтримують якість при допустимій участі.
Системи репутацій, вимоги до стейкінгу та механізми виправлення можуть пом’якшити ці ризики. Розв’язувачі можуть розміщувати значні облігації, які знищуються при виявленні неправомірних дій. Користувачі можуть публічно контролювати продуктивність розв’язувачів та направляти наміри до надійних операторів. Але ці механізми додають складності і можуть не повністю вирішити проблему централізації.
Питання конфіденційності
Вираження намірів публічно створює ризики витоку інформації. Оголошення про бажання торгувати великими обсягами виявляє вашу стратегію, що потенційно дозволяє розв’язувачам або спостерігачам здійснювати фронтраннінг на рівні намірів, а не транзакцій. Хоча наміри забезпечують певний захист через конкурентне рішення, вони не усувають всю інформаційну асиметрію.
SUAVE вирішує це завдання, використовучи довірені середовища виконання, але це вводить припущення безпеки навколо Intel SGX та подібного обладнання. Криптографічні методи, такі як докази з нульовим розголошенням, забезпечують сильні гарантії конфіденційності, але забирають значні ресурси.
Простір дизайну включає складні компроміси. Розв’язувачі мають потребу в інформації для забезпечення оптимального виконання, але надмірна інформація відкриває можливості для експлуатації. Знайти правильний баланс залишається відкритою проблемою досліджень, без явного рішення-переможця на даний момент.
Складність реалізації та затримка
Побудова систем, орієнтованих на наміри, пов'язана з значною технічною складністю. Ефективне зіставлення намірів потенційно мільйону користувачів вимагає складних алгоритмів. Міжланцюгові розрахунки викликають проблеми координації та затримку. Забезпечення атомарного виконання при залученні кількох ланцюгів вимагає ретельного проектування протоколів.
Ці складнощі можуть ввести режими відмов. Що відбувається, коли оптимальне вирішення займає більше часу, ніж користувачі готові терпіти? Як системи справляються з частковим виконанням?Існує безліч причин, чому користувачі можуть опинитися у ситуації, коли їхні наміри залишаються незадоволеними. Традиційні транзакційні системи забезпечують передбачувані результати; системи намірів додають невизначеності щодо того, чи відбудеться виконання і як саме.
Виклики стандартизації ускладнюють ці технічні труднощі. Без спільних форматів вираження намірів різні системи не можуть взаємодіяти. Але передчасна стандартизація може закріпити менш оптимальні проекти. Екосистема має врівноважувати швидкість розвитку з розбудовою стійких основ.
Спадщина смарт-контрактів та міграція
Існуюча екосистема Web3 містить мільярди в заблокованій вартості у смарт-контрактах, що побудовані на моделях на основі транзакцій. Ці контракти не можуть бути переписані за ніч. Шляхи міграції повинні існувати для поступового прийняття дизайнів, орієнтованих на наміри.
Гібридні архітектури, де шари намірів обгортають існуючі контракти, надають одне з рішень, але додають складності. Розробники мусять вивчати нові парадигми, підтримуючи при цьому старі системи. Користувачі стикаються з плутаниною щодо того, які програми підтримують які моделі взаємодії. Перехідний період створює фрагментацію замість єдності.
Освіта розробників є ще одним викликом. Зміна ментальної моделі від імперативного програмування транзакцій до декларативного вираження намірів є значною. Поточні розробники блокчейнів мають глибокі знання специфічних мов і зразків; перенавчання вимагає часу. Університети та буткемпи щойно почали викладати Solidity; розробка на основі намірів додає ще одну криву навчання.
Відповідальність і засоби правового захисту
Системи на основі транзакцій забезпечують чітку відповідальність. Якщо ваша транзакція не вдалася або поводилася непередбачувано, ви можете переглянути точну послідовність операцій. Системи на основі намірів абстрагують виконання, ускладнюючи розуміння того, що пішло не так, коли результати не відповідають очікуванням.
Хто відповідає, коли вирішувач надає менш оптимальне виконання? Які засоби правового захисту мають користувачі? Як вони можуть довести, що вирішувач діяв зловмисно, а не зробив чесну помилку? Ці питання не мають чітких відповідей у багатьох поточних проектах. Побудова рамок відповідальності для систем на основі намірів залишається ключовою для захисту користувачів.
Контрольний список перед запуском токенів для проектів на основі намірів
Команди, які готуються запускати токени в системах, орієнтованих на наміри, стикаються з унікальними міркуваннями, що виходять за рамки типових підготовок до запуску токенів. Ці проекти мають узгоджувати токеноміку з динамікою підґрунтчя вирішувача та механізмів відповіді на наміри.
Визначте чітку мову намірів і протоколи
Успішні проекти на основі намірів вимагають однозначних стандартів вираження намірів. Команди повинні:
Документувати схеми намірів всебічно: Визначте, які саме типи намірів підтримує система, як користувачі виражають обмеження, які параметри є обов'язковими, а які – за вибором. Мови намірів повинні бути достатньо виразними, щоб охопити бажання користувачів, залишаючись парсабельними для мереж вирішувачів.
Надати SDK та інструменти для розробників: Створення програм на основі систем намірів вимагає інших інструментів, ніж розробка на основі транзакцій. Чітка документація, зразки кодів та рамки для тестування знижують бар'єри на шляху впровадження.
Врахувати майбутню розширюваність: Мови намірів повинні підтримувати розвиток. Виникатимуть нові типи намірів; стандарт має враховувати їх без порушення існуючих реалізацій. Схеми версіонування та політики відмови мають значення.
Побудувати або співпрацювати для інфраструктури вирішувачів
Мережі вирішувачів є основою виконання систем на основі намірів. Токенні проекти повинні забезпечити надійну місткість виконання:
Запустіть початкову участь вирішувачів: Запуск вимагає достатньої кількості вирішувачів для забезпечення конкурентного виконання. Команди можуть потребувати самостійного запуску початкових вирішувачів, надання субсидій для ранніх учасників або співпраці з існуючими операторами вирішувачів з інших протоколів.
Ретельно розробити механізми стимулювання вирішувачів: Вирішувачі потребують винагороди, яка покриває витрати, стимулюючи оптимальні результати для користувачів. Економіка токену повинна винагороджувати гарну поведінку вирішувачів – надаючи надлишок користувачам – при цьому караючи або виключаючи поганих акторів.
Уникати монополій вирішувачів за допомогою дизайну: Різноманітні стратегії можуть сприяти децентралізації вирішувачів. Знижувати бар'єри входу, мінімізуючи вимоги до капіталу. Реалізувати репутаційні системи, які дозволяють новим вирішувачам поступово будувати довіру. Розгляньте моделі делегованого виконання, де вирішувачі спеціалізуються, а не вимагають, щоб кожен займався всім.
Планувати координацію вирішувачів між ланцюгами: Якщо протокол передбачає наміри між ланцюгами, вирішувачі повинні мати механізми для співпраці між доменами. Визначити, як відбувається врегулювання, хто несе витрати на перенесення, і як вирішуються суперечки.
Провести аудит логіки відповідності наміру-вирішувач
Серце будь-якої системи на основі намірів – це те, як наміри відповідають можливостям вирішувачів. Перед запуском токену:
Проводити ретельні аудити безпеки: Логіка відповідності намірів має бути бездоганною. Помилки можуть дозволити вирішувачам несправедливо вилучити значення або залишити наміри незадоволеними. Залучіть кілька фірм з аудитом з досвідом у проектуванні механізмів, а не лише в безпеці смарт-контрактів.
Тестуйте алгоритми відповідності при високих навантаженнях: Симулюйте сценарії з високим навантаженням. Що відбувається, коли одночасно надходять тисячі намірів? Як система граційно деградує при навантаженнях? Де виникають вузькі місця?
Перевірте стимулюючу сумісність: Теорія ігор має величезне значення. Переконайтеся, що вирішувачі не можуть отримати вигоду, відхиляючись від чесної поведінки. Перевірте, що рівноваги Неша відповідають бажаним результатам. Розгляньте векторні атаки, де змовницькі вирішувачі можуть експлуатувати користувачів.
Пріоритезація тестування призначеного для користувача досвіду
Мета дизайну на основі намірів – поліпшення користувацького досвіду. Перевірте це перед запуском:
Тестуйте з нетехнічними користувачами: Запропонуйте інтерфейс людям, незнайомим зі складністю блокчейна. Чи можуть вони зрозуміти, що означають наміри? Чи довіряють вони системі виконати відповідно до бажань? Де вони плутаються?
Порівняйте з традиційними альтернативами: Порівняйте досвід на основі намірів з еквівалентами на основі транзакцій. Чи є він насправді простіше? Чи є результати послідовно кращими? Документально фіксуйте конкретні покращення кількісно.
Створіть чіткі механізми зворотного зв'язку: Користувачі повинні розуміти, що відбувається з їхніми намірами. Надайте оновлення статусу: намір отримано, вирішувачі змагаються, запропоноване виконання, підтверджене врегулювання. Нечіткий зворотний зв'язок породжує недовіру.
Підготуйтеся до крайніх випадків: Що бачать користувачі, коли наміри не можуть бути виконані? Як вони модифікують або скасовують наміри? Що відбувається під час блокування мережі? Ретельно відполіруйте ці досвіди.
Встановіть шляхи управління і децентралізації
Управління на основі токенів повинно узгоджуватися з принципами, орієнтованими на наміри:
Визначити механізми оновлення: Протоколи намірів будуть розвиватися. Встановіть чіткі процеси для пропозиції, тестування і розгортання змін. Балансуйте швидкі ітерації з стабільністю, яку вимагають мережі вирішувачів.
Плануйте участь у управлінні вирішувачами: Чи повинні вирішувачі мати спеціальні управлінські права? Як протокол запобігає захопленню картелем вирішувачів? Розгляньте, чи потребує участь вирішувачів наявності токенів і що це означає для ризиків централізації.
Поступова дорожня карта децентралізації: Більшість проектів запускаються з деякими централізованими компонентами з прагматичних причин. Документуйте шлях до повної децентралізації експліцитно. Які віхи позначають перехід? Що викликає зміни в контролі?
Прозорість у токеноміці: Користувачі та вирішувачі повинні мати довіру до економіки токенів. Публікуйте чітку документацію про випуски, графіки вестинга, використання скарбниці та механізми накопичення вартості. Уникайте сюрпризів, що підривають довіру.
Забезпечте сумісність між протоколами
Екосистеми на основі намірів отримують користь від мережевих ефектів. Ізоляція вашого протоколу обмежує цінність:
Підтримуйте стандарти намірів, що виникають: Беріть участь у розвитку стандартів намірів між ланцюгами. Реалізуйте запропоновані ERCs, пов'язані з вираженням намірів. Зробіть інтеграцію з іншими протоколами простою.
Будуйте модульну архітектуру: Уникайте замикання на постачальника, зберігаючи компоненти розділеними. Інші проекти повинні мати можливість інтегрувати вашу мережу вирішувачів або відповідність намірів без прийняття всього вашого стеку.
Співпрацюйте з комплементарними протоколами: Екосистеми, орієнтовані на наміри, залучають спеціалізованих постачальників – деякі зосереджені на врегулюванні між ланцюгами, інші на конкретних типах активів, інші на конфіденційності. Стратегічні партнерства створюють більше цінності, ніж ізольована розробка.
Утримуватися від прив'язки до конкретних ланцюгів: Уникайте надання переваги визначеним рівням 1 чи 2, якщо ваш випадок використання цього не вимагає. Сила дизайну, орієнтованого на наміри, полягає у абстрагуванні відмінностей ланцюгів; штучні обмеження знижують привабливість.
Яким може бути майбутнє
Архітектури, орієнтовані на наміри, можуть радикально перетворити Web3, якщо вони досягнуть широкого прийняття. Екстраполяція поточних тенденцій вказує на кілька можливих майбутніх сценаріїв.
За межами торгівлі: все, орієнтоване на наміри
Хоча перші впровадження зосереджуються на DeFi-торгівлі, парадигма поширюється набагато далі. Ігрові додатки можуть використовувати наміри для управління активами в грі, дозволяючи гравцям вказувати бажане обладнання або шляхи прогресу без розуміння механіки блокчейна. Координація ланцюга постачання може виражати логістичні наміри: "доставити ціВміст: materials to this location by this date with proof of authenticity."
Соціальні координаційні механізми можуть працювати на основі намірів. DAO можуть виражати колективні бажання – фінансувати ці суспільні блага, досягати цих результатів – і мережі рішень можуть ідентифікувати оптимальні розподіли ресурсів. Квадратичне фінансування, ретроактивне фінансування суспільних благ та інші проєкти механізмів стають більш практичними коли шари намірів обробляють складність виконання.
Оптимізація дохідності між ланцюгами може стати повністю автоматизованою. Користувачі виражають рівень ризику і очікування доходів; розв'язувачі динамічно збалансовують між протоколами та ланцюгами, щоб максимізувати результати. Психологічне навантаження від активного управління позиціями в DeFi зникає.
Трансформація дизайну обміну
Поточні дизайни DEX можуть бути проміжними кроками, а не кінцевими станами. Якщо зіставлення намірів стане достатньо ефективним, окремі інтерфейси обміну можуть стати непотрібними. Самі гаманці можуть стати інтерфейсами намірів, з розв'язувачами, які надають ліквідність в часі, а не через постійно працюючі ліквідні пули.
Ця трансформація може значно покращити капітальну ефективність. Замість мільярдів заблокованих в AMM пулах, які заробляють низькі доходи, професійні маркетмейкери динамічно розподіляють капітал. Користувачі отримують кращі ціни; постачальники ліквідності отримують вищі доходи. Посередники, які забезпечують цінність – досвідчені розв'язувачі – отримують відповідну компенсацію, а не пасивний капітал, що отримує більшість винагород.
Агрегатори можуть розвиватися в мета-розв'язувачі, координуючи між спеціалізованими мережами розв'язувачів. Замість того, щоб безпосередньо агрегувати джерела ліквідності DEX, вони агрегують можливості розв'язувачів, перемикаючи наміри до будь-якої мережі, яка може найкраще виконати їх для конкретних типів намірів.
Зміна влади: від ланцюгів до розв’язувачів
Місце цінності та контролю може змінитися з блокчейнів першого рівня на шари оркестрації намірів. Якщо користувачі взаємодіють головним чином через інтерфейси намірів, підлежний ланцюг розрахунків має менше значення. Розв’язувачі вибирають місця виконання; користувачі цікавляться лише результатами.
Ця зміна може зменшити племінність ланцюгів і конкуренцію. Якщо Ethereum, Solana та інші ланцюги в основному служать як шари розрахунків для мереж намірів, їхня диференціація стає технічною (швидкість, вартість, безпека), а не культурною. Застосунки стають по-справжньому незалежними від ланцюгів.
Однак це також концентрує владу в мережах розв'язувачів. Якщо кілька операторів-розв'язувачів домінують, вони контролюють, які ланцюги використовуються, які програми успішні, і як розподіляється цінність. Децентралізація, яку обіцяли блокчейни, може бути підірвана через централізовану інфраструктуру вирішення. Щоб запобігти цьому результату, потрібно пильно стежити за дизайном мережі розв'язувачів.
Еволюція розробки смарт-контрактів
Розробники смарт-контрактів можуть змінити фокус з написання виконавчої логіки на визначення мов намірів і умов придатності. Замість того, щоб програмувати "якщо X відбувається, зробити Y", вони програмують "ці результати є дійсними, все інше є недійсним."
Ця трансформація відображає інші зміни у парадигмах програмування. Декларативне програмування вже домінує в багатьох сферах – SQL для баз даних, CSS для стилізації, React для інтерфейсів користувача. Розробка блокчейнів на основі намірів розширює декларативні підходи на координацію в ланцюгу.
Можливо, зміняться цінності, які надаються розробникам. Глибоке знання конкретних VM опкодів стане менш критичним; важливішим стане розуміння дизайну механізмів, теорії ігор та задоволення умов. Перехід сприятиме розробникам, які мислять про результати і стимули, а не зосереджуються на деталях реалізації.
Регуляторні наслідки
Системи на основі намірів можуть ускладнити регуляторний нагляд. Коли користувачі виражають результати, а розв'язувачі обробляють виконання, хто несе відповідальність за дотримання вимог? Якщо розв'язувач сприяє неочікуваному порушенню регуляцій, виконуючи технічно дійсний намір, де лежить відповідальність?
Навпаки, архітектури намірів можуть дозволити краще дотримання вимог. Намір може включати регуляторні обмеження, які розв'язувачі повинні відповідати. Геообмеження, вимоги до KYC, ліміти транзакцій – все це можна задати як обмеження намірів. Розв'язувачі, які порушують ці обмеження, втрачають репутацію та застави, створюючи ринково спрямоване дотримання вимог.
Результат залежить від того, як проєкти організують підзвітність. Системи, які роблять перевірку відповідності зручною, зберігаючи конфіденційність користувача, можуть задовольнити як регуляторні потреби, так і цінності Web3. Ті, що дозволяють регуляторний арбітраж через неясні мережі розв'язувачів, ймовірно, зіштовхнуться з репресіями.
Заключні думки
Дизайн, орієнтований на наміри, представляє фундаментальне переосмислення того, як люди взаємодіють з блокчейн-системами. Якщо смарт-контракти дозволяли програмовану розрахункову дію, архітектури, орієнтовані на наміри, обіцяють програмовані наміри – користувачі заявляють, що вони хочуть, а не як це досягти.
Переваги є переконливими: надзвичайно спрощенний досвід користувача, захист від експлуатації MEV, безшовна крос-ланцюгова координація та покращення капітальної ефективності. Ранні реалізації на зразок CoW Protocol демонструють, що ці переваги можуть бути реалізовані вже сьогодні, а не в спекулятивному майбутньому. Такі проєкти, як Anoma та SUAVE, будують інфраструктуру, яка може зробити взаємодію, орієнтовану на наміри, стандартом у всій Web3.
Однак ризики вимагають пильної уваги. Централізація розв'язувачів може відтворити концентрування влади, яке блокчейни прагнули усунути. Проблеми з конфіденційністю залишаються невирішеними. Складність реалізації може обмежити прийняття. Перехід від систем, заснованих на транзакціях, буде поступовим і заплутаним.
Для користувачів розуміння цього зсуву важливе, оскільки він вплине на те, як ви взаємодієте з блокчейн-застосунками в наступні роки. Інтерфейси, засновані на намірах, ймовірно, стануть нормою, абстрагуючи складність, але також затемнюючи деталі виконання. Знайте, чому ви довіряєте, коли підписуєте наміри, а не транзакції.
Для розробників дизайн, орієнтований на наміри, пропонує можливість створювати застосунки, що раніше були неможливими. Але це вимагає навчитися новим парадигмам і прийняти, що ваш код не буде виконуватися напряму – це зроблять мережі розв'язувачів. Розгляньте, чи цей модель підходить для ваших потреб застосунку.
Для команд токенів у цій галузі наведений список виділяє міркування, які виходять за межі типових запусків токенів. Протоколи, засновані на намірах, успішні або невдалі залежно від здоров'я мережі розв'язувачів, правильності дизайну механізмів і якості користувацького досвіду. Забезпечте ці основи, перш ніж зосереджуватися на ціні токену.
Перехід до архітектур, орієнтованих на наміри, не відбудеться миттєво і, ймовірно, не буде абсолютним. Гібридні системи домінуватимуть протягом багатьох років. Але напрямок здається ясним: Web3 потребує абстрагувати складність, якщо хоче досягти масового прийняття. Дизайн, орієнтований на наміри, надає шлях вперед, обмінюючи певну прозорість на величезні поліпшення у зручності використання.
Чи зможе цей трансформаційний процес врешті-решт реалізувати обіцяне, залежить від того, наскільки добре екосистема веде торгівлю. Чи можуть мережі розв'язувачів залишатися децентралізованими? Чи може конфіденційність зберігатися при забезпеченні оптимального виконання? Чи можуть з'явитися стандарти, які дозволяють інтопрацюючи, не пригнічуючи інновації?
Відповіді на ці питання визначать, чи стане дизайн, орієнтований на наміри, домінуючою архітектурою для Web3, або залишиться нішевим підходом для конкретних випадків використання. Що точно, так це те, що розмова вже перейшла з "чи" на "як" – парадигма формується зараз з мільярдами капіталу та значними розумовими ресурсами розробників за нею.
Для будь-кого, хто бере участь у Web3 – як користувач, розробник, інвестор чи дослідник – розуміння архітектур, орієнтованих на наміри, перейшло з варіантної можливості до необхідності. Це не віддалена можливість майбутнього, а активно розгорнутий процес трансформації фундаментальної архітектури блокчейну. Смарт-контракти, що визначили перший розділ Web3, поступаються місцем шарам намірів, які можуть визначити його наступний.
Звертаючи увагу, експериментуючи обережно, і визнаючи, що те, що здається поступовим поліпшенням використання, насправді може бути початком найбільшої архітектурної еволюції блокчейн з моменту, коли Ethereum представив програмовані розрахунки. Майбутнє Web3 формується зараз мовами намірів, мережами розв'язувачів і дизайнерськими рішеннями, які визначатимуть, чи стане блокчейн нарешті доступним для всіх, чи залишиться доменом технічних фахівців.
Можливості великі. Як і ставки.