Vitalik Buterin revela redesenho das transações do Ethereum

O cofundador da 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 um post detalhado. As ações alteram o estado da 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 de Merkle mostrando que uma saída não gasta existe, 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 a Ethereum a escalar sem abandonar seu ambiente de execução flexível. No entanto, a proposta permanece parte da pesquisa contínua de protocolo. Os desenvolvedores da Ethereum não aprovaram o design completo para implantação.

A Ethereum poderia processar dependências de transação em paralelo

As transações da 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 várias verificações independentes são conhecidas antecipadamente, os clientes podem distribuir o trabalho entre os recursos de processamento disponíveis.

Verificações dependentes de estado exigem mais 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 os mempools poderiam raciocinar sobre essas condições de forma mais eficaz quando as transações declaram quais partes do estado acessam.

A abordagem recompensaria transações previsíveis. Operações que especificam suas dependências claramente poderiam receber custos de gás 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 permaneceriam possíveis, mas poderiam custar mais.

Buterin estimou que mais de 90% da atividade da Ethereum por volume não requer o nível total de flexibilidade dinâmica da rede. Esse número é sua avaliação, em vez de uma medição de rede publicada no post. O argumento mais amplo é que transferências comuns e interações rotineiras com contratos poderiam usar formatos mais restritivos sem limitar aplicações especializadas.

O modelo proposto preservaria o sistema de contas flexível da Ethereum para transações que precisam dele. Atividade mais previsível poderia usar estruturas estaticamente analisáveis semelhantes a partes do modelo de transação do Bitcoin.

O Bitcoin usa um modelo de saída de transação não gasta em que 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.

EIP-8141 fornece uma estrutura geral de transação

EIP-8141 é uma Proposta de Melhoria do Ethereum (Ethereum Improvement Proposal) em rascunho para um novo tipo de transação conhecido como Transação de Quadro (Frame Transaction). Ela divide uma transação em quadros de chamada de contrato que podem validar autoridade, aprovar pagamento de gás e executar operações do usuário.

A proposta oficial diz que a validade da transação e o pagamento de taxas não dependeriam mais apenas de uma assinatura padrão anexada à transação externa. O código da conta poderia, em vez disso, definir as regras de autorização e pagamento necessárias.

As Transações de Quadro 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 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 quadros de verificação determinariam se o remetente autorizou a transação. Quadros separados poderiam estabelecer quem paga as taxas e então executar as operações solicitadas.

Essa estrutura está alinhada com a divisão de Buterin entre dependências e ações. Os quadros de verificação lidam com condições que devem ser satisfeitas. Os quadros de remetente lidam com as operações que alteram o estado.

O formato também poderia melhorar a interoperabilidade entre redes da Máquina Virtual Ethereum. Diferentes cadeias poderiam suportar a mesma estrutura mínima de transação enquanto aplicam suas próprias ferramentas de verificação, pré-compilações ou recursos de conta.

Buterin descreveu o formato potencial como uma lista básica de chamadas com sinalizadores 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.

EIP-8141 permanece classificado como uma proposta Core em rascunho. Sua especificação atual inclui regras detalhadas para admissão no mempool, execução de quadros, recibos, assinaturas, contabilidade de gás 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 em ferramentas, limites de transações pendentes e restrições colocadas em quadros de verificação.

Uma discussão observou que o mempool público proposto normalmente manteria apenas uma Transação de Quadro pendente para cada remetente. Os desenvolvedores questionaram como essa regra afetaria contas que enviam regularmente 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 do Ethereum. Essas questões devem ser resolvidas antes que as equipes de clientes possam implementar uma especificação estável.

STARKs recursivos poderiam eliminar verificação repetida

O modelo de longo prazo de Buterin vai além do EIP-8141. Ele sugeriu que dependências que não exigem acesso ao estado poderiam ser verificadas uma vez na camada do mempool em vez de serem repetidas por cada validador.

Uma dependência pura poderia 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 múltiplas 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 que uma parte demonstre que uma computação foi executada corretamente. Provas recursivas podem verificar outras provas, tornando possível combinar muitas verificações em uma tarefa de verificação menor.

O mempool proposto 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 na cadeia. Se a prova recursiva estabelecer que todas as dependências eram válidas, alguns dos dados originais poderiam potencialmente ser omitidos.

Esse resultado não faz parte da especificação atual do EIP-8141. Exigiria pesquisa adicional cobrindo geração de provas, coordenação do 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. Assinaturas resistentes a quantum são geralmente maiores e mais caras de verificar do que as assinaturas ECDSA usadas por contas Ethereum comuns.

O EIP-8141 poderia permitir que contas definissem novos esquemas de autorização sem esperar que o Ethereum substitua um único padrão de assinatura fixo. A agregação recursiva de provas poderia então reduzir o custo de verificar grandes assinaturas pós-quânticas.

O EIP-8141 poderia ajudar contas Ethereum a adotar autorização pós-quântica se sistemas de assinatura práticos estiverem disponíveis. Isso continua sendo um caminho de segurança de longo prazo, em vez de uma resposta imediata a uma ameaça quântica ativa.

Nonces chaveados podem remover gargalos de transação

As contas Ethereum usam nonces sequenciais para evitar replay de transações. Se uma conta envia 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 podem esperar, mesmo quando suas operações não estão relacionadas.

Nonces chaveados 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 avance.

Isso poderia ajudar contas inteligentes, sistemas de privacidade e aplicações que enviam várias operações independentes simultaneamente. Cada fluxo de trabalho poderia receber seu próprio domínio de nonce, mantendo a proteção contra replay.

O Crypto.news relatou anteriormente que nonces chaveados poderiam impedir que transações privadas independentes bloqueiem umas às outras. O recurso faz parte de um esforço mais amplo para melhorar transações de privacidade, contas flexíveis e resistência à censura.

Buterin também conectou o trabalho de transações 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 funcionando, mas consumiriam mais recursos porque os clientes não podem preparar sua execução da mesma maneira.

Tal precificação diferenciada tentaria alinhar as taxas com as restrições reais de escalabilidade criadas por cada transação. Não garantiria taxas mais baixas para todos os usuários ou aplicações.

EIP-8141 ainda requer aprovação e testes dos desenvolvedores

O EIP-8141 deve passar por várias etapas antes de afetar os usuários do Ethereum. Os desenvolvedores principais primeiro precisam concordar que as Transações Frame oferecem um caminho melhor do que designs concorrentes de abstração de conta.

A proposta exigiria então implementações de clientes, 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 Frame interagem com construtores de blocos, mempools, mercados de taxas e contratos inteligentes existentes.

Discussões anteriores de desenvolvedores consideraram o EIP-8141 para a futura atualização Hegotá do Ethereum. No entanto, o Crypto.news relatou que as Transações Frame permaneceram 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 o EIP-8141. As duas propostas abordam problemas diferentes. As Transações Frame dizem respeito à autorização e estrutura de execução, enquanto o FOCIL diz respeito à inclusão de transações elegíveis em blocos.

Os desenvolvedores argumentaram que usá-los juntos poderia fornecer abstração de conta nativa com resistência à censura mais forte. Essa combinação ainda é um pacote proposto, não um compromisso aprovado no roteiro do Ethereum.

Os comentários de Buterin em 6 de setembro, portanto, descrevem uma direção possível 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 gás da mainnet.

Os próximos marcos verificáveis seriam suporte formal dos desenvolvedores, inclusão em um escopo de atualização e implementações funcionais em redes de desenvolvimento. Até então, o EIP-8141 e os mempools STARK recursivos permanecem propostas ativas de pesquisa e engenharia.

Perguntas Frequentes