Introdução

O PEI-7702 permite que carteiras simples do Ethereum (EOAs) sejam atualizadas para carteiras de contrato inteligente, que oferecem segurança aprimorada, funcionalidades avançadas, a oportunidade de patrocínio de gás e outros benefícios. Historicamente, carteiras inteligentes tinham que ser criadas do zero, mas com a introdução do PEI-7702, carteiras tradicionais, com todos os seus ativos e histórico onchain, podem ser atualizadas e manter o mesmo endereço de carteira. É como mudar de um telefone fixo para um smartphone sem precisar de um novo número.

Os EOAs são atualizados definindo uma "designação de delegação", um ponteiro para um contrato inteligente deleGate, cuja lógica então governa o EOA. Os EOAs atualizados podem, portanto, ter funções, definir armazenamento, emitir eventos e fazer tudo o que um contrato inteligente pode fazer. Os EOAs podem alterar ou remover essa delegação a qualquer momento com uma nova autorização EIP-7702 assinada. Embora isso desbloqueie muitas novas possibilidades, esse recurso poderoso também introduz novos desafios de segurança que exigem consideração cuidadosa e soluções inovadoras.

Para permitir que EOAs atuem como carteiras de contratos inteligentes, desenvolvemos o EIP7702Proxy, um leveproxy ERC-1967 contrato projetado para servir como o PEI-7702 deleGate para um EOA. Além da lógica básica de encaminhamento realizada por um proxy, o EIP7702Proxy contém recursos e escolhas de design adicionais que resolvem vários desafios exclusivos das contas delegadas por PEI-7702. Um objetivo ao projetar o EIP7702Proxy era permitir a paridade mais próxima possível entre Carteiras Inteligentes Coinbase "de implantação padrão" e Carteiras Inteligentes Coinbase delegadas por PEI-7702, o que significava abstrair a complexidade adicional exigida pela mecânica do PEI-7702 no proxy dedicado e continuar a depender da implementação original da CoinbaseSmartWallet. A solução para esse desafio pode ser aplicada de forma útil a qualquer lógica de implementação, não apenas à implementação da CoinbaseSmartWallet, enquanto ajuda os EOAs a permanecerem seguros em um ambiente habilitado para 7702.

A seguir, descrevemos os desafios específicos e as soluções de design correspondentes que nos permitem adaptar com segurança qualquer implementação existente de carteira de contrato inteligente para ser usada nas atualizações do PEI-7702.

Desafio #1: Impor uma inicialização segura

O primeiro grande obstáculo na implementação do PEI-7702 decorre de suas restrições de inicialização. As carteiras de contratos inteligentes tradicionais, incluindo a CoinbaseSmartWallet, normalmente tratam da inicialização segura (o estabelecimento da propriedade da conta) de forma atômica durante sua implantação por meio de um contrato de fábrica separado. Essa atomicidade significa que muitas dessas implementações têm funções inicializadoras desprotegidas que podem ser chamadas exatamente uma vez. No entanto, o design do PEI-7702 não permite a execução de calldata de inicialização durante o processo de delegação de código (a etapa comparável à "implantação") e, portanto, isso não pode ser feito de forma atômica.

Essa separação de etapas cria uma janela de vulnerabilidade crítica. Quando um contrato de implementação é "implantado" em um EOA via PEI-7702, não há garantia de que essa atualização 7702 e a transação EVM padrão que inicializa a carteira serão executadas de forma atômica. O código que define a autorização pode tecnicamente ser aplicado independentemente da transação de inicialização, mesmo que sejam submetidos simultaneamente, e isso pode permitir que um atacante execute a transação de inicialização com sua própria carga útil e reivindique a propriedade da conta inteligente.

Solução: Exigir assinatura EOA para definir atomicamente a implementação e inicializar

Observe que as carteiras inteligentes existentes da Coinbase estão implantadas atrás de um proxy ERC-1967 com um UUPSUpgradeable implementação (a lógica real do CoinbaseSmartWallet). O código no endereço da conta real é um proxy, e o proxy utiliza um local de armazenamento convencional definido pelo ERC-1967 para manter um ponteiro para sua lógica de implementação. Nossa solução para a vulnerabilidade de inicialização em um contexto 7702 envolve reconhecer que qualquer lógica de implementação só se torna ativa (e, portanto, perigosa) quando o proxy realmente estabelece uma conexão com ela. Portanto, se não conseguirmos impor a implantação atômica com inicialização, podemos, em vez disso, impor a configuração de implementação atômica com inicialização.

Arquitetura do contrato CoinbaseSmartWallet EIP-7702 e fluxo lógico de delegação

No contexto do PEI-7702, a EOA em si é a autoridade inicial sobre quaisquer alterações em sua conta, e deve fornecer uma assinatura para autorizar a inicialização e estabelecer quaisquer proprietários da nova conta inteligente. Nosso contrato EIP7702Proxy implementa uma função setImplementation que pode definir atomicamente a nova implementação lógica e inicializar a conta. A função setImplementation:

1. Valida uma assinatura do EOA em dados-chave, como o endereço do novo contrato de implementação, dados de inicialização, o endereço de um contrato validador que avaliará a segurança do estado da conta resultante, e proteções básicas contra repetição de assinatura, como um nonce e uma expiração.
2. Define o valor do ponteiro ERC-1967 para a nova implementação e executa os dados de chamada fornecidos contra a nova implementação lógica
3. Faz uma chamada à função validateAccountState que deve ser implementada pelo validador incluído na assinatura.

O validador é um contrato específico de implementação que contém lógica para avaliar se considera o estado da conta resultante como seguro. Por exemplo, no caso da CoinbaseSmartWallet, o CoinbaseSmartWalletValidator verificará se o estado de propriedade da conta não está vazio e, portanto, não é mais suscetível a inicialização arbitrária.

Desafio #2: Armazenamento compartilhado entre os delegados do PEI-7702

Talvez o desafio mais intricado do PEI-7702 esteja relacionado à gestão de armazenamento. O EOA pode livremente re-designar sua lógica para diferentes contratos, ou remover completamente a delegação a qualquer momento. Todos os delegados compartilham o mesmo espaço de armazenamento no endereço EOA. Vários contratos compartilhando acesso ao mesmo armazenamento ao longo do tempo podem levar a um problema de "colisão de armazenamento". Colisões de armazenamento ocorrem quando dois contratos fazem alterações diferentes ou suposições sobre o mesmo local de armazenamento, potencialmente levando a bugs imprevisíveis.

A gestão de colisões de armazenamento já é um problema familiar no espaço de design de proxy, onde uma lógica de implementação mutável é usada para governar o armazenamento compartilhado. Embora proxies atualizáveis possam mudar implementações, o código do proxy em si (para endereços não-7702) não pode ser alterado. Isso traz certeza e garantias ao processo de atualização. A re-delegação 7702 introduz outra camada de total mutabilidade à lógica potencial que pode governar esse armazenamento compartilhado. Isso essencialmente remove quaisquer garantias sobre o efeito que um deleGate arbitrário pode ter no armazenamento. Por exemplo, se um EOA deleGates do deleGate A para B e volta para A novamente, o deleGate retornando não pode fazer suposições sobre o estado de seu armazenamento, que pode ter sido apagado ou manipulado pelo deleGate B em um estado que seria impossível de alcançar apenas pela lógica do deleGate A. Isso é verdade para qualquer deleGate 7702, independentemente do padrão de delegação, pois um deleGate anterior pode ter armazenado ou removido qualquer coisa em qualquer local de armazenamento.

Exemplo de um estado inválido para o DeleGate A induzido pelo padrão de delegação A → B → A

Solução: Externalização de valores de armazenamento críticos para segurança

A delegação de EOA pode afetar arbitrariamente o estado da conta. Se um EOA delegar para um contrato malicioso ou destrutivo, nenhum delegado incumbente pode proteger contra isso. Assim como assinar uma transação de drenagem, autorizar delegados 7702 maliciosos pode ser ruinoso, e proteger contra esses resultados está fora do nosso escopo de design.

Nós projetamos o EIP7702Proxy para ser autodefensivo contra problemas previsíveis em um ecossistema multi-carteira, habilitado para 7702, de atores bem-intencionados, mas potencialmente caóticos. Ele não pode proteger EOAs que autorizam deleGates realmente maliciosos ou com bugs.

Um problema previsível envolve assinaturas para chamadas setImplementation e os riscos introduzidos pelo estado mutável da conta. O EIP7702Proxy depende de assinaturas EOA para definir a lógica de implementação e inicializar para um estado seguro. Essas assinaturas poderiam se tornar passivos se fossem reexecutáveis. Por exemplo, se uma assinatura autorizar um proprietário inicial que mais tarde for comprometido e removido, uma assinatura reexecutável poderia restabelecer o proprietário comprometido ou forçar a rebaixar a implementação.

A proteção comum contra a reprodução de assinaturas usa nonces em mensagens assinadas, marcadas como consumidas quando verificadas. O risco para contas 7702: outros delegados poderiam comprometer esse armazenamento de rastreamento de nonces. Se o armazenamento que rastreia o uso de nonces for apagado, a assinatura setImplementation do EOA (disponível publicamente no mempool) poderia ser reaplicada ao delegar de volta para o EIP7702Proxy.

Para garantir a não-repetibilidade da assinatura, implementamos um singleton NonceTracker separado que mantém o status do nonce em um local de contrato imutável fora do armazenamento da conta. Somente a EOA pode afetar seus nonces (apenas de forma incremental), impedindo que outros deleGates manipulem esses valores críticos de segurança. O NonceTracker garante que cada assinatura setImplementation funcione apenas uma vez, independentemente das alterações no armazenamento da conta.

Desafio #3: Risco aumentado de locais de armazenamento convencional compartilhados

Slots de armazenamento padronizados como os definidos por ERC-1967são particularmente vulneráveis a potenciais colisões de armazenamento devido ao fato de serem locais convencionais que provavelmente serão usados por várias implementações de deleGate. O slot de implementação ERC-1967 é o único local de armazenamento padrão usado no EIP7702Proxy e ele contém o endereço da implementação lógica apontada pelo proxy. Nosso design garante que, independentemente do valor nesse local de armazenamento (que determina grande parte da lógica disponível na conta), o EIP7702Proxy sempre será capaz de definir com sucesso sua lógica de implementação para um contrato desejado pelo EOA.

Para ilustrar mais claramente o problema que está sendo resolvido, note que quando uma conta transita entre diferentes deleGates (A→B→A) onde ambos os deleGates implementam padrões de proxy ERC-1967, o deleGate B naturalmente usará o mesmo slot de armazenamento que o deleGate A estava usando para armazenar seu endereço de implementação. Durante seu mandato, o deleGate B poderia modificar ou sobrescrever este slot, seja intencionalmente ou como parte normal de suas próprias operações de proxy. Em um padrão de proxy UUPSUpgradeable, a lógica para atualizar uma implementação é definida no próprio contrato de implementação. Se a implementação colocada neste local de ponteiro pelo deleGate B não contiver a interface upgradeToAndCall esperada em uma implementação, então, ao retornar ao deleGate A, o próprio mecanismo para alterar sua implementação pode não existir na lógica disponível atual.

Exemplo de sobrescrever local de armazenamento convencional compartilhado por novo deleGate

Solução: Mecanismo de atualização disponível no PEI7702Proxy

Nosso EIP7702Proxy aborda isso por meio de sua função setImplementation, que fornece um mecanismo de atualização independente da implementação diretamente no proxy em si. Isso garante que, mesmo que um deleGate interveniente tenha apontado a implementação ERC-1967 para uma implementação inválida (ou a tenha removido completamente), o EOA original, após delegar de volta para um EIP7702Proxy, mantém a capacidade de reconfigurar o ponteiro ERC-1967 do proxy para sua implementação lógica escolhida.

Desafio #4: Compatibilidade reversa com o comportamento padrão de EOA

Um objetivo de design do EIP7702Proxy era manter a compatibilidade retroativa com a funcionalidade EOA da conta, além da nova funcionalidade de contrato inteligente. A presença ou ausência de código em um endereço pode afetar o fluxo de execução de protocolos que interagem com o endereço, pois eles se baseiam nessa qualidade para diferenciar entre EOAs e contratos inteligentes. Isso exigiu considerar dois comportamentos principais: verificação de assinatura e comportamento de recebimento de token.

Verificação de assinatura

Os contratos inteligentes possuem um padrão diferente para validação de assinatura em comparação com as EOAs padrão. Os contratos inteligentes implementam a interface isValidSignature definida por ERC-1271e estão livres para definir uma lógica arbitrária que determina se o contrato considera uma assinatura válida. Para EOAs padrão, uma assinatura é validada com uma verificação padrão de ecrecover que garante que o signatário recupere o endereço EOA esperado.

Para garantir que as assinaturas EOA existentes ou futuras continuem a ser aceitas no EOA após uma atualização 7702, o EIP7702Proxy implementa uma versão de isValidSignature que primeiro delega a validação de assinatura para a função isValidSignature que deve ser definida na implementação lógica, mas segue uma validação falhada com uma verificação final de ecrecover. Se isso passar, a assinatura é considerada válida. Dessa forma, EOAs que usam o EIP7702Proxy podem garantir que assinaturas simples de EOA sempre serão aceitas em seu endereço, independentemente da implementação de isValidSignature de sua carteira de contrato inteligente.

Recepção de token

Alguns padrões de token (especificamente ERC-1155 e ERC-721) tentativa de proteger contra tokens que ficam presos em contratos inteligentes que podem não ter a capacidade de gerenciá-los. Esses tokens exigem que qualquer contrato inteligente que receba tais tokens declare essa capacidade implementando interfaces padrão de recebimento de tokens que são chamadas pelo contrato do token durante o envio de tokens. Também é essencial que a lógica na EOA atualizada contenha uma função de recebimento padrão ou um fallback pagável para poder receber tokens nativos. Uma conta nunca deve estar em um estado que a deixe incapaz de receber ETH ou outros tokens, por mais breve que seja.

Como nosso proxy não possui uma implementação inicial, incluímos uma implementação imutável DefaultReceiver como a lógica padrão para o EIP7702Proxy na ausência de um ponteiro ERC-1967. Este receptor implementa uma função de recebimento e os ganchos de receptor para esses padrões de token comuns, garantindo que a conta possa aceitar transferências de token antes de definir explicitamente uma nova implementação.

Conclusão

O design do EIP7702Proxy nos permite manter uma paridade próxima com as Carteiras CoinbaseSmartWallets padrão e continuar usando a implementação existente da Carteira CoinbaseSmartWallet enquanto resolvemos os desafios de segurança únicos que surgem no contexto do EIP-7702. Ao considerar cuidadosamente a segurança de inicialização, as implicações da impermanência e interferência de armazenamento, a necessidade de manuseio ininterrupto de tokens e a compatibilidade retroativa com a verificação de assinatura EOA padrão, criamos um proxy para delegar e gerenciar de forma segura carteiras de contratos inteligentes EIP-7702. Embora o EIP7702Proxy tenha sido projetado com a implementação da Carteira CoinbaseSmartWallet V1 em mente, este proxy é, em última análise, agnóstico em relação à implementação. Incentivamos os desenvolvedores a avaliar esta solução para a prova 7702 de outras implementações de carteiras de contratos inteligentes.

Aviso Legal:

1. Este artigo foi reproduzido de [Blog de Engenharia Base]. Todos os direitos autorais pertencem ao autor original [Amie Corso]. Se houver objeções a esta reimpressão, por favor entre em contato com o Gate Learnequipe, e eles vão lidar com isso prontamente.
2. Isenção de Responsabilidade: As opiniões e pontos de vista expressos neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outras línguas são feitas pela equipe do Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.