Ethereum (ETH) ensaiou a sua próxima grande atualização em 6 de outubro. Poucos, fora dos canais de desenvolvimento, deram por isso. Mas a testnet Sepolia passou a operar com regras que alteram quem constrói blocos, como o gas é precificado e quanta carga computacional cada bloco consegue suportar.
Este guia destrinça as 18 alterações centrais de Glamsterdam — lideradas pela separação enraizada entre proponente e construtor (ePBS), listas de acesso ao nível de bloco e reproposição de gas — e o que elas significam para taxas, MEV, rollups e o plano de subir o limite de gas para 200 milhões.
- Glamsterdam entrou em funcionamento na testnet Sepolia da Ethereum em 6 de outubro de 2026, e os developers marcaram 26 de outubro para a testnet Hoodi. Não há data de mainnet, embora uma proposta preliminar de agendamento aponte opções para o início de dezembro.
- A atualização integra no protocolo a passagem de bastão entre proponente e construtor, adiciona listas de acesso ao nível de bloco para processamento paralelo e reproporciona como a Ethereum cobra por criação e leitura de estado.
- Após Glamsterdam, os developers convergiram para um piso de 200 milhões de gas por bloco, mais do triplo do padrão atual de 60 milhões, embora o impacto nas taxas dependa da procura e da adoção pelos validadores.
O que é a atualização Glamsterdam da Ethereum e por que é relevante?
Glamsterdam é o upgrade de rede que sucede a Fusaka, e o nome junta duas metades. O lado da camada de execução chama-se Amsterdam, em homenagem à cidade anfitriã do Devconnect 2022, enquanto o lado de consenso é Gloas, batizado em referência a uma estrela.
A Ethereum Foundation publicou o anúncio da testnet em 28 de setembro. A ativação em Sepolia foi agendada para o epoch 353.024, slot 11.296.768, às 13:53:36 UTC de 6 de outubro.
O fork aconteceu na hora marcada.
A investigadora independente de Ethereum Christine D. Kim relatou, em 9 de outubro, que a atualização em Sepolia “correu bem”. Os developers agendaram depois Glamsterdam para a Hoodi, a segunda e última testnet pública, para segunda‑feira, 26 de outubro, com lançamentos de clientes previstos até 16 de outubro.
O âmbito técnico está consolidado na proposta de acompanhamento EIP‑7773. Ela organiza 18 mudanças nucleares, apoiadas por cinco propostas de rede e duas informativas.
Já a mainnet é outra conversa. A fundação afirmou que as datas de Hoodi e mainnet “ainda não foram decididas”, e o ethereum.org continua a apontar apenas uma janela genérica para o quarto trimestre de 2026.
Uma proposta preliminar de calendário no GitHub sugere 1, 8 e 9 de dezembro como potenciais datas de mainnet, mas não há consenso entre os developers.
Por que isto importa? Durante anos, a Ethereum empurrou a maior parte do esforço de escalabilidade para os rollups e manteve a camada base conservadora. Glamsterdam marca uma mudança visível de foco.
A fundação enquadra o upgrade como o próximo passo para escalar a Layer 1. As funcionalidades de destaque existem sobretudo para permitir que a cadeia base processe, com segurança, muito mais atividade, ajustando o preço do gas ao custo real de execução e crescimento de estado.
Leia também: Interface inteligente do ChatGPT leva gráficos e calculadoras às respostas de 1,2B de utilizadores
Em que Glamsterdam difere de Pectra e Fusaka?
As duas últimas atualizações da Ethereum focaram‑se sobretudo em staking e dados. Glamsterdam é sobre execução — a parte do sistema que efetivamente corre as transações.
Pectra entrou em produção em 7 de maio de 2025, no epoch 364.032. Ela permitiu que carteiras comuns delegassem para código de smart contracts via EIP‑7702, elevou o saldo máximo de cada validador de 32 para 2.048 Ether e aumentou a meta de blobs para seis, com máximo de nove.
Fusaka foi ativada em 3 de dezembro de 2025, às 21:49:11 UTC. A sua estrela foi o PeerDAS, ou EIP‑7594, que permite aos nós verificarem dados de blobs amostrando pequenas partes, sem descarregar tudo.
Fusaka também introduziu forks “apenas de parâmetros de blob”, pequenos ajustes de configuração que alteram a capacidade de blobs sem agregarem outras funcionalidades. Dois desses ajustes vieram em 9 de dezembro de 2025 e 7 de janeiro de 2026.
A atualização Checkpoint de janeiro da fundação registou que a Ethereum passou a ter como alvo 14 blobs por bloco, com máximo de 21. Isso representa, segundo a fundação, um aumento de 2,3 vezes na capacidade de dados para Layer 2 face ao período pré‑Fusaka.
No lado da execução, Fusaka limitou cada transação a cerca de 16,8 milhões de gas e fixou, nos clientes, o limite padrão de gas por bloco em 60 milhões.
Glamsterdam muda a ordem das prioridades. Em vez de adicionar mais espaço para dados de rollups, ela reconstrói o modo como blocos são produzidos, validados e precificados, abrindo caminho para que o teto de 60 milhões suba muito mais.
Pectra e Fusaka alargaram os “canos” para as Layer 2, enquanto Glamsterdam mexe na “sala de máquinas” da Layer 1.
Leia também: Conseguirá a TRON blindar US$ 95B em stablecoins contra ataques quânticos? Sun diz que sim
O que é a separação enraizada entre proponente e construtor (ePBS)?
Hoje, a maioria dos blocos da Ethereum não é montada pelo próprio validador que a propõe. Construtores especializados competem para formar o bloco mais lucrativo, e um validador, usando o MEV‑Boost da Flashbots, escolhe o maior lance.
Essa troca depende de relays, que funcionam como intermediários de confiança. O relay guarda o bloco do construtor, mostra ao proponente apenas o cabeçalho e o valor da oferta, e só revela o conteúdo integral depois de o proponente assinar.
O modelo funciona, mas está totalmente fora do protocolo. Se um relay falhar, agir de forma maliciosa ou censurar, as regras de consenso da Ethereum não oferecem recurso direto.
A EIP‑7732 leva essa negociação para dentro da própria Ethereum. Construtores passam a ser participantes de protocolo, e os validadores ganham um novo dever: as chamadas “attestations de pontualidade de payload” (payload timeliness attestations).
No novo fluxo, o proponente inclui, no bloco da beacon chain, o compromisso assinado por um construtor a respeito de um payload de execução; o construtor revela o payload depois. O próprio protocolo cuida do pagamento ao proponente, reduzindo a dependência de middleware confiável.
Um subconjunto de validadores forma o comité de pontualidade de payload. Os seus membros atestam se o construtor revelou o payload a tempo e se os dados de blob correspondentes estavam disponíveis.
A mudança também separa a validação de consenso da validação de execução — e é aí que a escalabilidade entra em jogo.
A página de roteiro no ethereum.org afirma que essa separação alarga a janela de difusão de dados pela rede de 2 para cerca de 9 segundos. Mais tempo significa que validadores podem lidar, com segurança, com payloads muito maiores.
Os relays não desaparecem de imediato. A mesma página observa que construtores e proponentes podem continuar a usar relays externos ou outro middleware para funcionalidades avançadas que o protocolo base ainda não suporta.
Leia também: Claude Mythos 5 chegou a sites governamentais, e a Anthropic decidiu cortar os testes
Como Glamsterdam pode mexer no MEV e na economia dos validadores da Ethereum?
MEV, ou valor máximo extraível, é o lucro obtido ao ordenar, incluir ou excluir transações. Por via do MEV‑Boost, boa parte desse valor chega aos validadores sob a forma de lances de construtores, mas o mercado por trás desses lances é altamente concentrado.
O painel Relayscan da Flashbots mostrava a Titan a construir 52,6% dos blocos MEV‑Boost nas 24 horas até o início de 12 de outubro. A Quasar respondia por 18,5% e a BuilderNet por 13,3%, deixando três construtores com cerca de 84% do fluxo.
O ePBS não elimina o MEV, nem dissolve automaticamente a concentração entre construtores. O que ele muda é o modelo de confiança: o pagamento ao proponente deixa de depender de a relay cumprir a palavra.
Para stakers, o ganho aparece na margem. Um validador solo passa a ter um meio, imposto pelo próprio protocolo, de vender espaço em bloco, enquanto construtores têm de colocar stake próprio para participar.
Os stakers também ganham saídas mais rápidas. Pela EIP‑8061, a capacidade de saques cresce com o total de Ether em staking; segundo o ethereum.org, isso praticamente quadruplica a capacidade atual e duplica a margem para consolidação de validadores.
A contrapartida é uma janela de segurança mais curta para nós que ficam offline. Ainda segundo o ethereum.org, o período de “weak subjectivity” — após o qual um nó que regressa precisa de um checkpoint recente confiável — cai de cerca de 15,7 para aproximadamente 7 dias.
Developers reunidos no Soldøgn interop, em Svalbard, um encontro de primavera com pouco mais de 100 contribuidores core, destacaram duas questões controversas do ePBS. Uma é como proteger um desenho que exige apenas 1 ETH de stake por construtor contra ataques Sybil na rede peer‑to‑peer.
A preocupação reapareceu antes de Sepolia. Numa call de consenso de 17 de setembro, o developer da Prysm conhecido como Potuz alertou que Ether de teste gratuito permitiria a um atacante vencer leilões com construtores descartáveis e depois reter os payloads: “Posso simplesmente lançar mil construtores.”
Os primeiros dados de Sepolia apontam para um mercado ralo. Um resumo comunitário da call de 8 de outubro sobre a camada de execução citou a EthPandaOps a dizer que apenas quatro ou cinco construtores estavam ativos ali, com grandes players ausentes e muitos blocos ainda construídos localmente.
O ePBS só prova o seu valor quando construtores reais disputam blocos — o que faz de Hoodi o teste mais revelador.
Leia também: Dobravel iPhone Duo pode cumprimentar compradores pessoalmente ao ligar pela primeira vez por US$ 1.999
O que são listas de acesso ao nível de bloco e como melhoram o processamento de transações?
Hoje, os clientes da Ethereum processam, em grande medida, as transações de um bloco de forma sequencial. Eles não sabem, de antemão, que contas ou posições de armazenamento cada transação vai tocar; correr duas ao mesmo tempo arrisca colisões.
A EIP‑7928 introduz as block‑level access lists, ou BALs — listas de acesso ao nível de bloco — que registam todas as contas e slots de armazenamento que um bloco utiliza, juntamente com as alterações de estado feitas por cada transação. As listas são produzidas pelos construtores, e o cabeçalho do bloco… munido de um hash desse mapa.
Com esse mapa em mãos, os clientes conseguem paralelizar várias tarefas:
- Ler de uma só vez, a partir do disco, todo o estado necessário, em vez de o descobrir passo a passo.
- Validar, em núcleos de CPU distintos, transações que não se sobrepõem.
- Calcular a raiz de estado pós‑bloco de forma muito mais eficiente.
- Atualizar o estado a partir dos resultados registados, sem precisar de reexecutar cada transação, acelerando a sincronização.
Uma alteração de rede complementar, a EIP‑8159, permite que os nós troquem essas listas entre si. Outra, a EIP‑8189, usa dados BAL para reparar o estado durante o snap sync.
No Soldøgn, as equipas de clientes fizeram benchmarks de cada otimização BAL atrás do seu próprio feature flag. A ideia foi acelerar primeiro os gargalos de cada implementação, porque elevar o “elo mais fraco” aumenta o limite de gas seguro para todos.
BALs e ePBS funcionam em par. O ePBS alarga a janela de execução em cada slot, e os BALs permitem que os clientes aproveitem esse tempo de forma muito mais eficiente.
Also Read: Bezos Diz Que IA Pode Levar a Semana de 3 Dias de Trabalho Após a Amazon Cortar 30.000 Empregos
Como o Glamsterdam Vai Mudar a Contabilização de Gas e o Custo de Execução no Ethereum?
O preço do gas para operações de estado foi revisto pela última vez no upgrade Berlin, em 2021. Desde então, o estado do Ethereum cresceu de forma expressiva, e os aumentos recentes do limite de gas aceleraram esse crescimento.
Num artigo dirigido a developers de smart contracts, a fundação explicou, em 24 de agosto, que a nova tabela de preços permite “aproximadamente um aumento de 3x na capacidade base de throughput”. Reprecificar estas operações, diz o texto, é pré‑requisito para voltar a subir o gas limit.
Duas EIPs concentram a maior parte do trabalho. A EIP‑8037 aumenta e passa a medir em separado o custo de criação de estado, enquanto a EIP‑8038 encarece as operações de leitura e escrita de estado, como SLOAD, SSTORE e acesso a contas “frias”.
A EIP‑8037 estabelece um preço fixo de 1.530 unidades de gas por novo byte de estado, derivado de uma meta de crescimento de estado de 120 GiB por ano, assumindo um gas limit de referência de 150 milhões.
A essa taxa, um novo storage slot passa a custar 97.920 unidades de “state gas”, face às 20.000 atuais, e uma nova conta custa 183.600, em vez de 25.000. O deploy de um contrato de tamanho máximo (24 KiB) fica cerca de oito vezes mais caro.
O “state gas” também ganha o seu próprio medidor. O teto por transação introduzido no Fusaka passa a aplicar‑se apenas ao gas de execução, e cada bloco passa a ser limitado pela dimensão — execução ou estado — que estiver mais próxima do respetivo máximo.
O resto do pacote de gas é mais cirúrgico, mas cumulativo:
- A EIP‑7778 impede que os gas refunds contem para o limite de gas do bloco, embora os utilizadores continuem a receber reembolsos sobre o que pagam.
- A EIP‑7976 sobe o piso de calldata para 64 unidades de gas por byte em transações muito intensivas em dados.
- A EIP‑7981 cobra os dados de access lists à mesma razão, 64 unidades de gas por byte.
- A EIP‑2780 reconstrói o gas intrínseco da transação em torno do uso real de recursos, com um custo base de 12.000 unidades de gas.
- A EIP‑7954 aumenta o tamanho máximo de contrato de 24 KiB para 64 KiB.
A versão atual da EIP‑2780 mantém uma transferência simples de Ether para uma conta já existente em 21.000 unidades de gas, enquanto uma transferência que cria uma nova conta acrescenta 183.600 unidades de state gas. A página da ethereum.org sobre o Glamsterdam, atualizada pela última vez em 6 de agosto, ainda descreve transferências até 71% mais baratas.
Os números ainda podem mexer. Várias destas propostas, incluindo a EIP‑2780 e a EIP‑8037, permanecem em Last Call até 1 de novembro, e a ethereum.org sublinha que o âmbito pode mudar antes da mainnet.
Also Read: Zcash Tem Meta Quântica Para Janeiro Abrangendo 70% do ZEC, Falta‑Lhe é a Data
O Upgrade Pode Aumentar o Throughput da Layer 1 e Reduzir Taxas de Transação?
O ganho esperado está no throughput. No Soldøgn, developers alinhados apontaram para um “piso credível de 200M para o gas limit pós‑Glamsterdam”, cerca de 3,3 vezes o default atual de 60 milhões.
A projeção assenta em três pilares. O ePBS dá mais tempo à execução, as otimizações com BAL libertam margem nos clientes e a EIP‑8037 evita que um gas limit maior se traduza em crescimento descontrolado de estado.
A rede de testes Sepolia já opera com um limite de 200 milhões, agendado para o epoch do fork via EIP‑8261, que transforma o gas limit num parâmetro definido por fork.
O código dos clientes para o Hoodi agenda o mesmo patamar de 200 milhões. Resumos das calls indicam que a mainnet seguirá o mesmo modelo de fork‑epoch, mas ainda não há valor nem data oficiais anunciados para a rede principal.
As taxas vão cair? A ethereum.org escreve que o Glamsterdam “muito provavelmente reduzirá as taxas para utilizadores no dia a dia”. Mais espaço em bloco, com a mesma procura, deve pressionar os preços em baixa, mas o efeito final depende de quanta nova atividade ocupar esse espaço.
Operações pesadas em estado, como criação de novas contas ou novos storage slots, passam a consumir mais gas, pelo que o upgrade redistribui custos tanto quanto os reduz.
O Que Têm de Preparar Carteiras, Smart Contracts, Infraestrutura e Validadores?
Para quem apenas detém ETH, a resposta é: nada. A fundação afirma que utilizadores da mainnet não precisam de tomar qualquer ação, e a ethereum.org alerta que qualquer pedido para “atualizar” o seu ETH é golpe.
Para o resto do ecossistema, há trabalho de casa — e a nova estrutura de preços de gas é o principal ponto. A reexecução de transações históricas da mainnet revelou um pequeno conjunto de contratos que podem falhar ou degradar, em geral por dependerem de pressupostos rígidos sobre gas.
Segundo a fundação, um simples aumento do gas limit resolve a maioria dos casos sinalizados, e a grande maioria dos smart contracts não será afetada.
A checklist, compilada a partir da orientação da fundação e das equipas de clientes, é a seguinte:
- Developers de smart contracts devem verificar endereços na ferramenta de contratos afetados da fundação e testar correções na testnet Platåberget, com atenção ao stipend fixo de 2.300 unidades de gas em Solidity, a valores de gas codificados à mão e a lógica que depende do gas restante.
- Equipas de carteiras, fornecedores de RPC e tooling para nós têm de atualizar a lógica de estimação de gas, já que constantes em cache vão subestimar custos e provocar falhas nas transações.
- Exchanges, bridges e indexadores podem tirar partido dos novos logs da EIP‑7708, que fazem com que todas as transferências e burns de Ether não nulos emitam um evento padrão.
- Operadores de nós devem atualizar tanto o cliente de execução como o de consenso antes de cada ativação, e os validadores têm de atualizar o beacon node e o cliente de validação.
- Operadores de staking e equipas de builders precisam rever as novas funções e interfaces do ePBS, incluindo o payload timeliness committee, antes de cada fork.
Os clientes de execução já prontos para a Sepolia incluíam Geth 1.17.7, Nethermind 2.1.0, Besu 26.9.0, Erigon 3.7.1, Reth 2.7.0 e Ethrex 29.0.1. No lado do consenso, a lista incluía Lighthouse 8.3.0‑rc.0, Prysm 7.2.1, Teku 26.9.1, Lodestar 1.49.0, Nimbus 26.10.0 e Grandine 3.0.0‑rc.0.
Os defaults do gas limit mostram como pequenos detalhes são decisivos. A versão 7.2.0 do Prysm e a versão para Sepolia do Teku deixaram validadores nos 60 milhões após o fork, a menos que os operadores definissem manualmente os 200 milhões.
O Prysm integrou uma correção em 2 de outubro para que validadores sem definição explícita passem a seguir o calendário dos 200 milhões na Sepolia, e a fundação já lista o Prysm 7.2.1. No Teku, os validadores que queiram 200 milhões continuam a ter de o definir via flag de configuração.
Also Read: Catástrofe de IA em 12 Meses? OpenAI e Anthropic Estarão a Planear a Resposta
Como o Glamsterdam Afeta a Relação Entre a Layer 1 do Ethereum e as Redes de Layer 2?
O Glamsterdam não abandona os rollups. O roadmap oficial enquadra o upgrade como um avanço simultâneo dos objetivos Scale L1 e Scale Blobs.
A ligação é mecânica. Como o ePBS alarga a janela de propagação, a ethereum.org diz que o Ethereum passa a conseguir transportar com segurança muito mais dados, incluindo mais blobs para rollups, sem sobrecarregar a rede.
O Glamsterdam, em si, não fixa novos números para blobs. Desde o Fusaka, a capacidade de blobs muda através de forks dedicados exclusivamente a parâmetros de blobs, o que permite continuar a expandir a capacidade de dados para rollups num calendário próprio.
Do lado dos developers, não há pressa nessa frente. O January Checkpoint indicou que um terceiro fork desse tipo não é prioridade até a utilização de blobs convergir com os aumentos já aprovados.
Duas funcionalidades menores beneficiam diretamente as Layer 2. A EIP‑7997 coloca um contrato “factory” determinístico no mesmo endereço em todas as EVM chains participantes, permitindo que developers façam deploy de carteiras e aplicações no mesmo endereço em diferentes redes.
A segunda, a EIP‑8070, introduz um sparse blobpool, uma alteração de networking na forma como os nós tratam transações com blobs.
A tensão estratégica é real. Uma Layer 1 mais barata e mais rápida torna o deploy direto na mainnet mais atrativo, colocando‑a em concorrência com os rollups que nela assentam.
A resposta do Ethereum, até agora, é escalar ambas as camadas em paralelo. O roadmap trata capacidade de execução e capacidade de blobs como objetivos complementares, e o desenho do Glamsterdam reflete esse duplo mandato, em vez de uma escolha entre camadas.
Para utilizadores de rollups, o efeito prático é uma camada de settlement mais robusta e com menor necessidade de confiança por baixo da sua atividade.
O Que Vem Depois do Glamsterdam no Roadmap de Escalabilidade do Ethereum?
O próximo fork será o Hegotá. Tal como o Glamsterdam, o nome junta uma cidade da execution layer, Bogotá, com uma estrela da consensus layer, Heze.
Os destaques já estão definidos. O cluster de Protocol da fundação apontou a EIP‑7805, as inclusion lists aplicadas pela regra de fork‑choice (FOCIL), para a camada de consenso, e a EIP‑8141, Frame Transactions, para a camada de execução.
O FOCIL chegou a ser candidato ao Glamsterdam. Os developers decidiram adiá‑lo para limitar o âmbito do fork, segundo a…Checkpoint de janeiro da fundação
O FOCIL permite que múltiplos validadores obriguem construtores (builders) a incluir transações válidas, enfrentando de forma direta o risco de censura gerado pela concentração de builders. As transações de Frame tornam a validação e o pagamento de gas programáveis, oferecendo às contas um caminho nativo para além das atuais chaves secp256k1.
A lista de classificação complementar do cluster avaliou 62 EIPs propostos, a partir de 397 avaliações de nível atribuídas por um grupo de cerca de 60 participantes. Dois foram classificados como “obrigatórios”, 15 como “provavelmente incluídos” e 28 foram descartados.
O calendário é ambicioso. O cluster indicou que as equipas de clientes poderiam, de forma realista, iniciar a implementação de Hegotá no final do quarto trimestre de 2026, e o planeamento parte do pressuposto de que Glamsterdam será ativado em dezembro — um cenário de trabalho, não uma data oficial.
Para além de Hegotá, o cluster estrutura o seu trabalho em torno de cinco grandes linhas de investigação, que atravessam múltiplos hard forks:
- Finalidade rápida, com o objetivo de reduzir o tempo de finalização de minutos para segundos, tendo o “consenso desacoplado” como principal candidato para o fork após Hegotá.
- Segurança pós‑quântica, orientada por uma meta autoimposta de tornar a Layer 1 resistente a computação quântica — em execução, consenso e dados — até dezembro de 2029.
- Privacidade, começando em Hegotá com suporte de protocolo para transações privadas na Layer 1, sem necessidade de confiança e resistentes à censura.
- State, englobando uma nova trie, crescimento sustentável do estado e acesso descentralizado ao estado atual e histórico.
- zkEVM, evoluindo as provas de execução de opcionais para obrigatórias, para que os validadores, no futuro, verifiquem provas em vez de reexecutar todos os blocos.
Leia também: Venda de Bitcoin da MARA continua não comprovada após US$ 81 milhões chegarem a uma carteira da Galaxy Digital
Conclusão: o que Glamsterdam representa para o Ethereum
Glamsterdam é menos uma funcionalidade isolada e mais uma reorganização da camada base do Ethereum. Leva o mercado de builders para dentro do protocolo, dá às equipas de clientes um mapa para trabalho em paralelo e passa a cobrar de forma mais transparente pelo uso de estado permanente.
O lançamento em Sepolia decorreu sem sobressaltos, mas os testes mais difíceis ainda estão pela frente. Potuz chamou a atenção para o facto de Hoodi concentrar pools de staking e validadores domésticos, o que torna este fork muito mais exigente do que Sepolia.
Uma proposta de calendarização dos core developers marca o fork Hoodi para o epoch 132.352, ou 17:42:48 UTC de 26 de outubro. Ainda não há data para a mainnet, e a fundação afirmou que fará um anúncio separado quando houver decisão.
As questões em aberto são tanto económicas quanto técnicas. Se haverá builders relevantes, se os validadores vão adotar o novo limite superior de gas e se a procura efetivamente preencherá esse espaço adicional determinará o que Glamsterdam, na prática, vai entregar.
Se a aposta resultar, a camada base do Ethereum escalará segundo a sua própria lógica, com os rollups a construir por cima — em vez de carregar sozinhos todo o peso da rede.
Leia a seguir: Estreia da Evernorth no Nasdaq passa para 12 de outubro: o que muda com o adiamento da fusão
