Дослідження проблеми ліквідності обдурювання людей, як лохів в епоху Рівня 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)

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

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

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

Рішення

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

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

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

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

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

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

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

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

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

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

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

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

Ще один проект - це ринок ZK потужностей Ethereum, ZK супутні процесори та розробники Layer2, команда має глибокі знання технології ZK. Був запропонований розв'язок zkSharding, який використовує технологію ZK для горизонтального масштабування основної мережі Ethereum, виконує паралобробку транзакцій та генерує ZKP, тоді як основний шард верифікує дані, спілкується з Ethereum і синхронізує стан мережі між усіма валідаторами. Основний шард також управляє розподілом валідаторів і рахунків у виконавчих шардах. Консенсусний протокол, що використовується в комітеті верифікації, також є Hotstuff, що є поширеним у останніх проектах паралельного виконання. Цей проект L2 з самого початку вбудував крос-шардову комунікацію в протокол. Крос-шардові повідомлення верифікуються комітетом верифікації кожного шару як транзакції.

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

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

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

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