Os desenvolvedores do Ethereum e da Base encerraram os trabalhos em um padrão comum de abstração de contas após o fracasso dos esforços para conciliar EIP-8141 e EIP-8130, deixando as duas redes seguirem designs de transação separados.
O desenvolvedor da Ethlabs, Derek Chiang, disse na segunda-feira que os autores das duas propostas pararam de trabalhar em uma especificação compartilhada na semana passada, após constatarem que as opções técnicas disponíveis exigiriam que Ethereum ou Base comprometessem seus requisitos principais.
Ambas as propostas visam simplificar a forma como os usuários interagem com as carteiras de criptomoedas, incluindo permitir transações sem que os usuários precisem ter ETH para gás primeiro e suportar métodos de autenticação como chaves de acesso de telefone. As equipes estavam explorando se um único design poderia servir tanto para a Camada 1 do Ethereum quanto para a Camada 2 da Base.
“Embora tenhamos identificado várias soluções técnicas, todas elas exigiam que um lado ou outro comprometesse pelo menos um pouco de seus objetivos centrais”, disse Chiang. “Então, seguimos caminhos separados, colocando o ônus nas carteiras para lidar com a fragmentação que se segue.”
Os desenvolvedores do Ethereum estão priorizando a resistência à censura, privacidade e segurança, enquanto a Base está focando em escala, personalização e conformidade, de acordo com Chiang. As diferenças acabaram impedindo que as equipes chegassem a um único formato de transação.
A decisão deixa os desenvolvedores de carteiras diante da possibilidade de suportar dois formatos de transação nativos se EIP-8141 e EIP-8130 ambos chegarem à produção.
Chiang disse que as carteiras ainda poderiam oferecer aos usuários uma experiência consistente, apesar das diferenças técnicas entre as redes, dependendo de como os desenvolvedores lidam com os padrões separados.
“Se eles executarem bem, e se a comunidade de carteiras conseguir superar a fragmentação, podemos muito bem acabar com a melhor UX possível para os usuários finais”, disse ele.
O resultado muda a direção que os desenvolvedores estavam discutindo apenas dias antes. Em 7 de setembro, crypto.news relatou anteriormente que os desenvolvedores da EIP-8141 estavam explorando a compatibilidade com a EIP-8130 enquanto trabalhavam em maneiras de manter as transações programáveis, ao mesmo tempo em que tornavam seus requisitos de autenticação mais fáceis de inspecionar para os provedores de infraestrutura.
Nessa fase, Chiang disse que a EIP-8130 poderia fornecer estruturas definidas em torno dos frames da EIP-8141. O arranjo proposto visava preservar a natureza programável dos frames, ao mesmo tempo em que fornecia às carteiras e redes de alto throughput um formato de transação mais claro.
A EIP-8130 usa um keystore on-chain onde as contas podem registrar atores aprovados e contratos autenticadores. As transações identificam o método de autenticação que usam, permitindo que uma rede determine o processo de validação necessário antes de executar o código da carteira.
A EIP-8141 segue um caminho diferente, estruturando as transações como chamadas de contrato programáveis, chamadas frames. Os frames podem executar diferentes funções dentro da mesma transação, incluindo validação, aprovação de gás e execução.
As equipes agora abandonaram o esforço para transformar essas abordagens em um único padrão.
O Ethereum continua com a EIP-8141, ou Transações de Frame, como parte de sua atualização planejada Hegotá.
O cluster de Protocolo da Ethereum Foundation colocou a proposta em sua categoria de “implementação obrigatória” no início deste mês, enquanto o material de origem afirma que a proposta visa tornar a abstração de contas nativa do Ethereum e melhorar a segurança e a prontidão pós-quântica.
As Transações de Frame dividem uma transação em uma sequência de frames programáveis. Um frame pode validar o remetente, outro pode autorizar a conta responsável pelo gás, e frames subsequentes podem executar as ações solicitadas pelo usuário.
O modelo permitiria que a conta que inicia uma ação e a conta que paga por ela fossem diferentes.
Os desenvolvedores do Ethereum já haviam agendado a EIP-8141 para Hegotá até 7 de setembro. Os desenvolvedores principais moveram a proposta de Considerada para Inclusão para Agendada para Inclusão durante a chamada de execução de Todos os Desenvolvedores Principais de 27 de agosto, dando às Transações de Frame uma posição formal na atualização planejada para 2027, enquanto sua especificação permaneceu em forma de rascunho.
Sob o sistema proposto, um aplicativo poderia cobrir a taxa de transação de um usuário ou providenciar para que o usuário pagasse por meio de outro ativo, enquanto os validadores do Ethereum continuam recebendo a taxa de rede em ETH.
A estrutura poderia remover um requisito comum de carteira, segundo o qual usuários que possuem stablecoins ou outros tokens ainda precisam de ETH antes de poderem fazer uma transação.
Os frames também podem ser usados para o agrupamento de transações (transaction batching). Ações relacionadas poderiam ser agrupadas para que todas sejam bem-sucedidas juntas ou sejam revertidas quando uma falhar.
Uma troca de tokens, por exemplo, pode atualmente exigir uma aprovação separada que permite que um aplicativo gaste tokens antes que a própria troca seja executada. As Transações de Frame poderiam colocar ações relacionadas dentro da mesma estrutura de transação programável.
A EIP-8141 foi projetada para mover mais lógica de validação de conta para código programável, em vez de exigir que as contas convencionais do Ethereum dependam de um processo de autenticação fixo.
A proposta descreve seu estado final como aquele em que “uma conta simplesmente se torna um endereço com código”.
Vitalik Buterin, coautor da EIP-8141, descreveu a proposta em fevereiro como um “ônibus que engloba e resolve todos os problemas restantes que a AA (Abstração de Contas) pretendia abordar”.
Em 5 de setembro, Buterin disse que a proposta havia feito “muito progresso importante” nos meses anteriores e estava chegando “próxima do ideal”.
Os desenvolvedores descobriram posteriormente que várias funcionalidades de transação poderiam ser expressas através de frames programáveis da EIP-8141, em vez de expandir repetidamente o envelope de transações do Ethereum.
O relatório de 7 de setembro do crypto.news disse que a abordagem poderia lidar com a expiração de transações, agregação de assinaturas, provas de privacidade e asserções pós-transação como chamadas de contrato programáveis. As Transações de Frame ainda exigiriam mudanças nas regras de consenso do Ethereum, mas as funções individuais poderiam ser construídas através de alvos de frame e padrões de chamada.
A validação programável poderia dar às contas mais controle sobre a autenticação. A EIP-8141 foi projetada para suportar recursos como sistemas de assinatura alternativos, pagamentos de gás patrocinados, agrupamento de transações (transaction batching) e rotação de chaves.
A mesma arquitetura poderia ajudar as contas Ethereum a se afastarem da dependência do sistema de assinatura usado por contas convencionais de propriedade externa. Um usuário poderia potencialmente mudar o método de autenticação que controla uma conta sem transferir os ativos para um novo endereço.
Pesquisadores do Ethereum estavam considerando as Transações de Frame para Hegotá antes que a proposta fosse formalmente agendada. Em agosto, os desenvolvedores estavam comparando a EIP-8141 com a EIP-8130 como abordagens concorrentes para a abstração de contas nativa, enquanto restringiam o escopo da atualização de 2027.
Naquela época, as propostas faziam parte de um processo de seleção maior para Hegotá, abrangendo resistência à censura, privacidade, precificação de gás, economia de validadores e escalonamento da Camada 1.
Pesquisadores do Ethereum haviam examinado separadamente como as Transações de Frame poderiam suportar aplicações focadas em privacidade. Uma proposta de agosto discutiu pools de privacidade autofinanciados nos quais pagamentos de taxas programáveis poderiam permitir que um pool de privacidade cobrisse seu próprio gás em vez de depender de um relayer externo.
Esse trabalho combinou as Transações de Frame com outras mudanças propostas, incluindo Nonces Chaveados (Keyed Nonces), Raízes Recentes (Recent Roots) e Asserções de Transação (Transaction Assertions). A proposta de pool de privacidade permaneceu como um pacote preferido de pesquisadores, em vez de uma decisão final dos desenvolvedores principais do Ethereum na época.
A EIP-8130 da Base agora prosseguirá separadamente da proposta de Transações de Frame do Ethereum.
O design criado pela Base combina um novo tipo de transação com um “Keystore” on-chain que registra signatários e autenticadores aprovados para uma conta. Ele visa suportar autenticação personalizada, agrupamento de chamadas (call batching) e patrocínio de gás.
Embora as duas propostas compartilhem vários objetivos de abstração de contas, suas estruturas técnicas dão às suas respectivas redes diferentes níveis de controle sobre como as transações são autenticadas e processadas.
Antes da separação das equipes, os desenvolvedores do Ethereum estavam tentando determinar se o sistema de autenticação estruturado da EIP-8130 poderia ser combinado com os frames programáveis da EIP-8141 sem forçar as redes da Camada 1 ou da Camada 2 a abrir mão de suas propriedades preferenciais.
A Ethlabs havia anteriormente colocado as Transações de Frame entre suas principais prioridades para a atualização Hegotá, citando a abstração de contas nativa ao lado da resistência à censura, blocos mais rápidos e escalabilidade contínua da Camada 1.
Com o esforço conjunto agora encerrado, a EIP-8141 permanece como a rota de abstração de contas nativa planejada para o Ethereum para Hegotá, enquanto a Base continuará desenvolvendo a EIP-8130 em torno de seu tipo de transação separado e keystore on-chain.
ETH