Engenheiro da Lido alerta para risco de sequestro de depósito durante a transição Glamsterdam do ethereum

2026/10/21 14:09:00

Por que os desenvolvedores do Ethereum rejeitaram a correção ao nível do protocolo

A próxima grande atualização da rede Ethereum visa escalar a camada base por meio da separação consagrada entre proponente e construtor e limites de gás mais altos, mas uma vulnerabilidade específica no tempo atraiu nova atenção de um dos maiores provedores de staking líquido. Em 20 de outubro de 2026, Dima Gusakov, Chefe de Engenharia da Lido Finance, detalhou publicamente como a transição para Glamsterdam poderia permitir que um operador de node malicioso antecipasse o depósito do validador de um staker. O ataque usaria depósitos de construtor com credenciais de retirada prefixadas por 0xB0 que compartilham temporariamente a fila de depósito, potencialmente creditando o ETH em uma conta de construtor em vez de ativar o validador pretendido. A janela é limitada à própria transição do hard-fork. Após a atualização, os depósitos de construtor passam para um caminho de contrato separado.

Uma proposta de correção ao nível do protocolo nas especificações de consenso foi encerrada como “não planejada”, transferindo a carga defensiva para os protocolos de staking. Este artigo examina os mecanismos técnicos do risco, as escolhas de design da atualização que criaram a sobreposição temporária, as razões pelas quais os desenvolvedores principais recusaram um patch do protocolo, os passos práticos que os provedores de staking líquido devem tomar, o cronograma da testnet que dá aos operadores apenas alguns dias para se preparar e as lições mais amplas para a segurança do staking delegado à medida que o Ethereum avança em sua rota de escalonamento. A análise baseia-se exclusivamente em relatos e declarações primárias dos últimos 30 dias, concentrando-se em detalhes verificados em vez de especulações.

Líder de Engenharia do Lido detalha o vetor de front-running no X e em reuniões de desenvolvedores

Dima Gusakov emitiu o aviso em 20 de outubro de 2026, dirigindo-se diretamente aos protocolos de staking e aos stakers delegados. Ele explicou que um operador de node poderia enviar um depósito de builder usando a mesma chave pública antes que a transação de depósito do validador legítimo seja confirmada. Como Glamsterdam introduz depósitos de builder que dependem de credenciais de retirada prefixadas com 0xB0, e como esses depósitos compartilham a fila de depósitos de validador durante a transição, o primeiro depósito válido pode reivindicar os fundos. O resultado é que o validador do staker nunca aparece na beacon chain, enquanto os ETH são creditados na conta de builder do atacante. Gusakov enfatizou que o ataque é possível apenas no momento do hard fork. Antes do Glamsterdam, os depósitos de builder passam pela fila existente de depósitos de validador; após isso, eles são roteados por um contrato dedicado. Ele observou que a duração limitada torna a mitigação viável para protocolos preparados.

A mesma preocupação surgiu na chamada All Core Devs Consensus (ACDC #189). Gusakov destacou que o mecanismo de integração única de construtores do Glamsterdam pode interferir nos padrões de proteção de depósitos nos quais os protocolos de staking confiaram por muito tempo. Sob as regras atuais, o primeiro depósito válido para uma chave pública define permanentemente as credenciais de retirada. Os protocolos frequentemente depositam uma pequena quantia inicialmente, confirmam se as credenciais esperadas aparecem e só então completam o saldo restante. Durante a transição do fork, o caminho especial de integração pode produzir um terceiro resultado: nenhum validador é ativado, e o depósito completo é atribuído a um construtor. Os desenvolvedores principais recusaram uma alteração tardia na especificação que preservaria a distinção entre depósitos de validador e construtor durante a integração única, citando o fato de que o Sepolia já havia sido ativado sob as regras existentes e as versões do cliente Hoodi já estavam em preparação. Alterar o comportamento nessa fase exigiria a reimplantação do Sepolia e ciclos adicionais de teste.

Como as credenciais do construtor 0xB0 interagem com a fila compartilhada de depósitos

Glamsterdam introduz depósitos de construtores como parte da transição para a separação consagrada entre proponente e construtor. Esses depósitos possuem credenciais de retirada que começam com o prefixo 0xB0, diferenciando-se das credenciais comuns de validador. Durante o período de transição, os dois tipos de depósitos compartilham o mesmo caminho de processamento na fila. Um operador de nó que controla ou pode influenciar a ordem de submissão de depósitos pode, portanto, inserir um depósito com credencial de construtor que corresponda a uma chave pública de staker pendente. Uma vez que o primeiro depósito seja aceito, a rede trata a chave pública como reivindicada sob as credenciais do construtor. Depósitos subsequentes sob a mesma chave são ignorados para ativação de validador ou redirecionados de acordo com as novas regras de interpretação aplicáveis ao redor do limite do fork.

O efeito prático é que o staker perde tanto o validador esperado quanto o ETH depositado, que agora está sob o controle do construtor. Validadores ativos existentes e depósitos já processados permanecem inalterados. O risco está limitado a depósitos novos ou ainda na fila que cruzam o epoch de ativação. Como o comportamento da fila compartilhada termina assim que o fork é concluído e os depósitos do construtor são movidos para seu contrato dedicado, a exposição é temporária. Esse caráter temporário é a razão central pela qual Gusakov aconselhou contra o pânico, enquanto ainda incentivava todos os serviços de staking delegado a implementar ou fortalecer a verificação pré-depósito antes da ativação no mainnet.

Desenvolvedores principais fecham a proposta de especificações de consenso como não planejada

A discussão técnica de um remédio ao nível do protocolo apareceu no issue #5735 dos consensus-specs. A proposta solicitava verificações pré-depósito que validariam certas condições antes de aceitar um depósito na fila. Após análise, o issue foi fechado com o status “não planejado”. A decisão deixa a responsabilidade defensiva na camada de aplicação, em vez de incorporar verificações adicionais no protocolo principal. A orientação pública de Gusakov, portanto, concentra-se nos protocolos de staking realizarem sua própria validação pré-depósito. Restrições de tempo influenciaram fortemente o resultado. O Sepolia já havia feito fork sob a especificação existente em 6 de outubro de 2026.

As versões do cliente Hoodi estavam avançando em direção à ativação em 26 de outubro. Introduzir uma alteração comportamental tardia corria o risco de forçar uma nova implantação na Sepolia e novos atrasos nos testes. Os desenvolvedores principais consideraram que a janela limitada e a capacidade das equipes da camada de aplicação de adicionar verificações tornavam um patch de protocolo desnecessário nesta fase. O resultado é um modelo de segurança distribuída no qual cada provedor de staking líquido deve confirmar que sua pipeline de depósito distingue corretamente ou bloqueia depósitos prefixados com 0xB0 que tentam reivindicar chaves públicas de validadores.

Verificações pré-depósito tornam-se a principal defesa para serviços de staking líquido

O Lido próprio opera um Módulo de Segurança de Depósito e um comitê de guardiões desde que vulnerabilidades relacionadas a depósitos surgiram anos atrás. Os guardiões revisam instantâneos do root de depósito antes que os lotes prossigam, e um único guardião honesto pode pausar depósitos. A questão em aberto é se essa infraestrutura existente já considera o novo tipo de credencial 0xB0 e a dinâmica temporária da fila compartilhada, ou se lógica adicional é necessária para a transição do Glamsterdam. Outros protocolos que não possuem supervisão multipartidária comparável enfrentam uma tarefa de preparação mais complexa.

As verificações pré-depósito podem assumir várias formas concretas. Um protocolo pode recusar qualquer depósito cujas credenciais de retirada comecem com 0xB0 quando a intenção for a ativação padrão de validador. Pode exigir uma atestação on-chain ou off-chain de que a chave pública ainda não foi reivindicada sob credenciais de construtor. Pode pausar novos depósitos por um curto período em torno da época de ativação até o fim do período de fila compartilhada. Como a superfície de ataque existe apenas enquanto as filas se sobrepõem, uma pausa temporária ou um escrutínio aprimorado durante esse intervalo pode eliminar a maioria das exposições práticas. Serviços de staking menores ou mais novos que ainda não construíram comitês do tipo guardião precisarão agir rapidamente se pretendem aceitar depósitos durante a transição para o mainnet.

Agenda de ativação do Glamsterdam deixa pouca margem para preparação

A Ethereum Foundation confirmou que Glamsterdam será ativado na testnet Hoodi na epoch 132.352, slot 4.235.264, correspondente a 26 de outubro de 2026, às 17:42:48 UTC. Na mesma epoch, o limite de gás da Hoodi aumenta para 200 milhões. Sepolia já foi ativada em 6 de outubro. O cronograma para o mainnet ainda não foi definido, com datas candidatas no início de dezembro em discussão, condicionadas a um fork limpo da Hoodi. Operadores de nós e equipes de staking têm, portanto, apenas alguns dias após o aviso de Gusakov para validar seus pipelines de depósito na Hoodi.

As equipes de clientes publicaram versões compatíveis para ambas as camadas de consenso e execução. Os operadores devem atualizar tanto os nós de beacon quanto o cliente de validador, revisar quaisquer alterações nas interfaces de builder introduzidas pela separação de proposer-builder enraizada e confirmar que a lógica de submissão de depósitos lida corretamente com o novo prefixo de credenciais. O curto intervalo entre o aviso público e a primeira ativação pública do testnet sublinha por que as defesas da camada de aplicação precisam estar prontas antes da janela de transição para o mainnet abrir.

Separação Consagrada entre Propositores e Construtores Introduz a Nova Via de Depósito

Glamsterdam combina as alterações da camada de execução de Amsterdam com as alterações da camada de consenso Gloas. Suas duas principais funcionalidades são a separação consagrada de proponente e construtor (EIP-7732) e listas de acesso em nível de bloco. Sob ePBS, os construtores se registram on-chain com seus próprios saldos e chaves públicas, enviam lances e posteriormente revelam cargas de execução. O próprio protocolo realiza o pagamento ao proponente, reduzindo a dependência de relés externos. Os depósitos e saídas dos construtores tornam-se solicitações de execução de primeira classe, o que explica a sobreposição do prefixo de credencial 0xB0 e da fila temporária.

O design melhora a escalabilidade ao dar aos validadores mais tempo para processar cargas maiores e ao permitir limites de gás mais altos. Ao mesmo tempo, ele cria um novo caminho de integração para construtores que deve ser cuidadosamente distinguido dos depósitos normais de validadores. A mecânica de transição única é a fonte da ambiguidade temporária. Uma vez que a rede tenha sido totalmente migrada, os depósitos de construtores percorrem seu próprio contrato, e o risco da fila compartilhada desaparece. Portanto, a atualização melhora a arquitetura de longo prazo, exigindo vigilância de curto prazo de qualquer serviço que envie depósitos em nome dos usuários.

A experiência anterior de segurança de depósito da Lido informa a resposta atual

O Lido enfrentou riscos de front-running de depósitos nos últimos anos e respondeu formalizando o Módulo de Segurança de Depósito junto com um comitê guardião. O comitê aprova instantâneos do root de depósito; um único guardião pode acionar uma pausa. Essa infraestrutura já se mostrou útil em outros incidentes operacionais. O caso Glamsterdam testa se os mesmos controles reconhecem corretamente o novo tipo de credencial e o breve período de compartilhamento de fila.

Protocolos que adotaram padrões semelhantes de assinatura múltipla ou guardiães após incidentes anteriores estão melhor posicionados do que aqueles que ainda não implementaram salvaguardas comparáveis. O padrão mais amplo é familiar: atualizações de protocolo podem revelar casos extremos que sistemas de camada de aplicação devem absorver. Como os desenvolvedores principais rejeitaram uma alteração tardia na especificação, a indústria deve tratar a validação pré-depósito como um requisito contínuo, e não como um aprimoramento opcional. Equipes que já monitoram raízes de depósito e podem pausar rapidamente enfrentarão menor risco operacional durante a transição.

Operadores de node e stakers delegados enfrentam exposição concentrada durante a janela

O ataque exige um operador de node malicioso ou comprometido que possa enviar uma transação de depósito que seja incluída antes da legítima. Stakers comuns que simplesmente depositam em um protocolo de staking líquido não conseguem executar o front-run por si mesmos; o risco reside no operador que assina ou envia finalmente o depósito na cadeia. Validadores já ativados e depósitos já confirmados permanecem fora da superfície de ataque. Apenas chaves públicas que ainda tenham depósitos pendentes ou recém-enviados durante o epoch de transição estão expostas.

Os stakers delegados devem, portanto, confirmar que seu protocolo escolhido publicou orientações sobre o manejo de depósitos em torno da ativação do Glamsterdam. Os operadores devem auditar cuidadosamente a ordem de envio, limitar a taxa ou sequenciar depósitos, e verificar que nenhum depósito prefixado com 0xB0 possa reivindicar uma chave destinada a um validador padrão. Como a janela é curta, uma redução temporária no throughput de novos depósitos ou uma postura de monitoramento aumentada pode fechar a maioria das rotas de ataque práticas sem interrupção de longo prazo nas operações de staking.

Hoodi oferece o primeiro ambiente ao vivo para teste do pipeline de depósito

A ativação do Hoodi em 26 de outubro é a primeira oportunidade pública para equipes de staking observarem o comportamento da fila compartilhada em condições realistas. Os protocolos podem enviar depósitos de teste com credenciais comuns e 0xB0, medir os resultados de ordenação e confirmar que seus filtros pré-depósito rejeitam ou isolam o caminho indesejado. As equipes de clientes já lançaram versões compatíveis com Hoodi; os operadores devem garantir que ambos os clientes de execução e consenso estejam atualizados e que todas as ferramentas externas de builder tenham sido revisadas para as novas interfaces.

A testagem bem-sucedida no Hoodi dará à indústria maior confiança antes da abertura da janela do mainnet. Falhas ou casos limite inesperados descobertos no testnet ainda podem ser resolvidas com alterações na camada de aplicação ou pausas curtas, sem exigir um redesenho do protocolo. O curto intervalo entre o aviso público e a ativação do Hoodi torna essencial a testagem coordenada.

A responsabilidade pela mitigação agora recai sobre cada protocolo de staking

Ao fechar a issue dos consensus-specs como não planejada, os desenvolvedores principais sinalizaram que o risco temporário é melhor gerenciado na camada de aplicação. Provedores de liquid staking, plataformas de operadores individuais e qualquer serviço que envie depósitos em nome dos usuários devem, portanto, implementar suas próprias verificações. Provedores que já mantêm comitês de guardiões ou processos de atestação de root de depósito podem estender esses processos para cobrir o prefixo 0xB0. Provedores sem tal infraestrutura enfrentam um prazo mais apertado para adicionar controles equivalentes.

O modelo distribuído possui vantagens e desvantagens. Ele permite respostas rápidas e personalizadas sem precisar aguardar uma mudança de fork na rede inteira. Também significa que a segurança do depósito de qualquer staker depende das práticas específicas do protocolo escolhido por eles. A transparência sobre os procedimentos de manipulação de depósitos em torno do epoch de ativação ajudará os usuários a avaliar o risco residual.

Metas de escalonamento e casos extremos temporários permanecem ligados nas atualizações do ethereum

Glamsterdam avança a rota de escala L1 do ethereum aumentando o limite prático de gás em direção a 200 milhões, permitindo o processamento paralelo de transações por meio de listas de acesso em nível de bloco e removendo relés externos do caminho crítico da produção de blocos. Esses ganhos exigem novas primitivas on-chain para construtores, o que, por sua vez, cria a sobreposição temporária da fila de depósito. O padrão é característico de grandes atualizações: melhorias arquiteturais de longo prazo podem revelar casos extremos de curta duração que as equipes de aplicativos devem gerenciar.

A capacidade do setor de absorver esses casos extremos sem perdas de fundos dos usuários influenciará a confiança em atualizações subsequentes. A validação pré-depósito, a pausa temporária nos depósitos e a comunicação clara do operador são as ferramentas práticas disponíveis neste caso. Como o risco está confinado a um intervalo conhecido e curto, o custo da preparação é finito, e o benefício é a preservação dos depósitos dos usuários durante a transição.

Depósitos pendentes exigem monitoramento reforçado até a conclusão da transição

Qualquer chave pública que ainda tenha um depósito não processado no momento em que as regras do Glamsterdam forem ativadas está dentro da janela de ataque potencial. Os protocolos podem mitigar isso esvaziando ou acelerando suas filas de depósitos antes da época, rejeitando credenciais 0xB0 para intenções de validador ou pausando novas submissões por um breve período ao redor da ativação. O monitoramento contínuo das alterações no root de depósito e do status de reivindicação de chave pública durante as horas críticas permitirá uma resposta rápida caso atividades anômalas apareçam.

Uma vez que o fork for concluído e os depósitos do builder se movam para seu caminho de contrato separado, o vetor da fila compartilhada é fechado. A carga de monitoramento tem, portanto, uma data final clara. As equipes que tratam a transição como um período operacional de alta atenção, em vez de uma atualização rotineira, estarão melhor posicionadas para proteger os fundos dos stakers.

🔥 Além das manchetes: O que o KuCoin 5.0 significa para você

As notícias do mercado se movem rápido — mas onde você atua sobre elas importa tanto quanto. Este outono, a KuCoin lança a KuCoin 5.0, transformando a KuCoin em uma plataforma reconstruída. Aqui está o que realmente muda para você:

Uma conta para tudo. Plataformas antigas dividiam seu dinheiro entre contas separadas de "spot", "margin" e "futures" e esperavam que você entendesse por quê. A Conta Unificada do KuCoin 5.0 elimina isso completamente — faça um único depósito e tudo estará simplesmente disponível (apenas disponível para VIPs por enquanto).
Ações, índices e commodities. O KuCoin 5.0 se expande além do cripto para mercados globais. Quando o cripto flutua lateralmente e os ativos de renda variável sobem (ou o contrário), você faz a rotação em minutos, em vez de abrir uma conta na corretora e esperar dias pelas vias de moeda fiduciária.
Ativos do mundo real (RWA). Exposição tokenizada a ativos tradicionais, como commodities, diretamente na sua conta de cripto. Um dos segmentos de mais rápido crescimento na finança global já não é mais reservado para instituições — você acessa-o a partir do mesmo saldo que utiliza para negociar.
Ganhe enquanto aprende. Não está pronto para negociar? KCUSD permite que suas stablecoins ganhem juros diários com composição automática. A forma menos estressante de colocar seu depósito ocioso para trabalhar, com rendimento de 4%.
Um assistente de IA em linguagem simples. Faça perguntas, obtenha contexto de mercado, entenda o que está vendo — integrado à plataforma, sem necessidade de jargões.
Um aplicativo que não sobrecarrega. Mais rápido, mais limpo e consistente — intuitivo desde o primeiro toque, não após um tutorial.
Segurança que você pode verificar, não apenas confiar. Uma entidade da UE com licença MiCAR, Proof of Reserves que você pode verificar por conta própria, e segurança certificada internacionalmente (SOC 2 Type II, ISO 27001:2022).

Crie sua conta em minutos — e comece na plataforma construída para onde o cripto está indo, não para onde já esteve.

Perguntas frequentes

O que exatamente é a atualização Glamsterdam e por que ela é importante para o staking?

Glamsterdam é o nome combinado para as alterações da camada de execução de Amsterdam e da camada de consenso Gloas. Seus principais objetivos são a separação consagrada entre proponente e construtor e listas de acesso em nível de bloco que suportam limites de gás mais altos e processamento de bloco mais eficiente. Para staking, a introdução do registro de construtor on-chain e a via de depósito associada criam o comportamento temporário de compartilhamento de fila que fundamenta o risco de front-running.

Por quanto tempo dura a janela de sequestro de depósito?

A janela existe apenas enquanto os depósitos do builder ainda estiverem passando pela fila de depósitos do validador. Essa condição se mantém durante a própria transição do hard-fork. Após a conclusão da atualização, os depósitos do builder são processados por um contrato separado, encerrando o caminho da fila compartilhada. A duração prática é, portanto, medida nas horas em torno do epoch de ativação, e não em dias ou semanas.

O risco afeta validadores já ativados ou ETH já apostada?

Não. O ataque visa depósitos novos ou ainda em fila para chaves públicas que ainda não produziram um validador ativo. Validadores existentes e seus saldos permanecem sob suas credenciais de retirada estabelecidas e estão fora da superfície de ataque descrita.

O que os stakers comuns podem fazer para se proteger?

Stakers que depositarem por meio de um protocolo de staking líquido devem confirmar que o protocolo publicou orientações específicas sobre o tratamento de depósitos em torno da ativação do Glamsterdam. Escolher um provedor que já opera segurança de depósito em múltiplas partes ou supervisão do tipo guardian reduz o risco residual. Stakers que executam seus próprios validadores devem garantir que sua lógica de envio de depósito não permita que um depósito competidor 0xB0 reivindique a mesma chave pública.

Por que os desenvolvedores principais rejeitaram uma correção ao nível do protocolo?

A proposta para verificações pré-depósito foi encerrada como não planejada, principalmente devido à pressão de cronograma. O Sepolia já havia sido ativado sob as regras existentes, e as versões do cliente Hoodi estavam avançando. Uma alteração comportamental tardia teria arriscado novas implantações e atrasos adicionais na testnet. Os desenvolvedores consideraram que as mitigações na camada de aplicação eram suficientes, dado o curto período de exposição.

Disclaimer: Este conteúdo é apenas para fins informativos e não constitui aconselhamento financeiro. Investimentos em criptomoedas envolvem risco. Faça sua própria pesquisa (DYOR).

Aviso legal: Esta página foi traduzida usando tecnologia de IA para sua conveniência. Para informações mais precisas, consulte a versão original em inglês.