Abstração de contas multi-chain: Revelando o futuro da 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) – será realizada em Bruxelas, Bélgica. Esta edição da conferência (EthCC 7) contará com mais de 350 líderes de opinião da indústria de blockchain que farão palestras, incluindo Alfred, um desenvolvedor da imToken Labs, que discutirá profundamente o tema "análise da abstração de contas multi-chain".

Pontos principais da apresentação

• As duas principais características da abstração de contas (AA): abstração de assinatura e abstração de pagamento. A primeira permite que os usuários escolham qualquer mecanismo de validação, enquanto a segunda suporta várias opções de pagamento de transações, melhorando conjuntamente a segurança e a experiência do usuário.

• Há diferenças no design das funções de ponto de entrada nas fases de verificação e execução entre ERC-4337 e AA nativa. O ponto de entrada na fase de verificação do ERC-4337 é fixo, enquanto o da fase de execução não é fixo; na AA nativa, ambos os pontos de entrada nas duas fases são fixos.

• Ao implementar o ERC-4337 em cadeias compatíveis com EVM, as diferenças nos protocolos do design do Rollup e a maneira como os endereços são calculados resultam em diferenças sutis, mas importantes, na implementação entre L1 e L2.

Abstração de contas

A essência da abstração de contas

A abstração de contas (AA) inclui principalmente dois pontos-chave:

1. Abstração de assinatura: permite que os usuários escolham qualquer mecanismo de verificação que desejem, não se limitando a algoritmos de assinatura digital específicos.

2. 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 ativos nativos, ou serem patrocinados por terceiros.

Essa flexibilidade aumentou consideravelmente a segurança e a experiência do usuário.

Análise do ERC-4337

O ERC-4337 visa superar as limitações das contas de propriedade externa do Ethereum (EOA), introduzindo métodos mais flexíveis de gestão de contas e processamento de transações:

• Estrutura userOp: O utilizador envia o userOp ao Bundler, que recolhe vários userOp e os envia ao contrato EntryPoint através da chamada da função handleOps.

• Contrato EntryPoint: como o núcleo do processamento de transações, as principais funções incluem:

  1. Chame a função validate do contrato de conta para validar a autorização do userOp.
  2. Cobrar taxas.
  3. Chame a função execute do contrato de conta para executar a operação alvo userOp.

visão geral da AA nativa

Na AA nativa, cada conta é um contrato, e o mecanismo de processamento de transações está diretamente embutido no protocolo blockchain. O design de AA adotado em diferentes redes varia.

• Abstração de contas ERC-4337: Ethereum, Arbitrum, Optimism, Base, Linea, Scroll, Polygon PoS
• Seguir a abstração de contas nativa ERC-4337: StarkNet e zkSync Era
• abstração de contas nativa com design de privacidade: Aztec

Comparação entre ERC-4337 e AA nativo

função do sistema operativo

O sistema operacional AA precisa resolver os seguintes problemas:

• Decisão do preço do gás
• Determinação da ordem de transações e posição do pool de memória
• Disparo da função de ponto de entrada
• Definição do processo de tratamento de transações

O ERC-4337 conclui essas tarefas através da colaboração entre o Bundler e o Contrato EntryPoint. Já na AA nativa, os usuários enviam os userOps diretamente para os operadores/ordenadores do servidor oficial.

No StarkNet, o Sequencer é responsável por lidar com todas essas tarefas. O zkSync Era requer que o Operator trabalhe em conjunto com o bootloader (contrato do sistema).

interface de contrato

A interface do contrato da conta é aproximadamente semelhante em diferentes implementações, contendo a função de ponto de entrada chamada pelo sistema operacional de abstração de contas (AA):

• 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
• StarkNet：executar、validar、validar_declarar、validar_implantar

etapas de verificação restritas

Para prevenir ataques DoS, diferentes implementações impuseram limitações distintas na validação de transações:

• O ERC-4337 define códigos de operação proibidos e restrições de acesso à memória.
• zkSync Era aliviou o uso de alguns OpCodes, mas limitou o alcance de acesso ao armazenamento.
• StarkNet não permite chamadas de contratos externos.

limite de etapas de execução

• zkSync requer a confirmação da bandeira do sistema para executar chamadas de sistema.
• ERC-4337 e StarkNet não têm restrições especiais na fase de execução.

tratamento de números aleatórios

• O ERC-4337 distingue entre valores de chave de 192 bits e valores aleatórios de 64 bits.
• zkSync utiliza o contrato do sistema NonceHolder para gerenciar o nonce, garantindo um aumento estrito.
• O nonce do StarkNet também aumenta estritamente, mas não há um contrato de gestão específico.

primeira transação de implantação

• ERC-4337 contém o campo initcode na estrutura userOp, usado para a implantação inicial do contrato da conta.
• StarkNet e zkSync exigem que os usuários enviem a primeira transação para o operador/classificador para implantar o contrato de conta.

zkSync de design especial

zkSync permite que os usuários transfiram ETH diretamente de um EOA do Ethereum, sem a necessidade de implantar um contrato de conta personalizado para obter uma conta padrão com o mesmo endereço, que pode funcionar como um EOA do Ethereum.

Diferenças na implementação do ERC-4337 entre L1 e L2

diferença de protocolo

O L2 precisa enviar dados para o L1 para garantir segurança e liquidação. No ERC-4337, a taxa de segurança do L1 e as taxas de blob devem ser incluídas no Gas de pré-validação, o que apresenta desafios para determinar as taxas de upload apropriadas.

diferença de endereço

A forma de calcular endereços em diferentes cadeias é diferente:

• O método de codificação de endereço na função create do zkSync ERA é diferente do Ethereum e do OP.
• StarkNet utiliza uma função de hash única para calcular endereços.

Além disso, os novos códigos de operação introduzidos no hard fork podem causar alterações no bytecode, afetando assim a consistência do endereço do contrato da conta. Por exemplo, se a cadeia L2 não suportar o hard fork de Xangai e a versão EVM não for especificada durante a compilação, a introdução do push0 alterará o bytecode.