Дослідження проблеми розриву ліквідності в епоху Рівня 2
З переходом Ethereum до стратегії масштабування, що базується на Рівні 2, та з появою таких інструментів, як RaaS, велика кількість публічних блокчейнів швидко розвивається. Багато підприємств прагнуть створити свої власні ланцюги, щоб представляти різні інтереси та шукати вищу оцінку. Однак поява численних публічних блокчейнів ускладнює розвиток екосистеми, що призводить до того, що багато проектів зазнають невдачі вже під час випуску.
За допомогою OP Stack, одна торгова платформа запустила свій власний Рівень 2; за допомогою ZK технології, інша торгова платформа запустила свій власний Рівень; одна компанія випустила свою власну ланцюг, одна компанія програмного забезпечення для зв’язку запустила свій власний ланцюг тощо. Сьогодні витрати на створення ланцюга та технологічні бар'єри значно знижені, витрати на експлуатацію ланцюга на основі OP Stack складають приблизно 10 000 доларів на місяць.
Майбутнє, безумовно, буде епохою співіснування багатьох ланцюгів. Незважаючи на те, що ці ланцюги Рівень 2 можуть вибрати сумісність з EVM для досягнення взаємозв'язку, через те, що за ними стоять великі Web2 сутності з безліччю downstream додатків, їм важко будувати додатки на одному ланцюзі та досягати консенсусу.
Поточна багатоланкова екосистема принесла новий виклик: ліквідність і розподіл стану. Оскільки багатоланковість є неминучою, то взаємодія є необхідною сферою для вивчення та вирішення. Наразі існує безліч рішень для ліквідності, таких як абстракція ланцюга, намір, Clearing Execution, Native CrossChain, ZKSharding, але їхня основна суть є однією й тією ж.
Ми використовуємо широко визнану в галузі архітектуру Cake, щоб зверху вниз представити основні компоненти абстракції крос-чейн.
Застосунковий рівень(Application Layer)
Це рівень, на якому користувачі взаємодіють безпосередньо, і це також найабстрактніший рівень у рішеннях ліквідності, оскільки він повністю приховує деталі конверсії ліквідності. На прикладному рівні користувачі взаємодіють з інтерфейсом, не обов'язково розуміючи механізм конверсії ліквідності на нижньому рівні.
权限层(Рівень 2)
Розташований нижче рівня застосунків, користувачі підключають гаманці до dApp і запитують ціну для задоволення торгового наміру. Тут "намір" відноситься до очікуваного користувачем кінцевого результату угоди (, а не до конкретного шляху виконання угоди.
Управління обліковими записами та абстракція рівня )Керування ключами та абстракція облікових записів(
Через наявність багатоланцюгового середовища, потрібна система управління обліковими записами та абстракції, яка адаптується до різних ланцюгів, щоб підтримувати унікальну структуру облікових записів кожного ланцюга. Наприклад, об'єктно-централізована система облікових записів SUI зовсім не схожа на EVM. Деякі проекти побудували надійну систему облікових записів, не потребуючи встановлення міжланцюгового консенсусу, лише довірчі зобов'язання між існуючими системами облікових записів. Інші проекти реалізували абстрактне управління, генеруючи мульти-ланцюгові гаманці для користувачів, що значно оптимізувало досвід користувачів і зменшило фрагментацію UX. Однак, в аспекті ліквідності, основна інтеграція зосереджена на існуючих публічних ланцюгах.
求解层)Solver Рівень 2 (
Цей рівень відповідає за прийом та реалізацію торгових намірів користувачів, роль Solver тут змагається за надання кращого користувацького досвіду, включаючи швидший час торгівлі та швидкість виконання. На цій основі проекти, що базуються на намірах, побудували різні рішення, орієнтовані на намір. Подібні похідні від намірів, такі як компонент Predicate, можуть реалізувати наміри користувача за певними правилами.
Рівень 2 ) Рівень розрахунків (
Це шар, що використовується для вирішення користувацьких намірів через проміжний шар. Основні компоненти рішень з ліквідності та децентралізації стану включають:
预言机)Oracle(: використовується для отримання інформації про стан з інших ланцюгів.
Кросчейн міст ) Bridges (: відповідають за передачу інформації та ліквідності між мережами.
Попереднє підтвердження ): скорочення часу підтвердження між ланцюгами.
Доступність даних(DA): забезпечення доступності даних.
Крім того, слід врахувати ліквідність між ланцюгами, остаточну підтвердженість (Finality), механізм підтвердження Рівень 2 та інші фактори, щоб забезпечити ефективну роботу всієї багатоланцюгової системи.
Наразі на ринку існує безліч рішень для подолання ліквідності, після огляду великої кількості рішень ми виявили, що основними є кілька способів:
Зосередження на RaaS: подібно до рішень Rollup, таких як OP Stack, шляхом додавання специфічних спільних сортувальників і крос-чейн мостів, щоб допомогти у створенні Rollup на OP Stack, спільну ліквідність і стан. Це має на меті вирішити проблему розподілу ліквідності та стану на вищому рівні. Тут є більш детальне рішення - окремий дизайн спільних сортувальників, це рішення більше орієнтоване на Рівень 2, не має універсальності.
З обліковим записом в центрі: створення багатоланцюгового гаманця, який підтримує підписання та виконання транзакцій через технологію, відому як "ланцюговий підпис". Основним компонентом є мережа MPC, яка підписує багатоланцюгові транзакції від імені користувача. Це рішення, хоча і може значно вирішити проблему фрагментації UX, проте для розробників воно пов'язане зі складною реалізацією на стороні сервера, і принципово не вирішує питання ліквідності та розподілу стану.
Зосередження на мережі намірів поза ланцюгом: це наша "вступна" схема архітектури торта, в якій мережа Solver є основною, де користувачі надсилають наміри до мережі Solver, а роль Solver полягає в конкуренції за пропозиції, надаючи найкращий час виконання та ціну угоди. Ці Solver можуть бути AI Agent, CEX, Market Maker або навіть інтеграційними протоколами. Хоча наміри теоретично можуть реалізувати складні крос-ланцюгові операції будь-якої складності, для їх реалізації необхідні достатні ліквідні Solver для допомоги, і у разі виникнення певних запитів поза ланцюгом існує можливість шахрайства з боку Solver. Якщо впроваджувати такі методи, як докази шахрайства, реалізація мережі Solver стане ще більш складною, а поріг входження для роботи Solver також підвищиться.
Зосередженість на мережі ліквідності на базі блокчейну: цей напрямок спеціально оптимізує проблеми ліквідності між ланцюгами, але не вирішує інші проблеми розподілу стану на ланцюгах. Його суть полягає у створенні шару ліквідності, на якому будуються додатки для спільного використання ліквідності всього ланцюга.
Орієнтація на додатки на базі блокчейну: такі додатки створюються шляхом інтеграції великих MM або сторонніх додатків для побудови високоліквідних додатків. Ці проекти потребують управління складними міжланцюговими процесами, що висуває високі вимоги до розробників, тому також дуже легко можуть статися випадки хакерських атак.
Вирішення проблеми ліквідності є дуже важливим питанням, у фінансовому світі ліквідність часто означає все. Якщо вдасться створити інтегровану платформу ліквідності, особливо об'єднавши розрізнену ліквідність з усіх ланцюгів, це матиме великий потенціал, і ми також розглянули багато різних рішень.
У цих двох категоріях ми можемо побачити, що відповідно до структури торта, Settlement Layer є найатомарнішим рішенням, над якими, у свою чергу, побудовані більш абстрактні рівні, такі як Solver Layer, Permission Layer та Application Layer, що є атомними рішеннями для міжланцюгових, оракулів, Pre-Confirmation рішень тощо. Різні рівні, перераховані вище, що побудовані в різних напрямках для створення абстрактних або ліквідних рішень, можуть розглядатися як зв'язок між верхніми та нижніми ланками. Проте ці рішення все ще не є атомарними, проблема розриву ліквідності призвела до появи багатьох складних похідних питань, тому для взаємодії виникло безліч різноманітних рішень. Але в основному це ще залежить від цих компонентів.
Вирішення проблеми ліквідності між ланцюгами є дуже складною та різноманітною галуззю, наприклад, рішення Рівня 2 поділяються на ті, що використовують вбудовані міжланцюгові повідомлення, зокрема ERC-7683, а також на рішення, побудовані на Рівні 2, такі як OP Stack, для спільного використання Sequencer. Виходячи з контексту Рівня 2, всі Layer1 також стикаються з проблемами ліквідності, стану та розриву в користувацькому досвіді, існують спеціалізовані рішення, що зосереджені на ліквідності, а також рішення, що базуються на мережі Solver, включаючи рішення, зосереджені на рахунках, але також потрібно базуватися на ролі Solver як позамережевої ролі.
Ми досить визнані, кросчейн Ліквідність, стан, розрив користувацького досвіду є проблемою для всієї блокчейн-індустрії. Якщо розглядати це в цілому, потрібно йти до більш абстрактного підходу, схожого на абстракцію ланцюга, що є справжнім входом у Web3. Це вирішує розрив у користувацькому досвіді, одночасно інтегруючи Ліквідність і стан в місцях, які користувач не може сприймати. Конкретно, як інтегрувати, це також поділяється на використання оффчейн мережі Solver і атомарну інтеграцію кросчейн мостів та інших об'єктів, що заслуговує на обговорення. У цілому, майбутнє безумовно буде багатоланцюговим, вирішення проблеми розподілу Ліквідності є питанням, з яким галузь неминуче зіткнеться, і така інтеграція повної Ліквідності ланцюга має величезний потенціал для зростання, що може створити новий тип інтернет-входу епохи Web3.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
17 лайків
Нагородити
17
3
Репост
Поділіться
Прокоментувати
0/400
FromMinerToFarmer
· 07-25 18:33
обдурювати людей, як лохів потім з'єднати – це неминуче
Переглянути оригіналвідповісти на0
StakeWhisperer
· 07-23 11:21
Чи варто щось робити, якщо багато ланцюгів, а грошей мало?
Виклики епохи Рівня 2: дослідження ліквідності обдурювання людей, як лохів у багатоланковій екосистемі та шляхи їх вирішення
Дослідження проблеми розриву ліквідності в епоху Рівня 2
З переходом Ethereum до стратегії масштабування, що базується на Рівні 2, та з появою таких інструментів, як RaaS, велика кількість публічних блокчейнів швидко розвивається. Багато підприємств прагнуть створити свої власні ланцюги, щоб представляти різні інтереси та шукати вищу оцінку. Однак поява численних публічних блокчейнів ускладнює розвиток екосистеми, що призводить до того, що багато проектів зазнають невдачі вже під час випуску.
За допомогою OP Stack, одна торгова платформа запустила свій власний Рівень 2; за допомогою ZK технології, інша торгова платформа запустила свій власний Рівень; одна компанія випустила свою власну ланцюг, одна компанія програмного забезпечення для зв’язку запустила свій власний ланцюг тощо. Сьогодні витрати на створення ланцюга та технологічні бар'єри значно знижені, витрати на експлуатацію ланцюга на основі OP Stack складають приблизно 10 000 доларів на місяць.
Майбутнє, безумовно, буде епохою співіснування багатьох ланцюгів. Незважаючи на те, що ці ланцюги Рівень 2 можуть вибрати сумісність з EVM для досягнення взаємозв'язку, через те, що за ними стоять великі Web2 сутності з безліччю downstream додатків, їм важко будувати додатки на одному ланцюзі та досягати консенсусу.
Поточна багатоланкова екосистема принесла новий виклик: ліквідність і розподіл стану. Оскільки багатоланковість є неминучою, то взаємодія є необхідною сферою для вивчення та вирішення. Наразі існує безліч рішень для ліквідності, таких як абстракція ланцюга, намір, Clearing Execution, Native CrossChain, ZKSharding, але їхня основна суть є однією й тією ж.
Ми використовуємо широко визнану в галузі архітектуру Cake, щоб зверху вниз представити основні компоненти абстракції крос-чейн.
Застосунковий рівень(Application Layer)
Це рівень, на якому користувачі взаємодіють безпосередньо, і це також найабстрактніший рівень у рішеннях ліквідності, оскільки він повністю приховує деталі конверсії ліквідності. На прикладному рівні користувачі взаємодіють з інтерфейсом, не обов'язково розуміючи механізм конверсії ліквідності на нижньому рівні.
权限层(Рівень 2)
Розташований нижче рівня застосунків, користувачі підключають гаманці до dApp і запитують ціну для задоволення торгового наміру. Тут "намір" відноситься до очікуваного користувачем кінцевого результату угоди (, а не до конкретного шляху виконання угоди.
Управління обліковими записами та абстракція рівня )Керування ключами та абстракція облікових записів(
Через наявність багатоланцюгового середовища, потрібна система управління обліковими записами та абстракції, яка адаптується до різних ланцюгів, щоб підтримувати унікальну структуру облікових записів кожного ланцюга. Наприклад, об'єктно-централізована система облікових записів SUI зовсім не схожа на EVM. Деякі проекти побудували надійну систему облікових записів, не потребуючи встановлення міжланцюгового консенсусу, лише довірчі зобов'язання між існуючими системами облікових записів. Інші проекти реалізували абстрактне управління, генеруючи мульти-ланцюгові гаманці для користувачів, що значно оптимізувало досвід користувачів і зменшило фрагментацію UX. Однак, в аспекті ліквідності, основна інтеграція зосереджена на існуючих публічних ланцюгах.
求解层)Solver Рівень 2 (
Цей рівень відповідає за прийом та реалізацію торгових намірів користувачів, роль Solver тут змагається за надання кращого користувацького досвіду, включаючи швидший час торгівлі та швидкість виконання. На цій основі проекти, що базуються на намірах, побудували різні рішення, орієнтовані на намір. Подібні похідні від намірів, такі як компонент Predicate, можуть реалізувати наміри користувача за певними правилами.
Рівень 2 ) Рівень розрахунків (
Це шар, що використовується для вирішення користувацьких намірів через проміжний шар. Основні компоненти рішень з ліквідності та децентралізації стану включають:
Крім того, слід врахувати ліквідність між ланцюгами, остаточну підтвердженість (Finality), механізм підтвердження Рівень 2 та інші фактори, щоб забезпечити ефективну роботу всієї багатоланцюгової системи.
Наразі на ринку існує безліч рішень для подолання ліквідності, після огляду великої кількості рішень ми виявили, що основними є кілька способів:
Зосередження на RaaS: подібно до рішень Rollup, таких як OP Stack, шляхом додавання специфічних спільних сортувальників і крос-чейн мостів, щоб допомогти у створенні Rollup на OP Stack, спільну ліквідність і стан. Це має на меті вирішити проблему розподілу ліквідності та стану на вищому рівні. Тут є більш детальне рішення - окремий дизайн спільних сортувальників, це рішення більше орієнтоване на Рівень 2, не має універсальності.
З обліковим записом в центрі: створення багатоланцюгового гаманця, який підтримує підписання та виконання транзакцій через технологію, відому як "ланцюговий підпис". Основним компонентом є мережа MPC, яка підписує багатоланцюгові транзакції від імені користувача. Це рішення, хоча і може значно вирішити проблему фрагментації UX, проте для розробників воно пов'язане зі складною реалізацією на стороні сервера, і принципово не вирішує питання ліквідності та розподілу стану.
Зосередження на мережі намірів поза ланцюгом: це наша "вступна" схема архітектури торта, в якій мережа Solver є основною, де користувачі надсилають наміри до мережі Solver, а роль Solver полягає в конкуренції за пропозиції, надаючи найкращий час виконання та ціну угоди. Ці Solver можуть бути AI Agent, CEX, Market Maker або навіть інтеграційними протоколами. Хоча наміри теоретично можуть реалізувати складні крос-ланцюгові операції будь-якої складності, для їх реалізації необхідні достатні ліквідні Solver для допомоги, і у разі виникнення певних запитів поза ланцюгом існує можливість шахрайства з боку Solver. Якщо впроваджувати такі методи, як докази шахрайства, реалізація мережі Solver стане ще більш складною, а поріг входження для роботи Solver також підвищиться.
Зосередженість на мережі ліквідності на базі блокчейну: цей напрямок спеціально оптимізує проблеми ліквідності між ланцюгами, але не вирішує інші проблеми розподілу стану на ланцюгах. Його суть полягає у створенні шару ліквідності, на якому будуються додатки для спільного використання ліквідності всього ланцюга.
Орієнтація на додатки на базі блокчейну: такі додатки створюються шляхом інтеграції великих MM або сторонніх додатків для побудови високоліквідних додатків. Ці проекти потребують управління складними міжланцюговими процесами, що висуває високі вимоги до розробників, тому також дуже легко можуть статися випадки хакерських атак.
Вирішення проблеми ліквідності є дуже важливим питанням, у фінансовому світі ліквідність часто означає все. Якщо вдасться створити інтегровану платформу ліквідності, особливо об'єднавши розрізнену ліквідність з усіх ланцюгів, це матиме великий потенціал, і ми також розглянули багато різних рішень.
У цих двох категоріях ми можемо побачити, що відповідно до структури торта, Settlement Layer є найатомарнішим рішенням, над якими, у свою чергу, побудовані більш абстрактні рівні, такі як Solver Layer, Permission Layer та Application Layer, що є атомними рішеннями для міжланцюгових, оракулів, Pre-Confirmation рішень тощо. Різні рівні, перераховані вище, що побудовані в різних напрямках для створення абстрактних або ліквідних рішень, можуть розглядатися як зв'язок між верхніми та нижніми ланками. Проте ці рішення все ще не є атомарними, проблема розриву ліквідності призвела до появи багатьох складних похідних питань, тому для взаємодії виникло безліч різноманітних рішень. Але в основному це ще залежить від цих компонентів.
Вирішення проблеми ліквідності між ланцюгами є дуже складною та різноманітною галуззю, наприклад, рішення Рівня 2 поділяються на ті, що використовують вбудовані міжланцюгові повідомлення, зокрема ERC-7683, а також на рішення, побудовані на Рівні 2, такі як OP Stack, для спільного використання Sequencer. Виходячи з контексту Рівня 2, всі Layer1 також стикаються з проблемами ліквідності, стану та розриву в користувацькому досвіді, існують спеціалізовані рішення, що зосереджені на ліквідності, а також рішення, що базуються на мережі Solver, включаючи рішення, зосереджені на рахунках, але також потрібно базуватися на ролі Solver як позамережевої ролі.
Ми досить визнані, кросчейн Ліквідність, стан, розрив користувацького досвіду є проблемою для всієї блокчейн-індустрії. Якщо розглядати це в цілому, потрібно йти до більш абстрактного підходу, схожого на абстракцію ланцюга, що є справжнім входом у Web3. Це вирішує розрив у користувацькому досвіді, одночасно інтегруючи Ліквідність і стан в місцях, які користувач не може сприймати. Конкретно, як інтегрувати, це також поділяється на використання оффчейн мережі Solver і атомарну інтеграцію кросчейн мостів та інших об'єктів, що заслуговує на обговорення. У цілому, майбутнє безумовно буде багатоланцюговим, вирішення проблеми розподілу Ліквідності є питанням, з яким галузь неминуче зіткнеться, і така інтеграція повної Ліквідності ланцюга має величезний потенціал для зростання, що може створити новий тип інтернет-входу епохи Web3.