Стаття взята з: Gate Ventures
Вступ
Відтоді, як Ethereum перейшов на рішення з акцентом на Layer 2, разом із зростанням інструментів, таких як RaaS, багато публічних ланцюгів швидко розвиваються. Багато суб'єктів хочуть створити свої ланцюги, щоб представляти різні інтереси та шукати вищу оцінку. Однак поява багатьох публічних ланцюгів ускладнює розвиток екосистеми, внаслідок чого багато проектів зазнають збитків під час TGE.
Завдяки OP Stack, Coinbase запустила свій Base Layer 2, Kraken випустив Ink; завдяки технології ZK, OKX запустив XLayer; Sony випустив Soneium, LINE випустив Kaia тощо. Сьогодні вартість і технічний поріг для створення ланцюга значно знизилися, витрати на експлуатацію ланцюга на основі OP Stack складають приблизно 10,000 доларів на місяць.
Майбутнє обов'язково буде епохою спільного існування багатьох ланцюгів. Хоча ці Layer 2 можуть вибрати сумісність EVM для забезпечення взаємозв'язку, через величезну кількість downstream додатків, що стоять за ними, їм важко будувати додатки на одному ланцюзі та досягати консенсусу.
Розподіл TVL, джерело: Defillama
Сучасна багатоланцюгова екосистема створила новий виклик: розподіл ліквідності та стану. Оскільки наявність багатьох ланцюгів є неминучою, міжопераційність є областю, яку необхідно дослідити та вирішити. Наразі існує багато рішень для ліквідності, такі як абстракція ланцюга (Particle Network, Socket, XION, INFINIT, Borsa), намір (Anoma, Khalani), Clearing Execution (Connext), Native CrossChain (Cross), ZKSharding (=nil; Foundation), але їхня основна суть однакова.
Стек абстракції ланцюга, джерело: FrontierResearch
Ми використовуємо визнану в індустрії архітектуру 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)
Цей шар є проміжним шаром, який Solver використовує для реалізації намірів користувача. Основні компоненти рішень для ліквідності та розподілу стану включають:
Оракул (Oracle): використовується для отримання інформації про стан з інших ланцюгів.
Мости (Bridges): відповідальні за передачу інформації та ліквідності між ланцюгами.
Попереднє підтвердження (Pre-Confirmation): скорочення часу підтвердження між ланцюгами.
Доступність даних (DA): забезпечення доступності даних.
Крім того, слід враховувати міжланцюгову ліквідність, остаточну підтвердженість (Finality), механізми доказу другого рівня тощо, щоб забезпечити ефективну роботу всієї багатоланцюгової системи.
Рішення
На сьогоднішній день на ринку існує кілька рішень для розподілу ліквідності. Після огляду великої кількості рішень, ми виявили, що основними є ці кілька способів:
1. Центр RaaS: Подібно до рішення Rollup, такого як OP Stack, через додавання спеціальних спільних сортувальників та крос-ланцюгових мостів для підтримки спільної ліквідності та стану в Rollup, побудованому на OP Stack. Це сподівається вирішити проблеми ліквідності та розподілу стану на більш високому рівні. Одним з більш детальних аспектів є окремий дизайн спільних сортувальників, цей варіант більше стосується Layer2, не має універсальності, такі як Astria, Espresso та Flashbots.
Абстракція ланцюга, джерело: NEAR
2. Центр облікових записів: Подібно до NEAR, розробити обліковий гаманець для всієї ланцюга, за допомогою технології, відомої як «ланцюгова підписка», що підтримує підписання та виконання угод через різні блокчейн-протоколи. Основним компонентом є мережа MPC, яка замінює користувачів для підписання багатоланцюгових угод. Це рішення, хоча й значно вирішує проблеми фрагментації UX, все ж вимагає складної реалізації з боку розробників, і не вирішує суттєво проблеми розподілу ліквідності та стану.
3. Центр мережі намірів поза ланцюгом: тобто Solver Network в нашій схемі «вступу», основою є те, що користувач надсилає намір до мережі Solver, де роль Solver змагається за найкращу ціну та найкращий час виконання угоди. Ці Solver можуть бути AI агентами, 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, 1inch, Hedgemony тощо. Ці проекти вимагають управління складними міжланцюговими процесами, мають високі вимоги до розробників, тому вони також піддаються атакам хакерів.
Вирішення проблеми ліквідності є дуже важливим питанням; у фінансовому світі ліквідність зазвичай означає все. Якщо вдасться створити платформу для інтеграції ліквідності, особливо об'єднати фрагментовану ліквідність усіх ланцюгів, це матиме величезний потенціал, і ми також розглянули багато різних рішень.
У наведених вище двох категоріях ми можемо побачити, що згідно з пиріжковою структурою, Settlement Layer є найбільш атомарним рішенням. На цих атомарних рішеннях, таких як міжланцюгові, оракули, рішення попереднього підтвердження тощо, будується більш абстрактний рівень, це шари Solver, Permission та Application. Різні рішення, що ми перерахували вище, відповідно до різних напрямків побудови абстракції або рішень для ліквідності, відповідають цій системі різних рівнів, що можна розглядати як відношення між верхнім і нижнім потоком. Проте ці рішення все ще не є атомарними рішеннями, і вся проблема фрагментації ліквідності викликає безліч супутніх проблем. Отже, для міжопераційності виникає безліч різноманітних рішень. Проте в основі все ще лежать ці компоненти. Далі ми обговоримо кілька типових проектів концепцій абстракції ланцюга, щоб побачити, як кожен з них вирішує проблему фрагментації ліквідності з власної точки зору.
INFINIT
Структура INFINIT, джерело: Infinit
INFINIT побудував RaaS-сервіс для DeFi, який може надавати компоненти, необхідні для прямого створення DeFi-протоколів, такі як Oracle, Pool Type, IRM, Asset тощо, а також може надати компоненти, які можна швидко активувати, такі як Leverage Trading та Yield Strategy. Це еквівалентно іншим кінцевим додаткам, але кінцева ліквідність залишається в ліквідному шарі Infinit. Однак наразі він все ще не розкриває основи роботи. Наразі INFINIT отримав 6 мільйонів доларів у початковому раунді фінансування від Robot Ventures, Electric Capital та Maelstrom Capital.
Khalani Network
Структура мережі Khalani, джерело: KhalaniNetwork
Khalani побудував три основні компоненти: сумісний шар намірів, Validity та загальний шар розрахунків.
Зовнішні додатки або шар намірів можуть надсилати наміри до Khalani, і тоді сумісний шар намірів Khalani може перетворити зовнішні наміри в формат, який може розуміти протокол Solver. Використовуваний стандартизований формат - це мова Validity. Вузли Khalani відповідають за подання остаточних результатів до загального шару розрахунків через крос-ланцюгові мости, технології швидких розрахунків тощо. Цей проект все ще на стадії розробки, і наразі не розкрито більше деталей роботи. У серпні він отримав 2,2 мільйона доларів у початковому раунді фінансування від Ethereal Ventures, Nascent, Maelstrom Capital та інших.
Liquorice
Структура Liquorice, джерело: Liquorice
Liquorice - це децентралізований додаток, який забезпечує ціновий відкриття на основі аукціонів та односторонні ліквідні пулі. Основна місія Liquorice полягає в наданні професійним торговим компаніям ефективних інструментів управління запасами та легкому з'єднанні з основними DeFi протоколами, такими як 1inch та Uniswap X, під час розрахунку угод. Одночасно Liquorice створив ринок кредитування для проведення своїх кредитних угод. Цей додаток більше зосереджений на самій торгівлі. Наразі він все ще на стадії розробки, а в липні оголосив про отримання 1,2 мільйона доларів у раунді Pre-seed від GreenField.
Xion
Xion - це оновлений додаток бренду Burnt, який раніше зосереджувався на споживчих додатках. Після того, як команда виявила величезну фрагментацію в ланцюгових взаємодіях, було створено Xion для покращення цієї проблеми. Xion побудований на основі консенсусного протоколу Comet BFT. Крос-ланцюгова комунікація базується на Cosmos IBC, тому вона є більш рідною та безпечною, ніж інші крос-ланцюгові мости. Вона пройшла чотири раунди фінансування, а інвестори включають Animoca, Multicoin, Alliance DAO, Mechanism та інші.
=nil; Foundation
nil - це ринок ZK обчислень Ethereum, ZK обчислювальні процесори та розробник Layer2, команда має глибокі знання в технології ZK. Вони представили рішення zkSharding, яке використовує технології ZK для горизонтального масштабування основної мережі Ethereum, виконуючи паралельну обробку транзакцій та генеруючи ZKP, тоді як основний шард перевіряє дані, спілкується з Ethereum та синхронізує мережевий стан між усіма валідаторами. Основний шард також управляє розподілом валідаторів та облікових записів у виконуючому шарді. Консенсусний протокол, що використовується комісією з верифікації, також є Hotstuff, що досить поширено в останніх проектах паралельного виконання. =nil; L2 з самого початку вбудував міжшардову комунікацію в протокол. Міжшардові повідомлення перевіряються комісією валідаторів кожного шард.
Основна ідея полягає в тому, щоб побудувати вбудовану архітектуру міжланцюгової комунікації, подібну до IBC за допомогою шардованої архітектури Layer2, що дозволить вирішити проблеми ліквідності та розподілу стану. Однак основна ідея не цілком розумна, оскільки проблема розподілу ліквідності стосується багатоланцюгової проблеми, а не єдиної Layer2, що означає, що для вирішення цієї проблеми всі ланцюги повинні стати частинами ZK-sharding, що важко реалізувати.
ERC-7683
ERC-7683, джерело: Across
Ethereum також працює над вирішенням проблеми міжланцюгової ліквідності. Наразі Arbitrum, OP, Uniswap публічно підтримують стандарт ERC7683, що використовує міжланцюгові методи на основі намірів. Основна мета - створити загальний стандарт для міжланцюгових операцій між L2 та бічними ланцюгами, стандартизувати замовлення та інтерфейси розрахунків, забезпечити безшовне міжланцюгове виконання, а основним ядром є Filler, який також можна вважати роллю Solver у абстракції ланцюга. Цю пропозицію спільно створили Uniswap та Across, і вона наразі перебуває на розгляді робочої групи Cake.
OP Stack
OP Stack, ERC-7683, і zkSharding - це рішення для фрагментації ліквідності між Layer2 в межах Ethereum, які вирішують ці проблеми на архітектурному, консенсусному та прикладному рівнях. OP Stack проектує повне рішення для кількох Layer2, щоб одноразово вирішити проблеми передачі інформації та децентралізації Sequencer. Коли ви використовуєте архітектуру OP Stack, автоматично розгортаються крос-ланцюгові контракти, а також існує наглядова особа для запобігання передачі неправдивої крос-ланцюгової інформації. Наразі такі компанії, як Coinbase, Uniswap, Kraken, використовують OP Stack.
Серед них, найбільш типовим є Unichain. Unichain вирішує проблему фрагментації ліквідності між ланцюгами, інтегруючись із мережею Superchain. Це налаштування сприяє безперешкодному переміщенню ліквідності, пропонуючи наступні функції:
Міст міжланцюгових намірів: цей міст підтримує швидкий і надійний перенесення ліквідності між блокчейнами, дозволяючи користувачам визначати наміри, що допомагає системі автоматично вибирати найкращий шлях для перенесення ліквідності. Цей метод абстрагує складності від користувачів, роблячи міжланцюгові угоди більш плавними та швидкими.
Мережа верифікації Unichain (UVN): ця децентралізована мережа операторів вузлів перевіряє міжланцюгові угоди, забезпечуючи швидшу економічну остаточність. Швидша остаточність є критично важливою для забезпечення ефективного розрахунку міжланцюгових угод, щоб зменшити ризики фрагментації ліквідності через затримки розрахунків.
Flashblocks та перевірені блоки: завдяки використанню Flashblocks, Unichain значно скоротив час блокування, підвищив ефективність постачальників ліквідності та забезпечив більш синхронізовані міжланцюгові ринки. Flashblocks допомагають забезпечити, щоб ліквідність була завжди доступною і зменшують негативний вплив, викликаний затримкою підтвердження блоків, що може призвести до фрагментації ліквідності.
Резюме
Вирішення проблеми міжланцюгової ліквідності - це дуже складна та різноманітна область, наприклад, рішення Layer2 поділяються на вбудовані міжланцюгові повідомлення Ethereum, особливо ERC-7683, а також Layer2, такі як OP, які створюють OP Stack для спільного використання Sequencer. Виходячи за межі Layer2, всі Layer1 також стикаються з проблемами ліквідності, стану та фрагментації користувацького досвіду. Існують спеціалізовані рішення, орієнтовані на ліквідність, а також рішення Solver Network поза ланцюгом, навіть такі рішення, як NEAR, що базуються на облікових записах, але також потребують ролі Solver.
Ми вважаємо, що фрагментація міжланцюгової ліквідності, стану та користувацького досвіду є проблемою всього блокчейн-індустрії. Якщо дивитися в цілому, потрібно підійти до цього більш абстрактно, подібно до абстракції ланцюга, що є справжнім входом у Web3, вирішуючи проблеми фрагментації користувацького досвіду, а також інтеграцію ліквідності та стану в місцях, які користувачі не можуть усвідомити. Як саме інтегрувати, також поділяється на використання поза ланцюгової мережі Solver та атомарних інтеграцій крос-ланцюгових мостів тощо, це все заслуговує на обговорення. Загалом, майбутнє обов'язково буде багатоланцюговим, і вирішення проблеми фрагментації ліквідності є неминучим завданням для галузі, а ця інтеграція ліквідності всіх ланцюгів має величезний потенціал для зростання, що може призвести до створення Google епохи Web3.
