Grande atualização do Ethereum em 2026: desta vez, abandonar o "progressismo"

Autor: Chloe, ChainCatcher

Nas últimas duas semanas, o fundador do Ethereum, Vitalik Buterin, publicou intensamente vários artigos técnicos no X, abordando temas centrais como rotas de escalabilidade, resistência a ataques quânticos, abstração de contas, reconstrução da camada de execução e aceleração do desenvolvimento com IA, sendo apelidado de “Plano de grande reforma do Ethereum em 2026”. Por trás dessas publicações, está o esboço do Strawmap, uma estrutura de roteiro divulgada pela Fundação Ethereum, que planeja levar a taxa de throughput do Ethereum L1 para 10.000 TPS até 2029.

No entanto, quanto maior a ambição do plano, maior a dúvida sobre sua capacidade de entrega, pois, olhando para a história, o ritmo de implementação do Ethereum costuma ser mais lento do que o esperado. Será que o Ethereum está realmente preparado para abandonar o “progressismo” e embarcar em uma reestruturação radical?

Strawmap: Roteiro para alcançar 10.000 TPS no Ethereum até 2029

Em 25 de fevereiro, o pesquisador da Fundação Ethereum, Justin Drake, divulgou um esboço de roteiro chamado Strawmap, que revela a visão do Ethereum L1 e seu cronograma de atualizações futuras. O plano define cinco grandes “estrelas-guia”: desempenho ultra-rápido do L1, throughput de gigagas, expansão do L2 para teragas, segurança pós-quântica do L1 e transferências privadas nativas do L1. A meta final é processar 10.000 transações por segundo no L1 e 10 milhões no L2.

O plano prevê sete bifurcações, com atualizações a cada seis meses, abrangendo mudanças na camada de consenso, dados e execução. Vitalik Buterin, fundador do Ethereum, apoiou a iniciativa, tendo também publicado nos últimos dias vários artigos técnicos detalhando os principais aspectos do roteiro.

Foco estratégico: escalabilidade do L1 e reconstrução da camada de execução

Vitalik argumenta que, diferentemente dos últimos anos, focados em rollups L2 e L1 leves, a visão atual busca manter uma direção de longo prazo enquanto aumenta significativamente a capacidade de escalabilidade do L1 no curto prazo.

1. Curto prazo: Atualização Glamsterdam

Nos planos de curto prazo, a próxima atualização Glamsterdam introduzirá “Listas de Acesso em Blocos (BALs)” para suportar validação paralela, quebrando o gargalo de processamento sequencial, além de avançar na separação entre proposers e construtores (Enshrined Proposer-Builder Separation, ePBS), otimizando a utilização dos nós nos slots de 12 segundos.

2. Longo prazo: Evolução do ZK-EVM e Blob

Para expansão de longo prazo, duas principais bases sustentam o esforço: ZK-EVM e Blob. No caminho do ZK-EVM, espera-se que até o final de 2026 alguns validadores adotem inicialmente clientes ZK-EVM, expandindo sua participação a partir de 2027 e reforçando a segurança, com o objetivo de implementar um mecanismo de múltiplas provas obrigatórias (3 de 5), onde um bloco precisa ser validado por pelo menos três dos cinco sistemas de prova.

Na trajetória do Blob, o PeerDAS (amostragem de disponibilidade de dados) continuará evoluindo, visando aumentar a capacidade de processamento de dados para cerca de 8 MB/s. Essa tecnologia permite que os nós validem apenas pequenos fragmentos de dados, aumentando o throughput e reduzindo os requisitos de hardware. Além disso, para suportar adoções em larga escala, o Ethereum migrará para armazenar os dados dos blocos diretamente no espaço Blob, substituindo o antigo modelo caro de calldata que precisava ser armazenado permanentemente. Essa mudança visa otimizar a estrutura de dados e redesenhar a escalabilidade do Ethereum na camada de dados.

3. Reconstrução da camada de execução: mudança para árvores de estado binárias, substituindo a EVM

Vitalik aponta que 80% da ineficiência de prova do Ethereum atualmente vem de uma arquitetura obsoleta. Segundo a EIP-7864, a troca do atual “árvore de estado Keccak MPT em hexadecimal” por uma “árvore de estado binária” reduzirá o comprimento das ramificações em até 4 vezes, trazendo melhorias significativas na eficiência de dados:

• Largura de banda de dados: redução de custos em cerca de 4 vezes, um avanço para clientes leves como Helios.

• Velocidade de prova: com BLAKE3, aceleração de aproximadamente 3 vezes; com variantes de Poseidon, potencialmente até 100 vezes.

• Otimização de acesso: o design de “páginas” de slots (64–256 slots) permite que DApps economizem mais de 10.000 Gas por transação ao ler ou escrever dados adjacentes.

Um plano mais ambicioso é a migração da VM (máquina virtual). Atualmente, os provadores ZK geralmente usam RISC-V; se a EVM puder rodar diretamente em RISC-V, eliminando a tradução entre duas camadas virtuais, a capacidade de prova do sistema aumentará drasticamente. O roteiro de implantação prevê três etapas:

1. Permitir que a nova VM assuma contratos pré-compilados existentes

2. Permitir que usuários implantem contratos na nova VM

3. Reescrever a EVM como um contrato inteligente rodando na nova VM

Essa abordagem garante compatibilidade retroativa, com o custo final sendo apenas a reavaliação das taxas de Gas.

Roteiro de resistência a ataques quânticos: preenchendo as quatro principais vulnerabilidades do Ethereum

No que diz respeito à segurança pós-quântica do L1, Vitalik destaca que o Ethereum atualmente possui quatro vulnerabilidades quânticas principais:

1. Camada de consenso: Assinaturas BLS

A substituição da camada de consenso já está em estágio inicial: Vitalik propõe o “Lean consensus” (consenso enxuto), usando assinaturas baseadas em hash (Hash-based) combinadas com STARKs para agregação e compressão, visando resistência a ataques quânticos. Antes de uma implementação completa do “consenso enxuto”, uma versão “leve e utilizável” será lançada, processando entre 256 e 1024 assinaturas por slot, sem necessidade de STARKs, reduzindo a complexidade.

2. Disponibilidade de dados: KZG commitments e provas

Para a disponibilidade de dados, Vitalik sugere substituir as “compromissos KZG” por STARKs com resistência quântica, embora haja trade-offs: STARKs não suportam amostragem eficiente em 2D devido à falta de linearidade, levando o Ethereum a optar por uma abordagem conservadora, como PeerDAS, priorizando robustez ao invés de máxima escalabilidade.

Além disso, provas STARK tendem a ser grandes, exigindo engenharia complexa, como provas recursivas, para evitar que a prova seja maior que os próprios dados. Em resumo, Vitalik acredita que, ao simplificar objetivos técnicos e dividir o desenvolvimento em fases, essa rota é viável, embora exija um esforço de engenharia considerável.

3. Contas externas (EOA): Assinaturas ECDSA

Para contas externas, como as carteiras atuais, a vulnerabilidade do ECDSA frente a computadores quânticos é evidente. Vitalik propõe a abstração de contas nativas (native AA), permitindo que os usuários troquem de algoritmos de assinatura resistentes a quânticos, sem precisar abandonar seus endereços atuais.

4. Camada de aplicação: provas ZK baseadas em KZG ou Groth16

Na camada de aplicação, o maior desafio é que provas STARK resistentes a quânticos têm custos de Gas cerca de 20 vezes maiores que SNARKs atuais, tornando-se inviáveis para protocolos de privacidade e L2. Vitalik sugere a introdução do “Validation Frame” via EIP-8141, que permite agregar várias assinaturas e provas complexas fora da cadeia.

Usando provas recursivas, dados de validação que hoje chegam a centenas de MB podem ser comprimidos em uma prova STARK extremamente pequena, economizando espaço no bloco e reduzindo custos. Além disso, essa técnica possibilita validações instantâneas na mempool, garantindo operações eficientes mesmo sob ameaça quântica, com baixo custo.

IA como acelerador: roteiro do Ethereum até 2030 em semanas

Além das melhorias técnicas, Vitalik destaca que a IA está acelerando o desenvolvimento do Ethereum. Ele compartilhou um experimento onde, em duas semanas, foi criado um protótipo do roteiro Ethereum 2030 usando “vibe-coding”, e comentou: “Seis meses atrás, isso parecia impossível; agora, é uma tendência.”

Ele mesmo testou usando seu laptop com o modelo gpt-oss:20b, que gerou o backend de um blog em uma hora; com um modelo mais potente, kimi-2.5, espera-se que o processo seja ainda mais rápido. A IA está mudando a velocidade de entrega do roteiro do Ethereum de forma não linear.

Ele defende que os benefícios da IA sejam divididos: metade para acelerar, metade para garantir segurança, usando IA para gerar testes em larga escala, validar formalmente componentes críticos e criar múltiplas implementações independentes para cross-checking. Sua avaliação é que, no futuro próximo, não será possível substituir uma boa implementação por um único prompt, mas esse processo pode ser acelerado em até 5 vezes.

Por fim, ele sugere que o roteiro do Ethereum pode ser concluído mais rapidamente do que o esperado, com padrões de segurança superiores às expectativas. “Código sem bugs, há muito considerado uma fantasia idealista, pode se tornar uma realidade.” Se essa frase fosse dita há cinco anos, no contexto do desenvolvimento do Ethereum, seria quase impossível de imaginar.

Ritmo de entrega lento e desafios reais

Porém, divulgar tantos detalhes técnicos complexos ao mercado sempre levanta dúvidas sobre a capacidade de cumprir esses compromissos pontualmente.

Historicamente, o ritmo de implementação do Ethereum costuma ser mais lento do que o previsto. O The Merge, inicialmente esperado para o final de 2020, foi adiado até setembro de 2022; a implementação do EIP-4844 (Proto-Danksharding) também levou anos. Esses atrasos geralmente decorrem de auditorias de segurança, coordenação entre múltiplos clientes e governança descentralizada.

Porém, desta vez, o tempo para o Ethereum se tornar mais lento está se esgotando. A pressão de concorrentes, a ameaça real dos ataques quânticos e a revolução produtiva impulsionada pela IA forçam o Ethereum a abandonar o “progressismo”; na encruzilhada entre avançar ou ficar para trás, as pequenas melhorias do passado podem não ser suficientes para alcançar sua visão de se tornar a camada de liquidação global.

Recentemente, Vitalik também pediu à comunidade que abandone dependências de rotas tradicionais na camada de aplicação, defendendo uma reconstrução baseada em princípios fundamentais, focando na resistência à censura, código aberto, privacidade e segurança (CROPS).

Embora o roteiro técnico exista, a verdadeira mudança de mentalidade, sem um cronograma de bifurcações, talvez seja a maior dificuldade para deixar o “progressismo” para trás.