Beosin: EIP-7702 e análise de auditoria de segurança da carteira AA de próxima geração

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 é atualmente a solução de implementação AA mais convencional e 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 entrada e melhorar o suporte nativo para abstrações de contas, Vitalik propôs o EIP-7702 em 2024 e o incluiu na atualização do Petra. 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 introduz um novo mecanismo para "injeção de código no nível de 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 de código de contrato pré-implantado. Isso quebra o modelo tradicional de permissão baseado 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 só verificar a segurança do próprio código injetado, mas também avaliar o seu potencial impacto noutros sistemas contratuais num contexto dinâmico.

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

1. Introdução ao EIP-77021

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

introduz um novo tipo de transação, 0x 04 (SetCode), que permite à EOA autorizar o código de contrato que precisa ser executado através desta 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])

Quando 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 transações, a estrutura interna é:

1. authorization_list = [[chain_id, endereço, nonce, y_parity, r, s]].

onde chain_id representa a cadeia na qual a autorização do usuário produz efeitos, 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 || endereço, onde endereço é o endereço do contrato autorizado. Se você quiser desautorizar, basta iniciar uma transação SetCode com o endereço definido como 0.

2º. 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. Este design melhora significativamente a escalabilidade funcional da conta e rompe as limitações das contas externas tradicionais (EOA).

(2) As

Contas SecurityAbstract Reforçadas 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 utilizador perca a sua chave privada, pode recuperar a sua conta através de contactos de confiança ou autenticação multifator, evitando a perda permanente de ativos causada pela perda da chave privada nas contas tradicionais. Ao mesmo tempo, funções como o controlo de limites também podem impedir que grandes quantidades de fundos sejam roubadas maliciosamente.

(3) A Conta de Captação Otimizada

Gás suporta um mecanismo flexível de captação de gás, permitindo que os usuários paguem pelo Gás através de terceiros e até mesmo usem diretamente outros tokens para pagar taxas de transação. Este mecanismo não só 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 de várias etapas.

(4) Promover a popularização da Web3Ao

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

2. Análise de Riscos de Segurança no EIP-7702 Na prática

Embora o EIP-7702 tenha injetado um novo impulso no ecossistema Ethereum e expandido uma riqueza de cenários de aplicativos, ao mesmo tempo, 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 estiver definido como 0, a autorização poderá entrar em vigor em várias cadeias. Embora esse design de "autorização universal entre cadeias" melhore a flexibilidade em alguns cenários, ele também introduz riscos de segurança óbvios.

É importante notar 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 realizam tais 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 detetado definindo o chainId como 0, um aviso de risco claro deve ser dado para lembrar o usuário de que a autorização entrará em vigor em todas as cadeias compatíveis com EVM e pode ser abusada por contratos mal-intencionados.

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 da interface do usuário para reduzir o risco de mau funcionamento ou ataques de phishing.

2. Compatibilidade de contrato

1) Compatibilidade de retorno de chamada de 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 através 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 ser capazes de receber tokens mainstream sem o 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 os tokens principais.

(2) A verificação "tx.origin" falhaNos

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 contratuais.

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

• usuário assina uma transação de autorização e o relayer ou bundler a transmite em nome do usuário. Quando uma transação é executada, "tx.origin" é o endereço de recamaçã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 o julgamento de segurança e usar o mecanismo de verificação de assinatura ou autorização.

(3) "isContract" julga erroneamenteMuitos

contratos impedem as contas contratuais de participar em determinadas operações, tais como airdrops, vendas flash, etc., através de "isContract(address)":

require(!isContract(msg.sender), "Contracts not allowed"

). Sob o mecanismo EIP-7702, o endereço do usuário pode ser alterado para uma conta de contrato através 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 de o usuário usar certos serviços e a experiência ser bloqueada.

Com a popularização gradual das carteiras de contrato, o design de confiar em "isContract" para determinar se "um usuário humano" não é mais seguro, e recomenda-se 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. Uma vez que um usuário autoriza um contrato malicioso, um invasor pode obter controle total sobre os ativos da conta, resultando na transferência rápida ou roubo de fundos, o que é extremamente arriscado.

Por conseguinte, para os prestadores de serviços de carteiras digitais, é necessário apoiar o mecanismo de resolução de transações e identificação de riscos EIP-7702 o mais rapidamente possívelCrucial. 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 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 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.

Em particular, o EIP-7702 introduz um formato de assinatura delegado que não é compatível com as normas 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 da Carteira

( 1) Gestão da Autoridade de Contrato da Carteira

Muitos contratos de carteira EIP-7702 adotam uma arquitetura de proxy (ou permissões de gerenciamento integradas) para suportar atualizações lógicas. No entanto, tal também representa um risco mais elevado de gestão dos 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 em adulteração da conta do usuário ou roubo de fundos.

Recomendações de segurança

• : use mecanismos de multiassinatura, autenticação multifator ou bloqueio de tempo para controlar os 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 utilizadores a conhecer e participar.

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

carteira ou diferentes prestadores de serviços de carteira podem reutilizar o mesmo slot de armazenamento. Se o usuário alterar o provedor de serviços da carteira ou atualizar a lógica da carteira, a reutilização do slot de armazenamento causará o conflito da variável de estado, substituição de dados, exceções de leitura e outros problemas. Isso não só pode perturbar 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 é compatível e evite a sobreposição de variáveis.

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

(3) O gerenciamento de nonce dentro da carteira

O contrato de carteira geralmente configura um nonce dentro e gerencia a si mesmo para garantir a ordem de execução das operações do usuário e evitar ataques de replay. 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 impasses de nonce.

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

fim de garantir a segurança, o contrato da carteira deve garantir que o chamador da função chave é o proprietário da conta da carteira. Os dois métodos comuns incluem:

• a assinatura off-chain autoriza

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

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

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

3. Outlook: 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 de contrato introduzido por ele traz um amplo espaço para exploração para o futuro design de carteira e sistema de contrato, e também apresenta novos requisitos para padrões de auditoria de segurança.

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

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 segundo constrói 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:

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

● 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": usar o EIP-7702 como um substituto leve em cadeias que não suportam EIP-4337 e continuar a depender da pilha de protocolos 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 a nova lógica de carteira, como MPC e ZK, e o

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

● No modelo MPC, o comportamento de assinatura não depende mais de uma única chave privada, mas é uma tomada de decisão colaborativa de várias partes. As assinaturas geradas através da convergência do EIP-7702 e do MPC controlam a lógica do contrato carregado 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 executar automaticamente uma determinada lógica somente depois que certas condições de privacidade forem 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 acima mencionadas: 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 de implantação de contrato tradicional e eliminando a necessidade de pré-implantação, melhorando muito a flexibilidade e a combinação do comportamento da conta.

3. Implicações para os promotores e auditores

conduzirá a uma mudança profunda no paradigma de desenvolvimento. Os desenvolvedores de contratos não mais simplesmente tratam 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 EOA e 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 os desenvolvedores e auditores:

• introduzam uma verificação mais rigorosa do chamador e uma lógica de julgamento de permissão;

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

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

• Clarificar as "dependências de contexto" da lógica contratual, tais como o controlo de limites de chamadas estáticas e chamadas delegadas;

• No nível da cadeia de ferramentas, a simulação e a análise de reversão de cenários setCode são suportadas.

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.

introduz uma implementação mais leve, nativa e flexível de Abstração de Conta (AA), para que o EOA comum possa carregar 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 ao "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.