Problema dos blocos descartados no slot-0 do Ethereum tem solução?

O slot-31 é o último slot de cada epoch no Ethereum, um marco crítico que desencadeia a troca de comitês, o reshuffle do RANDAO e a finalização dos checkpoints. Por proteção implícita da regra de fork choice, ele raramente é reorgado. Mas seu comportamento direto influencia o slot-0: como o slot-31 é ‘seguro’, os operadores não pressionam tanto a latência ali, e isso empurra a carga computacional e de propagação para o slot-0, onde a rede está mais congestionada e menos tolerante. O problema não é o slot-31 em si, mas como sua estabilidade cria um pico artificial de demanda logo depois dele.

Os dados mostram que 97% dos blocos orphaned no slot-0 foram construídos sobre um slot-31 pai visto em média 1,7s após o início do slot, ou seja, o problema não vem de falha no slot-31, mas de uma cascata de decisões de construção no limite: relays falhando na transição de epoch, builders locais sobrecarregados tentando empacotar até 21 blobs sem ajuste de prioridade, e operadores como a Upbit (responsável por 18% dos descartes) mantendo configurações fixas mesmo com a taxa subindo de 0,58% em 2024 para 1,73% em 2026.

A cobertura CEVIU anterior não tratava do slot-0 ou de reorgs em epoch boundaries. A novidade real aqui é técnica e operacional: pela primeira vez, dados de 21 meses confirmam que o problema não é estrutural, nem um ‘custo inevitável’ da transição de epoch , , mas concentrado em três vetores corrigíveis: (1) fallback local de construção lento em operadores específicos; (2) excesso de blobs em blocos construídos localmente; (3) prazo de atestação ainda muito frouxo para o pico de carga. Isso muda o diagnóstico: antes, discutia-se se o custo era inerente ao protocolo; agora, sabemos que é um gargalo de produção com causa identificável e endereçável via EIP-7872 (max-blobs para fallback) e ajuste do deadline para ~3s no Glamsterdam.

Porque o deadline de atestação define quanto tempo sobra para propagação de payloads maiores, e isso limita diretamente o aumento seguro do gas limit e do número de blobs por slot. Se o Glamsterdam quiser escalar para 200M de gas e mais blobs, não pode deixar o slot-0 ditar o ritmo. Um deadline mal calibrado não só gera reorgs pontuais: trava a evolução da camada de execução. E o fato de 18% dos descartes virem de uma única exchange mostra que a solução depende menos de mudanças de consenso e mais de engenharia operacional compartilhada entre grandes staking providers e builders.