Autor: Chloe, ChainCatcher
Nas últimas duas semanas, o criador da Ethereum, Vitalik Buterin, publicou uma série de artigos técnicos detalhados no X, abordando temas centrais como rota de escalabilidade, resistência a ataques quânticos, abstração de conta, reestruturação da camada de execução e aceleração do desenvolvimento por IA, sendo chamado de “plano de grande reforma da Ethereum para 2026”. Por trás dessa série de postagens está o framework Strawmap lançado simultaneamente pela Ethereum Foundation, um documento que planeja elevar o throughput da Ethereum L1 para o nível de 10.000 TPS até 2029.
No entanto, quanto mais ambicioso for o plano, mais dúvidas surgem sobre sua capacidade de entrega, pois, analisando o histórico, o ritmo de entrega da Ethereum sempre foi mais lento do que o esperado. A Ethereum está realmente pronta para deixar o “gradualismo” para trás e abraçar uma reestruturação radical?
Strawmap de roteiro: Ethereum atingindo 10.000 TPS em 2029
O pesquisador da Ethereum Foundation, Justin Drake, publicou em 25 de fevereiro um esboço de rota chamado Strawmap, que visa revelar a visão e a agenda de atualizações futuras do Ethereum L1. O plano estabelece cinco “estrelas polares”: desempenho L1 extremamente rápido, capacidade de throughput L1 em gigagas, escalabilidade L2 em teragas, segurança L1 pós-quântica e transferências privadas nativas L1. Os objetivos quantitativos finais são de 10.000 transações por segundo no L1 e 10 milhões de transações por segundo no L2.
Este plano prevê avançar por meio de sete forks, com ciclos de atualização a cada seis meses, abrangendo alterações nas camadas de consenso, dados e execução. Nesse sentido, o criador da Ethereum, Vitalik Buterin, expressou apoio e, nas últimas duas semanas, publicou extensos artigos técnicos no X, desmontando as dimensões centrais do roadmap.
Estratégia principal: focar na escalabilidade do Ethereum L1 e na reestruturação da camada de execução
Vitalik'sargument shows: Unlike the strategy of the past few years, which prioritized L2 Rollups and minimized L1, the current vision is to significantly enhance L1's own scalability in the short term while maintaining the long-term shift.
1. Processo curto prazo: Upgrade Glamsterdam
No planejamento de curto prazo, a próxima atualização Glamsterdam introduzirá "Listas de Acesso em Nível de Bloco (Block-Level Access Lists, BALs)" para suportar validação paralela, superando o gargalo de eficiência do processamento sequencial anterior, além de avançar na separação nativa de proponente e construtor (Enshrined Proposer-Builder Separation, ePBS), otimizando a utilização dos nós para slots de 12 segundos.
2. Processo de longo prazo: Evolução do ZK-EVM e dos Blobs
A expansão de longo prazo é sustentada por dois pilares principais: ZK-EVM e Blob. No caminho ZK-EVM, espera-se que, até o final de 2026, um pequeno número de validadores adote inicialmente o cliente ZK-EVM; a partir de 2027, a proporção será ampliada e a segurança reforçada, com o objetivo final de alcançar o mecanismo de prova múltipla obrigatória “3-of-5”, ou seja, um bloco só será válido se aprovado por pelo menos três dos cinco sistemas de prova.
No caminho de desenvolvimento do Blob, o PeerDAS (amostragem de disponibilidade de dados) será continuamente aprimorado, visando aumentar a capacidade de processamento de dados para cerca de 8 MB/s. O núcleo dessa tecnologia permite que os nós validem dados baixando apenas pequenos fragmentos, aumentando significativamente o throughput enquanto reduz efetivamente os requisitos de hardware dos nós. Por outro lado, para atender à demanda futura de adoção em larga escala, a rede principal da Ethereum migrará para armazenar diretamente os dados dos blocos no espaço Blob, substituindo o antigo modelo de calldata, que era caro e exigia armazenamento permanente. Essa mudança visa principalmente otimizar a estrutura de承载 de dados, reestruturando o caminho de escalabilidade da Ethereum na camada de dados.
3. Reestruturação da camada de execução: migração para árvore de estado binária, substituindo a EVM
Vitalik aponta que o atual gargalo de eficiência de prova da Ethereum tem 80% de origem em uma arquitetura obsoleta. De acordo com a EIP-7864, espera-se que, após a transição da atual “árvore de estado MPT Keccak hexadecimal” para uma “árvore de estado binária”, o comprimento dos ramos seja reduzido em até 4 vezes. Essa mudança trará uma melhoria significativa na eficiência de dados:
Banda de dados: redução de custos de aproximadamente 4 vezes, um avanço significativo para clientes leves como o Helios.
Velocidade de prova: se utilizado BLAKE3, aceleração de aproximadamente 3 vezes; se for variante Poseidon, aceleração potencial de até 100 vezes.
Otimização de acesso: O design do slot de página (64–256 slots) permite que dapps economizem mais de 10.000 Gas por transação ao ler e escrever dados adjacentes.
Mais ambiciosoé o提案 de migração da VM (máquina virtual), atualmente os provadores ZK são escritos principalmente em RISC-V; se o EVM puder rodar diretamente em RISC-V, eliminando a perda de tradução entre as duas camadas de máquinas virtuais, a provabilidade de todo o sistema será significativamente aumentada. O plano de implantação atual consiste em três etapas:
1. Primeiro, permita que o novo VM assuma os contratos pré-compilados existentes
2. Reabrir a possibilidade de os usuários implantarem novos contratos VM
3. Reescrever finalmente o próprio EVM como um contrato inteligente rodando em uma nova VM.
This ensures backward compatibility, and the final conversion cost requires only a gas fee recalibration.
Roadmap para ameaças quânticas: preencher as 4 principais vulnerabilidades técnicas da Ethereum
Para a questão crucial da segurança pós-quantum L1, Vitalik destacou claramente em um artigo técnicoque a Ethereum atualmente possui quatro pontos vulneráveis à computação quântica, conforme abaixo:
1. Camada de consenso: assinatura BLS
O caminho de substituição da camada de consenso já está se formando: Vitalik propôs a solução “Consenso Enxuto”, introduzindo uma variante de assinatura baseada em hash, combinada com STARKs para agregação e compressão, visando resistência a ataques quânticos. No entanto, Vitalik acrescentou que, antes da implementação completa do “Consenso Enxuto”, uma versão “cadeia enxuta e utilizável” será lançada primeiro, exigindo apenas o processamento de 256 a 1.024 assinaturas por slot, operando temporariamente sem agregação STARK, reduzindo significativamente a barreira de engenharia.
2. Disponibilidade de dados: Compromissos e provas KZG
Em termos de disponibilidade de dados, Vitalik propõe substituir os atuais “compromissos KZG” por “STARKs resistentes a quantum”, mas isso apresenta dois trade-offs:
Primeiramente, os STARKs carecem da propriedade linear do KZG, tornando difícil suportar amostragem de dados 2D eficiente; por isso, a Ethereum optou por um caminho mais conservador de DAS 1D (como o PeerDAS), priorizando a robustez da rede em vez de buscar expansão máxima.
Em segundo lugar, como as provas STARK são de grande tamanho, os desenvolvedores precisam resolver o problema de engenharia de “provas maiores que os dados” por meio de técnicas complexas, como provas recursivas. Em resumo, Vitalik acredita que, ao simplificar os objetivos técnicos e otimizar em fases, esse caminho resistente a quantum é ainda viável do ponto de vista de engenharia, mas exige um volume de engenharia considerável.
3. Conta externa detida (EOA): assinatura ECDSA
Em relação à proteção de contas externas (EOA), como a assinatura ECDSA atual é extremamente vulnerável a computadores quânticos, Vitalik prefere tornar todos os contas contratos por meio de “abstração de conta nativa (native AA)”, permitindo que os usuários alterem flexivelmente algoritmos de assinatura resistentes a quantum sem precisar abandonar seus endereços de carteira atuais.
4. Camada de aplicação: provas ZK que dependem de KZG ou Groth16
Por fim, no nível da camada de aplicação, o principal desafio é o alto custo de gas das provas STARK resistentes a quânticos, cerca de 20 vezes maior do que os SNARKs atuais, o que é muito caro para protocolos de privacidade e L2. Vitalik propõe introduzir o EIP-8141 “Validation Frame” para permitir a agregação off-chain de grandes quantidades de assinaturas e provas complexas.
Por meio da técnica de prova recursiva, os dados de verificação que originalmente chegavam a centenas de MB são finalmente comprimidos em uma prova STARK extremamente pequena, registrada na cadeia, economizando espaço de bloco e reduzindo drasticamente os custos de uso, permitindo até mesmo a verificação instantânea na fase Mempool, permitindo que os usuários operem diversas aplicações descentralizadas de forma barata e eficiente na era das ameaças quânticas.
AI como acelerador: conclua a rota da Ethereum 2030 em semanas
Além da atualização da arquitetura técnica, os recentes tweets de Vitalik enfatizam que a IA está acelerando o processo de desenvolvimento da Ethereum. Ele compartilhou uma experiência de um desenvolvedor que construiu um protótipo da rota da Ethereum para 2030 em duas semanas por meio de “vibe-coding” e comentou: “Há seis meses, isso nem estava dentro do possível; agora, tornou-se uma tendência.”
Até mesmo Vitalik testou pessoalmente: ele concluiu o código de backend do blog em uma hora usando o modelo gpt-oss:20b rodando em um laptop; se fosse usado o mais poderoso kimi-2.5, ele espera conseguir “fazer tudo de uma vez”. Pode-se dizer que o aumento de eficiência proporcionado pela IA não é mais linear — ela está alterando a velocidade de entrega do roadmap do Ethereum.
Para isso, ele propõe dividir os benefícios trazidos pela IA: “metade para velocidade, metade para segurança”, utilizando IA para gerar grandes conjuntos de testes, realizar verificação formal dos módulos principais e gerar múltiplas implementações independentes para a mesma lógica, a fim de realizar comparações cruzadas. A avaliação de Vitalik é que, no futuro previsível, você não conseguirá trocar um único prompt por um código de programa de alta segurança; o processo de luta contra bugs e inconsistências de implementação ainda existe, mas pode ser amplificado em cinco vezes.
Por fim, ele também levantou a possibilidade de que o roadmap da Ethereum seja concluído em uma velocidade mais rápida do que o esperado externamente, com padrões de segurança superiores ao esperado. “Código de programa sem bugs, há muito tempo considerado uma ilusão idealista, talvez agora se torne possível.” Essa frase, se dita no contexto de desenvolvimento da Ethereum há cinco anos, seria quase impossível.
ritmo de entrega lento e desafios reais
No entanto, ao divulgar tantos conteúdos técnicos complexos ao mercado, o roadmap da Ethereum sempre dependerá da possibilidade de cumprir esses compromissos pontualmente.
Historicamente, o ritmo de entrega da Ethereum sempre foi mais lento do que o esperado. O Merge foi adiado do prazo inicial de “fim do ano” em início de 2020 até setembro de 2022; a implementação do EIP-4844 (Proto-Danksharding) também levou vários anos. Esse atraso geralmente ocorre devido a fatores como auditorias de segurança, coordenação entre múltiplos clientes e governança descentralizada.
Mas desta vez, o tempo pacífico留给以太坊已经所剩无几。竞争对手的步步紧逼、量子威胁的现实挑战，以及由AI引发的生产力革命，正迫使以太坊彻底告别“渐进主义”；站在“不进则退”的历史转折点，过去那种温和的小步迭代，或许已难以支撑以太坊迈向全球结算层的愿景。
And Vitalik recent callalso highlights that this transformation is not merely a technical restructuring; he calls on the community to completely abandon path dependency at the application layer and uphold the core principles of censorship resistance, open source, privacy, and security (CROPS), rethinking application design from first principles.
A tecnologia pode ter um cronograma, mas a evolução da mentalidade não tem um cronograma de bifurcação — talvez esta seja a etapa mais difícil para deixar para trás o "gradualismo".