Дослідження проблеми ліквідності в епоху Layer2

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

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

Майбутнє, безумовно, буде епохою співіснування багатьох ланцюгів. Хоча ці ланцюги Layer 2 можуть вибрати сумісність з EVM для забезпечення взаємодії, через наявність великої кількості додатків нижнього рівня у 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 тут змагається за надання кращого досвіду для користувачів, включаючи швидший час торгівлі та швидкість виконання. На цій основі проекти на основі намірів, такі як Anoma, розробили різноманітні рішення, що керуються намірами. Подібні похідні від намірів, такі як компонент Predicate, можуть реалізувати наміри користувачів відповідно до певних правил.

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

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

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

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

Рішення

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

1. Орієнтація на RaaS: подібно до рішення Rollup, такого як OP Stack, шляхом додавання специфічних спільних сортувальників та крос-ланцюгових мостів для сприяння спільної ліквідності та стану Rollup, побудованого на OP Stack. Це має на меті вирішення проблеми ліквідності та розподілу стану на більш високому рівні. Тут є більш детальний аспект, який стосується окремого проектування спільних сортувальників, це рішення більше орієнтоване на Layer2 і не має універсальності, такі як Astria, Espresso та ін.

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

3. Зосередженість на мережі поза ланцюгом: це те, що ми маємо на увазі під "вступним" графіком архітектури торта Solver Network, де основна ідея полягає в тому, що користувач надсилає наміри до мережі Solver, а роль Solver полягає в конкуренції за пропозиції, надаючи найкращий час виконання та ціну угоди. Цими Solver можуть бути AI Agent, CEX, Market Maker або навіть інтегровані протоколи, такі як Liquorice тощо. Проекти в цій сфері включають Anoma, Khalani, Enso, aori та Valantis. Хоча наміри теоретично можуть реалізувати складні крос-ланцюгові операції будь-якої складності, на практиці дійсно необхідно мати достатню Ліквідність Solver для допомоги, а також, коли виникають деякі поза ланцюгові запити, існує можливість шахрайства з боку Solver. Якщо впровадити методи, такі як шахрайські докази, складність реалізації мережі Solver зросте, а поріг входження для запуску Solver також стане вищим.

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

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

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

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

INFINIT

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

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

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

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

Лакриця

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

Xion

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

=нуль; Фонд

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

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

ERC-7683

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