Carteiras de contratos inteligentes: pipeline do ERC-4337

Carteiras de contratos inteligentes e abstração de contas mudam a atividade das carteiras Ethereum de regras de transação eoa fixas para um pipeline programável onde uma UserOperation é simulada, precificada e só depois transformada em uma transação on-chain por um bundler.

O ERC-4337 é o design de camada de aplicação dominante para isso, e a verdadeira chave é entender os novos intermediários, APIs e modos de falha em vez de memorizar recursos de UX.

Principais Conclusões

• O ERC-4337 substitui o objeto de transação normal por uma UserOperation que fica em um mempool separado até que um bundler a inclua on-chain via handleOps do EntryPoint.
• Bundlers são roteadores de seleção e execução, não relays passivos, porque simulam operações, gerenciam risco de spam e escolhem o que agrupar.
• O ERC-7769 padroniza métodos JSON-RPC wallet↔bundler como eth_sendUserOperation e eth_getUserOperationReceipt, permitindo portabilidade de bundler e melhor rastreamento de recibos.
• Abstração de contacria novas superfícies de custo de DoS e computação, então regras de validação, sistemas de reputação e endurecimento de produção como bloquear endpoints debug_* se tornam parte do modelo de segurança.

Como carteiras de contratos inteligentes diferem de EOAs

Dois tipos diferentes de 'conta' aparecem em umEthereumtela: um eoa que assina uma transação diretamente, e uma conta de contrato que só faz algo quando o código é executado. Umacarteira de contrato inteligentetorna essa conta de contrato a carteira principal, de modo que verificações de assinatura, regras de nonce e lógica de execução se tornam programáveis.

Esse é o núcleo da abstração de conta, e está dentro do mapa mais amplo dos tipos de carteiras cripto explicados: a “carteira” não é mais apenas um par de chaves e um contador de nonce.

A consequência imediata é que os recursos da carteira deixam de ser codificados de forma rígida nas regras de eoa do protocolo. Uma conta inteligente pode aceitar diferentes esquemas de assinatura, impor políticas de gasto ou restringir ações por trás de múltiplas condições, porque a validação é código. É daí que vêm recursos como recuperação social e a categoria mais ampla de carteiras sem semente e de recuperação social. O detalhe importante é que esses recursos estão a jusante do modelo de execução, não do modelo em si.

No Ethereum, o caminho dominante para a abstração de conta é o ERC-4337, que é explicitamente enquadrado como um nível de aplicação em vez de uma mudança no nível de consenso. Esse enquadramento é importante porque implica uma nova cadeia de suprimento de transações em vez de uma reescrita do protocolo.

A “ação da carteira” não é mais sinônimo de “uma transação transmitida para o mempool público.” Torna-se um objeto de intenção que precisa de um agente de inclusão.

Essa camada de agente de inclusão é onde a maioria das explicações se torna preguiçosa. O modelo mental útil não é “uma transação normal com etapas extras.” O modelo útil é “um mercado de transações paralelo” com seu próprio mempool, seus próprios roteadores e suas próprias restrições operacionais.

O fluxo de operação do usuário ERC-4337

Uma UserOperation não entra na cadeia por conta própria. Ela vive fora da cadeia até que um bundler decida que vale a pena transformá-la em uma transação on-chain. As definições do ERC-7769 tornam a sequência explícita: nos fluxos do ERC-4337, transações de usuários são substituídas por objetos UserOperation, e um bundler coleta uma ou mais UserOperations e as envia para o contrato EntryPoint em uma única chamada handleOps.

Esse pipeline tem uma ordem clara de eventos:

1. A carteira constrói uma UserOperation que codifica o que o usuário deseja fazer e como as taxas serão cobertas. 2. A UserOperation é enviada para um nó de mempool de UserOperation que valida e simula antes de aceitá-la. 3. Um bundler seleciona UserOperations aceitas, as empacota e envia uma transação on-chain chamando EntryPoint.handleOps. 4.

EntryPoint executa as operações, e a cadeia produz um recibo de transação normal para o pacote mais os resultados por UserOperation.

A tese do “mercado paralelo” aparece no passo 3. A inclusão e a precificação não são mais puramente o problema do usuário de definir maxFeePerGas e esperar. O bundler assume o custo de computação e o risco de seleção.

É por isso que alguns desenvolvedores argumentam que o principal valor do ERC-4337 é um mercado de taxas descentralizado para operações de usuários que vão para carteiras de contratos inteligentes, não apenas uma experiência do usuário mais agradável.

É também aqui que "abstração de conta explicada" tende a dar errado. O objeto que o usuário assina não é garantido que se torne uma transação. O usuário pode fazer tudo corretamente e ainda assim não ser incluído se os agregadores não o pegarem, se a simulação falhar ou se a operação expirar.

A postura correta de UX é tratar o hash da UserOperation como o principal identificador de rastreamento até a inclusão, e depois mapeá-lo para o hash da transação do pacote após o fato.

APIs e ferramentas de carteira para agregadores

ERC-4337 só se torna utilizável em grande escala quando as carteiras podem se comunicar com os bundlers de uma maneira padronizada. É isso que o ERC-7769 adiciona: uma interface JSON-RPC que espelha a ergonomia da submissão de transações Ethereum normal e da busca de recibos, mas para UserOperations.

Os métodos principais que o ERC-7769 define são aqueles que mudam as decisões de integração do dia a dia:

1. eth_sendUserOperation envia uma UserOperation para o mempool de UserOperation. O cliente valida e simula, e deve retornar um userOpHash apenas se passou na simulação e foi aceito no pool. 2. eth_estimateUserOperationGas estimagáscampos para uma UserOperation, com a assinatura ignorada para fins de estimativa. 3.

eth_getUserOperationByHash permite que uma carteira consulte se uma operação está pendente, incluída ou desconhecida, e retorna metadados de inclusão como blockNumber e transactionHash quando disponíveis. 4. eth_getUserOperationReceipt retorna um recibo por operação uma vez incluído, incluindo actualGasCost, actualGasUsed e uma flag de sucesso, enquanto também retorna o TransactionReceipt do bundle. 5.

eth_supportedEntryPoints informa à carteira quais Endereços de EntryPoint o bundler suporta, que é a primeira verificação de portabilidade que um backend de carteira deve realizar.

Esta é a história da infraestrutura silenciosa: a padronização é o que torna possível um mercado competitivo de bundlers. Se uma carteira fala ERC-7769, ela pode trocar os backends de bundler sem reescrever toda a sua lógica de submissão e rastreamento. Isso édescentralizaçãopor interface, não por slogan.

ERC-7769 também traça uma linha dura entre teste e produção. Ele define debug_métodos para desenvolvimento e teste de compatibilidade, e especifica que esses métodos debug_JSON-RPC devem ser bloqueados em servidores de produção. Isso não é etiqueta. Faz parte do modelo de segurança para qualquer um que opere infraestrutura AA pública.

ERC-7769 também faz referência explícita ao suporte eip 7702 no objeto UserOperation em redes onde está ativado, através de uma tupla eip7702Auth. As fontes fornecidas não determinam o escopo final ou o status de ativação do eip 7702 em redes, mas o trabalho de interface no ERC-7769 sinaliza que a conexão entre carteira↔bundler está sendo projetada para acomodar essa direção.

Segurança do Mempool, simulação e riscos de DoS

A simulação é o centro de custo que faz a abstração de contas parecer como se estivesse executando um motor de correspondência em vez de uma caixa RPC passiva. O ERC-7769 é direto sobre isso: operar um nó ERC-4337 público em produção é intensivo em computação e pode ser um alvo de DoS. Esse é o preço a pagar por ter um mempool de UserOperation separado onde os nós devem validar e simular antes de aceitar operações.

A superfície de DoS é estrutural. Um ator malicioso pode enviar operações que são baratas para enviar, mas caras para simular, forçando bundlers e nós do mempool a consumir computação. O ERC-7769 aponta para mitigação através das regras de validação do ERC-7562 e mecanismos de reputação, que são projetados para evitar que nós aceitem operações UserOperations maliciosamente elaboradas e para rastrear a reputação dos participantes.

A insistência do mesmo documento em bloquear debug_* em produção é outra mitigação prática, porque endpoints de depuração podem expor comportamentos de redefinição de estado e agrupamento forçado que são úteis em testes e perigosos na internet aberta.

O ERC-5189 existe porque a saúde do mempool é a parte difícil, e ataca o problema de um ângulo diferente. Ele propõe a abstração de contas através de uma estrutura Operation e contratos de “endorser”, evitando explicitamente novos tipos de transações na camada de consenso, enquanto permanece compatível com carteiras de contratos inteligentes existentes.

O trabalho do endorser é ajudar os bundlers a filtrar “boas operações” de “más operações” em um mempool de operações dedicado.

O mecanismo chave no ERC-5189 é que o endorser retorna informações de prontidão mais informações de dependência. Esse sinal de dependência informa aos bundlers quais mudanças de estado devem acionar a reavaliação, que é uma maneira de evitar que um mempool apodreça com operações que não são mais válidas.

O ERC-5189 ainda não escapa da restrição central: os bundlers devem simular a execução off-chain antes da inclusão, e os operadores do mempool podem banir endorsers que se comportam mal. O design está negociando a mesma troca entre abertura e resistência a spam, apenas com uma conexão diferente.

Caminhos concorrentes para a abstração de contas

Os desenvolvedores do Ethereum não estão debatendo se as carteiras de contratos inteligentes são úteis. Eles estão debatendo qual caminho se tornará o padrão de longo prazo e quais compensações são aceitáveis.

Uma linha de falha visível é EIP-3074 versus ERC-4337, com argumentos de que 3074 poderia oferecer melhorias de UX mais imediatas, enquanto o grupo do 4337 enfatiza propriedades como resistência à censura e, crucialmente, o mercado de taxas descentralizado para operações de usuários.

Esse debate é importante para os construtores porque muda o que significa "infraestrutura de carteira". O ERC-4337 empurra a complexidade para um mercado de transações paralelo: UserOperations, bundlers, EntryPoint, regras de simulação, sistemas de reputação e agora RPC padronizado via ERC-7769.

Essa pilha pode evoluir sem um hard fork de protocolo, mas também cria novos intermediários cujos incentivos e tempo de atividade se tornam parte da experiência do usuário.

A outra razão pela qual existem várias propostas é que "abstração de contas" é um termo abrangente. Algumas propostas se concentram na submissão de intenções e mercados de inclusão. Outras se concentram em como fazer contas de contratos parecerem como EOAs sem forçar cada carteira a ser atualizada.

O objetivo de compatibilidade do ERC-5189 é explícito: suportar implementações existentes de carteiras de contratos inteligentes sem exigir que cada instância de carteira seja atualizada manualmente.

As fontes também destacam o eip 7702 como uma nova direção introduzida em maio de 2024 por Vitalik Buterin e outros, enquadrada como uma resposta às limitações da abordagem em nível de aplicação. O material fornecido não inclui os detalhes da especificação do eip 7702, então a única conclusão responsável é a conscientização do escopo: o ecossistema está construindo interfaces, como a tupla opcional eip7702Auth do ERC-7769, que antecipam mudanças.

Equívocos comuns sobre carteiras de contratos inteligentes e abstração de contas

"A abstração de contas é uma atualização de protocolo que muda as contas do Ethereum." O ERC-4337 é enquadrado como em nível de aplicação, o que significa que não muda como o protocolo Ethereum vê as contas. O protocolo ainda vê EOAs e contas de contratos. A abstração é construída por contratos mais infraestrutura off-chain.

"Bundlers são apenas relayers." Um relayer encaminha uma transação. Um bundler executa validação e simulação, escolhe quais UserOperations aceitar e as empacota em uma chamada handleOps para EntryPoint. Esse papel de seleção é a razão pela qual os bundlers herdam a exposição ao DoS e por que mecanismos de reputação e filtragem aparecem nos padrões.

"AA é principalmente sobre recuperação social e chaves de sessão." Esses são recursos de carteira que se tornam mais fáceis quando a validação é programável, e a recuperação social é um exemplo comum. O diferenciador que muda a estrutura do mercado é o pipeline UserOperation + bundler + EntryPoint e o mempool separado que isso implica.

"O rastreamento funciona como hashes de tx normais." O ERC-7769 adiciona explicitamente métodos by-hash e de recibo para UserOperations porque a semântica de tx-hash não se aplica até que um bundler inclua a operação. Carteiras que tratam a submissão como final enviarão estados pendentes quebrados e um manuseio de falhas confuso.

A Tomada

Eu vi equipes lançarem "UX de conta inteligente" que parecia impressionante em demonstrações e depois desmoronou sob carga porque trataram o ERC-4337 como uma transação normal enfeitada. O erro caro é ignorar a camada de inclusão. Uma UserOperation é uma ordem em um local separado, e ela se torna uma transação na cadeia apenas quando um bundler escolhe roteá-la através de EntryPoint.handleOps.

Se há uma postura que economiza tempo, é construir em torno da infraestrutura: métodos ERC-7769 para envio e rastreamento de recebimento, estados pendentes explícitos e portabilidade de bundler via eth_supportedEntryPoints. No lado da infraestrutura, eu vi pessoas exporem endpoints debug_* em servidores públicos e agirem surpresas quando são abusados. O ERC-7769 destaca isso por uma razão. A abstração de conta é um mercado de transações paralelas, e mercados atraem fluxo adversarial.

Fontes

• Propostas de Melhoria do Ethereum
• Propostas de Melhoria do Ethereum
• Desencadeado
• blockcryptowriter.medium.com