## Ethereum enfrenta uma encrucilhada crítica na sua roadmap 2026: o desafio oculto para os validadores

A estratégia de escalabilidade do Ethereum para 2026 bifurca-se em dois caminhos simultâneos. Por um lado, amplia-se a capacidade de dados através de blobs; por outro, busca-se elevar o desempenho da camada base ajustando os parâmetros de gas. A complexidade reside no facto de ambos os objetivos dependerem de mudanças fundamentais na forma como os validadores processam e verificam informações. Esta transição silenciosa esconde riscos operacionais maiores do que os titulares técnicos sugerem.

## O debut de Fusaka: primeiro passo na roadmap

Fusaka, lançada a 3 de dezembro de 2025, marca o marco inicial. Esta atualização implementa PeerDAS juntamente com ajustes granulares nos parâmetros de blob (BPO). Ao contrário de mudanças radicais, esta abordagem permite aumentar o desempenho por etapas medidas, permitindo que a rede se adapte progressivamente.

PeerDAS é a alavanca mais direta para incrementar capacidade: permite que os rollups acessem maior disponibilidade de dados sem obrigar cada nó a descarregar todos os blobs. Inicialmente, os objetivos de blobs não se elevam de imediato após a ativação. Posteriormente, podem duplicar-se a cada poucas semanas até atingir um máximo de 48 blobs por bloco, sempre sob supervisão da saúde da rede.

Os dados da equipa Optimism projetam um desempenho em rollups que se multiplicaria: aproximadamente de 220 a perto de 3.500 UOPS sob esse objetivo de 48 blobs. No entanto, uma questão prática persiste para 2026: chegará a procura real na forma de uso de blobs, ou as licitações por execução em L1 continuarão a dominar? Além disso, a estabilidade P2P e o consumo de largura de banda dos nós devem manter-se dentro de tolerâncias operacionais enquanto o BPO aumenta.

## O teto do escalonamento social: métricas de gas que importam

Em paralelo, o Ethereum experimenta com maior desempenho através de coordenação em vez de bifurcações duras. O registo mais recente mostra um limite de gas de 60.000.000, com uma média de 24 horas próxima de 59.990.755. Este nível atua como ponto de referência do que os validadores aceitaram praticar. Também expõe o limite do "escalonamento social" antes de que latência, carga de validação, tensão no mempool e competição MEV se tornem limitantes.

Converter estes números de gas em desempenho utiliza o intervalo de blocos de 12 segundos do Ethereum. A tabela de cenários revela:

**Cenário Atual de Coordenação**: 60.000.000 de limite de gas = ~5.000.000 gas/segundo = ~238 transações/segundo (a 21k gas) ou ~42 transações/segundo (a 120k gas).

**Cenário 2× limite de gas**: 120.000.000 de limite = ~10.000.000 gas/segundo = ~476 tx/s (a 21k) ou ~83 tx/s (a 120k).

**Cenário de desempenho máximo** (requer mudança de validação): 200.000.000 de limite = ~16.666.667 gas/segundo = ~793 tx/s (a 21k) ou ~139 tx/s (a 120k).

Estas escalas representam o espectro teórico, mas cada nível introduz complexidades operacionais que os validadores devem absorver.

## Glamsterdam: a convergência de três frentes de execução

O nome-chave "Glamsterdam" agrupa múltiplas propostas orientadas a otimizar execução sob uma sombrinha conceptual. Três elementos-chave permanecem em estado de rascunho segundo as respetivas páginas EIP:

**ePBS (EIP-7732) — Proposição-Construção Separadas Encriptadas**: Desacopla temporariamente a validação de execução da validação de consenso. Esta flexibilidade temporária, embora poderosa para o desempenho, é precisamente onde podem surgir novos modos de falha. Investigação académica sobre o "problema da opção gratuita" estima que os validadores exerceriam opções em aproximadamente 0,82% dos blocos sob condições normais, mas este percentual salta para 6% durante dias de alta volatilidade. Estes episódios de exercício de opção representam momentos em que a rede experimenta pressão não linear.

**BALs (EIP-7928) — Listas de Acesso a Nível de Bloco**: Posicionam-se como infraestrutura para paralelismo. A proposta contempla leituras paralelas de disco, validação concorrente de transações, cálculo paralelo de raiz de estado e "atualizações de estado sem execução". O overhead médio estimado é de 70-72 KiB comprimido por bloco. A lacuna entre teoria e prática é significativa: estes ganhos só se materializam se os clientes implementarem verdadeira concorrência nos gargalos reais. Além disso, os dados e passos de verificação adicionais não podem tornar-se no seu próprio imposto de latência.

**Reavaliação Geral (EIP-7904)**: Aborda desajustes crónicos no esquema de gas que persistiram anos. A correção de cálculos errados de computação poderia aumentar o desempenho utilizável, mas com riscos de ataques de negação de serviço e a realidade de contratos que codificam pressupostos de gas específicos.

## O risco verdadeiro: a carga sobre os validadores

Aqui está o risco que supera o óbvio: a transição de reexecutar blocos para verificar provas ZK não é apenas uma mudança técnica, mas uma transformação operacional profunda para os validadores.

A roadmap "Realtime Proving" da Ethereum Foundation descreve um deployment escalonado onde primeiro um pequeno grupo de validadores executa clientes ZK em produção. Só após uma supermaioria de stake se sentir confortável, os limites de gas podem ser elevados a níveis onde a verificação de provas substitua a reexecução como mecanismo prático em hardware razoável.

As restrições técnicas importam mais do que a narrativa: objetivo de segurança de 128 bits (com 100 bits aceites temporariamente), tamanho de prova inferior a 300 KiB, e evitar dependências de envoltórios recursivos com configurações de confiança. Mais criticamente, a escalabilidade vinculada a mercados de provas requer que o fornecimento de provas seja económico e credível sem concentrar-se num pequeno conjunto de provadores que recriariam dependências tipo relay noutra camada do stack.

## Hegota: cronograma visível para decisões cruciais

Após Glamsterdam, "Hegota" surge como uma etiqueta para finais de 2026, embora o seu alcance continue a ser processual mais do que definido. A Ethereum Foundation estabeleceu um cronograma explícito: janela de propostas principais de 8 de janeiro a 4 de fevereiro, seguida de discussão e finalização de 5 a 26 de fevereiro, com uma janela posterior para propostas não principais.

O meta-EIP de Hegota (EIP-8081) em estado de rascunho enumera elementos "considerados" em vez de fixados, incluindo FOCIL (EIP-7805) atualmente sob consideração. O valor imediato reside em criar pontos de decisão com data que investidores e desenvolvedores podem rastrear sem inferir compromissos de nomes em chave. O primeiro marco crítico: as propostas principais de Hegota encerram a 4 de fevereiro.

## A conclusão: uma roadmap que exige adaptação operacional

A roadmap do Ethereum para 2026 não apresenta apenas mudanças técnicas, mas uma reconfiguração do papel do validador. A transição de coordenação de desempenho social para dependência de provas ZK, combinada com aumentos de gas e maior processamento paralelo, cria uma janela de vulnerabilidade operacional. Os validadores não só precisam de nova infraestrutura; devem confiar em mercados de provas que ainda não existem à escala. Esta é a premissa silenciosa que faz com que os riscos sejam maiores do que aparentam em retrospectiva técnica.