Abstração de contas multi-chain: explorando o futuro da infraestrutura de encriptação
De 8 a 11 de julho de 2024, a Conferência da Comunidade Ethereum (EthCC) será realizada em Bruxelas, na Bélgica. Como o maior evento anual de Ethereum na Europa, esta conferência se concentra no desenvolvimento técnico e comunitário.
Na presente Conferência da Comunidade Ethereum (EthCC 7), mais de 350 líderes de opinião do setor de blockchain proferiram discursos. Entre eles, um desenvolvedor de blockchain foi convidado a participar e fez uma apresentação sobre o tema "Revelando o Futuro: Análise da Abstração de Contas Multichain".
Resumo dos pontos da palestra
A abstração de contas (AA) inclui 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 oferece várias opções de pagamento para transações. Essa flexibilidade melhora significativamente a segurança e a experiência do usuário.
As funções de ponto de entrada na fase de verificação do ERC-4337 e do AA nativo são fixas, mas na fase de execução, apenas o AA nativo mantém um ponto de entrada fixo. As diferentes maneiras de implementação têm características distintas nas restrições de transação de verificação e nos passos de execução de transação.
Ao implementar o ERC-4337 em cadeias compatíveis com EVM, enfrenta-se principalmente dois grandes desafios: as diferenças de protocolo no design do Rollup e as diferenças na forma de cálculo de endereços. Essas diferenças resultam em alguns detalhes de desenvolvimento difíceis de perceber ao implementar o ERC-4337 entre L1 e L2.
Abstração de contas: Introdução
A definição da abstração de contas
abstração de contas (AA)主要包含两个关键概念：
Abstração de assinatura: os usuários podem escolher livremente qualquer mecanismo de verificação que gostem, não se limitando a algoritmos de assinatura digital específicos (como ECDSA).
Abstração de pagamentos: os usuários podem usar várias maneiras de pagar as taxas de transação, como usar tokens ERC-20 em vez de tokens nativos, ou ser patrocinados por terceiros para a transação.
Esta flexibilidade não só aumentou a segurança, como também otimizou a experiência do utilizador. O objetivo da abstração de contas é alcançar estes dois conceitos fundamentais de várias maneiras.
Análise do ERC-4337
Atualmente, as contas de propriedade externa (EOA) no protocolo Ethereum têm algumas limitações, como métodos de assinatura fixos e design de pagamento. O ERC-4337 aborda esses problemas ao introduzir métodos de gestão de contas e processamento de transações mais flexíveis.
Estrutura userOp: no ERC-4337, o usuário envia a estrutura userOp para o Bundler. O Bundler coleta várias userOp e as envia para o contrato EntryPoint chamando a função handleOps.
Contrato EntryPoint: Este contrato processa transações como um sistema operativo, e suas principais funções incluem:
Chamar a função validate no contrato da conta para garantir que userOp obtenha a autorização do proprietário da conta.
Cobrança de taxas.
Chamar a função execute no contrato da conta para executar a operação alvo do userOp.
Introdução ao AA nativo
No Ethereum, as contas são divididas em EOA e contas de contrato. No entanto, na AA nativa, cada conta é um contrato, e o mecanismo de processamento de transações está diretamente incorporado no protocolo blockchain.
Seguir a abstração de contas nativa ERC-4337: StarkNet e a era zkSync
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 os seguintes problemas:
Decisor do preço do gás
Decisor da ordem de transações e posição do pool de memória
Gatilho da função de ponto de entrada
Fatores determinantes do processo de tratamento de transações
No ERC-4337, esses papéis são desempenhados em conjunto pelo Bundler e pelo EntryPoint Contract.
No AA nativo, os usuários enviam seus userOps para o operador/classificador do servidor oficial, em vez de para o Bundler e o EntryPoint Contract.
No StarkNet, o Sequencer é responsável por tratar todas essas tarefas.
As principais características do zkSync Era são que o Operador precisa trabalhar em conjunto com o bootloader (contrato do sistema). O bootloader é responsável por iniciar novos blocos, definir os parâmetros do bloco e os parâmetros de Gas, e receber as transações do Operador para validação.
interface de contrato
Devido à existência de três etapas, a interface do contrato de conta é semelhante em diferentes implementações, e esses pontos de entrada só podem ser chamados pelo AA OS:
ERC-4337: validação de operações do usuário
zkSync: validação de transações, pagamento de transações, execução de transações
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 na AA nativa é fixo.
Limitações nos passos de verificação
Devido à ausência de limites de custo na validação de transações, um atacante pode realizar um ataque DoS ao pool de memória, impactando o bundler (EIP-4337) ou o operador/classificador (AA nativo).
O EIP-4337 define os códigos de operação proibidos e as restrições de acesso ao armazenamento. O zkSync Era aligeirou o uso de alguns OpCode:
A lógica do contrato só pode acessar seu próprio slot de armazenamento.
A lógica do contrato não pode acessar variáveis globais, como o número do bloco.
StarkNet não permite a chamada de contratos externos.
Limitações dos passos de execução
Em zkSync, a execução de chamadas de sistema requer a confirmação da existência de sinais do sistema. Por exemplo, aumentar o nonce requer interação com o NonceHolder, enquanto a implementação de contratos requer interação com o ContractDeployer.
Não há restrições especiais na fase de execução para ERC-4337 e StarkNet.
tratamento de números aleatórios
ERC-4337: O design do ponto de entrada distingue entre o valor da chave de 192 bits e o valor aleatório de 64 bits.
zkSync: O contrato do sistema NonceHolder gerencia o nonce, garantindo um aumento rigoroso.
StarkNet: o nonce também é estritamente crescente, mas não há um contrato específico de gestão.
primeira transação de implantação
ERC-4337: a estrutura userOp contém o campo initcode, utilizado para implantar o remetente (contrato de conta) na primeira userOp.
StarkNet e zkSync: os usuários devem enviar a primeira transação para o operador/classificador para implantar o contrato de conta.
design especial zkSync
No zkSync, se você transferir ETH diretamente de um EOA do Ethereum, sem a necessidade de implantar um contrato de conta personalizado, o usuário receberá uma conta padrão com o mesmo endereço. Essa conta pode funcionar como um EOA do Ethereum e é controlada pela chave privada correspondente do EOA do Ethereum.
Este tipo de conta é da versão None em vez da versão 1. Os usuários não podem chamar as funções DefaultAccount, pois não foi implementado nenhum código no espaço do kernel.
Diferenças entre L1 e L2 em 4337
A implementação do ERC-4337 em cadeias compatíveis com EVM apresenta duas diferenças principais: diferenças de protocolo e diferenças de endereço.
diferenças de protocolo
No design de Rollup, o L2 precisa carregar dados para o L1 para garantir segurança e liquidação. No ERC-4337, as taxas relacionadas a este processo de upload (como a taxa de segurança L1 e a taxa de blob) devem estar incluídas no Gas de pré-validação. Determinar as taxas de upload apropriadas no Gas de pré-validação é um desafio significativo.
diferença de endereço
O modo de codificação de endereços na função create do zkSync ERA é diferente do Ethereum e da agregação OP. Além disso, o StarkNet utiliza uma função de hash única para o cálculo de endereços.
No contexto do ERC-4337 em cadeias compatíveis com EVM, geralmente assumimos que o cálculo de endereços é consistente entre as várias cadeias. No entanto, um detalhe que pode ser facilmente ignorado pode levar a endereços de contratos de conta diferentes entre as implementações do ERC-4337 no Ethereum e no L2.
A questão chave é a adição de novos códigos de operação em forks duros. Por exemplo, se a cadeia L2 não suportar o fork duro de Xangai e a versão EVM não for especificada durante a compilação, a introdução do push0 resultará em alterações no bytecode, mesmo que o código Solidity permaneça o mesmo.
Ver original
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
8 Curtidas
Recompensa
8
5
Compartilhar
Comentário
0/400
StableGenius
· 15h atrás
*bocejos* mais uma conversa aa... já vi este filme antes, empiricamente falando, são apenas os maxies do eth a lidar com isso.
Ver originalResponder0
OfflineNewbie
· 15h atrás
Veja quem ainda está pulando
Ver originalResponder0
TokenVelocity
· 15h atrás
Vamos falar sobre todos os projetos nas cadeias depois...
A conferência EthCC discute a abstração de contas multichain: comparação técnica entre ERC-4337 e AA nativo.
Abstração de contas multi-chain: explorando o futuro da infraestrutura de encriptação
De 8 a 11 de julho de 2024, a Conferência da Comunidade Ethereum (EthCC) será realizada em Bruxelas, na Bélgica. Como o maior evento anual de Ethereum na Europa, esta conferência se concentra no desenvolvimento técnico e comunitário.
Na presente Conferência da Comunidade Ethereum (EthCC 7), mais de 350 líderes de opinião do setor de blockchain proferiram discursos. Entre eles, um desenvolvedor de blockchain foi convidado a participar e fez uma apresentação sobre o tema "Revelando o Futuro: Análise da Abstração de Contas Multichain".
Resumo dos pontos da palestra
A abstração de contas (AA) inclui 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 oferece várias opções de pagamento para transações. Essa flexibilidade melhora significativamente a segurança e a experiência do usuário.
As funções de ponto de entrada na fase de verificação do ERC-4337 e do AA nativo são fixas, mas na fase de execução, apenas o AA nativo mantém um ponto de entrada fixo. As diferentes maneiras de implementação têm características distintas nas restrições de transação de verificação e nos passos de execução de transação.
Ao implementar o ERC-4337 em cadeias compatíveis com EVM, enfrenta-se principalmente dois grandes desafios: as diferenças de protocolo no design do Rollup e as diferenças na forma de cálculo de endereços. Essas diferenças resultam em alguns detalhes de desenvolvimento difíceis de perceber ao implementar o ERC-4337 entre L1 e L2.
Abstração de contas: Introdução
A definição da abstração de contas
abstração de contas (AA)主要包含两个关键概念：
Abstração de assinatura: os usuários podem escolher livremente qualquer mecanismo de verificação que gostem, não se limitando a algoritmos de assinatura digital específicos (como ECDSA).
Abstração de pagamentos: os usuários podem usar várias maneiras de pagar as taxas de transação, como usar tokens ERC-20 em vez de tokens nativos, ou ser patrocinados por terceiros para a transação.
Esta flexibilidade não só aumentou a segurança, como também otimizou a experiência do utilizador. O objetivo da abstração de contas é alcançar estes dois conceitos fundamentais de várias maneiras.
Análise do ERC-4337
Atualmente, as contas de propriedade externa (EOA) no protocolo Ethereum têm algumas limitações, como métodos de assinatura fixos e design de pagamento. O ERC-4337 aborda esses problemas ao introduzir métodos de gestão de contas e processamento de transações mais flexíveis.
Estrutura userOp: no ERC-4337, o usuário envia a estrutura userOp para o Bundler. O Bundler coleta várias userOp e as envia para o contrato EntryPoint chamando a função handleOps.
Contrato EntryPoint: Este contrato processa transações como um sistema operativo, e suas principais funções incluem:
Introdução ao AA nativo
No Ethereum, as contas são divididas em EOA e contas de contrato. No entanto, na AA nativa, cada conta é um contrato, e o mecanismo de processamento de transações está diretamente incorporado no protocolo blockchain.
Design de AA em várias redes de blockchain:
Diferenças entre ERC-4337 e AA nativo
papel do sistema operativo
O sistema operacional AA precisa resolver os seguintes problemas:
No ERC-4337, esses papéis são desempenhados em conjunto pelo Bundler e pelo EntryPoint Contract.
No AA nativo, os usuários enviam seus userOps para o operador/classificador do servidor oficial, em vez de para o Bundler e o EntryPoint Contract.
No StarkNet, o Sequencer é responsável por tratar todas essas tarefas.
As principais características do zkSync Era são que o Operador precisa trabalhar em conjunto com o bootloader (contrato do sistema). O bootloader é responsável por iniciar novos blocos, definir os parâmetros do bloco e os parâmetros de Gas, e receber as transações do Operador para validação.
interface de contrato
Devido à existência de três etapas, a interface do contrato de conta é semelhante em diferentes implementações, e esses pontos de entrada só podem ser chamados pelo AA OS:
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 na AA nativa é fixo.
Limitações nos passos de verificação
Devido à ausência de limites de custo na validação de transações, um atacante pode realizar um ataque DoS ao pool de memória, impactando o bundler (EIP-4337) ou o operador/classificador (AA nativo).
O EIP-4337 define os códigos de operação proibidos e as restrições de acesso ao armazenamento. O zkSync Era aligeirou o uso de alguns OpCode:
Limitações dos passos de execução
Em zkSync, a execução de chamadas de sistema requer a confirmação da existência de sinais do sistema. Por exemplo, aumentar o nonce requer interação com o NonceHolder, enquanto a implementação de contratos requer interação com o ContractDeployer.
Não há restrições especiais na fase de execução para ERC-4337 e StarkNet.
tratamento de números aleatórios
primeira transação de implantação
design especial zkSync
No zkSync, se você transferir ETH diretamente de um EOA do Ethereum, sem a necessidade de implantar um contrato de conta personalizado, o usuário receberá uma conta padrão com o mesmo endereço. Essa conta pode funcionar como um EOA do Ethereum e é controlada pela chave privada correspondente do EOA do Ethereum.
Este tipo de conta é da versão None em vez da versão 1. Os usuários não podem chamar as funções DefaultAccount, pois não foi implementado nenhum código no espaço do kernel.
Diferenças entre L1 e L2 em 4337
A implementação do ERC-4337 em cadeias compatíveis com EVM apresenta duas diferenças principais: diferenças de protocolo e diferenças de endereço.
diferenças de protocolo
No design de Rollup, o L2 precisa carregar dados para o L1 para garantir segurança e liquidação. No ERC-4337, as taxas relacionadas a este processo de upload (como a taxa de segurança L1 e a taxa de blob) devem estar incluídas no Gas de pré-validação. Determinar as taxas de upload apropriadas no Gas de pré-validação é um desafio significativo.
diferença de endereço
O modo de codificação de endereços na função create do zkSync ERA é diferente do Ethereum e da agregação OP. Além disso, o StarkNet utiliza uma função de hash única para o cálculo de endereços.
No contexto do ERC-4337 em cadeias compatíveis com EVM, geralmente assumimos que o cálculo de endereços é consistente entre as várias cadeias. No entanto, um detalhe que pode ser facilmente ignorado pode levar a endereços de contratos de conta diferentes entre as implementações do ERC-4337 no Ethereum e no L2.
A questão chave é a adição de novos códigos de operação em forks duros. Por exemplo, se a cadeia L2 não suportar o fork duro de Xangai e a versão EVM não for especificada durante a compilação, a introdução do push0 resultará em alterações no bytecode, mesmo que o código Solidity permaneça o mesmo.