Abstração de contas nativas + resistência a ameaças quânticas: porque é que o EIP-8141 ainda não se tornou a principal proposta do Ethereum Hegotá?

Artigo: imToken

Na semana passada, na reunião formal de programadores principais do Ethereum, discutiu-se, de forma oficial, se o EIP-8141 deveria ou não ser incluído na atualização Hegota. O resultado foi inesperado: a proposta, que foi endossada pessoalmente por Vitalik, não foi listada como um dos “destaques” da Hegota, mas sim recebeu o estatuto de “a considerar para inclusão” (CFI).

E nesta semana, a equipa de Quantum AI da Google publicou o seu mais recente white paper, afirmando que, sob as premissas de hardware que definiu, a estimativa do número de qubits quânticos físicos necessários para quebrar o ECDLP-256 diminuiu, em comparação com antes, de forma substancial — vinte vezes. Embora isto não signifique que os ataques quânticos estejam à porta, serve, de forma muito concreta, para nos lembrar que, se o sistema de contas não conseguir, no futuro, mudar de forma flexível a lógica de validação, então muitas das discussões de hoje sobre a experiência das carteiras poderão, no fim, evoluir para problemas de segurança.

Apesar de, do ponto de vista da realidade do avanço do protocolo, o EIP-8141 ainda estar demasiado pesado atualmente — especialmente no que toca à implementação nos clientes, à segurança do mempool e à complexidade da validação — ainda não se formou um consenso suficientemente sólido.

Mas, neste momento, parecem existir cada vez mais razões para discutir e analisar seriamente o EIP-8141.

1. O que é que o EIP-8141 pretende resolver, afinal?

O EIP-8141 é promovido por Vitalik Buterin e outros contributores centrais, como timbeiko. O seu nome oficial é Frame Transactions (transações em moldura).

Se o resumirmos numa frase mais fácil de entender, a sua intenção não é, na verdade, adicionar isoladamente uma funcionalidade de carteira, mas sim tentar, a nível de protocolo, fazer com que qualquer conta já não fique presa a um único caminho de assinatura por ECDSA, e que possa, em vez disso, ter lógica de validação e execução mais flexível.

Isto também significa que carteiras multi-assinatura (multi-sig), patrocínio de Gas, rotação de chaves, recuperação social e, até mesmo, no futuro, a integração de esquemas de assinatura resistentes a ataques quânticos, deixam de ser apenas capacidades “extras” por fora da carteira, passando a ter a oportunidade de se tornarem “membros nativos” no sistema de contas do Ethereum.

Se olharmos apenas para a superfície, a discussão em torno do EIP-8141 fala de um conjunto de capacidades bastante concretas: pagar Gas com stablecoins, compor múltiplas ações numa única transação, suportar formas de assinatura mais flexíveis e, até, deixar espaço para assinaturas resistentes a ataques quânticos no futuro. Pode-se dizer que, ao longo de muitos anos, melhorias em torno da experiência de carteiras — desde o ERC-4337 até ao EIP-7702 —, no fundo, têm vindo a tornar a conta mais do que apenas uma chave privada: uma entrada onde é possível personalizar regras.

O problema é que, embora estas melhorias tornem a carteira cada vez mais parecida com uma conta inteligente, nunca chegam verdadeiramente a tocar no modelo nativo por defeito mais profundo do Ethereum.

Como é sabido, no sistema atual, as contas do Ethereum se dividem, em termos gerais, em dois tipos. Um é a conta de posse externa, ou seja, a EOA (Externally Owned Account) que todos conhecemos bem: é controlada por uma chave privada, pode iniciar transações ativamente, mas não tem capacidade programável; o outro é a conta de contrato — ou seja, o próprio contrato inteligente: consegue executar lógica complexa, mas não pode iniciar transações por si.

Daqui resulta que a capacidade de iniciar transações fica, durante muito tempo, ligada a uma assinatura de chave privada única. Enquanto esse pressuposto se mantiver, muitas capacidades que muitos utilizadores hoje consideram “óbvias” — como mudar de forma flexível as regras de assinatura, permitir que terceiros paguem o Gas, recuperar o controlo da conta após perder a chave privada ou, no futuro, migrar de forma suave para um novo sistema de credenciais — dificilmente se tornam capacidades por defeito reais da conta.

Se já usou o imToken ou outra carteira Web3, muito provavelmente também já enfrentou estes pontos dolorosos: existe muito USDC na carteira, mas sem ETH não consegue enviar transações (porque o Gas só pode ser pago com ETH); perdeu a frase-semente e perdeu definitivamente o dinheiro, sem possibilidade de recuperação; uma operação do tipo “autorizar + trocar” exige assinar duas vezes e confirmar duas vezes, etc.

Estes problemas não se devem a “produto de carteira” que não seja suficientemente bom; são, na verdade, um resultado do próprio desenho do modelo de contas do Ethereum.

Visto por este ângulo, a evolução dos últimos dois anos tem estado já muito clara: o ERC-4337, sem modificar o protocolo, trouxe a abstração de conta para funcionar primeiro ao nível da aplicação; e o EIP-7702 provou ainda mais que a EOA não é totalmente impossível de expandir — pelo menos pode obter temporariamente parte das capacidades próximas de uma conta inteligente.

Ou seja, o Ethereum não é que não queira fazer abstração de contas, mas tem vindo sempre a fazê-lo de uma forma mais suave e conservadora, aproximando-se passo a passo deste objetivo. E o aparecimento do EIP-8141 significa que esta trajetória chegou a um novo ponto. Deixa de se contentar em empilhar uma camada de capacidades de conta inteligente na periferia do sistema existente: pretende incorporar a abstração de contas diretamente no modelo de transações, fazendo com que, desde o nível de protocolo, a conta passe a ter lógica programável de validação e execução.

É por isso que o EIP-8141 volta a estar “em alta” hoje. Por um lado, a experiência de carteira ao nível superior já está cada vez mais próxima da abstração nativa de contas, e o protocolo mais cedo ou mais tarde precisará de acompanhar; por outro lado, a pressão de longo prazo trazida pela computação quântica está também a transformar a questão de “se a conta consegue mudar de forma flexível o método de assinatura” de um tema técnico distante numa questão real que é preciso considerar com seriedade antecipadamente.

2. Como é que o EIP-8141 funciona?

No fundo, o EIP-8141 introduz um tipo de transação completamente novo — uma Frame Transaction (transação em moldura), com o identificador do tipo de transação 0x06.

Se a lógica base das transações tradicionais do Ethereum for que uma transação corresponde a uma chamada, então o que o EIP-8141 quer fazer é decompor uma transação num conjunto de “molduras” executadas por regra, numa sequência definida, de modo a separar as três coisas que antes vinham atadas: validação, pagamento e execução.

Cada “moldura” tem três modos de execução:

VERIFY (moldura de validação): responsável por validar se a transação é legítima. Vai executar a lógica de validação definida pela conta; se passar, chama o novo opcode de APPROVE, para autorizar a execução e indicar o limite máximo de Gas.

SENDER (moldura de envio): executa a ação real, como transferências, chamadas de contrato, etc. O endereço do chamador é o próprio remetente da transação.

DEFAULT (moldura de entrada): usa o endereço de entrada do sistema como chamador, para cenários como implementação de contratos, validação de Paymaster, etc.;

O significado deste mecanismo não é simplesmente tornar a transação mais complexa, mas sim separar pela primeira vez “validação, pagamento e execução” das ações da conta e deixá-las a cargo do agendamento nativo do protocolo.

No passado, essencialmente, quem valida a transação, quem paga o Gas e quem executa a ação real estavam, em grande medida, presos à mesma ação de conta. No desenho do EIP-8141, estas tarefas podem ser separadas em molduras diferentes, executadas pelo protocolo numa ordem clara. E é exatamente por isso que a conta deixa de ter de depender apenas de uma única chave privada para “assinar tudo de uma vez” e começa a assumir uma forma mais próxima de um agente de execução programável.

Para dar um exemplo concreto: suponha que quer usar USDC para pagar o Gas e concluir um Swap. No quadro do EIP-8141, em teoria, isto pode ser organizado como um fluxo completo de molduras: primeiro, a conta valida a assinatura e as permissões de execução; depois, o pagador ou o Paymaster valida as condições de que concorda em assumir os custos; em seguida, completa-se o pagamento das taxas do ativo correspondente; por fim, executa-se de facto a operação swap.

Desta forma, o pagamento do Gas e a transação principal podem ser incluídos no mesmo fluxo atómico: ou tudo tem sucesso, ou tudo é revertido.

Para os utilizadores, a mudança mais intuitiva é que muitas operações que antes tinham de ser feitas em duas ou três etapas, com riscos de falha no meio, poderão no futuro parecer-se mais com uma única ação completa. Por isso, a atomicidade é também uma das chaves que o EIP-8141 quer resolver: a fragmentação da experiência do utilizador.

O que é que isto significa para os utilizadores de carteiras? Pelos resultados, há pelo menos quatro camadas de mudança mais imediatas:

Gas abstrato: se a carteira tiver stablecoins, isso já não significa que terá de preparar ainda mais um pouco de ETH para conseguir operar; no futuro, pagar o Gas por conta será algo mais “nativo” feito por DApp, Paymaster ou outros patrocinadores;

Operações em múltiplas etapas consolidadas: fluxos como “autorização + Swap” e “autorização + staking”, que hoje muitas vezes exigem múltiplas assinaturas, têm oportunidade de ser empacotados numa operação mais completa;

Regras de segurança da conta abertas: multi-sig, recuperação social, limites diários, time locks (bloqueios temporais), rotação de chaves — tudo isto deixa de ser apenas uma funcionalidade avançada adicionada por algum produto de carteira e passa a ter, pela primeira vez, a oportunidade de ser construído sobre uma lógica de conta mais nativa;

Esquema de assinatura já não precisa de ficar travado numa única via por ECDSA: isto abre, no futuro, a possibilidade em termos de protocolo para a conta migrar para diferentes sistemas de credenciais, incluindo esquemas de assinaturas pós-quânticas. Pela primeira vez, passa a existir relevância a nível de protocolo;

3. Por que razão não se tornou o principal destaque da Hegotá?

Um ponto que é fácil de ignorar, mas que é muito importante para utilizadores de carteiras, é o seguinte: mesmo que o EIP-8141 seja finalmente concretizado, o sistema de contas existente não será, por isso, totalmente substituído.

Mesmo que esteja a usar agora uma carteira Web3 existente como o imToken, não precisa de migrar: mantém compatibilidade retroativa. Os endereços atuais de EOA podem continuar a ser usados; só é necessário, quando chegar o momento adequado, escolher “atualizar” a lógica de validação da conta.

Mas, por outro lado, é precisamente por ter mexido suficientemente fundo que não chegou a tornar-se diretamente o principal destaque de funcionalidade da Hegotá nas discussões mais recentes. Contudo, de acordo com o processo do “EIP champion” de 2026, o significado de CFI (Considered for Inclusion) não é ser negado: é entrar na fase de consideração séria, mas ainda não chegar ao momento de uma decisão final para lançamento.

Por outras palavras, os programadores principais não estão a rejeitar a direção do EIP-8141; estão, sim, a reconhecer o seu valor, mas também a considerá-lo ainda demasiado “pesado” neste momento.

No fim, a abstração nativa de contas não pode ser impulsionada primeiro, como o ERC-4337, por um pequeno conjunto de carteiras, infraestrutura e aplicações. Quando entra no nível do protocolo, significa que todos os clientes do nível de execução têm de o levar a sério: implementar, testar e coordenar. Isso, por natureza, aumenta a barreira para avançar, e leva também os programadores principais, ao planear um fork, a penderem para uma abordagem mais prudente.

Então o que acontecerá a seguir? Podemos olhar para isto como duas linhas:

Como o EIP-8141 está em estado de CFI, isso indica que ainda está a ser avaliado continuamente. O autor da proposta irá continuar a completar os detalhes-chave em torno da segurança do mempool, das regras de validação e da implementação dos clientes; depois, nas reuniões ACD, ele será novamente revisitado para verificar se reúne condições para um avanço adicional;

Se estas incertezas puderem ser continuamente reduzidas, pode existir a hipótese de ele entrar numa fase mais substancial de inclusão nas atualizações seguintes; caso contrário, também é totalmente possível que seja adiado para um ciclo de atualização mais tarde;

Dito de forma honesta, o EIP-8141 não é a única proposta de abstração nativa de contas. E, além disso, ele não é, por si, um tipo de solução pronta para assinaturas resistentes a ataques quânticos que resolva diretamente o problema da computação quântica. No entanto, a sua importância está em que, pela primeira vez, ele fornece uma saída com significado a nível de protocolo para que as contas se libertem do caminho único de ECDSA.

Visto por este ângulo, o verdadeiro valor do EIP-8141 não está em saber se é ou não a única resposta correta, mas em que, pela primeira vez, coloca de forma muito completa na mesa de discussão do protocolo Ethereum a questão de como deve ser, no fim, a abstração de contas nativa.

Não é a única solução, mas é, de facto, uma das mais ambiciosas e que mais se aproxima do limite máximo da imaginação de um “AA nativo completo” nos dias de hoje.

Independentemente de o EIP-8141 conseguir ou não chegar a tempo à Hegotá, esta discussão em si já está a mostrar pelo menos uma coisa:

O Ethereum não ficou à espera parada para o problema ganhar maturidade; está a abrir caminho para o próximo sistema de contas com passos pequenos e consistentes, a preparar o futuro com antecedência.