Desenvolvedores do Ethereum nomeiam atualização pós-Glamsterdam como 'Hegota' enquanto o roteiro para 2026 começa a tomar forma

Os desenvolvedores principais do Ethereum nomearam oficialmente a próxima atualização da rede após Glamsterdam como "Hegota", definindo ainda mais o ciclo de desenvolvimento da rede para 2026, enquanto mantém sua cadência de lançamentos duas vezes por ano.

Hegota combina a atualização da camada de execução "Bogota", seguindo a tradição de nomear atualizações com cidades anfitriãs do Devcon, com a camada de consenso "Heze", nomeada em homenagem a uma estrela. Os desenvolvedores disseram que o EIP principal para Hegota só será selecionado em fevereiro, enquanto o trabalho em Glamsterdam — a primeira atualização agendada do Ethereum para 2026 — continua.

A decisão sobre o nome foi tomada durante a chamada All Core Developers Execution (ACDE) na quinta-feira, a última reunião do ano. As chamadas ACDE estão programadas para retomar em 5 de janeiro, quando os desenvolvedores pretendem finalizar o escopo de Glamsterdam.

Ciclo de lançamentos de 2026

A nomeação ocorre em um momento em que o processo de atualização do Ethereum está se ajustando ao ritmo pretendido.

Com Pectra e Fusaka lançados em 2025, a rede efetivamente iniciou seu cronograma de atualizações semestrais. A abordagem visa tornar as melhorias mais iterativas, previsíveis e de escopo reduzido, diminuindo a necessidade de revisões raras e abrangentes.

Com base na cadência estabelecida, Glamsterdam provavelmente será lançada no primeiro semestre de 2026, com Hegota vindo posteriormente no mesmo ano.

Embora Hegota ainda esteja em planejamento inicial, espera-se que sua atualização futura seja baseada em metas de longo prazo do roadmap e em itens excedentes adiados de Glamsterdam. Em especial, as Verkle Trees — um pré-requisito para clientes totalmente stateless — têm sido frequentemente citadas como candidatas à inclusão em um dos hard forks de 2026. No entanto, nenhuma seleção formal foi feita.

Outras áreas em discussão incluem mecanismos de expiração de estado e histórico e otimizações adicionais da camada de execução. Notavelmente, as conversas sobre expiração de estado podem ganhar mais atenção após um recente lote de propostas da Ethereum Foundation.

Como relatado anteriormente pelo The Block, a equipe Stateless Consensus da EF alertou que o inchaço do estado — a expansão constante dos dados armazenados pelo Ethereum — está se tornando um fardo crescente para os operadores de nós.

Glamsterdam foca em eficiência da Layer 1 e descentralização dos construtores

Enquanto isso, os desenvolvedores continuam a refinar o hard fork de Glamsterdam. Propostas ainda em consideração incluem a separação enraizada entre proponente e construtor, ou ePBS, destinada a conter a centralização na construção de blocos; listas de acesso em nível de bloco, que visam reduzir gargalos de acesso ao estado; e reprecificação do gás para alinhar melhor os custos do EVM com o uso de recursos.

Mudanças mais complexas, como a redução dos tempos de slot, já foram adiadas para ciclos posteriores. Quaisquer itens que se mostrem ambiciosos demais para o cronograma podem ser transferidos para Hegota, com decisões finais esperadas quando as chamadas forem retomadas no novo ano.

Um roadmap que vai além de 2026

A revelação de Hegota também posiciona o Ethereum dentro de seu roadmap técnico mais amplo e multifásico. Em setembro de 2022, os desenvolvedores executaram a primeira parte desse caminho, chamada The Merge, que fez a transição do Ethereum de uma blockchain proof-of-work para uma rede proof-of-stake.

Os componentes seguintes foram definidos como The Surge, The Verge, The Purge e The Splurge.

The Surge foca em alcançar uma escalabilidade massiva impulsionada por rollups. Fusaka avançou nesse objetivo por meio do PeerDAS e da expansão da capacidade de blobs, enquanto Glamsterdam busca melhorar ainda mais o desempenho da Layer 1 para apoiar o aumento da atividade de rollups sem criar novas pressões de centralização.

Em seguida, The Verge se concentra em statelessness e verificação de light-client. A possível integração de Verkle em Hegota está diretamente alinhada com essa fase ao reduzir os requisitos de armazenamento dos nós e permitir uma participação mais ampla na rede. Fases posteriores — The Purge e The Splurge — tratam da limpeza histórica e da simplificação de longo prazo do protocolo.