Дослідження проблеми ліквідності обдурювання людей, як лохів в епоху Рівня 2

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

Завдяки OP Stack, одна торгівельна платформа запустила свій власний Рівень 2, інша торгівельна платформа випустила Ink; завдяки ZK технології, одна торгівельна платформа представила XLayer; Sony випустила Soneium, LINE запустила Kaia тощо. Сьогодні, капітальні та технологічні бар'єри для створення ланцюга значно знижені, витрати на експлуатацію ланцюга на базі OP Stack складають приблизно 10,000 доларів на місяць.

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

Поточна багатоланкова екосистема створила новий виклик: Ліквідність та розподіл стану. Оскільки існування багатоланковості є неминучим, то міжмережна взаємодія є областю, яку необхідно досліджувати та вирішувати. Наразі існує багато рішень для Ліквідності, таких як абстракція ланцюга, наміри, Clearing Execution, Native CrossChain, ZKSharding тощо, але їхня основна суть однакова.

Ми використовуємо визнану в галузі архітектуру Cake, щоб зверху вниз представити основні компоненти абстракції міжланцюгової передачі:

Рівень застосунків (Application Layer)

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

Шар дозволів (Permission Layer)

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

Управління обліковими записами та абстракція ключів (Key Management and Account Abstraction)

У зв'язку з наявністю багатьох ланцюгів, потрібна система управління обліковими записами та абстракцій, яка адаптується до різних ланцюгів, щоб підтримувати унікальну структуру облікових записів кожного з них. Наприклад, об'єктно-орієнтована система облікових записів SUI абсолютно відрізняється від EVM. One Balance є представницьким проектом у цій сфері, він створив надійну систему облікових записів, не вимагаючи створення міжланцюгового консенсусу, а лише довірчих зобов'язань між існуючими системами облікових записів. Near Account реалізує абстрактне управління, генеруючи мульти-ланцюгові гаманці для користувачів, що значно оптимізує досвід користувачів і зменшує фрагментацію UX. Однак, у сфері ліквідності в основному інтегровано існуючі публічні ланцюги.

Рівень вирішення (Solver Layer)

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

Рівень розрахунків (Settlement Layer)

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

• Оракул (Oracle): використовується для отримання інформації про стан на інших ланцюгах.
• Крос-чейн мости (Bridges): відповідають за передачу інформації та ліквідності між різними блокчейнами.
• Попереднє підтвердження (Pre-Confirmation): скорочення часу підтвердження між ланцюгами.
• Доступність даних (DA): забезпечує доступність даних.

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

Рішення

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

1. Центр на RaaS: подібно до рішень Rollup, таких як OP Stack, шляхом додавання специфічних спільних сортувальників та міжланцюгових мостів для сприяння спільній ліквідності та стану, побудованим на OP Stack. Це має на меті вирішення проблеми розподілу ліквідності та стану на більш високому рівні. Тут є більш детальне рішення — окремий дизайн спільного сортувальника, яке більше орієнтоване на Рівень 2 і не є універсальним.

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

3. Орієнтація на мережу намірів поза ланцюгом: суть в тому, що користувач надсилає намір до мережі Solver, роль Solver полягає в конкуренції за цінові пропозиції, надаючи оптимальний час виконання та ціну交易, ці Solver можуть бути AI Agent, CEX, Market Maker або навіть інтегрованим протоколом. Хоча намір теоретично може реалізувати будь-які складні крос-ланцюгові операції, на практиці необхідно мати достатню ліквідність Solver для допомоги, і коли виникають певні потреби поза ланцюгом, існує можливість шахрайства з боку Solver, якщо впроваджуються такі методи, як докази шахрайства, реалізація мережі Solver стане ще складнішою, а поріг входження для роботи з Solver буде ще вищим.

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

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

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

У двох вище згаданих категоріях ми можемо побачити, що відповідно до структури торта, Settlement Layer є найатомарнішим рішенням, над яким будується більш абстрактний рівень, такий як Solver Layer, Permission Layer і Application Layer, над такими атомарними рішеннями, як міжланкові, оракули, Pre-Confirmation рішення тощо. Різні рівні, які ми навели вище, що будуються в різних напрямках для створення абстрактних або ліквіднісних рішень, можна розуміти як відносини між верхньою і нижньою частинами. Але ці рішення все ще не є атомарними рішеннями, і вся проблема розриву ліквідності призвела до виникнення багатьох складних похідних проблем, тому для міжоперабельності виникло безліч різноманітних рішень. Але в основному все ще потрібно покладатися на ці компоненти. Далі ми обговоримо кілька типових проектів концепцій абстракції ланцюга, щоб подивитися, як кожен з них вирішує проблему розриву ліквідності з власної точки зору.

INFINIT

INFINIT створив сервіс RaaS для DeFi, який може надати компоненти, необхідні для безпосереднього будівництва DeFi-протоколів, такі як Oracle, Pool Type, IRM, Asset тощо, а також може запропонувати компоненти, які можна негайно активувати, такі як Leverage Trading та Yield Strategy. Це еквівалентно іншим додаткам для будівництва, але фінальна ліквідність розміщується на ліквідності Infinit. Проте наразі не було розкрито принципи роботи підкладки. Наразі INFINIT вже отримав 6 мільйонів доларів у рамках посівного фінансування від певних інвестиційних установ.

Мережа Халані

Khalani побудував три основні компоненти: шар сумісності Intent, Validity та загальний розрахунковий шар.

Зовнішні додатки або рівень намірів можуть публікувати наміри Khalani, а потім сумісний рівень намірів Khalani може перетворити зовнішні наміри в формат, який може розпізнати протокол Solver, використовуючи нормалізований формат, який називається мовою Validity. Вузол Khalani відповідає за подання остаточних результатів до універсального рівня розрахунків через міжланцюговий міст, технології швидкого розрахунку тощо. Цей проект все ще знаходиться на стадії будівництва, і подробиці роботи поки що не розкрито. У серпні він отримав 2,2 мільйона доларів США в рамках початкового фінансування від деяких інвестиційних установ.

Лікериця

Liquorice є децентралізованим додатком, який забезпечує виявлення цін на основі аукціонів та односторонні ліквідні пулу. Основна місія Liquorice полягає в наданні професійним торговим компаніям ефективних інструментів управління запасами та легкому з'єднанні з основними DeFi протоколами під час розрахунку угод за наміром використання. Тим часом, Liquorice створила ринок кредитування для проведення кредитних угод. Цей додаток більше зосереджений на самій угоді. Наразі він ще знаходиться на стадії розробки, у липні було оголошено про залучення 1,2 мільйона доларів у раунді фінансування Pre-seed під керівництвом певної інвестиційної установи.

Сіон

Xion є оновленою версією бренду Burnt, який раніше був зосереджений на споживчих додатках. Пізніше команда виявила, що існує величезна проблема фрагментації в ланцюгових взаємодіях, тому було створено Xion для покращення цієї проблеми. Xion побудовано на основі консенсусного протоколу Comet BFT. Використана крос-ланцюгова комунікація базується на Cosmos IBC, тому вона є більш рідною та безпечною, ніж інші крос-ланцюгові мости. Вона пройшла чотири раунди фінансування та отримала підтримку від декількох інвестиційних установ.

=nil; Фонд

nil є ринком ZK обчислювальної потужності Ethereum, ZK ко-процесором та розробником Рівня 2, команда має глибокі знання в технології ZK. Вони запропонували рішення zkSharding, яке використовує технологію ZK для горизонтального масштабування основної мережі Ethereum, виконання паралельної обробки транзакцій та генерації ZKP, в той час як основний фрагмент перевіряє дані, спілкується з Ethereum та синхронізує стан мережі між усіма валідаторами. Основний фрагмент також керує розподілом валідаторів та рахунків у виконавчих фрагментах. Консенсусний протокол, що використовує комітет перевірки, також є Hotstuff, що є поширеним у новітніх проектах паралельного виконання. =nil; L2 з самого початку вбудував міжфрагментну комунікацію в протокол. Міжфрагментні повідомлення перевіряються комітетом валідаторів кожного фрагмента як транзакції.

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

ERC-7683

Ethereum також працює над вирішенням цієї проблеми крос-ланцюгової ліквідності, наразі деякі відомі проєкти спочатку відкрито підтримують стандарт ERC7683, який також використовує крос-ланцюговий підхід на основі Intent. Його основна мета полягає в створенні загального стандарту для крос-ланцюгових операцій між L2 і бічними ланцюгами, стандартизації замовлень і розрахункових інтерфейсів, що забезпечує безшовне виконання крос-ланцюгових транзакцій. Основна суть полягає в тому, що Filler, також можна сказати, виконує роль Solver у абстракції ланцюга. Цю пропозицію спільно розробили деякі відомі проєкти, в даний час вона розглядається робочою групою Cake.

Стек ### OP

OP Stack, ERC-7683 та zkSharding є рішеннями для фрагментації ліквідності між Layer 2 в межах Ethereum, які вирішуються на архітектурному, консенсусному та прикладному рівнях відповідно. OP Stack розроблений як повноцінне рішення для кількох Layer 2, щоб одноразово вирішити проблеми передачі інформації та децентралізації Sequencer. Коли ви використовуєте архітектуру OP Stack, автоматично розгортається крос-чейн контракт, а також існує Supervisor, щоб оскаржувати та уникати передачі неправдивої крос-чейн інформації. Наразі кілька відомих торгових платформ і проектів використовують архітектуру OP Stack.

Серед них, найбільш типовим є Unichain. Unichain в основному працює через співпрацю з