Estudo sobre o problema da liquidez fragmentada na era da Camada 2

Após a Ethereum ter mudado para soluções de escalabilidade centradas na 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 proliferação de blockchains públicas dificultou o desenvolvimento do ecossistema em acompanhar o ritmo das blockchains públicas, levando muitos projetos a enfrentarem dificuldades desde o início.

Aproveitando o OP Stack, uma plataforma de negociação lançou sua própria Camada 2, enquanto outra plataforma de negociação lançou um novo projeto de blockchain; com a tecnologia ZK, uma plataforma de negociação lançou uma nova camada. Algumas grandes empresas de tecnologia também lançaram seus próprios projetos de blockchain. Hoje em dia, o capital e a tecnologia necessários para construir uma cadeia foram significativamente reduzidos, e o custo de 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 ao grande número de aplicações downstream das empresas de tecnologia tradicionais 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 dispersão de estados. Dado que a existência de multichain é inevitável, a interoperabilidade é um campo que precisa ser explorado e resolvido. Atualmente, existem muitas soluções de liquidez, como abstração de cadeia, intenção, Clearing Execution, Native CrossChain, ZKSharding, entre outras, mas a sua essência central é a mesma.

Usamos 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: 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ões: localizada abaixo da camada de aplicação, os usuários conectam a carteira ao dApp e solicitam cotações para satisfazer a intenção de negociação. Aqui, a "intenção" refere-se ao resultado final esperado da transação pelo usuário, e não ao caminho específico de execução da transação.

Gestão de contas e camada abstrata: Devido à existência de um ambiente multi-chain, é necessário um sistema de gestão de contas e abstração que se adapte a diferentes cadeias para manter a estrutura de contas única de cada cadeia. Alguns projetos construíram um sistema de contas confiável, sem a necessidade de estabelecer um consenso entre cadeias, apenas requerendo um compromisso confiável entre os sistemas de contas existentes. Outros projetos realizam a gestão abstrata gerando carteiras de contas multi-chain para os usuários, otimizando consideravelmente a experiência do usuário e reduzindo a fragmentação da UX. No entanto, em termos de liquidez, foi principalmente integrada a blockchain pública existente.

Camada 2: Esta camada é responsável por receber e implementar as intenções 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 maior velocidade de execução. Com base nisso, diversos projetos orientados por intenções foram construídos. Derivados de tais intenções, como o componente Predicate, podem realizar as intenções do usuário sob regras específicas.

Camada de liquidação: esta é a camada de middleware utilizada pela camada de solução para realizar a intenção do usuário. Os componentes principais das soluções de liquidez e dispersão de estado incluem: oráculos, pontes entre cadeias, esquemas de confirmação antecipada e disponibilidade de dados. Além disso, devem ser considerados fatores como liquidez entre cadeias, confirmação final, mecanismos de prova da Camada 2, entre outros, para garantir a operação eficiente de todo o sistema multichain.

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

1. Centrado em RaaS: semelhante a algumas soluções Rollup, assistindo na construção de Rollups por meio da adição de ordenadores compartilhados específicos e pontes entre cadeias para compartilhar liquidez e estado. Isso espera resolver a liquidez e a dispersão de estado em uma direção de nível mais alto. Dentro disso, há um design mais segmentado que é o ordenadores compartilhados separados, esta solução é mais direcionada para a Camada 2, não possui universalidade.

2. Centrado na conta: construir uma carteira de conta em toda a cadeia, suportada por uma tecnologia chamada "assinatura em cadeia" que permite a assinatura e execução de transações através de vários protocolos de blockchain. O componente central é a rede MPC, que substitui o usuário na assinatura de transações multichain. Embora esta solução possa resolver imensamente o problema da fragmentação da experiência do usuário, para os desenvolvedores, isso envolve uma implementação de backend complexa e não resolve essencialmente a liquidez e a dispersão de estado.

3. Centrado na rede de intenções off-chain: ou seja, a Rede Solver no diagrama de arquitetura do "introdução" do nosso bolo, o núcleo é que os usuários enviam intenções para a rede Solver, esse papel de Solver compete por cotações, fornecendo o melhor tempo de conclusão e preço de negociação. Esses Solvers podem ser Agentes de IA, bolsas, formadores de mercado ou até mesmo o próprio protocolo integrado. Embora a intenção possa teoricamente realizar operações complexas entre cadeias de qualquer dificuldade, na prática, é necessário ter Solvers com liquidez suficiente para ajudar, e ao enfrentar algumas demandas off-chain, existe a possibilidade de fraude por parte dos Solvers. Se forem introduzidos meios como provas de fraude, a dificuldade de implementação da Rede Solver se tornará maior, assim como o limiar para operar como Solver.

4. Centrado na rede de liquidez on-chain: esta direção é especificamente otimizada para o problema de liquidez entre cadeias, mas não resolveu o problema da dispersão do estado on-chain de outras cadeias. O núcleo é construir uma camada de liquidez, na qual as aplicações são construídas para compartilhar a liquidez de toda a cadeia.

5. Centrado em aplicações on-chain: este tipo de aplicações constrói aplicações de alta liquidez através da integração de grandes market makers ou aplicações de terceiros. Estes projetos precisam gerir processos complexos entre cadeias, exigindo um alto nível de habilidade dos desenvolvedores, portanto, são também muito suscetíveis a vulnerabilidades de segurança.

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

Nas duas classificações acima, podemos ver que, de acordo com a estrutura do bolo, a Settlement Layer é a solução mais atómica, e acima dessas soluções atómicas, como as 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, correspondem a esses diferentes níveis e podem 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 liquidez fragmentada traz à tona muitos problemas derivados complicados, portanto, para a interoperabilidade, surgiram uma variedade de soluções. Mas, essencialmente, ainda depende desses componentes.

A seguir, discutiremos alguns projetos típicos de conceitos de abstração de cadeia, para ver como cada um resolve o problema da liquidez de forma diferente.

Um determinado projeto construiu um serviço RaaS no campo do DeFi, que pode fornecer os componentes necessários para a construção direta de protocolos DeFi, como Oracle, Pool Type, IRM, Asset, entre outros, 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 aplicações, mas a liquidez final é colocada na camada de liquidez desse projeto. No entanto, atualmente ainda não revelou o funcionamento subjacente.

Outro projeto construiu três componentes principais, que são a camada de compatibilidade de Intent, Validity e a camada de liquidez geral. Aplicações externas ou a camada de intent podem publicar intents para este projeto, e então sua camada de compatibilidade de Intent pode converter as intents externas em um formato que o Solver do protocolo pode reconhecer, usando o formato normalizado que é a linguagem Validity. Os nós deste projeto são responsáveis por enviar o resultado final para a camada de liquidez geral através de pontes cross-chain, tecnologia de liquidação rápida, entre outros. Este projeto ainda está em fase de construção e mais detalhes sobre o trabalho ainda não foram divulgados.

Há um projeto que é uma aplicação descentralizada, capaz de realizar descoberta de preços baseada em leilões e pools de liquidez unidirecionais. Sua principal missão é fornecer às empresas de trading profissionais ferramentas eficientes de gestão de inventário e conectar-se facilmente aos protocolos DeFi principais ao liquidar transações com a intenção de uso. Ao mesmo tempo, o projeto criou um mercado de empréstimos para realizar transações de empréstimo. Esta aplicação foca ainda mais na própria negociação.

Um determinado projeto é uma atualização de outra marca, que anteriormente se concentrava em aplicações para consumidores. Depois, a equipe descobriu que havia um grande problema de fragmentação nas interações na blockchain, por isso construíram um novo projeto para melhorar essa questão. Este projeto é baseado no protocolo de consenso Comet BFT. A comunicação entre cadeias utilizada é baseada no Cosmos IBC, sendo assim mais nativa e segura do que outras pontes entre cadeias.

Uma fundação é uma desenvolvedora do mercado de poder de computação ZK, do processador ZK e da Camada 2 da Ethereum, com uma equipe que possui uma sólida base em tecnologia ZK. Propôs a solução zkSharding, que utiliza a tecnologia ZK para escalar horizontalmente a rede principal da Ethereum, executando processamento paralelo de fragmentos e gerando ZKP, enquanto o fragmento principal valida dados, comunica-se com a Ethereum e sincroniza o estado da rede entre todos os validadores. O fragmento principal também gerencia a distribuição de validadores e contas nos fragmentos de execução. O protocolo de consenso usado pelo comitê de validação também é o Hotstuff, que é comum em projetos de execução paralela mais recentes. A solução incorporou 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 em fragmentos, assim poderá resolver os problemas de liquidez e dispersão de estado. No entanto, a ideia central não é razoável, porque o problema da dispersão de liquidez é um problema de múltiplas cadeias, e a construção é de uma única Layer 2, o que significa que, para resolver, todas as cadeias precisariam se tornar um fragmento do ZK-sharding, o que é difícil de realizar.

O Ethereum também está a trabalhar para resolver o problema da liquidez entre cadeias, atualmente existem vários projetos principais que apoiam publicamente um determinado padrão ERC, que utiliza também uma abordagem de cross-chain baseada em Intent. O objetivo central é estabelecer um padrão genérico para operações cross-chain entre L2 e sidechains, padronizando interfaces de pedidos e liquidação, permitindo uma execução cross-chain sem interrupções, sendo o núcleo principal um Filler que também pode ser visto como um papel de Solver na abstração da cadeia para pagamento. Esta proposta foi construída em conjunto por dois projetos principais e está atualmente a ser revista por um grupo de trabalho.

Uma pilha tecnológica, o padrão ERC mencionado acima e o zkSharding são soluções internas do Ethereum para a fragmentação da liquidez entre Camada 2, abordando isso em níveis de arquitetura, consenso e aplicação. Esta pilha tecnológica resolve de uma vez os problemas de transmissão de informação e descentralização do Sequencer, ao projetar uma solução completa de múltiplas Camadas 2. Quando você usa a arquitetura dessa pilha tecnológica, contratos entre cadeias são automaticamente implantados, e existe um Supervisor para desafiar e evitar a transmissão de informações falsas entre cadeias. Atualmente, vários projetos conhecidos estão utilizando essa arquitetura.

Resolver o problema da liquidez entre cadeias é um campo muito complexo e com muitas soluções, como as soluções da Camada 2 que se dividem em resolver através de mensagens entre cadeias embutidas no Ethereum, especialmente os padrões ERC mencionados acima, e um Sequencer compartilhado construído com um determinado stack tecnológico. Fora do contexto da Camada 2, todas as Layer1 também