Na noite de segunda-feira, uma alteração de uma única linha no EIP-7928 foi incorporada, e a história por trás dessa linha é uma boa demonstração de como as duas camadas de clientes do Ethereum dependem uma da outra. O EIP-7928 adiciona listas de acesso em nível de bloco ao Glamsterdam. Uma BAL registra quais contas e slots de armazenamento um bloco toca, além das alterações de estado após cada transação, permitindo que os clientes leiam e validem em paralelo. A regra original dizia que os clientes de execução precisavam manter as BALs por apenas 3.533 épocas, cerca de 16 dias. Essa é a janela de subjetividade fraca, e para a camada de execução isso é mais que suficiente. Um desenvolvedor de cliente de execução fez o ponto justo na PR de que um node pode validar um bloco sem nenhuma BAL. O problema estava no lado de consenso. Alguns clientes de consenso não armazenam cargas completas. Eles mantêm uma versão "cega" e, quando um par pede o bloco, eles chamam engine_getPayloadBodiesBy*V2 no cliente de execução para preencher o restante. Isso funciona para transações e saques, porque os clientes de execução mantêm os corpos dos blocos por 14.299 épocas. No entanto, sob Gloas, a BAL também faz parte da carga de execução. Assim, após 16 dias, o cliente de execução retornaria nulo para a BAL, e o cliente de consenso não conseguiria mais reconstruir uma carga que ainda é esperado servir. Sua única opção seria começar a armazenar as BALs por conta própria, o que significa que os mesmos dados estariam duplicados no disco. A correção faz com que a retenção da BAL siga a janela do corpo do bloco: 14.299 épocas, um pouco mais de dois meses. Não é gratuito. Usando o tamanho típico da BAL de cerca de 70 KiB citado nessa discussão, minha estimativa aproximada é de cerca de 30 GiB de BALs por node, aumentando de cerca de 7,5 GiB. Nada sobre a segurança do consenso mudou aqui. Duas camadas simplesmente tinham ideias diferentes sobre o que significava "manter isso disponível".