Estudo sobre o problema de liquidez fazer as pessoas de parvas na era da Camada 2

Com a transição do Ethereum para soluções de escalabilidade baseadas em Camada 2, juntamente com o surgimento de ferramentas como RaaS, muitas blockchains públicas estão se desenvolvendo rapidamente. Muitas entidades desejam construir suas próprias cadeias para representar diferentes interesses e buscar uma avaliação mais alta. No entanto, a emergência de numerosas blockchains públicas dificultou o desenvolvimento do ecossistema, fazendo com que muitos projetos se desvalorizassem no momento do TGE.

Aproveitando o OP Stack, uma plataforma de negociação lançou sua própria Camada 2, outra plataforma lançou o Ink; utilizando a tecnologia ZK, uma plataforma lançou o XLayer; a Sony lançou o Soneium e a LINE lançou o Kaia, entre outros. Hoje em dia, o financiamento e a tecnologia para construir uma cadeia foram significativamente 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 Camada 2 possam optar pela compatibilidade com EVM para alcançar a interoperabilidade, devido à grande quantidade de aplicações downstream das entidades Web2 por trás delas, é difícil construir aplicações e alcançar consenso na mesma cadeia.

O ecossistema multichain atual trouxe um novo desafio: Liquidez e descentralização de estado. Dado que a existência do multichain é inevitável, a interoperabilidade é um campo que deve ser explorado e resolvido. Atualmente, existem muitas soluções de liquidez, como abstração de cadeia, intenção, Clearing Execution, Native CrossChain, ZKSharding, mas sua essência central é a mesma.

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

Camada de Aplicação (Application Layer)

Esta é a camada com a qual os usuários interagem diretamente, e também é a camada mais abstrata nas soluções de liquidez, pois oculta completamente os detalhes da conversão de liquidez. Na camada de aplicação, os usuários interagem com a interface frontal, sem necessariamente entender o mecanismo de conversão de liquidez subjacente.

Camada de Permissão (Permission Layer)

Localizado abaixo da camada de aplicação, os utilizadores satisfazem a intenção de negociação ligando a carteira à dApp e solicitando um orçamento. Aqui, a "intenção" refere-se ao resultado final esperado da negociação (ou seja, a saída), e não ao caminho específico de execução da negociação.

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

Devido à existência de um ambiente multichain, é necessário um sistema de gestão de contas e abstração que se adapte a diferentes cadeias para manter as estruturas de contas únicas de cada cadeia. Por exemplo, o sistema de contas centrado em objetos da SUI é completamente diferente do EVM. O One Balance é um projeto representativo nesta área, que construiu um sistema de contas confiável, sem a necessidade de estabelecer um consenso intercadeias, apenas com compromissos confiáveis entre os sistemas de contas existentes. A Near Account realiza a gestão abstraída criando carteiras de contas multichain para os usuários, otimizando grandemente a experiência do usuário e reduzindo a fragmentação da UX. No entanto, em termos de liquidez, integrou principalmente as cadeias públicas existentes.

Camada de Solução (Solver Layer)

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

Camada de Liquidação (Settlement Layer)

Esta é a camada intermediária utilizada para resolver a intenção do usuário. Os componentes principais da solução de liquidez e estado descentralizado incluem:

• Oracle: utilizado para obter informações de estado de outras cadeias.
• Pontes (Bridges): 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): fornece a acessibilidade dos dados.

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

Atualmente, existem várias soluções no mercado para a liquidez dividida. Após analisarmos diversas opções, constatamos que as principais formas são estas:

1. Centrado em RaaS: Soluções de Rollup como o OP Stack, que ajudam a compartilhar liquidez e estado nos Rollups construídos no OP Stack, ao adicionar ordenadores compartilhados e pontes entre cadeias específicas. Isso visa resolver a dispersão de liquidez e estado de uma forma mais elevada. Um aspecto mais detalhado é o design separado de ordenadores compartilhados, que é mais direcionado à Camada 2 e não possui aplicabilidade universal.

2. Centrado na conta: construir uma carteira de conta em toda a cadeia, suportada por uma tecnologia chamada "assinatura em cadeia" para assinar e executar transações através de múltiplos protocolos de blockchain. O componente central é a rede MPC, que substitui o usuário na assinatura de transações em várias cadeias. Esta solução, embora possa resolver significativamente o problema da fragmentação da experiência do utilizador, envolve uma implementação de backend complexa para os desenvolvedores e não resolve essencialmente a liquidez e a dispersão de estado.

3. Com a rede de intenção off-chain como centro: ou seja, a nossa rede Solver no diagrama da estrutura do bolo da "introdução", o núcleo é que os usuários enviam intenções para a rede Solver, e este papel de Solver compete por cotações, fornecendo 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 o protocolo integrado. Embora a intenção possa, em teoria, realizar operações cross-chain de complexidade arbitrária, na prática, é necessário ter Solvers com liquidez suficiente para ajudar, e ao enfrentar algumas necessidades off-chain, existe a possibilidade de fraudes por parte dos Solvers. Se forem introduzidos métodos como a prova de fraude, a dificuldade de implementar a Rede Solver aumentará, assim como a barreira de entrada para operar um Solver.

4. Centrado na rede de liquidez on-chain: essa direção é especificamente otimizada para problemas de liquidez entre cadeias, mas não resolve o problema da dispersão de estados em outras cadeias. Seu núcleo é construir uma camada de liquidez, na qual aplicações são construídas para compartilhar liquidez em toda a cadeia.

5. Centrado em aplicações on-chain: Este tipo de aplicação constrói aplicações de alta liquidez integrando grandes MM ou aplicações de terceiros. Estes projetos precisam gerir processos complexos entre cadeias, exigindo muito dos desenvolvedores, sendo assim, são também muito suscetíveis a ataques de hackers.

Resolver o problema da liquidez é uma questão muito importante, no mundo financeiro a liquidez muitas vezes representa tudo. Se for possível construir uma plataforma de liquidez integrada, especialmente integrando a liquidez fragmentada de toda a cadeia, terá um grande potencial, e também analisámos muitas soluções diferentes.

Nas duas classificações acima, podemos ver que, de acordo com a estrutura do bolo, a Camada de Liquidação é a solução mais atômica. Acima dessas soluções atômicas, como as de cross-chain, oráculos e Pre-Confirmation, existe uma camada mais abstrata, que é a Camada Solver, Camada de Permissão e Camada de Aplicação. As várias soluções de abstração ou Liquidez que listamos acima, construídas em diferentes direções, se encaixam nesses diferentes níveis, 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. O problema da fragmentação da liquidez trouxe à tona muitos problemas derivados complexos, levando ao surgimento de uma variedade de soluções para interoperabilidade. Mas, essencialmente, ainda dependemos desses componentes. A seguir, discutiremos alguns projetos típicos que abordam conceitos de abstração de cadeias, para ver como cada um deles resolve o problema da fragmentação da liquidez a partir de seu próprio ponto de partida.

INFINIT construiu um serviço RaaS para o setor DeFi, que pode fornecer os componentes necessários para a construção direta de protocolos DeFi, como Oracle, Pool Type, IRM, Asset, etc., e também pode oferecer componentes como Leverage Trading e Yield Strategy 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, até agora, ainda não foi divulgada a operação subjacente.

Khalani construiu três componentes principais: a camada de compatibilidade de Intent, Validity e a camada de liquidação genérica. Aplicações externas ou a camada de intent podem publicar intents para Khalani, e então a camada de compatibilidade de Intent do Khalani pode converter as intents externas em um formato que o Solver do protocolo pode reconhecer, utilizando o formato padronizado que é a linguagem Validity. Os nós do Khalani são responsáveis por submeter o resultado final à camada de liquidação genérica através de pontes cross-chain, tecnologias de liquidação rápida, entre outros.

Liquorice é uma aplicação descentralizada que permite a descoberta de preços baseada em leilões e pools de liquidez unidirecionais. A principal missão do Liquorice é fornecer ferramentas eficientes de gestão de inventário para empresas de trading profissionais, e conectar-se facilmente aos protocolos DeFi principais 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 foca ainda mais na própria negociação.

Xion é construído sobre o 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.

=nil; A Foundation propôs a solução zkSharding, que utiliza a 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 em projetos de execução paralela mais recentes. =nil; A L2 incorporou a comunicação entre fragmentos no protocolo desde o início.

Ethereum também está a trabalhar na resolução deste problema de liquidez entre cadeias. Atualmente, algumas das principais plataformas de negociação estão a apoiar publicamente o padrão ERC7683, que também 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 as interfaces de pedidos e liquidação, visando uma execução cross-chain sem costura. O núcleo principal é um Filler, que também pode ser visto como o papel de Solver na abstração de cadeia.

OP Stack resolve, através do design de uma solução completa de Camada 2, os problemas de transmissão de informações e descentralização do Sequencer de uma só vez. Ao utilizar a arquitetura OP Stack, contratos cross-chain são automaticamente implantados, ao mesmo tempo que existe um Supervisor para desafiar e evitar a transmissão de informações cross-chain falsas.

Resolver o problema da liquidez entre cadeias é um campo muito complexo e com muitas soluções. As soluções da Camada 2 incluem a mensagem entre cadeias embutida no Ethereum, especialmente o ERC-7683, além da Camada 2, como o OP, que constrói o OP Stack para compartilhar Sequencer. Fora do contexto da Camada 2, todas as Camadas 1 também enfrentam problemas de liquidez, estado e fragmentação da experiência do usuário. Existem soluções especializadas centradas em aplicações para liquidez, bem como soluções fora da cadeia como a Solver Network, e até mesmo soluções centradas em contas como a NEAR, mas que também precisam se basear em papéis fora da cadeia como o Solver.

A liquidez, o estado e a fragmentação da experiência do usuário entre cadeias são problemas de toda a indústria de blockchain. Se pensarmos de forma mais abrangente, precisamos abordar isso de uma maneira mais abstrata, semelhante à abstração de camada, o que equivale a ser verdadeiramente