Desenvolvedores da Ethereum recentemente divulgaram novos avanços no design do EIP-8141. A proposta tenta implementar certas funcionalidades de transação como chamadas de contratos programáveis, chamadas de "frames", em vez de modificar o formato de embalagem da transação da Ethereum toda vez que uma nova funcionalidade é adicionada.
A funcionalidade de negociação foi alterada para chamada programável
As funcionalidades abrangidas por esta abordagem incluem o vencimento da transação, assinatura agregada, raiz Merkle relacionada ao pool de privacidade e verificação de asserções após a execução da transação. Os desenvolvedores consideram que, se essa interface for suficientemente genérica, quando a Ethereum introduzir novos métodos de validação no futuro, carteiras, navegadores, dispositivos de assinatura e Layer 2 não precisarão adaptar novos envelopes de transação a cada nova implementação.
O rascunho do EIP-8141 define uma Frame Transaction como uma sequência de chamadas de contrato. Diferentes frames podem ser responsáveis por validar condições de transação, aprovar pagamentos de gas ou executar operações do usuário.
O rascunho atual lista três modos: DEFAULT, VERIFY e SENDER. O frame VERIFY é usado para verificar se uma determinada condição foi atendida, enquanto o frame SENDER representa a execução de uma operação em nome do remetente da transação. Vários frames também podem ser agrupados em um lote atômico, que ou bem-sucedido por completo, ou totalmente revertido.
Reduzir os custos de coordenação de carteiras e infraestrutura
A visão central do desenvolvedor Derek Chiang é que novas funcionalidades futuras não precisam necessariamente de um novo conjunto de encapsulamentos de negociação. Através de novos alvos de frame e padrões de chamada, é possível expandir a capacidade mantendo a estabilidade da estrutura básica.
Cada alteração no pacote de transações da Ethereum afeta não apenas os clientes de execução. Carteiras, Layer 2, exploradores de blocos, dispositivos de assinatura, bibliotecas de software e diversos provedores de infraestrutura precisam compreender e suportar o novo formato.
Chiang afirmou que as atualizações da Ethereum ocorrem aproximadamente a cada nove meses, e alterações frequentes no empacotamento de transações acarretariam altos custos de coordenação. Em contraste, se o formato frame pudesse se tornar uma interface mais estável, novos métodos de validação poderiam ser mais facilmente delegados a contratos ou componentes específicos do protocolo.
No entanto, isso não significa que todas as funcionalidades futuras possam contornar atualizações de rede. O EIP-8141 ainda modificará as regras de consenso da Ethereum e exigirá implementação nos clientes. Se envolver novos opcodes, contratos pré-compilados ou regras de gas, ainda poderá ser necessário um hard fork.
EIP-8130 e direção da validação paralela
Os desenvolvedores também reconhecem que, com o aumento do nível de abstração de transações, torna-se mais difícil para carteiras e ordenadores analisarem as transações antes da execução. Para isso, a equipe está investigando como integrar o EIP-8141 com outro rascunho de abstração de conta, o EIP-8130.
EIP-8130 propõe uma estrutura de keystore na cadeia, permitindo que contas registrem previamente participantes e contratos de autenticação, e especifiquem claramente o método de autenticação nas transações. Assim, os nós podem determinar qual processo de validação é necessário antes de executar qualquer código de carteira. Para Layer 2, isso ajuda a limitar os métodos de autenticação a um conjunto com custos mais previsíveis.
Vitalik Buterin também explicou a direção relacionada em outra postagem. Ele dividiu as transações em duas partes: "ações" e "condições de dependência". A primeira é responsável por alterar o estado do Ethereum, enquanto a segunda inclui pré-requisitos como assinaturas, provas Merkle ou provas de conhecimento zero. Se essas dependências forem independentes entre si, futuramente poderá haver verificação paralela, reduzindo o custo de processamento de algumas transações.
Listado no Hegotá, mas horário de ativação ainda não definido
O EIP oficial do Hegotá Meta já listou as Frame Transactions como uma das atualizações planejadas, o que significa que seu status avançou em relação ao anterior. No entanto, o EIP-8141 ainda é um rascunho principal, e os detalhes técnicos ainda não foram finalizados.
Os trabalhos ainda a serem realizados incluem: atualizar as especificações, concluir a implementação do cliente de execução, configurar a rede de desenvolvimento e realizar testes de interoperabilidade com carteiras e sistemas de Layer 2. Os desenvolvedores também precisam avaliar os riscos de ataque de negação de serviço ao mempool, pois a verificação programável pode aumentar o custo computacional para filtrar transações inválidas.
Atualmente, os tempos de ativação do Sepolia, Hoodi e da rede principal do Hegotá ainda estão em branco. O EIP-8141 já foi incluído no plano de atualização, mas ainda há um processo de implementação e teste a ser concluído antes da implementação final.