A próxima década do Ethereum na visão de Vitalik

Autor: Chloe, ChainCatcher

Em 5 de julho de 2026, Vitalik Buterin publicou um texto longo no X, anunciando uma longa folha de rota chamada Lean Ethereum. Vitalik a posicionou como a terceira grande evolução do Ethereum após o Merge. Ela não é uma atualização única, mas uma série de melhorias de protocolo que serão implementadas em fases ao longo dos próximos 3 a 4 anos, cobrindo quase todos os módulos centrais do protocolo — desde o modo de verificação, criptografia, finalização até armazenamento de estado — com uma reconstrução total.

Essa folha de rota nasceu durante uma reorganização do ecossistema do Ethereum e precisa ser entendida dentro de um contexto temporal mais completo. Para interpretar essa reconstrução abrangente, não basta esclarecer quais são as atualizações técnicas específicas; é preciso também enxergar como o design redistribui o equilíbrio entre “custo de migração” e “limiar de verificação” e investigar como essa transformação na camada base acabará se refletindo no desempenho do preço do ETH.

Três etapas de desenvolvimento do Ethereum

Para situar essa atualização, vale primeiro listar as três gerações do Ethereum:

A primeira geração é a arquitetura original de “PoW + EVM”, cujo núcleo é que todos os nós reexecutam diretamente (Re-execution) todas as transações. Embora esse modelo seja seguro, versátil e aberto, a escalabilidade fica limitada por isso.

A segunda geração é o Ethereum PoS após o “Merge (Fusão)” de 2022. A mudança no mecanismo de consenso alterou completamente o modelo de segurança, o modelo de emissão e o sistema de staking do Ethereum, e também provou ao mercado que o Ethereum tem uma capacidade de engenharia extremamente alta para trocar o motor central em modo “sem desligar”.

A terceira geração é o Lean Ethereum de hoje. Ele não se limita à divisão existente de “L1 faz o settlement, L2 faz a expansão”, mas inclui, dentro de uma mesma estrutura de reconstrução de longo prazo, o desempenho da L1, verificação baseada em provas (Proved Verification), privacidade, resistência a ataques quânticos, estrutura de estado e a arquitetura do client.

A origem da folha de rota do Lean Ethereum

A folha de rota do Lean Ethereum foi publicada em strawmap.org. O pesquisador da fundação Justin Drake apresentou pela primeira vez neste ano, em fevereiro, um rascunho público, planejando sete upgrades de rede até 2029. A palavra strawmap vem de straw (palha); o documento se descreve como um rascunho editável. O strawmap também ressalta que é uma ferramenta de coordenação ainda em andamento, e não um cronograma fechado: qualquer upgrade ainda precisa passar por pesquisa, testes, implementação nos clients e um “consenso aproximado”.

Nessa visão, ficam traçados claramente cinco objetivos estratégicos de longo prazo: finalizar (Finality) da L1 mais rápida, atingir um throughput de L1 de 1 gigagas por segundo (no estado limite, com capacidade para dezenas de milhares de TPS), expansão do L2 com visão de ecossistema em teragas, segurança criptográfica quântica com defesa completa e transferências nativas de privacidade na L1.

Comparando com o cenário atual, dá para sentir o quão audaciosos esses objetivos são. Com base nos dados do Etherscan, atualmente a L1 do Ethereum processa em média apenas cerca de 32 transações por segundo (aprox. 2,7 milhões de transações por dia); e a meta de 1 gigagas significa que a capacidade de computação da L1 deve explodir centenas de vezes. Vale notar que a demanda on-chain da L1, no último ano, na verdade tem estado em uma trajetória de crescimento: o volume diário de transações voltou a subir bastante, saindo de 1,4 milhão em meados de 2025; desde 2026, na maior parte do tempo tem ficado estável entre 2 milhões e 2,9 milhões, e no pico de mercado de abril e maio chegou a se aproximar de 3,6 milhões de transações. O lançamento desta folha de rota é justamente para resolver essa demanda de atividade on-chain que está se recuperando.

As marcações de tempo também são bem claras: a Hegotá, marcada como o segundo upgrade de 2026, provavelmente será o último hard fork do Ethereum “pré- Lean” antes disso; a partir daí, cada upgrade, em teoria, fará parte dessa reconstrução. Já o upgrade mais próximo, o Glamsterdam, deve trazer um aumento considerável do teto de gas; esse upgrade originalmente era esperado para começar no primeiro semestre de 2026, mas até agora ainda não foi implementado.

O cronograma também é um dos pontos mais debatidos após a divulgação da folha de rota. Dankrad Feist, principal pesquisador central da Fundação Ethereum e proponente da proposta de Danksharding do Ethereum, escreveu no X que apoia o strawmap, mas que um cronograma de 3 a 4 anos é muito lento — com a tecnologia de modelos de linguagem grande atual, essa atualização poderia ser concluída em um ano.

Grande atualização central de tecnologia: verificação por prova e reconstrução do estado

O núcleo técnico do Lean Ethereum é trocar o modo de verificação fundamentalmente. Hoje, o modelo de segurança do Ethereum é que cada nó reexecute cada transação para confirmar que o estado está correto. O novo design inclui provas STARK recursivas como um componente nativo central do protocolo: um provador realiza o trabalho pesado de cálculo, enquanto todos os outros nós só precisam verificar uma prova matemática enxuta.

Essa escolha também se relaciona a outro problema: o STARK usa criptografia baseada em hash e, atualmente, não há um caminho de ataque quântico conhecido; já o esquema de assinatura em uso no Ethereum tem riscos relacionados. Vitalik afirma que a prioridade para segurança quântica foi “aumentada de forma significativa” e que a folha de rota planeja substituir gradualmente todos os componentes frágeis a quântica, começando pelas assinaturas Winternitz. A parte mais urgente é encontrar um desenho resistente a quântica para os blobs que o L2 usa para reduzir custos.

A camada de consenso também está dentro do escopo de mudança. No Ethereum atual, as transações são incluídas on-chain em apenas alguns dezenas de segundos, mas para garantir a finalização, cerca de 15 minutos são necessários. No novo design, “a cadeia que produz blocos continuamente” e “a finalização” são separadas como coisas distintas, com a meta de que validadores cheguem a um veredito após 1 ou 2 rodadas de votação, reduzindo os 15 minutos para algo próximo do tempo real. Além disso, há precificação de gas em múltiplas dimensões: isso significa que recursos diferentes — como computação, armazenamento e transmissão de dados — são cobrados separadamente, como água e eletricidade calculadas à parte, e não tudo misturado em uma única conta.

A mudança na arquitetura do estado afeta diretamente desenvolvedores de aplicações. O estado pode ser entendido como o livro-razão em tempo real do Ethereum, registrando os saldos de todas as contas e dados de contratos inteligentes. Esse livro só engrossa cada vez mais e, atualmente, todos os nós precisam manter uma cópia completa, o que faz os custos de armazenamento on-chain ficarem altos.

A proposta de Vitalik é fazer uma divisão estrutural do armazenamento em camadas: o “estado dinâmico (Dynamic State / núcleo essencial)” existente e funcional completo será rigidamente limitado a um limite de hardware de 2 TB, impedindo expansão ilimitada; ao mesmo tempo, o protocolo abrirá uma nova “camada de armazenamento de estado” com capacidade de até 100 TB e mais expansibilidade (“grande armazém”). No cenário de Vitalik para 2030, na maior parte dos tokens (ERC-20), NFTs e aplicações DeFi comuns, se eles estiverem dispostos a reescrever os contratos e migrar para o grande armazém usando essa nova arquitetura, a taxa de transação pode cair diretamente mais de 10 vezes. A camada de protocolo não força nem subsidia: apenas coloca essa enorme diferença de custo entre duas camadas na mesa, deixando para o mercado decidir o timing da migração.

A posição da privacidade também é redefinida. No passado, a divisão do Ethereum era: tudo on-chain é público e transparente; usuários que querem privacidade procuram, por conta própria, protocolos de privacidade de terceiros. Desta vez, Vitalik escreveu Privacy is no longer an afterthought, it is a first class goal, ou seja, a privacidade deixa de ser algo “adicionado depois” e passa a ser parte das normas da construção: no futuro, cada novo componente do protocolo será testado em fase de design com uma pergunta — ele consegue suportar recursos de privacidade que não exigem intermediários e ainda resistem a ataques quânticos com baixo custo? Se isso pode ser feito, ainda precisa ser verificado, mas os critérios de avaliação já estão escritos na folha de rota.

Controvérsia sobre substituição do EVM: jogo no ecossistema L2

O motor usado pelo Ethereum por dez anos chama-se EVM. Contratos, ferramentas de desenvolvimento e linguagens de programação do mundo inteiro foram construídos em torno dele. Agora, Vitalik propõe substituir esse motor, e a lógica está relacionada ao STARK citado antes: para gerar provas matemáticas de transações, rodar no EVM custa caro; trocar por um motor mais amigável a provas reduziria muito esse custo.

Ele cita como candidatos RISC-V e duas arquiteturas: leanISA. O objetivo ideal do desfecho é que o novo motor se torne o próprio protocolo, enquanto o EVM fique apenas como uma camada de tradução: contratos antigos ainda rodam, mas o nível de baixo primeiro traduz o contrato para instruções que o novo motor entende e então executa. Como trocar o motor é uma mudança relativamente mais complexa, essa proposta vem gerando controvérsias desde que Vitalik lançou pela primeira vez a ideia de RISC-V em abril de 2025.

Offchain Labs, o principal desenvolvedor por trás do L2 Arbitrum, no ano passado em novembro, defendeu publicamente que outra arquitetura — WebAssembly (WASM) — seria a melhor escolha. Porém, desta vez, entre os candidatos listados por Vitalik, não há WASM. Por que isso importa? Porque o Stylus, a tecnologia de contratos do Arbitrum, é construída sobre WASM.

Dá para entender assim: trocar o motor da L1 equivale a redefinir as “especificações de plugue” de todo o ecossistema. Se o “plugue” do seu dispositivo for exatamente do mesmo tipo, você aproveita diretamente; se não for, você precisa gastar para fazer a adaptação. Quem é selecionado na lista determina quais investimentos que as L2 fizeram no passado conseguem se conectar sem atrito com o futuro da L1, e quais vão ter custo de adaptação.

O Ethereum não tem um mecanismo de votação para arbitrar essa divergência sobre se vai trocar e, caso vá, por qual. No fim, isso depende do “consenso aproximado” dos desenvolvedores na reunião All Core Devs e de se as equipes de cada client estão dispostas a colocar a mão para implementar. Até agora, a troca do motor ainda permanece como uma meta de longo prazo mencionada por Vitalik, sem qualquer conclusão formal na reunião de desenvolvedores.

A folha de rota vai afetar o preço do ETH?

Ao relacionar a folha de rota aos preços do ETH, há dois níveis temporais.

O primeiro é o caminho de transmissão em termos de mecanismos. Desde o EIP-1559, no Ethereum a taxa base de cada transação é destruída (burn). Assim, o tamanho da atividade de transações na L1 afeta diretamente a dinâmica de oferta do ETH e o valor do settlement. De acordo com esse mecanismo, se a meta de gigagas for alcançada e a atividade de transações da L1 voltar a subir junto com a melhoria do throughput, o consumo de gas e a quantidade destruída aumentarão em sincronia — essa é a transmissão mais direta entre a folha de rota e a precificação do ETH. Mas é importante enfatizar que essa conexão só vale se “a demanda voltar junto após o aumento de capacidade”; por si só, a capacidade não cria demanda automaticamente.

O segundo é o descompasso de tempo. A folha de rota foi publicada como um projeto de engenharia faseado de 3 a 4 anos: até 2026, essa folha de rota não mudará nenhum aspecto do Ethereum, sendo apenas um compromisso direcional. E compromissos direcionais do Ethereum no cronograma já tiveram histórico de atraso — o Merge mesmo ficou vários anos acima das estimativas iniciais. Em outras palavras, esta folha de rota aumenta o limite superior de capacidade de longo prazo do Ethereum, mas não resolve o problema de captura de valor no meio do caminho do ETH; a crítica do analista Ignas à folha de rota justamente aponta para isso, porque ela não contempla os ajustes na economia de tokens do próprio ETH.

Lista de observação do próximo decênio

Juntando tudo acima, a resposta final acaba apontando para uma mesma estrutura: esta strawmap aumenta o limite superior de longo prazo do Ethereum, mas não resolve imediatamente o problema de captura de valor no meio do ciclo do ETH — e agora não é hora de comprar seguindo o FOMO do cronograma.

Em vez de precificar a própria folha de rota, o mais prático é acompanhar alguns pontos que podem ser testados ainda em breve:

Se o upgrade Glamsterdam consegue iniciar e concluir o aumento do teto de gas

Se a demanda por blobs consegue continuar crescendo junto com a atividade de L2

Se a receita de taxas da L1 e a quantidade de ETH destruída melhoram

Se o crescimento do L2 consegue retroalimentar a L1 via pagamento por blobs e demanda de settlement

Se a performance relativa do ETH contra o BTC consegue se recuperar

Esses indicadores correspondem, cada um, às etapas da folha de rota e podem ser verificados semanalmente em páginas de gráficos do Etherscan e em dashboards públicos como o DefiLlama. Qualquer mudança em qualquer um deles está mais perto do que serve de base para precificação do que o arquivo da folha de rota em si. Qualquer mudança, vai avisar o mercado mais cedo do que o próprio documento, revelando se essa reconstrução de 3 a 4 anos está de fato sendo cumprida ou apenas adiada.