Atualização Glamsterdam, a solução de escalabilidade de camada 1 do Ethereum.

Original | Odaily Planet Daily jk

A próxima atualização Glamsterdam para Ethereum é considerada pelos desenvolvedores principais como a maior reestruturação em nível de protocolo desde a Fusão. O nome vem da combinação de duas partes: a atualização da camada de execução mantém "Amsterdam", nomeada em homenagem ao local dos eventos Devconnect anteriores; a atualização da camada de consenso é chamada de "Gloas", em referência a uma estrela. Seguindo a atualização Fusaka anterior, Glamsterdam aprimora a escalabilidade da camada 1 reorganizando a forma como a rede processa transações e gerencia seu banco de dados crescente, atualizando fundamentalmente a maneira como o Ethereum cria e verifica blocos.

Esta atualização gira em torno de três objetivos principais:

• Processamento acelerado (paralelização): Reorganização da forma como a rede registra as dependências de dados, permitindo o processamento seguro de um grande número de transações simultaneamente, em vez de processá-las lentamente, uma a uma.
• Escalabilidade: Dividir a carga de trabalho pesada de criação e verificação de blocos, dando à rede mais tempo para propagar maiores quantidades de dados sem perder velocidade.
• Sustentabilidade: Ajustar as tarifas de rede para refletir com precisão os custos de hardware a longo prazo para armazenamento de novos dados, removendo obstáculos para futuros aumentos nos limites de gás e evitando a degradação do desempenho do hardware.

As duas principais propostas da atualização estão focadas na camada de consenso e na camada de execução:

Existem duas propostas principais para o Headliner. Fonte: Ethereum

Proposta Principal Um: ePBS, Transformando "Intermediários Terceirizados" em "Regras Integradas"

Primeiramente, vamos discutir a proposta principal para a camada de consenso, que separa proponentes e construtores dentro do protocolo, abreviada em inglês como ePBS (EIP-7732).

Cada vez que o Ethereum produz um bloco, o processo envolve duas etapas: uma pessoa é responsável por "selecionar qual bloco" (o proponente) e outra é responsável por "montar as transações no bloco" (o construtor). Atualmente, essa divisão de trabalho não é especificada pelo próprio protocolo Ethereum, mas depende de um grupo de "empresas intermediárias" externas (comumente chamadas de relays) para facilitar o processo. Essa relação externa também cria um gargalo durante a verificação do bloco, forçando os validadores a concluir rapidamente a transmissão e a execução das transações em uma janela apertada de 2 segundos, limitando a quantidade de dados que a rede pode processar. Por exemplo, isso é semelhante a um restaurante onde os processos de pedido e preparo dependem de um intermediário externo independente para coordenar a entrega dos pratos; se esse intermediário falhar, a cozinha e o salão podem não estar sincronizados.

O que o ePBS faz é incorporar essa divisão de trabalho entre "pedido e preparo" no próprio manual de operações do restaurante, eliminando a necessidade de intermediários externos. Como resultado, um mecanismo confiável de entrega e pagamento on-chain é integrado diretamente ao protocolo, dispensando o uso de middleware de terceiros. No entanto, caso ambas as partes desejem utilizar funções complexas ainda não especificadas no protocolo, podem optar por recorrer a intermediários externos. Além disso, para evitar caos durante a fase de "entrega", o ePBS criou uma "equipe de verificação de pratos" para checar "quem fez o pedido" e "se o prato foi preparado a tempo", ampliando o prazo de entrega original de 2 segundos para cerca de 9 segundos. Isso permite que o restaurante processe mais pedidos simultaneamente, o que significa que o Ethereum pode acomodar mais dados destinados à Camada 2.

Proposta Principal Dois: BALs, Preparando uma "Lista de Compras" Antes da Partida

Em seguida, vamos discutir a proposta principal para a camada de execução, que é uma lista de acesso em nível de bloco, abreviada como BALs (EIP-7928).

Atualmente, a forma como o Ethereum processa transações é um tanto semelhante a uma pessoa fazendo compras em um supermercado de olhos fechados: primeiro, ela precisa apalpar o produto, confirmar o que é e, em seguida, decidir como proceder, o que a obriga a enfileirar um item por vez. Como o sistema não sabe antecipadamente quais dados uma transação utilizará, como, por exemplo, quais contas estão envolvidas, ele precisa processar as transações em ordem rigorosa; caso contrário, duas transações poderiam, inadvertidamente, tentar modificar os mesmos dados (como o saldo do mesmo endereço), causando conflitos.

As listas de acesso (BALs) permitem que o usuário obtenha uma lista de compras que indica claramente "quais prateleiras visitar e quais itens pegar" antes de sair de casa. Com essa lista, o sistema consegue prever quais transações não "entrarão em conflito", permitindo que transações não relacionadas sejam agrupadas e processadas em paralelo, em vez de serem enfileiradas uma a uma. Essa lista também oferece um benefício adicional: quando novos nós se juntam à rede, eles podem copiar diretamente os resultados finais registrados na lista, sem precisar recalcular todo o histórico complexo de transações, acelerando significativamente o processo de sincronização para novos nós. Para facilitar a circulação dessa lista na rede, a Glamsterdam também incluiu uma atualização correspondente no protocolo de transmissão, que permite que os nós compartilhem essas listas de acesso, o que agora se tornou um requisito obrigatório para todos os clientes da camada de execução.

Propostas de apoio: Reavaliação das operações de "ocupação de espaço"

Além dessas duas propostas principais, a Glamsterdam também apresentou duas propostas complementares para reajuste de preços, que podem ser entendidas como ajustes na tabela de preços das "taxas de armazenamento" e "taxas de consulta" da rede.

• A primeira proposta aborda operações como a criação de novas contas e a implementação de contratos que "ocuparão espaço permanentemente" na rede. Anteriormente, as taxas cobradas não eram proporcionais ao espaço efetivamente ocupado; agora, serão recalculadas com base na "cobrança por unidade de espaço ocupado", visando controlar a taxa de crescimento geral de dados da rede para um nível seguro e previsível de 120 GiB por ano, garantindo que a rede possa continuar operando em hardware comum. Além disso, essa taxa de armazenamento será contabilizada separadamente, não mais misturada com as taxas computacionais para processamento de transações. Contanto que os desenvolvedores estejam dispostos a pagar um pouco mais em taxas de armazenamento, eles ainda poderão implementar aplicações maiores e mais complexas sem serem imediatamente limitados pelo limite geral de Gas.
• A segunda proposta aborda operações como consulta e leitura de dados existentes na rede, que anteriormente tinham preços abaixo do mercado e não acompanhavam o aumento dos custos reais de consulta à medida que o volume de dados crescia. Desta vez, os padrões de preços para esses códigos de operação serão elevados para melhor refletir as condições reais de carga do hardware moderno, além de impedir que indivíduos explorem as baixas taxas para congestionar intencionalmente a rede com solicitações de consulta excessivas.

Data de lançamento da Mainnet: Ainda não definida

Em termos de cronograma, o Glamsterdam encontra-se atualmente em uma fase bastante delicada. Oficialmente, a reunião mais recente e verificável de todos os desenvolvedores principais da camada de execução (ACDE) foi a 241ª, realizada em 16 de julho, com a pauta principal incluindo atualizações sobre a fase Devnet do Glamsterdam e a seleção de propostas principais para a próxima atualização, Hegota. Um cronograma amplamente referenciado no setor indicava que a fase Devnet passou por oito iterações, de 0 a 7, abrangendo o período de 28 de março de 2026 a 8 de julho, seguida pelo fork da testnet Sepolia, originalmente agendado para 3 de agosto de 2026, e pelo fork da testnet Hoodi, originalmente agendado para 17 de agosto de 2026, com a data prevista para ativação da mainnet definida para 16 de setembro de 2026.

O cronograma original era para o primeiro semestre de 2026. Fonte: Ethereum

No entanto, com base nos últimos acontecimentos, é provável que esse cronograma tenha sido adiado. A equipe EthPandaOps lançou recentemente uma nova testnet chamada Plataberget, a primeira testnet pública de curto prazo projetada especificamente para a Glamsterdam. Espera-se que as implantações oficiais da Sepolia e da Hoodi sejam adiadas para setembro, e a meta para o lançamento da mainnet foi alterada para o quarto trimestre de 2026. Esta é a segunda vez que o cronograma da Glamsterdam sofre atrasos, após o adiamento anterior, originalmente planejado para o primeiro semestre de 2026. Os desenvolvedores principais têm enfatizado repetidamente que a correção da atualização tem prioridade sobre o cumprimento de qualquer data específica; portanto, até que a altura do bloco seja definida durante a reunião formal do ACD, podemos não ver essa atualização até o quarto trimestre ou mesmo o final do ano.