Contas inteligentes Ethereum: UserOperations, bundlers e patrocínio de gás

Uma conta de propriedade externa (EOA) comprova controle com a assinatura de uma chave privada. Seu nonce ordena as transações.

É um modelo simples, mas normalmente a mesma chave autoriza todas as ações e uma transação comum costuma iniciar uma chamada de primeiro nível; o contrato chamado ainda pode executar outras chamadas internas.

Essa distinção complementa o guia de transações pendentes da Ethereum, que trata do pool de transações EOA, e não do fluxo ERC-4337.

Uma conta inteligente é um contrato que pode manter ativos e executar chamadas.

Seu código de validação pode aplicar regras específicas da conta, como uma assinatura, um limite de várias assinaturas ou permissões que expiram após determinado período.

O ERC-4337 não determina um produto de carteira nem uma política de recuperação; ele fornece uma interface para que uma conta em contrato autorize e execute operações.

A Ethereum.org apresenta possibilidades da abstração de conta, como chaves de backup, permissões limitadas e patrocínio de gás. Cada carteira pode implementar recursos diferentes.

O rótulo “carteira inteligente” não revela, por si só, a segurança da conta nem quem a controla. Confira qual contrato mantém os ativos, qual código e EntryPoint a conta considera confiáveis e quais signatários podem autorizar chamadas.

Se a lógica da conta puder ser atualizada, o acesso administrativo e os procedimentos de mudança também afetam o controle dos ativos.

Uma UserOperation é um objeto que descreve o que uma conta inteligente pretende fazer. Em geral, inclui a conta remetente, um nonce próprio da conta, dados da chamada, uma assinatura, limites de gás e condições de tarifa.

Também pode conter informações de uma factory para criar a conta ou de um paymaster para solicitar patrocínio. Os campos exatos dependem da versão do EntryPoint.

Em vez de enviar o objeto diretamente à rede pelo método comum eth_sendTransaction, a carteira o envia a um bundler ou relay que oferece RPC ERC-4337, como eth_sendUserOperation.

A solicitação passa por um pool de UserOperations separado do pool de transações Ethereum comuns. O hash da UserOperation identifica a solicitação; a transação on-chain criada pelo bundler tem outro hash e recibo.

A ERC-7769 define métodos RPC para envio, consulta pelo hash e recibos de UserOperation.

Uma resposta do bundler pode significar que a solicitação passou pelas verificações daquele serviço e entrou em seu pool. Isso não prova que um bloco a incluiu nem que a ação do app foi bem-sucedida.

A forma como um bundler compartilha a solicitação com outros depende de sua infraestrutura e política. Separe o aceite do provedor do resultado registrado na rede.

O bundler recebe a UserOperation, verifica a compatibilidade com sua versão do EntryPoint e simula a validação da conta e do paymaster.

Confere a assinatura, se a conta confia naquele EntryPoint e se nonce, gás e condições do patrocínio são válidos. Pode rejeitar uma operação que viole suas regras ou falhe na simulação.

O guia de bundlers do ERC-4337 explica esse papel na simulação e no envio de lotes.

O bundler seleciona uma ou mais operações aprovadas e cria uma transação Ethereum comum que chama handleOps no EntryPoint. A inclusão dessa transação em um bloco ainda depende da produção de blocos e das condições da rede.

O hash de UserOperation retornado não prova que a execução aconteceu na rede canônica.

O pool de UserOperations é separado do pool EOA; não presuma que todos os provedores compartilham os mesmos pedidos. Um bundler pode rejeitar uma operação ou deixá-la aguardando.

As redes, versões de EntryPoint e políticas compatíveis podem variar entre carteiras e provedores. Ao verificar o status, diferencie a tela da carteira, o recibo da operação e o recibo on-chain da transação em lote.

O EntryPoint recebe a chamada handleOps do bundler e invoca a função de validação de cada conta inteligente. A conta confirma se a chamada veio de um EntryPoint confiável e aplica suas regras à assinatura.

O EntryPoint valida e incrementa a sequência de 64 bits de cada conta e chave nonce; a conta pode definir sua própria lógica para o campo de chave de 192 bits. Assim, uma conta pode usar várias chaves, cada uma com sua sequência.

Um paymaster opcional também verifica se patrocinará a operação. Depois da validação, o EntryPoint chama a função de execução da conta para realizar a ação descrita em callData e liquidar o custo.

O EntryPoint é o contrato central que possibilita fluxos de conta inteligente sem alterar o protocolo Ethereum para cada modelo de carteira. Confira o endereço realmente implantado, a versão e as redes compatíveis com a carteira.

O guia ERC-4337 do EntryPoint detalha a validação e a execução.

A simulação é uma prévia útil, não uma promessa de inclusão. O estado da rede, as tarifas, uma janela de validade ou o estado de um contrato externo podem mudar enquanto a operação espera e alterar o resultado da validação on-chain.

Mesmo depois de validada, uma chamada do app pode falhar ou reverter. A inclusão em bloco, por si só, não prova que a transferência ou ação pretendida foi concluída.

Se a UserOperation incluir dados de paymaster, o EntryPoint pergunta a esse contrato se ele aceita patrociná-la. Isso pode permitir que um app cubra as tarifas ou que uma pessoa comece uma ação sem manter ETH na conta.

Alguns modelos também aceitam pagamento em tokens ou outros critérios, conforme a carteira e a implementação do paymaster.

O patrocínio não faz o gás desaparecer nem elimina as condições. Um paymaster pode limitar apps, usuários, número de operações ou valores elegíveis, analisar a solicitação e recusá-la.

O depósito dele no EntryPoint paga os custos das operações. Se houver stake separado, ele funciona como garantia segundo as regras de validação; não é o mesmo saldo disponível para pagar o gás.

O guia de paymasters do ERC-4337 e a EIP-4337 descrevem validação e liquidação.

Uma tarifa exibida como zero no app não significa que não há custo. O patrocinador pode pagar primeiro e recuperar valor depois por assinatura, cobrança em token ou termos do serviço.

Confira quem arca com o custo final, se o patrocínio tem limite ou teto de uso e se uma operação malsucedida ainda pode gerar tarifa.

Se a carteira oferecer suporte, a pessoa pode incluir uma aprovação do app e um swap na mesma UserOperation. As duas ações são enviadas como uma operação pelo EntryPoint.

Isso é diferente de uma transação EOA comum e também de um bundler colocar várias UserOperations distintas em uma transação da rede. Confira a prévia da carteira para entender qual estrutura será usada.

Em um exemplo hipotético, suponha que uma operação patrocinada e aprovada tenha custo real de gás de 0,0012 ETH. Esse custo pode ser liquidado pelo depósito do paymaster no EntryPoint, e não pelo saldo da pessoa.

0,0012 ETH é um valor ilustrativo, não cotação ou preço atual. O valor real depende do gás usado, das condições da tarifa e da rede.

Agrupar chamadas não é automaticamente mais barato nem mais seguro. A atomicidade de várias chamadas depende de como a conta inteligente lida com falhas.

Confira se uma chamada malsucedida reverte todo o lote, se algumas ações ainda podem ser concluídas e quem paga o gás. Uma estimativa imprecisa ou um app indisponível pode causar rejeição ou falha de execução.

O guia de tarifas de gás da Ethereum explica os campos gerais de tarifa.

Uma conta inteligente pode ter signatários de backup ou um processo em que guardiões confiáveis atingem um limite para substituir uma chave.

Alguns modelos acrescentam um período de espera durante o qual a chave atual pode contestar a mudança. Mas, se uma única assinatura específica for sempre necessária, perder essa chave pode deixar a conta sem caminho de recuperação.

O ERC-4337 permite que cada conta valide UserOperations segundo suas regras; não fornece chaves de backup nem recuperação social por padrão.

Poucos guardiões ou regras fracas de substituição podem criar um caminho de ataque. Muitos guardiões ou requisitos rigorosos podem atrasar a recuperação legítima.

Confira o limite, o período de espera, os direitos de cancelamento e como as chaves de recuperação são protegidas. Essas regras também determinam quem pode bloquear uma operação, além de quem pode autorizá-la.

Uma carteira em contrato não é automaticamente custodial nem não custodial.

O controle depende de quem guarda as chaves de assinatura, se a conta tem autoridade administrativa ou de atualização e o que um signatário hospedado ou serviço de recuperação pode autorizar.

Analise separadamente o contrato que guarda os ativos e as chaves e serviços que o controlam.

O backup de frase-semente comum é um tema separado do guia de recuperação de carteira.

Na prévia da carteira, verifique rede, endereço da conta, contratos de destino, dados de chamada, escopo das aprovações de tokens e número de chamadas. Uma assinatura pode autorizar mais do que a única ação destacada pela interface.

Se você não entender os dados assinados, consulte a documentação oficial do app e da carteira antes de continuar.

Para entender o patrocínio, leia os critérios de elegibilidade, limites de uso, condições de pagamento alternativas e regras de custo em caso de falha; não confie apenas no nome do paymaster.

Uma indicação de patrocínio ativo não significa que o app seja incondicionalmente grátis, e o paymaster ainda pode recusar a operação. Congestionamento da rede e atrasos de inclusão são questões separadas.

Se uma UserOperation ficar aguardando por muito tempo, não aplique um fluxo EOA de “acelerar” ou “cancelar” sem conferir como a carteira trata UserOperations. Primeiro procure o hash e o recibo da operação.

Se houver o hash da transação do bundler, confira também o recibo do bloco e o resultado da execução. Recibos RPC podem distinguir custo e sucesso de uma operação do recibo da transação em lote inteira.

Isso difere de substituir ou cancelar uma transação EOA com o mesmo nonce.