Yellow.com

Ethereum (ETH) ensaiou sua próxima grande reformulação em 6 de outubro. Quase ninguém fora dos canais de desenvolvedores percebeu. Mas a testnet Sepolia agora roda regras que mudam quem constrói blocos, como o gás é precificado e quanta carga cada bloco consegue suportar.

Este guia destrincha as 18 mudanças centrais de Glamsterdam — lideradas pela separação de propositor e construtor incorporada ao protocolo (ePBS), listas de acesso em nível de bloco e reprojeção de gás — e o que elas significam para taxas, MEV, rollups e o plano de elevar o limite de gás para 200 milhões.

Glamsterdam entrou em operação na testnet Sepolia da Ethereum em 6 de outubro de 2026, e os desenvolvedores marcaram 26 de outubro para a testnet Hoodi. Ainda não há data definida para a rede principal, embora uma proposta preliminar de agenda liste opções no início de dezembro.

A atualização leva a transição entre propositor e construtor para dentro do protocolo, adiciona listas de acesso em nível de bloco para processamento em paralelo e reprojeta a forma como a Ethereum cobra por criação e leitura de estado.

Após Glamsterdam, os desenvolvedores convergiram para um piso de limite de gás de 200 milhões, mais de três vezes o padrão atual de 60 milhões, embora o impacto nas taxas dependa da demanda e da adoção pelos validadores.

O que é a atualização Glamsterdam da Ethereum e por que ela importa?

Glamsterdam é a atualização de rede que sucede Fusaka e, como de costume na Ethereum, seu nome junta duas metades. O lado da camada de execução se chama Amsterdam, em homenagem à cidade anfitriã do Devconnect em 2022, enquanto o lado de consenso é Gloas, nome de uma estrela.

A Fundação Ethereum publicou o anúncio da testnet em 28 de setembro. A ativação em Sepolia foi marcada para o epoch 353.024, slot 11.296.768, às 13h53min36s UTC de 6 de outubro.

O fork entrou no ar exatamente no horário previsto.

A pesquisadora independente de Ethereum Christine D. Kim relatou em 9 de outubro que a atualização em Sepolia “correu bem”. Em seguida, os desenvolvedores agendaram Glamsterdam para a Hoodi, segunda e última testnet pública, na segunda-feira, 26 de outubro, com lançamentos de clientes esperados até 16 de outubro.

O escopo da atualização está consolidado na proposta de rastreamento EIP-7773. Ela organiza 18 mudanças centrais, apoiadas por cinco propostas de rede e duas informacionais.

Na rede principal, o cenário é bem menos definido. A fundação indicou que as datas de Hoodi e mainnet “ainda não foram decididas”, e o ethereum.org segue apontando apenas uma meta genérica de quarto trimestre de 2026.

Um rascunho de agenda no GitHub menciona 1º, 8 e 9 de dezembro como possíveis janelas de ativação na mainnet, mas os desenvolvedores ainda não chegaram a consenso.

Por que isso importa? Por anos, a Ethereum empurrou boa parte do trabalho de escalabilidade para os rollups e manteve a camada base conservadora. Glamsterdam marca uma mudança visível de foco.

A fundação apresenta a atualização como o próximo passo do plano de escalar a camada 1. Os recursos de destaque existem, sobretudo, para permitir que a cadeia base processe com segurança muito mais atividade, ajustando o preço do gás para mais perto do custo real de execução e crescimento de estado.

Em que Glamsterdam difere de Pectra e Fusaka?

As duas últimas grandes atualizações da Ethereum giraram principalmente em torno de staking e dados. Glamsterdam foca a execução — a parte do sistema que de fato roda as transações.

Pectra entrou em operação em 7 de maio de 2025, no epoch 364.032. Ela permitiu que carteiras comuns delegassem poder a contratos inteligentes via EIP-7702, elevou o saldo máximo de validadores 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 21h49min11s UTC. Seu destaque foi o PeerDAS, o EIP-7594, que permite a nós verificarem dados de blobs amostrando pequenos pedaços, em vez de baixar tudo.

Fusaka também introduziu forks “apenas de parâmetros de blob”, pequenos ajustes de configuração que mudam a capacidade de blobs sem agrupar outros recursos. Dois desses ajustes vieram na sequência, em 9 de dezembro de 2025 e 7 de janeiro de 2026.

A atualização “January Checkpoint” da fundação ressaltou que a Ethereum passou a mirar 14 blobs por bloco, com máximo de 21. Segundo o texto, isso representou um aumento de 2,3 vezes no espaço de dados para camadas 2 em comparação ao período pré-Fusaka.

Do lado da execução, Fusaka limitou transações individuais a cerca de 16,8 milhões de gás e fixou em 60 milhões o limite padrão de gás por bloco nos clientes.

Glamsterdam muda a ordem das prioridades. Em vez de apenas adicionar espaço para dados de rollups, a atualização reconstrói como blocos são produzidos, validados e precificados, abrindo caminho para elevar muito além dos atuais 60 milhões de gás.

Pectra e Fusaka alargaram as “tubulações” para L2s; Glamsterdam mexe no motor da camada 1.

O que é a separação propositor-construtor incorporada (ePBS)?

Hoje, a maioria dos blocos da Ethereum não é montada pelo próprio validador que os propõe. Construtores especializados competem para montar o bloco mais lucrativo, e um validador rodando o MEV-Boost, da Flashbots, escolhe o maior lance.

Essa transição depende de relays, intermediários de confiança. O relay segura o bloco do construtor, mostra ao propositor apenas o cabeçalho e o valor do lance e libera o conteúdo completo depois que o propositor assina.

O arranjo funciona, mas está totalmente fora do protocolo. Se um relay falha, se comporta de forma maliciosa ou censura blocos, as regras de consenso da Ethereum não oferecem proteção.

O EIP-7732 leva essa troca para dentro do próprio protocolo da Ethereum. Ele trata construtores como participantes nativos do protocolo e dá aos validadores uma nova responsabilidade, chamada de “atestações de pontualidade de payload”.

No novo fluxo, o propositor inclui, no bloco da beacon chain, o compromisso assinado de um construtor com um payload de execução, e o construtor revela esse payload em seguida. O protocolo cuida do pagamento ao propositor, reduzindo a dependência de middleware de confiança.

Um subconjunto de validadores forma o comitê de pontualidade de payload. 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 entra a escalabilidade.

A página de roteiro no ethereum.org afirma que essa separação aumenta a janela para disseminar dados pela rede de 2 para cerca de 9 segundos. Mais tempo significa que os validadores conseguem lidar, com segurança, com payloads muito maiores.

Os relays não vão desaparecer da noite para o dia. A mesma página observa que construtores e propositores podem continuar usando relays fora do protocolo ou outros middlewares para recursos avançados que o núcleo ainda não suporta.

Como Glamsterdam pode mudar o MEV e a economia dos validadores da Ethereum?

O valor máximo extraível, ou MEV, é o lucro disponível ao ordenar, incluir ou excluir transações. Via MEV-Boost, boa parte desse valor flui para validadores na forma de lances de construtores, mas o mercado por trás desses lances é altamente concentrado.

O painel Relayscan, da Flashbots, mostrava Titan construindo 52,6% dos blocos MEV-Boost nas 24 horas até o início de 12 de outubro. Quasar respondia por 18,5% e BuilderNet por 13,3%, deixando três construtores com cerca de 84% do fluxo.

A ePBS não elimina o MEV, nem dissolve automaticamente a concentração entre construtores. O que muda é o modelo de confiança: o pagamento ao propositor deixa de depender de um relay cumprir, de boa-fé, o que prometeu.

Para stakers, o ganho aparece na margem. Um validador solo passa a ter, no protocolo, um mecanismo garantido para vender espaço em bloco, enquanto construtores precisam também colocar sua própria garantia em stake para participar.

Stakers também ganham saídas mais rápidas. Com o EIP-8061, a capacidade de saída passa a escalar com o total de Ether em staking, o que, segundo o ethereum.org, quadruplica aproximadamente essa capacidade nos níveis atuais e dobra o espaço para consolidação de validadores.

A contrapartida é uma janela de segurança mais curta para nós que ficam offline. O ethereum.org aponta que o período de subjetividade fraca — após o qual um nó que retorna precisa de um checkpoint recente de confiança — cai de cerca de 15,7 dias para algo em torno de 7 dias.

Em Soldøgn, encontro de interoperabilidade em Svalbard que reuniu pouco mais de 100 contribuintes centrais, desenvolvedores destacaram duas questões ainda sensíveis em torno da ePBS. Uma delas é como proteger um desenho que exige apenas 1 ETH de stake dos construtores contra ataques Sybil na rede peer-to-peer.

A preocupação voltou às discussões antes de Sepolia. Em uma call de consenso em 17 de setembro, o desenvolvedor 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 ligar mil construtores.”

Os primeiros dados de Sepolia indicam um mercado raso. Um resumo comunitário da call de 8 de outubro, focada na camada de execução, citou a EthPandaOps ao afirmar que apenas quatro ou cinco construtores tinham estado ativos na rede, sem presença dos principais players e com muitos blocos ainda sendo construídos localmente.

A ePBS só mostra todo o seu valor quando construtores reais competem por blocos — o que faz de Hoodi o teste mais revelador.

O que são listas de acesso em nível de bloco e como elas melhoram o processamento de transações?

Hoje, clientes da Ethereum em geral processam as transações de um bloco em sequência. Eles não conseguem saber, de antemão, quais contas ou slots de armazenamento cada transação vai tocar; rodar duas em paralelo abre risco de colisão.

O EIP-7928 introduz as listas de acesso em nível de bloco, ou BALs (block-level access lists). Elas registram todas as contas e slots de armazenamento que um bloco acessa, junto com as mudanças de estado que cada transação provoca. Os construtores produzem essa lista, e o cabeçalho do bloco … Com esse mapa em mãos, os clientes conseguem paralelizar vários trabalhos ao mesmo tempo:

Ler de uma só vez, em disco, todo o estado de que precisam, em vez de descobri-lo passo a passo.
Validar em núcleos de CPU distintos as transações que não têm interseção entre si.
Calcular a state root pós-bloco de forma bem mais eficiente.
Atualizar o estado a partir dos resultados gravados, sem precisar reexecutar cada transação — o que acelera o sincronismo.

Uma mudança de rede complementar, a EIP-8159, permite que os nós troquem essas listas entre si. Outra, a EIP-8189, usa dados de BAL para “cicatrizar” o estado durante o snap sync.

No Soldøgn, as equipes de clientes testaram cada otimização de BAL com sua própria feature flag. A ideia foi acelerar primeiro os trechos mais lentos de cada cliente: ao elevar o desempenho da implementação mais fraca, sobe o limite de gás seguro para toda a rede.

BALs e ePBS funcionam em par. O ePBS amplia a janela de execução em cada slot; os BALs permitem que os clientes usem esse tempo extra com muito mais eficiência.

Como Glamsterdam Vai Mudar a Contabilização de Gás e o Custo de Execução no Ethereum?

Os preços de gás para operações de estado foram reformulados pela última vez no hard fork Berlin, em 2021. Desde então, o estado do Ethereum cresceu de forma expressiva, e os aumentos recentes no gas limit aceleraram ainda mais esse crescimento.

Um post da Fundação voltado a desenvolvedores de smart contracts explicou, em 24 de agosto, que a nova tabela de preços permite “algo como um aumento de 3x na vazão básica”. Segundo o texto, reproporcionar essas operações é pré-requisito para qualquer novo salto no gas limit.

Duas EIPs concentram a maior parte do trabalho. A EIP-8037 aumenta — e passa a medir separadamente — o custo de criar novo estado. Já a EIP-8038 encarece as leituras e gravações desse estado, em operações como SLOAD, SSTORE e acessos “cold” a contas.

A EIP-8037 define um preço fixo de 1.530 unidades de gás por novo byte de estado, calculado a partir de uma meta de crescimento anual de 120 GiB de estado, considerando um gas limit de referência de 150 milhões.

Nessa nova taxa, um novo slot de storage passa a custar 97.920 unidades de “state gas”, ante as 20.000 atuais, e uma nova conta sobe para 183.600, contra 25.000 hoje. Implantar um contrato no tamanho máximo de 24 KiB fica algo como oito vezes mais caro.

O gás de estado também ganha um medidor próprio. O teto por transação introduzido em Fusaka passa a valer apenas para o “execution gas”; já o bloco é considerado cheio quando qualquer uma das duas dimensões — execução ou estado — se aproxima mais do seu limite.

O resto do pacote de gás é mais pontual, mas cumulativo:

A EIP-7778 deixa de abater reembolsos de gás do gas limit do bloco, embora o usuário continue recebendo o reembolso sobre o que pagou.
A EIP-7976 eleva o piso de calldata para 64 unidades de gás por byte em transações intensivas em dados.
A EIP-7981 cobra dados de access list na mesma taxa de 64 gás por byte.
A EIP-2780 reconstrói o gás intrínseco da transação em torno do uso real de recursos, com custo base de 12.000 unidades.
A EIP-7954 eleva o tamanho máximo de contrato de 24 KiB para 64 KiB.

O rascunho atual da EIP-2780 mantém a transferência simples de Ether para uma conta já existente em 21.000 gás, enquanto uma transferência que cria nova conta acrescenta 183.600 unidades de state gas. A página de Glamsterdam no Ethereum.org, atualizada pela última vez em 6 de agosto, ainda fala em transferências ficando até 71% mais baratas.

Os números ainda podem mudar. Várias dessas propostas, incluindo EIP-2780 e EIP-8037, permanecem em Last Call até 1º de novembro, e o ethereum.org observa que o escopo ainda pode ser ajustado antes da ativação na mainnet.

O Upgrade Pode Aumentar a Vazão da Camada 1 e Reduzir Taxas de Transação?

A contrapartida esperada é justamente a vazão. No Soldøgn, desenvolvedores convergiram em um “piso crível de gas limit pós-Glamsterdam de 200 milhões”, algo como 3,3 vezes os 60 milhões que hoje são o padrão.

Essa cifra se apoia em três pilares. O ePBS amplia o tempo disponível para execução; as otimizações de BAL abrem folga de desempenho nos clientes; e a EIP-8037 impede que um gas limit maior se traduza em um crescimento descontrolado do estado.

A rede de testes Sepolia já roda com limite de 200 milhões, programado na epoch do fork pela EIP-8261, que torna o gas limit um parâmetro definido em forks.

O código dos clientes para Hoodi agenda o mesmo patamar de 200 milhões. Resumos de chamadas de desenvolvedores indicam que a mainnet deve seguir a mesma lógica de fork epoch, mas ainda não há número ou data formalmente definidos para a rede principal.

As taxas vão cair? O Ethereum.org afirma que Glamsterdam “muito provavelmente reduzirá as taxas para o usuário comum”. Mais espaço em bloco, com a mesma demanda, tende a pressionar o preço do gás para baixo — mas o resultado final depende de quanto novo uso efetivamente preencher esse espaço.

Ações intensivas em estado, como criar novas contas ou novos slots de storage, ficarão mais caras em termos de gás. Na prática, o upgrade redistribui custos tanto quanto os reduz.

O Que Carteiras, Smart Contracts, Provedores de Infraestrutura e Validadores Precisam Fazer?

Para o investidor de varejo, a resposta é: nada. A Fundação afirma que usuários da mainnet não precisam tomar qualquer ação, e o ethereum.org alerta que quem disser que é preciso “atualizar” o seu ETH está aplicando golpe.

Para o restante do ecossistema, o dever de casa é amplo, e a nova precificação de gás é o maior item da lista. Reexecutar transações históricas da mainnet revelou um conjunto pequeno de contratos que podem quebrar ou se degradar, em geral por dependerem de premissas fixas sobre consumo de gás.

Segundo a Fundação, aumentar o gas limit local desses contratos resolve a maior parte dos problemas detectados, e a imensa maioria dos smart contracts não é afetada.

O checklist, compilado a partir das orientações da Fundação e de equipes de clientes, inclui:

Desenvolvedores de smart contracts devem conferir 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 gás do Solidity, valores de gás hardcoded e lógicas que mudam de rumo com base no gás restante.
Carteiras, provedores de RPC e ferramentas de nó precisam atualizar a estimativa de gás: constantes de gás em cache passarão a subestimar custos e levar a falhas de transação.
Exchanges, bridges e indexadores podem usar os novos logs da EIP-7708, que fazem toda transferência ou queima não zero de Ether emitir um evento padronizado.
Operadores de nós precisam atualizar tanto o cliente de execução quanto o de consenso antes de cada ativação; validadores devem atualizar o beacon node e o cliente validador.
Operadores de staking e equipes de builders devem revisar as novas funções e interfaces do ePBS, incluindo o “payload timeliness committee”, antes de cada fork.

Na Sepolia, os clientes de execução prontos 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. Do lado de consenso, a lista trazia 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 padrões de gas limit mostram como detalhes aparentemente pequenos importam. A versão 7.2.0 do Prysm e a versão de Sepolia do Teku deixavam validadores em 60 milhões após o fork, a menos que os operadores ajustassem manualmente para 200 milhões.

O Prysm incorporou uma correção em 2 de outubro, passando a seguir automaticamente o cronograma de 200 milhões de Sepolia quando não houver configuração explícita do operador; a Fundação agora recomenda o Prysm 7.2.1. Já validadores Teku que quiserem 200 milhões ainda precisam definir o valor via flag de configuração.

Como Glamsterdam Afeta a Relação Entre a Camada 1 do Ethereum e as Redes de Camada 2?

Glamsterdam não abandona os rollups. O roadmap oficial apresenta o upgrade como avanço simultâneo dos objetivos “Scale L1” e “Scale Blobs”.

A conexão é direta. Como o ePBS amplia a janela de propagação de blocos, o ethereum.org afirma que o Ethereum pode carregar com segurança muito mais dados — inclusive mais blobs para rollups — sem pressionar demais a rede.

O Glamsterdam em si não redefine a capacidade de blobs. Desde Fusaka, qualquer mudança nesses parâmetros passa por forks exclusivos de blobs, de modo que a capacidade de dados para rollups pode crescer em cronograma próprio.

Desenvolvedores não demonstram pressa nesse ponto. O “January Checkpoint” indicou que um terceiro fork focado em blobs não é prioridade até que o uso efetivo alcance os aumentos já aprovados.

Duas novidades menores ajudam diretamente as L2s. A EIP-7997 instala um contrato-fábrica determinístico no mesmo endereço em todas as EVM chains participantes, permitindo que carteiras e aplicativos sejam implantados em endereços idênticos em múltiplas redes.

A segunda, EIP-8070, cria um “sparse blobpool”, uma mudança de rede na forma como nós lidam com transações de blob.

A tensão estratégica é real. Uma Camada 1 mais barata e rápida torna a implantação direta na mainnet mais atraente, o que a coloca em competição com os rollups que nela se liquidam.

A resposta do Ethereum, até aqui, é escalar as duas camadas simultaneamente. O roadmap trata capacidade de execução e capacidade de blobs como metas paralelas, e o desenho do Glamsterdam reflete esse duplo mandato, não uma escolha entre L1 e L2.

Para usuários de rollups, o efeito prático é uma camada de liquidação mais robusta e com menos necessidade de confiança por baixo deles.

O Que Vem Depois de Glamsterdam no Roadmap de Escalabilidade do Ethereum?

O próximo fork atende por Hegotá. Assim como Glamsterdam, o nome combina uma cidade ligada à camada de execução, Bogotá, com uma estrela associada à camada de consenso, Heze.

Os destaques já estão definidos. O cluster de Protocolo da Fundação apontou a EIP-7805, que cria listas de inclusão forçadas via fork choice (FOCIL), para a camada de consenso, e a EIP-8141, de Frame Transactions, para a camada de execução.

O FOCIL quase entrou em Glamsterdam. Desenvolvedores acabaram adiando a inclusão para não ampliar demais o escopo do fork, de acordo com a…Checkpoint de janeiro da Fundação

FOCIL permite que vários validadores obriguem construtores (builders) a incluir transações válidas, atacando diretamente o risco de censura gerado pela concentração de builders. Já as transações Frame tornam a validação e o pagamento de gás programáveis, oferecendo às contas um caminho nativo para além das atuais chaves secp256k1.

A lista de camadas (tier list) preparada pelo cluster classificou 62 EIPs propostos, com base em 397 avaliações de prioridade de um grupo de cerca de 60 pessoas. Duas propostas foram marcadas como “obrigatórias”, 15 “provavelmente incluídas” e 28 rejeitadas.

O cronograma é ambicioso. O cluster avalia que as equipes de clientes poderiam, de forma realista, começar a implementar Hegotá no fim do quarto trimestre de 2026, partindo da premissa de que Glamsterdam entra em produção em dezembro — um pressuposto de planejamento, não uma data oficial.

Além de Hegotá, o cluster organiza sua agenda em torno de cinco linhas de pesquisa que se estendem por múltiplos forks:

Finalidade rápida, com a meta 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, ancorada na meta autoimposta de tornar a Layer 1 resistente a computadores quânticos — em execução, consenso e dados — até dezembro de 2029.
Privacidade, começando em Hegotá com suporte de protocolo para transações privadas, sem confiança em terceiros e resistentes à censura na Layer 1.
Estado, cobrindo um novo trie, crescimento sustentável do estado e acesso descentralizado ao estado atual e histórico.
zkEVM, migrando gradualmente de provas de execução opcionais para obrigatórias, até que validadores passem a verificar provas em vez de reexecutar todos os blocos.

Conclusão: O que Glamsterdam representa para o Ethereum

Glamsterdam não é um único recurso, mas uma reconfiguração da camada base do Ethereum. Ele internaliza o mercado de builders no próprio protocolo, oferece aos clientes um roteiro para paralelizar trabalho e torna a cobrança por estado permanente mais transparente.

O lançamento em Sepolia transcorreu sem sobressaltos, mas os testes realmente complexos ainda estão por vir. Potuz destacou que Hoodi abriga pools de staking e validadores domésticos, o que faz dessa uma bifurcação muito mais desafiadora que Sepolia.

Uma proposta de cronograma dos desenvolvedores centrais fixa o fork de Hoodi no epoch 132.352, às 17:42:48 UTC de 26 de outubro. Ainda não há data definida para a rede principal; a fundação informou que fará um anúncio separado quando houver decisão.

As dúvidas em aberto são tanto econômicas quanto técnicas. Se builders relevantes vão, de fato, participar; se os validadores vão aderir ao limite de gás mais alto; e se a demanda vai ocupar o novo espaço disponível — tudo isso determinará o que Glamsterdam realmente entrega.

Se a atualização funcionar como planejado, a camada base do Ethereum passará a escalar em seus próprios termos, com rollups construindo por cima dela, e não carregando sozinhos todo o peso da rede.

Próximo artigo: Estreia da Evernorth na Nasdaq vai para 12 de outubro: o que muda com o adiamento da fusão

O que é Glamsterdam? Por dentro da aposta de 18 mudanças da Ethereum em sua camada base