O Ethereum ativa Glamsterdam na Sepolia em 6 de outubro. O Alpenglow da Solana já está ativo na testnet. As duas atualizações reformulam a mecânica da camada de consenso no mesmo mês. Este relatório compara as duas mudanças com dados.
O que é Glamsterdam
Glamsterdam é o próximo hard fork do Ethereum, previsto para o quarto trimestre de 2026 na mainnet. Ele combina duas atualizações de camada: Amsterdam (execução) e Gloas (consenso). A Ethereum Foundation confirmou a ativação na testnet Sepolia no epoch 353.024, slot 11.296.768, em 6 de outubro, às 13:53:36 UTC.
A atualização é acompanhada sob a Meta EIP-7773. Ela inclui dez EIPs nas camadas de consenso e execução. As duas propostas principais são a EIP-7732 e a EIP-7928. Essas duas EIPs funcionam como um par interligado.
EIP-7732: separação incorporada ao protocolo entre proponente e construtor
Atualmente, mais de 90% dos blocos do Ethereum são construídos por relays MEV-Boost externos. Os quatro principais construtores são responsáveis por mais de 90% de todos os blocos (pontuação HHI: 3.892). Esses relays operam inteiramente off-chain, sem prestação de contas ao protocolo.
A EIP-7732 incorpora diretamente ao protocolo de consenso a separação entre proponente e construtor. Um construtor passa a ser um participante da camada de consenso com stake. O proponente assume o compromisso com a oferta de um construtor. Depois, o construtor revela o payload. Um novo comitê de pontualidade do payload (PTC) atesta se os dados chegaram a tempo.
O ePBS também amplia a janela de propagação de dados de 2 para aproximadamente 9 segundos. Isso permite blocos maiores e mais capacidade de blobs por slot sem ultrapassar o prazo de 12 segundos do slot.
EIP-7928: listas de acesso em nível de bloco
Como mostra o gráfico, o consumo diário de gas do Ethereum historicamente cresceu em etapas distintas, acompanhando os aumentos do limite de gas dos blocos e ficando em torno de 215–220 bilhões de gas por dia em 2026. A EIP-7928 possibilita três mudanças concretas na execução para aumentar essa capacidade com segurança: leituras paralelas em disco entre núcleos de CPU, validação paralela de transações e reconstrução de estado sem execução para clientes leves. Em conjunto, essas otimizações tornam seguro escalar para um limite de 200M de gas em hardware padrão de validador.
Sem a EIP-7928, triplicar o limite de gas para além dos níveis diários atuais imporia um overhead de execução sequencial proporcionalmente maior a cada validador. O Devnet-11 executou com sucesso 84.000 validadores simulados a 200M de gas, sem falha de finalidade, abrindo caminho para a ativação da testnet Sepolia em 6 de outubro.
Mudanças nos preços de gas: EIP-8037 e EIP-8038
Glamsterdam reajusta os preços de duas categorias de acesso ao estado. A EIP-8037 aumenta o custo de criar novas entradas de estado. A EIP-8038 atualiza o custo de ler estados existentes. O reajuste aproxima os custos de gas do uso real de recursos de hardware. Os desenvolvedores de aplicações devem testar os contratos segundo as novas regras antes da mainnet.
Cronograma de ativação do Glamsterdam
RedeDataStatusObservaçõesTestnet Sepolia6 de out. de 2026 (13:53:36) UTCConfirmadoÉpoca 353.024 / Slot 11.296.768Testnet Hoodi27 de out. de 2026 (provisório)Não confirmadoDepende da estabilidade da SepoliaMainnet4.º trimestre de 2026 (sem data)Não confirmadoAnúncio separado pendente
Os operadores da Arbitrum Sepolia devem atualizar para o Nitro v3.11.4 antes de 6 de outubro. Glamsterdam adiciona novos campos aos cabeçalhos dos blocos do Ethereum. Lotes estimados antes do fork e incluídos depois dele podem falhar devido às novas regras de gas.
Após a ativação, o Prysm 7.2.0 define por padrão um limite de 60M de gas. Os validadores que pretendem atingir 200M devem configurá-lo manualmente por meio de um arquivo de configurações de proponente versão 2 ou da API do keymanager. A flag ‘suggested-gas-limit’ não tem efeito após o fork Gloas.
O que é Alpenglow
Alpenglow é a maior mudança de protocolo da Solana desde o lançamento. Substitui o TowerBFT, o mecanismo de consenso atual, por um sistema de dois componentes chamado Votor e Rotor. A atualização foi aprovada por votação de governança dos validadores (SIMD-0326) em setembro de 2025, com 98,27% de aprovação e participação de 52% dos tokens em stake.
Alpenglow foi ativado no cluster de testes dedicado da comunidade e, em seguida, na testnet, na última semana de setembro de 2026. A ativação na mainnet ocorrerá com o Agave 4.3, prevista para outubro de 2026, sem altura de bloco confirmada.
Fase 1: Votor
No consenso TowerBFT legado da Solana, a rede paga um preço alto em desempenho: cada voto de validador precisa ser processado e enviado como uma transação padrão on-chain. Essas transações de manutenção do consenso congestionam frequentemente o ledger e consomem enormes quantidades de espaço dos blocos. O acompanhamento acadêmico de transações do início de 2024 até o primeiro trimestre de 2026 (segundo o graoh) confirma que as transações de voto (em rosa) representaram consistentemente, em média, 71,5% e, no máximo, cerca de 75% do total de transações na Solana, inflando artificialmente as métricas de throughput.
O Votor elimina esse overhead estrutural ao retirar completamente da cadeia as transações de voto. Os validadores trocam certificados de assinatura BLS diretamente entre si, peer-to-peer e off-chain, e enviam à cadeia um único certificado agregado de aproximadamente 1.000 bytes por bloco, em vez de milhões de transações de voto individuais. Isso libera estruturalmente mais de 70% da capacidade atual dos blocos para transações reais de usuários.
Para isso, o Votor executa dois caminhos de finalização simultâneos: um caminho rápido, em que os blocos são finalizados em uma única rodada de votação, e um caminho lento, em que uma segunda rodada conclui a finalização se menos validadores responderem dentro do prazo. A meta combinada é de 100 a 150 milissegundos para a finalidade econômica, o que representa uma redução de 99% no tempo de espera em comparação com os atuais 12,8 segundos.
Tolerância a falhas: de 33% para 20% + 20%
O TowerBFT exige que mais de dois terços do stake (67%) sejam honestos e estejam online para que o consenso prossiga. Uma rede em que 34% dos validadores são adversariais faz o TowerBFT parar.
O Votor altera o modelo de falhas. Ele tolera simultaneamente até 20% de stake adversarial e 20% de stake offline, o que significa resiliência a falhas de até 40% no total. A contrapartida é um limite adversarial bizantino mais restrito (de 33% para 20%). Ao reduzir esse limite, o Votor pode finalizar em uma única rodada, em vez de duas, o que permite atingir a meta de 150 ms.
A prova de segurança que fundamenta o Votor foi desenvolvida pela Anza em colaboração com pesquisadores da ETH Zurich. Ela foi verificada formalmente, e não se baseia em simulações, ao contrário do modelo de segurança empírico do TowerBFT.
Fase 2: Rotor
O Rotor substitui o Turbine, o protocolo atual de propagação de dados de blocos da Solana. O Turbine usa uma árvore de nós com vários saltos para distribuir os dados dos blocos entre os validadores. O Rotor substitui a árvore por uma única camada de relay, reduzindo os saltos de propagação. O Rotor não tem data de ativação confirmada e não faz parte do lançamento do Agave 4.3.
Comparação lado a lado
DimensãoEthereum GlamsterdamSolana Alpenglow (Votor)Tipo de atualizaçãoHard fork (transição coordenada)Feature gate (supermaioria do stake)Data da testnetSepolia em 6 de out. (confirmada)Testnet ativa desde 24–25 de set. (confirmada)Data da mainnet4.º trimestre de 2026 (sem data confirmada)Agave 4.3 (previsto para outubro, mas sem data definida)Mudança na finalidadeNenhuma com esta atualização12,8 s para 100–150 ms (redução de 99%)Mudança no throughput60M para 200M de gas/bloco (3,3x)75% do espaço dos blocos liberado das transações de votoMudança em relays/confiançaMais de 90% dos blocos dependem de relays off-chainSem mudança nos relaysTolerância a falhasInalterada (máximo de 33% adversarial)20% adversarial + 20% offlineTipo de prova de segurançaSimulação e testes empíricosVerificação formal (ETH Zurich)Impacto nas taxasTransferências de ETH com redução projetada de 71%Economia nas taxas de voto de aprox. 0,56 SOL por épocaFase 2 previstaTestnet Hoodi em 27 de out. (provisória)Rotor (sem data confirmada)O que NÃO resolveVelocidade de finalidade. Pressupostos de confiança das L2.Throughput bruto. Propagação de blocos.
Principais diferenças de abordagem
Conforme mostram os dados atuais das redes em operação da Chainspect, há um contraste marcante na finalidade econômica de referência: atualmente, a Solana leva 12,8 segundos para alcançar o estado totalmente finalizado com o TowerBFT, enquanto o Ethereum precisa de 12 minutos e 48 segundos.
O Alpenglow aborda diretamente essa diferença na Solana, usando o Votor para reduzir o atraso de 12,8 segundos para 100–150 milissegundos em condições de consenso pelo caminho rápido. Isso é possível ao eliminar as transações de voto, que atualmente consomem até 75% do espaço dos blocos da Solana, liberando indiretamente uma enorme capacidade para transações de usuários, sem aumentar diretamente o throughput bruto de transações por si só.
Em contrapartida, Glamsterdam mantém inalterada a finalidade do Ethereum, de 12 min e 48 s, concentrando-se, em vez disso, em escalar a capacidade de execução em bloco único de 60M para 200M de gas. Ao tornar mais seguro criar blocos maiores e executá-los em paralelo, Glamsterdam proporciona uma expansão de 3,3x do limite de gas, ampliando o espaço dos blocos.
Em última análise, nenhuma das atualizações resolve o problema que a outra pretende abordar: a finalidade multiépoca do Ethereum permanece inalterada, e o motor central de transações da Solana depende do Votor para obter velocidade, não para escalar a execução bruta. Essas métricas distintas mostram como cada rede prioriza sua principal limitação por meio de soluções paralelas: o Ethereum expande a capacidade do espaço dos blocos, enquanto a Solana busca liquidação em menos de um segundo.
O que acompanhar em outubro
Para o Ethereum: os dados da Sepolia a partir de 6 de outubro mostrarão se a referência de 200M de gas do Devnet-11 se mantém em condições reais de validação. A ativação da testnet Hoodi (provisoriamente em 27 de outubro) é o próximo marco definido antes do anúncio da mainnet.
Para a Solana: o Agave 4.3 ainda não tem data de lançamento confirmada. Em 5 de outubro, a mainnet continua no TowerBFT. A sequência é: lançamento do Agave 4.3, atualizações dos validadores e ativação do feature gate por supermaioria. Não há um único número de bloco de ativação para acompanhar antecipadamente.