Статья опубликована с разрешения: Gate Ventures

Введение

С тех пор как Ethereum перешел на масштабируемые решения с учетом уровня 2, и в связи с ростом таких инструментов, как RaaS, многие публичные цепочки быстро развиваются. Многие организации стремятся создать свои собственные цепи, чтобы представлять разные интересы и добиться более высокой оценки. Однако появление множества публичных цепочек затрудняет развитие экосистемы, что приводит к тому, что многие проекты терпят крах на момент TGE.

С помощью OP Stack Coinbase запустила свой собственный Base Layer 2, Kraken выпустил Ink; с использованием технологий ZK OKX запустил XLayer; Sony выпустил Soneium, LINE выпустил Kaia и др. Теперь финансирование и технический порог для создания цепочки значительно снизились, стоимость эксплуатации цепочки на основе OP Stack составляет около 10 000 долларов в месяц.

Будущее, безусловно, будет эпохой сосуществования многослойности. Несмотря на то, что эти цепочки уровня 2 могут выбирать совместимость с EVM для обеспечения взаимосвязи, из-за большого количества downstream приложений у их задействованных Web2-сущностей сложно строить приложения на одной цепочке и достигать консенсуса.

Разбивка 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 (Solver Layer)

Этот уровень отвечает за получение и реализацию намерений пользователей. Роль Solver здесь конкурирует, чтобы предоставить лучший пользовательский опыт, включая более быстрое время транзакции и скорость исполнения. На этой основе проекты, основанные на намерениях, такие как Anoma, разработали различные решения, ориентированные на намерения. Производные от таких намерений, такие как компоненты Predicate, могут реализовывать намерения пользователей при соблюдении определенных условий.

Уровень расчетов (Settlement Layer)

Это промежуточный уровень, который Solver использует для реализации намерений пользователей. Основные компоненты решения проблем ликвидности и распределения состояния включают:

  • Оракул (Oracle): используется для получения информации о состоянии других цепочек.

  • Мосты (Bridges): отвечают за передачу информации и ликвидности между цепочками.

  • Предварительное подтверждение (Pre-Confirmation): сокращение времени подтверждения между цепочками.

  • Доступность данных (DA): обеспечивает доступность данных.

Кроме того, необходимо учитывать такие факторы, как межцепочечная ликвидность, окончательная подтверждаемость (финальность), механизмы доказательства второго уровня и т.д., чтобы обеспечить эффективную работу всей многослойной системы.

Решение

В настоящее время на рынке существует множество решений для проблемы разрыва ликвидности. Мы изучили множество решений и обнаружили, что основные способы такие:

1. Центрированное на RaaS: решения типа Rollup, такие как OP Stack, помогают строить Rollup с общей ликвидностью и состоянием, добавляя специальные совместные сортировщики и межцепочечные мосты. Это должно помочь решить проблемы распределения ликвидности и состояния на более высоком уровне. Здесь имеется более детализированный подход к отдельному проектированию совместного сортировщика, который в основном касается уровня 2 и не обладает универсальностью, как 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 и др. Эти проекты требуют управления сложными межцепочечными процессами, что предъявляет высокие требования к разработчикам и делает их уязвимыми для атак хакеров.

Решение проблемы ликвидности является чрезвычайно важной задачей, поскольку в финансовом мире ликвидность часто представляет все. Если удастся создать интегрированную платформу ликвидности, особенно объединяющую разрозненную ликвидность всей цепочки, это имеет огромный потенциал. Мы также рассмотрели множество различных решений.

В двух вышеуказанных категориях мы можем увидеть, что согласно структуре пирога уровень расчетов является самым атомарным решением, на этих атомарных решениях, таких как межцепочечные, оракулы, решения по предварительному подтверждению и т.д., построен более абстрактный уровень, а именно уровень Solver, уровень разрешений и уровень приложения. Все перечисленные нами решения, построенные в различных направлениях, соответствуют этой системе разных уровней, и их можно понимать как отношения между верхним и нижним уровнем. Однако эти решения все еще не являются атомарными, и проблема разрыва ликвидности вызывает множество сложных производных проблем. Поэтому для обеспечения взаимосвязи возникли разнообразные решения. Но, по сути, они все еще зависят от этих компонентов. Далее мы обсудим несколько типичных проектов концепции абстракции цепочки, чтобы увидеть, как каждый из них решает проблему разрыва ликвидности с своей точки зрения.

INFINIT

Структура INFINIT, источник: Infinit

INFINIT разработал сервис RaaS для DeFi, который может предоставлять компоненты, необходимые для непосредственного создания DeFi-протоколов, такие как оракулы, типы пулов, IRM, активы и т.д., также может предоставлять компоненты для немедленного использования, такие как Leverage Trading и Yield Strategy. Это как бы другие приложения для создания, но конечная ликвидность находится на уровне ликвидности Infinit. Однако в настоящее время он все еще не раскрывает принципы своего внутреннего устройства. В настоящее время INFINIT привлек 6 миллионов долларов в виде начальных инвестиций от таких компаний, как Robot Ventures, Electric Capital и Maelstrom Capital.

Сеть Khalani (Khalani Network)

Структура сети Khalani, источник: KhalaniNetwork

Khalani построил три основных компонента: совместимый слой намерений, действительность и общий расчетный слой.

Внешние приложения или уровень намерений могут публиковать намерения в Khalani, а затем совместимый слой намерений Khalani может преобразовать внешние намерения в формат, который может распознавать протокол Solver, используя стандартизованный формат, именуемый языком действительности. Узел 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; ранее 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 с самого начала внедрил межшардовую связь в протокол. Межшардовые сообщения проверяются комитетом валидаторов каждого шарда как транзакции.

Основная идея заключается в том, чтобы с помощью архитектуры уровня 2, основанной на шардировании, создать встроенную межшардовую коммуникационную архитектуру, аналогичную IBC, которая сможет решить проблемы ликвидности и распределения состояния. Однако основная идея не является разумной, поскольку проблемы с распределением ликвидности касаются многослойности, а создаваемая архитектура является единственным уровнем 2, что означает, что для решения этой проблемы необходимо, чтобы все цепочки стали частью 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 являются решениями для ликвидности между уровнями 2 в Ethereum, которые решают проблему фрагментации ликвидности на архитектурном, уровне консенсуса и уровне приложений. OP Stack проектирует полное многослойное решение, чтобы единовременно решить проблемы передачи информации и децентрализации Sequencer. Когда вы используете архитектуру OP Stack, автоматически развертываются межцепочечные контракты, и существует супервизор, который бросает вызов, чтобы избежать передачи ложной межцепочечной информации. В настоящее время такие компании, как Coinbase, Uniswap, Kraken и другие используют архитектуру OP Stack.

Примером является Unichain. Unichain в основном решает проблемы фрагментации ликвидности межцепочечного взаимодействия через интеграцию с сетью Superchain. Эта настройка облегчает бесшовное перемещение ликвидности, предоставляя следующие функции:

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

Сеть верификации Unichain (UVN): эта сеть децентрализованных операторов узлов проверяет межцепочечные транзакции и обеспечивает более быструю экономическую финальность. Более быстрая финальность жизненно важна для обеспечения эффективных расчетов межцепочечных транзакций, что значительно снижает риск фрагментации ликвидности из-за задержек с расчетами.

Flashblocks и проверяемое построение блоков: используя Flashblocks, Unichain значительно сократил время блокировки, повысил эффективность поставщиков ликвидности и создал более согласованный межцепочечный рынок. Flashblocks помогают обеспечить доступность ликвидности в любое время и снизить негативные последствия задержек подтверждения блоков, которые могут привести к фрагментации ликвидности.

Резюме

Решение проблемы межцепочечной ликвидности — это очень сложная сфера с множеством решений. Например, решения уровня 2 делятся на встроенные межцепочечные сообщения Ethereum, особенно ERC-7683, и на OP Stack, построенный OP для совместного использования Sequencer. Вне контекста уровня 2 все уровни 1 также сталкиваются с проблемами фрагментации ликвидности, состояния и пользовательского опыта. Существуют решения, сосредоточенные на приложениях, предназначенные специально для ликвидности, а также решения, основанные на сети Solver, и даже решения, подобные NEAR, которые сосредоточены на аккаунте, но также требуют роли Solver в сети.

Мы считаем, что проблемы с межцепочечной ликвидностью, состоянием и пользовательским опытом являются проблемами всей блокчейн-индустрии. Если рассматривать это в более общем плане, необходимо подойти к этому более абстрактно, как к абстракции цепочки, что фактически является настоящим входом в Web3, решая проблемы разрыва пользовательского опыта и объединяя ликвидность и состояние в местах, которые пользователи не могут заметить. Как именно это объединить, также делится на использование сети Solver вне цепочки и атомарные мосты для межцепочечных соединений и другие средства, которые стоит обсудить. В целом, будущее однозначно будет многослойным, и решение проблемы распределения ликвидности является неизбежной задачей для отрасли. Объединение ликвидности всей цепочки имеет огромное пространство для роста и может привести к созданию Google эпохи Web3.