Saltar para o conteúdo principal

Glamsterdam Escorrega: A Reforma de MEV do Ethereum Enfrenta Realidade da Engenharia com Atraso no ePBS

· 13 min de leitura
Dora Noda
Dora Noda
Software Engineer

Pela primeira vez na cadência acelerada de forks da Ethereum em 2026 - 2027, o roadmap vacilou. Em meados de abril de 2026, os desenvolvedores principais reconheceram publicamente o que as equipes de clientes sussurravam há semanas: a Separação Propositor - Construtor Incorporada (ePBS) — a peça mais ambiciosa do hard fork Glamsterdam — é "mais complexa do que o previsto", e a janela original da mainnet para maio - junho está quase certamente fora de alcance. O atraso empurra o Glamsterdam para o T3 ou T4 de 2026, estreitando a lacuna com o fork Hegota já agendado e reabrindo uma questão que a Ethereum pensava ter resolvido: pode uma camada base de cinco clientes ainda atualizar no ritmo que uma economia de L2 pós - Pectra exige?

A resposta importa muito além do próprio ecossistema da Ethereum. Cada semana que o ePBS permanece em devnet é uma semana em que o atual oligopólio de relays da Flashbots continua mediando dezenas de bilhões em fluxos anuais de MEV, uma semana em que as L2s continuam precificando blobs contra uma curva de oferta que o fork deveria suavizar, e uma semana em que a Solana — que garantiu 98,27 % de aprovação dos validadores para sua reformulação de consenso Alpenglow em setembro de 2025 — amplia sua liderança em uma cadência de atualização monolítica mensuravelmente mais rápida. O Glamsterdam nunca foi apenas mais um hard fork. Era a resposta da Ethereum à tese da "L1 Rápida". A resposta agora está atrasada.

Os Dois EIPs Que Definem o Glamsterdam​

Glamsterdam — uma fusão de Gloas (o codinome da camada de consenso) e Amsterdam (o codinome da camada de execução, seguindo a tradição de cidades - sede da Devcon) — está ancorado por dois EIPs principais que, juntos, reformularão a forma como a Ethereum produz blocos.

EIP - 7732 (ePBS) divide o bloco de consenso do bloco de execução no nível do protocolo. Hoje, os validadores que executam o MEV - Boost entregam a construção do bloco a um mercado de construtores fora do protocolo por meio de relays centralizados. A própria migração da Flashbots em dezembro de 2024 de todos os construtores e fluxo de ordens para a BuilderNet foi, por si só, uma admissão de que a arquitetura de relay cria riscos de concentração. O ePBS incorpora a separação: propositores e construtores tornam-se participantes do protocolo de primeira classe que interagem diretamente, sem a necessidade de relays.

EIP - 7928 (Listas de Acesso no Nível do Bloco) faz com que os blocos declarem sua pegada de leitura / escrita — contas e slots de armazenamento acessados — antecipadamente. Os clientes podem então paralelizar a execução e a verificação, reduzindo o tempo que um bloco leva na propagação. Combinado com o ePBS, o par visa uma redução de ~ 50 % na latência efetiva do bloco.

No papel, esses EIPs se complementam perfeitamente. Na implementação, eles estão interagindo com todas as outras partes da infraestrutura pós - Pectra — incluindo a consolidação de validadores EIP - 7251 MaxEB, já lançada no Pectra — de maneiras que as especificações originais não previram totalmente.

O Que Realmente Atrasou​

A chamada de Consenso de Todos os Desenvolvedores Principais (ACDC # 177) de 16 de abril de 2026 tornou clara a realidade da engenharia. Até este mês, os testes eram bifurcados em duas redes separadas: epbs-devnet para a separação propositor - construtor e bals-devnet para as listas de acesso. A "devnet generalizada" que as funde — o primeiro ambiente onde todos os componentes do Glamsterdam coexistem — só recebeu luz verde depois que o Lighthouse e alguns outros clientes de consenso produziram builds estáveis durante a janela de interoperabilidade de abril.

"A Devnet Zero do ePBS foca menos no desempenho e mais na interoperabilidade", observou um engenheiro de cliente no resumo da chamada. Tradução: ainda estamos descobrindo o que quebra quando cinco clientes de consenso e cinco clientes de execução interpretam a especificação de forma independente. As primeiras execuções produzem principalmente blocos vazios — não uma falha estrutural, mas um sinal de que o caminho ideal ainda está sendo pavimentado, quanto mais o caminho adversarial.

As consequências no cronograma se acumulam:

  • A Devnet Zero deve se estabilizar entre Lighthouse, Prysm, Teku, Nimbus e Lodestar no lado do consenso, além de Geth, Nethermind, Besu, Erigon e Reth no lado da execução.
  • As Devnets Um e Dois precisam revelar bugs de interação entre ePBS, BALs, reprecificação de gas e os mais de 25 EIPs secundários em consideração.
  • As testnets públicas (sucessora da Holesky, Sepolia) precisam de pelo menos 6 - 8 semanas de atividade de shadow - fork antes que qualquer data de lançamento na mainnet possa ser definida de forma confiável.
  • As versões dos clientes devem ser finalizadas, auditadas e distribuídas aos stakers com antecedência suficiente para que um problema de escolha de fork (fork - choice) na mainnet não se torne um incidente de vivacidade (liveness).

Cada etapa é medida em semanas, não dias. Um lançamento em maio - junho exigia que a Devnet Zero estivesse estável em fevereiro. Não estava. Junho - julho exigia estabilidade em março. Não estava. Em abril, a matemática simplesmente não fecha — daí o reconhecimento silencioso de que o fork principal está deslizando para o segundo semestre de 2026.

O Paradoxo da Diversidade de Clientes​

A diversidade de cinco clientes de execução da Ethereum é possivelmente sua propriedade de neutralidade credível mais valiosa — um bug em um único cliente não pode derrubar a rede. Mas essa diversidade é também o motivo pelo qual o Glamsterdam é difícil.

Cada equipe de implementação deve construir, testar e estabilizar o ePBS de forma independente. Cada uma revela diferentes casos extremos. As atas da ACDC de abril descrevem "pull requests pendentes" em vários clientes e observam que as mudanças nas especificações de consenso podem bloquear totalmente a Devnet Dois do ePBS até serem resolvidas. Este é precisamente o imposto de coordenação que uma rede de implementação única não paga.

Compare com a cadência da Solana. O Alpenglow, a substituição do consenso da Solana visando uma finalidade determinística de 100 - 150 ms, passou por uma votação de validadores com 98,27 % de apoio — um dos mandatos mais fortes na história da rede — em setembro de 2025. O plano de implementação é simples: o cliente Agave da Anza lança a atualização no T3 de 2026; o Firedancer, a segunda implementação da Jump Crypto, segue em seguida. Como a Solana teve efetivamente apenas um cliente de produção até o Firedancer ultrapassar 20 % de participação na mainnet no início deste ano, sua superfície de coordenação é uma fração da da Ethereum.

Esta não é uma observação neutra. Redes monolíticas lançam atualizações mais rápido. Redes multi - cliente lançam atualizações de forma mais segura. O atraso do Glamsterdam é o preço da escolha arquitetônica da Ethereum — e, pela primeira vez desde o Merge, o mercado está avaliando se esse preço ainda vale a pena ser pago.

O que o Atraso Significa para L2s e MEV​

O fork Pectra foi lançado em 2025 conforme o cronograma. O Fusaka adicionou PeerDAS e expandiu a capacidade de blobs logo depois. As equipes de L2 construíram seus planos de capacidade para 2026 com base no lançamento do Glamsterdam no 2º trimestre, com a expansão adicional de blobs e a redistribuição de MEV chegando para atender à crescente demanda de rollups.

Esses planos agora precisam ser refeitos.

Precificação de blobs. Esperava-se que o Glamsterdam aumentasse ainda mais a contagem de blobs por bloco — potencialmente para 72 ou mais — proporcionando aos rollups optimistic e ZK uma disponibilidade de dados significativamente mais barata. Um atraso para o 3º ou 4º trimestre significa de 2 a 4 meses extras de oferta de blobs mais restrita, o que é mais importante para rollups que já saturaram suas faixas de taxas.

Redistribuição de MEV. A arquitetura MEV-boost de hoje recompensa os maiores construtores de forma desproporcional. Retornos superlineares na agregação de fluxo de pedidos (orderflow) significam que, uma vez que um construtor garante uma liderança, a economia empurra para o monopólio. O ePBS não elimina o MEV, mas remove o relay como um ponto de estrangulamento de coordenação — o que deve, em teoria, redistribuir uma fração da extração atual de volta para os proposers e, consequentemente, para os stakers. Cada mês de atraso é um mês em que a dinâmica de MEV existente persiste.

Competição de L2s. A Base já atingiu tempos de bloco de 2 segundos. Arbitrum e Optimism estão lançando suas próprias melhorias de sequenciador e DA em cadências independentes. Quanto mais tempo o gargalo da L1 persistir, mais os roadmaps das L2s divergem de qualquer atualização unificada da L1 — e mais o "roadmap centrado em rollups" se torna N roadmaps de rollups separados que por acaso liquidam na mesma camada base.

A Questão do FOCIL e o Aperto do Hegota​

Uma das decisões mais consequentes da ACDC de abril foi mover as Listas de Inclusão de Escolha de Fork (FOCIL) para fora do Glamsterdam e para o Hegota, onde foi formalmente selecionado como o destaque da camada de consenso para o final de 2026.

O FOCIL é a resposta de resistência à censura da Ethereum — um mecanismo que permite que um comitê de proposers imponha coletivamente a inclusão de transações, para que nenhum construtor individual possa excluir sistematicamente payloads (endereços sancionados pela OFAC, por exemplo). A equipe de engenharia da Base alertou publicamente que agrupar FOCIL com ePBS empurraria o Glamsterdam para além de 2026 inteiramente. Removê-lo traz alívio ao cronograma do Glamsterdam — ao custo de comprimir a janela entre a eventual ativação da mainnet do Glamsterdam e a do Hegota.

Se o Glamsterdam for lançado no 4º trimestre de 2026 e o Hegota visar o final do 4º trimestre, o intervalo pode ser de apenas 6 a 8 semanas. Esse é um prazo curto para validadores, construtores de blocos, provedores de staking e equipes de L2 absorverem uma mudança de protocolo antes que a próxima chegue. O roadmap do Hegota também inclui um trabalho significativo de inchaço de estado (state-bloat) — as discussões iniciais focaram em Árvores de Verkle (Verkle Trees), que reduziriam os requisitos de hardware dos nós, mas exigiriam seus próprios testes extensivos.

O cenário para o qual a Ethereum está agora planejando silenciosamente: dois forks principais aterrissando dentro de um trimestre um do outro, em uma matriz de testes que a Solana lança em um único lançamento coordenado.

Por que Isso Não é uma Crise — Ainda​

Seria um erro interpretar o atraso do Glamsterdam como algo existencial. O processo de fork da Ethereum está funcionando exatamente como planejado. O ePBS está sendo adiado não porque a coordenação falhou, mas porque a coordenação detectou um problema — ambiguidades na especificação e casos extremos de implementação — antes que chegassem à mainnet. A alternativa, lançar no prazo e combater bugs de escolha de fork em tempo real com mais de US$ 400 bilhões em valor liquidado em jogo, é imensamente pior.

A questão mais profunda é se a cadência atual da Ethereum é sustentável à medida que a complexidade por fork cresce. Glamsterdam não são apenas dois EIPs; são dois recursos principais mais de 25 pequenas mudanças, cada uma interagindo com um conjunto de validadores pós-Pectra que já possui consolidação maxEB, blobs habilitados para PeerDAS e um ecossistema L2 maduro por cima. Cada novo fork torna a matriz de teste mais ampla.

Propostas para dividir o próprio Glamsterdam — lançando BALs no 3º trimestre e ePBS no 1º trimestre de 2027 — foram levantadas e, até agora, rejeitadas. O contra-argumento é convincente: BALs sem ePBS entregam valor marginal, porque os ganhos de execução paralela são limitados pela arquitetura atual do construtor. Os recursos são genuinamente complementares, e desmembrá-los economiza tempo ao custo da coerência da atualização.

O que Observar nos Próximos 90 Dias​

Para desenvolvedores, stakers e qualquer pessoa que esteja precificando o espaço de bloco da L2 para a segunda metade de 2026, três sinais importam:

  1. Estabilidade da Devnet Zero. Se a devnet generalizada rodar por mais de 30 dias sem um incidente crítico até o início de junho, uma meta para o 3º trimestre de 2026 torna-se credível. Se não, o 4º trimestre é o limite mínimo.
  2. Ativação de testnet pública. O sucessor da Holesky e a Sepolia precisam fazer o fork pelo menos 8 semanas antes da mainnet. Sem data de fork na testnet = sem data de fork na mainnet.
  3. Seleção de EIPs do Hegota. O destaque do Hegota em fevereiro de 2026 era o FOCIL; o destaque da camada de execução ainda está sendo debatido. O que quer que seja escolhido restringirá ainda mais o quão proximamente os dois forks podem ser sequenciados.

O roadmap 2026-2027 da Ethereum sempre foi ambicioso. O atraso do Glamsterdam é o primeiro lembrete concreto de que ambicioso não significa pontual. Para uma rede cuja credibilidade repousa em fazer coisas difíceis com cuidado, um atraso medido não é uma falha. É o recurso.

A BlockEden.xyz opera infraestrutura Ethereum de nível empresarial através do Pectra, Fusaka e em todas as redes de teste que preparam as regras de fork do Glamsterdam. Se você está construindo contra um alvo de atualização móvel e precisa de nós que rastreiem mainnet, testnets e devnets em paralelo, explore nossos serviços de API Ethereum — infraestrutura projetada para equipes que não podem se dar ao luxo de um estado de fork no lado errado de uma mudança de especificação.

Fontes​

Share on Twitter