Fundação Ethereum traça caminho para provas zkEVM na L1 da mainnet

A Ethereum Foundation publicou um plano passo a passo para permitir que a cadeia principal do Ethereum valide blocos usando provas zkEVM, reduzindo a necessidade de os validadores executarem novamente cada computação. A proposta, partilhada via X a 15 de janeiro por Tomasz K. Stańczak, Codiretor Executivo da Ethereum Foundation, delineia o trabalho de engenharia necessário nos clientes de execução e consenso do Ethereum, além de nova infraestrutura de prova e processos de segurança.

Ethereum L1 Avança para Validação Baseada em Prova zk

Já em julho do ano passado, a Ethereum Foundation anunciou a sua abordagem "zk-first". Atualmente, os validadores do Ethereum normalmente verificam um bloco executando novamente as transações e comparando os resultados. O plano propõe uma alternativa: os validadores poderiam verificar uma prova criptográfica de que a execução do bloco estava correta.

O documento resume o pipeline pretendido em termos simples: um cliente de execução produz um pacote "testemunha" compacto para um bloco, um programa zkEVM padronizado usa esse pacote para gerar uma prova de execução correta, e os clientes de consenso verificam essa prova durante a validação do bloco.

O primeiro marco é criar uma "ExecutionWitness", uma estrutura de dados por bloco contendo a informação necessária para validar a execução sem executá-la novamente. O plano exige um formato de testemunha formal nas especificações de execução do Ethereum, testes de conformidade e um endpoint RPC padronizado. Observa que o endpoint debug_executionWitness atual já está "a ser usado em produção pelo Kona do Optimism", sugerindo que um endpoint mais amigável para zk pode ser necessário.

Uma dependência chave é adicionar melhor rastreamento de quais partes do estado um bloco toca, através de Block Level Access Lists (BALs). O documento afirma que, a partir de novembro de 2025, este trabalho não foi tratado como suficientemente urgente para ser retroportado para forks anteriores.

O próximo marco é um "programa convidado zkEVM", descrito como lógica de validação sem estado que verifica se um bloco produz uma transição de estado válida quando combinado com a sua testemunha. O plano enfatiza compilações reproduzíveis e compilação para alvos padronizados para que as suposições sejam explícitas e verificáveis.

Além do código específico do Ethereum, o plano visa padronizar a interface entre zkVMs e o programa convidado: alvos comuns, formas comuns de aceder a precompiles e I/O, e suposições acordadas sobre como os programas são carregados e executados.

Do lado do consenso, o roteiro exige alterações para que os clientes de consenso possam aceitar provas zk como parte da validação de blocos beacon, com especificações acompanhantes, vetores de teste e um plano de implementação interna. O documento também sinaliza a disponibilidade de payload de execução como importante, incluindo uma abordagem que poderia envolver "colocar o bloco em blobs".

A proposta trata a geração de provas como um problema operacional tanto quanto um problema de protocolo. Inclui marcos para integrar zkVMs em ferramentas EF como Ethproofs e Ere, testar configurações de GPU (incluindo "zkboost") e rastrear confiabilidade e gargalos.

O benchmarking é enquadrado como trabalho em curso, com objetivos explícitos como medir o tempo de geração de testemunhas, tempo de criação e verificação de provas, e o impacto na rede da propagação de provas. Essas medições poderiam alimentar propostas futuras de repreçamento de gas para cargas de trabalho pesadas em zk.

A segurança também é marcada como perpétua, com planos para especificações formais, monitoramento de riscos em tempo real, controlos de cadeia de fornecimento como compilações reproduzíveis e assinatura de artefactos, e um modelo documentado de confiança e ameaças. O documento propõe uma "estrutura go/no-go" para decidir quando os sistemas de prova estão suficientemente maduros para uso mais amplo.

Uma dependência externa destaca-se: ePBS, que o documento descreve como necessária para dar aos provers mais tempo. Sem ela, o plano diz que o prover tem "1–2 segundos" para criar uma prova; com ela, "6–9 segundos". O documento acrescenta um enquadramento de duas frases que captura a urgência: "Este não é um projeto em que estamos a trabalhar. No entanto, é uma otimização de que precisamos." Espera-se que o ePBS seja implementado em "Glamsterdam", previsto para meados de 2026.

Se estes marcos forem alcançados, o Ethereum estará a avançar para a validação baseada em provas como uma opção prática no L1, enquanto o timing e a complexidade operacional da prova permanecem os fatores limitantes.

No momento da publicação, o ETH era negociado a $3.300.