Como o L1 zkEVM reescreve a especificação Ethereum: evolução de Rollup para computação verificável

Desde 2025, a comunidade de desenvolvedores do Ethereum demonstra uma intensidade de atualizações e repensamentos de seu papel na criptosfera nunca antes vista. Em meio às discussões sobre a dinâmica de preços do ETH, a Fundação Ethereum apresentou um ambicioso roteiro (Strawmap), que descreve a evolução técnica do protocolo para os próximos anos. A especificação não é apenas um aprimoramento técnico — é uma transformação qualitativa do próprio Ethereum: de uma camada de cálculo para L2 a uma base verificável de confiança para toda a economia descentralizada.

Essa transformação significa que cada passo na execução do estado L1 poderá ser comprimido e verificado por meio de provas de conhecimento zero. Não se trata de copiar projetos zkEVM de L2 (zkSync, Starknet, Scroll), mas de um objetivo fundamentalmente diferente: transformar a própria camada de execução do Ethereum em um sistema compatível com ZK. Se L2 zkEVM constrói um mundo ZK sobre o Ethereum, então L1 zkEVM é a transformação do próprio Ethereum para esse nível.

Três linhas de transformação: de um registro programável a uma infraestrutura verificável

O desenvolvimento do Ethereum na última década foi acompanhado por uma evolução gradual de sua base conceitual e prioridades técnicas. O primeiro período (2015–2020) focou na ideia de que o Ethereum é um registro programável capaz de fazer mais do que o Bitcoin. Contratos inteligentes, DeFi, NFT, DAO — tudo isso surgiu dessa história fundamental sobre a universalidade do cálculo na blockchain.

O segundo período (2021–2023) deslocou o foco para escalabilidade via soluções Layer 2. Com o aumento do custo do gás, usuários comuns não podiam realizar transações na L1, e soluções de Rollup começaram a dominar. O Ethereum passou a se reimaginar como uma camada de dados e finalização, fornecendo uma base segura para L2. The Merge e EIP-4844 serviram exatamente a esse propósito.

O terceiro período (2024–2025) marca uma reflexão mais profunda. O paradoxo é que a explosão de L2 levou à desvalorização do L1: usuários migraram para Arbitrum, Base, Optimism e raramente interagiram diretamente com o L1. Isso levantou uma questão crítica na comunidade: onde encontrar valor no L1, se o L2 está levando todos os usuários?

A análise das principais direções tecnológicas do Strawmap fornece a resposta. Verkle Tree, Stateless Client, verificação formal do EVM, suporte nativo a ZK — todos esses vetores apontam na mesma direção: dotar o Ethereum L1 de sua própria verificabilidade. Essa é uma mudança qualitativa que culminará na realização do L1 zkEVM.

A especificação é fundamental: por que 8 linhas de trabalho mudam a arquitetura do Ethereum

A conexão entre as mudanças técnicas no Strawmap é melhor compreendida ao considerar as 8 linhas de trabalho como um sistema arquitetural único, onde cada componente apoia os demais.

Linha de trabalho 1: Especificação formal do EVM como base

A especificação não é uma concepção abstrata — é uma definição matemática de cada instrução e regra de transformação de estado. Atualmente, o comportamento do EVM é definido por implementações de clientes (Geth, Nethermind), não por uma especificação formal. Isso significa que o comportamento pode variar em casos limites. Para construir provas ZK, não se pode trabalhar com um sistema ambíguo. Portanto, a primeira e mais importante linha de trabalho é formalizar cada aspecto do EVM de modo que possa ser verificado matematicamente.

Linha de trabalho 2: Substituição de funções de hash por compatíveis com ZK

Ethereum usa ativamente Keccak-256, que é bastante custoso para provas ZK. A principal tarefa é substituir gradualmente o Keccak por funções amigáveis a ZK (Poseidon, série Blake) nos componentes internos, especialmente em árvores de estado e provas Merkle. Essa mudança é sistêmica, pois as funções de hash permeiam todo o protocolo.

Linha de trabalho 3: Verkle Tree em vez de Merkle Patricia Tree

Verkle Tree substitui cadeias de hash por compromissos vetoriais, reduzindo em dezenas de vezes o tamanho das provas de evidência. Para L1 zkEVM, isso significa menos dados para comprovar o bloco, geração mais rápida de provas, além de que Verkle Tree é uma pré-condição essencial para a viabilidade do L1 zkEVM.

Linha de trabalho 4: Clientes sem estado (Stateless Clients)

Clientes sem estado podem verificar blocos sem armazenar localmente toda a base de dados de estado — apenas dados de testemunho (witness). Isso está intimamente ligado à Verkle Tree, pois a viabilidade prática depende do tamanho das evidências. Para o L1 zkEVM, isso tem efeito duplo: reduz os requisitos de hardware dos nós e fornece limites claros para os dados de entrada das provas.

Linha de trabalho 5: Padronização de provas ZK

O L1 zkEVM precisa de um sistema maduro de geração de provas, mas o campo ZK é altamente fragmentado. O objetivo dessa linha é definir uma interface padronizada a nível de protocolo, permitindo que diferentes sistemas concorram. A equipe PSE (Privacy and Scaling Explorations) tem vasta experiência nisso.

Linha de trabalho 6: Separação entre camada de execução e de consenso

Atualmente, a camada de execução (EL) e a camada de consenso (CL) interagem via Engine API. No L1 zkEVM, cada mudança de estado requer geração de prova ZK, o que pode exceder o intervalo entre blocos. É necessário separar execução e geração de provas sem comprometer o consenso — execução rápida, provas geradas de forma assíncrona.

Linha de trabalho 7: Provas recursivas e agregadas

Gerar uma prova para um único bloco é custoso, mas a agregação recursiva de múltiplos blocos em uma única prova reduz significativamente os custos de verificação. O progresso aqui determinará diretamente o custo do trabalho do L1 zkEVM.

Linha de trabalho 8: Ferramentas para desenvolvedores e compatibilidade com EVM

Todas as melhorias de baixo nível devem ser transparentes para os desenvolvedores de contratos inteligentes: dezenas de milhares de contratos não podem se tornar inutilizáveis. Essa linha é a mais subestimada, mas frequentemente a mais custosa em termos de tempo. Cada atualização do EVM exigiu testes massivos de compatibilidade reversa. As mudanças no L1 zkEVM superam as anteriores, e o volume de trabalho com ferramentas aumentará exponencialmente.

Por que exatamente agora: uma reavaliação do Ethereum como infraestrutura verificável

O lançamento do Strawmap ocorre em um período de dúvidas sobre a dinâmica de preços do ETH, mas seu verdadeiro valor está na reinterpretação do Ethereum como uma infraestrutura de longo prazo.

Para os desenvolvedores, o Strawmap oferece clareza de direção e confiança no investimento de tempo. Para os usuários, essas melhorias se traduzem em uma experiência perceptível: transações confirmadas em segundos, ativos movendo-se sem interrupções entre L1 e L2, privacidade integrada — não como um complemento, mas como uma funcionalidade nativa.

Objetivamente, o L1 zkEVM não surgirá rapidamente — a implementação completa é esperada para 2028–2029 ou mais tarde. Mas ela reconfigura a proposta de valor do Ethereum de forma fundamental. Se o L1 zkEVM for bem-sucedido, o Ethereum deixará de ser apenas uma camada de cálculo para L2 e se tornará uma base verificável de confiança para todo o Web3, permitindo que qualquer cadeia de estado seja matematicamente rastreada até a cadeia de provas ZK do Ethereum.

Isso também impacta a posição de longo prazo do ecossistema L2. Quando o L1 tiver suas próprias capacidades ZK, o papel do L2 evoluirá — de uma “solução de escalabilidade segura” para um “ambiente de execução especializado”. Quais L2 encontrarão seu lugar nessa nova arquitetura será o processo evolutivo mais interessante dos próximos anos.

O mais importante é que o L1 zkEVM demonstra uma capacidade única do Ethereum: avançar simultaneamente oito linhas técnicas interdependentes, cada uma uma iniciativa de anos de duração, mantendo uma abordagem descentralizada de coordenação. Essa é a verdadeira ambição da engenharia.

Evolução através da especificação: de uma orientação para Rollup a cálculos verificáveis

A evolução do relato do Ethereum — de um modelo “centrado em Rollup” em 2021 para o Strawmap 2026 — reflete uma trajetória clara: a escalabilidade não pode depender apenas do L2, mas o L1 e o L2 devem evoluir de forma conjunta e sinérgica.

As oito linhas de trabalho do L1 zkEVM representam a tradução técnica dessa mudança de paradigma. Cada linha visa um objetivo: garantir um aumento exponencial na produtividade da rede principal sem perder a descentralização. Não é uma negação do caminho do L2, mas sua melhoria e complemento orgânico.

Nos próximos três anos, a ecossistema passará por sete ramificações do protocolo, substituindo muitos componentes de sua arquitetura. Quando atingir a próxima fase em 2029, talvez vejamos um “nível de cálculo verificável global” — rápido, seguro, privado e, como sempre, aberto a todos. A especificação não é apenas um mecanismo — é uma promessa de que o Ethereum continuará sendo uma infraestrutura para um futuro descentralizado.