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

Вступ

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

За допомогою технології OP Stack одна з торгових платформ запустила свою мережу Рівень 2 Base, а інша платформа представила 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, через додавання специфічних спільних сортувальників та кросчейн-мостів для допомоги в забезпеченні спільної ліквідності та стану Rollup, побудованих на OP Stack. Це має на меті вирішити проблему ліквідності та розподілу стану на більш високому рівні. Тут є більш детальний аспект, що стосується окремого дизайну спільного сортувальника, це рішення більше орієнтоване на Рівень 2 і не є універсальним.

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

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

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

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

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

У двох наведених категоріях ми можемо побачити, що відповідно до структури торта, Settlement Layer є найатомарнішим рівнем рішення, а над цими атомарними рішеннями, такими як міжланцюгові, oracle, 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 мільйонів доларів у раунді початкового фінансування.

Мережа Khalani

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

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

ERC-7683

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

Стек ### OP

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

Серед них найбільш типовими є