📝 Olá, sou 10, Vitalik recentemente fez um longo tweet, revelando que o Ethereum está prestes a passar por uma atualização de nível de motor em verdadeiro sentido.

Não é uma simples correção, não é uma otimização de desempenho, mas sim uma reestruturação completa do EVM (Máquina Virtual Ethereum), até mesmo substituí-lo.

Fazendo uma comparação que não é tão apropriada: você usou um iPhone por sete anos, o sistema sempre foi atualizado, mas o chip nunca foi trocado. Um dia, a Apple anunciou de repente que, sob seu uso normal, iria trocar toda a arquitetura do chip, o impacto, é claro, seria enorme.

👇👇👇

Um, por que finalmente estamos indo para cima do EVM

No círculo da Ethereum, as pessoas geralmente não mexem na EVM. Quando encontram novas demandas, muitos pensam primeiro em acelerar na camada de protocolo (como contratos pré-compilados) para evitar a máquina virtual.

A razão é muito prática: a EVM realmente é lenta ao processar certas operações complexas. O que Vitalik quer dizer é bastante simples: se a cozinha não é boa o suficiente, construa uma nova, não é preciso sempre contar com ajuda externa.

Dois, a primeira mudança é substituir aquela árvore gorda.

Ele sugeriu duas grandes mudanças. A primeira é sobre a árvore de estados, que você pode entender como o índice do livro razão da Ethereum.

Você pode entender a árvore de estados como o índice do livro razão da Ethereum. Atualmente, usamos uma árvore de seis caminhos, onde cada nó pode ter até 16 filhos, resultando em caminhos de busca longos e eficiência baixa. Vitalik propôs mudar para uma árvore binária, que tem apenas dois direções, o que acelera a busca e reduz o consumo de largura de banda.

É como passar de folhear um grosso catálogo telefônico para pesquisar diretamente na lista de contatos do celular. Ao mesmo tempo, a função hash também precisa ser alterada: introduzir o Blake3 para aumentar a estabilidade, enquanto o Poseidon pode melhorar a eficiência em dezenas de vezes.

Esta proposta na verdade substitui a árvore Verkle anterior. Como a árvore Verkle depende de criptografia que pode não suportar a computação quântica, ela foi gradualmente abandonada pela comunidade desde o ano passado. O roteiro tecnológico pode mudar rapidamente.

Três, a segunda mudança transforma a EVM em história.

A segunda mudança é mais ousada, substituindo a EVM pela arquitetura RISC-V. O RISC-V originalmente não tinha nada a ver com blockchain, mas agora muitos sistemas de prova ZK estão usando-o.

O pensamento de Vitalik é muito simples: uma vez que o RISC-V já está sendo usado como provador, por que a máquina virtual ainda precisa usar uma linguagem diferente e adicionar tradução extra? Remover essa camada de tradução naturalmente aumenta a eficiência.

Um interpretador RISC-V tem apenas algumas centenas de linhas de código, e Vitalik acredita que é assim que a máquina virtual da blockchain deve ser.

Seu plano em três etapas:

Primeiro, deixar a nova máquina virtual executar contratos pré-compilados para validar a viabilidade.

Permitir que os desenvolvedores implantem novos contratos de máquina virtual, com EVM e nova máquina virtual funcionando em paralelo.

A EVM será aposentada, mas os contratos antigos ainda poderão ser executados, pois a EVM será convertida em contratos inteligentes na nova máquina virtual.

Os usuários antigos não precisam trocar de carro, mas o motor foi atualizado silenciosamente. Vitalik calculou: a árvore de estados e a máquina virtual juntas representam mais de 80% do gargalo de prova da Ethereum. Não mexer nessas duas partes torna difícil implementar a escalabilidade ZK.

Quatro, a resposta da Arbitrum: direção correta, mas o caminho pode ser reconsiderado.

A equipe da Arbitrum respondeu à proposta do RISC-V em novembro passado. Eles reconhecem as vantagens do RISC-V em provas ZK, mas acreditam que não é adequado como formato de entrega de contratos.

Eles fizeram uma analogia: um empilhador é muito eficiente para mover mercadorias no armazém, mas um entregador não pode usar um empilhador para entregar na porta, certo?

Portanto, eles sugerem usar WASM (WebAssembly) como camada de contrato. O WASM pode ser executado rapidamente, tem um mecanismo de segurança de tipo maduro, e a cadeia de ferramentas já foi validada no ambiente do navegador. A Arbitrum já implementou um protótipo com WASM: os contratos são entregues via WASM e depois feitos ZK com RISC-V, cada um cumprindo seu papel sem interferir no outro.

Eles também se preocupam com uma coisa: o progresso da tecnologia ZK é muito rápido, o RISC-V acaba de entrar em 64 bits, e se em dois anos surgir uma arquitetura melhor?

Cinco, o L2 da Ethereum enfrenta um momento de desmame.

Um mês atrás, Vitalik questionou se ainda era necessário um roteiro específico para L2, provocando uma resposta coletiva do campo L2. Alguns apontaram que o L2 originalmente era para escalabilidade, e agora que a Ethereum se tornou mais rápida, o papel do L2 naturalmente precisa ser ajustado.

Os L2 não apenas não entraram em pânico, mas começaram a se tornar proativos em se desvincular da Ethereum. Alguns comparam L2 a sites independentes, enquanto a Ethereum é o padrão de liquidação subjacente; outros acreditam que o verdadeiro desafio é criar espaço de bloco único para cenários específicos.

Vitalik transmite um sinal sobre a mudança na camada de execução: a Ethereum não se contenta mais em ser apenas uma camada de liquidação, mas busca recuperar o controle das capacidades centrais. E os L2 também estão gradualmente encontrando suas próprias posições independentes.

Seis, será que isso realmente pode acontecer?

Vitalik também reconhece: a substituição da máquina virtual ainda não formou um consenso amplo. Atualmente, a reforma da árvore de estados está mais madura, e o EIP-7864 já tem um esboço concreto, mas a substituição da EVM pelo RISC-V ainda está na fase de roteiro.

Os próximos dois pontos-chave são: atualização Glamsterdam (prevista para o primeiro semestre de 2026) e atualização Hegota. A reforma da árvore de estados e a otimização da camada de execução são as linhas principais confirmadas, enquanto a substituição da máquina virtual deve acontecer até 2027.

No entanto, Vitalik tem uma frase que é especialmente interessante: a Ethereum já trocou uma vez o motor enquanto estava em voo (referindo-se ao The Merge), e ainda pode trocar mais quatro vezes. Embora isso possa parecer uma afirmação leve, pense um pouco - uma rede com um valor de mercado de centenas de bilhões é capaz de mudar o mecanismo de consenso, a máquina virtual e a árvore de estados sem parar, sem afetar os usuários, algo impensável na era da internet tradicional.

Sete, minhas impressões.

A Ethereum funcionou na EVM por sete anos, e o problema do acúmulo de contratos pré-compilados sempre existiu. Por que agora fazer ajustes em grande escala? Eu acho que é porque a demanda mudou na era ZK.

No passado, a Ethereum só precisava garantir que funcionasse em hardware comum, enquanto agora a prova ZK exige que cada operação possa gerar uma prova de verificação. A EVM não considerou inicialmente a prova ZK, muitas operações não funcionam nos circuitos ZK, portanto, contratos pré-compilados tornaram-se uma solução temporária, mas essa solução provisória acumulou muitos problemas, e agora é hora de mudar.

A postura de Vitalik desta vez também está mais decidida, não é mais algo a considerar, mas sim uma questão a ser resolvida diretamente. Isso pode significar que a comunidade já alcançou um consenso interno e não pode mais adiar.

Se terá sucesso, saberemos em 2027, mas pelo menos é certo que a Ethereum não quer continuar sendo um sistema de patch na era ZK.

Quanto a como fazer isso, essa discussão é mais valiosa do que o resultado. Afinal, não há muitos lugares onde se pode discutir projetos futuros.