Estudo sobre o problema da liquidez fragmentada na era Layer2
Com a transição do Ethereum para soluções de escalonamento centradas em Layer 2, juntamente com o surgimento de ferramentas como RaaS, muitas blockchains públicas estão a desenvolver-se rapidamente. Muitas entidades desejam construir as suas próprias cadeias para representar diferentes interesses e buscar uma avaliação mais alta. No entanto, a proliferação de blockchains públicas torna difícil para o desenvolvimento do ecossistema acompanhar o ritmo destas blockchains, resultando em muitos projetos a desvalorizarem-se logo no TGE.
Com a ajuda do OP Stack, uma plataforma de negociação lançou a sua própria Base Layer 2, outra plataforma de negociação lançou o Ink; com a tecnologia ZK, uma plataforma lançou o XLayer; a Sony lançou o Soneium, a LINE lançou o Kaia, entre outros. Hoje em dia, o financiamento e as barreiras tecnológicas para construir uma cadeia foram drasticamente 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 cadeias Layer 2 possam optar pela compatibilidade EVM para alcançar a interoperabilidade, devido às entidades Web2 por trás delas possuírem uma grande quantidade de aplicações downstream, é difícil construir aplicações na mesma cadeia e alcançar um consenso.
O ecossistema multichain atual trouxe um novo desafio: Liquidez e estado disperso. Dado que a existência de multichains é inevitável, a interoperabilidade é um campo que deve ser explorado e resolvido. Atualmente, existem muitas soluções de liquidez, como todos nós ouvimos falar de abstração de cadeia, intenção, Clearing Execution, Native CrossChain, ZKSharding, mas a sua essência central é a mesma.
Utilizamos a arquitetura Cake, amplamente reconhecida na indústria, para apresentar de cima para baixo a composição dos componentes centrais da abstração cross-chain:
Camada de Aplicação (Application Layer)
Este é o nível de interação direta do usuário, que também é a camada mais abstrata na solução de liquidez, uma vez que oculta completamente os detalhes da conversão de liquidez. Na camada de aplicação, os usuários interagem com a interface frontal, podendo não entender o mecanismo de conversão de liquidez subjacente.
Camada de Permissão (Permission Layer)
Localizado abaixo da camada de aplicação, o usuário conecta a carteira ao dApp e solicita uma cotação para satisfazer a intenção de negociação. Aqui, a "intenção" refere-se ao resultado final da negociação que o usuário espera (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 Conta (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 as estruturas de contas únicas de cada cadeia. Por exemplo, o sistema de contas centrado em objetos do SUI é completamente diferente do EVM. One Balance é um projeto representativo nesta área, que construiu um sistema de contas confiável, sem a necessidade de estabelecer consenso entre cadeias, apenas com compromissos confiáveis entre os sistemas de contas existentes. A Near Account implementa a gestão abstrata gerando carteiras de contas multi-chain para os usuários, otimizando enormemente 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.
Camada de Resolução (Solver Layer)
Esta camada é responsável por receber e implementar a intenção de negociação do usuário, onde o papel do Solver compete para oferecer uma melhor experiência ao usuário, incluindo tempos de negociação mais rápidos e velocidade de execução. Com base nisso, projetos baseados em intenção como a Anoma construíram várias soluções impulsionadas por intenção. Derivados dessa intenção, como o componente Predicate, podem realizar a intenção do usuário sob regras específicas.
Camada de Liquidação (Settlement Layer)
Este é o nível de middleware utilizado para resolver a intenção do usuário. Os componentes principais da solução de liquidez e estado disperso 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 acessibilidade aos dados.
Além disso, é necessário considerar a liquidez entre cadeias, a confirmação final (Finality), o mecanismo de prova de Layer 2, entre 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 em frangalhos. Após analisarmos várias opções, descobrimos que as principais formas são estas:
Centrado em RaaS: soluções de Rollup como OP Stack, através da adição de ordenadores compartilhados específicos e pontes entre cadeias, ajudam a compartilhar liquidez e estado nas Rollups construídas sobre o OP Stack. A esperança é resolver a dispersão de liquidez e estado em um nível mais elevado. Dentro disso, há um design mais segmentado de ordenadores compartilhados, esta solução é mais direcionada para Layer2 e não possui universalidade, como Astria, Espresso, etc.
Com foco na conta: semelhante ao NEAR, construir uma carteira de conta em toda a cadeia, suportada por uma tecnologia chamada "assinatura em cadeia" que permite assinar e executar transações através de vários protocolos de blockchain. O componente central é a rede MPC, que assina transações multichain em vez do usuário. Esta solução, embora possa resolver significativamente o problema da fragmentação da experiência do usuário, envolve implementações de backend complexas para os desenvolvedores e não resolve essencialmente a liquidez e a dispersão de estados.
Centrado na rede de intenções off-chain: ou seja, a nossa "introdução" diagrama de estrutura do bolo, a rede Solver é o núcleo onde os usuários enviam intenções para a rede Solver, e este papel de 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 nessa área incluem Anoma, Khalani, Enso, aori e Valantis. Embora as intenções possam teoricamente realizar operações complexas entre cadeias de qualquer dificuldade, na prática é necessário ter Solvers de liquidez suficiente para ajudar, e quando há 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 aumentará, assim como a barreira para executar Solvers.
Com foco na rede de liquidez em cadeia: esta direção é especificamente otimizada para o problema de liquidez entre cadeias, mas não resolve o problema da dispersão de estado em outras cadeias. Seu núcleo é construir uma camada de liquidez, na qual aplicações são construídas para compartilhar a liquidez de toda a cadeia. Alguns projetos incluem: Raye Network, INFINIT, Everclear, Elixir, etc.
Com foco em aplicações on-chain: Este tipo de aplicação constrói aplicações de alta Liquidez através da integração de grandes MM ou de aplicações de terceiros, como Liquorice, Socket, Radiant Capital, algum DEX, Hedgemony, etc. Este tipo de projeto requer a gestão de processos complexos entre cadeias, o que exige muito dos desenvolvedores, tornando-os também muito suscetíveis a ataques hackers.
Resolver o problema de liquidez é um tema muito importante; no mundo financeiro, a liquidez frequentemente representa tudo. Se for possível construir uma plataforma de integração de liquidez, especialmente integrando a liquidez fragmentada de toda a cadeia, terá um grande potencial, e também vimos muitas soluções diferentes.
Nas duas categorias acima, podemos ver que, de acordo com a estrutura do bolo, a Settlement Layer é a solução em nível mais atômico, e acima dessas soluções atômicas, como as de cross-chain, oráculos e Pre-Confirmation, é construída 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 nesses diferentes níveis, podendo ser entendidas como uma relação entre upstream e downstream. Contudo, essas soluções ainda não são soluções atômicas, e o problema geral da liquidez está fragmentado, o que trouxe o surgimento de muitos problemas derivados complexos, portanto, em relação à interoperabilidade, surgiram inúmeras soluções diversas. 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 de liquidez a partir de seus próprios pontos de partida.
INFINIT
A 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, Tipo de Pool, IRM, Ativo, entre outros, e também pode 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 aplicações, mas a liquidez final é mantida na camada de liquidez da Infinit. No entanto, atualmente ainda não foi revelado o funcionamento subjacente. Atualmente, a INFINIT já arrecadou 6 milhões de dólares em uma rodada de sementes com Robot Ventures, Electric Capital e Maelstrom Capital.
Khalani Network
Khalani construiu três componentes principais: a camada de compatibilidade de Intent, a Validade e a camada de liquidação geral.
Aplicações externas ou a camada de intenção podem publicar intenções para o Khalani, e a camada de compatibilidade de Intent do Khalani pode converter as intenções externas em um formato que o Solver do protocolo pode reconhecer, utilizando o formato padronizado conhecido como linguagem Validity. Os nós do Khalani são responsáveis por submeter o resultado final à camada de liquidação universal através de pontes entre cadeias, tecnologia de liquidação rápida, entre outros. Este projeto ainda está em fase de construção e não divulgou mais detalhes sobre o trabalho. Em agosto, obteve um financiamento inicial de 2,2 milhões de dólares de Ethereal Ventures, Nascent, Maelstrom Capital, entre outros.
Liquorice
Liquorice é uma aplicação descentralizada que permite a descoberta de preços baseada em leilão e pools de liquidez unidirecional. A principal missão do Liquorice é fornecer ferramentas eficientes de gestão de estoque para empresas de trading profissionais e conectar-se facilmente aos protocolos DeFi principais ao liquidar transações com intenção de uso. Simultaneamente, o Liquorice criou um mercado de empréstimos para realizar transações de empréstimos. Esta aplicação está mais focada na própria negociação. Atualmente, ainda está em fase de desenvolvimento, tendo anunciado em julho uma captação de 1,2 milhões de dólares na ronda de Pre-seed liderada pela GreenField.
Xion
Xion é uma atualização da marca Burnt, que anteriormente se concentrava em aplicações para consumidores. Depois, a equipe percebeu que havia um grande problema de fragmentação nas interações em cadeia, por isso construíram a Xion para melhorar essa questão. Xion é construído sobre o protocolo de consenso Comet BFT. A comunicação entre cadeias que utiliza é baseada no Cosmos IBC, tornando-o mais nativo e seguro do que outras pontes entre cadeias. A Xion passou por quatro rodadas de financiamento, com investidores como Animoca, Multicoin, Alliance DAO e Mechanism.
=nil; Foundation
nil é o mercado de ZK da Ethereum, um coprocessador ZK e desenvolvedor de Layer2, com uma equipe que possui um profundo conhecimento técnico em ZK. Propôs a solução zkSharding, que usa a tecnologia ZK para escalar horizontalmente a mainnet Ethereum, executando o processamento paralelo de transações em shards e gerando ZKP, enquanto o shard principal valida dados, se comunica com a Ethereum e sincroniza o estado da rede entre todos os validadores. O shard principal também gerencia a distribuição de validadores e contas no shard 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; L2 incorporou a comunicação entre shards no protocolo desde o início. Mensagens entre shards são validadas pelo comitê de validadores de cada shard como transações.
A ideia básica é construir uma arquitetura de comunicação entre fragmentos integrada, semelhante ao IBC, através de uma arquitetura Layer2 fragmentada, o que resolveria os problemas de Liquidez e dispersão de estado. No entanto, a ideia central não é razoável, pois o problema da dispersão de Liquidez é um problema de múltiplas cadeias, enquanto a construção é de um único Layer2, ou seja, para resolver isso, todas as cadeias teriam que se tornar um fragmento de ZK-sharding, o que é difícil de realizar.
ERC-7683
Ethereum também está a trabalhar na resolução deste problema de liquidez entre cadeias, atualmente algumas das principais Layer 2 e DEX estão a apoiar publicamente o padrão ERC7683, que utiliza também um método de cross-chain baseado em Intent. O seu objetivo principal é estabelecer um padrão comum para operações cross-chain entre L2 e sidechains, padronizando as interfaces de pedidos e liquidação, permitindo uma execução cross-chain sem interrupções, sendo que o seu principal núcleo é um Filler.
Ver original
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
16 gostos
Recompensa
16
6
Republicar
Partilhar
Comentar
0/400
GasFeeCryer
· 9h atrás
Dar dinheiro não é cadeia cruzada
Ver originalResponder0
GasBandit
· 17h atrás
Já estou a fazer L2 novamente.
Ver originalResponder0
DecentralizedElder
· 17h atrás
Outro fazer as pessoas de parvas?
Ver originalResponder0
PriceOracleFairy
· 17h atrás
smh a ver estes l2s fragmentarem-se como as promessas da minha ex... a teoria dos jogos de liquidez é brutal af rn
Ver originalResponder0
MEVSandwich
· 17h atrás
fazer as pessoas de parvas再fazer as pessoas de parvas 连Carteira都快不够用了
Ver originalResponder0
NestedFox
· 17h atrás
fazer as pessoas de parvas? Há ponte não é tudo igual?
Exploração do problema da liquidez fragmentada na era Layer2 e soluções
Estudo sobre o problema da liquidez fragmentada na era Layer2
Com a transição do Ethereum para soluções de escalonamento centradas em Layer 2, juntamente com o surgimento de ferramentas como RaaS, muitas blockchains públicas estão a desenvolver-se rapidamente. Muitas entidades desejam construir as suas próprias cadeias para representar diferentes interesses e buscar uma avaliação mais alta. No entanto, a proliferação de blockchains públicas torna difícil para o desenvolvimento do ecossistema acompanhar o ritmo destas blockchains, resultando em muitos projetos a desvalorizarem-se logo no TGE.
Com a ajuda do OP Stack, uma plataforma de negociação lançou a sua própria Base Layer 2, outra plataforma de negociação lançou o Ink; com a tecnologia ZK, uma plataforma lançou o XLayer; a Sony lançou o Soneium, a LINE lançou o Kaia, entre outros. Hoje em dia, o financiamento e as barreiras tecnológicas para construir uma cadeia foram drasticamente 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 cadeias Layer 2 possam optar pela compatibilidade EVM para alcançar a interoperabilidade, devido às entidades Web2 por trás delas possuírem uma grande quantidade de aplicações downstream, é difícil construir aplicações na mesma cadeia e alcançar um consenso.
O ecossistema multichain atual trouxe um novo desafio: Liquidez e estado disperso. Dado que a existência de multichains é inevitável, a interoperabilidade é um campo que deve ser explorado e resolvido. Atualmente, existem muitas soluções de liquidez, como todos nós ouvimos falar de abstração de cadeia, intenção, Clearing Execution, Native CrossChain, ZKSharding, mas a sua essência central é a mesma.
Utilizamos a arquitetura Cake, amplamente reconhecida na indústria, para apresentar de cima para baixo a composição dos componentes centrais da abstração cross-chain:
Camada de Aplicação (Application Layer)
Este é o nível de interação direta do usuário, que também é a camada mais abstrata na solução de liquidez, uma vez que oculta completamente os detalhes da conversão de liquidez. Na camada de aplicação, os usuários interagem com a interface frontal, podendo não entender o mecanismo de conversão de liquidez subjacente.
Camada de Permissão (Permission Layer)
Localizado abaixo da camada de aplicação, o usuário conecta a carteira ao dApp e solicita uma cotação para satisfazer a intenção de negociação. Aqui, a "intenção" refere-se ao resultado final da negociação que o usuário espera (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 Conta (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 as estruturas de contas únicas de cada cadeia. Por exemplo, o sistema de contas centrado em objetos do SUI é completamente diferente do EVM. One Balance é um projeto representativo nesta área, que construiu um sistema de contas confiável, sem a necessidade de estabelecer consenso entre cadeias, apenas com compromissos confiáveis entre os sistemas de contas existentes. A Near Account implementa a gestão abstrata gerando carteiras de contas multi-chain para os usuários, otimizando enormemente 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.
Camada de Resolução (Solver Layer)
Esta camada é responsável por receber e implementar a intenção de negociação do usuário, onde o papel do Solver compete para oferecer uma melhor experiência ao usuário, incluindo tempos de negociação mais rápidos e velocidade de execução. Com base nisso, projetos baseados em intenção como a Anoma construíram várias soluções impulsionadas por intenção. Derivados dessa intenção, como o componente Predicate, podem realizar a intenção do usuário sob regras específicas.
Camada de Liquidação (Settlement Layer)
Este é o nível de middleware utilizado para resolver a intenção do usuário. Os componentes principais da solução de liquidez e estado disperso incluem:
Além disso, é necessário considerar a liquidez entre cadeias, a confirmação final (Finality), o mecanismo de prova de Layer 2, entre 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 em frangalhos. Após analisarmos várias opções, descobrimos que as principais formas são estas:
Centrado em RaaS: soluções de Rollup como OP Stack, através da adição de ordenadores compartilhados específicos e pontes entre cadeias, ajudam a compartilhar liquidez e estado nas Rollups construídas sobre o OP Stack. A esperança é resolver a dispersão de liquidez e estado em um nível mais elevado. Dentro disso, há um design mais segmentado de ordenadores compartilhados, esta solução é mais direcionada para Layer2 e não possui universalidade, como Astria, Espresso, etc.
Com foco na conta: semelhante ao NEAR, construir uma carteira de conta em toda a cadeia, suportada por uma tecnologia chamada "assinatura em cadeia" que permite assinar e executar transações através de vários protocolos de blockchain. O componente central é a rede MPC, que assina transações multichain em vez do usuário. Esta solução, embora possa resolver significativamente o problema da fragmentação da experiência do usuário, envolve implementações de backend complexas para os desenvolvedores e não resolve essencialmente a liquidez e a dispersão de estados.
Centrado na rede de intenções off-chain: ou seja, a nossa "introdução" diagrama de estrutura do bolo, a rede Solver é o núcleo onde os usuários enviam intenções para a rede Solver, e este papel de 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 nessa área incluem Anoma, Khalani, Enso, aori e Valantis. Embora as intenções possam teoricamente realizar operações complexas entre cadeias de qualquer dificuldade, na prática é necessário ter Solvers de liquidez suficiente para ajudar, e quando há 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 aumentará, assim como a barreira para executar Solvers.
Com foco na rede de liquidez em cadeia: esta direção é especificamente otimizada para o problema de liquidez entre cadeias, mas não resolve o problema da dispersão de estado em outras cadeias. Seu núcleo é construir uma camada de liquidez, na qual aplicações são construídas para compartilhar a liquidez de toda a cadeia. Alguns projetos incluem: Raye Network, INFINIT, Everclear, Elixir, etc.
Com foco em aplicações on-chain: Este tipo de aplicação constrói aplicações de alta Liquidez através da integração de grandes MM ou de aplicações de terceiros, como Liquorice, Socket, Radiant Capital, algum DEX, Hedgemony, etc. Este tipo de projeto requer a gestão de processos complexos entre cadeias, o que exige muito dos desenvolvedores, tornando-os também muito suscetíveis a ataques hackers.
Resolver o problema de liquidez é um tema muito importante; no mundo financeiro, a liquidez frequentemente representa tudo. Se for possível construir uma plataforma de integração de liquidez, especialmente integrando a liquidez fragmentada de toda a cadeia, terá um grande potencial, e também vimos muitas soluções diferentes.
Nas duas categorias acima, podemos ver que, de acordo com a estrutura do bolo, a Settlement Layer é a solução em nível mais atômico, e acima dessas soluções atômicas, como as de cross-chain, oráculos e Pre-Confirmation, é construída 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 nesses diferentes níveis, podendo ser entendidas como uma relação entre upstream e downstream. Contudo, essas soluções ainda não são soluções atômicas, e o problema geral da liquidez está fragmentado, o que trouxe o surgimento de muitos problemas derivados complexos, portanto, em relação à interoperabilidade, surgiram inúmeras soluções diversas. 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 de liquidez a partir de seus próprios pontos de partida.
INFINIT
A 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, Tipo de Pool, IRM, Ativo, entre outros, e também pode 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 aplicações, mas a liquidez final é mantida na camada de liquidez da Infinit. No entanto, atualmente ainda não foi revelado o funcionamento subjacente. Atualmente, a INFINIT já arrecadou 6 milhões de dólares em uma rodada de sementes com Robot Ventures, Electric Capital e Maelstrom Capital.
Khalani Network
Khalani construiu três componentes principais: a camada de compatibilidade de Intent, a Validade e a camada de liquidação geral.
Aplicações externas ou a camada de intenção podem publicar intenções para o Khalani, e a camada de compatibilidade de Intent do Khalani pode converter as intenções externas em um formato que o Solver do protocolo pode reconhecer, utilizando o formato padronizado conhecido como linguagem Validity. Os nós do Khalani são responsáveis por submeter o resultado final à camada de liquidação universal através de pontes entre cadeias, tecnologia de liquidação rápida, entre outros. Este projeto ainda está em fase de construção e não divulgou mais detalhes sobre o trabalho. Em agosto, obteve um financiamento inicial de 2,2 milhões de dólares de Ethereal Ventures, Nascent, Maelstrom Capital, entre outros.
Liquorice
Liquorice é uma aplicação descentralizada que permite a descoberta de preços baseada em leilão e pools de liquidez unidirecional. A principal missão do Liquorice é fornecer ferramentas eficientes de gestão de estoque para empresas de trading profissionais e conectar-se facilmente aos protocolos DeFi principais ao liquidar transações com intenção de uso. Simultaneamente, o Liquorice criou um mercado de empréstimos para realizar transações de empréstimos. Esta aplicação está mais focada na própria negociação. Atualmente, ainda está em fase de desenvolvimento, tendo anunciado em julho uma captação de 1,2 milhões de dólares na ronda de Pre-seed liderada pela GreenField.
Xion
Xion é uma atualização da marca Burnt, que anteriormente se concentrava em aplicações para consumidores. Depois, a equipe percebeu que havia um grande problema de fragmentação nas interações em cadeia, por isso construíram a Xion para melhorar essa questão. Xion é construído sobre o protocolo de consenso Comet BFT. A comunicação entre cadeias que utiliza é baseada no Cosmos IBC, tornando-o mais nativo e seguro do que outras pontes entre cadeias. A Xion passou por quatro rodadas de financiamento, com investidores como Animoca, Multicoin, Alliance DAO e Mechanism.
=nil; Foundation
nil é o mercado de ZK da Ethereum, um coprocessador ZK e desenvolvedor de Layer2, com uma equipe que possui um profundo conhecimento técnico em ZK. Propôs a solução zkSharding, que usa a tecnologia ZK para escalar horizontalmente a mainnet Ethereum, executando o processamento paralelo de transações em shards e gerando ZKP, enquanto o shard principal valida dados, se comunica com a Ethereum e sincroniza o estado da rede entre todos os validadores. O shard principal também gerencia a distribuição de validadores e contas no shard 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; L2 incorporou a comunicação entre shards no protocolo desde o início. Mensagens entre shards são validadas pelo comitê de validadores de cada shard como transações.
A ideia básica é construir uma arquitetura de comunicação entre fragmentos integrada, semelhante ao IBC, através de uma arquitetura Layer2 fragmentada, o que resolveria os problemas de Liquidez e dispersão de estado. No entanto, a ideia central não é razoável, pois o problema da dispersão de Liquidez é um problema de múltiplas cadeias, enquanto a construção é de um único Layer2, ou seja, para resolver isso, todas as cadeias teriam que se tornar um fragmento de ZK-sharding, o que é difícil de realizar.
ERC-7683
Ethereum também está a trabalhar na resolução deste problema de liquidez entre cadeias, atualmente algumas das principais Layer 2 e DEX estão a apoiar publicamente o padrão ERC7683, que utiliza também um método de cross-chain baseado em Intent. O seu objetivo principal é estabelecer um padrão comum para operações cross-chain entre L2 e sidechains, padronizando as interfaces de pedidos e liquidação, permitindo uma execução cross-chain sem interrupções, sendo que o seu principal núcleo é um Filler.