У понеділок вночі було об’єднано однорядкову зміну до EIP-7928, і історія за цією лінією — це гарний огляд того, як два клієнтських рівні Ethereum залежать один від одного. EIP-7928 додає списки доступу на рівні блоку до Glamsterdam. BAL записує, які акаунти та слоти зберігання торкається блок, а також зміни стану після кожної транзакції, щоб клієнти могли читати та перевіряти паралельно. Початкове правило стверджувало, що виконавчі клієнти повинні зберігати BAL лише протягом 3 533 епох, що становить близько 16 днів. Це вік слабкої суб’єктивності, і для виконавчого рівня цього достатньо. Один розробник виконавчого клієнта зробив правильний коментар у PR, що нода може перевірити блок взагалі без BAL. Проблема полягала на консенсусному боку. Деякі консенсусні клієнти не зберігають повні дані блоку. Вони зберігають «оcліплену» версію, і коли вузол запитує блок, вони викликають engine_getPayloadBodiesBy*V2 на виконавчому клієнті, щоб заповнити решту даних. Це працює для транзакцій та виведень, оскільки виконавчі клієнти зберігають тіла блоків протягом 14 299 епох. Але за Gloas BAL також є частиною виконавчого завантаження. Тож через 16 днів виконавчий клієнт повернув би null для BAL, і консенсусний клієнт був би не здатний відновити завантаження, яке все ще має надавати. Його єдиним варіантом було б самостійно зберігати BAL, що означало б подвоєння тих самих даних на диску. Виправлення робить тривалість зберігання BAL такою ж, як у вікна тіл блоку — 14 299 епох, трохи більше двох місяців. Це не безкоштовно. Використовуючи приблизно 70 КБ типовий розмір BAL, згаданий у цьому обговоренні, моя попередня оцінка становить близько 30 ГБ BAL на ноду, замість приблизно 7,5 ГБ. Ніщо з безпеки консенсусу тут не змінилося. Просто два рівні мали різні уявлення про те, що означає «зберегти це».