Glamsterdam: por que o ePBS atrasa o fork do Ethereum

O próximo hard fork do Ethereum, Glamsterdam, já não chegará no verão: a Ethereum Foundation o adiou para a segunda metade de 2026 — final de agosto no melhor cenário, sem data de mainnet anunciada — e o gargalo tem nome próprio: EIP-7732, conhecido como ePBS. O ePBS (enshrined Proposer-Builder Separation, separação proponente-construtor inscrita no protocolo) é a peça que reescreve como os blocos do Ethereum são construídos, e sua complexidade — somada a uma interação ainda não testada com as novas listas de acesso em nível de bloco — é o que freou o cronograma. Para os grandes stakers institucionais que hoje concentram boa parte da rede — Lido com cerca de 8,72 milhões de ETH e Coinbase com cerca de 4,5 milhões — não se trata de um detalhe técnico distante: o ePBS muda radicalmente de quem depende sua operação de construção de blocos. Este artigo explica por que houve o atraso, o que muda operacionalmente para quem faz staking e qual é a cronologia real das devnets para a mainnet.

O que é exatamente o Glamsterdam e o que traz o ePBS?

Glamsterdam é o codinome do hard fork (atualização da rede que exige que todos os nós adotem as novas regras simultaneamente) que sucede o Pectra, ativado na mainnet em 7 de maio de 2025. O pacote combina várias melhorias, mas a que domina o debate e dita o ritmo é a EIP-7732, ePBS.

Para entender o ePBS, convém fixar quatro termos. O proposer é o validador ao qual o protocolo atribui a vez de propor o próximo bloco. O builder é quem monta o conteúdo desse bloco: ordena as transações para maximizar seu valor. O MEV (Maximal Extractable Value, valor máximo extraível) é precisamente esse valor que pode ser capturado ao reordenar, incluir ou excluir transações dentro de um bloco. E o relay é o intermediário externo que hoje conecta builders e proposers para que a distribuição seja confiável sem que o conteúdo do bloco seja visto antecipadamente.

A analogia que melhor define o processo: o proposer escolhe o menu — qual slot será servido e sob quais condições —, mas o builder é quem cozinha o prato, decide a ordem dos ingredientes e fica com a gorjeta do MEV. Hoje, essa divisão entre quem escolhe o menu e quem cozinha é arbitrada por um intermediário de confiança fora do protocolo: o relay, dentro do sistema MEV-Boost. O ePBS pega esse arranjo e o insere dentro das regras do Ethereum: o mercado de builders deixa de depender de relays externos e passa a estar inscrito (daí o termo "enshrined") no próprio protocolo. A mecânica econômica de por que essa divisão importa — e de como o MEV passou de praga a ser inscrito e redistribuído — está detalhada em nossa análise da Era III do MEV; quem estiver começando do zero encontrará a base em o que é o MEV.

Junto ao ePBS, o Glamsterdam incorpora a EIP-7928 (Block-Level Access Lists, BALs), que anexa a cada bloco a lista de contas e armazenamento que as transações acessarão, permitindo uma execução mais paralela; e um pacote de reajuste dos preços de gas (gas repricing, no qual a EIP-7904 é uma das várias EIPs envolvidas). O FOCIL (Fork-Choice Inclusion Lists), que era considerado candidato, foi movido para o Hegotá, o fork posterior, justamente para não sobrecarregar o Glamsterdam.

Por que o Glamsterdam foi adiado?

O atraso não é uma falha: é cautela de engenharia. O ePBS é uma das modificações mais invasivas na camada de consenso desde a transição para Proof of Stake, pois altera o fluxo pelo qual um bloco passa da proposta à confirmação. Existem duas causas técnicas específicas por trás do adiamento do cronograma.

A primeira é a complexidade intrínseca de implementar a EIP-7732. Fazer com que a divisão proposer-builder viva dentro do protocolo obriga a coordenar pagamentos "trustless" (sem intermediário de confiança) entre ambas as partes, a redefinir como e quando o payload do bloco é validado, e a garantir que todos os clientes de consenso implementem a mesma lógica de forma compatível. Não é um código que se testa em uma tarde.

A segunda é a interação não testada em escala de mainnet entre o ePBS e as BALs (EIP-7928). Cada uma isoladamente é gerenciável; o problema é que elas se sobrepõem. As BALs antecipam quais contas e armazenamento cada transação acessará para poder paralelizar a execução, enquanto o ePBS separa o momento em que um bloco é comprometido do momento em que seu payload é validado. Combinar ambas cria novos caminhos de execução — o que se sabe sobre o conteúdo do bloco e quando — que só aparecem sob carga real e com muitos clientes diferentes comunicando-se entre si. Por isso, o processo está passando por quantas devnets forem necessárias antes de chegar às testnets públicas: uma falha de consenso aqui não é um bug qualquer, é uma bifurcação da rede.

A isso somou-se uma decisão estratégica. A equipe de engenharia da Base (a L2 da Coinbase) alertou que incluir o FOCIL além do ePBS teria empurrado o fork para além de 2026. A resposta foi remover o FOCIL do pacote e transferi-lo para o Hegotá, o fork seguinte. É a lógica que guiou todo o redesenho do Glamsterdam: em vez de incluir tudo o que é desejável e arriscar um fork impossível de concluir, limita-se o escopo ao ePBS mais as duas EIPs de suporte (BALs e gas repricing) e adia-se o restante. Reduzir a ambição para proteger a data é, por si só, um sinal de maturidade do processo.

Convém precisar o marco temporal para não cair em manchetes enganosas. O ethereum.org já classifica o Glamsterdam como uma atualização da segunda metade de 2026. O objetivo interno aspiracional gira em torno do final de agosto de 2026, sem data de mainnet anunciada, com risco real de deslizar para o quarto trimestre se o ePBS precisar de mais iterações em testnet. Não se trata de um atraso em relação à janela prevista: o fork continua dentro de sua faixa da segunda metade de 2026, mas com a peça mais complexa ainda em fase de amadurecimento.

O que muda operacionalmente para Lido e Coinbase?

Aqui está o verdadeiro diferencial, pois afeta quem concentra a rede. Hoje, mais de 90% do mercado de builders opera através do MEV-Boost, com relays externos de atores como Flashbots ou bloXroute (com o Commit-Boost ganhando terreno, em torno de 20% de adoção como alternativa de middleware). Isso significa que um grande operador de staking, quando chega sua vez de propor um bloco, não constrói o conteúdo: ele o leiloa para builders através de um relay e fica com a oferta mais alta. A construção de blocos — e a captura de MEV associada — está terceirizada para um punhado de intermediários fora do protocolo.

O ePBS reescreve essa dependência. Ao inscrever o mercado de builders no protocolo, a divisão proposer-builder deixa de exigir um relay de confiança: o próprio Ethereum garante que o proposer receba o pagamento e que o builder entregue o conteúdo. Para a Lido, Coinbase e qualquer grande operador, isso muda o ponto de controle e o perfil de risco de sua operação de construção de blocos — menos dependência de infraestrutura de terceiros, regras de divisão mais previsíveis —, embora o redesenho introduza novos requisitos (por exemplo, capital imobilizado para os builders inscritos) cujo efeito sobre a concorrência no mercado de builders é um dos pontos em debate.

O contexto de por que isso pesa tanto: o staking de Ethereum está em níveis máximos, com o mercado vigiando de perto a arquitetura de quem valida. A Lido lidera com cerca de 8,72 milhões de ETH (em torno de 24% do staking total) e a Coinbase gere cerca de 4,5 milhões (cerca de 12%, dados do primeiro trimestre de 2026). Esse contexto de staking recorde é abordado por nós na paradoxo staking-ETF, e o estado específico da Lido em staking institucional com stETH. O fato de o limite por validador ter subido de 32 para 2.048 ETH com o Pectra (EIP-7251) apenas concentrou mais stake por nó, o que torna mais urgente resolver a centralização da construção de blocos que o ePBS busca combater.

Quem é mais afetado pela mudança e de que forma?

O impacto não é uniforme. Convém separá-lo por tipo de ator, pois cada um entra no ePBS a partir de uma posição distinta.

A distribuição desigual tem uma nuance que merece destaque para os builders. Hoje, um punhado de builders profissionais captura a maioria do fluxo de MEV porque controlam a relação com os relays e a infraestrutura de leilão. O ePBS não elimina a vantagem do builder especializado — ordenar transações para extrair valor continua sendo um negócio de escala —, mas ao inscrever as regras no protocolo e exigir capital imobilizado dos builders inscritos, altera as alavancas da concorrência. Se essa barreira de capital consolidará os grandes ou, ao contrário, abrirá espaço para novos entrantes ao remover o relay como guardião, é justamente o ponto que ninguém pode afirmar com certeza ainda e que o próprio debate da Sigma Prime deixou em aberto.

Para o investidor que não opera nós, o relevante é que o mercado vigia a data do Glamsterdam como um sinal sobre a saúde do roadmap do Ethereum. Análises pessimistas como a do JPMorgan sobre o baixo desempenho estrutural do ETH usam precisamente a execução do roadmap como um de seus eixos: um atraso ordenado e comunicado não é o mesmo que um caótico, e as equipes estão escolhendo o primeiro. O staker que delega na Lido ou Coinbase não nota nada disso em seu rendimento diário; o que muda é a solidez da infraestrutura sobre a qual repousa esse rendimento.

Existe consenso em incluir o ePBS neste fork?

Não totalmente, e a tensão é instrutiva. O debate mais citado partiu da Sigma Prime, empresa por trás do cliente de consenso Lighthouse, e convém retratá-lo com precisão porque a posição da casa não foi monolítica. Internamente houve desacordo: Dapplion argumentou contra a inscrição da EIP-7732 no Glamsterdam, sustentando que inscrever a separação proposer-builder hoje é desnecessário — o MEV-Boost funciona com incidentes mínimos, parte dos benefícios de escalabilidade é alcançada com "payload split + delayed execution" sem necessidade de pagamentos trustless, e a rede tem margem para esperar mais um ciclo de fork. Sua ressalva: "se for necessário enviar alguma forma de ePBS agora, votarei por programar a EIP-7732 para o Glamsterdam", reconhecendo-a como a especificação mais madura disponível.

Diante dessa posição, Mark Mackey defendeu a proposta como o destaque do fork, e a empresa acabou apoiando sua inclusão. Ou seja: não é a "Sigma Prime contra", mas sim um debate interno resolvido a favor, com argumentos sérios de ambos os lados que vale a pena conhecer antes de ler manchetes simplistas. O eixo da discussão — inscreve-se o ePBS agora ou espera-se? — é exatamente o que uma análise externa não consegue destilar sem ter lido as fontes primárias. A CleanSky não toma partido: expõe que a cautela do cronograma e a própria existência deste debate explicam por que o fork avança devagar e bem acompanhado de revisão técnica.

Qual é a cronologia real das devnets para a mainnet?

O caminho de uma mudança de consenso no Ethereum tem fases bem definidas: primeiro devnets (redes de teste internas das equipes de clientes), depois testnets públicas (Sepolia, Hoodi) e, finalmente, mainnet. O Glamsterdam ainda está na primeira fase.

• Ao longo de 2024 — O MEV-Boost consolida seu domínio na construção de blocos (mais de 90% do mercado de builders).
• 7 de maio de 2025 — Pectra é ativado na mainnet; o limite por validador sobe de 32 para 2.048 ETH (EIP-7251).
• Início de 2026 — Glamsterdam se delineia como o próximo fork, com o ePBS (EIP-7732) como peça principal.
• ~Primeira semana de maio de 2026 — Conclui-se a devnet Soldøgn (fase de interoperabilidade entre clientes); Devnet-4 é finalizada.
• Junho de 2026 (atual) — devnets do Glamsterdam ativas (a linha de ePBS+BALs ainda em testes); testnets públicas (Sepolia, Hoodi) ainda pendentes.
• Final de agosto de 2026 (melhor caso) — Meta aspiracional de ativação, sem data de mainnet confirmada.
• Quarto trimestre de 2026 (risco) — Janela alternativa se o ePBS exigir mais iterações de testnet.

A leitura honesta desta cronologia é que o progresso é real, mas a incerteza reside no último trecho: o salto das devnets para as testnets públicas é o próximo marco a ser vigiado, e de sua fluidez dependerá se o final de agosto continuará plausível ou se o fork deslizará para o outono.

O que fica como lição para o staker?

Três ideias para quem faz staking ou investe em ETH. Primeiro, o atraso do Glamsterdam é sinal de disciplina, não de decomposição: a equipe prefere amadurecer o ePBS em devnets antes de enviar para a mainnet uma reescrita do fluxo de blocos com interações não testadas. Segundo, a mudança operacional de fundo é que o mercado de builders deixa de depender de relays externos — onde se concentra hoje mais de 90% do fluxo — para estar inscrito no protocolo, o que reduz a dependência de terceiros para Lido, Coinbase e validadores independentes. Terceiro, a data não está fechada: final de agosto de 2026 é o melhor cenário, o quarto trimestre é o risco, e o indicador a seguir é o salto das devnets para as testnets públicas (Sepolia e Hoodi).

Para quem deseja se aprofundar na mecânica econômica do MEV que o ePBS reordena, o detalhamento está em nossa análise da Era III do MEV. Glamsterdam não é o fim dessa história: é o momento em que o Ethereum decide colocar o mercado de builders dentro de suas próprias regras.

Fontes e links: ethereum.org — roadmap Glamsterdam · Ethereum Foundation — Checkpoint #9 · Sigma Prime — debate sobre EIP-7732 · Everstake — Glamsterdam explicado · Figment — o que significa para stakers institucionais