В понедельник вечером было объединено однострочное изменение EIP-7928, и история за этой строкой — хороший пример того, как два слоя клиентов Ethereum зависят друг от друга. EIP-7928 добавляет списки доступа на уровне блока в Glamsterdam. BAL записывает, какие аккаунты и слоты хранения затрагивает блок, а также изменения состояния после каждой транзакции, чтобы клиенты могли читать и проверять параллельно. Исходное правило гласило, что исполнительные клиенты должны хранить BAL только в течение 3 533 эпох — около 16 дней. Это окно слабой субъективности, и для исполнительного слоя этого вполне достаточно. Один разработчик исполнительного клиента справедливо отметил в PR, что нода может проверить блок вообще без BAL. Проблема была на консенсусной стороне. Некоторые консенсусные клиенты не хранят полные полезные нагрузки. Они сохраняют «ослеплённую» версию и, когда сосед запрашивает блок, они вызывают engine_getPayloadBodiesBy*V2 у исполнительного клиента, чтобы восстановить остальную часть. Это работает для транзакций и выводов, потому что исполнительные клиенты хранят тела блоков в течение 14 299 эпох. Однако в рамках Gloas BAL также является частью исполнительной полезной нагрузки. Таким образом, спустя 16 дней исполнительный клиент будет возвращать null для BAL, и консенсусный клиент больше не сможет восстановить полезную нагрузку, которую он всё ещё обязан предоставлять. Его единственный вариант — начать хранить BAL самостоятельно, что означает дублирование одних и тех же данных на диске. Исправление заставляет хранение BAL следовать окну хранения тел блоков — 14 299 эпох, чуть более двух месяцев. Это не бесплатно. Используя типичный размер BAL около 70 Кб, упомянутый в этом обсуждении, мой приблизительный расчёт составляет около 30 Гб BAL на ноду, вместо примерно 7,5 Гб. Ничто в безопасности консенсуса здесь не изменилось. Просто два слоя по-разному понимали, что значит «хранить это».