EIP-8141: Por que a Abstração de Conta Nativa não é um recurso principal na atualização Hegota do Ethereum

Artigo escrito por: imToken

Na semana passada, durante a reunião dos desenvolvedores principais da Ethereum, foi discutido formalmente se o EIP-8141 seria incluído na atualização Hegota. O resultado foi inesperado: a proposta, apoiada pessoalmente por Vitalik, não foi listada como uma “funcionalidade principal” da Hegota, mas recebeu o status de “consideração para inclusão” (CFI).

Esta semana, a equipe de Quantum AI do Google publicou um novo whitepaper, indicando que, sob suas suposições de hardware dadas, a estimativa de qubits físicos necessários para quebrar o ECDLP-256 caiu em 20 vezes em comparação com valores anteriores. Embora isso não signifique que ataques quânticos estejam iminentes, ele serve como um lembrete real de que, se os sistemas de conta não puderem ser flexivelmente atualizados no futuro para alterar a lógica de verificação, muitas das discussões atuais sobre experiência de carteira podem acabar se transformando em problemas de segurança.

Embora, do ponto de vista prático do avanço do protocolo, o EIP-8141 ainda seja muito pesado, especialmente em relação à implementação de clientes, segurança do transaction pool e complexidade de validação, ainda não se formou um consenso suficientemente sólido.

Mas, neste ponto temporal atual, os aspectos do EIP-8141 que merecem discussão e análise cuidadosa parecem realmente estar aumentando.

EIP-8141, impulsionado por Vitalik Buterin e outros contribuidores-chave como timbeiko, tem o nome oficial de Frame Transactions.

Em termos mais simples, o objetivo não é apenas adicionar uma função específica à carteira, mas sim, na camada de protocolo, permitir que qualquer conta deixe de depender exclusivamente de um caminho de assinatura ECDSA, adotando em vez disso lógicas de verificação e execução mais flexíveis.

Isso também significa que assinaturas multisig, patrocínio de gas, rotação de chaves, recuperação social e até mesmo futuras integrações com esquemas de assinaturas resistentes a quânticas não serão mais apenas funcionalidades externas adicionadas ao exterior da carteira, mas terão a oportunidade de se tornar “membros nativos” do sistema de contas da Ethereum.

Se observado apenas superficialmente, o EIP-8141 discute um conjunto de capacidades que parecem muito específicas: pagar gas em stablecoins, combinar operações múltiplas em uma única transação, suportar formas mais flexíveis de assinatura e até reservar espaço para assinaturas resistentes a computadores quânticos no futuro. Pode-se dizer que, ao longo dos anos, desde o ERC-4337 até o EIP-7702, muitas melhorias no用户体验 da carteira têm, essencialmente, transformado contas de meras chaves privadas em entradas com regras personalizáveis.

O problema é que essas melhorias realmente tornaram a carteira cada vez mais parecida com uma conta inteligente, mas nunca realmente tocaram no modelo de conta padrão mais fundamental da Ethereum.

Conhece-se amplamente que, no sistema atual, as contas Ethereum são divididas em duas categorias principais. Uma é a conta possuída externamente, também conhecida como EOA, controlada por uma chave privada, capaz de iniciar transações ativamente, mas sem capacidade de programação; a outra é a conta de contrato, ou seja, o próprio contrato inteligente, que pode executar lógicas complexas, mas não pode iniciar transações por conta própria.

Isso faz com que a capacidade de iniciar transações permaneça vinculada por longo prazo à assinatura de uma única chave privada. Enquanto esse pressuposto não mudar, muitas funcionalidades que hoje os usuários consideram naturais — como alterar flexivelmente as regras de assinatura, permitir que outros paguem o Gas, recuperar o controle da conta após perda da chave privada ou migrar suavemente para novos sistemas criptográficos no futuro — serão difíceis de se tornar capacidades padrão das contas.

Se você já usou o imToken ou outra carteira Web3, provavelmente já enfrentou esses problemas, como ter muitos USDC na carteira, mas não conseguir enviar transações por falta de ETH (pois as taxas de gas só podem ser pagas com ETH); perder a frase de recuperação e, consequentemente, perder permanentemente seus fundos; ou precisar assinar e confirmar duas vezes para uma única operação de “autorização + troca”.

Essas questões não são resultado do produto da carteira estar "insuficiente", mas sim da própria arquitetura da conta do Ethereum.

Do ponto de vista deste ângulo, a evolução dos últimos dois anos já ficou muito clara: o ERC-4337 implementou a abstração de conta na camada de aplicação sem modificar o protocolo; o EIP-7702 demonstrou ainda mais que os EOA não são totalmente incapazes de expansão, podendo pelo menos temporariamente adquirir parte das capacidades de contas inteligentes.

Ou seja, a Ethereum não queria evitar a abstração de contas, mas sim abordar o assunto de forma mais gradual e conservadora. A aparição do EIP-8141 significa que esse caminho chegou a um novo ponto: em vez de apenas adicionar uma camada de capacidade de conta inteligente ao redor do sistema existente, ele tenta integrar diretamente a abstração de contas no modelo de transação, permitindo que as contas possuam lógica programável de validação e execução desde o nível do protocolo.

É por isso que o EIP-8141 está voltando a ganhar atenção hoje. Por um lado, a experiência de carteiras de nível superior já está se aproximando cada vez mais da abstração de conta nativa, e o nível de protocolo certamente precisará acompanhar; por outro lado, a pressão de longo prazo proveniente da computação quântica está transformando a questão de "se as contas podem alterar flexivelmente os métodos de assinatura" de um tema técnico distante em uma preocupação prática que precisa ser levada a sério.

Em última análise, o EIP-8141 introduz um novo tipo de transação — a Frame Transaction, com o número do tipo de transação 0x06.

Se a lógica básica das transações tradicionais da Ethereum é que uma transação corresponde a uma única chamada, o EIP-8141 busca dividir uma transação em um conjunto de “quadros” que podem ser executados em uma ordem definida por regras, separando assim as três ações anteriormente vinculadas: validação, pagamento e execução.

Cada «quadro» tem três modos de execução:

• VERIFY (quadro de verificação): responsável por verificar se a transação é legítima; executa a lógica de verificação personalizada da conta e, se aprovada, chama o opcode APPROVE recém-introduzido para autorizar a execução e especificar o limite de Gas.
• REMETENTE (enviar quadro): Executa operações reais, como transferências, chamadas de contratos, etc. O endereço do chamador é o próprio remetente da transação.
• DEFAULT (quadro de entrada): usar o endereço de entrada do sistema como chamador, para cenários como implantação de contrato e verificação de Paymaster;

O significado desse mecanismo não é tornar as transações mais complexas, mas sim, pela primeira vez, separar as três ações de "verificação, pagamento e execução" das ações da conta e delegá-las ao agendamento nativo do protocolo.

No passado, quem validava as transações, quem pagava o Gas e quem executava as operações reais estava basicamente vinculado a uma única ação de conta. Já no design do EIP-8141, esses três aspectos podem ser divididos em diferentes quadros, executados sequencialmente pelo protocolo em uma ordem clara. Por isso, as contas já não dependem mais exclusivamente de uma única chave privada para assinar "como um todo", passando a adotar uma forma mais próxima de entidades executáveis programáveis.

Por exemplo, suponha que você queira usar USDC para pagar a taxa de gas para realizar uma troca. Sob o framework do EIP-8141, esse processo pode ser teoricamente organizado como um fluxo de quadro completo: primeiro, a conta verifica a assinatura e as permissões de execução; em seguida, o pagador ou o Paymaster verifica as condições sob as quais está disposto a arcar com as taxas; depois, é realizado o pagamento da taxa correspondente em ativos; por fim, a operação real de swap é executada.

Assim, o pagamento de Gas e a transação principal podem ser incluídos no mesmo processo atômico, sendo ambos bem-sucedidos ou ambos revertidos.

Para os usuários, a mudança mais intuitiva é que muitas operações que anteriormente exigiam duas ou três etapas separadas, com risco de falha no meio, poderão ser realizadas no futuro como um único processo completo. Por isso, essa atomicidade é uma das chaves para o EIP-8141 resolver o problema da fragmentação da experiência do usuário.

O que isso significa para os usuários de carteiras? Em termos de resultados, as mudanças mais diretas são, pelo menos, quatro camadas:

• O pagamento de gas foi abstraído: ter stablecoins na sua carteira não significa mais que você precise ter ETH adicional para operar; no futuro, o gas será pago de forma mais nativa por DApp, Paymaster ou outros patrocinadores;
• Operações em múltiplos passos foram combinadas: processos que frequentemente exigem múltiplas assinaturas, como “autorizar + swap” e “autorizar + staking”, agora têm a oportunidade de serem empacotados como uma única operação mais completa;
• As regras de segurança da conta foram ativadas: multisignature, recuperação social, limites diários, time lock e rotação de chaves não são mais apenas funções avançadas oferecidas adicionalmente por algum produto de carteira, mas começam a ter a oportunidade de serem construídas sobre lógicas de conta mais nativas;
• O esquema de assinatura não está mais restrito exclusivamente ao caminho ECDSA: isso pela primeira vez torna possível, no nível do protocolo, a migração futura da conta para diferentes sistemas criptográficos, incluindo esquemas de assinatura pós-quantum;

Um ponto facilmente ignorado, mas extremamente importante para os usuários de carteiras é: mesmo que o EIP-8141 seja finalmente implementado, o sistema de contas existente não será totalmente substituído.

Mesmo que você esteja usando uma carteira Web3 existente, como imToken, não é necessário migrar, pois é compatível com versões anteriores; seu endereço EOA atual pode continuar sendo usado, basta escolher a opção "atualizar" a lógica de verificação da conta no momento apropriado.

Mas, por outro lado, justamente por ter sido modificado profundamente, ele não se tornou diretamente a principal funcionalidade do Hegotá na discussão mais recente. No entanto, de acordo com o processo de EIP champion de 2026, o significado de CFI (Considered for Inclusion) não é uma rejeição, mas sim o ingresso em uma fase de consideração séria, ainda sem decisão final sobre o lançamento.

Em outras palavras, os desenvolvedores principais não rejeitam a direção do EIP-8141, mas, ao reconhecer seu valor, também consideram que ele ainda é muito “pesado” no momento.

Apesar de a abstração de conta nativa não poder ser impulsionada gradualmente por poucas carteiras, infraestrutura e aplicações, como o ERC-4337, uma vez que entre no nível do protocolo, significa que todos os clientes de camada de execução devem implementar, testar e coordenar seriamente, o que naturalmente eleva a barreira de adoção e faz com que os desenvolvedores principais sejam mais conservadores no planejamento de forks.

E o que acontecerá a seguir? Pode ser dividido em duas linhas:

• EIP-8141, ao estar em estado CFI, indica que ainda está sendo avaliado continuamente; o autor da proposta continuará preenchendo os detalhes cruciais sobre segurança do pool de transações, regras de validação e implementação de clientes, e as próximas reuniões do ACD também reavaliarão se ela possui condições para avançar ainda mais;
• Se essas incertezas puderem ser continuamente reduzidas, haverá oportunidade de avançar para uma fase de inclusão mais substancial nas atualizações futuras; se não puderem, também é totalmente possível que sejam adiadas para ciclos de atualização mais tardios;

Falando objetivamente, o EIP-8141 não é o único proposal de abstração de conta nativa, nem tampouco é um esquema de assinatura pós-quantum pronto, incapaz de resolver diretamente os problemas da computação quântica; mas sua importância reside no fato de que, pela primeira vez, oferece uma saída ao nível do protocolo para as contas se libertarem do caminho único do ECDSA.

Do ponto de vista desta perspectiva, o verdadeiro valor do EIP-8141 não reside em ser a única resposta correta, mas em colocar pela primeira vez, de forma completa, a questão de "como deveria ser o fim último da abstração de contas nativas" sobre a mesa de discussão do protocolo Ethereum.

Não é a única solução, mas é certamente uma das mais ambiciosas e mais próximas do limite da imaginação de um "AA nativo completo" atualmente.

Independentemente de o EIP-8141 conseguir ou não acompanhar o Hegotá, essa discussão já demonstrou, pelo menos, uma coisa:

Ethereum não ficou parado esperando problemas se agravarem, mas sim avançando passo a passo para preparar o caminho para a próxima geração de sistemas de contas.