Estudo sobre o problema da liquidez em Camada 2

Com a Ethereum a mudar para soluções de escalabilidade centradas na Camada 2, juntamente com o surgimento de ferramentas como RaaS, muitas blockchains públicas estão a desenvolver-se rapidamente. Muitas entidades desejam construir a sua própria blockchain para representar diferentes interesses e procurar uma avaliação mais alta. No entanto, o surgimento de numerosas blockchains públicas dificultou o desenvolvimento do ecossistema, fazendo com que muitos projetos desvalorizassem já no TGE.

Aproveitando o OP Stack, uma plataforma de negociação lançou sua própria Camada 2, outra plataforma de negociação lançou o Ink; aproveitando a tecnologia ZK, mais uma plataforma de negociação lançou o XLayer; a Sony lançou o Soneium, a LINE lançou o Kaia, entre outros. Hoje em dia, o custo e a barreira técnica para construir uma cadeia foram grandemente reduzidos, e o custo para operar uma cadeia baseada no OP Stack é de cerca de 10.000 dólares por mês.

O futuro será sem dúvida uma era de coexistência de múltiplas cadeias. Embora essas Camadas 2 possam optar pela compatibilidade com EVM para alcançar a interoperabilidade, devido às entidades Web2 por trás delas terem um grande número de aplicações downstream, é difícil construir aplicações na mesma cadeia e alcançar consenso.

O ecossistema multi-chain atual trouxe um novo desafio: Liquidez e dispersão de estado. Como a existência de múltiplas cadeias é inevitável, a interoperabilidade é um campo que precisa ser explorado e resolvido. Atualmente, existem várias soluções de liquidez, como todos nós ouvimos falar de abstração de cadeia, intenção, Execução de Clearing, CrossChain Nativo, ZKSharding, mas sua essência central é a mesma.

Utilizamos a arquitetura Cake, reconhecida na indústria, para apresentar de cima para baixo a composição dos componentes centrais da abstração de cross-chain:

Camada de Aplicação ( Camada de Aplicação )

Esta é a camada de interação direta do usuário, e também é a camada mais abstrata nas soluções de liquidez, pois oculta totalmente os detalhes da conversão de liquidez. Na camada de aplicação, os usuários interagem com a interface frontal, sem necessariamente compreender o mecanismo de conversão de liquidez subjacente.

Camada de Permissão (Permission Layer)

Situado abaixo da camada de aplicação, os usuários satisfazem a intenção de negociação conectando a carteira ao dApp e solicitando cotações. Aqui, a "intenção" refere-se ao resultado final da negociação esperado pelo usuário (, ou seja, a saída ), em vez do caminho específico de execução da negociação.

Gestão de Conta e Abstração de Camada (Key Management and Account Abstraction)

Devido à existência de um ambiente de múltiplas cadeias, é necessário um sistema de gestão de contas e abstração que se adapte a diferentes cadeias para manter a estrutura única das contas de cada cadeia. Por exemplo, o sistema de contas centrado em objetos da SUI é completamente diferente do EVM. O One Balance é um projeto representativo neste campo, que constrói um sistema de contas confiável, sem necessidade de estabelecer consenso entre cadeias, apenas exigindo compromissos confiáveis entre os sistemas de contas existentes. O Near Account implementa a gestão abstrata gerando carteiras de contas de múltiplas cadeias para os usuários, otimizando significativamente a experiência do usuário e reduzindo a fragmentação da UX. No entanto, a liquidez está principalmente integrada nas cadeias públicas existentes.

Resolver Camada ( Camada )

A camada 2 é responsável por receber e implementar as intenções de negociação dos usuários. O papel do Solver compete aqui para oferecer uma melhor experiência ao usuário, incluindo tempos de transação mais rápidos e velocidades de execução. Com base nisso, projetos baseados em intenções, como a Anoma, construíram várias soluções impulsionadas por intenções. Derivados dessas intenções, como o componente Predicate, podem realizar as intenções dos usuários sob regras específicas.

Camada de Liquidez (Settlement Layer )

Este é o nível intermediário utilizado para resolver a camada para realizar a intenção do usuário. Os componentes principais das soluções de liquidez e estado descentralizado incluem:

• 预言机(Oracle): utilizado para obter informações de estado de outras cadeias.
• Pontes de cadeia cruzada (: responsáveis pela transmissão de informações e liquidez entre cadeias.
• Confirmação antecipada ) Pre-Confirmation (: reduzir o tempo de confirmação entre cadeias.
• Disponibilidade de dados )DA(: fornecer acessibilidade aos dados.

Além disso, também é necessário considerar a liquidez entre cadeias, a finalidade )Finality(, mecanismos de prova da Camada 2 e outros fatores, para garantir a operação eficiente de todo o sistema multichain.

) Solução

Atualmente, existem várias soluções no mercado para resolver a liquidez fragmentada. Após analisarmos uma grande quantidade de soluções, descobrimos que as principais são estas:

1. Centrado em RaaS: soluções de Rollup como o OP Stack, que assistem na construção de Rollups compartilhando liquidez e estado através da adição de um ordenado compartilhado específico e pontes entre cadeias. Isso visa resolver a liquidez e o estado disperso em um nível mais elevado. Dentro disso, há um design mais específico para um ordenado compartilhado separado, que se destina mais a Camada 2, não sendo universal, como Astria, Espresso e Flashbots.

2. Centrado na conta: semelhante ao NEAR, construir uma carteira de conta em toda a cadeia, suportando a assinatura e execução de transações através de múltiplos protocolos de blockchain por meio de uma tecnologia chamada "assinatura em cadeia". O componente central é a rede MPC, que assina transações multi-chain em nome do usuário. Este conjunto de soluções, embora resolva em grande parte o problema da fragmentação da experiência do usuário (UX), envolve implementações de backend complexas para os desenvolvedores e não resolve essencialmente a liquidez e a dispersão de estado.

3. Centrado na rede de intenção off-chain: ou seja, a nossa "introdução" ao diagrama da estrutura do bolo da Rede Solver, o núcleo é o usuário que envia intenções para a rede Solver, onde o papel do Solver compete por cotações, oferecendo o melhor tempo de conclusão e preço de transação. Esses Solvers podem ser Agentes de IA, CEX, Market Makers ou até mesmo protocolos integrados como Liquorice. Projetos nesta área incluem Anoma, Khalani, Enso, aori e Valantis. Embora a intenção possa teoricamente realizar operações cruzadas de qualquer complexidade, na prática, é necessário ter Solvers com liquidez suficiente para ajudar, e quando surgem algumas demandas off-chain, existe a possibilidade de fraude por parte dos Solvers. Se forem introduzidos métodos como provas de fraude, a dificuldade de implementação da Rede Solver aumentará, assim como a barreira de entrada para operar como Solver.

4. Com a rede de liquidez em cadeia como centro: esta direção é especificamente otimizada para os problemas de liquidez entre cadeias, mas não resolve outros problemas de estado disperso em cadeia. O seu núcleo é construir uma camada de liquidez, na qual as aplicações são construídas, para compartilhar a liquidez total da cadeia. Alguns projetos incluem: Raye Network, INFINIT, Everclear, Elixir, entre outros.

5. Centrado em aplicações em cadeia: Este tipo de aplicação constrói aplicações de alta liquidez através da integração de grandes MM ou aplicações de terceiros, como Liquorice, Socket, Radiant Capital, 1inch, Hedgemony, entre outros. Este tipo de projeto requer a gestão de processos complexos de cross-chain, o que exige um elevado nível de habilidade dos desenvolvedores, tornando-os também muito suscetíveis a ataques de hackers.

Resolver o problema da liquidez é um tema muito importante, no mundo financeiro a liquidez muitas vezes representa tudo. Se conseguirmos construir uma plataforma de liquidez integrada, especialmente integrando a liquidez dispersa de toda a cadeia, teremos um potencial muito grande, e também vimos muitas soluções diferentes.

Nas duas classificações acima, podemos ver que, com base na estrutura do bolo, a Settlement Layer é a solução mais atômica, e acima dessas soluções atômicas, como as soluções de cross-chain, oráculos e Pre-Confirmation, constrói-se uma camada mais abstrata, que é a Solver Layer, Permission Layer e Application Layer. As várias soluções de abstração ou liquidez que listamos acima, construídas em diferentes direções, se encaixam nesta hierarquia, podendo ser entendidas como uma relação de upstream e downstream. No entanto, essas soluções ainda não são soluções atômicas, e o problema da fragmentação da liquidez trouxe à tona muitos problemas derivados complexos, resultando em uma variedade de soluções para interoperabilidade. Mas, essencialmente, ainda dependemos desses componentes. A seguir, discutiremos alguns projetos típicos de conceitos de abstração de cadeia para ver como cada um deles aborda o problema da fragmentação da liquidez a partir de seu próprio ponto de partida.

![Camada 2时代下，Liquidez fazer as pessoas de parvas问题的研究]###https://img-cdn.gateio.im/webp-social/moments-e170f453d0b5b33f7ffc55facc9626c8.webp(

)# INFINIT

A INFINIT construiu um serviço RaaS no espaço DeFi, capaz de fornecer os componentes necessários para a construção direta de protocolos DeFi, como Oracle, Tipo de Pool, IRM, Ativo, entre outros, além de oferecer componentes como Negociação com Alavancagem e Estratégia de Rendimento que podem ser ativados imediatamente. É equivalente a outros pontos de construção de aplicativos, mas a liquidez final é colocada na camada de liquidez da Infinit. No entanto, atualmente ainda não foi revelado o funcionamento interno. Atualmente, a INFINIT já obteve 6 milhões de dólares em uma rodada de financiamento seed de algumas instituições de investimento conhecidas.

Khalani Network

Khalani construiu três componentes centrais, que são a Camada de Compatibilidade de Intenção, Validade e a Camada de Liquidação Geral.

A aplicação externa ou a camada de intenções pode publicar intenções para o Khalani, e então a camada de compatibilidade de intenções do Khalani pode converter as intenções externas em um formato que o Solver de protocolo pode reconhecer, utilizando o formato normalizado que é a linguagem Validity. O nó Khalani é responsável por submeter o resultado final à camada de liquidez geral através de pontes de cross-chain, técnicas de liquidação rápida, etc. Este projeto ainda está em fase de construção, e mais detalhes do trabalho ainda não foram divulgados. Em agosto, obteve 2,2 milhões de dólares em financiamento de sementes de algumas instituições de investimento conhecidas.

Liquorice

Liquorice é uma aplicação descentralizada que permite a descoberta de preços baseada em leilões e pools de liquidez unidirecionais. A missão principal do Liquorice é fornecer ferramentas eficientes de gestão de inventário para empresas de trading profissionais e conectar-se facilmente a alguns protocolos DeFi essenciais ao liquidar transações com intenção de uso. Ao mesmo tempo, o Liquorice criou um mercado de empréstimos para realizar transações de empréstimo. Esta aplicação está mais focada na própria negociação. Atualmente, ainda está em fase de desenvolvimento, tendo anunciado em julho que obteve um financiamento de 1,2 milhões de dólares na ronda Pre-seed de algumas instituições de investimento renomadas.

Xion

Xion é uma atualização da marca Burnt, que anteriormente se concentrava em aplicações para consumidores. Depois, a equipe descobriu que havia um grande problema de fragmentação nas interações em cadeia, por isso construíram o Xion para melhorar essa questão. O Xion é baseado no protocolo de consenso Comet BFT. A comunicação entre cadeias que utiliza é baseada no Cosmos IBC, tornando-a mais nativa e segura do que outras pontes entre cadeias. Já passou por quatro rodadas de financiamento, com investidores de algumas instituições de investimento conhecidas.

=nil; Fundação

nil é o mercado de poder computacional ZK do Ethereum, um co-processador ZK e desenvolvedor de Camada 2, com uma equipe que possui uma base sólida em tecnologia ZK. Foi proposta a solução zkSharding, que utiliza tecnologia ZK para escalar horizontalmente a rede principal do Ethereum, executando o processamento paralelo de fragmentos e gerando ZKP, enquanto o fragmento principal valida dados, comunica-se com o Ethereum e sincroniza o estado da rede entre todos os validadores. O fragmento principal também gerencia a distribuição de validadores e contas no fragmento de execução. O protocolo de consenso utilizado pelo comitê de validação é também o Hotstuff, que é comum nos projetos de execução paralela mais recentes. =nil; A L2 integrou a comunicação entre fragmentos no protocolo desde o início. As mensagens entre fragmentos são validadas pelo comitê de validadores de cada fragmento como transações.

A ideia básica é construir uma arquitetura de comunicação entre fragmentos embutida, semelhante ao IBC, através de uma arquitetura de Layer 2 fragmentada, assim será possível resolver os problemas de Liquidez e dispersão de estado. No entanto, a ideia central não é razoável, pois o problema que a dispersão de Liquidez resolve é um problema de múltiplas cadeias; a construção proposta é uma Layer 2 única, o que significa que, para resolver, todas as cadeias teriam que se tornar um fragmento de ZK-sharding, o que é difícil de realizar.

ERC-7683

A Ethereum também está a trabalhar na resolução deste problema de liquidez entre cadeias. Neste momento, alguns projetos conhecidos apoiam publicamente o padrão ERC7683, que utiliza um método de cross-chain baseado em Intent. O objetivo central é estabelecer um padrão comum para operações cross-chain entre L2 e sidechains, padronizando interfaces de pedidos e liquidação, para permitir uma execução cross-chain sem interrupções. O principal núcleo é um Filler, que também pode ser considerado o papel de Solver na abstração da cadeia para apoiar os pagamentos. Esta proposta está a ser construída em conjunto por alguns projetos conhecidos e está atualmente a ser revista pelo grupo de trabalho da Cake.

OP Stack

OP Stack, ERC-7683 e zkSharding são soluções internas do Ethereum para a fragmentação da liquidez entre a Camada 2, abordando isso em níveis de arquitetura, consenso e aplicação, respectivamente. O OP Stack resolve de uma vez os problemas de transmissão de informações e descentralização do Sequencer ao projetar uma solução completa multi-Camada 2. Ao usar a arquitetura OP Stack, contratos cross-chain são automaticamente implementados, e existe um Supervisor para desafiar e evitar a transmissão de informações falsas cross-chain. Atualmente, alguns projetos conhecidos usam a arquitetura OP Stack.

Entre eles, o mais típico é o Unichain. O Unichain resolve o problema da fragmentação da liquidez entre cadeias principalmente através da integração com a rede Superchain. Esta configuração facilita o movimento de liquidez sem costura, proporcionando as seguintes funcionalidades:

Ponte跨链 baseada em intenção: esta