A Abstração de Conta (AA) é uma direção importante de 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 maior programabilidade, segurança e capacidade de atualização. O EIP-4337, como a solução de implementação AA mais convencional, tem sido amplamente utilizado em várias carteiras de contratos inteligentes baseadas em EntryPoint (como Safe, Stacks e Argent). No entanto, a EIP-4337 ainda tem certas limitações em termos de atividade on-chain, complexidade operacional e compatibilidade ecológica devido à sua introdução de um pool de transações independente e mecanismo de contrato na rampa.
Para reduzir ainda mais a barreira de uso da abstração de contas e aumentar seu suporte nativo, Vitalik propôs a EIP-7702 em 2024, que foi incorporada na atualização Pectra. A ideia central da EIP-7702 é: permitir que um EOA original, ao iniciar uma transação, possa executar o código do contrato (contract_code) em um endereço específico, definindo assim a lógica de execução dessa transação.
A EIP-7702 introduziu um novo mecanismo de "injeção de código a nível de transação", permitindo que as contas dos usuários especifiquem dinamicamente a lógica de execução em cada transação, em vez de depender do código de contrato pré-implantado. Isso rompe o modelo de permissões tradicional baseado em código estático, trazendo maior flexibilidade, mas também introduz novos desafios de segurança: contratos que originalmente dependiam de lógicas de verificação como isContract e extcodehash podem falhar, e algumas suposições de que o chamador é um EOA puro também podem ser contornadas. Para os auditores, não é apenas necessário verificar a segurança do código injetado, mas também avaliar seu impacto potencial em outros sistemas de contratos em um contexto dinâmico.
Neste artigo, a equipe de segurança da Beosin irá abordar os princípios de design e as características chave do EIP-7702, sistematicamente revisar os riscos de segurança que as carteiras AA construídas com base nele podem enfrentar durante a auditoria, e, a partir de uma perspectiva prática, propor um processo de auditoria e recomendações para ajudar os pesquisadores de segurança a enfrentar melhor os desafios técnicos sob este novo paradigma.
Um, Introdução ao EIP-7702
Visão Geral da Tecnologia EIP-7702
EIP-7702 introduz um novo tipo de transação 0x04 (SetCode), que permite que EOA autorize o código do contrato a ser executado através desta transação, cuja estrutura de transação é a seguinte:
O authorization_list contém várias listas de autorização, podendo também incluir ações de autorização de não iniciadores de transações, e a estrutura interna é:
Neste caso, chain_id representa a cadeia na qual a autorização do usuário é válida, exigindo que seu valor seja igual ao ID da cadeia de execução ou 0. Quando chain_id é 0, isso indica que a autorização é válida para todas as cadeias EVM que suportam EIP-7702, desde que outros parâmetros (como nonce) correspondam. address representa o endereço do contrato alvo autorizado pelo usuário.
Após a autorização, o sistema irá modificar o campo code do usuário autorizado para 0xef0100 || address, onde address é o endereço do contrato autorizado. Se desejar cancelar a autorização, basta iniciar uma transação SetCode definindo address como 0.
Vantagens do EIP7702
(1) Flexibilidade e Personalização
As contas abstratas podem personalizar suas funcionalidades de forma flexível de acordo com as necessidades, ao escrever a lógica da conta em contratos inteligentes. Por exemplo, os usuários podem configurar assinaturas múltiplas, recuperação social, controle de limites, entre outros, atendendo às diferentes necessidades de indivíduos ou empresas. Este design aumenta significativamente a escalabilidade funcional da conta, superando as limitações das contas externas tradicionais (EOA).
(2) Aumentar a segurança
As contas abstratas oferecem múltiplas camadas de mecanismos de segurança, incluindo autenticação em várias etapas, limites de transação e recuperação social. Mesmo que o usuário perca a chave privada, pode recuperar a conta através de contatos confiáveis ou autenticação múltipla, evitando a perda permanente de ativos que ocorre com contas tradicionais devido à perda da chave privada. Ao mesmo tempo, funcionalidades como controle de limite também podem prevenir o roubo malicioso de grandes quantias de dinheiro.
(3) Gas otimização
A conta abstrata suporta um mecanismo de abstração de Gas flexível, permitindo que os usuários paguem o Gas através de terceiros, ou até mesmo usem outros tokens para pagar as taxas de transação. Este mecanismo não só reduz os custos operacionais dos usuários, mas também simplifica ainda mais o processo de uso da blockchain, sendo especialmente adequado para usuários iniciantes ou cenários de transações complexas em várias etapas.
(4) Acelerar a popularização do Web3
Ao otimizar a experiência e a segurança, contas abstratas escondem a complexidade da blockchain em um lugar que os usuários não veem, oferecendo operações mais convenientes semelhantes ao Web2. Este design reduz o custo de aprendizado para usuários comuns, permitindo que mais pessoas participem sem barreiras em aplicações Web3, promovendo a popularização da tecnologia descentralizada.
Dois, Análise dos riscos de segurança na prática do EIP-7702
Apesar de o EIP-7702 ter injetado nova dinâmica no ecossistema Ethereum e expandido uma rica gama de cenários de aplicação, ao mesmo tempo, ele também introduziu inevitavelmente algumas novas vulnerabilidades de segurança:
Ataque de repetição autorizado
No modelo EIP-7702, se um usuário definir o campo chain_id na autorização como 0, isso indica que a autorização é válida em várias cadeias. Embora esse design de "autorização genérica entre cadeias" aumente a flexibilidade em certos cenários, também introduz riscos de segurança evidentes.
É importante notar que, mesmo que a identidade da conta do mesmo endereço em cadeias diferentes seja a mesma, 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 assim um risco para os ativos do usuário.
Portanto, para prestadores de serviços de carteira ou plataformas de interação frontal, ao realizar operações de autorização desse tipo, deve-se verificar claramente se o chainId declarado na autorização do usuário corresponde à rede atual conectada; se detectar que o usuário definiu o chainId como 0, deve-se fornecer um aviso claro de risco, alertando o usuário de que essa autorização será válida em todas as cadeias compatíveis com EVM e pode ser abusada por contratos maliciosos.
Além disso, o prestador de serviços deve avaliar se deve limitar ou proibir por padrão o chainId igual a 0 na camada de UI, para reduzir o risco de operações incorretas ou ataques de phishing.
Questões de compatibilidade de contratos
(1) compatibilidade de callback de contrato
Os contratos de tokens existentes como ERC-721, ERC-777, ERC1155, ao transferirem para um endereço de contrato, chamarão as interfaces de callback padrão (como onERC721Received, tokensReceived) para completar a operação de transferência. Se o endereço de recepção não implementar a interface correspondente, a transferência falhará ou poderá até resultar no bloqueio de ativos.
No EIP-7702, os endereços de usuários podem ser atribuídos a códigos de contrato através da operação "set_code", tornando-se contas de contrato. Neste momento:
O endereço do usuário será considerado como um contrato;
Caso o contrato não implemente as interfaces de callback necessárias, a transferência de tokens falhará.
Os usuários podem não conseguir receber tokens principais sem saber.
Assim, os desenvolvedores devem garantir que os contratos-alvo delegados pelos usuários implementem as interfaces de callback relevantes, a fim de garantir a compatibilidade com os tokens mais utilizados.
(2) A verificação de "tx.origin" falhou
Em contratos tradicionais, "tx.origin" é frequentemente utilizado para determinar se a transação foi iniciada diretamente pelo usuário, sendo utilizado para controlar a segurança, como a prevenção de chamadas de contrato.
Mas no cenário do EIP-7702:
O usuário assina a transação autorizada, que é realmente transmitida por um relé ou serviço de agrupamento (bundler); ao executar a transação, o "tx.origin" é o endereço do relé e não o endereço do usuário.
"msg.sender" é o contrato de carteira que representa a identidade do usuário.
Portanto, a verificação de permissões baseada em "tx.origin == msg.sender" levará à recusa de operações de usuários legítimos, perdendo a confiabilidade, e o uso de restrições semelhantes como "tx.origin == user" para contratos também falhará. Recomenda-se deixar de usar "tx.origin" como base para julgamentos de segurança, optando por verificações de assinatura ou mecanismos de autorização.
(3) "isContract" erro de avaliação
Muitos contratos evitam que contas de contrato participem em certas operações, como airdrops, compras em massa, etc., através de "isContract (address)" (verificar o comprimento do código do endereço) :
Sob o mecanismo EIP-7702, o endereço do usuário pode se tornar uma conta de contrato através da transação "set_code", com "isContract" retornando true. O contrato pode erroneamente classificar usuários legítimos como contas de contrato, recusando sua participação nas operações, levando à impossibilidade de usar certos serviços e prejudicando a experiência do usuário.
Com a popularização das carteiras de contrato, a designação de depender de "isContract" para determinar "se é um usuário humano" já não é segura. Recomenda-se o uso de métodos de identificação de usuários mais precisos, como a verificação de assinatura.
Ataque de phishing
Após a implementação do mecanismo de delegação do EIP-7702, os ativos na conta do usuário estarão completamente sob o controle do contrato inteligente delegado. Uma vez que o usuário autoriza um contrato malicioso, o atacante pode obter controle total sobre os ativos da conta, resultando em transferência rápida ou roubo de fundos, com um risco de segurança muito alto.
Por conseguinte, é importante que os prestadores de serviços de carteiras digitais apoiem os mecanismos de resolução de transações e identificação de riscos EIP-7702 o mais rapidamente possível. Quando um usuário assina uma transação de atribuição, o front-end deve exibir de forma clara e destacada o endereço do contrato de destino e combinar informações de suporte, como informações de origem do contrato e 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 automatizados de análise de segurança para o contrato de destino, como verificação de status de código aberto do código do contrato, análise de 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.
É especialmente importante notar que o formato de assinatura delegada introduzido pelo EIP-7702 não é compatível com os padrões de assinatura existentes EIP-191 e EIP-712. A sua assinatura pode facilmente contornar os avisos de assinatura e as mensagens de interação já existentes nas carteiras, aumentando ainda mais o risco de os usuários serem enganados ao assinar operações maliciosas. Portanto, a introdução de um mecanismo de reconhecimento e tratamento dessa estrutura de assinatura na implementação das carteiras será uma etapa chave para garantir a segurança dos usuários.
Risco de contrato de carteira
(1) Gestão de Permissões de Contratos de Carteira
Muitas carteiras de contrato EIP-7702 adotam uma arquitetura de proxy ( ou permissões de gestão embutidas ), para suportar atualizações lógicas. No entanto, isso também traz um risco maior de gestão de permissões. Se as permissões de atualização não forem rigorosamente restritas, um atacante pode substituir o contrato de implementação e injetar código malicioso, levando à alteração de contas de usuários ou ao roubo de fundos.
Sugestões de segurança:
Utilizar múltiplas assinaturas, autenticação de múltiplos fatores ou mecanismos de bloqueio de tempo para controlar permissões de atualização.
As alterações de código e permissões devem passar por uma auditoria rigorosa e verificação de segurança.
Processo de atualização transparente e público, garantindo o direito à informação e à participação dos usuários.
(2) Risco de conflito de armazenamento e isolamento de dados
Versões de contrato de carteira ou diferentes provedores 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 com a variável de estado e haverá problemas como substituição de dados e exceções de leitura. Isso não só pode perturbar o funcionamento normal da carteira, mas também pode levar à perda de fundos ou permissões anormais.
Sugestões de segurança:
Utilizar soluções de isolamento de armazenamento especializadas (como o padrão EIP-1967) ou aproveitar um espaço de nome único para gerenciar os slots de armazenamento.
Ao atualizar o contrato, certifique-se de que o layout de armazenamento é compatível, evitando sobreposição de variáveis.
Testar rigorosamente a razoabilidade do estado armazenado durante o processo de atualização.
(3) Gestão de nonce interna da carteira
Os contratos de carteira normalmente configuram um nonce internamente e gerem-no por conta própria, a fim de garantir a ordem de execução das operações do usuário e prevenir ataques de repetição. Se o nonce for utilizado de forma inadequada, isso pode resultar na incapacidade das operações do usuário de serem executadas corretamente.
Sugestões de segurança:
nonce deve ser verificado para ser equivalente (ou crescente), não pode ser pulado.
É proibido que a função modifique diretamente o nonce; ele só deve ser atualizado quando uma ação do usuário é executada.
Projetar mecanismos de tolerância a falhas e recuperação para situações anômalas de nonce, evitando deadlocks de nonce.
(4) verificação de permissões do chamador da função
Para garantir a segurança, o contrato da carteira deve garantir que o chamador das funções chave seja a conta do proprietário da carteira. As duas maneiras comuns incluem:
Autorização de assinatura off-chain
Os usuários assinam um conjunto de operações com a chave privada, e o contrato da carteira verifica na blockchain se a assinatura é válida, se não está expirada e se atende ao nonce correspondente. Este método é adequado para o modo de transação de relé promovido pelo EIP-7702 (assinatura offline do usuário + envio de transações pelo relé).
Chamada de restrição (msg.sender == endereço (this))
As funções de operação do usuário só podem ser acionadas pelo próprio contrato, sendo essencialmente um mecanismo de controle de caminho de chamada, garantindo que o iniciador externo deve ser a própria conta. Isso é, na prática, equivalente a exigir que o chamador seja o EOA original, pois neste caso o endereço do contrato é o endereço do EOA.
Três, Perspectivas: EIP-7702 e o futuro do padrão de carteira AA
A proposta do EIP-7702 não é apenas uma inovação no modelo de contas tradicional, mas também um grande impulso para a ecologia da abstração de contas. A capacidade introduzida de carregar código de contrato pelo usuário traz um amplo espaço para exploração no design de carteiras e no sistema de contratos no futuro, além de apresentar novas exigências para os padrões de auditoria de segurança.
Evolução colaborativa com EIP-4337: rumo à compatibilidade bimodal
Embora o EIP-7702 e o EIP-4337 tenham objetivos de design diferentes, o primeiro reestrutura o mecanismo de carregamento de código da conta, enquanto o segundo constrói uma entrada de transação completa e um ecossistema de empacotamento. No entanto, os dois não são conflitantes, mas sim altamente complementares:
EIP-4337 oferece o "canal de transações genéricas" e a "interface de execução de contas abstratas";
EIP-7702 permite que contas de usuários atribuam dinamicamente capacidades lógicas a contratos sem alterar o endereço;
Assim, a carteira do futuro pode adotar uma "arquitetura de suporte duplo": usar o EIP-7702 como uma alternativa leve em cadeias que não suportam o EIP-4337, enquanto continua a depender da pilha de protocolos completa do EIP-4337 em cenários que exigem empacotamento off-chain e agregação de múltiplos usuários.
Este mecanismo de dupla modalidade também incentivará as carteiras a suportar um modelo de permissões de conta mais flexível, mecanismos de degradação e planos de reversão a nível do núcleo.
Apoio e inspiração para novas lógicas de carteiras como MPC e ZK
O mecanismo de contrato de conta promovido pelo EIP-7702 possui um potencial natural de fusão com novas arquiteturas populares atualmente, como carteiras MPC, carteiras ZK e carteiras modular.
No modo MPC, o comportamento de assinatura não depende de uma única chave privada, mas sim de uma decisão colaborativa entre várias partes. A assinatura gerada pela fusão do EIP-7702 e do MPC pode controlar a lógica contratual dinamicamente carregada, permitindo assim estratégias de execução mais flexíveis.
A carteira ZK verifica a identidade ou autorização do usuário através de provas de conhecimento zero, sem a necessidade de expor informações da chave privada. Com a combinação do EIP-7702, a carteira ZK pode injetar temporariamente contratos lógicos específicos após a validação, permitindo a implementação de comportamentos personalizados após o cálculo de privacidade, como a execução automática de determinada lógica apenas quando certas condições de privacidade são atendidas.
As carteiras modulares (Modular Wallets) podem decompor a lógica da conta em vários módulos, utilizando o EIP-7702, e carregar dinamicamente quando necessário.
Assim, o EIP-7702 oferece um "contenedor de execução" mais nativo para as carteiras avançadas mencionadas: o endereço do usuário permanece o mesmo, permitindo a injeção de diferentes lógicas de contrato, evitando o problema de dependência de endereço no processo tradicional de implantação de contratos, e não é necessário pré-implantar, aumentando significativamente a flexibilidade e a capacidade de combinação das ações da conta.
Insights for contract developers and auditors
EIP-7702 vai impulsionar uma profunda transformação no paradigma de desenvolvimento. Os desenvolvedores de contratos não devem mais ver os chamadores como EOAs tradicionais ou contas de contrato fixas, mas devem se adaptar a um novo mecanismo: a identidade do chamador pode mudar dinamicamente entre EOA e estado do contrato durante o processo de transação, e a lógica de comportamento da conta não é mais estática, mas pode ser alterada de forma flexível conforme a necessidade. Isso exige que desenvolvedores e auditores tenham:
Introduzir uma lógica de validação de caller e verificação de permissões mais rigorosa;
Verifique se o caminho de chamada é afetado pela lógica do contrato dinâmico.
Identificar potenciais vulnerabilidades de comportamentos como msg.sender.code.length == 0, isContract ();
Esclarecer a "dependência de contexto" da lógica do contrato, como o controle de limites de chamadas estáticas e deleGatecall;
Suporta simulação e análise de restauração do cenário setCode a nível de cadeia de ferramentas.
Em outras palavras, a segurança do código não é mais apenas uma "questão antes da implementação", mas sim um "processo dinâmico que também deve ser verificado durante as chamadas e transações".
Quatro, Resumo
O EIP-7702 introduz uma implementação mais leve, nativa e flexível do Account Abstraction (AA), que permite que o EOA comum carregue a lógica do contrato e a execute 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 muda para "o que a lógica contratual realizada 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.
O conteúdo serve apenas de referência e não constitui uma solicitação ou oferta. Não é prestado qualquer aconselhamento em matéria de investimento, fiscal ou jurídica. Consulte a Declaração de exoneração de responsabilidade para obter mais informações sobre os riscos.
Beosin: Análise de auditoria de segurança da carteira AA de próxima geração EIP-7702
Escrito por: Beosin
A Abstração de Conta (AA) é uma direção importante de 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 maior programabilidade, segurança e capacidade de atualização. O EIP-4337, como a solução de implementação AA mais convencional, tem sido amplamente utilizado em várias carteiras de contratos inteligentes baseadas em EntryPoint (como Safe, Stacks e Argent). No entanto, a EIP-4337 ainda tem certas limitações em termos de atividade on-chain, complexidade operacional e compatibilidade ecológica devido à sua introdução de um pool de transações independente e mecanismo de contrato na rampa.
Para reduzir ainda mais a barreira de uso da abstração de contas e aumentar seu suporte nativo, Vitalik propôs a EIP-7702 em 2024, que foi incorporada na atualização Pectra. A ideia central da EIP-7702 é: permitir que um EOA original, ao iniciar uma transação, possa executar o código do contrato (contract_code) em um endereço específico, definindo assim a lógica de execução dessa transação.
A EIP-7702 introduziu um novo mecanismo de "injeção de código a nível de transação", permitindo que as contas dos usuários especifiquem dinamicamente a lógica de execução em cada transação, em vez de depender do código de contrato pré-implantado. Isso rompe o modelo de permissões tradicional baseado em código estático, trazendo maior flexibilidade, mas também introduz novos desafios de segurança: contratos que originalmente dependiam de lógicas de verificação como isContract e extcodehash podem falhar, e algumas suposições de que o chamador é um EOA puro também podem ser contornadas. Para os auditores, não é apenas necessário verificar a segurança do código injetado, mas também avaliar seu impacto potencial em outros sistemas de contratos em um contexto dinâmico.
Neste artigo, a equipe de segurança da Beosin irá abordar os princípios de design e as características chave do EIP-7702, sistematicamente revisar os riscos de segurança que as carteiras AA construídas com base nele podem enfrentar durante a auditoria, e, a partir de uma perspectiva prática, propor um processo de auditoria e recomendações para ajudar os pesquisadores de segurança a enfrentar melhor os desafios técnicos sob este novo paradigma.
Um, Introdução ao EIP-7702
EIP-7702 introduz um novo tipo de transação 0x04 (SetCode), que permite que EOA autorize o código do contrato a ser executado através desta transação, cuja estrutura de transação é a seguinte:
O authorization_list contém várias listas de autorização, podendo também incluir ações de autorização de não iniciadores de transações, e a estrutura interna é:
Neste caso, chain_id representa a cadeia na qual a autorização do usuário é válida, exigindo que seu valor seja igual ao ID da cadeia de execução ou 0. Quando chain_id é 0, isso indica que a autorização é válida para todas as cadeias EVM que suportam EIP-7702, desde que outros parâmetros (como nonce) correspondam. address representa o endereço do contrato alvo autorizado pelo usuário.
Após a autorização, o sistema irá modificar o campo code do usuário autorizado para 0xef0100 || address, onde address é o endereço do contrato autorizado. Se desejar cancelar a autorização, basta iniciar uma transação SetCode definindo address como 0.
(1) Flexibilidade e Personalização
As contas abstratas podem personalizar suas funcionalidades de forma flexível de acordo com as necessidades, ao escrever a lógica da conta em contratos inteligentes. Por exemplo, os usuários podem configurar assinaturas múltiplas, recuperação social, controle de limites, entre outros, atendendo às diferentes necessidades de indivíduos ou empresas. Este design aumenta significativamente a escalabilidade funcional da conta, superando as limitações das contas externas tradicionais (EOA).
(2) Aumentar a segurança
As contas abstratas oferecem múltiplas camadas de mecanismos de segurança, incluindo autenticação em várias etapas, limites de transação e recuperação social. Mesmo que o usuário perca a chave privada, pode recuperar a conta através de contatos confiáveis ou autenticação múltipla, evitando a perda permanente de ativos que ocorre com contas tradicionais devido à perda da chave privada. Ao mesmo tempo, funcionalidades como controle de limite também podem prevenir o roubo malicioso de grandes quantias de dinheiro.
(3) Gas otimização
A conta abstrata suporta um mecanismo de abstração de Gas flexível, permitindo que os usuários paguem o Gas através de terceiros, ou até mesmo usem outros tokens para pagar as taxas de transação. Este mecanismo não só reduz os custos operacionais dos usuários, mas também simplifica ainda mais o processo de uso da blockchain, sendo especialmente adequado para usuários iniciantes ou cenários de transações complexas em várias etapas.
(4) Acelerar a popularização do Web3
Ao otimizar a experiência e a segurança, contas abstratas escondem a complexidade da blockchain em um lugar que os usuários não veem, oferecendo operações mais convenientes semelhantes ao Web2. Este design reduz o custo de aprendizado para usuários comuns, permitindo que mais pessoas participem sem barreiras em aplicações Web3, promovendo a popularização da tecnologia descentralizada.
Dois, Análise dos riscos de segurança na prática do EIP-7702
Apesar de o EIP-7702 ter injetado nova dinâmica no ecossistema Ethereum e expandido uma rica gama de cenários de aplicação, ao mesmo tempo, ele também introduziu inevitavelmente algumas novas vulnerabilidades de segurança:
No modelo EIP-7702, se um usuário definir o campo chain_id na autorização como 0, isso indica que a autorização é válida em várias cadeias. Embora esse design de "autorização genérica entre cadeias" aumente a flexibilidade em certos cenários, também introduz riscos de segurança evidentes.
É importante notar que, mesmo que a identidade da conta do mesmo endereço em cadeias diferentes seja a mesma, 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 assim um risco para os ativos do usuário.
Portanto, para prestadores de serviços de carteira ou plataformas de interação frontal, ao realizar operações de autorização desse tipo, deve-se verificar claramente se o chainId declarado na autorização do usuário corresponde à rede atual conectada; se detectar que o usuário definiu o chainId como 0, deve-se fornecer um aviso claro de risco, alertando o usuário de que essa autorização será válida em todas as cadeias compatíveis com EVM e pode ser abusada por contratos maliciosos.
Além disso, o prestador de serviços deve avaliar se deve limitar ou proibir por padrão o chainId igual a 0 na camada de UI, para reduzir o risco de operações incorretas ou ataques de phishing.
(1) compatibilidade de callback de contrato
Os contratos de tokens existentes como ERC-721, ERC-777, ERC1155, ao transferirem para um endereço de contrato, chamarão as interfaces de callback padrão (como onERC721Received, tokensReceived) para completar a operação de transferência. Se o endereço de recepção não implementar a interface correspondente, a transferência falhará ou poderá até resultar no bloqueio de ativos.
No EIP-7702, os endereços de usuários podem ser atribuídos a códigos de contrato através da operação "set_code", tornando-se contas de contrato. Neste momento:
O endereço do usuário será considerado como um contrato;
Caso o contrato não implemente as interfaces de callback necessárias, a transferência de tokens falhará.
Os usuários podem não conseguir receber tokens principais sem saber.
Assim, os desenvolvedores devem garantir que os contratos-alvo delegados pelos usuários implementem as interfaces de callback relevantes, a fim de garantir a compatibilidade com os tokens mais utilizados.
(2) A verificação de "tx.origin" falhou
Em contratos tradicionais, "tx.origin" é frequentemente utilizado para determinar se a transação foi iniciada diretamente pelo usuário, sendo utilizado para controlar a segurança, como a prevenção de chamadas de contrato. Mas no cenário do EIP-7702:
O usuário assina a transação autorizada, que é realmente transmitida por um relé ou serviço de agrupamento (bundler); ao executar a transação, o "tx.origin" é o endereço do relé e não o endereço do usuário.
"msg.sender" é o contrato de carteira que representa a identidade do usuário.
Portanto, a verificação de permissões baseada em "tx.origin == msg.sender" levará à recusa de operações de usuários legítimos, perdendo a confiabilidade, e o uso de restrições semelhantes como "tx.origin == user" para contratos também falhará. Recomenda-se deixar de usar "tx.origin" como base para julgamentos de segurança, optando por verificações de assinatura ou mecanismos de autorização.
(3) "isContract" erro de avaliação
Muitos contratos evitam que contas de contrato participem em certas operações, como airdrops, compras em massa, etc., através de "isContract (address)" (verificar o comprimento do código do endereço) :
Sob o mecanismo EIP-7702, o endereço do usuário pode se tornar uma conta de contrato através da transação "set_code", com "isContract" retornando true. O contrato pode erroneamente classificar usuários legítimos como contas de contrato, recusando sua participação nas operações, levando à impossibilidade de usar certos serviços e prejudicando a experiência do usuário. Com a popularização das carteiras de contrato, a designação de depender de "isContract" para determinar "se é um usuário humano" já não é segura. Recomenda-se o uso de métodos de identificação de usuários mais precisos, como a verificação de assinatura.
Após a implementação do mecanismo de delegação do EIP-7702, os ativos na conta do usuário estarão completamente sob o controle do contrato inteligente delegado. Uma vez que o usuário autoriza um contrato malicioso, o atacante pode obter controle total sobre os ativos da conta, resultando em transferência rápida ou roubo de fundos, com um risco de segurança muito alto.
Por conseguinte, é importante que os prestadores de serviços de carteiras digitais apoiem os mecanismos de resolução de transações e identificação de riscos EIP-7702 o mais rapidamente possível. Quando um usuário assina uma transação de atribuição, o front-end deve exibir de forma clara e destacada o endereço do contrato de destino e combinar informações de suporte, como informações de origem do contrato e 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 automatizados de análise de segurança para o contrato de destino, como verificação de status de código aberto do código do contrato, análise de 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.
É especialmente importante notar que o formato de assinatura delegada introduzido pelo EIP-7702 não é compatível com os padrões de assinatura existentes EIP-191 e EIP-712. A sua assinatura pode facilmente contornar os avisos de assinatura e as mensagens de interação já existentes nas carteiras, aumentando ainda mais o risco de os usuários serem enganados ao assinar operações maliciosas. Portanto, a introdução de um mecanismo de reconhecimento e tratamento dessa estrutura de assinatura na implementação das carteiras será uma etapa chave para garantir a segurança dos usuários.
(1) Gestão de Permissões de Contratos de Carteira
Muitas carteiras de contrato EIP-7702 adotam uma arquitetura de proxy ( ou permissões de gestão embutidas ), para suportar atualizações lógicas. No entanto, isso também traz um risco maior de gestão de permissões. Se as permissões de atualização não forem rigorosamente restritas, um atacante pode substituir o contrato de implementação e injetar código malicioso, levando à alteração de contas de usuários ou ao roubo de fundos.
Sugestões de segurança:
Utilizar múltiplas assinaturas, autenticação de múltiplos fatores ou mecanismos de bloqueio de tempo para controlar permissões de atualização.
As alterações de código e permissões devem passar por uma auditoria rigorosa e verificação de segurança.
Processo de atualização transparente e público, garantindo o direito à informação e à participação dos usuários.
(2) Risco de conflito de armazenamento e isolamento de dados
Versões de contrato de carteira ou diferentes provedores 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 com a variável de estado e haverá problemas como substituição de dados e exceções de leitura. Isso não só pode perturbar o funcionamento normal da carteira, mas também pode levar à perda de fundos ou permissões anormais.
Sugestões de segurança:
Utilizar soluções de isolamento de armazenamento especializadas (como o padrão EIP-1967) ou aproveitar um espaço de nome único para gerenciar os slots de armazenamento.
Ao atualizar o contrato, certifique-se de que o layout de armazenamento é compatível, evitando sobreposição de variáveis.
Testar rigorosamente a razoabilidade do estado armazenado durante o processo de atualização.
(3) Gestão de nonce interna da carteira
Os contratos de carteira normalmente configuram um nonce internamente e gerem-no por conta própria, a fim de garantir a ordem de execução das operações do usuário e prevenir ataques de repetição. Se o nonce for utilizado de forma inadequada, isso pode resultar na incapacidade das operações do usuário de serem executadas corretamente.
Sugestões de segurança:
nonce deve ser verificado para ser equivalente (ou crescente), não pode ser pulado.
É proibido que a função modifique diretamente o nonce; ele só deve ser atualizado quando uma ação do usuário é executada.
Projetar mecanismos de tolerância a falhas e recuperação para situações anômalas de nonce, evitando deadlocks de nonce.
(4) verificação de permissões do chamador da função
Para garantir a segurança, o contrato da carteira deve garantir que o chamador das funções chave seja a conta do proprietário da carteira. As duas maneiras comuns incluem:
Autorização de assinatura off-chain
Os usuários assinam um conjunto de operações com a chave privada, e o contrato da carteira verifica na blockchain se a assinatura é válida, se não está expirada e se atende ao nonce correspondente. Este método é adequado para o modo de transação de relé promovido pelo EIP-7702 (assinatura offline do usuário + envio de transações pelo relé).
Chamada de restrição (msg.sender == endereço (this))
As funções de operação do usuário só podem ser acionadas pelo próprio contrato, sendo essencialmente um mecanismo de controle de caminho de chamada, garantindo que o iniciador externo deve ser a própria conta. Isso é, na prática, equivalente a exigir que o chamador seja o EOA original, pois neste caso o endereço do contrato é o endereço do EOA.
Três, Perspectivas: EIP-7702 e o futuro do padrão de carteira AA
A proposta do EIP-7702 não é apenas uma inovação no modelo de contas tradicional, mas também um grande impulso para a ecologia da abstração de contas. A capacidade introduzida de carregar código de contrato pelo usuário traz um amplo espaço para exploração no design de carteiras e no sistema de contratos no futuro, além de apresentar novas exigências para os padrões de auditoria de segurança.
Embora o EIP-7702 e o EIP-4337 tenham objetivos de design diferentes, o primeiro reestrutura o mecanismo de carregamento de código da conta, enquanto o segundo constrói uma entrada de transação completa e um ecossistema de empacotamento. No entanto, os dois não são conflitantes, mas sim altamente complementares:
EIP-4337 oferece o "canal de transações genéricas" e a "interface de execução de contas abstratas";
EIP-7702 permite que contas de usuários atribuam dinamicamente capacidades lógicas a contratos sem alterar o endereço;
Assim, a carteira do futuro pode adotar uma "arquitetura de suporte duplo": usar o EIP-7702 como uma alternativa leve em cadeias que não suportam o EIP-4337, enquanto continua a depender da pilha de protocolos completa do EIP-4337 em cenários que exigem empacotamento off-chain e agregação de múltiplos usuários.
Este mecanismo de dupla modalidade também incentivará as carteiras a suportar um modelo de permissões de conta mais flexível, mecanismos de degradação e planos de reversão a nível do núcleo.
O mecanismo de contrato de conta promovido pelo EIP-7702 possui um potencial natural de fusão com novas arquiteturas populares atualmente, como carteiras MPC, carteiras ZK e carteiras modular.
No modo MPC, o comportamento de assinatura não depende de uma única chave privada, mas sim de uma decisão colaborativa entre várias partes. A assinatura gerada pela fusão do EIP-7702 e do MPC pode controlar a lógica contratual dinamicamente carregada, permitindo assim estratégias de execução mais flexíveis.
A carteira ZK verifica a identidade ou autorização do usuário através de provas de conhecimento zero, sem a necessidade de expor informações da chave privada. Com a combinação do EIP-7702, a carteira ZK pode injetar temporariamente contratos lógicos específicos após a validação, permitindo a implementação de comportamentos personalizados após o cálculo de privacidade, como a execução automática de determinada lógica apenas quando certas condições de privacidade são atendidas.
As carteiras modulares (Modular Wallets) podem decompor a lógica da conta em vários módulos, utilizando o EIP-7702, e carregar dinamicamente quando necessário.
Assim, o EIP-7702 oferece um "contenedor de execução" mais nativo para as carteiras avançadas mencionadas: o endereço do usuário permanece o mesmo, permitindo a injeção de diferentes lógicas de contrato, evitando o problema de dependência de endereço no processo tradicional de implantação de contratos, e não é necessário pré-implantar, aumentando significativamente a flexibilidade e a capacidade de combinação das ações da conta.
EIP-7702 vai impulsionar uma profunda transformação no paradigma de desenvolvimento. Os desenvolvedores de contratos não devem mais ver os chamadores como EOAs tradicionais ou contas de contrato fixas, mas devem se adaptar a um novo mecanismo: a identidade do chamador pode mudar dinamicamente entre EOA e estado do contrato durante o processo de transação, e a lógica de comportamento da conta não é mais estática, mas pode ser alterada de forma flexível conforme a necessidade. Isso exige que desenvolvedores e auditores tenham:
Introduzir uma lógica de validação de caller e verificação de permissões mais rigorosa;
Verifique se o caminho de chamada é afetado pela lógica do contrato dinâmico.
Identificar potenciais vulnerabilidades de comportamentos como msg.sender.code.length == 0, isContract ();
Esclarecer a "dependência de contexto" da lógica do contrato, como o controle de limites de chamadas estáticas e deleGatecall;
Suporta simulação e análise de restauração do cenário setCode a nível de cadeia de ferramentas.
Em outras palavras, a segurança do código não é mais apenas uma "questão antes da implementação", mas sim um "processo dinâmico que também deve ser verificado durante as chamadas e transações".
Quatro, Resumo
O EIP-7702 introduz uma implementação mais leve, nativa e flexível do Account Abstraction (AA), que permite que o EOA comum carregue a lógica do contrato e a execute 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 muda para "o que a lógica contratual realizada 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.