Estudo sobre o problema de liquidez fragmentada na era da Camada 2
Desde que o Ethereum se voltou para soluções de escalonamento centradas na Camada 2, juntamente com o surgimento de ferramentas como RaaS, muitas blockchains públicas se desenvolveram rapidamente. Muitas entidades desejam construir sua própria cadeia para representar diferentes interesses e buscar uma avaliação mais alta. No entanto, a emergência de inúmeras blockchains públicas dificultou o desenvolvimento do ecossistema, levando a muitos projetos a perderem valor logo no TGE.
Através da OP Stack, uma plataforma de negociação lançou a sua própria Camada 2, outra plataforma de negociação lançou a Ink; com a tecnologia ZK, uma plataforma lançou a XLayer; a Sony lançou a Soneium, a LINE lançou a Kaia, entre outros. Hoje em dia, o custo e a barreira técnica para construir uma cadeia foram significativamente reduzidos, e o custo de operação de uma cadeia baseada na OP Stack é de cerca de 10.000 dólares por mês.
O futuro será certamente uma era de coexistência de múltiplas cadeias. Embora essas Camada 2 possam optar pela compatibilidade EVM para facilitar a interoperabilidade, devido à grande quantidade de aplicações downstream das entidades Web2 por trás delas, é difícil construir aplicações na mesma cadeia e alcançar consenso.
O ecossistema multichain atual trouxe um novo desafio: Liquidez e dispersão de estado. Dado que a existência de múltiplas cadeias é inevitável, a interoperabilidade é uma área que precisa ser explorada e resolvida. Atualmente, existem muitas soluções de liquidez, como abstração de cadeia, intenção, Clearing Execution, Native CrossChain, ZKSharding, entre outras, mas sua essência central é a mesma.
Utilizamos a arquitetura Cake, amplamente reconhecida na indústria, para apresentar de cima para baixo os componentes principais da abstração de cross-chain:
Camada de Aplicação(Camada de Aplicação)
Esta é a camada de interação direta do utilizador, e também a camada mais abstrata na solução de liquidez, pois oculta completamente os detalhes da conversão de liquidez. Na camada de aplicação, os utilizadores interagem com a interface frontal, podendo não compreender o mecanismo de conversão de liquidez subjacente.
Camada de Permissão(Camada de Permissão)
Situado abaixo da camada de aplicação, os usuários conectam a carteira ao dApp e solicitam 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 Camada (Key Management and Account Abstraction)
Devido à existência de um ambiente multichain, é necessária uma gestão de contas e um sistema de 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. O One Balance é um projeto representativo nesta área, que construiu um sistema de contas confiável, sem necessidade de estabelecer um consenso entre cadeias, apenas requerendo compromissos confiáveis entre os sistemas de contas existentes. A Near Account realiza a gestão de abstração gerando carteiras de contas multichain para os usuários, otimizando enormemente a experiência do usuário e reduzindo a fragmentação da UX. No entanto, em termos de liquidez, integra principalmente as blockchains públicas existentes.
Resolver Camada ( Camada )
Esta camada é responsável por receber e implementar a intenção de negociação dos usuários. O papel do Solver compete aqui 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ção construíram várias soluções orientadas 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)
Esta é a camada intermediária utilizada para resolver a camada para realizar a intenção do usuário. Os componentes principais das soluções de liquidez e estado descentralizado incluem:
Oráculo (: utilizado para obter informações de estado em outras cadeias.
Pontes de Cross-Chain ): responsáveis pela transmissão de informações e liquidez entre cadeias.
Confirmação Prévia (: reduzir o tempo de confirmação entre cadeias.
Disponibilidade de dados)DA(: fornecer acessibilidade aos dados.
Além disso, é necessário considerar a liquidez entre as cadeias, a finalidade )Finality(, o mecanismo de prova da Camada 2, entre outros fatores, para garantir o funcionamento eficiente de todo o sistema multichain.
![Camada 2时代下，Liquidez fazer as pessoas de parvas问题的研究])https://img-cdn.gateio.im/webp-social/moments-a94f0982457fcb1d9c6ef2493b0a499f.webp(
Atualmente, existem várias soluções no mercado para resolver a liquidez e, após analisarmos uma grande quantidade de opções, descobrimos que as principais formas são as seguintes:
Centrado em RaaS: soluções de Rollup como o OP Stack, assistem na construção de Rollups com liquidez e estado compartilhados ao adicionar ordenadores compartilhados específicos e pontes cross-chain. Isso espera resolver a liquidez e a dispersão do estado de uma forma mais elevada. Um aspecto mais específico é o design separado de ordenadores compartilhados, que é mais voltado para a Camada 2 e não possui universalidade.
Centrado na conta: semelhante ao NEAR, 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 vários protocolos de blockchain. O componente central é a rede MPC, que assina transações multichain em nome do usuário. Este conjunto de soluções, embora possa resolver amplamente o problema de fragmentação da UX, envolve uma implementação backend complexa para os desenvolvedores e não resolve essencialmente a liquidez e a dispersão do estado.
Centrado na rede de intenções off-chain: ou seja, a Rede Solver no diagrama da arquitetura do "Introdução" ao bolo, o núcleo é que os usuários enviam intenções para a rede Solver, este papel de Solver compete por cotações, oferecendo o melhor tempo de conclusão e preço de negociação. Esses Solvers podem ser Agentes de IA, CEX, Market Makers ou até mesmo protocolos integrados. Embora a intenção possa teoricamente realizar operações cross-chain de complexidade arbitrária, na prática, é necessário ter Solvers com liquidez suficiente para auxiliar, e quando há algumas demandas off-chain, existe a possibilidade de fraude por parte do Solver. Se forem introduzidos mecanismos como provas de fraude, a dificuldade de implementação da Rede Solver aumentará, assim como o limiar para operar como Solver.
Centrando-se na rede de liquidez em cadeia: esta direção é especificamente otimizada para problemas de liquidez entre cadeias, mas não resolve outros problemas de estado disperso em cadeia. O núcleo é construir uma camada de liquidez, na qual aplicações são construídas para compartilhar a liquidez de toda a cadeia.
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 MM ou de aplicações de terceiros. Estes projetos requerem a gestão de processos complexos de cross-chain, exigindo muito dos desenvolvedores, e por isso são também suscetíveis a ataques de hackers.
Resolver o problema da liquidez é uma questão muito importante, pois 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.
![Camada 2时代下，Liquidez fazer as pessoas de parvas问题的研究])https://img-cdn.gateio.im/webp-social/moments-e170f453d0b5b33f7ffc55facc9626c8.webp(
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 cross-chain, oráculos, e soluções de Pre-Confirmation, é construída uma camada mais abstrata, que é a Solver Layer, Permission Layer e Application Layer. As várias soluções abstratas ou de liquidez que listamos acima, construídas em diferentes direções, podem ser entendidas como uma relação entre 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, levando ao surgimento de uma infinidade 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.
)# INFINIT
A INFINIT construiu um serviço RaaS para o DeFi, que pode fornecer os componentes necessários para a construção direta de protocolos DeFi, como Oracle, Tipo de Pool, IRM, Ativo, etc., e também pode fornecer componentes como Negociação com Alavancagem e Estratégia de Rendimento prontos para uso. É equivalente a outros pontos de construção de aplicações, mas a liquidez final é colocada na camada de liquidez da Infinit. No entanto, atualmente ainda não divulgou os princípios de funcionamento subjacentes.
(# Khalani Network
Khalani construiu três componentes principais, que são a camada de compatibilidade Intent, Validity 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 compatível de Intenção do Khalani pode converter as intenções externas em um formato que o Solver do protocolo consegue reconhecer, utilizando o formato normalizado que é a linguagem Validity. O nó Khalani é responsável por submeter o resultado final à camada de liquidação geral através de pontes cross-chain, tecnologias 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.
)# Liquorice
Liquorice é uma aplicação descentralizada que permite a descoberta de preços com base em leilões e pools de liquidez unidirecionais. A principal missão do Liquorice é fornecer ferramentas de gestão de inventário eficientes para empresas de trading profissionais e conectar-se facilmente aos protocolos DeFi fundamentais ao liquidar transações com intenção de uso. Ao mesmo tempo, o Liquorice criou um mercado de empréstimos para suas transações de empréstimo. Esta aplicação está mais focada na própria negociação. Atualmente, ainda está em fase de desenvolvimento.
Xion
Xion é uma atualização da marca Burnt. Anteriormente, a Burnt estava focada em aplicações para consumidores, mas a equipe percebeu 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 é 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.
![Camada 2时代下，Liquidez fazer as pessoas de parvas问题的研究]###https://img-cdn.gateio.im/webp-social/moments-0f51232f5a7495ce85432c8feb374ed1.webp###
=nil; Fundação
nil é o mercado de poder computacional ZK da Ethereum, co-processador ZK e desenvolvedor de Camada 2, com uma equipe que possui um profundo conhecimento técnico em ZK. Propôs a solução zkSharding, que usa tecnologia ZK para escalar horizontalmente a rede principal da Ethereum, executar o processamento paralelo de fragmentos e gerar ZKP, enquanto o fragmento principal valida dados, se comunica 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 no fragmento de execução. O protocolo de consenso utilizado pelo comitê de validação também é o Hotstuff, que é comum em projetos recentes de execução paralela. =nil; L2 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.
Seu conceito básico é construir uma arquitetura de comunicação entre fragmentos embutida, semelhante ao IBC, através de uma arquitetura Layer 2 em fragmentos, assim pode resolver os problemas de Liquidez e dispersão de estado. No entanto, sua ideia central não é razoável, pois o problema que a dispersão de Liquidez resolve é o problema de múltiplas cadeias, e o que está sendo construído é uma única Layer 2, o que significa que, para resolver, todas as cadeias precisam se tornar um fragmento do 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, havendo atualmente várias plataformas que suportam publicamente o padrão ERC7683, que utiliza um método de cross-chain baseado em Intent. O seu objetivo principal é estabelecer um padrão comum para operações de cross-chain entre L2 e sidechains, padronizando as interfaces de pedidos e liquidação, e permitindo a execução cross-chain sem interrupções. O seu núcleo principal é um Filler, que também pode ser descrito como o papel de Solver na abstração da cadeia, que paga em nome dos outros. Esta proposta foi construída em conjunto por dois projetos, e está atualmente a ser revista pelo grupo de trabalho Cake.
![Camada 2时代下，Liquidez fazer as pessoas de parvas问题的研究])https://img-cdn.gateio.im/webp-social/moments-e4d53accc40f8c915eaabbd2909f51d4.webp###
OP Stack
OP Stack, ERC-7683 e zkSharding são soluções internas do Ethereum para a fragmentação da liquidez entre Camada 2, abordando as questões a nível de arquitetura, consenso e aplicação. O OP Stack projeta uma solução completa de múltiplas Camadas 2 para resolver de uma vez os problemas de transmissão de informações e descentralização do Sequencer. Ao usar a arquitetura OP Stack, contratos cross-chain são automaticamente implantados, e existe um Supervisor para desafiar e evitar a transmissão de informações cross-chain falsas. Atualmente, vários projetos conhecidos utilizam a arquitetura OP Stack.
entre outros, um exemplo típico é o Unichain. O Unichain se destaca principalmente por
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.
10 gostos
Recompensa
10
5
Partilhar
Comentar
0/400
MemeTokenGenius
· 7h atrás
fazer as pessoas de parvas无药可医
Ver originalResponder0
SocialAnxietyStaker
· 7h atrás
Layer2 está saindo em velocidade.
Ver originalResponder0
GateUser-9ad11037
· 7h atrás
Grandes problemas exigem flexibilidade na abordagem
Ver originalResponder0
MysteriousZhang
· 7h atrás
Clareza profissional com muita profundidade
Ver originalResponder0
ConsensusBot
· 7h atrás
Desenvolver-se muito rapidamente não é uma coisa boa.
Desafios e soluções para a liquidez fragmentada na era da Camada 2
Estudo sobre o problema de liquidez fragmentada na era da Camada 2
Desde que o Ethereum se voltou para soluções de escalonamento centradas na Camada 2, juntamente com o surgimento de ferramentas como RaaS, muitas blockchains públicas se desenvolveram rapidamente. Muitas entidades desejam construir sua própria cadeia para representar diferentes interesses e buscar uma avaliação mais alta. No entanto, a emergência de inúmeras blockchains públicas dificultou o desenvolvimento do ecossistema, levando a muitos projetos a perderem valor logo no TGE.
Através da OP Stack, uma plataforma de negociação lançou a sua própria Camada 2, outra plataforma de negociação lançou a Ink; com a tecnologia ZK, uma plataforma lançou a XLayer; a Sony lançou a Soneium, a LINE lançou a Kaia, entre outros. Hoje em dia, o custo e a barreira técnica para construir uma cadeia foram significativamente reduzidos, e o custo de operação de uma cadeia baseada na OP Stack é de cerca de 10.000 dólares por mês.
O futuro será certamente uma era de coexistência de múltiplas cadeias. Embora essas Camada 2 possam optar pela compatibilidade EVM para facilitar a interoperabilidade, devido à grande quantidade de aplicações downstream das entidades Web2 por trás delas, é difícil construir aplicações na mesma cadeia e alcançar consenso.
O ecossistema multichain atual trouxe um novo desafio: Liquidez e dispersão de estado. Dado que a existência de múltiplas cadeias é inevitável, a interoperabilidade é uma área que precisa ser explorada e resolvida. Atualmente, existem muitas soluções de liquidez, como abstração de cadeia, intenção, Clearing Execution, Native CrossChain, ZKSharding, entre outras, mas sua essência central é a mesma.
Utilizamos a arquitetura Cake, amplamente reconhecida na indústria, para apresentar de cima para baixo os componentes principais da abstração de cross-chain:
Camada de Aplicação(Camada de Aplicação)
Esta é a camada de interação direta do utilizador, e também a camada mais abstrata na solução de liquidez, pois oculta completamente os detalhes da conversão de liquidez. Na camada de aplicação, os utilizadores interagem com a interface frontal, podendo não compreender o mecanismo de conversão de liquidez subjacente.
Camada de Permissão(Camada de Permissão)
Situado abaixo da camada de aplicação, os usuários conectam a carteira ao dApp e solicitam 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 Camada (Key Management and Account Abstraction)
Devido à existência de um ambiente multichain, é necessária uma gestão de contas e um sistema de 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. O One Balance é um projeto representativo nesta área, que construiu um sistema de contas confiável, sem necessidade de estabelecer um consenso entre cadeias, apenas requerendo compromissos confiáveis entre os sistemas de contas existentes. A Near Account realiza a gestão de abstração gerando carteiras de contas multichain para os usuários, otimizando enormemente a experiência do usuário e reduzindo a fragmentação da UX. No entanto, em termos de liquidez, integra principalmente as blockchains públicas existentes.
Resolver Camada ( Camada )
Esta camada é responsável por receber e implementar a intenção de negociação dos usuários. O papel do Solver compete aqui 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ção construíram várias soluções orientadas 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)
Esta é a camada intermediária utilizada para resolver a camada para realizar a intenção do usuário. Os componentes principais das soluções de liquidez e estado descentralizado incluem:
Além disso, é necessário considerar a liquidez entre as cadeias, a finalidade )Finality(, o mecanismo de prova da Camada 2, entre outros fatores, para garantir o funcionamento eficiente de todo o sistema multichain.
![Camada 2时代下，Liquidez fazer as pessoas de parvas问题的研究])https://img-cdn.gateio.im/webp-social/moments-a94f0982457fcb1d9c6ef2493b0a499f.webp(
Atualmente, existem várias soluções no mercado para resolver a liquidez e, após analisarmos uma grande quantidade de opções, descobrimos que as principais formas são as seguintes:
Centrado em RaaS: soluções de Rollup como o OP Stack, assistem na construção de Rollups com liquidez e estado compartilhados ao adicionar ordenadores compartilhados específicos e pontes cross-chain. Isso espera resolver a liquidez e a dispersão do estado de uma forma mais elevada. Um aspecto mais específico é o design separado de ordenadores compartilhados, que é mais voltado para a Camada 2 e não possui universalidade.
Centrado na conta: semelhante ao NEAR, 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 vários protocolos de blockchain. O componente central é a rede MPC, que assina transações multichain em nome do usuário. Este conjunto de soluções, embora possa resolver amplamente o problema de fragmentação da UX, envolve uma implementação backend complexa para os desenvolvedores e não resolve essencialmente a liquidez e a dispersão do estado.
Centrado na rede de intenções off-chain: ou seja, a Rede Solver no diagrama da arquitetura do "Introdução" ao bolo, o núcleo é que os usuários enviam intenções para a rede Solver, este papel de Solver compete por cotações, oferecendo o melhor tempo de conclusão e preço de negociação. Esses Solvers podem ser Agentes de IA, CEX, Market Makers ou até mesmo protocolos integrados. Embora a intenção possa teoricamente realizar operações cross-chain de complexidade arbitrária, na prática, é necessário ter Solvers com liquidez suficiente para auxiliar, e quando há algumas demandas off-chain, existe a possibilidade de fraude por parte do Solver. Se forem introduzidos mecanismos como provas de fraude, a dificuldade de implementação da Rede Solver aumentará, assim como o limiar para operar como Solver.
Centrando-se na rede de liquidez em cadeia: esta direção é especificamente otimizada para problemas de liquidez entre cadeias, mas não resolve outros problemas de estado disperso em cadeia. O núcleo é construir uma camada de liquidez, na qual aplicações são construídas para compartilhar a liquidez de toda a cadeia.
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 MM ou de aplicações de terceiros. Estes projetos requerem a gestão de processos complexos de cross-chain, exigindo muito dos desenvolvedores, e por isso são também suscetíveis a ataques de hackers.
Resolver o problema da liquidez é uma questão muito importante, pois 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.
![Camada 2时代下，Liquidez fazer as pessoas de parvas问题的研究])https://img-cdn.gateio.im/webp-social/moments-e170f453d0b5b33f7ffc55facc9626c8.webp(
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 cross-chain, oráculos, e soluções de Pre-Confirmation, é construída uma camada mais abstrata, que é a Solver Layer, Permission Layer e Application Layer. As várias soluções abstratas ou de liquidez que listamos acima, construídas em diferentes direções, podem ser entendidas como uma relação entre 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, levando ao surgimento de uma infinidade 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.
)# INFINIT
A INFINIT construiu um serviço RaaS para o DeFi, que pode fornecer os componentes necessários para a construção direta de protocolos DeFi, como Oracle, Tipo de Pool, IRM, Ativo, etc., e também pode fornecer componentes como Negociação com Alavancagem e Estratégia de Rendimento prontos para uso. É equivalente a outros pontos de construção de aplicações, mas a liquidez final é colocada na camada de liquidez da Infinit. No entanto, atualmente ainda não divulgou os princípios de funcionamento subjacentes.
(# Khalani Network
Khalani construiu três componentes principais, que são a camada de compatibilidade Intent, Validity 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 compatível de Intenção do Khalani pode converter as intenções externas em um formato que o Solver do protocolo consegue reconhecer, utilizando o formato normalizado que é a linguagem Validity. O nó Khalani é responsável por submeter o resultado final à camada de liquidação geral através de pontes cross-chain, tecnologias 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.
)# Liquorice
Liquorice é uma aplicação descentralizada que permite a descoberta de preços com base em leilões e pools de liquidez unidirecionais. A principal missão do Liquorice é fornecer ferramentas de gestão de inventário eficientes para empresas de trading profissionais e conectar-se facilmente aos protocolos DeFi fundamentais ao liquidar transações com intenção de uso. Ao mesmo tempo, o Liquorice criou um mercado de empréstimos para suas transações de empréstimo. Esta aplicação está mais focada na própria negociação. Atualmente, ainda está em fase de desenvolvimento.
Xion
Xion é uma atualização da marca Burnt. Anteriormente, a Burnt estava focada em aplicações para consumidores, mas a equipe percebeu 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 é 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.
![Camada 2时代下，Liquidez fazer as pessoas de parvas问题的研究]###https://img-cdn.gateio.im/webp-social/moments-0f51232f5a7495ce85432c8feb374ed1.webp###
=nil; Fundação
nil é o mercado de poder computacional ZK da Ethereum, co-processador ZK e desenvolvedor de Camada 2, com uma equipe que possui um profundo conhecimento técnico em ZK. Propôs a solução zkSharding, que usa tecnologia ZK para escalar horizontalmente a rede principal da Ethereum, executar o processamento paralelo de fragmentos e gerar ZKP, enquanto o fragmento principal valida dados, se comunica 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 no fragmento de execução. O protocolo de consenso utilizado pelo comitê de validação também é o Hotstuff, que é comum em projetos recentes de execução paralela. =nil; L2 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.
Seu conceito básico é construir uma arquitetura de comunicação entre fragmentos embutida, semelhante ao IBC, através de uma arquitetura Layer 2 em fragmentos, assim pode resolver os problemas de Liquidez e dispersão de estado. No entanto, sua ideia central não é razoável, pois o problema que a dispersão de Liquidez resolve é o problema de múltiplas cadeias, e o que está sendo construído é uma única Layer 2, o que significa que, para resolver, todas as cadeias precisam se tornar um fragmento do 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, havendo atualmente várias plataformas que suportam publicamente o padrão ERC7683, que utiliza um método de cross-chain baseado em Intent. O seu objetivo principal é estabelecer um padrão comum para operações de cross-chain entre L2 e sidechains, padronizando as interfaces de pedidos e liquidação, e permitindo a execução cross-chain sem interrupções. O seu núcleo principal é um Filler, que também pode ser descrito como o papel de Solver na abstração da cadeia, que paga em nome dos outros. Esta proposta foi construída em conjunto por dois projetos, e está atualmente a ser revista pelo grupo de trabalho Cake.
![Camada 2时代下，Liquidez fazer as pessoas de parvas问题的研究])https://img-cdn.gateio.im/webp-social/moments-e4d53accc40f8c915eaabbd2909f51d4.webp###
OP Stack
OP Stack, ERC-7683 e zkSharding são soluções internas do Ethereum para a fragmentação da liquidez entre Camada 2, abordando as questões a nível de arquitetura, consenso e aplicação. O OP Stack projeta uma solução completa de múltiplas Camadas 2 para resolver de uma vez os problemas de transmissão de informações e descentralização do Sequencer. Ao usar a arquitetura OP Stack, contratos cross-chain são automaticamente implantados, e existe um Supervisor para desafiar e evitar a transmissão de informações cross-chain falsas. Atualmente, vários projetos conhecidos utilizam a arquitetura OP Stack.
entre outros, um exemplo típico é o Unichain. O Unichain se destaca principalmente por