週一晚上，EIP-7928 的一行修改被合併，這一行背後的故事很好地展示了以太坊的兩個客戶端層如何相互依賴。 EIP-7928 為 Glamsterdam 增加了區塊級別的存取清單。 BAL 記錄了區塊所觸及的帳戶和儲存插槽，以及每次交易後的狀態變更，以便客戶端可以並行讀取和驗證。 原始規則規定，執行客戶端只需保留 3,533 個周期（約 16 天）的 BAL。 這是弱主觀性窗口，對執行層來說已經足夠。 一位執行客戶端開發者在 PR 中提出了合理的觀點：節點完全可以在沒有 BAL 的情況下驗證區塊。 問題出現在共識層。 一些共識客戶端不會儲存完整的載荷。 它們只保留一個「盲化」版本，當對等節點請求區塊時，它們會向執行客戶端呼叫 engine_getPayloadBodiesBy*V2 以填回其餘部分。 這對於交易和提款是可行的，因為執行客戶端會保留區塊主體長達 14,299 個周期。 但在 Gloas 下，BAL 也是執行載荷的一部分。 因此，16 天後，執行客戶端會為 BAL 返回 null，而共識客戶端便無法重建它仍需提供的載荷。 它唯一的選擇是自己開始儲存 BAL，這意味著相同數據在磁碟上重複儲存兩次。 修復方案使 BAL 的保留時間與區塊主體窗口一致，即 14,299 個周期，略多於兩個月。 這並非沒有代價。 根據該討論中提到的約 70 KiB 的典型 BAL 大小，我粗略估算每節點的 BAL 數據量將從約 7.5 GiB 增加至約 30 GiB。 這裡並未改變共識的安全性。 兩個層只是對「保留它」的含義有不同的理解。