Автор: 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-сумісність для забезпечення міжоперабельності, через велику кількість додатків, що походять від Web2, їм буде важко побудувати додатки на одному ланцюзі та досягти консенсусу.
Розподіл TVL, джерело: Defillama
Сучасна багатоланцюгова екосистема принесла новий виклик: розподіленість ліквідності та стану. Оскільки існування багатьох ланцюгів є неминучим, то міжоперабельність є обов'язковою для дослідження та вирішення. Наразі є багато рішень для ліквідності, такі як ми чули про ланцюгову абстракцію (Particle Network, Socket, XION, INFINIT, Borsa), наміри (Anoma, Khalani), Clearing Execution (Connext), Native CrossChain (Cross), ZKSharding (=nil; Foundation), але їхня суть однакова.
Стек крос-ланцюгової абстракції, джерело: Frontier Research
Ми використовуємо визнану у галузі архітектуру Cake, щоб зверху вниз представити основні компоненти крос-ланцюгової абстракції:
Рівень застосунків (Application Layer)
Це шар безпосередньої взаємодії користувачів, а також найабстрактніший шар у рішеннях ліквідності, оскільки він повністю приховує деталі конвертації ліквідності. У шарі застосунків користувачі взаємодіють з інтерфейсом, не обов'язково усвідомлюючи механізми конвертації ліквідності на нижньому рівні.
Шар дозволів (Permission Layer)
Розташований нижче рівня застосунків, користувачі підключають гаманці до dApp і запитують котирування, щоб задовольнити торгові наміри. Тут «наміри» означають бажаний кінцевий результат угоди (тобто вихід), а не конкретний шлях виконання угоди.
Управління обліковими записами та абстрактний шар (Key Management and Account Abstraction)
Оскільки існує багатоланцева середа, потрібна система управління обліковими записами та абстракції, що адаптується до різних ланцюгів, щоб підтримувати унікальні структури облікових записів кожного з ланцюгів. Наприклад, об'єктно-орієнтована система облікових записів SUI абсолютно відрізняється від EVM. One Balance є представницьким проектом у цій галузі, який побудував надійну систему облікових записів без необхідності встановлювати міжланцюгову консенсус, лише з використанням наявних облікових систем. Near Account реалізує абстрактне управління, генеруючи багатоланцюговий гаманець для користувачів, значно оптимізуючи користувацький досвід та зменшуючи фрагментацію UX. Тим не менш, ліквідність переважно інтегрована з наявними публічними ланцюгами.
Шар Solver (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 та 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 Network стане ще складнішою, а поріг входу для роботи Solver також підвищиться.
4. Центрований на мережі ліквідності: цей напрямок спеціально оптимізує проблему ліквідності між ланцюгами, але не вирішує інші проблеми розподілу стану між ланцюгами. Його суть полягає в створенні шару ліквідності, на якому будуються додатки для спільного використання ліквідності всіх ланцюгів. Деякі проекти включають: Raye Network, INFINIT, Everclear, Elixir тощо.
5. Центрований на ланцюгових додатках: ці додатки створюють високоліквідні додатки, інтегруючи великих MM або сторонні додатки, такі як Liquorice, Socket, Radiant Capital, 1inch, Hedgemony тощо. Ці проекти потребують управління складними крос-ланцюговими процесами, що накладає високі вимоги на розробників, тому вони також схильні до атак хакерів.
Розв'язання проблеми ліквідності є дуже важливим питанням, оскільки в фінансовому світі ліквідність часто означає все. Якщо можна створити платформу для інтеграції ліквідності, особливо об'єднуючи розрізнені ліквідності по всьому ланцюгу, це матиме великий потенціал, і ми також розглянули багато різних рішень.
У двох вищезазначених категоріях ми можемо бачити, згідно з структурою торта, що Settlement Layer є найбільш атомарним рішенням. На цих атомарних рішеннях, таких як крос-ланцюги, оракули, Pre-Confirmation тощо, будуються більш абстрактні шари, такі як Solver Layer, Permission Layer та Application Layer. Ми вказали різні рівні, на яких різні рішення для абстракції або ліквідності можуть бути зрозумілі як відносини між верхнім і нижнім потоком. Проте ці рішення все ще не є атомарними рішеннями, і вся проблема фрагментації ліквідності викликає безліч похідних проблем, тому для міжоперабельності виникає безліч рішень. Але в основному це залежить від цих компонентів. Далі ми обговоримо кілька типових проектів концепцій крос-ланцюгової абстракції, щоб подивитися, як кожен із них вирішує проблему фрагментації ліквідності з власної точки зору.
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 Network, джерело: Khalani Network
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 з самого початку вбудувала крос-шардову комунікацію в протокол. Крос-шардові повідомлення перевіряються комітетом валідаторів кожного шардового блоку як транзакції.
Основна ідея полягає в тому, щоб за допомогою шардованої архітектури Layer2 створити вбудовану крос-шардову комунікаційну архітектуру, подібну до IBC, щоб вирішити проблеми ліквідності та розподілу стану. Але основна ідея не є раціональною, оскільки проблема розподілу ліквідності є проблемою багатьох ланцюгів, а будівництво єдиної 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 розроблено для вирішення проблеми передачі інформації та децентралізації 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.
