$ETH
A disputa pela abstração nativa de contas do Ethereum (AA): 8130 é dividido em três EIPs
Como implementar a “abstração nativa de contas (native Account Abstraction)” do Ethereum? A comunidade de desenvolvedores discute isso há algum tempo; agora surgiu uma solução de compromisso que aproxima as duas partes. De acordo com um tópico no fórum da Ethereum Magicians, a proposta central original, o EIP-8130, está sendo reestruturada e dividida em três novos EIPs “componíveis” — 8398, 8399 e 8400.
O que é a AA nativa? Por que 8130 e Frame disputam
O objetivo da abstração de contas (AA) é tornar as “contas de contratos inteligentes” um cidadão de primeira classe na rede Ethereum, permitindo que definam a lógica de verificação, ofereçam recuperação social, possibilitem pagamento de gas por terceiros, transações em lote etc. Atualmente, a abordagem mais comum é usar o bundler off-chain do ERC-4337, enquanto a “AA nativa” pretende ter suporte diretamente no protocolo.
A disputa é sobre “como dar suporte”: uma parte defende a rota do EIP-8130, a chamada “keystore”: usar uma lista branca de verificadores confiáveis para gerenciar a verificação de assinaturas. A vantagem é que o custo de verificação é previsível e limitado (o que favorece especialmente a Layer 2) e que já vem embutido com padrões de conta que incluem policy e session keys, focando em simplicidade e menos fragmentação.
A outra parte é a dos Frame Transactions (EIP-8141): permite que, em qualquer etapa de uma transação, se execute uma “verificação não estruturada” com qualquer código EVM, viabilizando novas possibilidades como “uma conta sem ETH conseguir obter fundos no meio da execução”. Em troca, oferece a maior flexibilidade e espaço para inovação sem hard fork, mas também traz maior risco de fragmentação e, em alguns modos avançados, requer mempool privado.
A comparação anterior de Derek Chiang, da Ethlabs, no artigo〈8130 vs Frame Transactions〉, apontou exatamente o trade-off entre “simples e controlável” e “extremamente flexível”.
Solução de compromisso: dividir em 8398, 8399 e 8400
Uma “abstração nativa de contas componível”, proposta por Pedro UID em 27 de agosto, transforma o compromisso em três EIPs componíveis. Nela, as funções são separadas em três camadas de EIPs centrais (correspondentes às mesmas PRs do GitHub de #12248 no mesmo dia):
- EIP-8398 “Keystore de conta portátil”: define participantes (atores), verificadores, configurações de conta e a criação e portabilidade entre cadeias;
- EIP-8399: construído sobre o 8398, introduz o tipo de transação 0x79 de AA nativa e adiciona transações em lote, patrocínio de transações (sponsorship) e nonces ordenados;
- EIP-8400: requer os dois anteriores, além de policy, travamento (lock) da conta e “transações sem nonce” usando o mesmo envelope de transação.
O EIP-8130 original permanece inalterado, sendo reestruturado como a base dessas três especificações complementares.
Significado: modularidade para cada cadeia adotar sob demanda, mas ainda na fase de proposta
Ao dividir um grande projeto em três módulos componíveis, o maior ganho é a flexibilidade: diferentes cadeias ou equipes podem adotar apenas o nível de que precisam, sem serem obrigadas a ter tudo ou a ter nada. Uma interpretação presente na comunidade é que a rota do Frame, que enfatiza a flexibilidade, acaba vencendo em linhas gerais, e as ideias do keystore da visão de L2 foram incorporadas — em outras palavras, nenhum lado “perde completamente”.
Ainda assim, vale lembrar: tudo isso ainda está em fase de proposta de EIP e discussão na comunidade, não se tornando a solução final do Ethereum. O próximo passo dependerá de como os desenvolvedores principais vão convergir essas três especificações para uma rota formal de upgrade.
Este artigo “A disputa pela abstração nativa de contas do Ethereum (AA): 8130 é dividido em três EIPs” apareceu pela primeira vez em .
A disputa pela abstração nativa de contas do Ethereum (AA): 8130 é dividido em três EIPs
Como implementar a “abstração nativa de contas (native Account Abstraction)” do Ethereum? A comunidade de desenvolvedores discute isso há algum tempo; agora surgiu uma solução de compromisso que aproxima as duas partes. De acordo com um tópico no fórum da Ethereum Magicians, a proposta central original, o EIP-8130, está sendo reestruturada e dividida em três novos EIPs “componíveis” — 8398, 8399 e 8400.
O que é a AA nativa? Por que 8130 e Frame disputam
O objetivo da abstração de contas (AA) é tornar as “contas de contratos inteligentes” um cidadão de primeira classe na rede Ethereum, permitindo que definam a lógica de verificação, ofereçam recuperação social, possibilitem pagamento de gas por terceiros, transações em lote etc. Atualmente, a abordagem mais comum é usar o bundler off-chain do ERC-4337, enquanto a “AA nativa” pretende ter suporte diretamente no protocolo.
A disputa é sobre “como dar suporte”: uma parte defende a rota do EIP-8130, a chamada “keystore”: usar uma lista branca de verificadores confiáveis para gerenciar a verificação de assinaturas. A vantagem é que o custo de verificação é previsível e limitado (o que favorece especialmente a Layer 2) e que já vem embutido com padrões de conta que incluem policy e session keys, focando em simplicidade e menos fragmentação.
A outra parte é a dos Frame Transactions (EIP-8141): permite que, em qualquer etapa de uma transação, se execute uma “verificação não estruturada” com qualquer código EVM, viabilizando novas possibilidades como “uma conta sem ETH conseguir obter fundos no meio da execução”. Em troca, oferece a maior flexibilidade e espaço para inovação sem hard fork, mas também traz maior risco de fragmentação e, em alguns modos avançados, requer mempool privado.
A comparação anterior de Derek Chiang, da Ethlabs, no artigo〈8130 vs Frame Transactions〉, apontou exatamente o trade-off entre “simples e controlável” e “extremamente flexível”.
Solução de compromisso: dividir em 8398, 8399 e 8400
Uma “abstração nativa de contas componível”, proposta por Pedro UID em 27 de agosto, transforma o compromisso em três EIPs componíveis. Nela, as funções são separadas em três camadas de EIPs centrais (correspondentes às mesmas PRs do GitHub de #12248 no mesmo dia):
- EIP-8398 “Keystore de conta portátil”: define participantes (atores), verificadores, configurações de conta e a criação e portabilidade entre cadeias;
- EIP-8399: construído sobre o 8398, introduz o tipo de transação 0x79 de AA nativa e adiciona transações em lote, patrocínio de transações (sponsorship) e nonces ordenados;
- EIP-8400: requer os dois anteriores, além de policy, travamento (lock) da conta e “transações sem nonce” usando o mesmo envelope de transação.
O EIP-8130 original permanece inalterado, sendo reestruturado como a base dessas três especificações complementares.
Significado: modularidade para cada cadeia adotar sob demanda, mas ainda na fase de proposta
Ao dividir um grande projeto em três módulos componíveis, o maior ganho é a flexibilidade: diferentes cadeias ou equipes podem adotar apenas o nível de que precisam, sem serem obrigadas a ter tudo ou a ter nada. Uma interpretação presente na comunidade é que a rota do Frame, que enfatiza a flexibilidade, acaba vencendo em linhas gerais, e as ideias do keystore da visão de L2 foram incorporadas — em outras palavras, nenhum lado “perde completamente”.
Ainda assim, vale lembrar: tudo isso ainda está em fase de proposta de EIP e discussão na comunidade, não se tornando a solução final do Ethereum. O próximo passo dependerá de como os desenvolvedores principais vão convergir essas três especificações para uma rota formal de upgrade.
Este artigo “A disputa pela abstração nativa de contas do Ethereum (AA): 8130 é dividido em três EIPs” apareceu pela primeira vez em .
