O Ethereum Está a Preparar-se para Validar Blocos Sem os Executar – Eis Como

Uma mudança subtil mas consequente está a tomar forma dentro da arquitetura central do Ethereum. Em vez de validar blocos reexecutando cada transação, a rede está a preparar um caminho alternativo onde os validadores confirmam a correção verificando provas de conhecimento zero.

O trabalho situa-se dentro do roteiro Layer-1 do Ethereum para 2026 e representa uma mudança estrutural na forma como o consenso pode ser alcançado, não uma nova funcionalidade de escalabilidade adicionada nas extremidades.

A proposta surgiu publicamente depois de um membro da Ethereum Foundation, conhecido como ladislaus.eth, ter delineado o progresso em direção a um design L1-zkEVM. A mudança não altera a forma como os blocos são produzidos ou o que os utilizadores submetem na blockchain. Em vez disso, muda a forma como os validadores decidem se um bloco é válido. O primeiro workshop L1-zkEVM está agendado para 11 de fevereiro de 2026, marcando o início formal da coordenação em torno deste esforço.

Da Reexecução Completa à Verificação de Prova

Atualmente, qualquer validador que queira atestar um bloco deve reexecutar cada transação dentro dele. Cada nó repete independentemente a mesma computação, verifica as mesmas transições de estado e armazena o mesmo estado de execução. Este modelo manteve-se desde a génese do Ethereum, mas escala linearmente com a atividade. Limites de gas mais altos aumentam a carga computacional, o tamanho do estado e os requisitos de largura de banda para cada participante.

A alternativa em desenvolvimento substitui a computação repetida por verificação criptográfica. Em vez de reexecutar transações, um validador verifica uma prova de conhecimento zero compacta mostrando que a execução foi realizada corretamente. O tempo de Verificação permanece aproximadamente constante independentemente da complexidade interna do bloco. Esta é a ideia central por trás das provas zkEVM, agora a ser incorporada diretamente no fluxo de trabalho de consenso do Ethereum.

Como Funciona o Pipeline L1-zkEVM

Sob o design atual, um cliente de execução produz uma Execution Witness, um pacote de dados autossuficiente para validar a transição de estado de um bloco sem manter o estado de execução completo. Um programa convidado padronizado consome essa testemunha e verifica a correção da execução. Uma zkVM executa este programa e gera uma prova atestando que a execução seguiu as regras do Ethereum.

Os clientes de consenso podem então verificar essa prova em vez de invocar um cliente de execução completo. Os validadores que escolhem este caminho são referidos como zkAttesters. Importante, este caminho é opcional. Os validadores podem continuar a reexecutar blocos exatamente como fazem hoje.

Este mecanismo está formalizado sob EIP-8025 (Optional Execution Proofs). A proposta não requer um hard fork e não força os validadores a adotar validação baseada em prova. Adiciona um caminho de Verificação paralelo juntamente com a reexecução.

Integração de Consenso e Diversidade de Clientes

O EIP-8025 especifica como as provas circulariam pela rede peer-to-peer. As provas de execução de diferentes implementações de clientes são divulgadas num tópico dedicado. Ao processar um bloco, um zkAttester pode verificar essas provas em vez de chamar um cliente de execução.

A suposição de trabalho atual é um limiar de 3 em 5. A execução de um bloco é aceite quando três de cinco provas independentes verificam com sucesso. Este limiar pode evoluir, mas a intenção é clara: preservar a diversidade de clientes de execução enquanto permite a validação baseada em prova. A diversidade permanece uma característica ao nível do protocolo em vez de uma escolha operacional.

Por Que Isto Importa Para os Validadores

Um zkAttester não precisa de armazenar o estado de execução ou sincronizar a cadeia completa da camada de execução. A sincronização reduz-se ao descarregamento de provas recentes desde o último checkpoint finalizado. Isto reduz drasticamente os requisitos de hardware para participar no consenso.

Para stakers a solo e validadores domésticos, isto é material. Executar um validador hoje requer manter tanto um cliente de consenso como um cliente de execução intensivo em recursos. A Verificação de prova substitui a reexecução, reduzindo as exigências de armazenamento, computação e largura de banda. Isto reduz a barreira de entrada sem enfraquecer as garantias de Verificação.

As implicações estendem-se para além dos attesters. Como as provas zkEVM são stateless, verificar o Ethereum localmente em hardware de consumidor torna-se mais acessível novamente. O princípio "não confie, verifique" é fortalecido em vez de diluído.

Dependências e Restrições de Tempo

Um pré-requisito importa. A geração de prova requer tempo, e sem pipelining, a janela é demasiado apertada. É aqui que o ePBS (Enshrined Proposer-Builder Separation) se torna relevante. Direcionado para o próximo hard fork Glamsterdam, o ePBS estende a janela de prova de aproximadamente um a dois segundos para cerca de seis a nove segundos. Essa extensão torna a geração de prova de slot único muito mais realista.

Sem ePBS, a Verificação de prova L1 permanece limitada. Com ele, o design torna-se operacionalmente viável.

Quem É Impactado

As equipas de clientes da camada de execução ganham uma nova superfície de prova, com cada cliente a tornar-se uma fonte potencial de prova. O design do prover permanece uma questão em aberto. Concentrar a prova num pequeno conjunto de builders sofisticados introduz riscos de disponibilidade, enquanto a prova totalmente distribuída levanta desafios de desempenho e coordenação. O objetivo do design é explícito: a prova deve permanecer viável fora de grandes centros de dados.

Os fornecedores de zkVM já a provar blocos do Ethereum ganham uma interface padronizada para construir. As equipas de Layer-2 também beneficiam. Uma vez que as provas de execução são verificadas pelos validadores, as mesmas provas podem servir rollups nativos através de infraestrutura partilhada.

Em última análise, os utilizadores beneficiam de Verificação mais barata, participação mais ampla de validadores e limites de gas viáveis mais altos sem pressão de centralização.

Estado Atual

O EIP-8025 entrou no ramo de funcionalidades consensus-specs e está a progredir para o estado de proposta. O roteiro L1-zkEVM para 2026 é agora público, estruturado através da padronização de testemunha de execução, interfaces zkVM, integração de consenso, infraestrutura de prover, benchmarking e Verificação de segurança formal.

O workshop de 11 de fevereiro de 2026 marca o início da coordenação focada nestas áreas. Esta não é uma atualização que chame a atenção dos títulos, mas é fundamental. Se o Ethereum escalar a sua camada de execução sem escalar os requisitos de validador, é assim que acontece.

A publicação Ethereum Is Preparing to Validate Blocks Without Running Them – Here is How apareceu primeiro em ETHNews.