O que é a delegação EIP-7702? Explicação sobre contas inteligentes EOA

A delegação EIP-7702 permite que uma conta detida externamente (EOA) entregue a sua lógica de execução a outro contrato sem alterar o endereço nem abdicar da chave privada. O campo de código é definido como 0xef0100 mais o endereço do delegado, e as chamadas posteriores executam esse código no contexto da própria EOA, continuando o saldo, o nonce e o armazenamento a pertencer à conta.

Destina-se a leitores que já conhecem carteiras de autocustódia e o modelo de contas da EVM. O Ethereum tem há muito tempo dois tipos de contas: EOA controladas por chave e contas de contrato com código, sendo que apenas as segundas podiam ter lógica de validação personalizada, à custa de um novo endereço. Foi introduzido com a atualização Pectra e transferiu a validação personalizada da abertura de uma nova conta para a escrita de código num endereço já em utilização.

Uma tupla de autorização contém seis campos, e o designador de delegação ocupa 23 bytes: um prefixo de três bytes mais um endereço de 20 bytes. O processo de escrita, os limites das novas capacidades, a divisão com o ERC-4337 e a fiabilidade do delegado determinam quanto controlo a conta mantém após essa assinatura.

Principais conclusões

• A delegação EIP-7702 mantém o endereço, a chave privada, o saldo e o nonce inalterados e direciona apenas o campo de código para um contrato delegado.

• Uma transação do tipo 0x04 escreve a delegação através de uma tupla de autorização; a mensagem assinada não contém campos de taxas, e o remetente não tem de ser o proprietário.

• Uma delegação não tem caducidade; a revogação elimina o código, mas não o armazenamento, as aprovações de tokens nem as assinaturas Permit.

• Um delegado sem receive() nem fallback() faz reverter transferências simples de ETH, e tx.origin deixa de implicar que uma conta não tem código.

• O ERC-4337 cria um sistema de contas separado, enquanto o EIP-7702 adiciona código a EOA existentes, pelo que ambos podem ser combinados.

O que muda a delegação EIP-7702 numa conta detida externamente?

O Ethereum tem dois tipos de contas: uma conta detida externamente, controlada por uma chave privada, e uma conta de contrato, que contém código.

Com o EIP-7702, o que muda é o campo de código, e não a identidade da conta, pois uma EOA pode apontar temporariamente para código de contrato sem alterar o seu endereço. O endereço, a chave privada, o saldo e o nonce mantêm-se onde estavam; a diferença é que o endereço passa a ter código executável obtido de outro contrato implementado.

O campo contém um designador de delegação de 23 bytes: o prefixo 0xef0100 mais um endereço de 20 bytes. Quando uma chamada visa essa EOA, a EVM lê o designador e carrega o código do delegado, pelo que a conta pode comportar-se como contas inteligentes, enquanto a chave privada permanece sob controlo e o remetente, o saldo e o armazenamento são todos lidos como sendo da EOA.

O delegado não consegue ver o seu próprio estado; a sua lógica de execução é carregada a partir do contrato de destino, enquanto o armazenamento e o contexto do remetente permanecem os da EOA, e as escritas seguem a mesma lógica para o armazenamento que a EOA nunca utilizou.

As assinaturas continuam a provir da chave privada original, pelo que a conta não se torna uma multisig, e o design constitui um passo rumo à abstração de contas, incluindo a variante nativa, e não uma alteração do tipo de conta.

Tipo 0x04 e tuplas de autorização: como a delegação chega ao código do contrato

A escrita requer um novo tipo de transação, 0x04, cujo corpo contém uma lista de autorizações; cada tupla é assinada pelo titular da conta, enquanto a própria transação pode ser enviada e paga por qualquer endereço, e a autorização especifica qual o código que a conta permite executar.

A tupla é [chain_id, address, nonce, y_parity, r, s], e a mensagem assinada é keccak(0x05 || rlp([chain_id, address, nonce])); a especificação EIP-7702 utiliza o prefixo 0x05 para separar as assinaturas de autorização das assinaturas de transações normais, e a mensagem não contém campos de gás nem de taxas.

O que é assinado é o endereço para o qual o código deve apontar, e não uma transação específica, pelo que alguns sistemas associam a autorização a uma intenção. A conta também pode assinar uma vez offline enquanto um patrocinador adianta o gás.

A validação pelo nó decorre em seis passos, sendo que a associação ao nonce torna uma autorização utilizável uma vez, no nonce correspondente.

A lista de autorizações é incluída no corpo da transação, tal como uma lista de acesso alarga o formato de transação: o ID da cadeia é 0 ou corresponde à cadeia local (0 significa válido em qualquer cadeia); o nonce é inferior a 2^64-1; ecrecover verifica a assinatura; o código da conta está vazio ou já foi delegado; o nonce corresponde ao valor atual; e o código é escrito como 0xef0100 || address, com o nonce incrementado.

A revogação segue o mesmo processo com o endereço definido como zero, o que elimina o hash do código sem uma alteração permanente de estado na EOA subjacente.

Que propriedades da conta permanecem inalteradas?

Quatro propriedades mantêm-se como estavam, e apenas o código e o armazenamento mudam: o código passa de 0x para o designador, os espaços de armazenamento não utilizados começam a receber escritas e esses valores sobrevivem à revogação. A especificação também enumera três invariantes on-chain que deixam de se verificar, abrangendo saldo, nonce e identidade do chamador; a secção de riscos aborda-os.

1. Endereço: inalterado, pelo que o histórico, as aprovações de tokens e os registos de nomes continuam a apontar para o mesmo endereço.

2. Chave privada: inalterada, e assina transações normais, bem como uma nova autorização que substitui ou revoga a delegação.

3. Saldo: inalterado, pois a delegação não move ativos e a conta continua a detê-los diretamente.

4. Nonce: continua a aumentar, pois a autorização consome um, o que impede a repetição da mesma assinatura.

Uma conta delegada pode continuar a receber ETH normalmente?

Não por predefinição. Quando a conta passa a ter código, uma transferência simples de ETH entra no percurso de execução do código; se o delegado não implementar receive() nem fallback(), a transferência reverte e os fundos regressam ao remetente.

Este problema pode ocorrer em fluxos de pagamento comuns, como levantamentos de exchanges, processamento de salários e airdrops. Normalmente, o software da carteira indica apenas uma falha, sem indicar que a causa é o delegado. Antes de assinar, confirmar que o destino implementa uma função receive ou encaminhar pagamentos recebidos através de uma chamada que transporte calldata; o software da carteira deve também indicar essa causa de forma mais clara aos utilizadores.

Figura 1. O processo de escrita EIP-7702: a EOA assina a tupla de autorização, uma transação do tipo 0x04 define o código como 0xef0100 mais o endereço do delegado e as chamadas posteriores executam esse código no contexto da EOA.

O que pode fazer uma conta delegada? Agrupamento, patrocínio de gás e recuperação

A delegação transforma uma EOA, que só pode assinar transações, numa conta que se comporta como uma conta inteligente para utilizadores comuns, com as vantagens mais claras no agrupamento, no patrocínio de gás e na recuperação baseada em regras.

O agrupamento é a vantagem mais concreta: aprovar e trocar podem ocorrer numa única transação; um patrocinador também pode simplificar a integração ou o agrupamento ao ajudar a concluir vários passos nos bastidores no momento adequado, pelo que uma única assinatura liquida uma vez e não fica nenhuma aprovação por utilizar pelo meio.

O patrocínio de gás resulta da separação entre a assinatura e o remetente: um terceiro paga, a conta não precisa de ETH antecipadamente e, com um paymaster ERC-4337, o custo pode ficar a cargo da aplicação. Isto também significa que algumas aplicações podem cobrir o gás ou simplificar a integração ao tratá-lo em segundo plano, mas os programadores devem evitar solicitar delegação quando um utilizador está apenas a pedir outra funcionalidade.

A recuperação e as chaves de sessão assentam no delegado a verificar as assinaturas, por exemplo com uma passkey, um conjunto de tutores ou limites de despesa em vez de uma chave. O delegado também pode aplicar funções semelhantes a políticas em torno de transferências ou da utilização de signatários.

O limite é direto: quem detém a chave privada pode sempre assinar uma nova autorização que substitui a delegação, pelo que a recuperação é aqui mais fraca do que numa conta inteligente nativa e apenas reduz o custo de uma chave perdida.

Uma delegação não tem caducidade. Mantém-se ativa até que uma nova autorização a substitua ou que um endereço zero a revogue, pelo que a permissão é duradoura e requer gestão ativa; do ponto de vista da segurança, analisar o âmbito do que o código delegado pode aceder e controlar.

Em que difere a delegação EIP-7702 do ERC-4337 e da abstração de contas?

O EIP-7702 adiciona código a uma EOA existente, enquanto o ERC-4337 cria um sistema de contas separado; como abordagens complementares à abstração de contas, ambos podem ser combinados em vez de se substituírem.

O ERC-4337 parte de um contrato recém-implementado, pelo que os ativos e as aprovações são transferidos; o 7702 parte do endereço original e adiciona código, evitando a migração ao permitir que as contas existentes utilizem o comportamento de contratos inteligentes sem implementar primeiro uma carteira separada.

Em conjunto, permitem que uma conta 7702 funcione como implementação de conta para ERC-4337, e os programadores podem criar fluxos compatíveis com 4337 sobre uma conta delegada 7702. Isto reintroduz uma corrida de inicialização: entre a confirmação da delegação e a conclusão da inicialização, qualquer pessoa pode chamar o inicializador e definir-se como proprietário.

Existem duas soluções — initWithSig, que associa a assinatura aos argumentos de inicialização, ou restringir a inicialização ao EntryPoint.

O delegado é fiável? Como verificar se é imutável

Delegar apenas a contratos imutáveis implementados a partir de initcode CREATE2 padrão; o mecanismo de verificação deve favorecer destinos sem via de atualização, pois contratos proxy, contratos atualizáveis e contratos com um percurso de autodestruição são todos destinos inadequados.

A delegação concede direitos de execução a esse código, e o titular não recebe qualquer notificação de alteração. Um destino atualizável significa que quem pode atualizá-lo detém poder de execução sobre todas as contas que lhe delegam; um destino imutável pelo menos fixa antecipadamente a superfície de ataque, onde pode ser auditada. A exposição de segurança aumenta se o código delegado puder mudar após a autorização.

Três critérios — código imutável, sem proxy e implementação reproduzível — tornam-se quatro verificações num explorador de blocos que carteiras e programadores devem realizar antes de conceder delegação:

1. Ler os espaços de implementação e de administrador: um espaço EIP-1967 diferente de zero que comece por 0x360894 indica um proxy ou um percurso de atualização.

2. Comparar o bytecode on-chain com o código-fonte verificado, confirmando que os argumentos do construtor e o bytecode implementado correspondem.

3. Procurar selfdestruct e delegatecall, confirmando que nenhuma ramificação pode eliminar o código ou encaminhar a execução para outro local.

4. Recalcular o endereço CREATE2 a partir do initcode e do salt, confirmando que o implementador não pode substituir outro contrato num endereço diferente.

Quais são os riscos da delegação EIP-7702?

O risco encontra-se em três áreas: erros no delegado, semântica de conta que a delegação altera e a irreversibilidade de uma assinatura única — uma contrapartida de segurança tanto quanto uma atualização funcional, sendo a principal preocupação o amplo âmbito do código que pode controlar a conta após a concessão da autorização.

A linha tx.origin tem o maior raio de impacto. Uma conta delegada pode executar código dentro da pilha de chamadas, pelo que msg.sender == tx.origin deixa de significar que o chamador não tem código, e as proteções baseadas nessa comparação deixam de proteger; bloqueios nonReentrant ou de armazenamento transitório não dependem da identidade do chamador.

Na prática, se as carteiras não apresentarem claramente os detalhes da autorização, os utilizadores podem aprovar acessos que não pretendiam analisar. As orientações EIP-7702 na documentação Pectra enumeram esta situação separadamente.

Um chain_id de 0 alarga a terceira categoria: a mesma assinatura é válida noutras cadeias EVM, pelo que uma conta pode receber código numa cadeia que o seu titular nunca considerou. Os dispositivos de assinatura muitas vezes omitem o ID da cadeia, e é aí que se encontra a contrapartida associada a ativar a delegação numa carteira fria.

Como verificar e revogar uma delegação?

A verificação requer uma leitura de código: eth_getCode a devolver 0x significa que não existe delegação, 23 bytes iniciados por 0xef0100 significam que a conta é uma conta detida externamente delegada, e qualquer outro bytecode significa que é uma conta de contrato.

A delegação é um estado ao nível da cadeia, pelo que um endereço pode estar delegado numa cadeia e inalterado noutra, e cada cadeia requer a sua própria verificação; os últimos 20 bytes correspondem ao delegado, e uma carteira ou plataforma pode automatizar estas verificações entre cadeias, mantendo registos de verificações de estado ou alterações para auditoria e monitorização.

Para uma análise manual rápida, verificar e revogar uma delegação explica o procedimento.

A revogação ocorre dentro da carteira: assinar uma nova autorização com o campo de endereço definido como zero e o nó elimina o hash do código, devolvendo a conta a uma EOA simples, enquanto as dApps externas geralmente não podem fazê-lo pelo titular; se as equipas das carteiras suportarem fluxos de revogação, quaisquer pedidos para atuar em nome de um titular devem ainda exigir a aprovação do próprio titular.

A revogação remove o código delegado, mas não remove aprovações anteriores de contratos inteligentes nem outros acessos já concedidos a aplicações, e as notas de delegação de EOA da OpenZeppelin estabelecem esse limite.

Resumo

O EIP-7702 dá programabilidade a uma EOA com uma assinatura: o endereço e a chave mantêm-se, o campo de código aponta para um delegado e a execução decorre no próprio contexto da conta.

O preço é a alteração da semântica e uma permissão duradoura: os pagamentos recebidos simples podem falhar, tx.origin deixa de ser uma EOA, uma assinatura com chain_id de 0 funciona entre cadeias e a revogação elimina apenas o código.

Perguntas frequentes

O EIP-7702 transforma a minha carteira numa multisig?

Não. A delegação altera apenas o campo de código, e as assinaturas continuam a provir da chave privada original, pelo que um titular de chave única pode realizar transações de forma independente e pode substituir a delegação com uma nova autorização. Um delegado que exija múltiplas assinaturas também pode ser contornado por essa chave.

Como posso verificar se a minha carteira está delegada ao abrigo do EIP-7702?

Chamar eth_getCode no endereço. Um retorno de 0x significa que não existe delegação; 23 bytes iniciados por 0xef0100 significam que está delegada, com os últimos 20 bytes a identificar o delegado; outro bytecode significa uma conta de contrato.

A delegação é registada por cadeia, pelo que é necessário verificar cada uma, e as carteiras ou os sistemas de administração podem manter registos dessas verificações para análise. Em suma, a resposta pode variar apenas nos detalhes da interface entre carteiras, mas a verificação de código subjacente é a mesma.

Como revogar uma delegação EIP-7702?

Assinar uma nova autorização com o campo de endereço definido como zero dentro da carteira, e o nó elimina o hash do código quando a validação é concluída. Apenas o titular da conta pode assiná-la, e as dApps externas geralmente não podem atuar em seu nome.

Uma delegação caduca e as aprovações anteriores de tokens sobrevivem à revogação?

Uma delegação não tem caducidade e mantém-se ativa até ser substituída ou revogada. A revogação elimina apenas o código, deixando o armazenamento, as aprovações ERC-20 e as assinaturas Permit inalterados.

A minha chave nunca foi exposta — uma autorização EIP-7702 maliciosa ainda pode drenar a conta?

Sim. A assinatura é uma transferência de autoridade: com ela, um atacante pode escrever uma delegação que aponta para um contrato malicioso e obter amplo acesso à conta, movendo ativos sem nunca tocar na chave privada.

Verificar o ID da cadeia e o endereço de destino na tupla e assinar apenas para contratos imutáveis; as equipas das carteiras devem também verificar a função do signatário antes de conceder aprovações internas relacionadas com delegação em nome de uma organização.