Дослідження проблеми ліквідності обдурювання людей, як лохів в епоху Рівня 2

З переходом Ethereum до розширення, яке зосереджене на Рівні 2, а також з виникненням таких інструментів, як RaaS, багато публічних ланцюгів швидко розвиваються. Багато суб'єктів прагнуть створити свої власні ланцюги, щоб представляти різні інтереси та шукати вищу оцінку. Однак поява великої кількості публічних ланцюгів ускладнює розвиток екосистеми, змушуючи багато проектів знецінюватись на TGE.

Завдяки OP Stack, одна торговельна платформа запустила свій власний Рівень 2, інша торговельна платформа випустила Ink; завдяки технології ZK, одна торговельна платформа запустила XLayer; одна технологічна компанія випустила Soneium, одна комунікаційна програма запустила Kaia тощо. Сьогодні фінансові та технологічні бар'єри для створення блокчейну значно знижені, а витрати на експлуатацію ланцюга на основі OP Stack складають приблизно 10 000 доларів на місяць.

Майбутнє, безумовно, буде епохою співіснування багатьох ланцюгів. Хоча ці Рівень 2 ланцюги можуть обрати EVM-сумісність для досягнення взаємодії, але через те, що за ними стоять великі Web2 сутності з великою кількістю downstream додатків, їм важко будувати додатки на одному ланцюзі та досягати консенсусу.

Поточна багаточеневе екосистема принесла новий виклик: Ліквідність та розподіл стану. Оскільки багаточеневість є неминучою, міжопераційність є галуззю, яку потрібно дослідити та вирішити. Наразі існує багато рішень для ліквідності, таких як абстракція ланцюга, наміри, Clearing Execution, Native CrossChain, ZKSharding, але їхня основна сутність однакова.

Ми використовуємо визнану в галузі архітектуру Cake, щоб зверху вниз представити основні компоненти абстракції міжланцюгових зв'язків:

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

Рівень 2 розташований нижче рівня додатків, користувачі підключають гаманці до dApp та запитують ціну, щоб задовольнити торгові наміри. Тут "наміри" означають очікуваний кінцевий результат угоди, а не конкретний шлях виконання угоди.

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

Рішення рівня відповідає за прийняття та реалізацію торгових намірів користувачів. Роль Solver тут змагається, щоб забезпечити кращий досвід користувачів, включаючи швидший час торгівлі та швидкість виконання. На цій основі, на основі наміру, проекти створили різні рішення, орієнтовані на намір. Такі похідні від наміру, як компонент Predicate, можуть реалізувати наміри користувачів за певними правилами.

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

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

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

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

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

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

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

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

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

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

Ми вказали різні рівні, що відповідають різним напрямкам побудови абстракцій або ліквідності, які можна розглядати як відносини між верхнім і нижнім ступенями. Але ці рішення все ще не є атомними, і проблема цілісної ліквідності обдурює людей, як лохів, що призводить до появи багатьох складних похідних проблем. Тому з точки зору взаємодії виникло безліч різноманітних рішень. Проте в основному все ще необхідно покладатися на ці компоненти. Далі ми обговоримо кілька типових проектів концепцій абстракції ланцюга, щоб подивитися, як кожен з них вирішує проблему ліквідності обдурюючи людей, як лохів, з власної точки зору.

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

Деяка мережа побудувала три ключові компоненти: сумісний рівень Intent, Validity та універсальний рівень розрахунків.

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

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

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

Якийсь фонд є розробником ринку ZK обчислювальної потужності Ethereum, ZK ко-процесорів та Рівня 2, команда має глибокі знання в технології ZK. Вони запропонували рішення zkSharding, яке використовує технологію ZK для горизонтального масштабування основної мережі Ethereum, виконує парал обробку транзакцій з поділом на частини та генерує ZKP, тоді як основна частина перевіряє дані, спілкується з Ethereum та синхронізує мережевий стан між усіма валідаторами. Основна частина також управляє розподілом валідаторів та облікових записів у виконавчих частинах. Протокол консенсусу, що використовується комісією з перевірки, також є Hotstuff, що досить поширено в останніх проектах паралельного виконання. L2 цього фонду з самого початку вбудував міжчастинну комунікацію в протокол.

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

Ефіріум також працює над вирішенням цієї проблеми ліквідності між ланцюгами, наразі певний Рівень 2 та певний DEX спершу відкрито підтримують певний стандарт, який також базується на міжланцюговому методі на основі намірів. Його основна мета полягає у створенні загального стандарту для міжланцюгових операцій між L2 та бічними ланцюгами, стандартизації замовлень та розрахункових інтерфейсів, забезпеченні безшовного виконання міжланцюгових операцій, головна суть полягає в тому, що заповнювач, також можна сказати, що виконує роль Solver в абстракції ланцюга. Цю пропозицію спільно розробили певний DEX та певний проект, наразі вона перебуває на розгляді робочою групою.

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

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

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

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

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

![Рівень 2时代下，Ліквідність обдурювати людей, як лохів问题的研究](