Introdução

EIP-7702 permite que carteiras Ethereum simples (EOAs) sejam atualizadas para carteiras de contrato inteligente, que oferecem segurança melhorada, funcionalidade avançada, a oportunidade de patrocínio de gás e outros benefícios. Historicamente, as carteiras inteligentes precisavam ser criadas do zero, mas com a introdução do EIP-7702, carteiras tradicionais, com todos os seus ativos e histórico on-chain, podem atualizar e manter o mesmo endereço de carteira. É como trocar de um telefone fixo para um smartphone sem precisar de um novo número.

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

Para permitir que os EOAs atuem como carteiras de contratos inteligentes, desenvolvemos o EIP7702Proxy, um leveproxy ERC-1967 contrato projetado para servir como o deleGate EIP-7702 para um EOA. Além da lógica básica de encaminhamento realizada por um proxy, o EIP7702Proxy contém recursos adicionais e escolhas de design que resolvem vários desafios únicos para contas delegadas EIP-7702. Um objetivo no design do EIP7702Proxy foi permitir a paridade mais próxima possível entre as Carteiras Inteligentes Coinbase "standard-deploy" e as Carteiras Inteligentes Coinbase delegadas EIP-7702, o que significava abstrair a complexidade adicional exigida pela mecânica do EIP-7702 no proxy dedicado e continuar a confiar na 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.

Descrevemos abaixo os desafios específicos e as soluções de design correspondentes que nos permitem adaptar de forma segura qualquer implementação existente de carteira de contrato inteligente para ser usada nas atualizações EIP-7702.

Desafio #1: Aplicar uma inicialização segura

O primeiro grande obstáculo na implementação do EIP-7702 decorre das suas restrições de inicialização. As carteiras de contratos inteligentes tradicionais, incluindo a CoinbaseSmartWallet, normalmente lidam com a inicialização segura (o estabelecimento da propriedade da conta) de forma atómica durante a sua implementação através de um contrato de fábrica separado. Esta 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 EIP-7702 não permite a execução de calldata de inicialização durante o processo de delegação de código (o passo comparável à “implementação”) e, portanto, isso não pode ser feito de forma atómica.

Esta separação de etapas cria uma janela de vulnerabilidade crítica. Quando um contrato de implementação é "desdobrado" para um EOA via EIP-7702, não há garantia de que esta 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 poderia tecnicamente ser aplicado independentemente da transação de inicialização, mesmo que sejam submetidos simultaneamente, e isso poderia permitir que um atacante precedesse a transação de inicialização com sua própria carga útil e reivindicasse a propriedade da conta inteligente.

Solução: Exigir assinatura EOA para definir atómica e inicializar a implementação

Note que as carteiras inteligentes Coinbase existentes estão implementadas 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 usa uma localização de armazenamento convencional definida pela 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 a inicialização, podemos, em vez disso, impor a configuração atômica da implementação com a inicialização.

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

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

1. Valida uma assinatura da EOA em dados chave, como o endereço do novo contrato de implementação, calldata 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 partilhado entre os deleGates do EIP-7702

Talvez o desafio mais intrincado do EIP-7702 esteja relacionado à gestão de armazenamento. O EOA pode livremente re-delegar 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 mudanças ou suposições diferentes sobre o mesmo local de armazenamento, potencialmente levando a erros imprevisíveis.

A gestão de colisões de armazenamento já é um problema familiar no espaço de design de proxies, onde a lógica de implementação mutável é utilizada para governar o armazenamento compartilhado. Mesmo que proxies atualizáveis possam mudar de implementações, o código do proxy em si (para endereços não-7702) não pode mudar. 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 este armazenamento compartilhado. Isso essencialmente remove quaisquer garantias sobre o efeito que um deleGate arbitrário pode ter no armazenamento. Por exemplo, se um EOA delega do deleGate A para B e volta para A novamente, o deleGate retornado não pode fazer suposições sobre o estado do seu armazenamento, que pode ter sido apagado ou manipulado pelo deleGate B para um estado que teria sido impossível de alcançar apenas através da lógica do deleGate A. Isso é verdade para qualquer deleGate 7702, independentemente do padrão de delegação, uma vez que 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 a 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 delegador incumbente pode proteger contra isso. Assim como assinar uma transação de drenagem, autorizar delegados maliciosos 7702 pode ser desastroso, e proteger contra esses resultados está fora do nosso escopo de design.

Projetámos o EIP7702Proxy para ser auto-defensivo contra problemas previsíveis num ecossistema multi-carteira, habilitado para 7702, de atores bem-intencionados mas potencialmente caóticos. Não pode proteger EOAs que autorizem deleGates verdadeiramente maliciosos ou com bugs.

Um problema previsível envolve as assinaturas para chamadas setImplementation e os riscos introduzidos pelo estado de conta mutável. 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 responsabilidades se algum dia fossem reproduzíveis. Por exemplo, se uma assinatura autoriza um proprietário inicial que mais tarde é comprometido e removido, uma assinatura reproduzível poderia restabelecer o proprietário comprometido ou forçar uma degradação da implementação.

A proteção comum contra a repetição de assinaturas utiliza nonces em mensagens assinadas, marcadas como consumidas quando verificadas. O risco para contas 7702: outros deleGates poderiam comprometer este 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 replays da assinatura, implementámos um singleton NonceTracker separado que mantém o estado do nonce em uma localização de contrato imutável fora do armazenamento da conta. Apenas o EOA pode afetar os seus nonces (apenas de forma incremental), impedindo que outros deleGates manipulem esses valores críticos de segurança. O NonceTracker assegura que cada assinatura setImplementation funcione apenas uma vez, independentemente das alterações no armazenamento da conta.

Desafio #3: Risco aumentado de locais de armazenamento convencionais 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 contém o endereço da implementação lógica apontada pelo proxy. Nosso design garante que, independentemente do valor neste 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á a ser 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 usará naturalmente o mesmo slot de armazenamento que o deleGate A estava a usar para armazenar o seu endereço de implementação. Durante o seu mandato, o deleGate B pode modificar ou sobrescrever este slot, seja intencionalmente ou como parte normal das suas próprias operações de proxy. Numa estrutura 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 numa implementação, então, ao retornar ao deleGate A, o próprio mecanismo para alterar a sua implementação pode não existir na lógica disponível atualmente.

Exemplo de sobreposição de local de armazenamento convencional partilhado por novo deleGate

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

O nosso EIP7702Proxy aborda isso através da sua função setImplementation, que fornece um mecanismo de atualização independente da implementação diretamente no próprio proxy. 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 a sua implementação lógica escolhida.

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

Um objetivo de design do EIP7702Proxy foi 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 dos protocolos que interagem com o endereço, uma vez que 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 tokens.

Verificação de assinatura

Os contratos inteligentes têm um padrão diferente para a validação de assinaturas do que as EOAs padrão. Os contratos inteligentes implementam a interface isValidSignature definida porERC-1271 e são livres para definir 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 ecrecover padrão que garante que o assinante recupere o endereço EOA esperado.

Para garantir que as assinaturas EOA existentes ou futuras continuem a ser aceites no EOA após uma atualização 7702, o EIP7702Proxy implementa uma versão de isValidSignature que primeiro delega a validação da 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 isto passar, a assinatura é considerada válida. Desta forma, os EOAs que utilizam o EIP7702Proxy podem garantir que as assinaturas EOA simples serão sempre aceites no seu endereço, independentemente da implementação de isValidSignature da 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 possam ficar presos em contratos inteligentes que podem não ter capacidade para gerenciá-los. Esses tokens exigem que qualquer contrato inteligente que receba tais tokens declare essa capacidade implementando interfaces padrão de receptor de token que são chamadas pelo contrato de 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 impeça de receber ETH ou outros tokens, mesmo que brevemente.

Uma vez que o nosso proxy não possui uma implementação inicial, incluímos uma implementação DefaultReceiver imutável 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 estes padrões de token comuns, garantindo que a conta possa aceitar transferências de tokens antes de definir explicitamente uma nova implementação.

Conclusão

O design do EIP7702Proxy permite-nos manter uma paridade próxima com as Carteiras CoinbaseSmartWallets de implementação padrão e continuar a utilizar a implementação existente da CoinbaseSmartWallet enquanto resolvemos os desafios de segurança únicos que surgem no contexto do EIP-7702. Considerando cuidadosamente a segurança da inicialização, as implicações da impermanência de armazenamento e interferência, a necessidade de manuseio ininterrupto de tokens e a compatibilidade retroativa com a verificação de assinatura EOA padrão, criámos um proxy para delegar e gerenciar de forma segura as carteiras de contratos inteligentes EIP-7702. Embora o EIP7702Proxy tenha sido projetado com a implementação da 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 proteção 7702 de outras implementações de carteiras de contratos inteligentes.

Aviso:

1. Este artigo é republicado 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 contacte o Gate Learn equipe, e eles lidarão 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 aconselhamento de investimento.
3. As traduções do artigo para outras línguas são feitas pela equipa Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.