Por que Glamsterdam pode ser uma das atualizações mais importantes do Ethereum após o Merge?
撰文：KarenZ，Foresight News
A atualização Glamsterdam do Ethereum pode facilmente ser mal interpretada como mais uma iteração técnica puramente focada em aumentar a taxa de transferência. A maneira mais precisa de colocar isso é: ela está reestruturando o processo de criação de blocos do Ethereum, os processos de validação e a forma de precificação de recursos, preparando o terreno para um limite de Gas mais alto, maior capacidade de blob e execução paralela futura.
Até 23 de junho de 2026, ethereum.org marcará Glamsterdam como uma atualização planejada para o segundo semestre de 2026. O nome Glamsterdam é uma combinação da atualização da camada de execução Amsterdam e da atualização da camada de consenso Gloas. O roadmap oficial a posiciona após o Fusaka em dezembro de 2025 e antes do Hegotá, listando claramente duas funcionalidades principais: separação entre proponentes e construtores dentro do protocolo, ou seja, ePBS, e a lista de acesso em nível de bloco, ou seja, BAL.
Quem propõe, quem constrói: ePBS escreve no protocolo a divisão do trabalho de proposição de blocos
Hoje, a proposição de blocos na Ethereum parece um turno de entrega com tempo muito apertado: alguém é responsável por propor o bloco, alguém é responsável por construir o conteúdo das transações; no meio disso, ainda depende de infraestrutura fora do protocolo como MEV-Boost e relays de terceiros.
Esse sistema já funciona há muitos anos, mas ele coloca parte das relações de confiança fora do protocolo; além disso, faz com que validadores processem tarefas como consenso, execução e disponibilidade de dados em uma janela de tempo bem curta.
Uma das maiores mudanças do Glamsterdam é o EIP-7732, isto é, ePBS (Enshrined Proposer-Builder Separation): ele escreve no protocolo a separação de tarefas entre proponente e construtor.
Em poucas palavras: o proponente é responsável por selecionar o bloco de consenso; o construtor prepara o conteúdo das transações dentro dele. O construtor não pode apenas prometer de forma verbal: ele precisa primeiro "entregar uma carta de garantia" dentro do protocolo, especificando claramente qual bloco de execução ele entregará e quanto pagará ao proponente; em seguida, o Payload Timeliness Committee (PTC, Comitê de Pontualidade de Carga Útil) verificará se ele entregou no prazo.
O ponto-chave dessa mudança não é apenas reduzir a dependência de relays de terceiros; também está em conseguir tempo para a propagação e a validação de blocos.
Hoje, os validadores precisam processar consenso e execução simultaneamente dentro de uma janela crítica bem curta. O ePBS separa essas duas coisas, permitindo que a carga de execução possa ser revelada e verificada mais tarde. Pelo desenho do EIP-7732, a janela de disseminação da carga de execução — isto é, o tempo disponível para os dados se propagarem na rede e serem recebidos pelos nós — pode ser estendida de cerca de 2 segundos para cerca de 9 segundos. Com uma janela maior, ao aumentar a capacidade de blocos, a Ethereum fica menos propensa a aumentar perdas de votos ou riscos de reorganização por falta de tempo para nós baixarem, validarem e votarem.
Para usuários comuns, a percepção direta disso pode ser pequena, mas é crucial para a expansão da Ethereum. Uma janela maior de propagação e validação significa que a rede pode lidar com cargas maiores com mais segurança. Em uma reportagem de 16 de junho de 2026, a CoinDesk citou declarações do engenheiro de DevOps da Fundação Ethereum, Parithosh Jayanthi: o Glamsterdam pode ser uma das maiores bifurcações desde o Merge, mudando muitas suposições sobre a Ethereum e preparando o terreno para expansões ainda maiores no futuro.
BAL e reprecificação: expansão não pode ser só acelerar; também é preciso controlar o banco de dados
Uma outra mudança central do Glamsterdam é o EIP-7928: Block-Level Access Lists (listas de acesso no nível do bloco).
Dá para entender isso como anexar a cada bloco uma espécie de "registro de acessos": durante a execução do bloco, quais contas e quais posições de armazenamento foram tocadas; depois da execução, em que estado relevante ficou. Tudo isso deve ser registrado. Assim, ao processar blocos, os nós não precisam mais agir como se estivessem "desvendando no escuro"; eles podem saber mais cedo quais dados precisam ser lidos e quais computações podem avançar em paralelo. Isso
O EIP-2930 anterior já introduziu listas de acesso no nível de transação, mas era opcional e de uso limitado. A mudança do EIP-7928 é que ele eleva as listas de acesso para o nível de bloco: o cabeçalho do bloco mantém um "fingerprint" (registro de hash) dessa lista; a carga de execução armazena a lista completa. Quando o nó executa o bloco, ele confere se os registros de acesso escritos na lista realmente correspondem ao processo de execução do bloco. Se não corresponder, o bloco é inválido.
Por que isso é importante? Hoje, ao executar transações na Ethereum, muitos acessos a dados só ficam conhecidos quando a execução realmente chega naquele ponto. Os nós não sabem se um conjunto de transações vai ler e escrever ao mesmo tempo a mesma conta ou o mesmo slot de armazenamento, então fica difícil confiar no processamento paralelo. A BAL equivale a escrever explicitamente o rastro de acessos dentro da execução do bloco, permitindo que clientes façam leitura de disco em paralelo, verificação de transações em paralelo e cálculo de roots de estado em paralelo; e, em alguns cenários, até atualizar o estado sem precisar replayar transações de forma completa e integral. Não é um botão para reduzir diretamente as taxas do usuário; é uma abertura para que engenheiros de clientes criem espaço de paralelização.
Mas a lógica de expansão do Glamsterdam não se resume a "alargar a estrada". Ela também precisa conter a expansão de longo prazo do banco de dados da Ethereum. O EIP-8037 aumenta o custo de criação de estado e introduz o custo por byte de cada estado CPSB. O estado pode ser entendido como o conteúdo do banco de dados que a Ethereum precisa manter por muito tempo: por exemplo, novas contas, novos contratos e novas posições de armazenamento. A execução de transações termina, mas o estado permanece no livro-razão que todos os nós precisam manter. Se o estado crescer rápido demais, rodar nós ficará cada vez mais caro, e a descentralização será gradualmente pressionada.
Os números de contexto apresentados pelo EIP-8037 são bem intuitivos: em janeiro de 2026, um banco de dados de nó Geth dedicado apenas a estados tem cerca de 390 GiB. Depois que o limite de gas da mainnet aumentou de 30 milhões para 60 milhões, o estado novo adicionado diariamente subiu de cerca de 105 MiB para 326 MiB — o que equivale a um crescimento anual de aproximadamente 116 GiB. Se extrapolar proporcionalmente sob um limite de 200 milhões de gas, o crescimento anual de estado poderia chegar a cerca de 387 GiB e ultrapassar, em menos de um ano, o patamar de degradação de desempenho de 650 GiB.
Portanto, o que o EIP-8037 pretende fazer é separar o preço entre "computação temporária" e "ocupação permanente do banco de dados". Criar um novo estado fica mais caro porque isso não traz para a rede apenas o custo de computação de uma vez; traz também a carga de armazenamento de longo prazo.
Vitalik Buterin também mencionou, ao explicar a rota de expansão do Glamsterdam, que o Glamsterdam separará o custo de criação de estado entre custos de execução e de calldata: a meta é permitir que a capacidade de execução aumente ainda mais, sem que o tamanho do estado cresça na mesma velocidade.
Visto em conjunto, a BAL torna mais fácil para nós processarem blocos em paralelo — e isso resolve o problema de "rodar mais rápido". Já a reprecificação da criação de estado faz com que operações que ocupam o banco de dados por muito tempo custem mais caro — resolvendo o problema de "não deixar o livro-razão inchar cada vez mais". A expansão do Glamsterdam não é apenas elevar o Gas limit; é uma pergunta mais realista: a Ethereum consegue acomodar mais transações sem que a disseminação de blocos, a verificação de transações e a pressão de armazenamento de estado saiam do controle.
Lista de EIPs do Glamsterdam toma forma: o que já está definido e o que ainda está esperando?
Até 23 de junho de 2026, de acordo com o conteúdo de acompanhamento no Forkcast sobre atualizações da Ethereum, os desenvolvedores da Ethereum estão testando a atualização do Glamsterdam em ambientes devnets; em 3 de agosto haverá lançamento na Sepolia; em 16 de setembro, na mainnet (as datas exatas podem mudar).
Atualmente, há 10 EIPs previstos para entrar na lista do Glamsterdam:
EIP-7708 (transferências de ETH também geram logs, facilitando indexação e rastreamento de transferências nativas de ETH)
EIP-7732 (ePBS: escreve no protocolo a separação entre proponente e construtor, reduzindo a dependência de relays fora do protocolo)
EIP-7778 (cancelar a contabilização de gas dos blocos relacionada a Gas refund, tornando o cálculo de gas do bloco mais simples)
EIP-7843 (adicionar o opcode SLOTNUM para permitir que contratos leiam o número do slot atual)
EIP-7928 (lista de acessos por bloco BAL: registra as contas e posições de armazenamento acessadas durante a execução do bloco, abrindo caminho para verificação paralela)
EIP-7954 (aumentar o limite máximo de tamanho de contrato, permitindo códigos maiores em bytescode)
EIP-7976 (aumentar o custo mínimo do calldata e ajustar o custo mínimo do calldata)
EIP-7981 (aumentar o custo de listas de acesso e recalibrar a precificação de gas das access lists)
EIP-8024 (opcodes SWAPN, DUPN e EXCHANGE compatíveis com versões anteriores, reforçando as capacidades de operações de pilha da EVM)
EIP-8037 (aumentar o custo de criação de estado e conter a expansão rápida demais do banco de dados de estado)
Esses EIPs podem ser divididos aproximadamente em três categorias: a primeira envolve reestruturação do fluxo de proposição e validação, com foco no EIP-7732 e EIP-7928; a segunda inclui ajustes de precificação de recursos, incluindo EIP-7778, EIP-7976, EIP-7981 e EIP-8037; a terceira traz mudanças na EVM e na experiência do desenvolvedor, incluindo EIP-7708, EIP-7843, EIP-7954 e EIP-8024.
Em outras palavras, o Glamsterdam não altera apenas um ponto de funcionalidade: ele atualiza simultaneamente a divisão de trabalho do bloco, a verificação em paralelo, a precificação de gas e a disponibilidade da EVM.
Outra leva de EIPs ainda está na lista de "em consideração":
EIP-2780 (gas intrínseco de transações dividido por recursos)
EIP-7610 (reversão ao criar contratos em contas de armazenamento não vazio)
EIP-7688 (estrutura de dados da camada de consenso voltada a compatibilidade futura)
EIP-7904 (análise de custos de gas; pode ser removido do Glamsterdam)
EIP-7975 (eth/70, parte da lista de recibos de bloco)
EIP-7997 (fábrica de contratos determinística)
EIP-8038 (atualização de custos de gas de acesso ao estado)
EIP-8045 (excluir validadores que foram penalizados e continuam propondo blocos)
EIP-8061 (aumentar o churn de saída e de fusão)
EIP-8070 (eth/72, Sparse Blobpool)
EIP-8080 (fazer a saída usar a consolidation queue)
EIP-8136 (cell-level deltas para broadcast de dados)
EIP-8159 (eth/71, troca de listas de acesso por bloco)
EIP-8246 (remover burn do SELFDESTRUCT)
EIP-8282 (Builder Execution Requests: fornece aos builders do ePBS solicitações dedicadas de registro e de saída)
Além disso, atualmente o Forkcast também lista o EIP-8254 (limitar o número de deposit requests dentro de cada bloco da camada de execução a 8192) como uma lista de "recomendado para consideração".
Do ponto de vista dos stakers, considerar o EIP-8061 e o EIP-8080 na lista é especialmente digno de atenção. Para stakers, isso significa que a liquidez da saída pode melhorar. Em um artigo de 5 de maio de 2026, a Figment afirma que os stakers institucionais precisam mais acompanhar ePBS, EIP-8061 e EIP-8080; e, estimando, considerando o tamanho do stake de cerca de 38,9 milhões de ETH até abril de 2026, o EIP-8061 pode aumentar o limite de churn de saída de 256 ETH/epoch para aproximadamente 1187 ETH/epoch; já o EIP-8080 permite que saídas normais usem a capacidade ociosa da fila de consolidação. A Figment também lembra que todos os números antes do lançamento na mainnet devem ser tratados como especulação.
Fonte: Figment
O protocolo está sendo atualizado, e membros da fundação também estão mudando
O preparo técnico do Glamsterdam e os ajustes de pessoal na Fundação Ethereum (Protocol cluster) aconteceram quase ao mesmo tempo. Em 11 de maio de 2026, o blog da Fundação Ethereum disse que o Glamsterdam atingiu vários marcos: a criação de um floor de 200 milhões de gas como alvo confiável pós-Glamsterdam, o ePBS funcionando de forma estável em devnets do Glamsterdam com múltiplos clientes, e o EIP-8037 finalizado.
A mesma matéria anunciou a transição de liderança do Protocol cluster: Will Corcoran, Kev Wedderburn e Fredrik se tornarão os novos coordenadores do cluster de protocolo. O coordenador anterior, Barnabé Monnot, e Tim Beiko saíram da Fundação Ethereum, e Alex Stokes está de férias.
A descrição das funções dos três novos coordenadores é: Will Corcoran tem experiência de coordenação entre equipes; Kev Wedderburn lidera a equipe de zkEVM; Fredrik lidera os projetos Protocol Security e Trillion Dollar Security.
Essas mudanças não ficaram apenas na equipe do protocolo. Em 18 de junho de 2026, Hsiao-Wei Wang publicou um texto afirmando que, após voltar de férias, decidiu renunciar aos cargos de diretor executivo em conjunto e de membro do conselho da Fundação Ethereum
Em 19 de junho de 2026, o ex-pesquisador da Fundação Ethereum Dankrad Feist disse que as pessoas que deixaram a EF são crentes de CROPS (anti-censura e anti-captura, open source, privacidade e segurança). Segundo ele, o problema não é estratégia, e sim gestão — e afirmou que essa saída de talentos é mais negativa para a Ethereum. Já Azeem, cofundador da Miden, interpretou na direção oposta: disse que a EF tem dificuldade de se transformar sozinha; após a saída de talentos, pode surgir uma nova organização capaz de executar melhor o roadmap da Ethereum, o que, no longo prazo, é líquido positivo para o ecossistema.
O posicionamento de pessoas internas da Fundação Ethereum parece mais uma delimitação de fronteiras. Bastian Aue (Aerugo), diretor executivo interino em conjunto da Fundação Ethereum, respondeu que os motivos de desligamento de membros da Fundação Ethereum incluem divergências estratégicas, adequação ao cargo, mudanças normais na instituição ou escolhas pessoais. A EF não discutirá assuntos pessoais de pessoal nas redes sociais, mas afirmou que quem sair deveria fazê-lo de maneira digna.
A Fundação Ethereum então usou uma thread oficial no Twitter para oferecer uma narrativa organizacional mais clara: para realizar o potencial da Ethereum, é preciso uma aliança de várias organizações; nos últimos 12 meses, várias organizações já reforçaram em conjunto a resiliência e as capacidades do ecossistema. Exemplos listados pela EF incluem: ethlabs (um laboratório de P&D sem fins lucrativos focado em ETH e na próxima fase da adoção de ETH), anunciado em 23 de junho; Eth Apps Guild (voltado à adoção real de aplicações nativas de Ethereum, com foco especial em mercados emergentes), iniciado em abril de 2026; e Ethereum Economic Zone (objetivo de reduzir a fragmentação do ecossistema por meio de sincronização/componibilidade e provas de conhecimento zero em tempo real) e Argot (um coletivo autônomo de engenheiros e pesquisadores que mantêm ferramentas de compilação Solidity e open source), fundada em 2025.
Essa thread oficial torna as mudanças recentes da Fundação Ethereum mais fáceis de entender: a fundação não está simplesmente empurrando pessoas e projetos para fora, nem está desistindo da coordenação central; em vez disso, talvez esteja quebrando o roadmap da Ethereum para que mais organizações possam compartilhá-lo em conjunto.
Resumo
Assim, o Glamsterdam não deveria ser visto apenas como um conjunto de EIPs. Trata-se de uma reorganização de engenharia da Ethereum antes de atingir um throughput maior: quem constrói os blocos, quem os propõe, quem valida, quais dados precisam ser mantidos por muito tempo e quais recursos devem ficar mais caros — tudo isso foi recolocado na mesa.
As palavras-chave da rota técnica são ePBS, BAL e o início de um gas multidimensional; já as palavras-chave da rota organizacional são mais realistas: se a Fundação Ethereum consegue manter poder de coordenação e se novas organizações fora da Fundação conseguem transformar essa coordenação em entrega contínua.
Referência:
https://forkcast.org/upgrade/glamsterdam/
https://ethereum.org/roadmap/glamsterdam/
https://blog.ethereum.org/2026/05/11/protocol-update-may-26
https://x.com/VitalikButerin/status/2027403360484430122