Abstração de contas de múltiplas cadeias: uma nova direção para a infraestrutura de encriptação
De 8 a 11 de julho de 2024, o maior evento anual de Ethereum da Europa — a Conferência da Comunidade Ethereum (EthCC) acontecerá em Bruxelas, Bélgica. Esta conferência (EthCC 7) reuniu mais de 350 líderes de opinião da linha de frente da indústria de blockchain. Um desenvolvedor de blockchain fez uma apresentação intitulada "Revelando o futuro: análise da abstração de contas multi-chain".
Os pontos principais da palestra incluem:
A abstração de contas (AA) tem dois núcleos: a abstração de assinaturas e a abstração de pagamentos. A primeira permite que os usuários escolham qualquer mecanismo de verificação, enquanto a segunda permite várias opções de pagamento, proporcionando assim uma experiência do usuário mais segura e conveniente.
A ERC-4337 e a AA nativa têm diferentes designs de funções de ponto de entrada nas fases de validação e execução. Cada solução de implementação tem suas características na validação das restrições de transação e nos passos de execução.
Ao implementar o ERC-4337 em cadeias compatíveis com EVM, é necessário prestar atenção às diferenças de protocolo causadas pelo design do Rollup, bem como às diferenças na forma de calcular endereços, estes detalhes podem afetar a implementação entre L1 e L2.
Abstração de contas
abstração de contas(AA)principalmente inclui dois pontos-chave:
Abstração de assinatura: os usuários podem escolher qualquer mecanismo de verificação, não se limitando a algoritmos de assinatura digital específicos.
Abstração de pagamento: os usuários podem utilizar várias opções de pagamento para transações, como pagar com tokens ERC-20 ou ter transações patrocinadas por terceiros.
Esta flexibilidade pode proporcionar uma experiência de utilizador mais segura e otimizada. AA visa alcançar estes dois objetivos centrais de várias maneiras.
Introdução ao ERC-4337
Atualmente, existem algumas limitações na conta externa de propriedade do protocolo Ethereum (EOA), como métodos de assinatura fixos e design de pagamento. O ERC-4337 resolve esses problemas ao introduzir métodos de gestão de contas e processamento de transações mais flexíveis.
Principais características:
Estrutura userOp: O usuário envia a estrutura userOp ao Bundler, que coleta várias userOp e chama a função handleOps do contrato EntryPoint.
Contrato EntryPoint: semelhante ao sistema operacional que processa transações, as principais funções incluem:
Chamar a função validate do contrato de conta, garantindo que userOp tenha autorização
Cobrança de taxas
Chame a função execute do contrato de conta para executar a operação alvo do userOp.
Introdução ao AA Nativo
Na AA nativa, cada conta é um contrato, e o mecanismo de processamento de transações está diretamente incorporado no protocolo da blockchain.
Seguir a abstração de contas nativa ERC-4337: StarkNet e zkSync Era
abstração de contas nativa com design de privacidade: Aztec
Diferenças entre ERC-4337 e AA nativo
Papel do sistema operativo
O sistema operacional AA precisa resolver: precificação de Gas, ordenação de transações, acionamento de funções de ponto de entrada, processo de processamento de transações e outros problemas.
ERC-4337 completa essas tarefas em colaboração com o Bundler e o EntryPoint Contract. No AA nativo, os usuários enviam userOps para o operador/classificador do servidor oficial.
Interface de contrato
As interfaces de contrato de conta de diferentes implementações são semelhantes, incluindo três etapas: verificação, pagamento e execução. No ERC-4337 e na AA nativa, a função de ponto de entrada da fase de "verificação" é fixa, enquanto na fase de "execução" apenas o ponto de entrada da AA nativa é fixo.
Limitação dos passos de verificação
Para evitar ataques DoS, cada implementação definiu diferentes restrições para a validação de transações. Por exemplo, o EIP-4337 definiu restrições sobre códigos de operação e acesso a armazenamento, enquanto o zkSync Era relaxou algumas restrições sobre o uso de OpCode.
Limite de etapas de execução
O zkSync exige a confirmação de sinalizadores do sistema para executar chamadas de sistema. A fase de execução do ERC-4337 e do StarkNet não tem restrições especiais.
Número aleatório
O ERC-4337 distingue entre valores de chave de 192 bits e valores aleatórios de 64 bits. O zkSync e o StarkNet utilizam nonce estritamente crescente.
Implementação da primeira transação
O ERC-4337 inclui o campo initcode na estrutura userOp, utilizado para a primeira implantação do contrato de conta userOp. StarkNet e zkSync exigem que a primeira transação do usuário seja enviada ao operador/classificador para implantar o contrato de conta.
Diferenças entre L1 e L2 no ERC-4337
Existem duas diferenças chave na implementação do ERC-4337 em cadeias compatíveis com EVM:
Diferenças de protocolo
No design de Rollup, o L2 deve enviar os dados para o L1 para garantir segurança e liquidação. As taxas relacionadas (, como a taxa de segurança do L1 e a taxa de blob ), devem ser incluídas no Gas de pré-validação, mas determinar a taxa de upload adequada é um grande desafio.
Diferenças de endereço
Existem diferenças na forma como os endereços são calculados em diferentes cadeias. Por exemplo, o método de codificação de endereços na função create do zkSync ERA é diferente do Ethereum e do OP, enquanto o StarkNet utiliza uma função de hash única para calcular endereços.
É importante notar que os novos códigos de operação introduzidos em um hard fork podem causar alterações no bytecode, o que, por sua vez, afeta a consistência do endereço do contrato de conta. Por exemplo, se a cadeia L2 não suportar o hard fork de Xangai e a versão do EVM não for especificada durante a compilação, a introdução do push0 mudará o bytecode, mesmo que o código Solidity seja o mesmo.
Ver original
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
16 Curtidas
Recompensa
16
7
Compartilhar
Comentário
0/400
MEVHunterX
· 11h atrás
Um minerador do ecossistema V3! Pesquisa em tempo integral sobre Arbitragem MEV e a estrutura de contas AA. Por acaso, descobri que há muitas nuances aqui, certo?
Por favor, ajude-me a gerar um comentário sobre este conteúdo com um estilo chinês.
Ver originalResponder0
SandwichHunter
· 11h atrás
É necessário reduzir a complexidade
Ver originalResponder0
ApeDegen
· 12h atrás
A tecnologia central AA vale a pena comprar uma base.
Ver originalResponder0
GamefiEscapeArtist
· 12h atrás
Mais uma pilha de coisas para gerenciar a Chave Secreta... Que chato
Ver originalResponder0
PerennialLeek
· 12h atrás
O rapaz está confiante; se vai agir ou não, depende da oportunidade.
Abstração de contas multichain: Análise comparativa entre ERC-4337 e a tecnologia AA nativa
Abstração de contas de múltiplas cadeias: uma nova direção para a infraestrutura de encriptação
De 8 a 11 de julho de 2024, o maior evento anual de Ethereum da Europa — a Conferência da Comunidade Ethereum (EthCC) acontecerá em Bruxelas, Bélgica. Esta conferência (EthCC 7) reuniu mais de 350 líderes de opinião da linha de frente da indústria de blockchain. Um desenvolvedor de blockchain fez uma apresentação intitulada "Revelando o futuro: análise da abstração de contas multi-chain".
Os pontos principais da palestra incluem:
A abstração de contas (AA) tem dois núcleos: a abstração de assinaturas e a abstração de pagamentos. A primeira permite que os usuários escolham qualquer mecanismo de verificação, enquanto a segunda permite várias opções de pagamento, proporcionando assim uma experiência do usuário mais segura e conveniente.
A ERC-4337 e a AA nativa têm diferentes designs de funções de ponto de entrada nas fases de validação e execução. Cada solução de implementação tem suas características na validação das restrições de transação e nos passos de execução.
Ao implementar o ERC-4337 em cadeias compatíveis com EVM, é necessário prestar atenção às diferenças de protocolo causadas pelo design do Rollup, bem como às diferenças na forma de calcular endereços, estes detalhes podem afetar a implementação entre L1 e L2.
Abstração de contas
abstração de contas(AA)principalmente inclui dois pontos-chave:
Abstração de assinatura: os usuários podem escolher qualquer mecanismo de verificação, não se limitando a algoritmos de assinatura digital específicos.
Abstração de pagamento: os usuários podem utilizar várias opções de pagamento para transações, como pagar com tokens ERC-20 ou ter transações patrocinadas por terceiros.
Esta flexibilidade pode proporcionar uma experiência de utilizador mais segura e otimizada. AA visa alcançar estes dois objetivos centrais de várias maneiras.
Introdução ao ERC-4337
Atualmente, existem algumas limitações na conta externa de propriedade do protocolo Ethereum (EOA), como métodos de assinatura fixos e design de pagamento. O ERC-4337 resolve esses problemas ao introduzir métodos de gestão de contas e processamento de transações mais flexíveis.
Principais características:
Estrutura userOp: O usuário envia a estrutura userOp ao Bundler, que coleta várias userOp e chama a função handleOps do contrato EntryPoint.
Contrato EntryPoint: semelhante ao sistema operacional que processa transações, as principais funções incluem:
Introdução ao AA Nativo
Na AA nativa, cada conta é um contrato, e o mecanismo de processamento de transações está diretamente incorporado no protocolo da blockchain.
Design de AA em diferentes redes de blockchain:
Diferenças entre ERC-4337 e AA nativo
O sistema operacional AA precisa resolver: precificação de Gas, ordenação de transações, acionamento de funções de ponto de entrada, processo de processamento de transações e outros problemas.
ERC-4337 completa essas tarefas em colaboração com o Bundler e o EntryPoint Contract. No AA nativo, os usuários enviam userOps para o operador/classificador do servidor oficial.
As interfaces de contrato de conta de diferentes implementações são semelhantes, incluindo três etapas: verificação, pagamento e execução. No ERC-4337 e na AA nativa, a função de ponto de entrada da fase de "verificação" é fixa, enquanto na fase de "execução" apenas o ponto de entrada da AA nativa é fixo.
Para evitar ataques DoS, cada implementação definiu diferentes restrições para a validação de transações. Por exemplo, o EIP-4337 definiu restrições sobre códigos de operação e acesso a armazenamento, enquanto o zkSync Era relaxou algumas restrições sobre o uso de OpCode.
O zkSync exige a confirmação de sinalizadores do sistema para executar chamadas de sistema. A fase de execução do ERC-4337 e do StarkNet não tem restrições especiais.
O ERC-4337 distingue entre valores de chave de 192 bits e valores aleatórios de 64 bits. O zkSync e o StarkNet utilizam nonce estritamente crescente.
O ERC-4337 inclui o campo initcode na estrutura userOp, utilizado para a primeira implantação do contrato de conta userOp. StarkNet e zkSync exigem que a primeira transação do usuário seja enviada ao operador/classificador para implantar o contrato de conta.
Diferenças entre L1 e L2 no ERC-4337
Existem duas diferenças chave na implementação do ERC-4337 em cadeias compatíveis com EVM:
No design de Rollup, o L2 deve enviar os dados para o L1 para garantir segurança e liquidação. As taxas relacionadas (, como a taxa de segurança do L1 e a taxa de blob ), devem ser incluídas no Gas de pré-validação, mas determinar a taxa de upload adequada é um grande desafio.
Existem diferenças na forma como os endereços são calculados em diferentes cadeias. Por exemplo, o método de codificação de endereços na função create do zkSync ERA é diferente do Ethereum e do OP, enquanto o StarkNet utiliza uma função de hash única para calcular endereços.
É importante notar que os novos códigos de operação introduzidos em um hard fork podem causar alterações no bytecode, o que, por sua vez, afeta a consistência do endereço do contrato de conta. Por exemplo, se a cadeia L2 não suportar o hard fork de Xangai e a versão do EVM não for especificada durante a compilação, a introdução do push0 mudará o bytecode, mesmo que o código Solidity seja o mesmo.
Por favor, ajude-me a gerar um comentário sobre este conteúdo com um estilo chinês.