O que é o EIP-8361? Provas de validade em Ethereum explicadas

O EIP-8361 foca-se exclusivamente na admissão baseada em prova para transações frame do EIP-8141, sem alterar a execução do Ethereum, criar novos tipos de transação, implementar contratos inteligentes, garantir privacidade de transação, modificar recompensas de validadores ou definir períodos de implementação. O seu objetivo prático é reduzir a computação redundante na validação de transações, preservando salvaguardas contra operações inválidas ou de elevado consumo de recursos.

As secções seguintes detalham o funcionamento do processo de admissão baseada em prova, o que os nodos verificam, as diferenças entre EIP-8361, provas de validade de rollup e simulação de transações, e as limitações técnicas ainda por resolver.

Principais conclusões

• O EIP-8361 padroniza os dados de prova de validade de transação para propagação peer-to-peer. Uma transação frame pode transportar um STARK que demonstra que o prefixo de validação atinge um estado aprovado.

• Os nodos verificam a prova em vez de executarem repetidamente lógica de autorização dispendiosa. Esta separação entre prova e verificação pode reduzir a computação redundante nos nodos Ethereum.

• A prova permanece fora do consenso. É transportada com a transação, utilizada para admissão no mempool e descartada quando deixa de ser necessária.

• O design suporta validação avançada de smart-account. Inclui regras de multisignature, sistemas alternativos de assinatura, paymasters e autorizações complexas.

• O EIP-8361 está em rascunho. Não é uma atualização ativada e não deve ser confundido com EIP-7701, EIP-7702, provas de validade de rollup ou propostas de recompensa de staking.

O que é o EIP-8361?

O EIP-8361, denominado Transaction Validity Proofs, propõe um mecanismo de rede para que uma transação Ethereum chegue acompanhada de evidência criptográfica de que a sua lógica de validação a aprova. O rascunho complementa as alterações de protocolo do EIP-8141, que define transações frame e etapas de validação programáveis.

Uma Ethereum Improvement Proposal é um documento técnico que descreve um potencial padrão, funcionalidade, interface ou processo para o Ethereum. A publicação como EIP não implica aceitação ou implementação automática. O EIP-8361 é um rascunho em desenvolvimento, cuja especificação, dependências e estado podem ser alterados.

A proposta responde à questão:

Como pode um nodo admitir com segurança uma transação cuja autorização é dispendiosa sem exigir que todos os peers repitam essa computação?

Com o EIP-8361, um provador executa off-chain a lógica de validação relevante e gera um STARK. O nodo receptor verifica a prova, confronta as suposições declaradas com o estado atual do Ethereum e decide se coloca a transação no mempool público.

A transação deve ser válida segundo as regras de execução do Ethereum ao ser incluída num bloco. A prova serve apenas para admissão, não substitui execução de protocolo nem validação de consenso.

Desafios na validação de transações complexas Ethereum

Uma externally owned account convencional é controlada por uma chave privada e correspondente chave pública. Autoriza transações com assinatura ECDSA, especificando campos como nonce, endereço de destino, valor, chain ID, limite de gás e parâmetros de taxa de gás ou EIP-1559.

Estas verificações são previsíveis: o nodo valida a assinatura, confirma fundos, verifica o nonce e rejeita transações malformadas ou repetidas.

Smart accounts ampliam a superfície de validação, podendo incluir:

• múltiplas chaves públicas;

• limites de gastos;

• chaves de sessão;

• contratos delegados;

• regras de paymaster;

• assinaturas pós-quânticas;

• condições de recuperação;

• provas de zero conhecimento;

• código de autorização específico.

Esta lógica pode estar num contrato inteligente já implementado ou num novo contrato criado durante o deployment. A validação pode incluir fábrica, código de inicialização ou endereço futuro do contrato.

Nodos Ethereum não podem executar código de validação ilimitado para todas as transações não confirmadas. Atacantes podem submeter transações fraudulentas que invocam contratos inteligentes dispendiosos, funções de hash, leituras de armazenamento ou sistemas de prova sem autorizar execução. Mesmo inválidas, a verificação consome recursos do nodo.

Provas de validade de transação do EIP-8361 deslocam o trabalho dispendioso para um provador, mantendo a verificação limitada.

Funcionamento das transações com prova EIP-8361

O EIP-8361 propõe dois caminhos para admitir uma transação frame do EIP-8141:

1. Admissão simulada: o nodo executa diretamente o prefixo de validação.

2. Admissão com prova: o nodo verifica um STARK que demonstra aprovação do prefixo de validação.

O segundo caminho é para casos em que a chamada ao código de validação excede o orçamento de verificação do nodo.

1. Definição da lógica de validação

Uma transação frame do EIP-8141 pode dividir o seu trabalho em frames com finalidades distintas. Alguns frames estabelecem autorização, identificam o pagador ou preparam execução. O prefixo de validação executa-se antes dos frames de execução normais.

O prefixo pode chamar um contrato inteligente do remetente ou um contrato delegado, verificando assinaturas, permissões, saldos, condições de caducidade ou outras regras antes da operação APPROVE.

O EIP-8141 difere de transações convencionais, em que uma assinatura ECDSA reconhecida pelo protocolo determina o remetente. O modelo programável integra-se na abstração nativa de contas do Ethereum. Evita depender da lista de autorização baseada em ECDSA do EIP-7702, visando maior flexibilidade criptográfica.

2. Execução do prefixo de validação pelo provador

O provador executa o prefixo de validação com inputs e suposições de estado declarados, incluindo verificações como:

• correspondência de assinatura com chave pública;

• saldo suficiente na conta do remetente;

• saldo do paymaster acima do valor exigido;

• slot de armazenamento com permissão esperada;

• chain ID correspondente à rede pretendida;

• nonce a prevenir replay;

• aprovação final do código de validação.

O provador cria um STARK que compromete a transação, dependências, suposições, pagador e condições de validade.

3. Declaração de suposições de estado

A prova criptográfica deixa de ser útil se depender de estado já alterado. O EIP-8361 propõe um vetor de suposições descrevendo os factos de estado usados na prova.

Condições de igualdade podem exigir que hash de código, nonce ou valor de armazenamento correspondam a valores declarados. Condições de maior ou igual podem exigir saldo acima de um mínimo.

Estas suposições ligam a prova a um estado válido anterior sem incorporar todo o estado Ethereum. Quando um novo bloco altera dados, o nodo pode revalidar o vetor de suposições.

Este mecanismo é central para a validação do mempool EIP-8361: o nodo não confia numa prova antiga apenas por validade criptográfica.

4. Verificação do STARK pelos nodos

O nodo receptor faz verificações estruturais de baixo custo antes de verificar a prova. Depois, valida o STARK com a chave de verificação e confronta dependências e suposições com o estado Ethereum atual.

Provas modernas podem ser verificadas mais rapidamente do que reexecutar a computação original. Uma prova pode substituir simulações repetidas, reduzindo computação redundante na rede peer-to-peer.

A geração de prova não é barata: produzir um STARK exige processamento, memória e software especializado. A proposta desloca a computação, não a elimina.

5. Entrada da transação no mempool

Com a prova e verificações de estado bem-sucedidas, o nodo pode admitir e propagar a transação sem reexecutar o prefixo de validação dispendioso.

A prova é metadata peer-to-peer, não é adicionada à calldata, armazenada em contratos inteligentes, escrita no estado da conta ou incluída na Merkle root do bloco.

Quando a transação é incluída, o Ethereum executa-a segundo as regras de protocolo. Se a prova ficar obsoleta ou a transação for removida, os metadados podem ser descartados.

O que comprova uma prova de validade EIP-8361?

Uma prova de validade EIP-8361 é evidência criptográfica de que uma computação de validação específica foi executada corretamente sob suposições declaradas e atingiu o estado de aprovação.

Pode demonstrar verificação de assinatura válida, saldos, nonce correto, pagador permitido ou autorização definida pelo contrato. Não comprova necessariamente todas as transições de estado EVM subsequentes da transação.

A distinção é relevante:

• O EIP-8361 comprova validação de admissão.

• Uma prova de validade de rollup comprova transições de estado off-chain.

• Uma prova de Merkle comprova inclusão numa estrutura de dados autenticada.

• Uma prova de zero conhecimento pode ocultar informação, mas validade não garante privacidade.

Provas de Merkle podem mostrar que uma transação pertence a um lote, bloco ou árvore de estado ao ligar uma folha a uma Merkle root conhecida. Em ZK rollups, podem estabelecer que contas de remetente e destinatário existiam no estado anterior e que saldos atualizados produzem a nova root de estado.

O EIP-8361 usa um STARK como prova eficiente de correção, mas não visa execução confidencial. A transação e dependências podem permanecer visíveis para nodos participantes.

EIP-8361 vs provas de validade de ZK-Rollup

Soluções Layer 2 usam provas de validade de forma mais abrangente. Um ZK rollup executa lotes de transações off-chain e submete uma prova sucinta a um contrato verificador Ethereum, demonstrando que o lote transformou o estado anterior num novo estado correto.

O contrato verificador valida a prova e inputs públicos, reduzindo recursos on-chain e distribuindo taxas de gás por várias transações. Provas recursivas podem agregar múltiplas provas numa só.

As provas de validade impedem que um ZK rollup finalize transições de estado inválidas, assumindo segurança do sistema de prova, circuito, contrato verificador e modelo de disponibilidade de dados. Permitem finalização L2-para-L1 mais rápida do que sistemas com janela de disputa.

O EIP-8361 não prova lotes de computação, não atualiza Merkle root L2, nem desencadeia levantamentos. Prova que uma transação frame cumpre requisitos de admissão.

Provas de validade EIP-8361 vs provas de fraude

Rollups otimistas assumem atualizações válidas salvo contestação. Provas de fraude exigem detetar transições contestadas e apresentar evidência durante o challenge. Reclamações inválidas podem ser provisoriamente aceites até resolução.

Provas de validade aceitam novos compromissos de estado apenas após confirmação de execução correta pelo verificador, permitindo levantamentos mais rápidos sem esperar por challenge de prova de fraude.

Afirmar que provas de validade são “mais seguras” que provas de fraude é demasiado generalista. As diferenças incluem complexidade do provador, segurança do verificador, disponibilidade de dados, trusted setups, suposições de challenge e maturidade de implementação.

O EIP-8361 não é um modelo de segurança de rollup. A sua prova é verificada antes da admissão no mempool, enquanto provas de fraude e de validade protegem sistemas de escalabilidade off-chain.

EIP-8361 vs delegação de conta EIP-7702

O EIP-7702 permite que EOAs definam um indicador de delegação no campo de código, para executar código de um contrato inteligente designado. Introduziu transações tipo-4 com authorization_list.

Cada tuplo de autorização inclui:

• chain_id;

• endereço de contrato delegado;

• nonce da conta;

• campos de assinatura.

A autorização é assinada pela chave privada do EOA. O signatário pode diferir de tx.origin e uma transação pode transportar autorizações de vários EOAs. Cada autorização pode atualizar o indicador de delegação da conta antes da execução.

Isto permite delegar execução a contratos inteligentes com autorizações assinadas, sem converter permanentemente a conta num contrato inteligente convencional. O código delegado pode suportar batching, patrocínio de gás, permissões ou outros comportamentos.

O EIP-7702 traz considerações de segurança: chain ID zero pode tornar autorizações válidas entre cadeias; nonces e campos assinados limitam replay; código delegado pode afetar tx.origin, transações pendentes, armazenamento e saldos.

O EIP-8361 não substitui nem estende a authorization_list. Aborda como nodos podem admitir transações com validação complexa. As diferenças entre provas de validade EIP-8361 e simulação de transações são sobre computação no mempool, não delegação EOA.

EIP-8361 vs abstração nativa de contas EIP-7701

O EIP-7701 foi proposto em 1 de maio de 2024 para abstração nativa de contas, dividindo processamento de transações em validação, execução e pós-operação, e propondo um novo tipo de transação EIP-2718.

Utilizava entry-point nativo 0x7701, opcodes por função, validação separada de remetente e paymaster, e pagamento de gás controlado por contrato. Não exigia bundler ERC-4337 para o seu tipo de transação.

O EIP-7701 foi retirado por ter sido substituído pelo EIP-8141, não apenas marcado como “Stagnant”. A especificação publicada indica diretamente o motivo. A exigência de contratos EOF não consta da especificação final.

O EIP-8361 baseia-se no modelo de transação frame do EIP-8141, facilitando validação programável dispendiosa de forma segura.

O EIP-2718 fornece o envelope de transação tipado usado em EIP-7701, EIP-7702 e EIP-8141. Define a transação como TransactionType || TransactionPayload, identificando como interpretar o payload. Incluir o tipo nos dados assinados reduz risco de replay entre tipos.

Impacto prático em carteiras, nodos e programadores

Programadores de carteiras podem usar admissão baseada em prova quando a autorização de smart accounts é demasiado dispendiosa para simulação ordinária no mempool. A carteira pode solicitar prova a provador local, serviço ou rede distribuída antes de submeter a transação.

Programadores de nodos devem implementar:

• transporte de prova peer-to-peer;

• chaves de verificação versionadas;

• limites de tamanho de prova;

• verificações de suposições e dependências;

• limites de taxa por peer;

• remoção de provas obsoletas;

• fallback de simulação.

Programadores de contratos inteligentes podem manter validação específica sem exigir execução total por todos os nodos, suportando assinaturas pós-quânticas, políticas de múltiplas chaves, paymasters complexos ou permissões baseadas em prova.

O impacto do EIP-8361 em carteiras, nodos e programadores depende de latência de prova, adoção, interoperabilidade e especificação final do EIP-8141.

Por exemplo, um negociador pode avaliar a reação do mercado numa exchange como a Gate a uma futura atualização Ethereum, comparando anúncios de rede com o gráfico ETH/USDT. Preço de mercado, volume ou taxas de gás não determinam se um EIP em rascunho foi aceite ou ativado.

Considerações de segurança e limitações

O EIP-8361 introduz várias considerações de segurança.

A solidez da prova depende da correção do circuito STARK e da chave de verificação. Bugs podem provar afirmações que não representam as regras de validação.

A verificação da prova consome computação e largura de banda. Atacantes podem enviar provas malformadas ou excessivas, tornando essenciais verificações preliminares, limites de tamanho e atribuição de peer.

As suposições podem tornar-se obsoletas: uma prova válida para saldo, armazenamento, hash de código ou nonce pode não ser aplicável após alteração do estado.

Políticas de nodo inconsistentes podem fragmentar propagação de transações. Clientes podem definir limites de tamanho, validação ou defaults distintos.

A geração de provas pode criar centralização, se poucos serviços possuírem hardware ou software suficiente.

O EIP-8361 não elimina custos de transação: ao atingir execução de bloco, o remetente ou pagador mantém responsabilidade pelo gás. Provas de validade reduzem computação redundante off-chain, mas não eliminam taxas Ethereum.

O que o EIP-8361 não propõe

Várias alegações pertencem a propostas não relacionadas e não devem ser atribuídas ao EIP-8361.

O EIP-8361 não:

• especifica período de transição de 18 meses;

• elimina piso de rendimento de staking;

• limita recompensas de validadores;

• deduz recompensas com staking a 50%;

• cria equilíbrio de staking orientado pelo mercado;

• introduz lista de autorização do EIP-7702;

• introduz entry point nativo do EIP-7701;

• cria novo tipo de transação EIP-2718;

• garante privacidade;

• liquida lotes de ZK-rollup;

• substitui provas de fraude;

• elimina direitos contratuais ou relacionados.

A secção de direitos de autor pode indicar renúncia sob CC0, como habitual nos EIPs. Este aviso refere-se ao documento da proposta, não a fundos, direitos de transação ou permissões de contratos inteligentes.

Conclusão

O EIP-8361 propõe admissão de transações baseada em prova para o mempool público do Ethereum. Um provador executa um prefixo de validação complexo do EIP-8141 uma vez, gera um STARK e permite que vários nodos verifiquem o resultado sem repetir a computação dispendiosa.

O principal caso de uso é autorização programável que excede limites ordinários de validação no mempool, incluindo smart accounts avançadas, sistemas alternativos de assinatura, paymasters e contratos complexos. O design reduz computação redundante nos nodos, mantendo suposições de estado atuais visíveis e revalidáveis.

O EIP-8361 não deve ser confundido com liquidação de ZK-rollup, challenges de prova de fraude, delegação de contas EIP-7702 ou o design retirado do EIP-7701. Permanece uma proposta em rascunho, cuja segurança, economia de prova, interoperabilidade e dependências requerem desenvolvimento adicional antes de possível implementação Ethereum.

Perguntas frequentes

O EIP-8361 cria um novo tipo de transação?

Não. Aplica admissão baseada em prova a transações frame do EIP-8141. O EIP-2718 fornece o framework tipado, mas o EIP-8361 não introduz outro envelope de transação.

As provas do EIP-8361 são provas de zero conhecimento?

O rascunho propõe provas de validade baseadas em STARK, mas validade não implica privacidade. A prova estabelece validação correta sob suposições declaradas, não oculta todos os dados da transação.

Uma prova pode cobrir várias transações?

Sistemas de prova podem agregar computações ou usar provas recursivas, e rollups podem comprimir provas de várias transações numa só. O EIP-8361 foca-se na admissão de uma transação frame específica, não na agregação arbitrária de lotes.

O EIP-8361 reduz taxas de gás?

Não diretamente. A proposta pode reduzir computação off-chain repetida, mas transações incluídas continuam a pagar gás pela execução Ethereum.

Qual a diferença entre EIP-8361 e EIP-7702?

O EIP-7702 permite delegação de execução via tuplos de autorização assinados. O EIP-8361 propõe admissão baseada em prova para validação programável dispendiosa.

Isenção de responsabilidade

Este conteúdo é educativo e descreve propostas técnicas em rascunho, não atualizações garantidas do Ethereum. Especificações, planos de implementação, suposições de segurança e suporte de rede podem mudar. Desenvolvimentos de protocolo e dados históricos de mercado não preveem o desempenho futuro do ETH.