Como funcionam as provas de validade de transações conforme a EIP-8361?

EIP-8361 possibilita que uma transação de frame EIP-8141 envie um STARK sucinto como parte do payload peer-to-peer, permitindo que os nós confirmem que o prefixo de validação aprovou a transação conforme as premissas de estado declaradas. Em vez de repetir o mesmo mecanismo, os nós analisam uma única prova, suas dependências e as condições de estado relevantes, o que pode reduzir o custo de verificação para lógicas de conta mais complexas. As seções a seguir detalham como as transações válidas obtêm provas, como os nós identificam transações obsoletas ou fraudulentas, por que a prova se refere ao estado anterior válido sem se tornar uma raiz de Merkle, e por que ela é descartada após a inclusão no bloco.

A explicação também diferencia o EIP-8361 dos dois principais tipos de segurança de rollup: provas ZK, que garantem correção antes da aceitação, e provas de fraude, que exigem contestação para demonstrar transição inválida. Esclarece ainda limitações envolvendo assinaturas ECDSA, segurança quântica, possíveis riscos de computadores quânticos e o papel mais restrito da proposta em relação a soluções de escalabilidade. Esta análise técnica é direcionada a equipes de carteiras, desenvolvedores de clientes, operadores de provadores e usuários que avaliam como transações portadoras de prova podem permitir validação Ethereum mais sofisticada enquanto o EIP-8361 permanece um rascunho de proposta de rede, não uma regra de consenso ativa.

Principais pontos

• EIP-8361 permite que uma transação de frame EIP-8141 carregue uma prova de admissão como metadado de transporte off-chain.
• Um provador off-chain executa o prefixo de validação sob premissas declaradas e gera um STARK vinculado à transação, pagador, dependências e condições de validade.
• O nó receptor realiza verificações stateless, valida a prova e as dependências e compara as premissas com seu estado Ethereum atual.
• Uma prova válida permite admissão no mempool sem repetir toda a simulação do prefixo de validação.
• A prova não determina validade de bloco, não altera execução nem integra o estado permanente do Ethereum. Ela é descartada após inclusão ou remoção do mempool.

O que são provas de validade de transação EIP-8361?

O EIP-8361 define um método proposto de admissão para transações criadas sob o EIP-8141. Seu escopo é restrito: tornar algumas transações computacionalmente caras baratas o suficiente para que os nós possam avaliá-las antes de encaminhá-las pelo mempool público.

Uma transação de frame EIP-8141 pode incluir lógica programável que determina se o remetente autoriza a transação, quem pagará pela execução e se condições específicas são atendidas. Essa lógica aparece em um prefixo de validação executado antes dos frames ordinários da transação.

Na admissão simulada tradicional, cada nó receptor pode precisar executar esse prefixo para decidir se a transação entra em seu mempool. O EIP-8361 oferece outra opção. Um provador executa o prefixo uma vez off-chain e cria uma prova criptográfica mostrando que termina com resultado APPROVE e pagador identificado.

A transação e a prova viajam juntas. O nó valida a prova em vez de reconstruir todo o processo de validação.

O framework EIP-8361 aborda a admissão no mempool portando prova, enquanto o processo de validação do mempool EIP-8361 determina como os nós receptores decidem aceitar, reter, estacionar ou remover essas transações.

Em 6 de agosto de 2026, o EIP-8361 está apresentado como draft pull request #12075, proposta de Standards Track Networking. Não introduz novo tipo de transação nem altera o consenso do Ethereum por si só.

Como funciona a prova criptográfica do EIP-8361?

A prova cobre uma afirmação específica, não alegando conhecimento de todos os resultados futuros de execução.

Simplificando, o provador deve demonstrar que:

O prefixo de validação da transação T, ao ser avaliado sob premissas e dependências declaradas, segue as regras de trace do EIP-8141 e termina com APPROVE e pagador P, conforme as condições declaradas.

Os inputs públicos vinculam a prova a cinco elementos:

Essa vinculação garante que uma prova válida para uma transação não possa ser reaproveitada em outra com dados, dependências, condições ou pagador diferentes.

A testemunha privada inclui as informações necessárias para avaliar o prefixo, incluindo o conteúdo da lista de dependências declaradas. A prova resultante demonstra a correção desse cálculo sem exigir que cada nó receptor o repita.

O EIP-8361 propõe reutilizar o formato de prova e o mecanismo de verificação de entrada do EIP-8288. O EIP utiliza STARKs por representarem grandes cálculos com provas sucintas, sem exigir que cada verificador refaça o trabalho original.

Como o vetor de premissas é usado na validação de transações?

Uma prova criptográfica pode mostrar que um cálculo está correto para determinados inputs, mas um nó do mempool ainda precisa conferir se esses inputs correspondem ao estado atual do Ethereum.

O EIP-8361 resolve isso com um vetor de premissas, A, que lista cada valor de estado lido pelo prefixo de validação. As entradas incluem endereço, chave de armazenamento ou referência de saldo, tipo de comparação e valor.

Dois tipos de comparação são definidos:

• Premissas EQ exigem que o valor de estado atual seja igual ao valor declarado na prova.
• Premissas GEQ exigem que o valor de estado atual seja maior ou igual ao limite declarado.

Uma entrada EQ é útil para hash de código, nonce ou branch de armazenamento cujo significado muda sempre que o valor subjacente muda. Uma GEQ é mais adequada a requisitos monotônicos, como checar se o pagador possui saldo suficiente para um pré-pagamento.

Por exemplo, se o prefixo de validação de uma smart account aprova uma transação apenas quando o saldo do paymaster for pelo menos 0,2 ETH, o provador pode registrar uma premissa GEQ com limite de 0,2 ETH. Um nó pode considerar a prova válida enquanto o saldo estiver em 0,2 ETH ou mais, sem necessidade de nova prova a cada aumento de saldo acima desse limite.

Esse design evita ancorar a prova a uma raiz de estado completa ou exigir uma grande prova de Merkle para todo o estado Ethereum. O circuito avalia o prefixo de validação com os valores declarados, enquanto o nó compara esses valores com seu estado atual.

Como funcionam as provas de validade de transação sob o EIP-8361?

O processo de validação de transação segue uma sequência ordenada de verificações.

1. Executar verificações stateless. O nó confere validade intrínseca da transação e formato da lista de dependências ou assinaturas. Transações malformadas são rejeitadas antes da verificação da prova.
2. Validar a prova de admissão. O nó valida o STARK com a chave de verificação designada. Falha indica que o cálculo de validação não foi estabelecido.
3. Validar dependências externas. A prova pode assumir que assinaturas ou dependências declaradas são válidas. O nó valida essas dependências separadamente e confere se a lista corresponde ao hash de dependências.
4. Verificar condições de validade. O nó avalia condições declaradas, como prazos, janelas de slot ou epoch, intervalos de vencimento ou requisitos de nonce.
5. Comparar premissas com o estado ao vivo. Entradas EQ são conferidas por igualdade; GEQ, em relação ao limite.
6. Admitir a transação. Se todas as verificações forem bem-sucedidas, o nó pode aceitar e propagar a transação sem simular todo o prefixo de validação.

Essa sequência impede que uma prova burle verificações estruturais, de assinatura, estado ou tempo. Ela altera o método computacional da decisão de admissão, não os requisitos de validade da transação.

O que acontece quando o estado do Ethereum muda?

A admissão no mempool não é garantia permanente, pois o estado do Ethereum muda após a entrada da transação no pool.

Com EIP-8361, um nó revalida as condições de validade e o vetor de premissas quando um novo bloco altera o head da cadeia. Não é preciso regenerar a prova, reexecutar o prefixo de validação ou validar novamente a mesma prova. A prova previamente validada fica em cache para a função de validação com os inputs declarados.

Uma falha EQ normalmente invalida a prova, pois um input exato mudou. O nó remove a transação, a menos que o remetente forneça nova prova ou a transação se enquadre em admissão simulada.

Uma GEQ falha pode ser tratada de forma diferente: o nó pode estacionar a transação. Se o pagador ou paymaster receber fundos suficientes, o nó pode reativar a transação ao checar novamente o limite.

Essa distinção faz do vetor de premissas mais do que um compromisso ao estilo Merkle com um estado histórico. Ele define quais mudanças de estado invalidam a aprovação e quais permanecem compatíveis.

Por que a prova é descartada após a inclusão no bloco?

A prova EIP-8361 é necessária apenas para admissão e propagação no mempool público. Não é a prova autoritativa de que a transação incluída produziu a transição de estado correta.

Quando um validador inclui a transação em um bloco, o Ethereum a processa por execução protocolar ordinária. A EVM executa o prefixo de validação e os frames restantes conforme o estado do bloco. Clientes de consenso determinam se o bloco é válido pelas regras normais do Ethereum.

Assim, a prova de admissão:

• não é incluída no bloco;
• não é adicionada ao calldata da transação;
• não aparece no recibo;
• não integra árvore de Merkle ou raiz de estado;
• não cria alteração permanente de estado on-chain;
• não precisa ser retida após inclusão ou remoção.

Descartar a prova evita custos permanentes de calldata e crescimento de estado para informações que já cumpriram sua função de rede. A transação permanece on-chain, mas seu envelope de prova temporário não.

Sistema de prova EIP-8361 vs. provas de validade ZK-Rollup

O EIP-8361 utiliza provas criptográficas, mas sua prova de admissão não equivale às provas de validade usadas por ZK rollups.

ZK rollups normalmente utilizam ZK-SNARKs ou ZK-STARKs para provar a correção de lotes de transações. Após a aceitação da prova pelo contrato Layer 1, o rollup pode finalizar a transição de estado sem aguardar período de contestação de fraude de rollups otimistas.

O EIP-8361 não prova lote L2, não autoriza saque imediato nem garante que uma cadeia L2 nunca entre em estado inválido. Sua prova é artefato temporário de rede para validação pré-inclusão.

Ainda que provas de conhecimento zero possam validar afirmações sem revelar todos os dados da testemunha, EIP-8361 não é uma proposta de privacidade. “Prova sucinta” e “conhecimento zero” são características relacionadas, mas não idênticas.

Saques de Layer 2 para Layer 1 podem ser mais rápidos com provas de validade porque ZK rollups não requerem período de contestação de fraude. O tempo final de saque depende de geração da prova, verificação Layer 1, regras de bridge e finalização do Ethereum. O EIP-8361 não oferece esse mecanismo; sua prova apoia admissão no mempool de uma transação de frame EIP-8141, não liquidação de lote Layer 2.

Como funcionam as provas de fraude em rollups otimistas?

Provas de fraude utilizam mecanismo de segurança distinto. Um rollup otimista aceita uma transição de estado proposta e permite contestação durante um período de disputa. A resolução pode exigir múltiplas rodadas ou prova de execução reduzida.

O EIP-8361 busca estabelecer a afirmação de admissão antes da aceitação da transação no mempool. Não há período de contestação pós-admissão em que outro participante prove fraude no prefixo.

A diferença-chave está no tempo e escopo:

• Prova de validade demonstra uma afirmação antes da aceitação.
• Prova de fraude permite afirmação otimista até ser contestada.
• Prova de admissão EIP-8361 diz respeito à política do mempool.
• Prova de fraude de rollup diz respeito à correção de transição de estado L2.

Os trade-offs técnicos entre execução EVM repetida e verificação sucinta são discutidos em EIP-8361 versus simulação de transação, incluindo onde o custo de geração da prova substitui a simulação no nó.

EIP-8361, validação de contas complexas e segurança pós-quântica

Contas programáveis podem usar multisig, rotação de chaves, regras de recuperação, esquemas de assinatura não convencionais, candidatos a assinatura pós-quântica, políticas de gastos ou verificações de conhecimento zero com alto custo de gas. Parte dessa lógica pode ser válida, mas cara demais para simulação segura por cada nó de mempool.

O EIP-8361 busca preservar a propagação pública de transações para essas contas tornando a validação cara para o provador, mas barata para cada verificador. Pode também reduzir a pressão para mover autorizações complexas para a fase de execução, onde falhas podem gerar transações revertidas pagas e registradas publicamente.

Esse mecanismo não garante segurança total nem estabelece segurança pós-quântica completa. Um STARK pode evitar algumas premissas de sistemas baseados em curva elíptica, mas a transação ainda pode depender de chaves públicas, esquemas de assinatura, implementações de clientes, código de carteira ou chaves de verificação com propriedades de segurança distintas.

As responsabilidades para criadores de transações, carteiras, provadores e clientes diferem substancialmente, como resumido em impacto do EIP-8361 em carteiras, nós e desenvolvedores.

Por exemplo, um trader avaliando se avanços em account abstraction do Ethereum influenciam o sentimento do mercado pode comparar marcos da proposta ao gráfico de mercado ETH/USDT, embora o preço não confirme implementação ou adoção de um EIP em rascunho.

Riscos e limitações

O EIP-8361 ainda é rascunho, então formato de prova, limites, dependências, terminologia e detalhes de implementação podem mudar antes da padronização.

O mecanismo traz riscos técnicos:

Concentração na geração da prova: Gerar STARK pode exigir software especializado e computação significativa. Se poucos serviços geram provas com eficiência, carteiras podem depender de infraestrutura centralizada de provadores.

Pressão de negação de serviço: Verificação da prova é mais barata que repetir o cálculo original, mas não gratuita. Clientes precisam de limites de tamanho de prova, limites de taxa entre peers e atribuição de falhas para evitar ataques com provas inválidas ou grandes demais.

Completude das premissas: A prova só é válida se o vetor de premissas contiver toda leitura de estado usada pelo prefixo de validação. Bugs que omitam dependências podem gerar decisões de admissão incorretas.

Obsolescência de estado: Uma prova pode permanecer correta criptograficamente mesmo que suas condições não correspondam mais ao estado atual. Nós devem revalidar A e C enquanto a transação estiver no pool.

Sem garantia de execução: Admissão no mempool não garante inclusão em bloco ou execução final bem-sucedida. Outra transação pode alterar nonce, saldo, código, armazenamento ou outro estado relevante do remetente antes da inclusão.

Complexidade de implementação: Clientes, carteiras e sistemas de provadores precisam concordar sobre codificação da prova, chaves de verificação, tratamento de dependências, comportamento entre peers e regras de revalidação. Implementações inconsistentes podem fragmentar a propagação de transações.

O EIP-8361 também é a proposta Tapered Issuance Burn?

Discussões iniciais associaram o número EIP-8361 a uma proposta distinta de política monetária do Ethereum chamada Tapered Issuance Burn. Essa proposta passou a ser EIP-8363, enquanto EIP-8361 refere-se a Transaction Validity Proofs na categoria networking. São propostas independentes: EIP-8361 trata de admissão no mempool baseada em prova; Tapered Issuance Burn altera a economia de recompensas do consenso conforme o saldo ativo de staking.

Conclusão

As provas de validade de transação EIP-8361 transferem o custo da validação de transações programáveis de cada nó receptor para um provador off-chain. O STARK resultante vincula uma transação EIP-8141 ao resultado de aprovação, pagador, dependências, condições e premissas de estado, permitindo que nós verifiquem uma afirmação concisa antes da admissão no mempool.

O mecanismo é mais útil quando uma smart account possui lógica de validação legítima que excede limites práticos de simulação. Sua principal restrição: a prova se aplica apenas à admissão na camada de rede. O Ethereum ainda executa a transação normalmente na inclusão, e a prova temporária é descartada porque não tem papel de consenso ou on-chain posteriormente.

Perguntas frequentes

Como ZK rollups usam provas de validade?

ZK rollups processam transações off-chain, agrupam-nas em lotes e geram uma prova de validade para cada lote. A prova, geralmente com ZK-SNARKs, ZK-STARKs ou compromissos polinomiais, permite que um contrato Ethereum valide a transição de estado sem reexecutar cada transação.

Provas de validade garantem que uma cadeia L2 não pode se tornar inválida?

Provas de validade impedem que um verificador L1 aceite transição de estado inválida, desde que circuito, contrato verificador, criptografia e implementação funcionem corretamente. Não eliminam riscos de código defeituoso, disponibilidade de dados, bridges, sequenciadores, governança ou upgrades.

Por que saques de ZK-rollup costumam ser mais rápidos?

ZK rollups podem finalizar saques após a prova de validade ser submetida e verificada, sem aguardar período de contestação de fraude de rollups otimistas. Saques ainda dependem de geração da prova, submissão do lote, regras de bridge e finalização do Ethereum, então “imediato” nem sempre significa instantâneo.

Como provas de validade diferem de provas de fraude?

Provas de validade estabelecem a correção da transação antes de uma transição de estado ser aceita. Provas de fraude seguem modelo otimista: uma transição pode ser aceita temporariamente e contestada depois; muitos rollups otimistas usam período de contestação de cerca de sete dias, embora a duração varie.

Provas de conhecimento zero sempre ocultam dados da transação?

Não. Provas de conhecimento zero podem validar uma afirmação sem revelar a testemunha privada, mas a privacidade depende de quais inputs permanecem ocultos. Muitos ZK rollups usam provas ZK principalmente para verificação escalável, não para transações totalmente privadas.

Qual a diferença entre ZK-SNARKs e ZK-STARKs?

ZK-SNARKs produzem provas pequenas com baixo custo de verificação, mas muitos designs requerem trusted setup. ZK-STARKs dispensam trusted setup e são considerados mais resistentes a ataques de computadores quânticos, mas as provas costumam ser maiores.

O que uma prova de Merkle verifica?

Uma prova de Merkle confirma que dados específicos pertencem a um conjunto representado por uma raiz de Merkle, sem baixar o conjunto completo. Ela prova inclusão ou exclusão, não a correção de todo lote de transações ou transição de estado.

Provas de validade reduzem o consumo de recursos on-chain?

Sim, podem comprimir um cálculo off-chain em uma única prova, mais barata de verificar on-chain do que reexecutar cada transação. A economia real depende do custo de verificação, tamanho do lote, uso de calldata ou blob e implementação do rollup.

Provas de validade reduzem o risco de ataque 51%?

Não diretamente. Provas de validade protegem a correção de transições de estado Layer 2 verificadas, enquanto ataque 51% diz respeito ao controle sobre o consenso do Ethereum. São mecanismos para riscos diferentes.

Provas EIP-8361 são iguais às de ZK-rollup?

Não. Provas de ZK-rollup validam lotes de transações Layer 2 e suportam finalização de estado e saques. Provas EIP-8361 suportam admissão no mempool para transações EIP-8141 individuais, ficam fora do bloco e são descartadas após inclusão ou remoção.

Isenção de responsabilidade

Este conteúdo é educacional e descreve uma proposta em rascunho do Ethereum cuja especificação e status de implementação podem mudar. Não oferece aconselhamento financeiro, de segurança ou de implantação de software. Desenvolvedores devem verificar o texto mais recente do EIP e os requisitos de clientes antes de construir sistemas em produção.