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

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

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

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

Шар розрахунків (Settlement Layer)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Розв'язання проблеми крос-чейн ліквідності є дуже складною та багатогранною областю. Рішення Рівня 2 поділяються на ті, що вбудовані в Ethereum для крос-чейн повідомлень, зокрема ERC-7683, а також Рівень 2, такі як OP, що будують OP Stack для спільного використання Sequencer. Виходячи за межі контексту Рівня 2, всі Рівні 1 також стикаються з проблемами ліквідності, стану та розриву користувацького досвіду. Є спеціалізовані рішення, орієнтовані на ліквідність, а також рішення з використанням Solver Network, а також подібні до NEAR рішення, що базуються на облікових записах, проте вони також потребують базування на ролі таких рішень, як Solver.

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