O cofundador do Ethereum, Vitalik Buterin, discutiu o formato de transação proposto EIP-8141 em uma publicação de 5 de setembro de 2026, explicando como ele poderia apoiar uma maior escalabilidade da rede. Buterin disse que a abordagem poderia ajudar o Ethereum a aumentar sua capacidade sem sacrificar a descentralização, ao permitir que partes das transações sejam processadas separadamente e em paralelo.
Pesquisas recentes sobre formatos de transação — incluindo EIP-8141, UTXOs, PBT, nonces com chave e um mempool STARK recursivo — produziram uma distinção mais clara entre ações e dependências de transações, disse Buterin. Uma ação é o efeito que uma transação tem sobre a rede, como uma transferência de Ethereum, enquanto uma dependência é uma condição que deve ser satisfeita para que a transação permaneça válida.
Separação entre ações e dependências
Buterin identificou assinaturas digitais, provas de Merkle para UTXOs, provas ZK-SNARK ou STARK e dados do estado da rede necessários para verificar uma transação como exemplos de dependências.
“As dependências podem ser processadas em paralelo”, explicou Buterin.
As dependências ligadas ao estado da rede poderiam ser analisadas no nível do mempool, particularmente quando uma transação declara antecipadamente quais dados de estado acessará, segundo Buterin. Dependências que não interagem com o estado poderiam potencialmente ser verificadas uma vez no mempool e depois substituídas por uma prova STARK.
Buterin disse que essa abordagem poderia acelerar a execução e, em alguns casos, eliminar a necessidade de processar ou transmitir determinados dados depois que sua correção tiver sido comprovada.
O EIP-8141 propõe um tipo de transação que divide uma transação em uma sequência de chamadas de contrato responsáveis pela validação, pelos pagamentos de gas e pela execução das operações do usuário.
Equilíbrio entre flexibilidade e escalabilidade
Buterin disse que o Ethereum não exigia uma separação tão detalhada das operações de transação em 2015, quando a rede processava relativamente poucas transações e a execução sequencial era suficiente. A estratégia atual de escalabilidade do Ethereum, no entanto, exige que a rede se afaste desse modelo, disse ele.
“O Ethereum é querido por muitos desenvolvedores porque o modelo de execução e estado é tão dinâmico e flexível. Mas dinâmico e flexível não é favorável à escalabilidade”, escreveu Buterin.
Mais de 90% da atividade do Ethereum por volume não exige esse grau de dinamismo, segundo Buterin. Ele disse que o protocolo deveria exigir que contratos, contas e transações definam mais claramente quais operações são dinâmicas e quais podem ser analisadas estaticamente.
Taxas de gas mais baixas poderiam então ser aplicadas a operações analisáveis estaticamente, criando um incentivo econômico para usar estruturas de transação mais fáceis de escalar, disse Buterin.
Ele descreveu a abordagem como uma combinação de características do Ethereum inicial com um modelo mais próximo ao Bitcoin, que, segundo ele, utilizou efetivamente o que chama de abstração de contas desde o início. Novos tipos de estado, nonces com chave e um mempool STARK recursivo devem contribuir para reduzir a carga da rede e melhorar a escalabilidade, segundo Buterin.
EIP-8141 como base para mudanças adicionais
Buterin disse que um formato universal de transação poderia fornecer uma interface natural para futuras generalizações do protocolo e vinculou esse papel diretamente ao EIP-8141.
“Portanto, nesse sentido, a 8141 bem executada não é apenas a culminação de 10 anos de trabalho em abstração de contas, mas também a preparação para os próximos anos de hiperescala responsável e favorável à descentralização”, disse ele.
O EIP-8141 também oferece suporte a métodos alternativos de pagamento de taxas sem intermediários centralizados e separaria as contas de chaves ECDSA específicas. Buterin disse que isso estabeleceria as bases para substituir essas chaves e adotar novos esquemas de assinatura.
Segundo Buterin, a proposta poderia ajudar o Ethereum a migrar gradualmente de um modelo universal, mas difícil de escalar, para uma arquitetura que prioriza operações mais simples e mais analisáveis estaticamente em custo e escalabilidade.
Fonte: HODL Press
