O que é a EIP-8361? Explicação sobre as provas de validade na Ethereum

EIP-8361 trata exclusivamente da admissão baseada em prova para transações frame do EIP-8141, sem substituir a execução do Ethereum, criar novos tipos de transação, implantar contratos inteligentes, oferecer privacidade, alterar recompensas de validadores ou definir um prazo de implementação de 18 meses. Seu objetivo prático é reduzir a computação redundante na validação de transações, mantendo salvaguardas contra transações inválidas ou que consomem muitos recursos.

As seções a seguir detalham o funcionamento do processo de admissão baseada em prova, o que os nós verificam, as diferenças entre EIP-8361, provas de validade de rollup e simulação de transações, além das limitações técnicas ainda pendentes.

Principais pontos

• O EIP-8361 padroniza dados de prova de validade de transação para propagação peer-to-peer. Uma transação frame pode incluir um STARK comprovando que seu prefixo de validação atinge um estado aprovado.
• Nós verificam a prova ao invés de repetir lógicas de autorização custosas. Essa separação entre geração de prova e verificação pode reduzir a computação repetida entre nós do Ethereum.
• A prova permanece fora do consenso. Ela é transportada junto à transação, utilizada para admissão no mempool e descartada quando não for mais necessária.
• O design suporta validação complexa de smart accounts. Exemplos incluem regras de multissinatura, sistemas alternativos de assinatura, paymasters e autorizações baseadas em prova.
• 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, chamado Provas de Validade de Transação, propõe um mecanismo de rede no qual uma transação Ethereum pode ser enviada com evidência criptográfica de que sua lógica de validação a aprova. O rascunho complementa as mudanças de protocolo do EIP-8141, que define transações frame e estágios programáveis de validação.

Uma Proposta de Melhoria do Ethereum (EIP) é um documento técnico que descreve um possível padrão, funcionalidade de protocolo, interface ou processo para o Ethereum. A publicação como EIP não garante aceitação ou implementação. O EIP-8361 segue em rascunho, podendo ter especificação, dependências e status alterados.

A proposta responde à questão:

Como um nó pode admitir com segurança uma transação cuja autorização é cara sem exigir que cada peer repita esse processamento?

No EIP-8361, um provador executa a lógica de validação relevante da transação off-chain e gera um STARK. O nó receptor verifica a prova, confere as suposições declaradas em relação ao estado atual do Ethereum e decide se inclui a transação no mempool público.

A transação ainda deve ser válida sob as regras de execução do Ethereum ao ser incluída em um bloco. A prova serve à política de admissão, não substitui a execução em nível de protocolo nem a validação de consenso.

Por que validar transações complexas no Ethereum é difícil

Uma conta de propriedade externa (EOA) é controlada por uma chave privada e sua chave pública correspondente. A conta autoriza uma transação com assinatura ECDSA e a transação define campos como nonce, endereço de destino, valor, chain ID, limite de gas e preço de gas ou parâmetros de taxa do EIP-1559.

Essas verificações são previsíveis. Um nó pode validar a assinatura, checar saldo suficiente para cobrir valor e gas, conferir nonce e rejeitar transações malformadas ou repetidas.

Smart accounts ampliam a superfície de validação. Em vez de depender de uma única chave privada, podem usar:

• 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 conhecimento zero;
• código de autorização específico para a aplicação.

Essa lógica pode estar em um contrato inteligente já implantado ou em um novo contrato criado ao implantar a conta. A criação e implantação podem exigir validação de uma factory, código de inicialização ou endereço futuro.

Nós do Ethereum não podem executar código de validação ilimitado para cada transação não confirmada. Um atacante poderia enviar transações fraudulentas que invocam contratos inteligentes caros, funções de hash, leituras de armazenamento ou sistemas de prova, sem autorizar execução. Mesmo inválidas, a verificação consome recursos do nó.

Provas de validade de transação EIP-8361 transferem o trabalho caro para o provador, mantendo a verificação da prova limitada.

Como funcionam 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 nó executa o prefixo de validação.
2. Admissão baseada em prova: o nó verifica um STARK comprovando aprovação do prefixo de validação.

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

1. Uma transação define sua lógica de validação

Uma transação frame do EIP-8141 pode dividir o trabalho em frames com diferentes propósitos. Alguns frames estabelecem autorização, identificam o pagador ou preparam a execução. O prefixo de validação roda antes dos frames normais de execução.

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

O EIP-8141 difere de uma transação convencional, onde uma assinatura ECDSA reconhecida determina o remetente. Seu modelo programável de validação faz parte do movimento do Ethereum para abstração nativa de contas. O EIP-8141 evita depender da lista de autorizações baseada em ECDSA do EIP-7702, buscando maior flexibilidade criptográfica.

2. Um provador executa o prefixo de validação

O provador executa o prefixo de validação da transação com um conjunto de entradas e suposições de estado declarados. Esse processo pode incluir:

• assinatura correspondente à chave pública;
• saldo suficiente da conta remetente;
• saldo do paymaster acima do mínimo;
• slot de armazenamento do contrato com permissão esperada;
• chain ID correspondente à rede Ethereum;
• nonce que evita replay;
• código de validação termina com aprovação.

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

3. A prova declara suposições de estado

Uma prova criptográfica não é útil se depender de um estado já alterado. O EIP-8361 propõe um vetor de suposições descrevendo os fatos de estado usados na geração da prova.

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

Essas suposições conectam a prova a um estado válido anterior sem incorporar todo o estado do Ethereum. Quando um novo bloco altera dados relevantes, o nó pode revalidar o vetor de suposições.

Esse mecanismo é central para a validação de mempool do EIP-8361: o nó não confia cegamente em uma prova antiga só porque sua criptografia permanece válida.

4. Nós verificam o STARK

O nó receptor faz checagens estruturais de baixo custo antes de verificar a prova. Em seguida, valida o STARK com a chave de verificação especificada e confere dependências e suposições declaradas em relação ao estado atual do Ethereum.

Sistemas modernos de prova produzem provas mais rápidas de verificar do que reexecutar o cálculo original. Assim, uma prova pode substituir simulação repetida de vários peers, reduzindo computação redundante na rede peer-to-peer.

A geração da prova não é barata. Produzir um STARK pode exigir processamento, memória e software especializado. A proposta transfere a computação, não a elimina.

5. A transação entra no mempool

Com sucesso nas verificações de prova e estado, o nó pode admitir e propagar a transação sem repetir o prefixo de validação caro.

A prova permanece como metadado peer-to-peer, não é adicionada à calldata, nem armazenada por contrato inteligente implantado, nem escrita no estado da conta ou incluída na raiz de Merkle do bloco.

Após incluída, o Ethereum executa a transação sob as regras de protocolo. Se a prova ficar obsoleta ou a transação for removida, os metadados de rede podem ser descartados.

O que uma prova de validade EIP-8361 comprova?

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

Ela pode demonstrar que a lógica de validação conferiu assinatura válida, saldo suficiente, nonce correto, pagador permitido ou autorização definida por contrato. Não comprova, porém, a correção de todas as transições de estado EVM subsequentes.

A distinção é relevante:

• EIP-8361 comprova validação para admissão.
• Prova de validade de rollup comprova uma ou mais transições de estado off-chain.
• Prova de Merkle comprova inclusão em estrutura de dados autenticada.
• Prova de conhecimento zero pode ocultar informações, mas validade não garante privacidade.

Uma prova de Merkle mostra que uma transação pertence a um lote, bloco ou árvore de estado ao conectar uma folha a uma raiz de Merkle conhecida. Em ZK rollups, essas provas podem demonstrar existência de contas e atualização de saldos.

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

EIP-8361 vs provas de validade de ZK-Rollup

Soluções de escalabilidade de camada 2 usam provas de validade de modo mais amplo. Um ZK rollup executa um lote de transações off-chain e envia uma prova sucinta para um contrato verificador no Ethereum. Essa prova mostra que o lote transformou o estado anterior em um novo estado correto.

Em vez de reexecutar cada transação, o contrato verificador valida a prova e os inputs públicos. Isso reduz consumo on-chain e distribui taxas de gas entre várias transações. Provas recursivas podem agregar múltiplas provas em uma.

Provas de validade evitam que ZK rollups finalizem transições de estado inválidas, supondo que sistema de provas, circuito, contrato verificador e modelo de disponibilidade de dados sejam seguros. Também permitem finalização L2-L1 mais rápida do que sistemas com janela de disputa.

O EIP-8361 é diferente. Não comprova lote de computação, nem atualiza raiz de Merkle L2 ou aciona saque. Comprova que uma transação frame atende aos requisitos de admissão de um nó.

Provas de validade EIP-8361 vs provas de fraude

Rollups otimistas assumem que atualizações de estado submetidas são válidas, salvo contestação. Provas de fraude exigem que observadores detectem transições contestadas e forneçam evidência durante o período de challenge. Uma reivindicação inválida pode ser aceita até resolução da disputa.

Sistemas de provas de validade fazem o oposto: um novo compromisso de estado só é aceito após o verificador confirmar evidência criptográfica de execução correta. Isso permite saques mais rápidos, já que usuários não precisam esperar por challenge de fraude.

Afirmar que provas de validade são sempre “mais seguras” que provas de fraude é generalização indevida. Diferenças envolvem complexidade do provador, segurança do verificador, disponibilidade de dados, trusted setup, suposições de challenge e maturidade da implementação.

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

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

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

Cada tupla de autorização inclui:

• chain_id;
• endereço do contrato delegado;
• nonce da conta;
• campos de assinatura.

A autorização é assinada pela chave privada do EOA. O assinante pode ser diferente de tx.origin, e uma transação pode carregar autorizações de múltiplos EOAs. Cada autorização pode atualizar o indicador de delegação antes da execução normal.

Isso permite delegar execução para contratos inteligentes com autorizações assinadas, sem converter a conta em contrato inteligente implantado. O código delegado pode dar suporte a batching, patrocínio de gas, permissões ou outros comportamentos de smart account.

O EIP-7702 traz considerações de segurança. Um chain ID igual a zero pode tornar uma autorização válida entre chains, enquanto 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. Ele trata de como nós podem admitir transações com validação complexa. As diferenças entre provas de validade do EIP-8361 e simulação de transação envolvem computação no mempool, não delegação de código de EOA.

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

O EIP-7701 foi criado em 1 de maio de 2024 como proposta de abstração nativa de conta. Dividiu o processamento de transações em validação, execução e pós-operação e propôs novo tipo de transação EIP-2718.

O design usava endereço de entry-point nativo 0x7701, opcodes baseados em função, validação separada de remetente e paymaster e pagamento de gas controlado por contrato. Não exigia o fluxo de bundler ERC-4337.

O EIP-7701 foi retirado, substituído pelo EIP-8141. A especificação publicada lista o motivo da retirada. A exigência de contratos no formato EOF não faz parte da especificação final.

O EIP-8361 se baseia no modelo de transação frame do EIP-8141, apoiando um caminho de abstração de conta em nível de protocolo ao tornar validações programáveis caras mais seguras de propagar.

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

Impacto prático para carteiras, nós e desenvolvedores

Desenvolvedores de carteira podem usar admissão baseada em prova quando a autorização da smart account for cara demais para simulação comum de mempool. A carteira pode solicitar prova de provador local, serviço ou rede distribuída antes de enviar a transação.

Desenvolvedores de nós precisam implementar:

• transporte de provas 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.

Desenvolvedores de contratos inteligentes podem manter validação específica da aplicação sem exigir execução total de todos os nós. Isso pode dar suporte a assinaturas pós-quânticas, políticas de múltiplas chaves, paymasters complexos ou permissões baseadas em prova.

O impacto do EIP-8361 para carteiras, nós e desenvolvedores dependerá de latência de prova, adoção de clientes, interoperabilidade e da especificação final do EIP-8141.

Por exemplo, um trader avaliando reação do mercado em uma exchange como a Gate a uma atualização futura do Ethereum pode comparar anúncios de rede com o gráfico ETH/USDT. Preço de mercado, volume ou taxas de gas não determinam se um EIP em rascunho foi aceito ou ativado.

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

O EIP-8361 traz diversas considerações de segurança.

A solidez da prova depende da correção do circuito STARK e da chave de verificação. Um bug pode comprovar algo fora das regras de validação.

A verificação da prova consome computação e banda. Atacantes podem enviar provas malformadas ou grandes demais, exigindo checagens preliminares, limites de tamanho e atribuição de peers.

Suposições podem ficar obsoletas. Uma prova válida para saldo, armazenamento, hash de código ou nonce pode perder validade após um novo bloco.

Políticas de nó inconsistentes podem fragmentar a propagação de transações. Clientes diferentes podem adotar limites distintos.

A geração de provas pode centralizar se poucos serviços tiverem hardware ou software suficiente.

O EIP-8361 não elimina custos normais de transação. Se a transação for executada em bloco, o remetente ou pagador arca com o gas. A prova de validade reduz computação redundante off-chain, mas não elimina taxas de gas do Ethereum.

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

Diversas 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;
• remove piso de rendimento de staking;
• limita recompensas de validadores;
• deduz recompensas conforme staking se aproxima de 50%;
• cria equilíbrio de staking baseado em mercado;
• introduz lista de autorizações do EIP-7702;
• introduz entry point do EIP-7701;
• cria novo tipo de transação EIP-2718;
• garante privacidade;
• liquida batches de ZK-rollup;
• substitui provas de fraude;
• renuncia a direitos contratuais ou relacionados dos usuários.

A seção de direitos autorais pode declarar renúncia de direitos sob CC0, comum para EIPs. Esse aviso legal refere-se ao documento, não a fundos de usuários, 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, gera um STARK e permite que diversos nós verifiquem o resultado sem repetir a computação cara.

O principal caso de uso é autorização programável que excede limites comuns de validação de mempool, incluindo smart accounts avançadas, sistemas alternativos de assinatura, paymasters e contratos baseados em prova. O design pode reduzir computação redundante, mantendo suposições de estado visíveis e verificáveis.

O EIP-8361 não deve ser confundido com liquidação de ZK-rollup, provas de fraude, delegação de conta EIP-7702 ou o EIP-7701 retirado. Permanece um rascunho de proposta de rede, cuja segurança, economia, interoperabilidade e dependências exigem desenvolvimento adicional antes de qualquer implementação no Ethereum.

Perguntas frequentes

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

Não. Ele aplica admissão baseada em prova para transações frame do EIP-8141. O EIP-2718 fornece o framework geral de transações tipadas, mas o EIP-8361 não cria outro envelope.

Provas do EIP-8361 são zero-knowledge proofs?

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.

Uma prova cobre múltiplas transações?

Sistemas de prova podem agregar cálculos ou usar provas recursivas, e rollups podem comprimir várias provas em uma. O EIP-8361 foca na admissão de uma transação frame, não na agregação arbitrária de lotes.

O EIP-8361 reduz taxas de gas?

Não diretamente. A proposta pode reduzir computação off-chain repetida, mas uma transação incluída ainda paga o gas da execução no Ethereum.

Como o EIP-8361 difere do EIP-7702?

O EIP-7702 permite delegação de execução de código por tuplas de autorização assinadas. O EIP-8361 propõe admissão de transações com validação programável cara baseada em prova.

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, premissas de segurança e suporte de rede podem mudar. Desenvolvimentos de protocolo e dados históricos de mercado não preveem desempenho futuro do ETH.