Evolução Completa da Arquitetura EVM: Estratégia de Escalonamento Gradual do Ethereum

Com a rápida expansão do ecossistema Ethereum, como escalar a rede enquanto se mantém a segurança e a descentralização emergiu como um dos desafios mais importantes. O roteiro técnico apresentado por Vitalik Buterin oferece uma abordagem abrangente para a eficiência e expansão do EVM. Trata-se de uma estratégia que visa aumentar gradualmente a capacidade de processamento do Ethereum em duas camadas distintas, de curto prazo e longo prazo.

EVM do Ethereum: Otimização de Gas e Paralelização da Verificação de Blocos para Curto Prazo

As estratégias de escalonamento de curto prazo concentram-se na maximização da eficiência operacional, aproveitando o design das máquinas EVM existentes. Espera-se que melhorias técnicas centradas na atualização Glamsterdam aumentem gradualmente a capacidade de processamento da rede.

A introdução de um mecanismo de lista de acesso em nível de bloco permitirá a paralelização do processo de validação de blocos do EVM. O trabalho de validação, que anteriormente era executado em ordem, poderá agora ser processado simultaneamente em vários processos, resultando na redução do tempo total de geração de blocos. Esta é uma melhoria que se traduz diretamente em um aumento da velocidade de processamento de transações em toda a rede.

A ePBS (Encrypted Proposer-Builder Separation), que será implementada também em Glamsterdam, possui várias funcionalidades importantes. Um ponto particularmente notável é a capacidade de expandir o tempo dedicado à verificação de blocos em cada slot, de centenas de milissegundos tradicionais para uma proporção de tempo maior. Isso cria uma folga no processo de verificação, permitindo que mais dados sejam processados de forma segura.

Mecanismo de Gás Multidimensional: Inovação no Design EVM

O mecanismo de redefinição de gás não é apenas um ajuste de tarifas, mas significa uma mudança fundamental na filosofia de design do EVM. Se o custo de gás para várias operações passar a corresponder exatamente ao tempo de execução e ao consumo de recursos correspondente, será possível uma distribuição mais eficiente dos recursos da rede.

A introdução do gás multidimensional evoluirá o mecanismo de gás, que até agora era gerenciado em uma única dimensão, para uma estrutura que permite a gestão de limites independentes para cada tipo de recurso. Na primeira fase, está planejado separar o “custo de criação de estado” do “custo de execução e calldata” na atualização do Glamsterdam.

Um exemplo concreto é que, na operação SSTORE atual, mudar um slot de armazenamento de zero para não zero consome 20000 gás. Após a reavaliação em Glamsterdam, espera-se que esse custo aumente drasticamente, subindo para cerca de 60000 gás. Essa mudança, que à primeira vista parece negativa, na verdade tem um objetivo estratégico. Ao expandir simultaneamente o limite de gás, é possível superar significativamente a velocidade de expansão da capacidade de execução da validação de blocos em relação à velocidade de aumento do tamanho do estado da blockchain.

No design existente do EVM, o gás é implementado como uma única dimensão. Portanto, todos os opcodes, como GAS e CALL, baseiam-se nesta premissa, mas a transição para um gás multidimensional requer que esta suposição básica não seja alterada e a compatibilidade retroativa seja mantida.

A solução adotada deverá respeitar as seguintes condições inalteráveis. Em primeiro lugar, se uma chamada for iniciada com gás X, essa chamada deve possuir gás X e deve poder ser utilizada para operações normais, criação de estado ou em outras dimensões que possam ser adicionadas no futuro. Em segundo lugar, se o opcode GAS indicar que atualmente há gás Y, isso significa que, mesmo que uma chamada que consome gás X seja emitida, deve restar pelo menos Y - X gás após o retorno da chamada, que deve estar disponível para operações subsequentes.

Na implementação específica, introduzimos N+1 dimensões de gás. Por padrão, N=1 (criação de estado), e a dimensão adicional é chamada de “reservatório”. A lógica de execução EVM prioriza o consumo de gás da dimensão dedicada sempre que possível, e, na falta, realiza um consumo adicional a partir do reservatório.

Por exemplo, no caso de ter gás (100000 para a criação de estado, 100000 reservatório ), ao usar SSTORE para criar um novo estado 3 vezes, a transição de gás será (100000, 100000)→ (45000, 95000)→ (0, 80000)→ (0, 20000). Neste design, o opcode GAS retorna o reservatório, e o CALL passa a quantidade especificada de gás do reservatório, enquanto também passa todo o gás que não é do reservatório ao mesmo tempo.

A introdução de uma estratégia de preços multidimensional que aplica diferentes taxas de gás variáveis a múltiplas dimensões de recursos espera-se que melhore a sustentabilidade econômica a longo prazo e realize uma eficiência de alocação de recursos superior.

longo prazo de escalonamento: a fusão de ZK-EVM e Blobs

Enquanto as melhorias de curto prazo aumentam a eficiência das máquinas EVM existentes, as estratégias de escalonamento a longo prazo visam mudanças de design mais fundamentais. As duas principais direções tecnológicas, ZK-EVM (verificação de execução EVM baseada em provas de conhecimento zero) e Blobs, moldarão o futuro do Ethereum.

Atualmente, em 2026, a emergência de clientes compatíveis com ZK-EVM está prestes a se tornar uma realidade. Estamos chegando a um estágio em que os nós poderão participar da atestação (verificação de assinatura na rede) usando ZK-EVM. No entanto, nesta fase inicial, esses clientes ainda não alcançaram um nível de segurança adequado, portanto, a rede como um todo não pode depender completamente deles. É aceitável que cerca de 5% dos nós da rede usem ZK-EVM, mas a adoção acima dessa proporção será evitada. Neste estágio, se surgirem problemas com a prova ZK-EVM, as recompensas de staking dos nós individuais não serão penalizadas, mas existe a possibilidade de construção de blocos inválidos, o que pode levar à perda de receita para esses nós.

Em 2027, recomenda-se que mais nós executem o ZK-EVM, avançando para uma fase em que se dá ênfase à verificação formal e à melhoria contínua da segurança. O mais importante é que, com apenas 20% dos nós da rede usando o ZK-EVM, será possível oferecer caminhos de verificação de baixo custo para os solo stakers, o que permitirá um aumento significativo no limite de gás. Considerando que o total de solo stakers é inferior a 20% da rede, as melhorias nesta fase beneficiarão muitos usuários.

Está previsto que, numa fase em que a tecnologia esteja suficientemente madura, seja introduzido um mecanismo de prova forçada 3-of-5. Isso significa que, para que um bloco seja considerado válido, deve incluir pelo menos 3 provas de 5 sistemas de prova diferentes. Este mecanismo de prova diversificada ajuda a reduzir o risco de depender de uma única tecnologia e pode aumentar ainda mais a resiliência da rede. Numa fase posterior, espera-se que a maioria dos nós, exceto aqueles que necessitam de funções de índice, transitem para um estado em que dependam de provas ZK-EVM.

A longo prazo, o objetivo é melhorar ainda mais o ZK-EVM de forma robusta e realizar verificações formais mais rigorosas. Nesta fase, também serão considerados mudanças estruturais a nível de máquina virtual, incluindo direções como RISC-V. Isso sugere a possibilidade de evoluir fundamentalmente o design mecânico do EVM.

Evolução para Blobs e Camadas de Dados Avançadas

Em relação aos Blobs, com a melhoria contínua da camada de transporte PeerDA, o objetivo é alcançar, eventualmente, uma taxa de transferência de dados de cerca de 8 MB/s. Este nível de capacidade de processamento de dados é suficiente para atender à demanda da própria Ethereum. No entanto, não se pretende que a Ethereum se torne uma camada de dados em escala global, mas sim atender a nível de demanda como uma rede independente.

Atualmente, os Blobs são principalmente utilizados para armazenamento de dados em soluções de camada 2 (L2). Como evolução futura, está sendo considerado a possibilidade de escrever diretamente os dados do próprio bloco do Ethereum nos Blobs. O objetivo dessa mudança é extremamente importante. Será possível validar uma rede Ethereum altamente escalonada sem precisar baixar e reexecutar toda a cadeia.

A realização deste objetivo combina duas tecnologias importantes. Primeiro, os ZK-SNARKs (provas de conhecimento zero concisas e não interativas) eliminam a necessidade do próprio processo de reexecução. Em seguida, com o PeerDAS e os Blobs, será possível validar a disponibilidade dos dados sem a necessidade de baixar todos os dados. Esta combinação tornará a participação na verificação completa da rede uma realidade, mesmo para nós leves.

A estratégia de escalonamento do Ethereum demonstra uma abordagem para expandir gradualmente a capacidade da rede, equilibrando a eficiência de curto prazo e a evolução estrutural de longo prazo. A otimização contínua do EVM e a introdução gradual de novas tecnologias de validação determinarão o desenvolvimento da rede Ethereum nos próximos anos.