Beosin: EIP-7702 e análise de auditoria de segurança de carteira AA de última geração

A abstração de conta (AA) é uma direção importante da exploração de longo prazo no ecossistema Ethereum, com o objetivo de quebrar a fronteira entre contas externas (EOA) e contas de contrato, para que a carteira tenha programabilidade, segurança e capacidade de atualização mais fortes. O EIP-4337 é atualmente a solução de implementação AA mais convencional e tem sido amplamente utilizada em várias carteiras de contratos inteligentes baseadas em EntryPoint (como Safe, Stacks e Argent). No entanto, o EIP-4337 ainda tem certas limitações em termos de natividade on-chain, complexidade operacional e compatibilidade ecológica devido à introdução de um pool de transações independente e mecanismo de contrato on-ramp.

Para reduzir ainda mais a barreira de entrada e aprimorar o suporte nativo para abstrações de contas, Vitalik propôs o EIP-7702 em 2024 e o incluiu na atualização do Pectra. A ideia central do EIP-7702 é permitir que um EOA original execute o código de contrato (contract_code) de um endereço especificado ao iniciar uma transação e usar esse código para definir a lógica de execução da transação.

O EIP-7702 apresenta um novo mecanismo para "injeção de código no nível da transação", que permite que as contas de usuário especifiquem dinamicamente a lógica de execução em cada transação, em vez de depender do código de contrato pré-implantado. Isso quebra o modelo tradicional de permissão baseada em código estático, traz maior flexibilidade e introduz novos desafios de segurança: contratos que dependem da lógica de julgamento, como isContract e extcodehash, podem se tornar inválidos e alguns sistemas que assumem que o chamador é EOA puro também podem ser ignorados. Para os auditores, é importante não apenas verificar a segurança do código injetado em si, mas também avaliar seu impacto potencial em outros sistemas contratuais em um contexto dinâmico.

Neste artigo, a equipe de segurança da Beosin se concentrará nos princípios de design e nos principais recursos do EIP-7702, classificará sistematicamente os riscos de segurança que a carteira AA construída com base nele pode enfrentar na auditoria e apresentará o processo de auditoria e sugestões de uma perspectiva prática para ajudar os pesquisadores de segurança a lidar melhor com os desafios técnicos sob este novo paradigma.

1. Introdução ao EIP-77021

. Visão geral técnica do EIP-7702EIP-7702

introduz um novo tipo de transação, 0x 04 (SetCode), que permite que o EOA autorize o código do contrato que precisa ser executado por meio dessa transação, com a seguinte estrutura de transação:

1. rlp([chain_id, nonce, max_priority_fee_per_gas, max_ fee_per_gas, gas_limit,

2. destino, valor, dados, access_list, authorization_list, signature_y_parity, signature_r, signature_s])

Onde authorization_list contém várias listas de autorização e também pode conter ações de autorização de iniciadores que não são de transação, a estrutura interna é:

1. authorization_list = [[chain_id, address, nonce, y_parity, r, s]].

onde chain_id representa a cadeia na qual a autorização do usuário entra em vigor e seu valor deve ser igual ao ID da cadeia de execução ou 0. Quando chain_id é 0, a autorização entra em vigor para todas as cadeias EVM que suportam EIP-7702, mas somente se outros parâmetros (como nonce) corresponderem. address indica o endereço do contrato de destino autorizado pelo usuário.

Após a conclusão da autorização, o sistema modificará o campo de código do usuário autorizado para 0x ef 0100 || address, onde address é o endereço do contrato autorizado. Se você quiser desautorizar, basta iniciar uma transação SetCode com o endereço definido como 0.

algarismo. Vantagens do EIP 7702

(1) Flexibilidade e Personalização

Contas abstratasAo escrever a lógica da conta em contratos inteligentes, você pode personalizar funções de forma flexível de acordo com suas necessidades. Por exemplo, os usuários podem configurar várias assinaturas, recuperação social e controle de cotas para atender às necessidades de indivíduos ou empresas em diferentes cenários. Esse design melhora muito a escalabilidade funcional da conta e rompe as limitações das contas externas tradicionais (EOA).

(2) Segurança

aprimoradaAs contas abstratas fornecem um mecanismo de segurança em várias camadas, incluindo autenticação multifator, limites de transação e recuperação social. Mesmo que um usuário perca sua chave privada, ele pode recuperar sua conta por meio de contatos confiáveis ou autenticação multifator, evitando a perda permanente de ativos causada pela perda da chave privada em contas tradicionais. Ao mesmo tempo, funções como controle de limite também podem impedir que grandes quantias de fundos sejam roubadas maliciosamente.

(3) A

Conta de Captação Otimizada para Gás suporta um mecanismo flexível de captação de gás, permitindo que os usuários paguem pelo Gás por meio de terceiros e até usem diretamente outros tokens para pagar taxas de transação. Esse mecanismo não apenas reduz o custo de operação dos usuários, mas também simplifica ainda mais o uso do blockchain, especialmente adequado para usuários iniciantes ou cenários complexos de transação em várias etapas.

(4) Promover a popularização da Web3Ao

otimizar a experiência e a segurança, as contas abstratas ocultam a complexidade do blockchain em lugares que os usuários não podem ver, proporcionando operações convenientes mais próximas da Web2. Esse design reduz o custo de aprendizado de usuários comuns, permite que mais pessoas participem de aplicativos Web3 sem barreiras e promove a popularização da tecnologia descentralizada.

2. Análise dos riscos de segurança no EIP-7702 na prática

Embora o EIP-7702 tenha injetado um novo ímpeto no ecossistema Ethereum e expandido uma variedade de cenários de aplicativos, ao mesmo tempo, ele inevitavelmente introduziu alguns novos riscos de segurança:

1. Ataque de repetição de autorização

No modelo EIP-7702, se o usuário autorizar o chain_ Se o campo id for definido como 0, a autorização poderá entrar em vigor em várias cadeias. Embora esse design de "autorização universal de cadeia cruzada" melhore a flexibilidade em alguns cenários, ele também apresenta riscos de segurança óbvios.

É importante observar que, mesmo que a identidade da conta do mesmo endereço seja a mesma em cadeias diferentes, a implementação do contrato por trás dela pode ser completamente diferente. Isso significa que um invasor pode implantar uma versão maliciosa do contrato em outra cadeia e executar ações não intencionais usando a autorização do mesmo endereço na cadeia, representando riscos para os ativos do usuário.

Portanto, para provedores de serviços de carteira ou plataformas de interação front-end, quando os usuários executam essas operações de autorização, eles devem verificar claramente se o chainId declarado na autorização do usuário é consistente com a rede de conexão atual; Se um usuário for detectado definindo o chainId como 0, um aviso de risco claro deve ser dado para lembrar ao usuário que a autorização entrará em vigor em todas as cadeias compatíveis com EVM e pode ser abusada por contratos maliciosos.

Além disso, o provedor de serviços também deve avaliar se deve restringir ou proibir a autorização com chainId 0 por padrão na camada de interface do usuário para reduzir o risco de operação incorreta ou ataques de phishing.

2. Compatibilidade do contrato

1) Compatibilidade de retorno de chamada do contrato

transferir dinheiro para um endereço de contrato para contratos de token existentes, como ERC-721, ERC-777 e ERC 1155, eles chamarão interfaces de retorno de chamada padrão (como onERC 721 Received, tokensReceived) para concluir a operação de transferência. Se o endereço de recebimento não implementar a interface correspondente, a transferência falhará ou até mesmo fará com que o ativo seja bloqueado.

No EIP-7702, um endereço de usuário pode ser transformado em uma conta de contrato recebendo um código de contrato por meio da operação "set_code". Neste caso:

• O endereço do usuário é considerado um contrato;

• Se o contrato não implementar a interface de retorno de chamada necessária, a transferência de token falhará;

• Os usuários podem não conseguir receber tokens convencionais sem seu conhecimento.

Portanto, os desenvolvedores devem garantir que o contrato de destino delegado pelo usuário implemente a interface de retorno de chamada relevante para garantir a compatibilidade com tokens convencionais.

(2) falha na verificação "tx.origin"Nos

contratos tradicionais, "tx.origin" é frequentemente usado para determinar se a transação é iniciada diretamente pelo usuário e é usado para evitar controles de segurança, como chamadas de contrato.

No entanto, no cenário EIP-7702, o

• usuário assina uma transação de autorização e o retransmissor ou empacotador a transmite em nome do usuário. Quando uma transação é executada, "tx.origin" é o endereço de retransmissão, não o endereço do usuário.

• "msg.sender" é um contrato de carteira que representa a identidade do usuário.

Portanto, a verificação de permissão baseada em "tx.origin == msg.sender" fará com que as operações legítimas do usuário sejam rejeitadas e percam a confiabilidade, e as mesmas chamadas de contrato restritas, como "tx.origin == user", também serão invalidadas. Recomenda-se abandonar "tx.origin" como base para julgamento de segurança e usar o mecanismo de verificação ou autorização de assinatura.

(3) "isContract" julga malMuitos

contratos impedem que as contas contratuais participem de certas operações, como airdrops, vendas instantâneas, etc., por meio de "isContract(address)":

require(!isContract(msg.sender), "Contratos não permitidos"

). De acordo com o mecanismo EIP-7702, o endereço do usuário pode ser alterado para uma conta de contrato por meio de uma transação "set_code" e "isContract" retorna true, e o contrato identificará erroneamente o usuário legítimo como a conta do contrato e se recusará a participar da operação, resultando na impossibilidade do usuário de usar determinados serviços e no bloqueio da experiência.

Com a popularização gradual das carteiras de contratos, o design de confiar em "isContract" para determinar se "um usuário humano" não é mais seguro, e é recomendável usar métodos de identificação de usuário mais precisos, como verificação de assinatura.

3. Ataque de phishingApós

a implementação do mecanismo de delegação do EIP-7702, os ativos na conta do usuário serão totalmente controlados pelo contrato inteligente delegado. Depois que um usuário autoriza um contrato malicioso, um invasor pode obter controle total sobre os ativos da conta, resultando na rápida transferência ou roubo de fundos, o que é extremamente arriscado.

Portanto, para provedores de serviços de carteira, é necessário oferecer suporte ao mecanismo de resolução de transações e identificação de risco EIP-7702 o mais rápido possívelCrucial. Quando um usuário assina uma transação de atribuição, o front-end deve exibir de forma clara e proeminente o endereço do contrato de destino e combinar informações de suporte, como origem do contrato e informações de implantação, para ajudar os usuários a identificar possíveis comportamentos fraudulentos ou de phishing, reduzindo assim o risco de assinatura incorreta. Além disso, o serviço de carteira deve integrar recursos de análise automática de segurança para o contrato de destino, como verificação de status de código aberto do código do contrato, análise do modelo de permissão e identificação de operação potencialmente perigosa, para ajudar os usuários a fazer julgamentos mais seguros antes da autorização.

Em particular, o EIP-7702 introduz um formato de assinatura delegada que não é compatível com os padrões de assinatura EIP-191 e EIP-712 existentes. Sua assinatura pode facilmente ignorar o aviso de assinatura original e o prompt de interação da carteira, o que aumenta ainda mais o risco de os usuários serem enganados para assinar operações maliciosas. Portanto, a introdução do mecanismo de identificação e processamento da estrutura de assinatura na implementação da carteira será um elo fundamental para garantir a segurança dos usuários.

4. Riscos do Contrato de Carteira

( 1) Gerenciamento de Autoridade de Contrato de Carteira

Muitos contratos de carteira EIP-7702 adotam uma arquitetura de proxy (ou permissões de gerenciamento integradas) para oferecer suporte a atualizações lógicas. No entanto, isso também representa um risco maior de gerenciamento de direitos. Se os privilégios de escalonamento não forem estritamente restritos, um invasor poderá substituir o contrato de implementação e injetar código mal-intencionado, resultando na adulteração da conta do usuário ou no roubo de fundos.

Recomendações de segurança

• : use mecanismos de assinatura múltipla, autenticação multifator ou timelock para controlar privilégios de escalonamento.

• As alterações de código e permissão estão sujeitas a auditoria rigorosa e validação de segurança.

• O processo de atualização é aberto e transparente para garantir o direito dos usuários de saber e participar.

(2) Risco de conflitos de armazenamento e isolamento de dados, versões de

contrato de carteira ou diferentes provedores de serviços de carteira podem reutilizar o mesmo slot de armazenamento. Se o usuário alterar o provedor de serviços de carteira ou atualizar a lógica da carteira, a reutilização do slot de armazenamento causará conflito de variável de estado, substituição de dados, leitura de exceções e outros problemas. Isso não apenas pode atrapalhar o funcionamento normal da carteira, mas também pode levar à perda de fundos ou permissões anormais.

Recomendações de segurança:

• use um esquema de isolamento de armazenamento especializado, como o padrão EIP-1967, ou aproveite um namespace exclusivo para gerenciar slots de armazenamento.

• Ao atualizar o contrato, certifique-se de que o layout de armazenamento seja compatível e evite variáveis sobrepostas.

• Teste rigorosamente a plausibilidade do estado armazenado durante o processo de atualização.

(3) O gerenciamento de nonce dentro da carteira

O contrato da carteira geralmente configura um nonce dentro e se gerencia para garantir a ordem de execução das operações do usuário e evitar ataques de repetição. Se o nonce for usado incorretamente, a operação do usuário não será executada corretamente.

Recomendação de segurança:

• O nonce deve ser verificado à força para um valor equivalente (ou incremento) e não pode ser ignorado.

• É proibido que as funções modifiquem diretamente o nonce, e o nonce só será atualizado quando a operação do usuário for executada.

• Projete mecanismos de tolerância a falhas e recuperação para exceções nonce para evitar deadlocks nonce.

(4) Verificação de permissão do chamador da funçãoPara

garantir a segurança, o contrato da carteira deve garantir que o chamador da função principal seja a conta proprietária da carteira. Os dois métodos comuns incluem:

• assinatura off-chain autoriza

os usuários a assinar um conjunto de operações por meio da chave privada e o contrato da carteira verifica se a assinatura é legítima, expirou e satisfaz o nonce correspondente na cadeia. Esse método é aplicável ao modo de transação de retransmissão defendido pelo EIP-7702 (assinatura offline do usuário + retransmissão envia transação em nome do usuário).

• restrição de chamada (msg.sender == address(this))

só pode ser acionada pelo próprio contrato, que é essencialmente um mecanismo de controle de caminho de chamada que garante que o iniciador externo seja a própria conta. Isso é efetivamente equivalente a exigir que o chamador seja o EOA original, uma vez que o endereço do contrato é o endereço EOA.

3. Perspectiva: A proposta do EIP-7702 e o futuro padrão de carteira AA

EIP-7702 não é apenas uma inovação do modelo de conta tradicional, mas também uma grande promoção do ecossistema de abstração de contas. A capacidade de carregar o código do contrato introduzida por ele traz um amplo espaço para exploração para o futuro design da carteira e do sistema de contrato, e também apresenta novos requisitos para os padrões de auditoria de segurança.

1. Coevolução com EIP-4337: Rumo à compatibilidade de modo duploEmbora

o EIP-7702 e o EIP-4337 tenham objetivos de design diferentes, o primeiro reconstrói o mecanismo de carregamento de código da conta e o último cria um ecossistema completo de entrada e empacotamento de transações. No entanto, os dois não estão em conflito, mas têm forte complementaridade:

● O EIP-4337 fornece um "canal de transação comum" e uma "interface abstrata de execução de conta";

● O EIP-7702 permite que as contas de usuário concedam dinamicamente recursos de lógica de contrato sem alterar o endereço;

Portanto, no futuro, as carteiras podem adotar uma "arquitetura de suporte de modo duplo": use o EIP-7702 como um substituto leve em cadeias que não suportam o EIP-4337 e continue a contar com a pilha de protocolo completa do EIP-4337 em cenários que exigem empacotamento off-chain e agregação multiusuário.

Esse mecanismo de modo duplo também permitirá que as carteiras suportem modelos de permissão de conta mais flexíveis, mecanismos de downgrade e esquemas de reversão na camada do kernel.

2. Suporte e inspiração para novas lógicas de carteira, como MPC e ZK, e o

mecanismo de contrato de conta defendido pelo EIP-7702 tem potencial de integração natural com a atual carteira MPC popular, carteira ZK, carteira modular e outras novas arquiteturas:

● No modelo MPC, o comportamento da assinatura não depende mais de uma única chave privada, mas é uma tomada de decisão colaborativa de várias partes. As assinaturas geradas por meio da convergência de EIP-7702 e MPC controlam a lógica de contrato carregada dinamicamente, permitindo estratégias de execução mais flexíveis.

● A carteira ZK verifica a identidade ou autorização do usuário por meio de provas de conhecimento zero, sem expor informações de chave privada. Combinadas com o EIP-7702, as carteiras ZK podem injetar temporariamente contratos lógicos específicos após a conclusão da verificação, de modo a realizar a implantação de comportamentos personalizados após a computação de privacidade, como a execução automática de uma determinada lógica somente após certas condições de privacidade serem atendidas.

● As carteiras modulares podem usar o EIP-7702 para desmontar a lógica da conta em vários módulos e carregá-los dinamicamente quando necessário.

Portanto, o EIP-7702 fornece um "contêiner de execução" mais nativo para as carteiras avançadas mencionadas acima: diferentes lógicas de contrato podem ser injetadas com o mesmo endereço de usuário, evitando o problema de dependência de endereço no processo tradicional de implantação de contrato e eliminando a necessidade de pré-implantação, melhorando muito a flexibilidade e a combinação do comportamento da conta.

3. Implicações para desenvolvedores e auditores de contratosO

impulsionará uma mudança profunda no paradigma de desenvolvimento. Os desenvolvedores de contratos não tratam mais simplesmente o chamador como um EOA tradicional ou uma conta de contrato fixo, mas devem se adaptar a um novo mecanismo: a identidade do chamador pode ser alternada dinamicamente entre o EOA e o status do contrato durante a transação, e a lógica de comportamento da conta não é mais solidificada estaticamente, mas pode ser alterada de forma flexível de acordo com a demanda. Isso exige que desenvolvedores e auditores:

• introduzam uma lógica mais rígida de verificação de chamadas e julgamento de permissão;

• Verifique se o caminho da chamada é afetado pela lógica dinâmica do contrato;

• identificar possíveis vulnerabilidades que dependem de comportamentos como msg.sender.code.length == 0, isContract() etc.;

• Esclareça as "dependências de contexto" da lógica do contrato, como controle de limite de chamadas estáticas e delegadas;

• No nível da cadeia de ferramentas, há suporte para simulação e análise de reversão de cenários setCode.

Em outras palavras, a segurança do código não é mais apenas um "problema de pré-implantação", mas um "processo dinâmico que deve ser verificado durante a invocação e a transação".

4.

apresenta uma implementação mais leve, nativa e flexível de Abstração de Conta (AA), para que o EOA comum possa transportar a lógica do contrato e executá-la em uma única transação. Esse mecanismo quebra as suposições estáticas tradicionais sobre o comportamento da conta, e os desenvolvedores não podem mais simplesmente confiar no estado do código do endereço da conta para julgar seu modelo de comportamento, mas precisam reconstruir a compreensão do limite de identidade e autoridade do chamador.

Com isso, vem uma mudança de paradigma na análise de segurança. O foco da auditoria não se limita mais a "se um endereço tem permissões", mas a "o que a lógica do contrato carregada na transação pode fazer no contexto atual". Cada transação pode ter uma definição independente de comportamento, o que dá à conta maior funcionalidade e apresenta requisitos mais altos para auditorias de segurança.