Escrito por: imToken
Apenas pela sensação, desde 2025 a comunidade de desenvolvedores principais do Ethereum tem apresentado uma frequência de atualizações excepcionalmente intensa.
Desde a atualização do Fusaka, passando por Glamsterdam, até ao planeamento de longo prazo para os próximos três anos, centrado em temas como kEVM, sistemas de criptografia resistentes a quânticos, Gas Limit, entre outros, o Ethereum lançou várias folhas de roteiro que cobrem de três a cinco anos em poucos meses.
Este ritmo por si só é um sinal.
Se leres atentamente a última folha de roteiro, vais perceber que uma direção mais clara e também mais audaciosa está a emergir: o Ethereum está a transformar-se numa máquina de computação verificável, e o objetivo final é o L1 zkEVM.
1. Três mudanças de foco na narrativa do Ethereum
A 26 de fevereiro, Justin Drake, investigador da Fundação Ethereum, publicou numa rede social que a Fundação apresentou um rascunho de folha de roteiro chamado Strawmap, que descreve a direção das atualizações do protocolo Ethereum L1 nos próximos anos.
Este roteiro propõe cinco objetivos principais: uma L1 mais rápida (confirmação final em segundos), uma L1 “Gigagas” com 10.000 TPS via zkEVM, uma L2 de alta capacidade baseada em amostragem de disponibilidade de dados (DAS), sistemas de criptografia resistentes a quânticos, e transferências de privacidade nativas; além disso, planeia-se até 2029 realizar sete forks de protocolo, aproximadamente a cada seis meses.
Pode-se dizer que, nos últimos dez anos, o desenvolvimento do Ethereum tem sido marcado por uma evolução contínua na narrativa e na estratégia técnica.
Primeira fase (2015–2020): o livro-razão programável.
Este foi o núcleo inicial da narrativa do Ethereum, ou seja, “contratos inteligentes Turing-completos”. Na altura, a maior vantagem do Ethereum era poder fazer mais do que o Bitcoin, como DeFi, NFTs, DAOs — produtos desta narrativa. Uma grande quantidade de protocolos financeiros descentralizados começou a operar na cadeia, desde empréstimos, DEX, até stablecoins, tornando o Ethereum na principal rede de liquidação da economia cripto.
Segunda fase (2021–2023): a narrativa do L2 toma o protagonismo.
Com o aumento das taxas de gás na cadeia principal do Ethereum, os utilizadores comuns passaram a ter dificuldades em pagar as transações, levando ao crescimento dos Rollups como principal solução de escalabilidade. O Ethereum passou a ser visto como uma camada de liquidação, fornecendo uma base segura para as soluções L2.
Resumindo, a ideia era transferir a maior parte do cálculo de execução para o L2, usando Rollups para escalar, enquanto o L1 ficava responsável pela disponibilidade de dados e liquidação final. Durante esse período, o The Merge, EIP-4844, tudo servia essa narrativa, visando tornar o uso do Ethereum mais barato e seguro para o L2, confiando na segurança do Ethereum.
Terceira fase (2024–2025): foco na reflexão e na competição de narrativas.
Como é sabido, o crescimento do L2 trouxe um problema inesperado: o próprio L1 do Ethereum tornou-se menos relevante, pois os utilizadores passaram a operar mais em Arbitrum, Base, Optimism, raramente interagindo diretamente com o L1. O preço do ETH também refletiu essa ansiedade.
Isso levou a debates na comunidade: se o L2 captura toda a atividade e utilizadores, onde fica o valor do L1? Até às turbulências internas do Ethereum em 2025, e às várias folhas de roteiro lançadas em 2026, essa lógica está a evoluir profundamente.
Na verdade, ao analisar as principais direções tecnológicas desde 2025, aparecem conceitos como Verkle Tree, clientes sem estado (Stateless Clients), validação formal do EVM, suporte nativo a ZK, entre outros — todos apontando para uma mesma direção: tornar o L1 do Ethereum verificável, não apenas permitindo que provas do L2 sejam verificadas no L1, mas que cada passo de transição de estado do L1 possa ser comprimido e verificado via provas de conhecimento zero.
Este é o grande objetivo do zkEVM de L1. Diferente do zkEVM de L2 (como zkSync, Starknet, Scroll), o zkEVM de L1 (zkEVM embutido) significa integrar a tecnologia de provas de conhecimento zero diretamente na camada de consenso do Ethereum.
Não é uma cópia do zkEVM de L2, mas uma transformação do próprio sistema de execução do Ethereum, tornando-o um sistema amigável a ZK. Portanto, se o zkEVM de L2 é construir um mundo ZK sobre o Ethereum, o zkEVM de L1 é transformar o próprio Ethereum nesse mundo ZK.
Se esse objetivo for alcançado, a narrativa do Ethereum passará de uma camada de liquidação de L2 para uma “fonte de confiança verificável”.
Será uma mudança de paradigma, não uma simples evolução incremental dos últimos anos.
2. O que é realmente o zkEVM de L1?
Mais uma vez, uma questão clássica: na abordagem tradicional, os validadores precisam “reexecutar” cada transação para verificar o bloco, enquanto no zkEVM, basta verificar uma prova ZK, permitindo ao Ethereum aumentar o Gas Limit para 100 milhões ou mais (leia mais em “ZK Roadmap ‘Dawn’: A rota para o fim do Ethereum está acelerando?”).
No entanto, transformar o Ethereum L1 em zkEVM não é uma tarefa pontual, mas um esforço coordenado em oito frentes, cada uma de nível de anos de trabalho.
Linha de trabalho 1: Formalização do EVM
Para gerar provas ZK, é preciso uma definição matemática precisa do que se está a provar. Hoje, o comportamento do EVM é definido por implementações de clientes (Geth, Nethermind, etc.), não por uma especificação formal rigorosa. Diferenças entre clientes podem gerar comportamentos inconsistentes, dificultando a criação de circuitos ZK para o EVM, pois não se pode provar um sistema mal definido.
O objetivo aqui é formalizar cada instrução e cada transição de estado do EVM de forma que possam ser verificadas por máquina. Essa é a base de todo o projeto zkEVM de L1. Sem ela, tudo o resto é uma construção instável.
Linha de trabalho 2: Substituição de funções hash por versões ZK-friendly
Atualmente, o Ethereum usa principalmente Keccak-256, que é pouco amigável a circuitos ZK, pois sua computação é custosa. O foco aqui é substituir progressivamente por funções hash compatíveis com ZK, como Poseidon ou Blake, especialmente nas árvores de estado e caminhos de Merkle, uma mudança que impacta toda a arquitetura do Ethereum.
Linha de trabalho 3: Substituição da Merkle Patricia Tree por Verkle Tree
Uma das mudanças mais aguardadas na roadmap 2025–2027. O Ethereum usa atualmente MPT para armazenar o estado global, mas Verkle Trees, com compromissos vetoriais, podem reduzir o tamanho das provas em dezenas de vezes. Para o zkEVM de L1, isso significa menos dados por bloco, provas mais rápidas e uma infraestrutura fundamental para a viabilidade do projeto.
Linha de trabalho 4: Clientes sem estado (Stateless Clients)
Clientes sem estado permitem verificar blocos sem armazenar toda a base de dados de estado, apenas com provas anexadas aos blocos. Essa abordagem depende do uso de Verkle Trees, pois as provas precisam ser pequenas. Para o zkEVM de L1, isso reduz a barreira de hardware para rodar nós, aumenta a descentralização e fornece entradas claras para provas ZK, que só precisam processar os dados das provas, não o estado completo.
Linha de trabalho 5: Padronização e integração de sistemas de provas ZK
O zkEVM de L1 precisa de um sistema de provas ZK maduro, mas o mercado ainda é disperso, sem uma solução dominante. O objetivo é definir uma interface padrão de provas na camada do protocolo Ethereum, permitindo a integração de diferentes sistemas de provas via competição, mantendo a abertura tecnológica. A equipe PSE (Privacy and Scaling Explorations) da Ethereum Foundation já tem avanços nesse sentido.
Linha de trabalho 6: Desacoplamento entre camada de execução e de consenso (EIP-4844 e evolução do Engine API)
Hoje, a camada de execução (EL) e a camada de consenso (CL) comunicam-se via Engine API. Com zkEVM, cada transação gera uma prova ZK, cujo tempo de geração pode ser maior que o intervalo de blocos. É preciso desenvolver uma arquitetura onde a execução possa ser rápida, enquanto a geração de provas seja assíncrona, e os validadores possam confirmar tudo de forma finalizada posteriormente, o que exige uma profunda reformulação do modelo de finalização.
Linha de trabalho 7: Provas recursivas e agregação de provas
Gerar provas ZK para cada bloco é custoso, mas se for possível recursivamente agregar provas de múltiplos blocos em uma única prova, o custo de validação diminui drasticamente. Essa tecnologia será decisiva para viabilizar o zkEVM de L1 em escala.
Linha de trabalho 8: Ferramentas de desenvolvimento e compatibilidade com EVM
Todas as melhorias técnicas devem ser transparentes para os desenvolvedores de contratos inteligentes. Os milhões de contratos existentes não podem ser quebrados, e as ferramentas de desenvolvimento não podem precisar ser reescritas. Essa linha é muitas vezes subestimada, mas é a mais trabalhosa, pois cada atualização do EVM exige testes de compatibilidade e adaptação de ferramentas. O zkEVM de L1 terá uma magnitude de mudanças maior que as anteriores, demandando um esforço de compatibilidade sem precedentes.
3. Por que agora é o momento certo para entender tudo isso?
A publicação do Strawmap coincide com um momento de dúvida no mercado sobre o desempenho do ETH. Nesse sentido, a maior valia dessa folha de roteiro é redefinir o Ethereum como uma “infraestrutura”.
Para os desenvolvedores, o Strawmap oferece uma direção clara; para os usuários, essas melhorias se traduzirão em experiências perceptíveis: confirmações em segundos, transferências fluidas entre L1 e L2, privacidade integrada.
Obviamente, o zkEVM de L1 não será uma solução de curto prazo; sua implementação completa pode levar até 2028-2029 ou mais.
Mas, pelo menos, ele redefine a proposta de valor do Ethereum: se o zkEVM de L1 for bem-sucedido, o Ethereum deixará de ser apenas uma camada de liquidação de L2, tornando-se a raiz de confiança verificável de todo o Web3, permitindo que qualquer estado na cadeia seja matematicamente rastreável até a prova ZK do Ethereum, o que é decisivo para seu valor de longo prazo.
Além disso, influencia a visão de longo prazo do L2: se o L1 tiver capacidades ZK, o papel do L2 mudará — de “solução de escalabilidade segura” para “ambiente de execução dedicado”. Os L2 que encontrarem seu espaço nesse novo cenário serão os principais a evoluir nos próximos anos.
Mais importante, é uma janela única para observar a cultura de desenvolvimento do Ethereum — a capacidade de avançar oito frentes tecnológicas interdependentes, cada uma de anos de trabalho, mantendo uma coordenação descentralizada, é uma característica única do protocolo Ethereum.
Compreender isso ajuda a avaliar com maior precisão a posição real do Ethereum em meio às diversas narrativas concorrentes.
De 2020, com o foco em Rollups, até 2026, com o Strawmap, a evolução da narrativa do Ethereum reflete uma trajetória clara: escalabilidade não pode depender apenas do L2, o L1 e o L2 devem evoluir em conjunto.
Assim, as oito frentes do zkEVM de L1 representam essa mudança de paradigma, apontando para um objetivo comum: fazer do Ethereum uma rede principal, com desempenho de escala, sem sacrificar a descentralização. Não é uma negação do caminho do L2, mas uma sua complementação e aprimoramento.
Nos próximos três anos, essa “nave de Teseu” passará por sete forks e inúmeras substituições de “tábuas”. Quando chegar a 2029, poderemos ver uma verdadeira “camada de liquidação global” — rápida, segura, privada e, como sempre, aberta.
Vamos aguardar ansiosamente.
