Explicação do Hard Fork Glamsterdam do Ethereum: Como a Execução Paralela e o ePBS Visam 10.000 TPS
Atualmente, dois construtores de blocos (block builders) montam mais de 90% de cada bloco da Ethereum. Cada transação aguarda em uma fila única, independentemente de quantos núcleos de CPU um validador possua. E os preços do gás ainda refletem padrões estabelecidos anos atrás em hardware que não existe mais.
Glamsterdam, o próximo hard fork da Ethereum previsto para a primeira metade de 2026, foi projetado para desmantelar todos esses três problemas de uma só vez. Com um salto no limite de gás (gas limit) de 60 milhões para 200 milhões, uma nova primitiva de execução paralela e a separação entre proponente e construtor (proposer-builder separation) integrada diretamente na camada de consenso, a atualização representa a reformulação estrutural mais agressiva desde o The Merge. Se for entregue no prazo, a Camada 1 da Ethereum poderá processar aproximadamente 10.000 transações por segundo — cerca de dez vezes a capacidade atual — reduzindo as taxas de gás em quase 79%.
Aqui está o que realmente está mudando, por que isso importa e onde os riscos se escondem.
Por que a Ethereum Precisava de um Reinício Estrutural
A Ethereum passou 2025 observando os concorrentes ganharem terreno em termos de velocidade bruta. A Solana processa mais de 1.000 transações reais por segundo. A Monad, uma novata compatível com EVM, demonstrou mais de 10.000 TPS com blocos de menos de meio segundo. Enquanto isso, a Camada 1 da Ethereum permanece entre 15 e 20 TPS — um número que mal se moveu desde a atualização Shanghai.
A lacuna de desempenho criou um padrão de migração visível. Desenvolvedores que criam aplicações sensíveis à latência — jogos, DeFi de alta frequência, transações de agentes de IA — optaram cada vez mais por redes mais rápidas. A resposta da Ethereum até agora foi empurrar a capacidade de processamento para as Camadas 2 (Base, Arbitrum, Optimism), mas essa estratégia introduziu seus próprios problemas de fragmentação: liquidez dividida em mais de 60 rollups, atrasos de sete dias para saques e experiências de usuário que exigem conhecimento em bridges.
Glamsterdam não abandona o roteiro (roadmap) das L2s. Ele torna a própria L1 rápida o suficiente para recuperar as cargas de trabalho que migraram para os concorrentes, ao mesmo tempo em que melhora a economia para a liquidação (settlement) das L2s. Vitalik Buterin delineou oito Propostas de Melhoria da Ethereum (EIPs) no final de fevereiro de 2026 que definem o escopo da atualização, com duas EIPs principais recebendo prioridade máxima.
Os Dois Destaques: Execução Paralela e Construção de Blocos ao Nível do Protocolo
EIP-7928: Listas de Acesso ao Nível do Bloco (BALs)
Hoje, os clientes da Ethereum descobrem quais contas e slots de armazenamento um bloco acessa apenas durante a execução. Há visibilidade zero antecipada sobre o padrão de acesso ao estado de um bloco. As transações são processadas uma a uma em sequência estrita, mesmo quando envolvem partes do estado totalmente não relacionadas.
A EIP-7928 introduz as Listas de Acesso ao Nível do Bloco (Block-Level Access Lists - BALs) — declarações estruturadas que especificam exatamente quais slots de armazenamento e contas cada transação irá ler ou gravar. Um hash desta lista de acesso, o "BAL root", é incorporado diretamente no cabeçalho do bloco.
O impacto prático é transformador. Quando um validador sabe antecipadamente que uma transação é um swap na Uniswap e outra é um depósito na Aave em um pool separado, ele pode processá-las simultaneamente em vários núcleos de CPU. A execução sequencial torna-se um gráfico de dependência, onde apenas transações genuinamente conflitantes devem esperar umas pelas outras.
As BALs também permitem o pré-carregamento do estado (state prefetching): os nós podem carregar os dados de estado necessários na memória antes mesmo do início da execução, eliminando gargalos de I / O que atualmente atrasam o processamento de blocos. A Ethereum Foundation estima que as BALs podem entregar melhorias de 10 a 30 vezes no rendimento da execução a curto prazo.
EIP-7732: Separação Proponente-Construtor Consagrada (ePBS)
O problema da construção de blocos é mais difícil de ver, mas igualmente corrosivo. Hoje, 80-90% da produção de blocos da Ethereum depende de serviços fora da cadeia (off-chain) chamados relays — principalmente o MEV-Boost da Flashbots. Um punhado de construtores especializados (Flashbots, Titan, BeaverBuild) monta blocos para validadores, extraindo o Valor Máximo Extraível (Maximal Extractable Value - MEV) através da ordenação de transações.
Este arranjo funciona, mas cria três riscos estruturais:
- Centralização. Dois ou três construtores controlam virtualmente toda a produção de blocos.
- Vulnerabilidade à censura. Aproximadamente 30% dos blocos cumprem atualmente as listas de sanções da OFAC através da filtragem por relays, o que significa que transações podem ser sistematicamente excluídas por um pequeno grupo.
- Dependência de confiança. Os validadores devem confiar que os relays não irão adulterar os blocos ou reter pagamentos.
A EIP-7732 move todo o mecanismo proponente-construtor para dentro da cadeia (on-chain). Sob a ePBS, os construtores montam blocos e selam criptograficamente seu conteúdo, publicando lances com compromissos de carga útil (payload commitments). Os proponentes escolhem o bloco que paga mais sem poder ver ou adulterar o que está dentro. As transações são reveladas apenas após o bloco ser finalizado.
Um novo Comitê de Pontualidade de Carga Útil (Payload Timeliness Committee - PTC) lida com verificações básicas de validação, e todos os lances, compromissos e pagamentos fluem através de mensagens definidas pelo protocolo e verificáveis na rede. Sem mais relays fora da cadeia. Sem mais suposições de confiança.
A Flashbots já antecipou essa mudança, migrando suas operações para a BuilderNet em dezembro de 2024 — uma rede de construção descentralizada operada conjuntamente com a BeaverBuild e a Nethermind. A ePBS do Glamsterdam torna a abordagem descentralizada o padrão para cada construtor e proponente na rede.
O Elenco de Apoio: Reprecificação de Gas e Economia de Estado
Além das grandes atrações, o Glamsterdam inclui várias EIPs que reestruturam o modelo económico da Ethereum:
A EIP-7904: Reprecificação Geral recalibra os custos de gas para opcodes da EVM usando benchmarks empíricos de hardware moderno. Muitos preços de gas atuais foram definidos há anos e já não refletem o custo computacional real. A recalibração proporciona uma redução de 78,6 % nas taxas de gas, tanto para transferências simples de ETH quanto para interações complexas de contratos inteligentes.
A EIP-8037: Aumento do Custo de Gas para Criação de Estado eleva o custo de gas para a criação de novas contas e slots de armazenamento, desencorajando a expansão desnecessária do estado que sobrecarrega a rede.
A EIP-8038: Aumento do Custo de Gas para Acesso ao Estado aumenta os custos de gas para leituras de contas e armazenamento "frios" (cold), refletindo melhor o custo de E / S de aceder a estados pouco utilizados.
O efeito líquido é um modelo de gas que cobra mais pelo que é genuinamente caro (criar e aceder a estados frios) e menos pelo que é barato (executar opcodes comuns em processadores modernos). O aumento do limite de gas de 60 milhões para 200 milhões por bloco fornece a capacidade bruta para absorver estas mudanças, mantendo custos por transação dramaticamente mais baixos.
Como o Glamsterdam se Compara à Concorrência
A corrida pela execução paralela não está a acontecer de forma isolada. Eis como o Glamsterdam se posiciona:
| Recurso | Ethereum (Glamsterdam) | Solana | Monad |
|---|---|---|---|
| Abordagem de paralelismo | Listas de acesso pré-declaradas (BALs) | Escalonador nativo Sealevel | Execução paralela otimista |
| TPS Alvo | ~ 10.000 | ~ 1.000 - 1.500 (mundo real) | ~ 10.000+ |
| Compatibilidade com EVM | Nativa | Não (requer reescrita em Rust) | Totalmente compatível com EVM |
| Tempo de bloco | ~ 12 segundos | ~ 400 ms | ~ 400 ms |
| Gestão de MEV | ePBS ao nível do protocolo | Marketplace de gorjetas Jito | Herdada do ecossistema EVM |
| Conjunto de validadores | ~ 500.000+ | ~ 1.500 | Emergente |
A abordagem da Ethereum é distintamente conservadora: as transações devem declarar o seu acesso ao estado antecipadamente, o que garante uma execução paralela livre de conflitos, mas exige mudanças nas ferramentas dos programadores. O runtime Sealevel da Solana lida com o paralelismo de forma nativa ao nível da VM. O Monad utiliza a execução otimista — processando transações em paralelo e reexecutando em caso de conflito — o que preserva a compatibilidade total com a Ethereum sem alterações para os programadores.
A diferença crítica é a gravidade do ecossistema. A Ethereum possui mais de 500.000 validadores, a liquidez DeFi mais profunda e a maior comunidade de programadores. Mesmo que o Monad entregue um rendimento equivalente, terá de construir tudo o resto do zero. A aposta do Glamsterdam é que tornar o incumbente suficientemente rápido remove o incentivo à migração.
O Impacto nas L2: Melhor Economia para Rollups
As melhorias do Glamsterdam não beneficiam apenas os utilizadores da L1. O aumento do limite de gas e a potencial expansão para mais de 72 blobs de dados por bloco melhoram drasticamente a economia para os rollups de Camada 2.
Rollups como Arbitrum, Optimism e Base pagam atualmente gas na L1 da Ethereum para publicar dados de transações. Com custos de gas mais baixos e maior capacidade de blobs, a liquidação em L2 torna-se mais barata, o que se traduz em taxas mais baixas para os utilizadores finais destas redes. A Ethereum Foundation projetou que o rendimento combinado de L1 + L2 poderá eventualmente atingir centenas de milhares de TPS à medida que o dimensionamento de blobs se combina com a execução paralela.
Isto cria um ciclo virtuoso: uma liquidação de L2 mais barata atrai mais utilizadores de L2, uma maior utilização de L2 gera mais taxas de liquidação na L1, e um maior rendimento na L1 garante que a camada de liquidação não se torne um gargalo.
O Que Pode Correr Mal
O Glamsterdam é ambicioso, e a ambição acarreta riscos.
A adoção de BALs requer mudanças nas ferramentas. Os programadores e as carteiras devem atualizar-se para gerar listas de acesso ao nível do bloco. Até que as ferramentas do ecossistema amadureçam, os benefícios da execução paralela podem permanecer teóricos para alguns tipos de transação.
O cronograma é aspiracional. A documentação da comunidade aponta para junho de 2026 como meta, mas a equipa de DevOps da Ethereum Foundation testou apenas três das EIPs propostas na Devnet-4 até ao início de 2026, estando a Devnet-5 em curso. Historicamente, os hard forks da Ethereum sofreram atrasos de meses.
O ePBS interrompe a infraestrutura de MEV existente. Os construtores de blocos e searchers construíram negócios inteiros em torno do atual sistema baseado em relays. A transição para o ePBS irá remodelar a cadeia de suprimentos de MEV, e nem todos os participantes irão beneficiar.
A reprecificação de gas pode quebrar pressupostos. Aplicações que usam estimativas de gas hardcoded podem comportar-se de forma inesperada quando os custos dos opcodes mudam. Embora a reprecificação reduza a maioria dos custos, os aumentos para a criação de estado e leituras frias podem afetar contratos que realizam muitas operações de armazenamento frio.
Mais de 30 propostas foram rejeitadas para o Glamsterdam, incluindo tempos de slot reduzidos, medição de gas multidimensional e verificação de assinatura pós-quântica. Espera-se que estas funcionalidades cheguem no Hegota, o segundo fork de 2026 agendado para a segunda metade do ano.
O Que Vem a Seguir: A Estratégia de Quatro Forks
O Glamsterdam é o primeiro passo numa estratégia coordenada de desempenho em quatro forks que se estende até 2027:
- Regra de Confirmação Rápida — confirmações de depósito de 13 segundos sem necessidade de hard fork (já disponível ou iminente)
- Glamsterdam (H1 2026) — Execução paralela + ePBS + reprecificação de gas
- Fusaka — PeerDAS para disponibilidade de dados de 1 GB / s com um aumento de 30.000x na capacidade
- Hegota (H2 2026) — Árvores Verkle para provas 10x menores + migração para criptografia pós-quântica
Juntos, estes upgrades transformam a Ethereum de uma estrada de pista única numa rodovia de várias faixas com acessos otimizados para todos os tipos de tráfego. A questão já não é se a Ethereum consegue igualar a velocidade dos concorrentes, mas se consegue implementar estes upgrades antes que os casos de utilização sensíveis ao desempenho se estabeleçam permanentemente noutro local.
Conclusão
Glamsterdam não é um exercício de marketing. É uma resposta estrutural à ameaça existencial de que a Layer 1 da Ethereum se torne irrelevante como um ambiente de execução de propósito geral, enquanto os concorrentes capturam as cargas de trabalho que mais importam: jogos, pagamentos, transações de agentes de IA e DeFi em tempo real.
A atualização introduz inovações arquitetônicas genuínas — BALs para execução paralela, ePBS para construção de blocos descentralizada e reprecificação empírica de gas — que abordam problemas que a Ethereum tolera há anos. Se for entregue conforme o cronograma, a rede passará de 15 TPS para 10.000 TPS, tornando-se mais descentralizada, e não menos.
A ressalva é que "conforme o cronograma" carrega um grande peso nessa frase. O histórico da Ethereum sugere cautela em relação aos prazos. Mas o trabalho de engenharia é real, as devnets estão em execução e a pressão competitiva nunca foi tão alta.
Para desenvolvedores, validadores e usuários que observam de fora: vale a pena acompanhar a Glamsterdam de perto. Ela será ou a atualização que garantirá a posição da Ethereum para a próxima década — ou aquela onde o abismo entre a ambição e a execução finalmente cobrará seu preço.
BlockEden.xyz fornece endpoints RPC de Ethereum de nível empresarial e infraestrutura de API multi-chain para desenvolvedores que constroem na Ethereum L1 e nos rollups que nela liquidam. À medida que a Glamsterdam remodela a camada de execução, uma infraestrutura de nós confiável torna-se mais crítica do que nunca. Explore nossos serviços de API Ethereum para construir sobre bases projetadas para a próxima geração de throughput on-chain.