Pazartesi gece, EIP-7928'e tek bir satırlık bir değişiklik entegre edildi ve bu satırın ardındaki hikaye, Ethereum'un iki istemci katmanının birbirine nasıl bağımlı olduğunu gösteren güzel bir örnektir. EIP-7928, Glamsterdam'a blok seviyesinde erişim listeleri ekler. Bir BAL, bir bloğun hangi hesapları ve depolama alanlarını etkilediğini ve her işlem sonrası durum değişimlerini kaydeder; böylece istemciler paralel olarak okuyup doğrulayabilir. Orijinal kural, yürütme istemcilerinin yalnızca 3.533 epoch, yani yaklaşık 16 gün boyunca BAL'ları tutması gerektiğini belirtirdi. Bu, zayıf nesnellik penceresidir ve yürütme katmanı için bu yeterlidir. Bir yürütme istemcisi geliştiricisi, PR üzerinde, bir node'un bir BAL olmadan bir bloğu doğrulayabileceğini doğru bir şekilde vurguladı. Ancak sorun, uyum katmanındaydı. Bazı uyum istemcileri tam yükleri saklamaz. Onlar, "gizlenmiş" bir versiyon tutar ve bir eş bloğu istediğinde, geri kalan kısmı doldurmak için yürütme istemcisine engine_getPayloadBodiesBy*V2 çağrısı yapar. Bu, işlemler ve çekimler için çalışır, çünkü yürütme istemcileri blok gövdelerini 14.299 epoch boyunca saklar. Ancak Gloas altında, BAL da yürütme yükünün bir parçasıdır. Bu nedenle 16 gün sonra yürütme istemcisi BAL için null döndürecek ve uyum istemcisi hâlâ sunması beklenen bir yükü yeniden oluşturamayacaktı. Tek seçeneği, BAL'ları kendisinin saklamaya başlaması olacaktı; bu da aynı verinin diskte iki kez yer alması anlamına gelirdi. Düzeltme, BAL tutma süresini blok gövdesi penceresi olan 14.299 epocha, yani iki ayın biraz üzerindeki süreye uydurdu. Bu ücretsiz değil. Tartışmada belirtilen tipik 70 KiB BAL boyutunu kullanırsak, yaklaşık hesaplamama göre her node için BAL boyutu yaklaşık 7,5 GiB'den 30 GiB'a çıkıyor. Burada uyum güvenliğiyle ilgili hiçbir şey değişmedi. İki katman sadece "etrafında tutmak" ifadesine farklı anlamlar vermişti.