Estratégia de Layer Ethereum: Como L1 zkEVM Transforma Blockchain a Curto e Longo Prazo

Desde 2026, o Ethereum enfrenta um momento crítico na evolução da sua arquitetura em camadas. A frequência de anúncios da comunidade de desenvolvedores principais atingiu o seu pico, refletindo uma mudança estratégica fundamental sobre como o ecossistema deve evoluir. Do ponto de vista de curto prazo, o Ethereum está equilibrando atualmente o papel de Layer 1 e Layer 2; no entanto, a visão de longo prazo aponta para uma transformação muito mais ambiciosa: transformar o próprio L1 do Ethereum num sistema zkEVM integrado, e não apenas uma base de segurança para L2.

Essa mudança de entendimento é refletida numa série de propostas técnicas recentes. Em 26 de fevereiro, Justin Drake, da Ethereum Foundation, lançou um rascunho de roteiro chamado Strawmap, delineando a direção de desenvolvimento do protocolo Ethereum L1 para os próximos anos. O documento cobre cinco objetivos principais: aumentar a finalização para segundos, implementar um “Gigagas” L1 com throughput de até 10.000 TPS via zkEVM, lançar L2 de alta velocidade baseado em DAS (Data Availability Sampling), sistemas criptográficos resistentes a quânticos e recursos de privacidade nativos—tudo planejado através de sete hard forks até 2029, com uma média de um a cada seis meses.

De foco em L2 para reintegração de L1: Três ondas de mudança na narrativa do Ethereum

A trajetória do Ethereum nos últimos dez anos pode ser mapeada através de três fases evolutivas claras, cada uma refletindo prioridades diferentes em relação às camadas.

Fase 1 (2015–2020): Era do Ledger Programável

A narrativa central do Ethereum é a criação de uma plataforma para contratos inteligentes Turing-complete. Nesse período, a principal vantagem do Ethereum em relação ao Bitcoin era a flexibilidade de execução: a capacidade de rodar DeFi, NFTs, DAOs e diversas aplicações descentralizadas. O protocolo L1 do Ethereum tornou-se a camada principal de execução, hospedando a maior parte da atividade da criptoeconomia. Essa função posicionou o Ethereum como a “espinha dorsal da infraestrutura Web3”, embora sem questionamentos sérios sobre escalabilidade.

Fase 2 (2021–2023): Era do Rollup em L2

Quando as taxas de gás na mainnet do Ethereum dispararam, a narrativa mudou. Os Rollups em L2 tornaram-se a solução dominante, e o Ethereum passou a se reposicionar: de camada principal de execução para camada de liquidação. Upgrades como The Merge (2022) e EIP-4844 (Proto-Danksharding) foram projetados para suportar esse modelo—com o L1 responsável pela segurança e disponibilidade de dados, enquanto a computação principal migrava para o L2. Essa estratégia proporcionou escalabilidade significativa, mas criou um novo dilema.

Fase 3 (2024–2025): Reflexão e Reposicionamento

O sucesso do L2 trouxe um paradoxo inesperado: os usuários migraram massivamente para Arbitrum, Base, Optimism e outras plataformas L2, deixando o L1 do Ethereum com atividades relativamente limitadas. O valor capturado pelo L1 caiu, enquanto o L2 dominava. Perguntas fundamentais surgiram na comunidade: se todos os usuários e atividades estão no L2, qual a relevância do L1? Como o L1 pode captar valor a longo prazo?

Essas questões impulsionaram uma evolução radical. A comunidade percebeu que uma estratégia de camadas que depende apenas do L2 não é sustentável. É necessário reintegrar e criar sinergia entre L1 e L2, não apenas dividir tarefas separadamente.

Strawmap 2026: Oito caminhos técnicos rumo a um L1 zkEVM integrado

Essa nova visão assume forma concreta em oito rotas de trabalho técnico interligadas. Cada rota é um projeto plurianual, e o sucesso global depende do progresso simultâneo em todas elas. É isso que diferencia o L1 zkEVM de esforços anteriores de escalabilidade: sua complexidade não reside em um único avanço, mas na orquestração de oito inovações interdependentes.

Rota 1: Formalização da Especificação EVM

A base de toda prova de conhecimento zero é uma definição matemática precisa. Atualmente, o comportamento da EVM é definido por implementações de clientes (Geth, Nethermind, Besu, etc.), não por uma especificação formal rigorosa. Inconsistências nos limites de casos entre clientes dificultam o desenvolvimento de circuitos ZK. Essa rota visa converter cada instrução e regra de transição de estado da EVM em uma especificação formal verificável por máquina. Sem isso, todos os passos seguintes serão construídos sobre areia.

Rota 2: Migração para Funções Hash ZK-Friendly

O Ethereum atualmente usa Keccak-256 amplamente, o que é altamente não-ideal para circuitos ZK—overhead computacional elevado, aumentando significativamente o tempo e o custo de geração de provas. Essa rota envolve a substituição progressiva do Keccak por funções hash compatíveis com ZK, como Poseidon e Blake, especialmente em Merkle trees e caminhos de prova. Essa mudança terá impacto amplo, pois funções hash permeiam todo o protocolo.

Rota 3: Verkle Tree substituindo Merkle Patricia Tree

A infraestrutura da árvore de estado do Ethereum atualmente usa Merkle Patricia Tree (MPT). Verkle Trees substituem-na por compromissos vetoriais, comprimindo o tamanho do witness em dezenas de vezes. Para o L1 zkEVM, isso significa reduzir drasticamente os dados necessários para provar cada bloco, acelerando a geração de provas e tornando o L1 zkEVM economicamente viável. Verkle Tree é uma infraestrutura pré-requisito chave para a viabilidade do L1 zkEVM.

Rota 4: Clientes Stateless

Clientes stateless são nós que verificam blocos sem manter toda a base de dados de estado do Ethereum localmente—basta usar witness incluído no próprio bloco. Essa rota está relacionada à Verkle Tree (só viável se o witness for pequeno o suficiente), e tem dupla finalidade: reduzir a barreira de hardware para rodar nós (aumentando a descentralização) e fornecer limites claros de entrada para provas ZK (o provador só precisa processar o witness, não todo o estado global).

Rota 5: Padronização de Sistemas de Prova ZK

O L1 zkEVM precisa de sistemas de prova ZK maduros para gerar provas de execução de blocos. O cenário ZK atual é fragmentado, sem uma solução universalmente reconhecida. Essa rota define uma interface padronizada de provas no protocolo Ethereum, permitindo que diferentes sistemas de prova concorram por uma interface comum, sem monopólio de uma única solução. Assim, mantém-se a abertura técnica enquanto se permite evolução contínua. A equipe de PSE (Privacy and Scaling Explorations) da Ethereum Foundation já acumulou várias experiências iniciais nesse sentido.

Rota 6: Desacoplamento de Execução e Camada de Consenso

Atualmente, a camada de execução (EL) e a camada de consenso (CL) do Ethereum comunicam-se via Engine API. Na arquitetura do L1 zkEVM, cada transição de estado na camada de execução requer geração de prova ZK. Essa geração pode levar muito mais tempo que o intervalo de produção de blocos, criando um gargalo. Essa rota busca resolver o problema central: como separar execução e geração de provas sem comprometer o mecanismo de consenso—a execução pode ser concluída rapidamente, enquanto a prova é gerada de forma assíncrona e verificada pelos validadores no momento adequado para finalizar a finalização. Isso envolve modificações profundas no modelo de finalização de blocos.

Rota 7: Prova Recursiva e Agregação de Provas

O custo de gerar uma prova ZK para um único bloco é alto. Mas, se provas de múltiplos blocos puderem ser comprimidas recursivamente em uma única prova, o custo de verificação será muito mais eficiente. O progresso nessa rota determina diretamente o quão baixo pode ser o custo final do L1 zkEVM.

Rota 8: Ferramentas de Desenvolvimento e Compatibilidade EVM

Todas as reformas técnicas finais devem ser transparentes para os desenvolvedores de contratos inteligentes no Ethereum. Os dezenas de milhares de contratos existentes não podem ser quebrados, e as ferramentas de desenvolvimento não podem precisar de reescrita. Essa rota é muitas vezes subestimada, mas costuma ser a mais demorada; cada atualização anterior do EVM exige extensivos testes de compatibilidade retroativa e ajustes nas ferramentas. Para o L1 zkEVM, as mudanças são ainda maiores, aumentando exponencialmente a carga de trabalho de compatibilidade e ferramentas.

Impacto de curto prazo na camada: o que muda para L2 e ecossistema?

Essa transformação tem implicações imediatas e de longo prazo para diferentes stakeholders.

Implicações de curto prazo (2026–2027)

No horizonte de curto prazo, o L2 continuará dominando em escalabilidade. A Ethereum Foundation comunicou explicitamente que o L1 zkEVM não substituirá o L2, mas será uma evolução complementar. Rollups em L2 permanecerão como camada principal de execução para alto volume de transações, dando confiança aos construtores e usuários para continuar construindo no ecossistema L2, já maduro.

No entanto, à medida que o L1 do Ethereum se tornar mais capaz nos próximos anos, o posicionamento do L2 evoluirá de uma “solução de escalabilidade segura” para um “ambiente de execução especializado”. O L2 que encontrar um nicho de valor—seja por VM especializada, otimização de custos ou recursos de privacidade—sobrevivendo-á e prosperará na nova ordem.

Implicações de longo prazo (2028–2029)

Quando o L1 zkEVM estiver totalmente integrado, o Ethereum não será mais apenas uma camada de liquidação para o L2. Tornar-se-á uma “raiz de computação verificável” para todo o ecossistema Web3. Cada cadeia, cada L2, poderá, em última análise, ancorar sua proveniência matematicamente na cadeia de provas ZK do Ethereum, criando uma hierarquia de confiança unificada, porém descentralizada.

Por que esse momentum é importante: confiança dos construtores e posicionamento de longo prazo do Ethereum

O anúncio do Strawmap ocorre num momento em que o mercado questiona o desempenho do ETH. Nesse contexto, o valor mais importante dessa roadmap é a reafirmação do Ethereum como “infraestrutura primitiva”, não como commodity.

Para os construtores: O Strawmap oferece uma direção clara. Após um período de incerteza sobre a relevância do Ethereum, fica evidente que o ecossistema central continuará a evoluir com ambições técnicas elevadas. Isso inspira confiança para compromissos de longo prazo.

Para os usuários: Essas melhorias técnicas se traduzem em uma experiência mais tangível—finalidade em segundos, fluxo de ativos suave entre L1 e L2, privacidade como recurso nativo, não apenas plugin.

Para investidores: É uma oportunidade de reavaliar o posicionamento do Ethereum de forma renovada. Se o L1 zkEVM for implementado com sucesso, o Ethereum deixará de ser apenas uma camada de liquidação para o L2, tornando-se a raiz de confiança verificada para o Web3. Essa é uma mudança na narrativa de qualidade, não apenas uma melhoria quantitativa.

Na verdade, o L1 zkEVM não será um produto lançado imediatamente. Sua implementação completa talvez só aconteça em 2028–2029 ou até mais tarde. Mas ela redefine fundamentalmente a proposta de valor do Ethereum.

Essas oito rotas técnicas não são apenas um roteiro—são uma manifestação da cultura única de desenvolvimento do Ethereum: a capacidade de conduzir oito fluxos de trabalho técnicos simultâneos, interdependentes, cada um um projeto de engenharia de anos, enquanto mantém uma coordenação descentralizada. Essa é uma vantagem competitiva que outros concorrentes não podem copiar.

No geral, da narrativa “centrada em Rollups” de 2020 até o Strawmap de 2026, a evolução do Ethereum revela uma lição: escalabilidade não pode depender apenas do L2. L1 e L2 devem evoluir de forma sinérgica. Essas oito rotas do L1 zkEVM representam um mapeamento técnico dessa mudança de paradigma, apontando para um destino comum: melhorar drasticamente o mainnet do Ethereum sem comprometer a descentralização, não rejeitando o L2, mas aprimorando-o.

Nos próximos três anos, essa “Nave de Teseu” passará por sete forks e substituirá muitas “tábuas” e “velas”. Quando chegar ao seu próximo destino em 2029, podemos testemunhar uma “camada de liquidação global” verdadeiramente revolucionária—rápida, segura, privada e ainda aberta como desde o início. Vamos acompanhar essa evolução juntos.