Como funcionam as provas de validade de transações ao abrigo do EIP-8361?

O EIP-8361 permite que uma transação em frame EIP-8141 submeta um STARK sucinto juntamente com a respetiva carga peer-to-peer, proporcionando aos nodos a capacidade de confirmar que o prefixo de validação aprovou a transação com base nas assunções de estado declaradas. Em vez de executar repetidamente o mesmo mecanismo, os nodos validam uma única prova, as 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 secções seguintes detalham como as transações válidas obtêm provas, como os nodos detetam transações desatualizadas ou fraudulentas, porque a prova se refere ao estado válido anterior sem se tornar uma raiz de Merkle e porque desaparece após a inclusão em bloco.

A explicação diferencia também o EIP-8361 dos dois principais tipos de segurança de rollup: provas ZK, que estabelecem a correção antes da aceitação, e provas de fraude, que exigem um processo de desafio para demonstrar uma transição inválida. São ainda esclarecidos limites relacionados com assinaturas ECDSA, segurança quântica, potenciais riscos de computação quântica e o papel mais restrito da proposta face a soluções de escalabilidade. Esta análise técnica dirige-se a equipas de carteiras, programadores de clientes, operadores de provadores e utilizadores que avaliam o potencial das transações com prova para viabilizar validação Ethereum mais complexa, numa fase em que o EIP-8361 permanece uma proposta de networking em rascunho e não uma regra de consenso ativa.

Principais pontos

• O EIP-8361 permite que uma transação em frame EIP-8141 transporte uma prova de admissão como metadados de transporte off-chain.
• Um provador off-chain executa o prefixo de validação face às assunções declaradas e produz um STARK associado à transação, pagador, dependências e condições de validade.
• Um nodo recetor realiza verificações stateless, valida a prova e as dependências e compara as assunções com o seu estado Ethereum atual.
• Uma prova válida permite a admissão no mempool sem repetir a simulação completa do prefixo de validação.
• A prova não determina a validade do bloco, não altera a execução nem integra o estado permanente do Ethereum. É 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, com o objetivo restrito de tornar transações computacionalmente dispendiosas suficientemente acessíveis para que os nodos as avaliem antes de as encaminhar pelo mempool público.

Uma transação em frame EIP-8141 pode conter lógica programável que determina se o remetente autoriza a transação, quem paga pela execução e se as condições especificadas são cumpridas. Esta lógica surge num prefixo de validação executado antes dos frames de execução normais da transação.

Em regime de admissão simulada normal, cada nodo recetor pode necessitar de executar esse prefixo para decidir a entrada da transação no mempool. O EIP-8361 acrescenta outra opção: um provador executa o prefixo uma vez off-chain e cria uma prova criptográfica que demonstra que termina com APPROVE e um pagador identificado.

A transação e a prova seguem depois em conjunto. O nodo verifica a prova, em vez de reconstruir todo o processo de validação.

O framework EIP-8361 centra-se assim na admissão ao mempool baseada em provas, enquanto o processo de validação do mempool EIP-8361 define como os nodos recetores decidem aceitar, reter, estacionar ou remover estas transações.

Em 6 de agosto de 2026, o EIP-8361 encontra-se apresentado como pull request em rascunho n.º 12075, como proposta Standards Track Networking. Não introduz um novo tipo de transação nem altera o consenso Ethereum por si só.

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

A prova cobre uma afirmação específica, e não a totalidade dos resultados futuros de execução.

De forma simplificada, o provador deve demonstrar que:

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

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

Esta vinculação impede que uma prova válida para uma transação seja reutilizada noutra com dados, dependências, condições ou pagador diferentes.

A testemunha privada inclui a informação necessária 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 que cada nodo recetor tenha de o repetir.

O EIP-8361 propõe reutilizar o formato de prova e o mecanismo de verificação de entrada associados ao EIP-8288. O EIP refere STARKs por permitirem representar um cálculo extenso com uma prova sucinta e sem exigir que cada verificador reproduza o trabalho original.

Como é utilizado o vetor de assunções na validação de transações?

Uma prova criptográfica pode demonstrar a correção para inputs concretos, mas um nodo do mempool deve garantir que esses inputs refletem o estado Ethereum atual.

O EIP-8361 resolve isto com um vetor de assunções (A), que lista todos os valores de estado lidos 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 estão definidos:

• Assunções EQ: o valor de estado atual deve igualar o valor declarado na prova.
• Assunções GEQ: o valor de estado atual deve ser igual ou superior ao limite declarado.

Entradas EQ são adequadas para hashes de código, nonce ou ramos de armazenamento que mudam sempre que o valor subjacente muda. Entradas GEQ servem para requisitos monotónicos, como verificar que um pagador tem fundos suficientes para um pré-financiamento.

Por exemplo, se o prefixo de validação de uma smart account aprova uma transação apenas quando o saldo do paymaster é pelo menos 0,2 ETH, o provador pode registar uma assunção GEQ com esse limite. O nodo mantém a prova válida enquanto o saldo for 0,2 ETH ou superior, sem necessidade de nova prova a cada aumento.

Este design evita ancorar a prova a uma raiz de estado completa ou exigir uma prova de Merkle para todo o estado Ethereum. O circuito avalia o prefixo de validação com os valores declarados e o nodo compara-os com o seu estado atual.

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

O processo de validação segue uma ordem de verificações:

1. Executar verificações stateless. O nodo verifica a validade intrínseca da transação e assegura que a lista de dependências ou assinaturas está bem formada. Transações malformadas são rejeitadas antes da validação da prova.
2. Verificar a prova de admissão. O nodo valida o STARK com a chave de verificação designada. Falha significa ausência de validação estabelecida.
3. Verificar dependências externas. A prova pode assumir assinaturas ou dependências declaradas. O nodo valida-as separadamente e confirma a correspondência com o hash de dependências.
4. Verificar condições de validade. O nodo avalia as condições declaradas, como prazos, janelas de slot ou época, intervalos de caducidade ou requisitos de nonce.
5. Comparar assunções com o estado em tempo real. Entradas EQ são testadas para igualdade, GEQ face ao limite.
6. Admitir a transação. Com todas as verificações bem-sucedidas, o nodo pode aceitar e propagar a transação sem simular o prefixo de validação completo.

Este processo impede que a prova contorne as verificações estruturais, de assinatura, estado ou temporais. Modifica o método computacional da decisão de admissão, não os critérios 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.

Com o EIP-8361, o nodo revê as condições de validade e o vetor de assunções sempre que um novo bloco altera a chain head. Não é preciso regenerar a prova, voltar a executar o prefixo de validação ou verificar a mesma prova. A prova previamente validada mantém-se como resultado em cache para os inputs declarados.

Uma falha EQ normalmente invalida a prova, pois um input exato mudou. O nodo remove a transação, exceto se o remetente apresentar nova prova ou a transação for elegível para admissão simulada normal.

Uma condição GEQ falhada pode ser tratada de modo diferente: o nodo pode estacionar a transação em vez de a remover. Se o pagador ou paymaster receber fundos suficientes, o nodo pode reativar a transação ao verificar novamente o limite.

Esta distinção faz do vetor de assunções mais do que um compromisso ao estilo Merkle com um estado histórico; define que alterações invalidam a aprovação e quais permanecem compatíveis.

Porque é que a prova é descartada após a inclusão em bloco?

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

Assim que um validador inclui a transação num bloco, o Ethereum processa-a pela execução normal do protocolo. A EVM executa o prefixo de validação e os frames restantes segundo o estado canónico do bloco. Os clientes de consenso determinam a validade do bloco segundo as regras do Ethereum.

Assim, a prova de admissão:

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

Descartá-la evita custos de calldata e crescimento de estado para informação que já cumpriu o seu propósito de networking. A transação permanece on-chain, mas o envelope de prova temporário não.

Sistema de provas EIP-8361 vs. provas de validade de ZK-rollup

O EIP-8361 utiliza provas criptográficas, mas a sua prova de admissão não é equivalente às provas de validade dos ZK rollups.

ZK rollups usam ZK-SNARKs ou ZK-STARKs para provar a correção de lotes de transações. Quando a prova é aceite pelo contrato Layer 1, o rollup pode finalizar a transição de estado sem esperar pelo período de desafio de fraude dos rollups otimistas.

O EIP-8361 não prova um lote L2, não autoriza levantamentos imediatos de rollup nem garante que uma cadeia L2 nunca entra em estado inválido. A sua prova é um artefacto temporário de networking sobre validação pré-inclusão.

Apesar de provas de conhecimento zero poderem verificar uma afirmação sem revelar todos os dados subjacentes, o EIP-8361 não é uma proposta de privacidade. “Prova sucinta” e “conhecimento zero” são propriedades relacionadas, mas distintas.

Levantamentos de Layer 2 para Layer 1 podem ser mais rápidos com provas de validade porque ZK rollups não exigem o período de desafio de fraude dos rollups otimistas. O tempo final de levantamento depende ainda da geração da prova, verificação em Layer 1, regras de ponte e finalização Ethereum. O EIP-8361 não fornece este mecanismo; a sua prova suporta a admissão ao mempool de uma transação em frame EIP-8141, não a liquidação de um lote Layer 2.

Como funcionam as provas de fraude em rollups otimistas?

As provas de fraude baseiam-se num mecanismo diferente. Um rollup otimista aceita uma transição de estado proposta e permite desafios durante um período de disputa. Resolver uma disputa pode exigir múltiplas rondas ou uma prova de execução restrita.

O EIP-8361 estabelece a afirmação de admissão antes de a transação ser aceite no mempool relevante. Não existe período de desafio pós-admissão para contestar o resultado do prefixo.

A diferença central é o momento e o âmbito:

• Uma prova de validade demonstra a afirmação antes da aceitação.
• Uma prova de fraude permite uma afirmação otimista, salvo contestação.
• A prova de admissão EIP-8361 diz respeito à política de mempool.
• A prova de fraude de rollup diz respeito à correção de uma transição de estado L2.

As compensações entre execução EVM repetida e verificação sucinta são detalhadas em EIP-8361 versus simulação de transação, incluindo cenários em que o custo de geração de prova substitui o custo de simulação no nodo.

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

Contas programáveis podem recorrer a autorização multisignature, rotação de chaves, regras de recuperação, esquemas de assinatura não padronizados, candidatos a assinaturas pós-quânticas, políticas de gasto ou verificações zero-knowledge dispendiosas em Gas. Parte desta lógica pode ser válida, mas demasiado cara para simulação em todos os nodos do mempool.

O EIP-8361 permite a propagação pública de transações para estas contas, tornando a validação dispendiosa para o provador, mas acessível para cada verificador. Pode ainda reduzir a pressão para transferir autorizações complexas para a fase de execução, onde uma falha pode tornar-se uma transação revertida e registada publicamente.

Este mecanismo não torna todos os contratos inteligentes seguros nem garante segurança pós-quântica. Um STARK pode evitar certas assunções de sistemas baseados em curvas elípticas, mas a transação pode depender de chaves públicas, esquemas de assinatura, implementações, 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, conforme resumido em impacto do EIP-8361 em carteiras, nodos e programadores.

Por exemplo, um negociador que avalie o impacto de desenvolvimentos de abstração de contas Ethereum no sentimento de mercado pode comparar marcos da proposta com o gráfico de mercado ETH/USDT, embora a ação do preço não confirme implementação ou adoção de um EIP em rascunho.

Riscos e limitações

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

O mecanismo implica também riscos técnicos:

Concentração de geração de provas: Produzir um STARK pode exigir software especializado e computação significativa. Se poucos serviços gerarem provas eficientemente, carteiras podem depender de infraestrutura centralizada.

Pressão de negação de serviço: Verificar provas é mais barato do que repetir o cálculo, mas não é gratuito. São necessários limites de tamanho de prova, limites de taxa entre pares e atribuição de falhas para evitar ataques de provas inválidas ou excessivas.

Completude das assunções: A prova só é válida se o vetor de assunções contiver todos os estados lidos pelo prefixo de validação. Bugs que omitam dependências podem originar decisões de admissão incorretas.

Desatualização do estado: Uma prova pode manter-se criptograficamente correta mesmo que as condições declaradas já não reflitam o estado atual. Os nodos devem continuar a verificar A e C enquanto a transação estiver em pool.

Sem garantia de execução: A admissão no mempool não assegura inclusão em bloco ou execução final. Outras transações podem alterar nonce, saldo, código, armazenamento ou outros estados relevantes antes da inclusão.

Complexidade de implementação: Clientes, carteiras e provadores devem alinhar-se na codificação da prova, chaves de verificação, gestão de dependências, comportamento entre pares e regras de revalidação. Divergências podem fragmentar a propagação de transações.

O EIP-8361 é a proposta Tapered Issuance Burn?

Discussões iniciais associaram o número EIP-8361 a uma proposta distinta de política monetária Ethereum, Tapered Issuance Burn. Essa proposta foi depois identificada como EIP-8363, enquanto o EIP-8361 refere-se a Provas de Validade de Transação na categoria networking. São propostas distintas: o EIP-8361 aborda admissão ao mempool baseada em provas; Tapered Issuance Burn altera a economia de recompensas ao nível do consenso com base no saldo de staking ativo.

Conclusão

As provas de validade de transação EIP-8361 transferem o custo de validação de transações programáveis de cada nodo recetor para um provador off-chain. O STARK resultante vincula uma transação EIP-8141 ao seu resultado de aprovação, pagador, dependências, condições e assunções de estado, permitindo aos nodos validar uma afirmação concisa antes da admissão no mempool.

O mecanismo é útil quando uma smart account tem lógica de validação legítima que excede limites práticos de simulação. A principal restrição: a prova só se aplica à admissão ao nível de networking. O Ethereum executa a transação normalmente na inclusão, e a prova temporária é descartada porque não tem papel de consenso nem on-chain.

Perguntas Frequentes

Como é que os 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 construída com ZK-SNARKs, ZK-STARKs ou compromissos polinomiais, permite a um contrato Ethereum validar a transição de estado sem repetir todas as transações.

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

As provas de validade impedem que um verificador L1 aceite uma transição de estado inválida, desde que circuito, contrato verificador, criptografia e implementação estejam corretos. Não eliminam riscos de código defeituoso, disponibilidade de dados, pontes, sequenciadores, governança ou controlos de atualização.

Porque é que os levantamentos em ZK-rollups são normalmente mais rápidos?

ZK rollups podem finalizar levantamentos após a prova de validade ser submetida e validada, sem esperar pelo período de desafio dos rollups otimistas. Levantamentos podem depender ainda da geração da prova, submissão do lote, regras de ponte e finalização Ethereum, pelo que “imediato” nem sempre significa instantâneo.

Como diferem as provas de validade das provas de fraude?

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

As provas de conhecimento zero escondem sempre os dados da transação?

Não. Provas de conhecimento zero podem validar uma afirmação sem revelar a testemunha privada, mas a privacidade depende dos inputs ocultos. Muitos ZK rollups usam provas ZK 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 exigem configuração de confiança. ZK-STARKs não requerem configuração de confiança e são considerados mais resistentes a ataques de computação quântica, mas as provas são maiores.

O que verifica uma prova de Merkle?

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

As provas de validade reduzem o consumo de recursos on-chain?

Sim, podem comprimir um cálculo off-chain extenso numa prova única, mais barata de validar on-chain do que repetir todas as transações. A poupança depende do custo de validação da prova, tamanho do lote, uso de calldata ou blob e implementação do rollup.

As provas de validade reduzem o risco de um ataque 51%?

Não diretamente. Provas de validade protegem a correção de transições de estado Layer 2 validadas, enquanto um ataque de 51% diz respeito ao controlo do consenso Ethereum e escolha de fork. São mecanismos para riscos diferentes.

As 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 levantamentos. Provas EIP-8361 suportam admissão ao mempool de transações em frame EIP-8141, ficam fora do bloco e são descartadas após inclusão ou remoção.

Isenção de responsabilidade

Este conteúdo é educativo e descreve uma proposta Ethereum em rascunho cuja especificação e implementação podem mudar. Não constitui aconselhamento financeiro, de segurança ou de implementação de software. Os programadores devem consultar o texto EIP mais recente e os requisitos dos clientes antes de desenvolver sistemas de produção.