Порядку денного

У чому полягає проблема

1. Визначення кінцевого стану: що робить криптовалютні додатки «зручними»

2. Чому «абстракція ланцюга» є рішенням проблеми UX, що виникає з фундаментальної топології модульних ланцюгів

3. Чому корисні криптовалютні додатки повинні бути побудовані на основі інфраструктури абстракції ланцюга

Простір рішень

1. Як архітектура, заснована на намірах, породить ланцюгову абстракцію

2. Розуміння того, що ринки намірів працюють найкраще, коли мережа розв'язувачів велика та конкурентоспроможна

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

Пропозиція

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

Придатні криптозастосунки не можуть бути побудовані без абстрагування ланцюга

Чи наші найкращі та найрозумніші будують резервну інфраструктуру?

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

Однак я відкидаю твердження, що не існує жодних корисних криптовалютних додатків.

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

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

1. Швидкість: Застосунки повинні працювати так само швидко, як застосунки веб2.
2. Вартість: На відміну від веб2, всі взаємодії веб3 повинні понести певні витрати, але "вартість за клацання" повинна бути незначною.
3. Стійкість до цензури («безперешкодність»): Будь-хто з гаманцем повинен мати змогу взаємодіяти з додатком, якщо вони можуть собі це дозволити.
4. Безпека: Кліки повинні робити те, що користувачі від них очікують, і не повертати — всі оновлення веб3 повинні бути постійними.

Це властивості "використовуваних" криптовалютних додатків.

Ми вже довгий час намагаємося побудувати зручну криптовалюту

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

У 2020 році блокчейни були монолітними, пропонуючи дві з трьох властивостей кінцевим користувачам: швидкість, вартість або безпеку. Ми тоді уявилицентрикована на rollup або модульна майбутністьщо відімкне всі три властивості одночасно.

Сьогодні ми побудували основи для такої інфраструктури, спрямованої на rollup. L2 пропонує дешевий та швидкий блок-простір, і більшість з них пропонують блок-простір без дозволу. З іншого боку, L1 пропонує блок-простір, який є стійким до WW3, та безпечний. (Ви можете дізнатися більше про компроміс між безпекою та зручністю від L1 та L2 вмоя коротка стаття-дослідження). Ці L2 з'єднуються безпечно з L1 через канонічні шляхи повідомлень, закладаючи основу для модульної, але взаємоврізної мережі. За останні чотири роки ми побудували оптичний волоконний кабель між блокчейнами, який одного дня підтримає корисні криптовалютні застосунки. Але чому модулярні блокчейни настільки непридатні?

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

Модулярна топологія блокчейну сприяє тому, що безпечний блок-простір пропонується на іншому рівні, ніж дешевий та швидкий блок-простір. Користувачі природно віддають перевагу зберіганню своїх цінностей в найбільш безпечних мережах, але вони будуть вимагати найчастішої взаємодії з дешевими та швидкими мережами.За дизайном, канонічні шляхи між L2 та L1 повільні і / або дорогі. Ці явища пояснюють, чому користувачам потрібно пройти ці канонічні шляхи, щоб платити за взаємодію L2, використовуючи активи L1. Це призводить до «непридатного» криптовалютного UX.

Віталік про різні типи L2s

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

Отже, ланцюжкова абстракціязначно залежить від того, щоб користувачі могли безпечно, дешево та швидко передавати вартість через мережі. Згідно з сучасним користувацьким потоком, користувач з балансом USDC на "безпечній" мережі, такій як Ethereum, хоче випустити NFT або обміняти на нові токени на новішій мережі, такій як Blast або Base. Спосіб зробити це за можливо меншою кількістю кроків - послідовно виконати серію транзакцій Bridge→Swap→Mint (або Swap→Bridge→Mint).

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

Архітектура на основі намірів - єдиний спосіб побудувати абстракцію ланцюга

Абстракція ланцюжка ґрунтується на міжланцюжковому переказі вартості, але відправка вартості через канонічні шляхи повідомлень або дорога, або повільна. «Швидкі мости» пропонують дешеві та швидкі альтернативи для користувачів надсилання вартості через мережі, але вони вводять нові припущення щодо довіри. Передача повідомлень є найбільш інтуїтивним способом побудови швидкого моста, оскільки вона моделюється за архітектурою TCP/IP; вона ґрунтується на протоколі моста, який діє як маршрутизатор TCP для з'єднання двох ланцюжків.

TCP/IP діаграма з ResearchGate

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

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

Є кілька фундаментальних проблем з цією архітектурою:

1. Механізм верифікації повинен чекати на повну остаточність перед відправленням повідомлення на контракт протоколу цільового ланцюжка. Це може зайняти до семи днів для L2s з оптимістичними періодами остаточності.
2. Одне міжланцюжкове повідомлення надсилається за кожною транзакцією моста АБО повідомлення пакуються разом, але пакет може бути надісланий лише після завершення останнього повідомлення у пакеті.
3. Міст має обмежену можливість забезпечувати зовнішню ліквідність для покращення цін користувачів, оскільки він повинен бути декларативним щодо шляху виконання наміру користувача.

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

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

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

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

Мінімально можлива намір полягає в замовленні на оплату токенів X з ланцюжка A для отримання токену Y на ланцюжку B.

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

Протоколи врегулювання намірів

Протоколи мостів на основі намірів можуть бути позначені точніше як протоколи розрахунку намірів, які відповідають за те, щоб розв'язувачі не порушували умови, вказані користувачем. Протоколи розрахунку намірів пропонують розв'язувачам безпеку, що їм буде віддано гроші та винагороджено за виконання намірів користувача. Для цього протоколи розрахунку намірів потрібно звернутися до оракула для перевірки автентичності виконання наміру. Безпека оракула може ґрунтуватися на оптимістичному періоді виклику, порозі свідків або базуватися на доказі валідності ZK, наприклад.

Протоколи вирішення намірів пропонують швидкий та дешевий переказ вартості, оскільки окремі розв'язувачі можуть приймати ризик остаточності та визначати оптимальні шляхи виконання

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

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

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

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

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

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

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

Архітектура, заснована на намірах, фундаментально розроблена для забезпечення безпеки

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

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

Таким чином, як виникає абстракція ланцюга з архітектури, заснованої на намірах?

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

Інтент користувача не потрібно надсилати на ланцюжок користувачем, якщо він включає Дозвіл2абоEIP3074підпис. Це правда як для мостів на основі передачі повідомлень, так і для мостів на основі намірів. Обидві архітектури можуть скористатися шаблоном Permit2, щоб дозволити користувачеві підписати поза ланцюжок кількість токенів, яку вони готові заплатити зі свого гаманця ланцюжка походження.

Ринки намірів найкраще підтримують абстракцію ланцюга, оскільки вони пропонують дешевий та швидкий міжланцюжковий переказ вартості. Уявіть світ, де користувач може запитати вирішувача надати їм котирування для входу в позицію стейкінгу WETH на Arbitrum, використовуючи їхній USDC на Optimism як оплату. Користувач може відправити цей намір позачергово на аукціон RFQ, де вирішувачі можуть зробити ставки на це. Виграшний вирішувач аукціону може отримати підписаний намір користувача, що містить дозвіл на витрату їхніх USDC на Optimism, їхню бажану кількість WETH для отримання на Arbitrum та calldata, необхідні для внесення цих WETH у позицію стейкінгу на Arbitrum. Після цього вирішувач може подати цю транзакцію на Optimism (від імені користувача), щоб запустити міжланцюжковий намір та зняти USDC з гаманця користувача на Optimism. Нарешті, вирішувач може виконати намір користувача на Arbitrum, надіславши їм WETH та переславши calldata, щоб ввести користувача в онлайн-позицію стейкінгу.

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

Архітектура наміру від Across

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

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

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

Як ми запускаємо мережу розв'язувачів?

Нам потрібно надати перевагу вирішувачу UX.

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

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

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

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

Вибір розв'язувачем мережі розрахунків за намірами вплине на його здатність пропонувати користувачам комісії та гарантії часу виконання. Деякі розрахункові мережі можуть пропонувати періоди ексклюзивності розв'язувачів, що підтримає розвиток офчейн-аукціонів, де розв'язувачі та користувачі могли б вести переговори та брати на себе зобов'язання сплачувати комісію за ретрансляцію. (Крім того, ці аукціони з намірами можуть пропонувати економічно обґрунтовані попередні підтвердження, що ще більше посилює UX. Щоб дізнатися більше про користувацький потік із виявленням намірів за допомогою аукціонів і попередніх підтверджень, рекомендую дискусія Картика від Sorella.)

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

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

Це очевидно, що нам потрібен стандарт для намірів міжланцюгової взаємодії

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

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

Цей стандарт наміру повинен дозволити замовнику наміру або розв'язувальнику вказати, на якій мережі розрахунків вони бажають здійснити свій намір.

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

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

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

///@titleТип перехресного ланцюгового замовлення

/// @noticeСтандартна структура замовлення, яку підписують обмінники, розповсюджують серед заповнювачів і подають на укладення угод про розрахунок

структура CrossChainOrder {

/// @dev Адреса контракту, якою має бути проведено розрахунок./// Відправники відправляють цей наказ на цю адресу контракту на початковому ланцюжкуадреса settlementContract;/// @dev Адреса користувача, який ініціює обмін,/// чиї вхідні токени будуть взяті та заставленіадреса swapper;/// @dev Число, яке слід використовувати як захист від повторного відтворення для наказуuint256 nonce;/// @dev Ідентифікатор ланцюжка походженняuint32 originChainId;/// @dev Мітка часу, до якої має бути ініційований наказuint32 initiateDeadline;/// @dev Мітка часу, до якої має бути виконаний наказ на цільовому ланцюжкуuint32 fillDeadline;/// @dev Довільні дані, конкретні для реалізації/// Може бути використаний для визначення токенів, сум, цільових ланцюжків, комісій, параметрів розрахунку,/// або будь-якої іншої інформації, специфічної для типу наказуbytes orderData;

}

Цей стандарт призначений для полегшення роботи розв'язувача. Одним із необґрунтованих виборів, який він робить, є підтримка Permit2/EIP3074 за допомогою nonce та initiateDeadline, і це дає наповнювачам деякі гарантії, такі як сума, яку вони будуть відшкодовані з розрахункової мережі, та формат наміру користувача, який вони можуть відстежувати. Крім того, в стандарті визначена функція-ініціатор, яка критично дозволяє наповнювачу, тому, хто буде приносити ордер ончейн, вказувати додаткові "fillerData" ончейн, про які користувач не знав би на момент підписання CrossChainOrder. Це дозволяє заповнювачу переконатися, що він винагороджений розрахунковим контрактом за подання мета-транзакції користувача, а також встановити специфічну інформацію про погашення, таку як ланцюжок погашення.

Цей стандарт також призначений для того, щоб зробити йому легше для dapps відстежувати стан виконання намірів протягом всього його життєвого циклу. Будь-який контракт поселення, який реалізує цей стандарт, повинен створити власний підтип ResolvedCrossChainOrder, який може бути розібраний з довільного поля orderData. Це може включати інформацію, таку як токени, що беруть участь у свопі, ланцюжок(и) призначення та інші обмеження виконання. У стандарт включена функція розв'язання, щоб дозволити dapps розуміти, як відображати статуси намірів користувачам і солверам знати точну структуру намірного замовлення, з яким вони працюють.

/// @titleТип ResolvedCrossChainOrder

///@noticeУніфіковане представлення реалізації замовлення

///@devВизначає всі вимоги до заповнення замовлення шляхом розбору індивідуальних даних замовлення, специфічних для реалізації.

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

структура ResolvedCrossChainOrder {

/// @dev Адреса контракту, якою має бути проведена вирішення.address settlementContract;/// @dev Адреса користувача, який ініціює обмітaddress swapper;/// @dev Число для використання як захист від повторного відтворення для замовленняuint256 nonce;/// @dev Ланцюжок початкового ланцюжкаuint32 originChainId;/// @dev Відмітка часу, до якого замовлення повинно бути ініційованеuint32 initiateDeadline;/// @dev Відмітка часу, до якого замовлення повинно бути заповнене на цільовому ланцюжку(ах)uint32 fillDeadline;/// @dev Вхідні дані, які мають бути взяті від swapper як частина ініціації замовленняInput[] swapperInputs;/// @dev Вихідні дані, які мають бути надані swapper як частина виконання замовленняOutput[] swapperOutputs;/// @dev Вихідні дані, які мають бути надані наповнювачу як частина вирішення замовленняOutput[] fillerOutputs;

}

///@notice Токени, надіслані своппером як вхідні дані для ордера

структура Введення {

/// @dev Адреса токена ERC20 на початковому ланцюжкуaddress token;/// @dev Сума токена, яка буде відправленаuint256 amount;

}

/// @noticeТокени, які мають бути отримані для виконання дійсного замовлення

struct Output {

/// @dev Адреса токена ERC20 на цільовому ланцюжку/// @dev Адреса(0) використовується як покажчик для внутрішнього токенуадреса токену;/// @dev Кількість токенів, які будуть відправленіuint256 сума;/// @dev Адреса для отримання вихідних токенівадресат;/// @dev Цільовий ланцюжок для цього виводуuint32 chainId;

}

Реалізація договору про врегулювання, що відповідає вимогам, ПОВИННА реалізовувати інтерфейс ISettlementContract:

///@titleISettlementContract

/// @noticeСтандартний інтерфейс для розрахункових контрактів

інтерфейс ISettlementContract {

/// @notice Ініціює врегулювання крос-ланцюжкового замовлення/// @dev Повинно бути викликано філлером/// @param order Визначення CrossChainOrder/// @param signature Підпис swapper над замовленням/// @param fillerData Будь-які filler-визначені дані, необхідні для поселенцяфункція ініціює (CrossChainOrder order, байти підпису, байти fillerData) зовнішня;/// @notice Вирішує конкретний CrossChainOrder в загальний ResolvedCrossChainOrder/// @dev Призначено для поліпшення стандартизованої інтеграції різних типів замовлень та договорів про врегулювання/// @param order Визначення CrossChainOrder/// @param fillerData Будь-які filler-визначені дані, необхідні для поселенця/// @returns ResolvedCrossChainOrder гідратовані дані замовлення, включаючи вхідні та вихідні дані замовленняфункція вирішує (CrossChainOrder order, байти fillerData) зовнішній вид повертає (ResolvedCrossChainOrder);

}

Цілями цього стандарту було поліпшення UX рішення, спрощення підтримки різних мереж розрахунків та детерміністичний розрахунок їхніх винагород. Я вважаю, що це дозволить їм надавати користувачам більш точні та впевнені цитати. Ви можете прочитати більше деталей про цей стандарт, кодове позначення якого ERC7683.у цьому X/Twitter пості та обговорення, яке його оточує на форумі Ethereum Magicians.

Заключні думки

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

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

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

Щоб нас розпочати, Across та Uniswap спільнопропонуючи стандартдля всіх учасників ланцюга постачання використовувати під час обробки замовлень користувачів для відправки токенів X з ланцюга A та отримання токенів Y на ланцюзі B. Потік замовлень, який працює через UniswapX (маючи порівняльну перевагу в дизайні аукціону та походженні намірів) та Across (маючи порівняльну перевагу в здійсненні виконання намірів), може об'єднатися і розпочати процес виховання більшої, більш конкурентоспроможної мережі розв'язувальників.

Disclaimer:

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