On Monday night, a one-line change to EIP-7928 got merged, and the story behind that line is a nice look at how Ethereum's two client layers depend on each other. EIP-7928 adds block-level access lists to Glamsterdam. A BAL records which accounts and storage slots a block touches, plus the state changes after each transaction, so clients can read and validate in parallel. The original rule said execution clients only had to keep BALs for 3,533 epochs, about 16 days. That's the weak subjectivity window, and for the execution layer that's plenty. One execution client developer made the fair point on the PR that a node can validate a block without a BAL at all. The catch was on the consensus side. Some consensus clients don't store full payloads. They keep a "blinded" version and, when a peer asks for the block, they call engine_getPayloadBodiesBy*V2 on the execution client to fill the rest back in. That works for transactions and withdrawals, because execution clients keep block bodies for 14,299 epochs. Under Gloas, though, the BAL is part of the execution payload too. So after 16 days the execution client would return null for the BAL, and the consensus client could no longer rebuild a payload it's still expected to serve. Its only option would be to start storing BALs itself, which means the same data sitting on disk twice. The fix makes BAL retention follow the block body window, 14,299 epochs, a little over two months. It isn't free. Using the roughly 70 KiB typical BAL size cited in that discussion, my back-of-envelope number is around 30 GiB of BALs per node, up from about 7.5 GiB. Nothing about consensus safety changed here. Two layers just had different ideas of what "keep it around" meant.