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

A delegação EIP-7702 permite que uma conta controlada externamente (EOA) transfira sua lógica de execução para outro contrato sem alterar o endereço nem abrir mão 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 próprio contexto da EOA, com saldo, nonce e armazenamento continuando a pertencer à conta.

Ela é adequada para leitores que já conhecem carteiras de autocustódia e o modelo de contas da EVM. O Ethereum há muito tempo possui dois tipos de conta: EOAs controladas por chave e contas de contrato com código, e apenas o segundo tipo podia conter lógica de validação personalizada, ao custo de um novo endereço. A funcionalidade foi lançada com a atualização Pectra e transferiu a validação personalizada da abertura de uma nova conta para a gravação de código em um endereço já utilizado.

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 caminho de gravação, os limites das novas capacidades, a separação em relação ao ERC-4337 e a confiabilidade do delegado determinam quanto controle a conta mantém após essa assinatura.

Principais pontos

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

• Uma transação do tipo 0x04 grava a delegação por meio de uma tupla de autorização; a mensagem assinada não contém campos de taxa, e o remetente não precisa ser o proprietário.

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

• Um delegado sem receive() ou fallback() faz com que transferências simples de ETH sejam revertidas, e tx.origin deixa de indicar que uma conta não tem código.

• O ERC-4337 cria um sistema de contas separado, enquanto a EIP-7702 adiciona código a EOAs existentes. Portanto, as duas abordagens podem ser combinadas.

O que a delegação EIP-7702 altera em uma conta controlada externamente?

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

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

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 é direcionada a essa EOA, a EVM lê o designador e carrega o código do delegado. Assim, a conta pode se comportar como uma conta inteligente enquanto a chave privada permanece no controle, e remetente, saldo e armazenamento são todos lidos como pertencentes à EOA.

O delegado não pode acessar seu próprio estado; sua lógica de execução é carregada do contrato-alvo, enquanto o armazenamento e o contexto do remetente permanecem os da EOA, e as gravações seguem a mesma lógica para o armazenamento que a EOA nunca utilizou.

As assinaturas continuam vindo da chave privada original, portanto, a conta não se torna uma multisig, e o design representa um passo em direção à abstração de contas, incluindo a variante nativa, em vez de uma mudança de tipo de conta.

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

A gravação exige 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 código 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 usa o prefixo 0x05 para separar assinaturas de autorização de assinaturas de transações comuns, e a mensagem não contém campos de gas nem de taxa.

O que é assinado é o endereço para o qual o código deve apontar, e não uma transação específica. Por isso, alguns sistemas vinculam a autorização a uma intenção. A conta também pode assinar uma vez off-line enquanto um patrocinador adianta o gas.

A validação do nó ocorre em seis etapas, e o vínculo com o nonce torna uma autorização utilizável uma única vez, no nonce correspondente.

A lista de autorizações é incluída no corpo da transação da mesma forma que uma lista de acesso estende o formato da transação: o ID da cadeia é 0 ou corresponde à cadeia local, sendo que 0 significa válido em qualquer cadeia; o nonce é menor que 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 é gravado como 0xef0100 || address com o incremento do nonce.

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

Quais propriedades da conta permanecem inalteradas?

Quatro propriedades permanecem como estavam, e apenas o código e o armazenamento mudam: o código passa de 0x para o designador, slots de armazenamento não utilizados começam a receber gravações, e esses valores sobrevivem à revogação. A especificação lista separadamente três invariantes on-chain que deixam de se manter, abrangendo saldo, nonce e identidade do chamador; a seção de riscos os aborda.

1. Endereço: inalterado, portanto, o histórico, as aprovações de tokens e os registros de nomes continuam apontando para um único endereço.

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

3. Saldo: inalterado, porque a delegação não movimenta ativos e a conta continua a mantê-los diretamente.

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

Uma conta delegada ainda pode receber ETH normalmente?

Não por padrão. Quando a conta passa a conter código, uma transferência simples de ETH entra no caminho de execução do código; se o delegado não implementar receive() nem fallback(), a transferência é revertida e os fundos retornam ao remetente.

Esse problema pode ocorrer em fluxos de pagamento comuns, como saques em exchanges, folha de pagamento e airdrops. O software da carteira geralmente informa apenas uma falha, sem indicar que o delegado é a causa. Antes de assinar, confirme que o alvo implementa uma função receive ou direcione pagamentos recebidos por meio de uma chamada que inclua calldata. O software da carteira também deve apresentar essa causa de forma mais clara aos usuários.

Figura 1. O caminho de gravação da 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 chamadas posteriores executam esse código no contexto da EOA.

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

A delegação transforma uma EOA, de uma conta que só pode assinar transações, em uma conta que se comporta como uma conta inteligente para usuários cotidianos, com ganhos mais claros em agrupamento, patrocínio de gas e recuperação baseada em regras.

O agrupamento é o ganho mais concreto: aprovar e fazer swap podem ocorrer em uma única transação. Um patrocinador também pode facilitar a integração ou o agrupamento ao ajudar a concluir várias etapas em segundo plano no momento adequado, de modo que uma única assinatura conclua tudo de uma vez e nenhuma aprovação fique sem uso no intervalo.

O patrocínio de gas decorre da separação entre a assinatura e o remetente: um terceiro paga, a conta não precisa ter ETH antecipadamente e, com um paymaster ERC-4337, o custo pode ficar a cargo da aplicação. Isso também significa que alguns aplicativos podem cobrir o gas ou facilitar a integração ao processá-lo em segundo plano, mas os desenvolvedores devem evitar solicitar uma delegação quando o usuário está simplesmente pedindo outro recurso.

A recuperação e as chaves de sessão dependem de o delegado verificar as assinaturas por conta própria, por exemplo, com uma passkey, um conjunto de guardiões ou limites de gasto no lugar de uma chave. O delegado também pode impor funções semelhantes a políticas relacionadas a transferências ou ao uso de signatários.

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

Uma delegação não expira. Ela permanece ativa até que uma nova autorização a substitua ou que um endereço zero a revogue. Portanto, a permissão é duradoura e exige gerenciamento ativo; do ponto de vista de segurança, analise o escopo do que o código delegado pode acessar e controlar.

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

A 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, as duas podem ser combinadas, em vez de substituir uma à outra.

O ERC-4337 parte de um contrato recém-implantado, portanto, ativos e aprovações precisam ser movidos; a 7702 parte do endereço original e adiciona código, evitando a migração ao permitir que contas existentes usem o comportamento de contratos inteligentes sem antes implantar uma carteira separada.

Juntas, elas permitem que uma conta 7702 funcione como implementação de conta para o ERC-4337, e os desenvolvedores podem criar fluxos compatíveis com 4337 sobre uma conta delegada por 7702. Isso 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 a si mesma como proprietária.

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

O delegado é confiável? Como verificar se ele é imutável

Delegue apenas para contratos imutáveis implantados a partir de initcode CREATE2 padrão; o mecanismo de verificação deve priorizar alvos sem caminho de atualização, pois contratos proxy, contratos atualizáveis e contratos com caminho de self-destruct são alvos inadequados.

A delegação concede direitos de execução a esse código, e o titular não recebe notificação de alterações. Um alvo atualizável significa que quem realiza a atualização detém poder de execução sobre todas as contas que delegam a ele; um alvo imutável ao menos fixa previamente a superfície de ataque, que 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, ausência de proxy e implantação reproduzível, tornam-se quatro verificações em um explorador de blocos que carteiras e desenvolvedores devem realizar antes de conceder uma delegação:

1. Leia os slots de implementação e de administrador: um slot EIP-1967 diferente de zero que comece com 0x360894 indica um proxy ou caminho de atualização.

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

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

4. Recalcule o endereço CREATE2 a partir de initcode e salt, confirmando que o implantador não pode substituir o contrato por outro em um endereço diferente.

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

O risco está em três pontos: bugs no delegado, semânticas da conta que a delegação altera e a irreversibilidade de uma assinatura única. Trata-se tanto de uma contrapartida de segurança quanto de uma atualização de funcionalidade, sendo a principal preocupação o amplo escopo do código que pode controlar a conta após a concessão da autorização.

A linha sobre tx.origin possui o maior raio de impacto. Uma conta delegada pode executar código dentro da pilha de chamadas, portanto, msg.sender == tx.origin deixa de significar que o chamador não possui código, e as proteções construídas com base 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 exibirem claramente os detalhes da autorização, os usuários poderão aprovar acessos que não pretendiam analisar. As orientações da EIP-7702 na documentação da Pectra listam isso separadamente.

Um chain_id igual a 0 amplia a terceira categoria: a mesma assinatura é válida em outras cadeias EVM, portanto, uma conta pode receber código em uma cadeia que seu titular nunca considerou. Dispositivos de assinatura frequentemente omitem o ID da cadeia, e é nesse ponto que está a contrapartida de habilitar a delegação em uma carteira fria.

Como verificar e revogar uma delegação?

A verificação exige uma única leitura de código: eth_getCode retornando 0x significa que não há delegação; 23 bytes começando com 0xef0100 significam que a conta é uma conta controlada externamente delegada; e qualquer outro bytecode significa que ela é uma conta de contrato.

A delegação é um estado no nível da cadeia. Portanto, um endereço pode estar delegado em uma cadeia e permanecer inalterado em outra, e cada cadeia exige sua própria verificação; os últimos 20 bytes correspondem ao delegado, e uma carteira ou plataforma pode automatizar essas verificações entre cadeias, mantendo registros das verificações ou alterações de status para auditoria e monitoramento.

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

A revogação ocorre dentro da carteira: assine uma nova autorização com o campo de endereço definido como zero, e o nó limpa o hash do código, retornando a conta a uma EOA simples. Em geral, dApps externos não podem fazer isso pelo titular e, se as equipes de carteira oferecerem fluxos de revogação, quaisquer solicitações para agir em nome de um titular ainda devem 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 aplicativos, e as notas sobre delegação de EOA da OpenZeppelin estabelecem esse limite.

Resumo

A EIP-7702 concede programabilidade a uma EOA com uma assinatura: o endereço e a chave permanecem no lugar, o campo de código aponta para um delegado e a execução ocorre no próprio contexto da conta.

O custo são semânticas alteradas e uma permissão duradoura: pagamentos recebidos simples podem falhar, tx.origin deixa de ser uma EOA, uma assinatura com chain_id igual a 0 pode ser usada em várias cadeias e a revogação limpa apenas o código.

Perguntas frequentes

A EIP-7702 transforma minha carteira em uma multisig?

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

Como verificar se minha carteira está delegada pela EIP-7702?

Chame eth_getCode no endereço. Um retorno de 0x significa que não há delegação; 23 bytes começando com 0xef0100 significam que ela está delegada, com os últimos 20 bytes identificando o delegado; outro bytecode significa uma conta de contrato.

A delegação é registrada por cadeia, portanto, verifique cada uma delas, e carteiras ou sistemas administrativos podem manter registros dessas verificações para análise. Em resumo, a resposta pode variar apenas nos detalhes da interface entre carteiras, mas a verificação de código subjacente é a mesma.

Como revogo uma delegação EIP-7702?

Assine uma nova autorização com o campo de endereço definido como zero dentro da carteira, e o nó limpa o hash do código quando a validação for aprovada. Apenas o titular da conta pode assiná-la, e dApps externos normalmente não podem agir em seu nome.

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

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

Minha chave nunca vazou. Uma autorização EIP-7702 maliciosa ainda pode drenar a conta?

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

Verifique o ID da cadeia e o endereço-alvo na tupla, e assine apenas para contratos imutáveis; as equipes de carteira também devem verificar a função do signatário antes de conceder aprovações internas relacionadas à delegação em nome de uma organização.