Ethereum quer que validadores domésticos verifiquem provas, mas a realidade de 12 GPUs levanta uma nova ameaça

O pesquisador do Ethereum ladislaus.eth publicou na semana passada um guia explicando como o Ethereum planeia passar da re-execução de cada transação para a verificação de Provas de conhecimento zero.

A publicação apresenta-a como uma "transformação silenciosa mas fundamental", e o enquadramento é preciso. Não porque o trabalho seja secreto, mas porque as suas implicações propagam-se por toda a arquitetura do Ethereum de formas que não serão óbvias até que as peças se conectem.

Isto não é o Ethereum a "adicionar ZK" como funcionalidade. O Ethereum está a criar um protótipo de um caminho de validação alternativo no qual alguns validadores podem atestar blocos verificando provas de execução compactas em vez de re-executar cada transação.

Se funcionar, o papel da camada-1 do Ethereum muda de "liquidação e disponibilidade de dados para rollups" para "execução de alto débito cuja verificação permanece suficientemente económica para validadores domésticos."

O que está realmente a ser construído

A EIP-8025, intitulada "Provas de Execução Opcionais", foi apresentada em forma de rascunho e especifica a mecânica.
As provas de execução são partilhadas através da rede peer-to-peer da camada de consenso através de um tópico dedicado. Os validadores podem operar em dois novos modos: geração de provas ou validação sem estado.

A proposta afirma explicitamente que "não requer um hard fork" e permanece retrocompatível, enquanto os nós ainda podem re-executar como fazem atualmente.

A equipa zkEVM da Ethereum Foundation publicou um roteiro concreto para 2026 a 26 de janeiro, delineando seis sub-temas: testemunha de execução e padronização de programas convidados, padronização de API zkVM-guest, integração da camada de consenso, infraestrutura de prova, benchmarking e métricas, e segurança com verificação formal.

A primeira chamada de breakout L1-zkEVM está agendada para 11 de fevereiro às 15:00 UTC.

O pipeline end-to-end funciona assim: um cliente da camada de execução produz uma ExecutionWitness, um pacote autocontido contendo todos os dados necessários para validar um bloco sem manter o estado completo.

Um programa convidado padronizado consome essa testemunha e valida a transição de estado. Uma zkVM executa este programa, e um prover gera uma prova de execução correta. O cliente da camada de consenso verifica então essa prova em vez de chamar o cliente da camada de execução para re-executar.

A dependência chave é o ePBS (Enshrined Proposer-Builder Separation), previsto para o próximo hard fork Glamsterdam. Sem o ePBS, a janela de prova é de aproximadamente um a dois segundos, o que é demasiado apertado para prova em tempo real. Com o ePBS a fornecer pipelining de blocos, a janela estende-se para seis a nove segundos.

O compromisso da descentralização

Se as provas opcionais e os formatos de testemunha amadurecerem, mais validadores domésticos podem participar sem manter o estado completo da camada de execução.

Aumentar os limites de gas torna-se política e economicamente mais fácil porque o custo de validação desacopla-se da complexidade de execução. O trabalho de verificação já não escala linearmente com a atividade on-chain.

No entanto, a prova carrega o seu próprio risco de centralização. Uma publicação da Ethereum Research de 2 de fevereiro relata que provar um bloco completo do Ethereum requer atualmente aproximadamente 12 GPUs e demora uma média de 7 segundos.

O autor assinala preocupações sobre centralização e nota que os limites permanecem difíceis de prever. Se a prova permanecer pesada em GPU e se concentrar em redes de construtores ou provers, o Ethereum pode trocar "todos re-executam" por "poucos provam, muitos verificam."

O design visa abordar isto introduzindo diversidade de clientes na camada de prova. A suposição de trabalho da EIP-8025 é um limiar de três-em-cinco, o que significa que um atestador aceita a execução de um bloco como válida assim que tenha verificado três de cinco provas independentes de diferentes implementações de clientes da camada de execução.

Isto preserva a diversidade de clientes ao nível do protocolo, mas não resolve o problema de acesso ao hardware.

O enquadramento mais honesto é que o Ethereum está a mudar o campo de batalha da descentralização. A restrição de hoje é "pode pagar para executar um cliente da camada de execução?" A de amanhã pode ser "pode aceder a clusters de GPU ou redes de prover?"

A aposta é que a verificação de provas é mais fácil de mercantilizar do que o armazenamento de estado e a re-execução, mas a questão do hardware permanece em aberto.

Desbloqueio da escalabilidade L1

O roteiro do Ethereum, atualizado pela última vez a 5 de fevereiro, lista "Statelessness" como um tema principal de atualização: verificar blocos sem armazenar estado grande.

As provas de execução opcionais e as testemunhas são o mecanismo concreto que torna prática a validação sem estado. Um nó sem estado requer apenas um cliente de consenso e verifica provas durante o processamento de payload.

A sincronização reduz-se a descarregar provas para blocos recentes desde o último checkpoint de finalização.

Isto importa para os limites de gas. Hoje, cada aumento no limite de gas torna mais difícil executar um nó. Se os validadores podem verificar provas em vez de re-executar, o custo de verificação já não escala com o limite de gas. A complexidade de execução e o custo de validação desacoplam-se.

O fluxo de trabalho de benchmarking e repricing no roteiro de 2026 visa explicitamente métricas que mapeiam gas consumido para ciclos de prova e tempo de prova.

Se essas métricas estabilizarem, o Ethereum ganha uma alavanca que não teve antes: a capacidade de aumentar o débito sem aumentar proporcionalmente o custo de executar um validador.

O que isto significa para blockchains de camada-2

Uma publicação recente de Vitalik Buterin argumenta que as blockchains de camada-2 devem diferenciar-se além da escalabilidade e vincula explicitamente o valor de um "precompile de rollup nativo" à necessidade de provas zkEVM consagradas que o Ethereum já precisa para escalar a camada-1.

A lógica é direta: se todos os validadores verificam provas de execução, as mesmas provas também podem ser usadas por um precompile EXECUTE para rollups nativos. A infraestrutura de prova da camada-1 torna-se infraestrutura partilhada.

Isto muda a proposta de valor da camada-2. Se a camada-1 pode escalar para alto débito mantendo os custos de verificação baixos, os rollups não se podem justificar com base em "o Ethereum não consegue lidar com a carga."

Os novos eixos de diferenciação são máquinas virtuais especializadas, latência ultra-baixa, pré-confirmações e modelos de composabilidade como rollups que dependem de designs de prova rápida.

O cenário em que as camadas-2 permanecem relevantes é aquele em que os papéis são divididos entre especialização e interoperabilidade.

A camada-1 torna-se a camada de execução e liquidação de alto débito e baixo custo de verificação. As camadas-2 tornam-se laboratórios de funcionalidades, otimizadores de latência e pontes de composabilidade.

No entanto, isso requer que as equipas de camada-2 articulem novas propostas de valor e que o Ethereum entregue o roteiro de verificação de provas.

Três caminhos a seguir

Existem três cenários potenciais no futuro.

O primeiro cenário consiste em a validação proof-first tornar-se comum. Se as provas opcionais e os formatos de testemunha amadurecerem e as implementações de clientes se estabilizarem em torno de interfaces padronizadas, mais validadores domésticos podem participar sem executar o estado completo da camada de execução.

Os limites de gas aumentam porque o custo de validação já não se alinha com a complexidade de execução. Este caminho depende do fluxo de trabalho de padronização da ExecutionWitness e do programa convidado convergir em formatos portáteis.

O cenário dois é onde a centralização de prover se torna o novo ponto de estrangulamento. Se a prova permanecer pesada em GPU e concentrada em redes de construtores ou prover, então o Ethereum muda o campo de batalha da descentralização do hardware dos validadores para a estrutura de mercado de prover.

O protocolo ainda funciona, já que um prover honesto em qualquer lugar mantém a cadeia viva, mas o modelo de segurança muda.

O terceiro cenário é a verificação de provas da camada-1 tornar-se uma infraestrutura partilhada. Se a integração da camada de consenso endurecer e o ePBS entregar a janela de prova estendida, então a proposta de valor das camadas-2 inclina-se para VMs especializadas, latência ultra-baixa e novos modelos de composabilidade em vez de apenas "escalar o Ethereum."

Este caminho requer que o ePBS seja entregue no prazo para Glamsterdam.

O panorama geral

A maturidade de integração das consensus-specs sinalizará se "provas opcionais" passam de maioritariamente TODOs para vetores de teste endurecidos.

Padronizar a ExecutionWitness e o programa convidado é a pedra angular para a portabilidade de validação sem estado entre clientes. Benchmarks que mapeiam gas consumido para ciclos de prova e tempo de prova determinarão se o repricing de gas para amigabilidade ZK é viável.

O progresso do ePBS e Glamsterdam indicará se a janela de prova de seis a nove segundos se torna realidade. As saídas das chamadas de breakout revelarão se os grupos de trabalho convergem em interfaces e semântica de distribuição de prova mínima viável.

O Ethereum não está a mudar para validação baseada em prova em breve. A EIP-8025 afirma explicitamente que "não pode basear atualizações nela ainda", e o enquadramento opcional é intencional. Como resultado, este é um caminho testável em vez de uma ativação iminente.

No entanto, o facto de a Ethereum Foundation ter entregue um roteiro de implementação para 2026, agendado uma chamada de breakout com proprietários de projetos e redigido uma EIP com mecânica de gossip peer-to-peer concreta significa que este trabalho passou de plausibilidade de pesquisa para um programa de entrega.

A transformação é silenciosa porque não envolve mudanças dramáticas na economia de tokens ou funcionalidades voltadas para o utilizador. Mas é fundamental porque reescreve a relação entre complexidade de execução e custo de validação.

Se o Ethereum conseguir desacoplar os dois, a camada-1 deixará de ser o estrangulamento que força tudo o que é interessante para a camada-2.

E se a verificação de provas da camada-1 se tornar infraestrutura partilhada, todo o ecossistema de camada-2 precisa responder a uma questão mais difícil: o que estás a construir que a camada-1 não consegue?

A publicação Ethereum quer validadores domésticos para verificar provas mas uma realidade de 12 GPU levanta uma nova ameaça apareceu primeiro no CryptoSlate.