Ethereum Layer2 descentralizado não atende às expectativas: O que significa a declaração de Vitalik por trás disso?

Em maio de 2026, a Fundação Ethereum concluiu uma semana de Soldøgn Interop na Ilha de Svalbard, Noruega, encerrando oficialmente uma colaboração de mais de cem desenvolvedores centrais focada na atualização de Glamsterdam e na sua robustez. Esta reunião não só atingiu os objetivos técnicos centrais de Glamsterdam, como também confirmou uma mudança de direção na atualização Hegotá — de uma rota de escalabilidade para uma de “limpeza e reforço” do débito técnico, desviando-se da rota original 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 roadmap centrada em Rollups, o ritmo de avanço da descentralização Layer2 “é muito mais lento do que o esperado”. Esta 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 da descentralização Layer2 do Ethereum frequentemente fica aquém das expectativas

Em fevereiro de 2026, Vitalik declarou publicamente que a roadmap 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 baseia-se em dois fatos: primeiro, que o avanço da descentralização em estágios superiores do L2 “é muito mais lento e difícil do que o previsto”; segundo, que a capacidade de expansão do próprio L1 do Ethereum superou significativamente as previsões iniciais.

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

Este atraso, maior do que o esperado, tem causas técnicas e econômicas. Algumas equipes de L2 afirmam que, devido a restrições regulatórias ou modelos de negócio, talvez nunca busquem uma descentralização completa. A receita dos ordenadores (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 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 L2 depende de um único ordenador centralizado para empacotar e ordenar transações, uma solução eficiente e de baixo custo, mas que apresenta vulnerabilidades à censura e risco de ponto único de falha. O ordenador controla a ordem das transações, podendo extrair valor máximo (MEV) e exercer potencial capacidade de censura — o que contraria os princípios de descentralização do próprio Ethereum.

Segundo, a demora na implementação de provas de fraude e de validade. Rollups Otimistas dependem de janelas de desafio de cerca de 7 dias, obrigando os usuários a confiar por longos períodos nos operadores de L2. ZK Rollups teoricamente oferecem finalização instantânea, mas a geração de provas de validade exige circuitos altamente customizados e auditorias complexas, além de que cada hard fork do Ethereum que altera o comportamento do EVM requer atualizações sincronizadas nos sistemas de prova de cada L2, aumentando 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 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, agravando a fragmentação de liquidez. A maioria das conexões entre L2 e L1 depende de pontes multiassinatura — contratos que controlam transferências 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 expande verdadeiramente o Ethereum, mas cria uma plataforma independente baseada em confiança. O uso generalizado de pontes multiassinatura indica que muitos Rollups não herdaram a segurança do Ethereum, dependendo de controle centralizado para operar.

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

O lançamento do devnet Glamsterdam representa um marco importante na roadmap 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 entre o direito de construir blocos e o de propor, 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 dentro das 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 claras para a construção e proposição de blocos na camada de execução, oferecendo maior margem de segurança para futuras melhorias no limite de gás.

Glamsterdam também fixou o limite inferior e superior de gás após 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 a nível de bloco), os desenvolvedores têm uma base mais concreta para a escalabilidade da mainnet em 2026.

Marco de expansão 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 incorpora a amostragem de disponibilidade de dados na camada de protocolo. Permitindo que os nós armazenem apenas uma parte dos blobs de dados, em vez de todos, PeerDAS teoricamente aumenta a capacidade de blobs em cerca de 8 vezes, fornecendo maior espaço de dados para redes Layer2. Essa mudança reduz drasticamente os requisitos de hardware para operar nós — a largura de banda de blobs pode cair 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 desenvolvimento mais acelerada, saindo de ciclos longos para atualizações mais frequentes.

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

Por que a atualização Hegotá mudou o foco para “limpeza e reforço” ao invés de continuar expandindo

Hegotá, prevista para a segunda metade de 2026, marca uma mudança clara de foco — de uma rota de “Escalabilidade” para uma de “limpeza e reforço” (cleanup and hardening). Funcionalidades como FOCIL (Fork-choice Inclusion Lists), contas abstratas (AA) e assinaturas alternativas foram transferidas para o escopo de Hegotá.

A razão profunda é que, após Fusaka e Glamsterdam, a capacidade de expansão do L1 do Ethereum superou amplamente as expectativas de 2020, quando a roadmap de escalabilidade centrada em Rollups foi traçada. Vitalik aponta 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 “supere as previsões”. 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 que o L1 não consegue, como privacidade, baixa latência e otimizações específicas, justificando sua existência.

A inclusão de FOCIL, uma funcionalidade chave para resistência à censura, em Hegotá, visa dar mais tempo aos desenvolvedores 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.

Será que o Based Rollup e o mecanismo de pré-confirmação podem ser a solução?

Para enfrentar os problemas de centralização de ordenadores e interoperabilidade entre blockchains, o Based Rollup propõe uma abordagem alternativa: a ordenação dos blocos pelo validador do L1 do Ethereum, e não por um ordenador independente no L2. Essa estratégia garante que o grau de descentralização da ordenação seja herdado do nível de descentralização dos validadores do L1, eliminando a necessidade de um mecanismo de ordenação separado.

Por outro lado, o desafio é 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 pode não ser ideal para interações de baixa latência. Uma proposta é combinar o mecanismo de pré-confirmação com o Based Rollup, visando fornecer sinais de confirmação confiáveis em 15 a 30 segundos.

Além disso, a proposta de incluir precompilações nativas para Rollups também avança. Vitalik afirma que a adoção total de provas ZK no L1 do Ethereum e a integração de precompilações de Rollup estão se alinhando, o que permitirá que diferentes Rollups acessem infraestrutura compartilhada para validação de provas, eliminando a necessidade de construir sistemas de auditoria caros individualmente.

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

Após Glamsterdam e Hegotá, o roadmap do Ethereum entrará em uma nova fase, chamada Strawmap. O Cluster de Protocolos da Fundação Ethereum já promoveu mudanças na liderança, com foco em provas zkVM, coordenação pós-quântica, desenvolvimento de zkEVM e segurança de nível trilhão de dólares na camada de protocolo.

O Strawmap deve seguir uma rotina de cerca de duas hard forks por ano, planejando sete até 2029. Assim, o ritmo de desenvolvimento do Ethereum se tornará mais regular e acelerado, com atualizações mais controladas, evitando riscos de grandes mudanças de uma só vez.

Porém, é importante notar que alguns EIPs do Glamsterdam foram adiados, como o EIP-8237, que foi transferido para uma futura atualização. Além disso, a governança de alto nível para a descentralização do L2 ainda não está resolvida, e alguns L2 podem permanecer por longo tempo na fase 1, dependendo de considerações comerciais. Isso mostra que, mesmo com melhorias técnicas na camada de protocolo, 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 encontra-se em um ponto de inflexão claro: após três fases de melhorias na capacidade do L1 — com Fusaka (dados), Glamsterdam (throughput e MEV) e o protocolo ePBS — a capacidade de escalabilidade do Ethereum superou significativamente o limite inicial traçado em 2020 na roadmap centrada em Rollups. Contudo, o progresso na descentralização do L2 até o estágio 2 “é 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 liquidez via pontes multiassinatura, representam os três maiores obstáculos. O lançamento do devnet Glamsterdam com ePBS, a mudança de foco de Hegotá para “limpeza e reforço”, e a discussão sobre Based Rollup com pré-confirmação indicam caminhos promissores, com menor custo de interoperabilidade e maior segurança.

Porém, a descentralização do L2 não é apenas uma questão técnica, mas também de viabilidade econômica e incentivos. O Ethereum está adotando uma postura mais pragmática, reconhecendo a coexistência de diferentes estágios na comunidade, e promovendo avanços verificáveis na camada base 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 funcionando de forma estável, e os testes ponta a ponta entre diferentes clientes já cobrem quase todas as implementações.

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

Fusaka foi ativada em 3 de dezembro de 2025, introduzindo PeerDAS (EIP-7594), que aumenta a capacidade de dados disponíveis em cerca de 8 vezes e reduz o consumo de banda dos nós, elevando o limite de gás da mainnet para aproximadamente 60 milhões de unidades.

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

Porque, após Fusaka e Glamsterdam, a capacidade de expansão do L1 do Ethereum superou as expectativas iniciais. Assim, Hegotá prioriza melhorias na resistência à censura, contas abstratas e outras funções de reforço de protocolo, voltadas para segurança e descentralização.

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

Based Rollup transfere a ordenação dos blocos para os validadores do L1, eliminando a dependência de ordenadores independentes no L2. A combinação com mecanismos de pré-confirmação visa fornecer confirmações rápidas em 15 a 30 segundos, melhorando a sincronização e segurança.

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

Segundo o L2BEAT, os L2 estão classificados em: Stage 0 (dependência total de controle centralizado), Stage 1 (dependência limitada de governança multiassinatura) e Stage 2 (totalmente descentralizado, com garantia por código e criptografia). Até o início de 2026, a maioria permanece em Stage 0 ou 1, com progresso abaixo do esperado.