Vào đêm thứ Hai, một thay đổi một dòng đối với EIP-7928 đã được hợp nhất, và câu chuyện đằng sau dòng mã đó là một cái nhìn tốt về cách hai lớp client của ethereum phụ thuộc lẫn nhau. EIP-7928 thêm danh sách truy cập ở cấp khối vào Glamsterdam. Một BAL ghi lại các tài khoản và khe lưu trữ mà khối tiếp xúc, cùng với các thay đổi trạng thái sau mỗi giao dịch, để các client có thể đọc và xác thực song song. Quy tắc ban đầu nói rằng các client thực thi chỉ cần giữ BAL trong 3.533 epoch, khoảng 16 ngày. Đó là cửa sổ chủ quan yếu, và đối với lớp thực thi thì điều đó là đủ. Một nhà phát triển client thực thi đã đưa ra lập luận hợp lý trên PR rằng một nút mạng có thể xác thực một khối mà không cần BAL. Vấn đề nằm ở phía đồng thuận. Một số client đồng thuận không lưu trữ toàn bộ payload. Chúng giữ phiên bản “bị che khuất” và khi một peer yêu cầu khối, chúng gọi engine_getPayloadBodiesBy*V2 lên client thực thi để điền lại phần còn lại. Điều này hoạt động với giao dịch và rút tiền, vì các client thực thi giữ thân khối trong 14.299 epoch. Tuy nhiên, dưới Gloas, BAL cũng là một phần của payload thực thi. Do đó, sau 16 ngày, client thực thi sẽ trả về null cho BAL, và client đồng thuận không thể tái tạo lại payload mà nó vẫn được kỳ vọng phải cung cấp. Lựa chọn duy nhất của nó sẽ là tự lưu trữ BAL, nghĩa là cùng một dữ liệu được lưu hai lần trên đĩa. Giải pháp làm cho thời gian lưu giữ BAL tuân theo cửa sổ thân khối, 14.299 epoch, hơi hơn hai tháng. Điều này không miễn phí. Sử dụng kích thước BAL điển hình khoảng 70 KiB được đề cập trong cuộc thảo luận đó, con số ước tính của tôi là khoảng 30 GiB BAL trên mỗi nút, tăng từ khoảng 7,5 GiB. Không có gì về an toàn đồng thuận bị thay đổi ở đây. Hai lớp chỉ có những hiểu khác nhau về nghĩa của “giữ nó lại”.