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

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

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

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

Давайте поринемо!

Вступ до намірів

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

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

• Досвід користувача — UX відчувається безперервним і зазвичай швидким. Користувачі висловлюють наміри, а розв'язувачі роблять решту. Абстрагування газу та інші функції зроблюють досвід більш плавним, ніж звичайні транзакції. Ліквідність Just-In-Time (JIT) означає, що більше не потрібно чекати хвилини на транзакції. У цілому, досвід на основі намірів менше перевантажує користувачів, генеруючи той самий «одноклік» ефект, який можуть надати користувачам більшість веб-2 додатків.
• Ефективність виконання — Розв'язувальники, які часто є професійними ринковими зробниками або командами протоколу, відповідають за виконання транзакцій для користувачів. Теза тут полягає в тому, що спеціалізовані розв'язувальники краще підготовлені для побудови транзакції для оптимального виконання onchain, ніж базовий контракт AMM або кінцевий користувач, який навігує по кількох додатках. Пакетування транзакцій та інші функції, такі як відповідність замовлень, роблять виконання намірів більш капіталоефективним. Для користувачів: немає більше дурних помилок, втрачених ресурсів та неприємного onchain досвіду для користувачів. Для додатків: немає більше залежності від простих, неефективних з газом контрактів для складних транзакційних шляхів. Для LPs: немає більше латентної ліквідності, яка лежить у застарілих on-chain контрактах.

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

З намірами, це вирішувачі все дорогою вниз

Протоколи на основі намірів мають три основні частини:

• Intent Expression — Користувачі вказують бажаний результат у програмі. Наприклад, на мосту користувач може сказати, що вони хочуть обміняти 1 ETH на Arbitrum на 1 ETH на Optimism.
• Виконання наміру — Розв'язувачі, які беруть участь в аукціонах, визначають найефективніший спосіб виконання наміру користувача. Переможець (наприклад, Релеєр в Across) виконує запит (надсилає 1 ETH користувачеві на Optimism).
• Розрахунок наміру — Розв'язувальник отримує оплату за свою послугу (наприклад, отримання 1 ETH користувача на Arbitrum + невелика комісія). Протокол наміру доводить, що намір був виконаний. Однак це лише один аспект розрахунку. Більш широка картина полягає в тому, що розрахунок наміру також сприяє перебалансуванню капіталу між ланцюжками та активами для розв'язувальників.

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

Корінь централізації з намірами

Розв'язувачі - це основа протоколів на основі наміру. Вони є сутностями, які фактично виконують намір користувача, такі як доставка активу на ланцюг A з ланцюгу B.

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

• Вимоги до стейкінгу - Деякі протоколи на основі намірів мають вимогу до стейкінгу для участі розв'язувальників у їх аукціонах по потоку замовлень. Наприклад, в 1inch Fusion, топ-10 розв'язувальників (називаютьрозв'язувачі) допускаються до участі в аукціонах. Ці розв'язувачі ранжируються та включаються до білого списку на основі їх 'единорогової потужності', яка є метрикою, визначеною за їхніми заставленими токенами 1inch (самими розв'язувачами або їх делегатами) та тривалістю їхньої застави. Ці вимоги до застави існують для запобігання зловживанням, що є хорошою річчю. Проблема? Ці застави можуть стати значним бар'єром для вступу, особливо для менших гравців, які можуть не мати капіталу наперед.
• Системи з дозволом - Багато протоколів, спрямованих на наміри, мають дозвіл, що означає, що є воротарі, які вирішують, хто може брати участь. Наприклад, у випадку 1inch Fusion доступ базується на силі єднорога, тоді як у інших системах, таких як UniswapX Бета, участь може вимагати бути включеним до списку відбору протоколу, який виконує аукціон. Ці системи надають перевагу якості виконання, забезпечуючи, що можуть брати участь лише надійні розв'язувачі. Цей підхід допомагає протоколу забезпечити плавний і надійний користувацький досвід, надаючи користувачам впевненість у якості виконання. Однак, хоча дозвіл природи має свої переваги, він також обмежує доступ до аукціонів для ширшого кола розв'язувачів.
• Вартість складності - Розв'язувачі постійно потребують перебалансування для задоволення міжланцюжкових намірів. Більше того, кількість ланцюгів зростає, що ускладнює завдання розв'язувачів зберігати запаси через ланцюги, перебалансувати й утримувати вірні активи в екосистемі, де L3 може стати популярним ночівлею, або L2 може вирішити закритися наспіх. Є також проблема крихкості. Протоколи на основі намірів є відносно новими рішеннями на ринку і постійно розвиваються, оскільки з'являються нові випадки на межі. Це вимагає частіших оновлень з боку розв'язувача, додаючи ще один шар складності.
• Високі постійні витрати - Написання складного коду, управління спеціалізованими інтеграціями для кожного протоколу на основі намірів, підтримка інвентаризації активів по всім ланцюгам, вирішення проблем з витратами RPC, підтримка спеціалізованого обладнання для перемоги в змаганнях за швидкістю - це лише деякі перешкоди, які додають ще один рівень складності та витрат для розв'язувачів.
• Стимули та відсутність потоку замовлень – Розв'язувачі, будучи раціональними акторами, не працюють на благодійність. Їм потрібно бачити повернення від своїх інвестицій, щоб виправдати свою участь. Несучи ризики — такі як витрати, складність та ризиковані кошти — слід компенсувати вищими прибутками. Інакше очікувана вартість може бути недостатньо привабливою, щоб виправдати зусилля. Наразі ландшафт намірів має дуже мало застосувань з достатнім потоком замовлень, щоб робота була варта того для розв'язувачів (порівняйте обсяг та потенційну прибутковість з клопотом інтеграції). Тому, хоча додатки з значним потоком замовлень (1inch, CoWswap, UniswapX, Across) бачать достатню участь та конкуренцію розв'язувачів, інші додатки мають проблеми з привертанням достатньої кількості розв'язувачів через низький потік замовлень.

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

Наприклад, давайте розглянемо два показники для протоколів на основі намірів: Cowswap для намірів обміну та Across для намірів міжланцюжкового зв'язку:

Cowswapмає конкурентний аукціон з 16 незалежними розв'язувачами, які змагаються за замовлення користувачів. Жоден окремий розв'язувач не домінує, і жоден з розв'язувачів не керується командою CoWswap.

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

Розподіл потоку замовлень серед релеїв Across. Примітка: Risk Labs працює з розв'язувачами, позначеними зеленим і темно-сірим кольорами на вищевказаній діаграмі. Джерело: Внутрішні дані Across.

Тим часом більшість інші протоколи на основі намірівлише має розв'язувачі, які або добре капіталізовані ринкові зробники ( Привіт, Wintermute!) або сама команду протоколу (яка має зацікавленість у виконанні намірів користувачів, зібраних у їх додатку).

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

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

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

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

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

У наступному розділі ми детальніше розглянемо деякі нові рішення, які спрямовані на спрощення життя розв'язувачів на кожному етапі системи на основі наміру. Більше розв'язувачів, більше задоволення, чи не так?

Стандартизація виразу наміру — ERC-7683

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

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

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

Для вирішення цих питань Uniswap Labs та Across запропонувалиERC-7683, стандартизований формат для намірів міжланцюжкового взаємодії. Цей стандарт пропонує кілька переваг:

• Спрощене інтегрування — Розв'язувачам потрібно розуміти лише один формат, щоб виконати наміри з будь-якого протоколу, сумісного з ERC-7683. Це значно знижує бар’єр для нових розв'язувачів.
• Універсальна мережа існуючих вирішувачів — Додатки можуть підключатися до вже існуючої мережі вирішувачів, що усуває необхідність будувати та підтримувати власну. Це також збільшує конкуренцію серед вирішувачів для виконання намірів, що потенційно може призвести до зниження комісій для користувачів.

Багато протоколів інфраструктури на основі рішень, наприклад,Кхалані, Номінальний, прагнуть бути сумісними зі стандартом ERC-7683. Це багатообіцяюча розробка, яка є безпрограшним сценарієм для всіх зацікавлених сторін – програми, засновані на намірах, такі як UniswapX, виграють від збільшення кількості розв'язувачів, які конкурують за потік замовлень, тоді як розв'язувачі в цих протоколах інфраструктури отримають негайний доступ до більшого потоку замовлень з дня

1. Ця сумісність має кілька великих переваг:

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

Проте є також деякі потенційні недоліки та обмеження, які можуть ускладнити загальні переваги та прийняття ERC-7683:

• Можливість конкуруючих стандартів – проблема стандартів полягає в тому, що важко керувати стимулами серед усіх учасників екосистеми. Якщо стандарт не вбудований на рівні протоколу самим ланцюжком, виникають питання, чи він дійсно служить як загальнодоступне благо, яке рівно користується всіма. У випадку ERC-7683 можна стверджувати, що Across та Uniswap мають більше вигоди від його прийняття, як з маркетингової точки зору, так і як ранні прихильники, що визначають стандарт. Ми бачили подібні перешкоди з мостовими стандартами в минулому, такими як стандарт xERC-20, пов'язаний з брендом Connext, або стандарт OFT, пов'язаний з LayerZero Labs, ілюструють подібні перешкоди. Незважаючи на зусилля визначити стандарт як вірогідно нейтральний, залишаються сумніви, чи деякі сторони занадто вигідно скористаються. Цей скептицизм часто призводить до створення конкуруючих стандартів, що підриває саму мету встановлення єдиного стандарту.

Проблема стандартів - завжди буде більше одного.

• Динаміка ринку рішень насправді може погіршитися - ERC-7683 повинен забезпечити створення рівного поля гри, де нові та існуючі рішення можуть конкурувати чесно. Якщо стандарт веде до створення динаміки ринку, де більш капіталізовані рішення, такі як Wintermute, виграють більшість замовлень, то слід задати собі питання, чи дійсно є користь в цьому взагалі.
• Стандарт охоплює лише Ethereum та екосистему EVM – Програми на основі намірів не обмежені Ethereum та широкою екосистемою EVM. Сьогодні Solana постійно робить більше обсягів, ніж Ethereum та його L2s щоденно та щомісяця. Потрібно врахувати, щоб зробити цей стандарт нейтральним до ланцюжка та екосистеми, хоча це зробило б зусиль для координації ще більше.
• Стандарт охоплює лише крос-ланцюжкові перекази та лімітні заявки – ERC-7683 в основному спрямований на крос-ланцюжкові наміри. Це спрямування може обмежити його застосування до інших форм намірів, потенційно обмежуючи його корисність для широкого спектру використання в екосистемі протоколу, заснованого на намірах. Однак важливо врахувати тезу Across: вони вважають, що більшість крос-ланцюжкових дій будуть простими переказами, а не складними багатоетапними діями. Ці дії зазвичай передбачають початковий крос-ланцюжковий переказ, який слідує подальшому виконанню на призначеному ланцюжку. У суті, стандарт спрямований на найпоширеніший крос-ланцюжковий випадок використання: перекази. І його можна використовувати разом з одноланцюжковими діями для виконання різних намірів, а не для того, щоб стандарт сам по собі охоплював всі можливі наміри.

Спільна робота з розв'язувачем для виконання намірів — платформи, такі як Khalani

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

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

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

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

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

Джерело: Представляємо Калані

Як Кевін Ванг (співзасновник Khalani)описує: Khalani - це платформа для вирішення взаємодії «Coincidence of Can-do». Співпраця дозволяє розбивати складні наміри на менші спеціалізовані наміри (або компоновані наміри), більш керовані частини, які можуть обробляти окремі вирішувачі.

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

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

Давайте скажем, що ... Боб, користувач Ethereum з USDC, хоче ETH на Arbitrum та використовує міст на основі наміру.

Ось як розв'язувач може використовувати Khalani для виконання цього наміру:

1. Боб подає свою наміру: "Я хочу ETH на Arbitrum в обмін на USDC на Ethereum".

2. Міст на основі намірів вибирає виключного рішення для виконання наміру Боба, давайте назвемо цього рішення, Рішення A - обране.

Однак Solver A вичерпує запаси на Arbitrum для виконання наміру Боба і вирішує використати пул розв'язувачів Khalani для фронтового капіталу.

1. Розв'язувач A відправляє намір до Халані, щоб попросити іншого розв'язувача (або комбінацію розв'язувачів) фронтовати капітал на Arbitrum в обмін на заблоковані кошти Боба на Ethereum.

2. Інший розв'язувач, Розв'язувач B (Арбітражний кит Арбітр) , який утримує інвентар на передових позиціях Арбітра, передає бажані активи Бобу на Арбітрі.

3. Користувач - вирішення рішення - Як тільки Розв'язувач B завершить запит Боба, Розв'язувач A здійснює розрахунок з користувачем, надавши доказ розрахунку платформі, яка у цьому випадку є містом на основі наміру. В результаті Розв'язувач A отримує USDC Боба на Ethereum.

4. Розв'язувач - розв'язувач врегулювання - Розв'язувач A врегулював з Розв'язувачем B, представивши доказ виконання ланцюга Халані.

Це лише спрощений приклад того, як рішення може співпрацювати на Khalani, щоб виконати наміри, Khalani може виконати більш складні наміри за тим самим процесом.

Наприклад, Боб, користувач Ethereum з USDC, хоче внести ETH на платформу кредитування на Arbitrum.

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

• Рішення A (експерт з ціноутворення) - запускає спеціалізоване програмне забезпечення для пошуку найточніших цін на торгівельні пари в тій самій ланцюжку або між ланцюжками. Це може бути використано для встановлення ціни на ліквідність USDC / ETH на основі як ончейн, так і офчейн інформації.
• Solver B (Arbitrum whale) – утримує запаси на Arbitrum, які можуть бути використані для фронтування бажаної кількості ETH на Arbitrum.
• Solver C (виконавець Ethereum) - спеціалізується на здійсненні найкращого виконання на Ethereum, пропонуючи варіанти угод ціна/затримка для користувача. Його можна використовувати для виконання транзакції з метою забору депозитів користувача на Ethereum.
• Вирішувач D (виконавець Arbitrum) - спеціалізується на виконанні транзакцій на Arbitrum. Це можна використовувати для виконання локальної транзакції для внесення ETH на кредитну платформу на Arbitrum.

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

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

• Помилка користувача при поданні наміру — Коли інтерфейс програми розроблений для збору конкретних намірів (наприклад, обмін або місткування), обсяг помилок користувача обмежений, оскільки користувач працює в межах певних вказівок для подання свого наміру. Однак розробка інтерфейсу для збору узагальнених намірів може бути складнішою та схильною до помилок користувача, оскільки користувач може подати неправильний або неповний намір, що призводить до невдалих або неправильних виконань намірів.
• Ризики життєздатності – з інтент-системами існує ризик відсутності живої робочої сили, що може зупинити весь систему. Крім того, можливо, рішення можуть невірно виконувати свої завдання або не вчасно, що може призвести до невдалих транзакцій.
• Обмежена доступність розв'язувачів - У Іnfrastructure Khalani може бути обмежена кількість розв'язувачів для різних типів намірів. Це може зменшити можливість та загальну ефективність виконання наміру.
• Складність координації вирішувачів-вирішувачів – Координація декількох вирішувачів може бути складною та схильною до помилок через множину рухливих факторів, таких як наявність спеціалізованого вирішувача, ринкові умови, а також фактори, пов'язані з самим наміром, як-от залучені ланцюжки, розмір потрібного капіталу та інше.
• Ризики, пов'язані з атомним виконанням намірів - Усі дії розв'язувачів є атомними та виконуються разом на ланцюгу Khalani. Це означає, що розв'язувачі переживають атомність на Khalani, тобто або всі частини потоку успішно виконуються в одній дії, або ні. Якщо будь-яка частина транзакції не вдається, вся транзакція скасовується, що може призвести до високої частоти невдачі замірів. Однак тут немає ризику застряглого капіталу або втрати коштів.
• Solver collab додає затримку - під час виявлення співпраці, яка відбувається поза ланцюжком блоків, і є майже миттєвою, існує додаткова затримка через такі фактори, як:

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

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

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

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

ERC 7683 x Калані Flywheel

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

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

Ефективне урегулювання капіталу з наміром — прошарки розчищення, подібні до Everclear

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

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

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

Ключовим аспектом цінності Everclear є концепція узгодження.

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

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

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

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

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

Джерело: Представляємо Everclear

Everclear вважає, що ~80% щоденних потоків до та від ланцюгів можна скоротити.Це означає, що за кожен $1, який щодня перекладається на середній ланцюг, $0.80 перекладається назовні. Це означає, що загалом через мости надсилається в 5 разів більше обсягу, ніж потрібно, і розв'язувачі перебалансовуються між ланцюгами значно більше, оскільки вони працюють в ізоляції.

Спробуємо зрозуміти, як користувачі (протоколи, спрямовані на наміри, розв'язувачі або CEXs) використовували б стек Everclear.

Розгляньте приклад Еліс, розв'язувача, який віддає перевагу вирішенню на Arbitrum. Елісу потрібно заповнити транзакцію на суму 10 ETH з Optimism на Arbitrum. Ось як працюватиме потік з та без Everclear:

Ми бачимо, що переваги розчищувального шару, як от Everclear для його користувачів (вирішувачі, MMs) як Аліса є:

• Уподобання поселення - Аліса віддає перевагу поселенню на Арбітрумі, а Еверклір гарантує, що вона отримує відшкодування на Арбітрумі, відповідно до її уподобань.
• Немає потреби в перебалансуванні - Без Everclear Алісі потрібно буде перевести 10 ETH з Оптимізму на Арбітрум, щоб перебалансувати. З Everclear цей крок вилучається, що зберігає час та ресурси. З Everclear обробка перебалансування стає загальним потоком роботи простішою. Це може бути особливо привабливим для нових учасників, щоб приєднатися до пулу розв'язувачів.
• Зменшення операційних витрат - Шляхом усунення потреби в ручному перебалансуванні Everclear зменшує операційні витрати для Еліс, дозволяючи їй зосередитися на вирішенні більше транзакцій.
• Заощадження витрат – Уникнення потреби у мості між ланцюгами може зекономити на комісіях за транзакції та потенційному зриву, зробивши процес більш ефективним з точки зору витрат для Еліс. Це також може призвести до більш систематичної роботи та потенційно вищого доходу для розв'язувачів проблем.

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

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

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

Щоб це було можливо, 'Everclear' розроблений якArbitrum Orbitrollup використовуючиEigenDAу партнерстві зGelato RaaS’. На момент запуску альфа-основної мережі (заплановано на початок третього кварталу 2024 року), Everclear буде працювати під певними обмеженнями та захисними бар'єрами:

• Підтримка активів та ланцюгів з дозволеного доступу - спочатку підтримуються лише ланцюги та активи, які знаходяться в списку дозволених, що обмежує відкритість та можливість використання системи. Проте планується зробити обидва дозволеними у майбутньому.
• Надійність на Eigenlayer - Everclear покладається на Eigenlayer для забезпечення безпеки, але наразі він не підтримує відлучення. Це обмежує економічну безпеку до тих пір, поки не буде впроваджено відлучення. Користувачам доведеться довіряти тому, що Eigenlayer в майбутньому впровадить відлучення, щоб підвищити економічну безпеку. Однак до впровадження відлучення Everclear планує використовувати набір валідаторів ISM Hyperlane для забезпечення безпеки.
• Everclear буде запущений з можливістю оновлюваних розумних контрактів - Хоча оновлювані контракти дозволяють гнучкість, вони також несуть ризики, якщо не керувати ними належним чином, наприклад, можливість використання під час оновлень.

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

Крім того, існують певні потенційні ризики та припущення довіри, пов'язані з Everclear як кліринговим механізмом:

• Помилки системи – Відсутність життєздатності або відключення під час оновлень можуть нарушити процес розрахунку, що призведе до затримок або невірних вирішень. Це вплине на роботу всіх користувачів, які використовують Everclear. Часові вікна для розрахунків Everclear оцінюються приблизно кожні 3-6 годин, що означає, що на роботу користувачів вплине лише тривала відключеність. Крім того, якщо такі відмови відбуваються протягом тривалого часу, основний вплив буде на UX, а не на безпеку коштів. Це через те, що в Arbitrum Nitro є вбудована можливість «примусового оновлення». Якщо відбувається відключення, користувачі можуть скористатися цією функцією, щоб вийти з транзакцій на L1, забезпечуючи відсутність можливості цензурування користувачів.
• Залежність від ринкових маркерів для ролі арбітражників - Everclear намагається урівноважити розрахунки між розв'язувачами (через чистку) в разі можливості. Однак, якщо чистка не вдається, вони звертаються до арбітражників, щоб купити рахунки розв'язувачів. Це створює залежність від ринкових маркерів, які повинні постійно купувати ці рахунки, хоча зі знижкою. Щоб розпочати систему, Everclear активно співпрацює з великими ринковими маркерами, щоб виконати цю важливу роль.
• Динаміка аукціонів - залежність від аукціонування рахунків арбітражникам, якщо неттінг неможливий з будь-якої причини, такої як відсутність розв'язувачів в системі, може викликати волатильність та непередбачуваність у виплатах. Однак команда Everclear вважає, що цей вплив повинен бути керованим завдяки двом ключовим факторам:

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

2) запуск з активним та ліквідним пулом арбітражників забезпечить конкуренцію та потенційно стабільні ціни під час аукціонів.

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

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

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

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

На LI.FI ми розробили широку дистрибуцію 250+ додатків, гаманців, онрампів та інших протоколів DeFi, які інтегрували наш продукт. Ми безпосередньо торкаємося фронтендів, де користувачі виражають найбільш поширені наміри - обміни, трансфери між ланцюгами та багатокрокові дії, такі як замки. Ця унікальна точка зору дозволяє нам захоплювати значення, створене на рівні виявлення намірів.

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

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

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

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

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

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