Vendo que a Particle Network lançou recentemente a abstração de conta de cadeia completa, parece que precisa sobrepor uma "camada intermediária" em cima dos padrões de ERC4337 existentes, por que você tem que fazer isso? Se você está familiarizado com o status quo atual da abstração de contas, não é difícil encontrar a resposta:
Atualmente, cada cadeia equivalente de EVM, incluindo a cadeia de aplicação de Camada 1 e Camada 2 e Camada 3, tem uma abordagem completamente diferente, e este tipo de abstração é baseado em cadeia, não orientado para o utilizador;
A fim de realmente realizar o user-oriented, como permitir que um usuário conecte todas as cadeias associadas com base em uma entrada e um endereço, de modo a alcançar uma experiência interativa mais coerente e global, um papel de "camada intermediária" que pode definir a especificação unificada e padrões de implementação de intenção tornou-se uma obrigação;
Por que a prática atual do mercado de "abstração de contas" está muito dividida? Como a abstração de conta de cadeia completa da Particle Network é tecnicamente implementada? Até que ponto é possível alcançar a adoção em massa da trilha abstrata centrada na intenção? Vamos analisá-los um a um:
As soluções AA de abstração de conta são unificadas no nível de "engenharia" e a camada de prática é multifacetada
Em termos de simplicidade técnica, a abstração de conta é uma série de intenções que os usuários instalam no pool de memória do UserOP, e o empacotador as empacota e as envia para o contrato Entrypoint para execução, onde as transações em lote podem ser processadas através da agregação de assinatura do Agregador, e os detalhes do pagamento de gás são tratados pela Paymaster.
Este é um conjunto de padrões ERC4337 definidos, e a lógica de implementação de back-end também é unificada, mas é essencialmente uma abstração da cadeia EVM, e o front-end que conecta os usuários não é necessariamente "unificado".
Por exemplo, o zkSync usa endereços EOA para vincular contas, e todos os usuários veem é um endereço de sombra transferível, e o front-end dificilmente sente a existência de contas AA. Starknet, por outro lado, está na forma de uma conta de contrato atualizável, e os usuários precisam atualizar constantemente o contrato para atualizar a função da conta. Além disso, Argent usa o mecanismo de recuperação social do mecanismo Guardian, e o esquema de abstração de conta do Unipass tende a ser aplicado em aplicações multi-cadeia heterogêneas em ambientes não-EVM.
Espere, esse tipo de inconsistência na entrada parece ser uma espécie de personalização, mas sem dúvida aumenta o limiar para os usuários. A abstração vai e vem, por que o limiar é maior no "orientado para o usuário"? Isso se manifesta no fato de que é impossível para um usuário interagir com apenas uma cadeia em um ambiente multi-cadeia e multi-Layer2, e o custo de aprendizagem é gerado do nada ao abranger várias carteiras e várias cadeias; Um usuário gerará vários endereços de contrato diferentes em diferentes cadeias EVM, o que traz desafios para o gerenciamento unificado de ativos.
Como uma implementação de engenharia padrão ERC4337 multicadeia tão fragmentada pode levar a uma adoção em massa orientada ao usuário?
Qual é a dificuldade na lógica da prática abstrata das contas unificadas? Tomemos como exemplo a abstração de conta de cadeia completa
Como mencionado anteriormente, a abstração da conta corrente é baseada apenas na cadeia EVM, mas o endereço EOA ainda pode ser unificado com a cadeia EVM, por quê?
Como os endereços EOA são derivados da computação de chave pública, desde que os algoritmos de diferentes cadeias sejam os mesmos e a chave privada seja a mesma, o endereço derivado também é o mesmo. No entanto, o endereço do contrato é calculado a partir do endereço do Criador e do nonce, e o endereço do contrato é diferente devido aos diferentes nonces de cada cadeia. Uma abordagem aparentemente viável é usar uma abordagem de registro para mapear o mesmo endereço entre diferentes cadeias, mas há um risco de centralização.
Por outro lado, o diagrama de estrutura abstrata da Particle Network de toda a conta da cadeia, está tentando assumir o papel de um "centro de expedição" com a estrutura nativa da cadeia descentralizada, e cada nova cadeia com um novo endereço será gerada pelo contrato geral do centro de despacho, e o sub-Contrato de Implantação será uniformemente conectado ao Contrato de Implantação para operação unificada, incluindo implantação e atualização, todos os aspetos serão uniformemente programados pelo contrato geral.
A única dificuldade nisso é a fluência da comunicação instantânea entre cadeias heterogêneas, o que requer que a "camada intermediária" atue como um meio de comunicação eficiente, que pode alcançar um agendamento unificado distribuindo contratos em cada nó leve da cadeia, e o esquema de prática é semelhante à solução cross-chain da LayerZero.
Esta abordagem, pelo menos, rompe as limitações de atributos das cadeias EVM, de modo que qualquer cadeia múltipla que suporte a interoperabilidade de contratos de cadeia heterogênea e o esquema EIP-4337 serão incluídos no sistema multicadeia. A abstração de conta de cadeia completa pode ser implementada em grande escala.
No entanto, cadeias não-EVM como Aptos e Sui são atualmente incapazes de se conectar de forma semelhante em série. Este é um mercado grande o suficiente em um momento em que o ecossistema Ethereum é absolutamente dominante nas categorias Camada, Camada 2 e Camada 3.
Que tipo de imaginação pode ser libertada por outros serviços abstratos modulares na "camada intermédia"?
É claro que, para realmente alcançar uma gama completa de abstração "orientada para o usuário", a abstração de conta de cadeia completa é apenas o começo. Além da conta em si ser abstraída para melhorar a experiência, um centro de despacho de "nível intermediário" também pode tentar fazer outro trabalho abstrato:
A transferência de ativos de cadeia cruzada e a camada de liquidação unificada permitem que os usuários realizem a gestão e circulação de ativos de forma descentralizada entre diferentes cadeias, reduzindo o possível consumo de atrito de deslizamento de cadeias cruzadas.
Cross-chain DID unifica a concatenação de identidade e crédito, com a camada intermediária como o "centro de autenticação", para realizar o compartilhamento de identidade e sincronização de dados entre várias cadeias e, em seguida, derivar o "crédito" que pode ser aplicado entre cadeias, reduzir o limiar de plataforma cruzada para os usuários e, ao mesmo tempo, quebrar a separação de dados entre cadeias e realmente realizar a experiência interativa do padrão de "identidade";
Implemente uma solução unificada e descentralizada do Solver, é melhor agregar esses Solvers espalhados em um super centro de despacho do Solver, por exemplo, os usuários podem se conectar ao UniswapX e Cowswap e SUAVE do Flashbot e outras soluções do Solver em uma plataforma e construir um Solver que seja conveniente para potenciais participantes do Solver, como criadores de mercado, traders institucionais e cientistas de arbitragem. Porque sem a camada intermediária para agendamento, não há dúvida de que esses Solvers ainda existirão em fragmentos entre cadeias.
Você pode entender que, sob a premissa de que existem várias divisões padrão no ecossistema EVM, ERC4337 define as regras de comunicação, e a comunicação ainda depende de um IBC que atua como a "camada intermediária" para emergir.
E não subestime o valor desse tipo de INFRA de nível médio, porque é provável que seja um suplemento necessário para que a abstração de contas se afaste da camada de abstração de engenharia e avance para a popularização em larga escala.
Como maximizar o valor do padrão ERC4337, como unificar os produtos e padrões de protocolo de várias carteiras, cadeias e outros construtores na pista, e como realmente suavizar a lacuna entre a experiência do usuário Web2 e as características nativas da cadeia Web3 com base na orientação ao usuário são todos os tópicos que precisam ser superados.
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.
Por que a atual "abstração de conta" está muito dividida e como avançar para uma abstração unificada "orientada para o usuário"?
Autor: Haotian
Vendo que a Particle Network lançou recentemente a abstração de conta de cadeia completa, parece que precisa sobrepor uma "camada intermediária" em cima dos padrões de ERC4337 existentes, por que você tem que fazer isso? Se você está familiarizado com o status quo atual da abstração de contas, não é difícil encontrar a resposta:
Por que a prática atual do mercado de "abstração de contas" está muito dividida? Como a abstração de conta de cadeia completa da Particle Network é tecnicamente implementada? Até que ponto é possível alcançar a adoção em massa da trilha abstrata centrada na intenção? Vamos analisá-los um a um:
As soluções AA de abstração de conta são unificadas no nível de "engenharia" e a camada de prática é multifacetada
Em termos de simplicidade técnica, a abstração de conta é uma série de intenções que os usuários instalam no pool de memória do UserOP, e o empacotador as empacota e as envia para o contrato Entrypoint para execução, onde as transações em lote podem ser processadas através da agregação de assinatura do Agregador, e os detalhes do pagamento de gás são tratados pela Paymaster.
Este é um conjunto de padrões ERC4337 definidos, e a lógica de implementação de back-end também é unificada, mas é essencialmente uma abstração da cadeia EVM, e o front-end que conecta os usuários não é necessariamente "unificado".
Por exemplo, o zkSync usa endereços EOA para vincular contas, e todos os usuários veem é um endereço de sombra transferível, e o front-end dificilmente sente a existência de contas AA. Starknet, por outro lado, está na forma de uma conta de contrato atualizável, e os usuários precisam atualizar constantemente o contrato para atualizar a função da conta. Além disso, Argent usa o mecanismo de recuperação social do mecanismo Guardian, e o esquema de abstração de conta do Unipass tende a ser aplicado em aplicações multi-cadeia heterogêneas em ambientes não-EVM.
Espere, esse tipo de inconsistência na entrada parece ser uma espécie de personalização, mas sem dúvida aumenta o limiar para os usuários. A abstração vai e vem, por que o limiar é maior no "orientado para o usuário"? Isso se manifesta no fato de que é impossível para um usuário interagir com apenas uma cadeia em um ambiente multi-cadeia e multi-Layer2, e o custo de aprendizagem é gerado do nada ao abranger várias carteiras e várias cadeias; Um usuário gerará vários endereços de contrato diferentes em diferentes cadeias EVM, o que traz desafios para o gerenciamento unificado de ativos.
Como uma implementação de engenharia padrão ERC4337 multicadeia tão fragmentada pode levar a uma adoção em massa orientada ao usuário?
Qual é a dificuldade na lógica da prática abstrata das contas unificadas? Tomemos como exemplo a abstração de conta de cadeia completa
Como mencionado anteriormente, a abstração da conta corrente é baseada apenas na cadeia EVM, mas o endereço EOA ainda pode ser unificado com a cadeia EVM, por quê?
Como os endereços EOA são derivados da computação de chave pública, desde que os algoritmos de diferentes cadeias sejam os mesmos e a chave privada seja a mesma, o endereço derivado também é o mesmo. No entanto, o endereço do contrato é calculado a partir do endereço do Criador e do nonce, e o endereço do contrato é diferente devido aos diferentes nonces de cada cadeia. Uma abordagem aparentemente viável é usar uma abordagem de registro para mapear o mesmo endereço entre diferentes cadeias, mas há um risco de centralização.
Por outro lado, o diagrama de estrutura abstrata da Particle Network de toda a conta da cadeia, está tentando assumir o papel de um "centro de expedição" com a estrutura nativa da cadeia descentralizada, e cada nova cadeia com um novo endereço será gerada pelo contrato geral do centro de despacho, e o sub-Contrato de Implantação será uniformemente conectado ao Contrato de Implantação para operação unificada, incluindo implantação e atualização, todos os aspetos serão uniformemente programados pelo contrato geral.
A única dificuldade nisso é a fluência da comunicação instantânea entre cadeias heterogêneas, o que requer que a "camada intermediária" atue como um meio de comunicação eficiente, que pode alcançar um agendamento unificado distribuindo contratos em cada nó leve da cadeia, e o esquema de prática é semelhante à solução cross-chain da LayerZero.
Esta abordagem, pelo menos, rompe as limitações de atributos das cadeias EVM, de modo que qualquer cadeia múltipla que suporte a interoperabilidade de contratos de cadeia heterogênea e o esquema EIP-4337 serão incluídos no sistema multicadeia. A abstração de conta de cadeia completa pode ser implementada em grande escala.
No entanto, cadeias não-EVM como Aptos e Sui são atualmente incapazes de se conectar de forma semelhante em série. Este é um mercado grande o suficiente em um momento em que o ecossistema Ethereum é absolutamente dominante nas categorias Camada, Camada 2 e Camada 3.
Que tipo de imaginação pode ser libertada por outros serviços abstratos modulares na "camada intermédia"?
É claro que, para realmente alcançar uma gama completa de abstração "orientada para o usuário", a abstração de conta de cadeia completa é apenas o começo. Além da conta em si ser abstraída para melhorar a experiência, um centro de despacho de "nível intermediário" também pode tentar fazer outro trabalho abstrato:
A transferência de ativos de cadeia cruzada e a camada de liquidação unificada permitem que os usuários realizem a gestão e circulação de ativos de forma descentralizada entre diferentes cadeias, reduzindo o possível consumo de atrito de deslizamento de cadeias cruzadas.
Cross-chain DID unifica a concatenação de identidade e crédito, com a camada intermediária como o "centro de autenticação", para realizar o compartilhamento de identidade e sincronização de dados entre várias cadeias e, em seguida, derivar o "crédito" que pode ser aplicado entre cadeias, reduzir o limiar de plataforma cruzada para os usuários e, ao mesmo tempo, quebrar a separação de dados entre cadeias e realmente realizar a experiência interativa do padrão de "identidade";
Implemente uma solução unificada e descentralizada do Solver, é melhor agregar esses Solvers espalhados em um super centro de despacho do Solver, por exemplo, os usuários podem se conectar ao UniswapX e Cowswap e SUAVE do Flashbot e outras soluções do Solver em uma plataforma e construir um Solver que seja conveniente para potenciais participantes do Solver, como criadores de mercado, traders institucionais e cientistas de arbitragem. Porque sem a camada intermediária para agendamento, não há dúvida de que esses Solvers ainda existirão em fragmentos entre cadeias.
Você pode entender que, sob a premissa de que existem várias divisões padrão no ecossistema EVM, ERC4337 define as regras de comunicação, e a comunicação ainda depende de um IBC que atua como a "camada intermediária" para emergir.
E não subestime o valor desse tipo de INFRA de nível médio, porque é provável que seja um suplemento necessário para que a abstração de contas se afaste da camada de abstração de engenharia e avance para a popularização em larga escala.
Como maximizar o valor do padrão ERC4337, como unificar os produtos e padrões de protocolo de várias carteiras, cadeias e outros construtores na pista, e como realmente suavizar a lacuna entre a experiência do usuário Web2 e as características nativas da cadeia Web3 com base na orientação ao usuário são todos os tópicos que precisam ser superados.