O Caminho do Ethereum 2026: Desafios dos Validadores que Subestimaste

A folha de rota do Ethereum para 2026 articula-se em torno de duas estratégias fundamentais que procuram escalar simultaneamente em capacidade de dados e execução. No entanto, estas ambições trazem consigo riscos operacionais para os validadores que frequentemente passam despercebidos.

Os Dois Pilares de Escalabilidade

O Ethereum está a perseguir uma via dual: incrementar o throughput de blobs através de melhorias na disponibilidade de dados, enquanto expande a capacidade de execução na camada base ajustando o gas limit. O problema é que o segundo caminho depende de tecnologia ainda em fase experimental que os operadores de nós devem adotar sem garantias de estabilidade imediata.

A primeira via já tem âncora concreta com Fusaka, implementado a 3 de dezembro de 2025. Esta atualização introduz PeerDAS juntamente com ajustes ao parâmetro de blobs (BPO), permitindo aumentos graduais em desempenho sem obrigar cada nó a descarregar a totalidade dos dados de blobs. Segundo as orientações do ethereum.org, os objetivos de blobs não saltam imediatamente após a ativação, mas podem duplicar-se a cada poucas semanas até atingir um máximo de 48 blobs por bloco, enquanto se monitora a saúde da rede.

A equipa da Optimism projeta no seu cenário otimista “pelo menos 48 blobs objetivo”, o que implicaria aumentar o desempenho do rollup de aproximadamente 220 para perto de 3.500 UOPS. Mas aqui surge a primeira incerteza: chegará realmente a procura de uso de blobs, ou continuarão a escalar as licitações competitivas por execução em L1?

As Incógnitas de Infraestrutura

A estabilidade peer-to-peer e a largura de banda dos nós representam tensões reais à medida que o BPO aumenta. GasLimit.pics reporta um gas limit atual de 60.000.000, com uma média de 24 horas de 59.990.755 em momentos de observação. Este valor atua como ponto de referência sobre o que os validadores têm aceite na prática, mas também expõe o teto do “escalonamento social” antes que latência, carga de validação e pressões no mempool se tornem restritivas.

Traduzir o discurso sobre gas limit à velocidade de transações requer usar o intervalo de 12 segundos do Ethereum. Sob coordenação atual, o desempenho é aproximadamente 238 transações por segundo (a 21k gas) ou 42 (a 120k gas). Um cenário de 2× elevaria estes valores para 476 e 83 respetivamente, enquanto os níveis mais altos (requerendo mudanças de validação) atingiriam 793 e 139 Tx/seg.

Glamsterdam: Complexidade Oculta

A atualização prevista para 2026 agrupa iniciativas orientadas à execução sob o nome “Glamsterdam”, que engloba separação de proponente-construtor (ePBS, EIP-7732), Listas de Acesso a Nível de Bloco (BALs, EIP-7928) e reavaliação geral de gas (EIP-7904). Todas permanecem como rascunhos.

A reavaliação de gas procura corrigir desajustes acumulados ao longo de anos no esquema tarifário. O EIP-7904 argumenta que retificar erros de computação poderia aumentar o desempenho utilizável, embora reconheça riscos de DoS e a realidade de contratos inteligentes que codificam pressupostos específicos de gas.

As BALs posicionam-se como infraestrutura para paralelismo verdadeiro. O EIP menciona leituras paralelas de disco, validação concorrente de transações e cálculo paralelo de raiz de estado, estimando uma sobrecarga de aproximadamente 70-72 KiB por BAL comprimido. Mas esses ganhos teóricos só se concretizam se os clientes adotarem concorrência nos gargalos reais.

O ePBS ocupa o centro de debates porque desacopla temporariamente a validação de execução da validação de consenso, abrindo janelas para novos modos de falha. Investigação académica sobre o “problema da opção gratuita” estima exercício de opções em 0,82% de blocos em média sob janela de 8 segundos, escalando para 6% durante volatilidade extrema segundo análises no arXiv.

O Papel das ZK Proofs na Folha de Rota

A aposta mais estrutural por trás de limites de gas significativamente maiores repousa na adoção de provas de execução ZK pelos validadores. A folha de rota “Realtime Proving” da Fundação Ethereum descreve um despliegue gradual: primeiro um conjunto reduzido de validadores executa clientes ZK em produção, depois, só após uma supermaioria de stake se sentir confortável, os limites de gas podem crescer até níveis onde a verificação de provas substitua a reexecução.

As restrições técnicas importam mais do que a narrativa: objetivo de segurança de 128 bits (100 bits aceites temporariamente), tamanho da prova abaixo de 300 KiB, e evitar dependência de envoltórias recursivas com configurações fiáveis. A escalabilidade resultante está acoplada a mercados de provas: o fornecimento deve ser barato e credível sem concentrar-se em provadores únicos que recriem dependências do tipo relay noutra camada do stack.

Hegota e Cronograma Crítico

“Hegota” posiciona-se como faixa temporal para finais de 2026, mais focada em processo do que em alcance definitivo. A Fundação Ethereum estabeleceu janela de propostas principais de 8 de janeiro a 4 de fevereiro, discussão de 5 a 26 de fevereiro, depois janela para propostas secundárias.

O meta-EIP de Hegota (EIP-8081) enumera elementos como “considerados” em vez de “fijados”, incluindo FOCIL (EIP-7805). O valor real a curto prazo é que cria pontos de decisão com data específica que investidores e desenvolvedores podem monitorizar sem inferir compromissos de nomes em chave.

O primeiro marco crítico: encerramento das propostas principais de Hegota a 4 de fevereiro. Este calendário fornece visibilidade sobre quais elementos da folha de rota do Ethereum para 2026 avançarão realmente para implementação versus o que permanecerá em debate especulativo.

O Que os Validadores Devem Preparar-se para Confrontar

O risco para os validadores não é catastrófico, mas é multidimensional. Largura de banda, sincronização de estado, novas dependências de provadores ZK, e a possibilidade de que características planeadas não se materializem dentro do cronograma esperado. A coordenação social no gas limit tem limites onde a física de propagação de blocos e capacidade de validação se tornam restritivas, e ninguém pode simplesmente “atualizar” a velocidade da luz.

A verdadeira questão que a folha de rota do Ethereum para 2026 coloca aos operadores de infraestrutura é se estão dispostos a investir em hardware e software novos para funcionalidades que podem atrasar-se ou não chegar a ser amplamente adotadas se a procura real de mercado divergir das projeções técnicas.