Ethereum Layer2 descentralização não atinge as expectativas: o que significa a declaração de Vitalik?

Em maio de 2026, a Fundação Ethereum encerrou uma semana de Soldøgn Interop na Ilha de Svalbard, Noruega, com mais de cem desenvolvedores principais participando do encerramento oficial do esforço colaborativo de fortalecimento da atualização Glamsterdam. Esta reunião não apenas atingiu os objetivos técnicos centrais de Glamsterdam, mas também confirmou a mudança de direção na atualização Hegotá — de uma rota de escalabilidade originalmente planejada para uma bifurcação focada na “limpeza e fortalecimento” de dívidas técnicas, ao invés de expansão.

No entanto, quase simultaneamente, uma outra avaliação amplamente difundida na comunidade merece reflexão mais profunda: Vitalik Buterin admitiu explicitamente que, na rota centrada em Rollup do Ethereum, o avanço na descentralização do Layer2 “tem sido muito mais lento do que o esperado”. Essa realidade, entrelaçada com a rápida expansão do próprio L1 do Ethereum, está reformulando a lógica fundamental do caminho de escalabilidade do Ethereum.

Por que o progresso na descentralização do Layer2 do Ethereum frequentemente fica aquém das expectativas

Em fevereiro de 2026, Vitalik declarou publicamente que o roteiro de cinco anos atrás, que estabelecia o L2 como principal meio de escalabilidade do Ethereum, já não era mais aplicável. Sua avaliação central baseia-se em dois fatos: primeiro, que o progresso na descentralização do L2 em estágios mais avançados “tem sido muito mais lento e difícil do que o esperado”; segundo, que a velocidade de expansão do próprio L1 do Ethereum superou significativamente as previsões iniciais.

Do ponto de vista do quadro de níveis de descentralização, o L2BEAT divide os Rollups em três fases — Estágio 0 (completamente centralizado), Estágio 1 (com dependência limitada de governança por multiassinatura) e Estágio 2 (totalmente descentralizado, garantido apenas por código e criptografia). Até o início de 2026, a maioria dos principais L2s ainda permanecia nos Estágios 0 ou 1, sem atingir a descentralização total. Mesmo os poucos que avançaram para o Estágio 1 ainda estavam longe do padrão de “sem qualquer controle por portas dos fundos” exigido no Estágio 2.

Essa lentidão, além de razões técnicas, tem fatores econômicos. Algumas equipes de L2 afirmaram claramente que, devido a restrições regulatórias ou modelos de negócio, talvez nunca busquem uma descentralização completa. A receita dos ordenadores de transações (sequencers), núcleo do modelo de negócio dos operadores de L2, ao depender de ordenadores centralizados, implica ceder parte desses incentivos econômicos — o que, na prática, limita a velocidade do avanço na descentralização.

Centralização de ordenadores e pontes multiassinatura expõem três problemas estruturais

Ao analisar as causas estruturais do atraso na descentralização do L2, podemos focar em três questões interligadas.

Primeiro, a centralização dos ordenadores. Atualmente, a maioria dos L2s depende de um único ordenador centralizado para empacotar e ordenar transações. Embora essa abordagem seja eficiente e de baixo custo, ela apresenta problemas de resistência à censura e risco de ponto único de falha. O ordenador controla a ordem das transações, podendo extrair o máximo valor (MEV) e exercer potencial controle de censura — o que viola o princípio central de descentralização do próprio Ethereum.

Segundo, a demora na implementação de provas de fraude e de validade. Rollups Otimistas dependem de uma janela de desafio (normalmente 7 dias) para provas de fraude, obrigando os usuários a confiar na operação do L2 por um período prolongado. Embora ZK Rollups possam oferecer finalização quase instantânea, a geração de provas de validade exige circuitos altamente customizados e processos de auditoria complexos. Além disso, cada hard fork do Ethereum que altera o comportamento do EVM requer sincronização das provas nos L2s, aumentando os custos.

Terceiro, a fragmentação de liquidez entre blockchains. Até o início de 2026, mais de 50 redes de Rollup acumulam um valor total bloqueado (TVL) superior a 45 bilhões de dólares, mas os fundos e usuários estão dispersos entre várias redes e interfaces de ponte. A maior parte das conexões com o Ethereum L1 depende de pontes multiassinatura — contratos que controlam a transferência de ativos entre blockchains. A crítica de Vitalik é que uma cadeia EVM capaz de processar 10.000 TPS, conectada ao L1 por uma ponte multiassinatura, não está realmente expandindo o Ethereum, mas criando uma plataforma independente baseada em confiança. O uso generalizado de pontes multiassinatura indica que a maioria dos Rollups não herdou a segurança do Ethereum, dependendo de controle centralizado para operação.

Lançamento do Glamsterdam devnet e resposta do ePBS aos desafios de escalabilidade e segurança

O lançamento do Glamsterdam devnet representa um marco importante na rota do Ethereum em 2026. Antes do fim do Soldøgn Interop de maio, o glamsterdam-devnet-2 operava de forma estável, com o protocolo ePBS (Proposer-Builder Separation embutido na camada de protocolo) realizando testes ponta a ponta entre diferentes clientes, cobrindo “quase todas as implementações de clientes”.

O ePBS tem como valor central a separação do direito de construir blocos e do direito de propor blocos, além de incorporar uma mecânica de padronização na cadeia de suprimentos de MEV. Anteriormente, a construção de blocos dependia de retransmissores externos, o que apresentava riscos de centralização; o ePBS incorpora a construção e validação ao quadro de regras do protocolo, reduzindo significativamente o espaço para manipulação de MEV. Além disso, o ePBS redesenha a estrutura de Slots, adicionando janelas de tempo específicas para construção e proposição de blocos na camada de execução, aumentando a margem de segurança para futuras melhorias no limite de gás.

Glamsterdam também fixou o limite de gás para a atualização em 200 milhões de unidades, e, combinando a otimização da estrutura de tempo do ePBS com a capacidade de verificação paralela do BAL (Access List em nível de bloco), os desenvolvedores têm uma base mais concreta para a escalabilidade da rede principal em 2026.

Marco de escalabilidade Fusaka e avanço na disponibilidade de dados

A atualização Fusaka foi ativada oficialmente em 3 de dezembro de 2025. Sua principal inovação foi a introdução do PeerDAS (EIP-7594), que embute a capacidade de amostragem de disponibilidade de dados na camada de protocolo. Ao permitir que os nós armazenem apenas uma parte dos blobs de dados, e não todos, PeerDAS teoricamente aumenta a capacidade de blobs em cerca de 8 vezes, além de fornecer maior espaço de disponibilidade de dados para as redes Layer2. Essa mudança reduz drasticamente os requisitos de hardware para operar nós — a largura de banda de blobs pode ser reduzida em até 80%.

Outro aspecto importante de Fusaka é estabelecer um ritmo de desenvolvimento de “duas hard forks por ano” — de Pectra (maio de 2025) a Fusaka (dezembro de 2025), com apenas 7 meses entre elas, marcando uma fase de aceleração no ciclo de desenvolvimento do Ethereum, que antes era mais lento e controlado por ciclos longos.

Por outro lado, Fusaka mantém seu foco principal na escalabilidade, deixando para futuras atualizações funções centrais de descentralização e resistência à censura, o que gerou debates internos na comunidade sobre a prioridade de escalabilidade versus segurança e governança.

Por que a mudança na atualização Hegotá para “limpeza e fortalecimento” ao invés de expansão

Hegotá, planejada para a segunda metade de 2026, marca uma mudança clara de foco — de uma rota de “Escalabilidade” para uma bifurcação de “limpeza e fortalecimento”. Funcionalidades como FOCIL (Fork-choice Inclusion Lists), contas abstratas (AA) e esquemas de assinatura alternativa foram realocadas para Hegotá.

A razão profunda dessa mudança é que, após Fusaka e Glamsterdam, a capacidade de escalabilidade do L1 do Ethereum superou amplamente a linha de base estabelecida em 2020 pelo roteiro centrado em Rollup. Vitalik afirmou que a baixa de taxas e o aumento contínuo do limite de gás fazem com que a “velocidade de expansão do layer base seja muito maior do que o esperado”. Nesse cenário, o valor do L2 é reavaliado — não mais como uma “fragmentação oficial” do Ethereum, mas como uma camada que deve oferecer capacidades diferenciadas que o L1 não consegue, como privacidade, baixa latência ou otimizações específicas para certos aplicativos, justificando sua existência.

A inclusão de FOCIL, uma funcionalidade chave para resistência à censura, em Hegotá, visa dar mais tempo aos desenvolvedores principais para aprimorar mecanismos de inclusão obrigatória de transações na camada base, uma infraestrutura invisível ao usuário, mas fundamental para a justiça do protocolo.

O papel do Based Rollup e do mecanismo de pré-confirmação na mudança de paradigma

Para enfrentar os problemas de centralização de ordenadores e interoperabilidade entre blockchains, o Based Rollup propõe uma abordagem alternativa: a autoridade de ordenação dos blocos do Rollup fica a cargo dos validadores do L1 do Ethereum, e não de ordenadores independentes do L2. Essa abordagem garante que o grau de descentralização do ordenamento seja herdado diretamente do nível de descentralização dos validadores do L1, eliminando a necessidade de mecanismos de ordenação descentralizados adicionais.

Por outro lado, o desafio dessa abordagem é a latência na confirmação final — após a ordenação, o blockchain precisa aguardar a geração e confirmação do bloco, o que ainda não é ideal para interações de baixa latência. Uma proposta da comunidade é combinar o mecanismo de pré-confirmação com o Based Rollup, visando fornecer sinais de confirmação forte em 15 a 30 segundos.

Além disso, a proposta de incluir precompilações nativas de Rollup também avança. Vitalik afirmou que a adoção completa de provas ZK no L1 do Ethereum e a inclusão de precompilações de Rollup estão se alinhando, o que ajudará a resolver a fragmentação de sistemas de provas customizadas, permitindo que diferentes Rollups acessem infraestrutura compartilhada para validação de provas, ao invés de construir suas próprias cadeias de auditoria de alto custo.

Próximos passos na evolução do roteiro do Ethereum após Glamsterdam e Hegotá

Após a implementação de Glamsterdam e Hegotá, o roteiro do Ethereum entrará em uma nova fase, chamada Strawmap. O Cluster de Protocolos da Fundação Ethereum já promove uma mudança de liderança, com foco em provas zkVM, coordenação de criptografia pós-quântica, desenvolvimento de zkEVM e garantias de segurança de trilhões de dólares na camada de protocolo.

O Strawmap deve seguir um ritmo de cerca de duas hard forks por ano, planejando sete bifurcações até 2029. Isso indica uma fase de desenvolvimento acelerado e regularizado, onde as atualizações não precisarão mais de longas discussões de propostas, mas poderão ser implementadas de forma ordenada, reduzindo riscos de projetos “de pacote único”.

Porém, é importante notar que algumas EIPs de Glamsterdam foram adiadas, como a EIP-8237, que foi movida para uma bifurcação futura. Além disso, a governança de cima para baixo na descentralização do L2 ainda não foi resolvida, e alguns L2 podem permanecer por longo tempo no Estágio 1, impulsionados por considerações comerciais. Isso mostra que, mesmo com melhorias técnicas no protocolo do L1, a descentralização do L2 ainda depende de um equilíbrio entre modelos de negócio e evolução do protocolo.

Resumo

A trajetória de upgrades do Ethereum em 2026 está em um ponto de inflexão claro: após três fases de melhorias no L1 — disponibilidade de dados (Fusaka), otimizações de throughput e governança de MEV (Glamsterdam e ePBS) — a capacidade de escalabilidade já ultrapassou significativamente o limite inicial definido pelo roteiro de 2020 centrado em Rollup. No entanto, o progresso na descentralização do L2 até o Estágio 2 “tem sido mais lento e mais difícil do que o esperado”. Centralização de ordenadores, atrasos na implementação de provas de fraude e validade, além da fragmentação de ponte multiassinatura, representam os três principais obstáculos. O lançamento do ePBS na devnet, a mudança de foco de Hegotá para “limpeza e fortalecimento”, e a discussão sobre Based Rollup com pré-confirmação indicam caminhos promissores para enfrentar esses desafios, com custos menores e maior interoperabilidade.

Por outro lado, a descentralização do L2 não é apenas uma questão técnica, mas uma tensão entre viabilidade técnica e incentivos econômicos. O Ethereum está adotando uma postura mais pragmática, reconhecendo a coexistência de diferentes estágios na ecologia, e promovendo a continuidade do progresso verificável do L1 com atualizações semestrais, mesmo que nem todos os L2 atinjam o Estágio 2 em curto prazo.

FAQ

Pergunta: Qual o estado atual do glamsterdam-devnet?

O glamsterdam-devnet-2 está ativo, com o protocolo ePBS em operação estável, e o fluxo de construtores externos já passou por testes ponta a ponta cobrindo quase todas as implementações de clientes.

Pergunta: Quais foram as realizações específicas do marco de escalabilidade Fusaka?

Fusaka foi ativada em 3 de dezembro de 2025, introduzindo o PeerDAS (EIP-7594), que permite amostragem de disponibilidade de dados, aumentando a capacidade de blobs em cerca de 8 vezes e reduzindo o consumo de banda dos nós em até 80%. O limite de gás do mainnet foi elevado para aproximadamente 60 milhões de unidades.

Pergunta: Por que Hegotá mudou de foco de expansão para “limpeza e fortalecimento”?

Porque, após Fusaka e Glamsterdam, a capacidade de escalabilidade do L1 do Ethereum superou as expectativas iniciais. Assim, Hegotá passou a priorizar funcionalidades como FOCIL para resistência à censura e contas abstratas, focando na segurança e na correção de problemas de protocolo, ao invés de expandir a capacidade.

Pergunta: O que são o Based Rollup e o mecanismo de pré-confirmação?

O Based Rollup transfere a autoridade de ordenação dos blocos para os validadores do L1 do Ethereum, eliminando a dependência de ordenadores independentes do L2. A combinação com mecanismos de pré-confirmação visa fornecer sinais de confirmação rápida em 15 a 30 segundos, ajudando a resolver centralização de ordenadores e problemas de sincronização entre Rollups.

Pergunta: Em que estágio a descentralização do Layer2 se encontra atualmente?

De acordo com o L2BEAT, os L2s estão classificados em: Estágio 0 (dependência total de controle centralizado), Estágio 1 (dependência limitada de governança por multiassinatura) e Estágio 2 (totalmente descentralizado, apenas com código e criptografia). Até o início de 2026, a maioria ainda está nos Estágios 0 ou 1, com progresso mais lento do que o esperado.