O desenvolvedor de Ethereum Derek Chiang disse em 7 de setembro que os autores do EIP-8141 encontraram uma maneira de expressar vários recursos de transação como chamadas de contrato programáveis, em vez de adicioná-los separadamente ao envelope de transação do Ethereum.
Resumo
- Desenvolvedores de Ethereum dizem que o EIP-8141 pode expressar recursos de transação por meio de chamadas de contrato conhecidas como frames programáveis.
- Os frames podem suportar expiração, agregação de assinaturas, provas de privacidade e asserções pós-transação sem novos campos de envelope.
- O EIP-8141 está programado para Hegotá, embora sua especificação permaneça em rascunho e as datas de ativação ainda não tenham sido definidas.
- Os desenvolvedores estão coordenando o EIP-8141 com o EIP-8130 para preservar a estrutura e melhorar a legibilidade das transações para a infraestrutura.
- Vitalik Buterin argumenta que separar ações e dependências de transação poderia permitir validação paralela e custos mais baixos.
Chiang, coautor do EIP-8141 e colaborador da Ethlabs, descreveu o desenvolvimento como um "avanço de design" em um post discutindo o trabalho recente dos autores da proposta. A abordagem trata expiração de transação, assinaturas agregadas, raízes Merkle de pool de privacidade e asserções pós-transação como chamadas chamadas de "frames".
A especificação de rascunho oficial define uma Transação Frame como uma sequência de chamadas de contrato. Diferentes frames podem validar uma transação, aprovar seu pagamento de gás ou executar operações do usuário. A proposta atualmente fornece três modos: DEFAULT, VERIFY e SENDER.
Um frame VERIFY pode verificar se uma condição necessária é satisfeita. Um frame SENDER executa uma operação a partir da conta identificada como remetente da transação. Os frames também podem ser agrupados em lotes atômicos, o que significa que cada operação em um lote é bem-sucedida em conjunto ou todo o grupo é revertido.
A proposta ainda define um envelope de transação base contendo campos como identificador de cadeia, nonce, remetente, taxas, assinaturas e lista de frames. O ponto de Chiang é mais restrito: os desenvolvedores podem ser capazes de introduzir mais funcionalidades por meio de novos alvos de frame e padrões de chamada sem criar outro formato de envelope para cada recurso.
Um envelope estável poderia reduzir o trabalho de coordenação
Alterar o envelope de transação do Ethereum afeta mais do que clientes de execução. Carteiras, redes Layer 2, exploradores de blocos, dispositivos de assinatura, bibliotecas de software e provedores de infraestrutura devem todos entender o novo formato.
Chiang disse que as atualizações do Ethereum ocorrem aproximadamente a cada nove meses, tornando alterações repetidas de envelope lentas e com muita coordenação. Um formato de frame suficientemente geral poderia servir como uma interface estável enquanto contratos ou componentes de protocolo designados fornecem novos métodos de validação.
Isso não significa que funcionalidades futuras nunca exigiriam uma atualização de rede. O próprio EIP-8141 altera as regras de consenso do Ethereum e requer implementação no cliente. Novos opcodes, precompiles ou regras de gás também poderiam exigir hard forks. O benefício proposto é que os desenvolvedores não precisariam necessariamente redesenhar o contêiner de transação a cada vez.
A especificação do EIP-8141 lista a abstração de conta nativa entre seus principais objetivos. Ela poderia suportar rotação de chaves, sistemas de assinatura alternativos, pagamentos de gás patrocinados e agrupamento de transações. Também visa reduzir a dependência das contas Ethereum do sistema de assinatura secp256k1 usado por contas de propriedade externa convencionais.
Como o crypto.news relatou em sua cobertura da proposta de redesenho de transações do Ethereum de Vitalik Buterin, a validação programável poderia eventualmente ajudar o Ethereum a adotar novos sistemas de autenticação sem substituir um esquema de assinatura fixo por outro.
EIP-8130 poderia tornar os frames mais fáceis de inspecionar
Chiang também reconheceu uma compensação. Transações altamente abstratas podem se tornar difíceis para carteiras, sequenciadores e outras infraestruturas analisarem antes da execução. Um sequenciador de Layer 2, por exemplo, pode querer aceitar apenas métodos de assinatura específicos porque seus custos computacionais são previsíveis.
Os desenvolvedores estão, portanto, explorando como os frames poderiam funcionar com o EIP-8130, outra proposta de abstração de conta em rascunho. O EIP-8130 cria um keystore onchain onde as contas registram atores e contratos autenticadores. As transações identificam explicitamente seu método de autenticação.
Essa estrutura permite que um nó determine qual processo de validação uma transação exige antes de executar código arbitrário de carteira. Sob o perfil de Layer 2 proposto pelo EIP-8130, uma cadeia poderia restringir seu caminho de transação a um conjunto canônico de autenticadores de custo fixo, deixando outros métodos de autenticação disponíveis por meio da execução EVM comum.
Chiang disse que o EIP-8130 poderia impor estruturas definidas sobre os frames do EIP-8141. A colaboração poderia preservar a flexibilidade dos frames enquanto dá às carteiras e cadeias de alta produtividade um formato de transação mais legível. O design combinado não foi finalizado, e ambas as especificações permanecem abertas a revisões.
A cobertura anterior do crypto.news examinou a competição entre EIP-8141 e EIP-8130 durante o processo inicial de escopo do Hegotá. Os comentários mais recentes sugerem que os desenvolvedores agora procuram elementos compatíveis em vez de tratar as propostas apenas como alternativas mutuamente exclusivas.
Buterin conecta frames com validação paralela
Vitalik Buterin expandiu a direção técnica em uma postagem separada, distinguindo entre "ações" e "dependências" de transação. Uma ação altera o estado do Ethereum, como transferir ETH. Uma dependência é uma condição que deve ser satisfeita, como uma assinatura, prova de Merkle ou prova de conhecimento zero.
Buterin argumentou que dependências independentes poderiam ser verificadas em paralelo. Condições que não acessam o estado do Ethereum poderiam potencialmente ser processadas uma vez pelo mempool em vez de serem repetidas durante a execução. Múltiplas verificações poderiam eventualmente ser representadas por uma prova STARK recursiva, embora isso permaneça uma direção de pesquisa em vez de um recurso aprovado.
A distinção também poderia ajudar os clientes a separar transações previsíveis de operações que exigem o ambiente de execução dinâmico completo do Ethereum. Buterin disse que atividades mais estaticamente analisáveis poderiam receber custos de gás mais baixos e escalar ainda mais. Nenhum cronograma de taxas foi aprovado.
O modelo de frame fornece uma interface potencial para essa abordagem porque validação e execução aparecem como chamadas identificáveis. O Ethereum manteria execução de contrato flexível enquanto permitiria que transações mais simples declarassem mais informações sobre seus requisitos.
EIP-8141 está agendado, mas as datas permanecem em aberto
O Meta EIP do Hegotá oficial agora lista Frame Transactions e FOCIL como agendados para inclusão na atualização Hegotá do Ethereum. Isso representa um status mais forte do que a consideração anterior, mas não congela o design técnico atual do EIP-8141.
O EIP-8141 permanece marcado como uma proposta Core em rascunho. Seus autores podem revisar os modos de frame, manipulação de assinaturas, contabilidade de gás e o relacionamento com o EIP-8130 conforme o trabalho de implementação continua. O documento do Hegotá também deixa os campos de ativação da Sepolia, Hoodi e mainnet em branco.
Os próximos passos mensuráveis incluem especificações atualizadas, implementações de clientes de execução, redes de desenvolvimento e testes de interoperabilidade com carteiras e sistemas de Layer 2. Os desenvolvedores também devem examinar os riscos de negação de serviço no mempool porque a validação programável pode tornar a rejeição de transações inválidas mais cara computacionalmente.
Os testes determinarão se a combinação proposta de estruturas flexíveis e autenticadores estruturados pode atender às necessidades da camada base do Ethereum e das cadeias EVM mais rápidas. Até que os parâmetros de ativação sejam publicados, o EIP-8141 permanece uma parte agendada, mas inacabada, do Hegotá.
