Після переходу Ethereum на розширення, що базується на Рівні 2, і з появою таких інструментів, як RaaS, багато публічних блокчейнів швидко розвиваються. Багато компаній хочуть створити свої власні блокчейни, щоб представляти різні інтереси та шукати вищу оцінку. Проте велика кількість публічних блокчейнів ускладнює розвиток екосистеми, що призводить до того, що багато проектів втрачають вартість вже під час первинного розміщення токенів.
За допомогою OP Stack одна торгова платформа запустила свій власний Base Layer 2, інша торгова платформа випустила Ink; за допомогою ZK технології одна торгова платформа запустила XLayer; одна технологічна компанія випустила Soneium, одна комунікаційна компанія запустила Kaia тощо. Сьогодні витрати і технічний поріг для побудови ланцюга значно знизилися, витрати на експлуатацію ланцюга на базі OP Stack складають приблизно 10 000 доларів на місяць.
Майбутнє безумовно буде епохою співіснування багатьох ланцюгів. Незважаючи на те, що ці Рівень 2 ланцюги можуть обрати сумісність з EVM для забезпечення взаємодії, через те, що за ними стоять великі Web2 компанії з численними downstream додатками, їм важко будувати додатки на одному ланцюзі та досягати консенсусу.
Поточна багатоланкова екосистема принесла новий виклик: Ліквідність та розподіл стану. Оскільки існування багатоланковості є неминучим, то взаємодія є обов'язковою для дослідження та вирішення. Наразі існує безліч рішень для ліквідності, таких як абстракція ланцюга, наміри, Clearing Execution, Native CrossChain, ZKSharding тощо, але їхня основна суть однакова.
Ми використовуємо загальновизнану в галузі архітектуру Cake, щоб зверху вниз представити основні компоненти абстракції міжланцюгових зв'язків:
Рівень застосування
Це рівень безпосередньої взаємодії користувачів, а також найабстрактніший рівень у рішеннях для ліквідності, оскільки він повністю приховує деталі конвертації ліквідності. На прикладному рівні користувачі взаємодіють з інтерфейсом, не обов'язково розуміючи механізм конвертації ліквідності на нижньому рівні.
Шар дозволів (Permission Layer)
Розташований під рівнем додатків, користувачі задовольняють свої торгові наміри, підключаючи гаманці до dApp і запитуючи ціну. Тут «намір» відноситься до очікуваного кінцевого результату угоди (тобто виходу), а не до конкретного шляху виконання угоди.
Управління рахунками та абстракція ключів (Key Management and Account Abstraction)
Оскільки існує багатоланкова середовище, необхідна система управління обліковими записами та абстракції, яка підходить для різних ланцюгів, щоб підтримувати унікальну структуру облікових записів кожного ланцюга. Один проект створив надійну систему облікових записів, не потребуючи встановлення міжланцюгового консенсусу, а лише надійних зобов'язань між існуючими системами облікових записів. Інший проект реалізував абстрактне управління, генеруючи багатоланкові гаманці для користувачів, що значно оптимізувало користувацький досвід і зменшило фрагментацію UX. Однак у сфері ліквідності в основному було інтегровано існуючі публічні ланцюги.
Рівень розв'язання (Solver Layer)
Цей рівень відповідає за прийом та реалізацію торгових намірів користувачів, роль Solver тут змагається, щоб забезпечити кращий користувацький досвід, включаючи швидший час угод та швидкість виконання. На цій основі проекти, що базуються на намірах, створили різноманітні рішення, керовані намірами. Подібні похідні від намірів, такі як компонент Predicate, можуть реалізувати намір користувача за певними правилами.
Розрахунковий шар
Це проміжний шар, що використовується для реалізації намірів користувача. Основні компоненти рішень з ліквідності та розподілу стану включають:
Оракул (Oracle): використовується для отримання інформації про стан з інших ланцюгів.
Крос-чейн мости (Bridges): відповідають за передачу інформації та ліквідності між ланцюгами.
Попереднє підтвердження (Pre-Confirmation): скорочення часу підтвердження між мережами.
Доступність даних (DA): забезпечує доступність даних.
Крім того, необхідно враховувати ліквідність між ланцюгами, остаточність (Finality), механізм підтвердження Рівня 2 та інші фактори, щоб забезпечити ефективну роботу всього багатоланцюгового системи.
Наразі на ринку існує кілька рішень для вирішення проблеми ліквідності, основними з яких є:
Зосередженість на RaaS: допомога в створенні Rollup на OP Stack шляхом приєднання до певних спільних сортувальників і міжланцюгових мостів для спільної ліквідності та стану.
Централізований обліковий запис: побудуйте обліковий гаманець для всього ланцюга, який підтримує підписання та виконання транзакцій через технологію "ланцюгового підпису" на різних протоколах блокчейну.
Зосередженість на мережі поза ланцюгом: користувачі надсилають наміри до мережі Solver, Solver змагаються з пропозиціями, пропонуючи оптимальний час виконання та ціну угоди.
Зосередження на мережі ліквідності на основі блокчейн: побудова шару ліквідності, на якому розгортаються додатки для спільного використання ліквідності всього ланцюга.
Централізоване застосування на основі блокчейну: створення високоліквідних додатків через інтеграцію великих маркет-мейкерів або сторонніх додатків.
Вирішення проблеми ліквідності є дуже важливим питанням. У фінансовому світі ліквідність часто представляє все. Якщо вдасться створити платформу для інтеграції ліквідності, особливо об'єднавши розрізнену ліквідність усієї мережі, це матиме великий потенціал.
Деякі типові проекти концепції абстракції ланцюга включають:
ІНФІНІТ
INFINIT побудував сервіс RaaS для світу DeFi, надаючи компоненти, необхідні для прямого створення DeFi протоколів, такі як Oracle, Pool Type, IRM, Asset тощо, а також здатний надати компоненти, які можна негайно активувати, такі як Leverage Trading і Yield Strategy.
Мережа Халані
Khalani побудував три основні компоненти: шар сумісності Intent, Validity та універсальний розрахунковий шар. Зовнішні додатки або шар намірів можуть публікувати наміри до Khalani, після чого шар сумісності Intent Khalani може перетворити зовнішні наміри у формат, який може розпізнати протокол Solver.
Liquorice є децентралізованим додатком, що забезпечує виявлення цін на основі аукціонів та односторонні ліквідні пулі. Його основна місія полягає в наданні професійним торговим компаніям ефективних інструментів управління запасами та легкому підключенню до основних DeFi протоколів під час розрахунку угод за намірами використання.
Сіон
Xion побудований на основі протоколу консенсусу Comet BFT. Використувана міжланкова комунікація базується на Cosmos IBC, тому вона є більш нативною та безпечною, ніж інші міжланкові мости.
=nil; Фонд
nil є розробником ринку ZK потужностей, ZK співпроцесорів та Рівня 2 для Ethereum. Він представив рішення zkSharding, яке використовує технологію ZK для горизонтального масштабування основної мережі Ethereum, виконуючи парал обробку транзакцій та генеруючи ZKP.
ERC-7683
Це пропозиція щодо створення загального стандарту для крос-ланцюгових операцій між Рівень 2 та бічними ланцюгами, що має на меті стандартизацію інтерфейсів замовлень та розрахунків для забезпечення безшовного виконання крос-ланцюгових операцій.
Стек OP
OP Stack проектує повноцінне рішення для багатьох Рівень 2, щоб одноразово вирішити проблеми передачі інформації та децентралізації Sequencer. Коли використовується архітектура OP Stack, автоматично розгортаються крос-чейн контракти, одночасно існує Supervisor, щоб кинути виклик на запобігання передачі неправдивої крос-чейн інформації.
Вирішення проблеми ліквідності між ланцюгами є дуже складною та багатогранною областю з безліччю рішень. Майбутнє обов'язково буде багатоланцюговим, вирішення проблеми розподіленої ліквідності є викликом, з яким галузь неодмінно зіткнеться, а інтеграція ліквідності з усіх ланцюгів має величезний потенціал для зростання, що може стати важливою інфраструктурою епохи Web3.
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Виклики ліквідності в епоху Рівня 2 та рішення для інтеграції мульти-ланок
Виклики та рішення ліквідності епохи Рівня 2
Після переходу Ethereum на розширення, що базується на Рівні 2, і з появою таких інструментів, як RaaS, багато публічних блокчейнів швидко розвиваються. Багато компаній хочуть створити свої власні блокчейни, щоб представляти різні інтереси та шукати вищу оцінку. Проте велика кількість публічних блокчейнів ускладнює розвиток екосистеми, що призводить до того, що багато проектів втрачають вартість вже під час первинного розміщення токенів.
За допомогою OP Stack одна торгова платформа запустила свій власний Base Layer 2, інша торгова платформа випустила Ink; за допомогою ZK технології одна торгова платформа запустила XLayer; одна технологічна компанія випустила Soneium, одна комунікаційна компанія запустила Kaia тощо. Сьогодні витрати і технічний поріг для побудови ланцюга значно знизилися, витрати на експлуатацію ланцюга на базі OP Stack складають приблизно 10 000 доларів на місяць.
Майбутнє безумовно буде епохою співіснування багатьох ланцюгів. Незважаючи на те, що ці Рівень 2 ланцюги можуть обрати сумісність з EVM для забезпечення взаємодії, через те, що за ними стоять великі Web2 компанії з численними downstream додатками, їм важко будувати додатки на одному ланцюзі та досягати консенсусу.
! Дослідження фрагментації ліквідності в епоху Layer 2
Поточна багатоланкова екосистема принесла новий виклик: Ліквідність та розподіл стану. Оскільки існування багатоланковості є неминучим, то взаємодія є обов'язковою для дослідження та вирішення. Наразі існує безліч рішень для ліквідності, таких як абстракція ланцюга, наміри, Clearing Execution, Native CrossChain, ZKSharding тощо, але їхня основна суть однакова.
Ми використовуємо загальновизнану в галузі архітектуру Cake, щоб зверху вниз представити основні компоненти абстракції міжланцюгових зв'язків:
Рівень застосування
Це рівень безпосередньої взаємодії користувачів, а також найабстрактніший рівень у рішеннях для ліквідності, оскільки він повністю приховує деталі конвертації ліквідності. На прикладному рівні користувачі взаємодіють з інтерфейсом, не обов'язково розуміючи механізм конвертації ліквідності на нижньому рівні.
Шар дозволів (Permission Layer)
Розташований під рівнем додатків, користувачі задовольняють свої торгові наміри, підключаючи гаманці до dApp і запитуючи ціну. Тут «намір» відноситься до очікуваного кінцевого результату угоди (тобто виходу), а не до конкретного шляху виконання угоди.
Управління рахунками та абстракція ключів (Key Management and Account Abstraction)
Оскільки існує багатоланкова середовище, необхідна система управління обліковими записами та абстракції, яка підходить для різних ланцюгів, щоб підтримувати унікальну структуру облікових записів кожного ланцюга. Один проект створив надійну систему облікових записів, не потребуючи встановлення міжланцюгового консенсусу, а лише надійних зобов'язань між існуючими системами облікових записів. Інший проект реалізував абстрактне управління, генеруючи багатоланкові гаманці для користувачів, що значно оптимізувало користувацький досвід і зменшило фрагментацію UX. Однак у сфері ліквідності в основному було інтегровано існуючі публічні ланцюги.
Рівень розв'язання (Solver Layer)
Цей рівень відповідає за прийом та реалізацію торгових намірів користувачів, роль Solver тут змагається, щоб забезпечити кращий користувацький досвід, включаючи швидший час угод та швидкість виконання. На цій основі проекти, що базуються на намірах, створили різноманітні рішення, керовані намірами. Подібні похідні від намірів, такі як компонент Predicate, можуть реалізувати намір користувача за певними правилами.
Розрахунковий шар
Це проміжний шар, що використовується для реалізації намірів користувача. Основні компоненти рішень з ліквідності та розподілу стану включають:
Крім того, необхідно враховувати ліквідність між ланцюгами, остаточність (Finality), механізм підтвердження Рівня 2 та інші фактори, щоб забезпечити ефективну роботу всього багатоланцюгового системи.
! Дослідження фрагментації ліквідності в епоху Layer 2
Наразі на ринку існує кілька рішень для вирішення проблеми ліквідності, основними з яких є:
Зосередженість на RaaS: допомога в створенні Rollup на OP Stack шляхом приєднання до певних спільних сортувальників і міжланцюгових мостів для спільної ліквідності та стану.
Централізований обліковий запис: побудуйте обліковий гаманець для всього ланцюга, який підтримує підписання та виконання транзакцій через технологію "ланцюгового підпису" на різних протоколах блокчейну.
Зосередженість на мережі поза ланцюгом: користувачі надсилають наміри до мережі Solver, Solver змагаються з пропозиціями, пропонуючи оптимальний час виконання та ціну угоди.
Зосередження на мережі ліквідності на основі блокчейн: побудова шару ліквідності, на якому розгортаються додатки для спільного використання ліквідності всього ланцюга.
Централізоване застосування на основі блокчейну: створення високоліквідних додатків через інтеграцію великих маркет-мейкерів або сторонніх додатків.
Вирішення проблеми ліквідності є дуже важливим питанням. У фінансовому світі ліквідність часто представляє все. Якщо вдасться створити платформу для інтеграції ліквідності, особливо об'єднавши розрізнену ліквідність усієї мережі, це матиме великий потенціал.
Деякі типові проекти концепції абстракції ланцюга включають:
ІНФІНІТ
INFINIT побудував сервіс RaaS для світу DeFi, надаючи компоненти, необхідні для прямого створення DeFi протоколів, такі як Oracle, Pool Type, IRM, Asset тощо, а також здатний надати компоненти, які можна негайно активувати, такі як Leverage Trading і Yield Strategy.
Мережа Халані
Khalani побудував три основні компоненти: шар сумісності Intent, Validity та універсальний розрахунковий шар. Зовнішні додатки або шар намірів можуть публікувати наміри до Khalani, після чого шар сумісності Intent Khalani може перетворити зовнішні наміри у формат, який може розпізнати протокол Solver.
! Дослідження фрагментації ліквідності в епоху Layer 2
Лакриця
Liquorice є децентралізованим додатком, що забезпечує виявлення цін на основі аукціонів та односторонні ліквідні пулі. Його основна місія полягає в наданні професійним торговим компаніям ефективних інструментів управління запасами та легкому підключенню до основних DeFi протоколів під час розрахунку угод за намірами використання.
Сіон
Xion побудований на основі протоколу консенсусу Comet BFT. Використувана міжланкова комунікація базується на Cosmos IBC, тому вона є більш нативною та безпечною, ніж інші міжланкові мости.
=nil; Фонд
nil є розробником ринку ZK потужностей, ZK співпроцесорів та Рівня 2 для Ethereum. Він представив рішення zkSharding, яке використовує технологію ZK для горизонтального масштабування основної мережі Ethereum, виконуючи парал обробку транзакцій та генеруючи ZKP.
ERC-7683
Це пропозиція щодо створення загального стандарту для крос-ланцюгових операцій між Рівень 2 та бічними ланцюгами, що має на меті стандартизацію інтерфейсів замовлень та розрахунків для забезпечення безшовного виконання крос-ланцюгових операцій.
Стек OP
OP Stack проектує повноцінне рішення для багатьох Рівень 2, щоб одноразово вирішити проблеми передачі інформації та децентралізації Sequencer. Коли використовується архітектура OP Stack, автоматично розгортаються крос-чейн контракти, одночасно існує Supervisor, щоб кинути виклик на запобігання передачі неправдивої крос-чейн інформації.
! Дослідження фрагментації ліквідності в епоху Layer 2
Вирішення проблеми ліквідності між ланцюгами є дуже складною та багатогранною областю з безліччю рішень. Майбутнє обов'язково буде багатоланцюговим, вирішення проблеми розподіленої ліквідності є викликом, з яким галузь неодмінно зіткнеться, а інтеграція ліквідності з усіх ланцюгів має величезний потенціал для зростання, що може стати важливою інфраструктурою епохи Web3.