O cofundador do Ethereum, Vitalik Buterin, delineou um modelo de transação de longo prazo em 6 de setembro que poderia permitir que a rede processasse parte do trabalho de validação em paralelo.
Sua proposta separa os efeitos produzidos pelas transações das condições que devem ser satisfeitas antes que esses efeitos possam ocorrer.
Buterin descreveu os dois componentes como “ações” e “dependências” em uma postagem detalhada. As ações alteram o estado do Ethereum, como transferir ETH ou chamar um contrato. As dependências cobrem as informações necessárias para estabelecer que uma transação é válida.
Uma assinatura digital é um exemplo de dependência. Outros exemplos incluem provas Merkle mostrando que existe uma saída não gasta, provas de conhecimento zero e condições de estado que devem permanecer verdadeiras quando uma transação entra em um bloco.
Buterin argumentou que tornar essa distinção explícita poderia ajudar o Ethereum a escalar sem abandonar seu ambiente de execução flexível. No entanto, a proposta continua sendo parte da pesquisa de protocolo em andamento. Os desenvolvedores do Ethereum não aprovaram o design completo para implantação.
As transações do Ethereum atualmente combinam autorização, pagamento de taxas e execução dentro de um fluxo de processamento comum. Os nós verificam se uma transação está devidamente assinada, se o remetente pode pagar por ela e se suas instruções são executadas com sucesso.
Algumas dessas verificações não dependem das mudanças finais de estado da transação. Buterin disse que tais dependências poderiam ser processadas separadamente e, em muitos casos, simultaneamente.
Por exemplo, um validador pode precisar confirmar uma assinatura antes de aceitar uma transação. Essa verificação não precisa necessariamente esperar por assinaturas não relacionadas anexadas a outras transações. Se múltiplas verificações independentes forem conhecidas antecipadamente, os clientes podem distribuir o trabalho entre os recursos de processamento disponíveis.
As verificações dependentes de estado exigem maior cuidado. Uma condição ligada a um saldo de conta ou slot de armazenamento pode se tornar inválida se uma transação anterior alterar o mesmo estado. Buterin disse que as mempools poderiam raciocinar sobre essas condições de forma mais eficaz quando as transações declaram quais partes do estado elas acessam.
A abordagem recompensaria transações previsíveis. Operações que especificam suas dependências claramente poderiam receber custos de gas mais baixos porque os clientes poderiam verificá-las de forma mais eficiente. Transações que exigem chamadas dinâmicas e acesso imprevisível ao estado continuariam sendo possíveis, mas poderiam custar mais.
Buterin estimou que mais de 90% da atividade do Ethereum por volume não requer o nível total de flexibilidade dinâmica da rede. Esse número é sua avaliação, e não uma medição de rede publicada na postagem. O argumento mais amplo é que transferências comuns e interações de contrato rotineiras poderiam usar formatos mais restritivos sem limitar aplicações especializadas.
O modelo proposto preservaria o sistema de contas flexível do Ethereum para as transações que precisam dele. Atividades mais previsíveis poderiam usar estruturas analisáveis estaticamente, semelhantes a partes do modelo de transação do Bitcoin.
O Bitcoin usa um modelo de saída de transação não gasta (UTXO) no qual uma transação identifica as saídas que pretende gastar. O Ethereum normalmente usa contas com saldos, nonces e armazenamento de contrato programável. Buterin não está propondo que o Ethereum substitua seu modelo de conta pela arquitetura do Bitcoin. Ele descreveu um espectro combinando ideias de ambos os sistemas.
A EIP-8141 é uma Proposta de Melhoria do Ethereum preliminar para um novo tipo de transação conhecido como Transação de Frame. Ela divide uma transação em frames de chamada de contrato que podem validar a autoridade, aprovar o pagamento de gas e realizar operações do usuário.
A proposta oficial diz que a validade da transação e o pagamento de taxas não dependeriam mais exclusivamente de uma assinatura padrão anexada à transação externa. O código da conta poderia, em vez disso, definir as regras necessárias de autorização e pagamento.
As Transações de Frame poderiam suportar taxas patrocinadas, pagamentos em tokens diferentes de ETH, rotação de chaves e agrupamento de transações. Elas também poderiam permitir que contas de propriedade externa (EOAs) recebessem recursos de abstração de conta sem depender da mesma implantação de contrato em todas as redes compatíveis.
Sob a estrutura proposta, os frames de verificação determinariam se o remetente autorizou a transação. Frames separados poderiam estabelecer quem paga as taxas e, em seguida, executar as operações solicitadas.
Essa estrutura se alinha com a divisão de Buterin entre dependências e ações. Os frames de verificação lidam com as condições que devem ser satisfeitas. Os frames do remetente lidam com as operações que alteram o estado.
O formato também poderia melhorar a interoperabilidade entre as redes da Máquina Virtual Ethereum. Diferentes cadeias poderiam suportar a mesma estrutura mínima de transação, aplicando suas próprias ferramentas de verificação, precompiles ou recursos de conta.
Buterin descreveu o formato potencial como uma lista básica de chamadas com flags identificando sua função. Uma chamada poderia ser marcada como uma dependência pura, uma verificação dependente de estado ou uma ação. A transação também conteria informações padrão como sua origem e nonce.
A EIP-8141 permanece classificada como uma proposta Core preliminar. Sua especificação atual inclui regras detalhadas para admissão na mempool, execução de frame, recibos, assinaturas, contabilidade de gas e propagação de transações. Esses detalhes podem mudar durante a revisão.
Os desenvolvedores do Ethereum também debateram preocupações técnicas. Estas incluem riscos de negação de serviço, regras de substituição de transações, mudanças nas ferramentas, limites de transações pendentes e restrições impostas aos frames de verificação.
Uma discussão notou que a mempool pública proposta normalmente manteria apenas uma Transação de Frame pendente para cada remetente. Os desenvolvedores questionaram como essa regra afetaria contas que regularmente submetem várias transações dentro de um único bloco.
Outros participantes examinaram se o formato introduz complexidade adicional para carteiras, construtores de blocos e interfaces de chamada de procedimento remoto (RPC) do Ethereum. Essas questões devem ser resolvidas antes que as equipes de clientes possam implementar uma especificação estável.
O modelo de longo prazo de Buterin vai além da EIP-8141. Ele sugeriu que as dependências que não exigem acesso ao estado poderiam ser verificadas uma vez na camada da mempool, em vez de serem repetidas por cada validador.
Uma dependência pura pode incluir uma assinatura criptográfica ou prova cuja validade não muda com o estado do Ethereum. Após verificá-la, a rede poderia substituir várias peças de trabalho de verificação por um STARK recursivo confirmando que todas as verificações foram concluídas corretamente.
Um STARK é uma prova criptográfica que permite a uma parte demonstrar que uma computação foi realizada corretamente. Provas recursivas podem verificar outras provas, tornando possível combinar muitas verificações em uma tarefa de verificação menor.
A mempool proposta poderia agregar assinaturas de transação, provas de validade e outras dependências antes da execução do bloco. Os validadores então verificariam a prova agregada em vez de repetir independentemente cada computação original.
Buterin sugeriu que essa abordagem também poderia reduzir a quantidade de dados de verificação colocados on-chain. Se a prova recursiva estabelecer que todas as dependências eram válidas, alguns dos dados originais poderiam ser omitidos.
Esse resultado não faz parte da especificação atual da EIP-8141. Exigiria pesquisa adicional cobrindo geração de prova, coordenação de mempool, disponibilidade de dados e proteções contra agregação inválida.
O design também se relaciona com a preparação do Ethereum para a criptografia pós-quântica. As assinaturas resistentes a quânticos são geralmente maiores e mais caras para verificar do que as assinaturas ECDSA usadas por contas Ethereum comuns.
A EIP-8141 poderia permitir que as contas definissem novos esquemas de autorização sem esperar que o Ethereum substituísse um único padrão de assinatura fixo. A agregação de provas recursivas poderia então reduzir o custo de verificação de grandes assinaturas pós-quânticas.
A EIP-8141 poderia ajudar as contas Ethereum a adotar a autorização pós-quântica se sistemas de assinatura práticos se tornarem disponíveis. Esse continua sendo um caminho de segurança de longo prazo, em vez de uma resposta imediata a uma ameaça quântica ativa.
As contas Ethereum usam nonces sequenciais para evitar a reprodução de transações. Se uma conta submeter transações numeradas 10, 11 e 12, a rede normalmente as processa nessa ordem.
A sequência pode criar um gargalo. Se a transação 10 ficar presa ou inválida, transações posteriores da mesma conta também podem esperar, mesmo quando suas operações não estiverem relacionadas.
Nonces com chave dariam a uma conta várias sequências de nonce independentes. Transações atribuídas a chaves diferentes poderiam prosseguir sem esperar que outra sequência avançasse.
Isso poderia ajudar contas inteligentes, sistemas de privacidade e aplicações que submetem várias operações independentes simultaneamente. Cada fluxo de trabalho poderia receber seu próprio domínio de nonce, mantendo a proteção contra reprodução.
O Crypto.news relatou anteriormente que nonces com chave poderiam impedir que transações privadas independentes se bloqueassem mutuamente. O recurso faz parte de um esforço mais amplo para melhorar as transações de privacidade, contas flexíveis e resistência à censura.
Buterin também conectou o trabalho de transação com modelos de estado alternativos, incluindo designs UTXO nativos e estruturas de estado baseadas em provas. Esses projetos exploram se alguns ativos ou operações podem usar regras de estado previsíveis, enquanto contratos complexos mantêm a flexibilidade existente do Ethereum.
A abordagem poderia criar vários níveis de processamento. Operações simples e declaradas seriam mais fáceis de analisar e poderiam receber taxas mais baixas. Chamadas de contrato dinâmicas continuariam a funcionar, mas consumiriam mais recursos porque os clientes não podem preparar sua execução da mesma forma.
Essa precificação diferenciada tentaria alinhar as taxas com as restrições de escalabilidade reais criadas por cada transação. Não garantiria taxas mais baixas para cada usuário ou aplicação.
A EIP-8141 deve passar por várias etapas antes de poder afetar os usuários do Ethereum. Os desenvolvedores principais precisam primeiro concordar que as Transações de Frame oferecem um caminho melhor do que os designs concorrentes de abstração de conta.
A proposta exigiria então implementações de cliente, redes de desenvolvimento, testes de interoperabilidade, suporte a carteiras e revisão de segurança. Os desenvolvedores também precisariam testar como as Transações de Frame interagem com construtores de blocos, mempools, mercados de taxas e contratos inteligentes existentes.
Discussões anteriores de desenvolvedores consideraram a EIP-8141 para a futura atualização Hegotá do Ethereum. No entanto, o crypto.news relatou que as Transações de Frame permaneciam em consideração, em vez de formalmente agendadas.
FOCIL, uma proposta separada destinada a melhorar a resistência à censura por meio de listas de inclusão de transações, também foi discutida junto com a EIP-8141. As duas propostas abordam problemas diferentes. As Transações de Frame dizem respeito à estrutura de autorização e execução, enquanto a FOCIL diz respeito à inclusão de transações elegíveis em blocos.
Os desenvolvedores argumentaram que usá-las juntas poderia fornecer abstração de conta nativa com maior resistência à censura. Essa combinação ainda é um pacote proposto, não um compromisso aprovado do roteiro do Ethereum.
Os comentários de Buterin de 6 de setembro, portanto, descrevem uma possível direção para o design de transações do Ethereum. Eles não anunciam uma atualização concluída, data de ativação ou mudança confirmada nas taxas de gas da mainnet.
Os próximos marcos verificáveis seriam o suporte formal de desenvolvedores, a inclusão em um escopo de atualização e implementações funcionais em redes de desenvolvimento. Até então, a EIP-8141 e as mempools de STARKs recursivos permanecem propostas ativas de pesquisa e engenharia.
A EIP-8141 propõe Transações de Frame que dividem a validação, aprovação de taxas e execução em frames de chamada de contrato separados.
É atualmente uma proposta Core preliminar. Os desenvolvedores do Ethereum ainda podem alterar ou rejeitar sua especificação.
Uma ação muda o estado do Ethereum, como enviar ETH ou chamar um contrato. Uma dependência é uma condição que deve ser válida, como uma assinatura ou prova de estado.
Separar elas poderia permitir que dependências independentes fossem processadas simultaneamente antes que as operações de mudança de estado sejam executadas.
Poderia tornar as transações previsíveis mais baratas de processar se os desenvolvedores adotarem uma precificação de gas que recompense operações analisáveis estaticamente.
Nenhuma redução de taxa está confirmada. Os custos dependeriam da especificação final, implementação do cliente e futuras decisões de atualização.
ETH