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á?

Na semana passada, na reunião oficial dos programadores principais do Ethereum, discutiu-se formalmente se o EIP-8141 deve ser incluído na atualização Hegota; para surpresa de muitos, esta proposta, defendida pessoalmente por Vitalik, não foi listada como uma “funcionalidade de destaque” da Hegota, mas sim com o estado de “Considered for Inclusion” (CFI).

E nesta semana, a equipa de Quantum AI da Google publicou um novo whitepaper, afirmando que, sob as hipóteses de hardware que assume, a estimativa de qubits quânticos físicos necessários para quebrar o ECDLP-256 caiu drasticamente em comparação com antes, 20 vezes. Embora isto não signifique que um ataque quântico esteja iminente, serve de forma muito concreta para nos lembrar que se, no futuro, o sistema de contas não puder 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.

Do ponto de vista mais realista de avançar o protocolo, o EIP-8141 ainda é demasiado pesado neste momento, sobretudo no que toca à implementação em clientes, à segurança do mempool e à complexidade de validação — ainda não se formou um consenso suficientemente sólido.

Mas, neste ponto do tempo, parece que há cada vez mais razões para discutir e analisar cuidadosamente o EIP-8141 com seriedade.

I. O que é que o EIP-8141 pretende resolver?

O EIP-8141 é impulsionado por Vitalik Buterin e outros contribuidores principais, incluindo timbeiko; o nome oficial é Frame Transactions (transações em moldura).

Se o resumirmos numa frase mais fácil de compreender, o que ele quer fazer não é, na verdade, adicionar isoladamente uma funcionalidade específica da carteira, mas sim tentar, ao nível do protocolo, fazer com que qualquer conta já não esteja acorrentada a um único caminho de assinatura ECDSA; em vez disso, pode ter uma lógica de validação e execução mais flexível.

Isto também significa que carteiras multi-assinatura, patrocínio de Gas, rotação de chaves, recuperação social e, até mesmo no futuro, a ligação a soluções de assinaturas resistentes a ataques quânticos, deixam de ser apenas uma camada de capacidade “à parte” do exterior da carteira, e passam a ter a oportunidade de se tornarem membros “nativos” do ecossistema do sistema de contas do Ethereum.

Se olharmos apenas para a superfície, a discussão em torno do EIP-8141 aborda um conjunto de capacidades bastante concretas à primeira vista: pagar Gas com stablecoins, compor múltiplas etapas de operação numa única transação, suportar formas de assinatura mais flexíveis e reservar espaço para assinaturas resistentes a ataques quânticos no futuro. Pode dizer-se que, ao longo dos anos, de ERC-4337 a EIP-7702, muitas melhorias em torno da experiência de carteiras, no fundo, estão a fazer com que a conta deixe de ser apenas uma chave privada e passe a ser uma entrada na qual regras podem ser personalizadas.

O problema é que estas melhorias, de facto, fazem com que as carteiras se tornem cada vez mais como contas inteligentes, mas nunca chegam verdadeiramente a tocar no modelo de conta predefinido mais baixo do Ethereum.

Como é sabido, no sistema atual as contas do Ethereum, de forma geral, dividem-se em dois tipos. Um é a conta de propriedade externa (EOA), ou seja, aquela com que todos estão mais familiarizados: é controlada por uma chave privada, pode iniciar transações de forma ativa, mas não tem capacidade programável; o outro é a conta de contrato, isto é, o próprio contrato inteligente: pode executar lógica complexa, mas não pode iniciar transações por si só de forma ativa.

Isto leva a que a capacidade de iniciar transações fique ligada a longo prazo à assinatura de uma chave privada única. Enquanto esse pressuposto não mudar, torna-se difícil que capacidades que muitos utilizadores consideram hoje como óbvias, como trocar regras de assinatura de forma flexível, permitir que outros paguem o Gas, recuperar o controlo da conta após a perda da chave privada, ou migrar de forma mais suave no futuro para um novo sistema de palavras-passe, se tornem verdadeiramente capacidades predefinidas da conta.

Se já usou o imToken ou outras carteiras Web3, é muito provável que tenha encontrado esses problemas: por exemplo, há USDCs na carteira mas não há ETH e não consegue enviar transações (porque o Gas só pode ser pago com ETH); perder as palavras-passe mnemónicas significa perder o dinheiro de forma definitiva, sem possibilidade de recuperação; e uma operação de “autorização + troca” exige assinar duas vezes, confirmar duas vezes, etc.

Estes problemas não se devem a que o produto de carteira “não seja bom o suficiente”, mas sim ao resultado da própria conceção do modelo de contas do Ethereum.

Visto deste ângulo, a evolução dos últimos dois anos já está bastante clara: o ERC-4337, sem modificar o protocolo, fez com que a abstração de conta corresse primeiro na camada da aplicação; e o EIP-7702 veio demonstrar ainda que as EOA não são completamente impossíveis de expandir — pelo menos é possível obter temporariamente parte de capacidades próximas das contas inteligentes.

Ou seja, o Ethereum não é que não queira fazer abstração de contas, mas sim que tem vindo a fazê-lo de forma mais suave e conservadora, aproximando-se gradualmente desta ideia. E o surgimento do EIP-8141 significa que este caminho chegou a um novo ponto: ele já não se limita a sobrepor mais uma camada de capacidade de conta inteligente fora do sistema existente; em vez disso, tenta incorporar a abstração de contas diretamente no próprio modelo de transações, para que a conta possua lógica de validação e execução programável desde a camada do protocolo.

É por isso que o EIP-8141 volta a ganhar força hoje. Por um lado, a experiência da carteira na camada superior já se aproxima cada vez mais da abstração nativa de conta, e mais cedo ou mais tarde a camada do protocolo terá de acompanhar; por outro lado, a pressão de longo prazo trazida pela computação quântica também está a transformar “se a conta pode ou não mudar de forma flexível o método de assinatura” de um tema técnico distante numa questão de realidade que precisa de ser considerada com seriedade e com antecedência.

II. Como funciona o EIP-8141?

No fim de contas, o EIP-8141 introduz um tipo de transação completamente novo — transação em moldura (Frame Transaction), com identificador de 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 pretende fazer é pegar numa transação e dividi-la em “molduras” executáveis por ordem segundo regras, para separar as três coisas que antes ficavam atreladas — 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; ela executa a lógica de validação personalizada da conta. Se for aprovado, chama o novo opcode APPROVE para autorizar a execução e definir um limite máximo de Gas.
• SENDER (moldura de envio): executa a operaçã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 deployment de contratos e validação de Paymaster;

O significado deste mecanismo não é que a transação possa tornar-se mais complexa, mas sim que, pela primeira vez, as três coisas — validação, pagamento e execução — são separadas das ações da conta e passam a ser despachadas nativamente pelo protocolo.

Afinal, no passado, quem validava a transação, quem pagava o Gas e quem executava a operação real estavam, em grande medida, presos à mesma ação de conta. Mas sob o desenho do EIP-8141, essas tarefas podem ser separadas em molduras diferentes, e o protocolo executa-as por uma ordem clara e definida; é precisamente por isso que a conta deixa de depender apenas de uma única chave privada para “assinar tudo em conjunto” e passa a ter uma forma mais próxima de um agente executável programável.

Vejamos um exemplo concreto: suponha que pretende usar USDC para pagar o Gas para completar um Swap. No enquadramento 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 Paymaster valida as condições de que está disposto a assumir os custos; em seguida, é feito o pagamento dos custos do ativo correspondente; por fim, é executada a operação de swap em si.

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

Para os utilizadores, a mudança mais intuitiva é que muitas operações que antes eram obrigadas a ser decompostas em duas ou três etapas, com risco de falha no meio, no futuro podem ser tão “como uma ação completa”. Por isso, esta atomicidade é uma das chaves que o EIP-8141 quer resolver no sentido da fragmentação da experiência do utilizador.

Então, o que é que isto significa para utilizadores de carteiras? Em termos de resultados, a mudança mais direta tem, pelo menos, quatro camadas:

• O pagamento de Gas é abstratizado: ter stablecoins na carteira deixa de significar que tem de preparar ainda um pouco de ETH para operar; no futuro, que DApps, Paymasters ou outros patrocinadores paguem o Gas por si torna-se mais nativo;
• Operações em múltiplos passos são agregadas: processos como “autorização + Swap” e “autorização + staking”, que hoje frequentemente exigem várias assinaturas, têm a oportunidade de ser embalados numa operação mais completa;
• Regras de segurança da conta são abertas: multi-assinatura, recuperação social, limites diários, time locks, rotação de chaves — tudo isto deixa de ser apenas funcionalidades avançadas fornecidas como extras por algum produto de carteira, e passa a ter a oportunidade de ser construído sobre a lógica de conta mais nativa;
• A escolha do esquema de assinatura deixa de ter de ficar presa necessariamente a um único caminho ECDSA: isto faz com que a conta, no futuro, migre para diferentes sistemas de credenciais, incluindo esquemas de assinaturas resistentes a ataques quânticos, e pela primeira vez ganha uma possibilidade com significado ao nível do protocolo;

III. Porque é que não se tornou o carro-chefe da Hegotá?

Um ponto que é fácil de ignorar, mas que é crucial para utilizadores de carteiras, é: mesmo que o EIP-8141 seja finalmente implementado, o sistema de contas existente não será, por isso, totalmente posto de parte.

Mesmo que neste momento esteja a usar uma carteira Web3 existente, como o imToken, não precisa de migrar, porque é compatível com versões anteriores: os endereços atuais de EOA podem continuar a ser utilizados; basta, quando fizer sentido, escolher “atualizar” a lógica de validação da conta.

Mas, por outro lado, precisamente por ter sido alterado de forma suficientemente profunda, ele não se tornou diretamente uma funcionalidade carro-chefe da Hegotá na discussão mais recente. Contudo, seguindo o processo de EIP champion de 2026, o significado de CFI (Considered for Inclusion) não é “negado”; é sim que entra num estágio de consideração séria, mas ainda não é a altura de uma decisão final para ativação.

Por outras palavras, os programadores principais não estão a dizer que não reconhecem a direção do EIP-8141; estão a reconhecer o seu valor, mas entendem que, neste momento, ainda é demasiado “pesado”.

Afinal, a abstração nativa de contas não pode, como o ERC-4337, ser empurrada primeiro por um pequeno número de carteiras, infraestruturas e aplicações. Assim que entra na camada do protocolo, significa que todos os clientes da camada de execução têm de reconhecer, testar e coordenar de forma séria, o que naturalmente eleva o limiar de avanço; além disso, faz com que os programadores principais, ao planear um fork, tendam a preferir uma via mais prudente.

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

• Como o EIP-8141 está em estado de CFI, isso significa que ainda está a ser avaliado de forma contínua. O autor da proposta continuará a reforçar os detalhes-chave em torno da segurança do mempool, das regras de validação e da implementação em clientes; e, mais tarde, a reunião ACD voltará a examiná-lo para ver se cumpre condições para um avanço adicional;
• Se estas incertezas puderem ser reduzidas de forma contínua, ele poderá entrar numa fase de inclusão mais substancial em futuras atualizações; se não, também pode simplesmente ser adiado para um ciclo de atualização ainda mais tarde;

Dito de forma honesta, o EIP-8141 não é a única proposta de abstração nativa de contas; e, além disso, não é uma solução pronta para assinaturas resistentes a ataques quânticos que consiga resolver diretamente o problema da computação quântica. O seu valor reside no facto de que, pela primeira vez, ele fornece uma saída com significado ao nível do protocolo para libertar as contas de um caminho único de ECDSA.

Visto deste ângulo, o verdadeiro valor do EIP-8141 não está em saber se é a resposta única correta, mas sim em que ele coloca, pela primeira vez e de forma muito completa, na mesa das discussões do protocolo do Ethereum a questão de como o desfecho da “abstração nativa de contas” deveria realmente ser.

Não é a única solução, mas é uma das propostas mais ambiciosas e que mais se aproxima do limite da imaginação do que seria um “AA nativo completo”.

Seja qual for o desfecho — quer o EIP-8141 consiga ou não chegar a tempo para a Hegotá — esta discussão, por si só, já demonstra pelo menos uma coisa:

O Ethereum não está à espera, parado, que os problemas se avolumem; está a abrir caminho, com passos graduais, para o sistema de contas da próxima geração.