Pada malam Senin, satu baris perubahan pada EIP-7928 berhasil digabungkan, dan kisah di balik baris tersebut memberikan gambaran yang bagus tentang bagaimana dua lapisan klien Ethereum saling bergantung. EIP-7928 menambahkan daftar akses tingkat blok ke Glamsterdam. BAL mencatat akun dan slot penyimpanan yang disentuh oleh blok, plus perubahan status setelah setiap transaksi, sehingga klien dapat membaca dan memvalidasi secara paralel. Aturan awal menyatakan bahwa klien eksekusi hanya perlu menyimpan BAL selama 3.533 epoch, sekitar 16 hari. Itu adalah jendela subjektivitas lemah, dan bagi lapisan eksekusi itu sudah cukup. Seorang pengembang klien eksekusi membuat poin yang masuk akal di PR bahwa sebuah node dapat memvalidasi blok tanpa BAL sama sekali. Masalahnya ada di sisi konsensus. Beberapa klien konsensus tidak menyimpan payload penuh. Mereka menyimpan versi "blinded" dan, ketika rekan meminta blok, mereka memanggil engine_getPayloadBodiesBy*V2 pada klien eksekusi untuk mengisi kembali bagian yang tersisa. Itu berfungsi untuk transaksi dan penarikan, karena klien eksekusi menyimpan badan blok selama 14.299 epoch. Namun, di bawah Gloas, BAL juga merupakan bagian dari payload eksekusi. Jadi setelah 16 hari, klien eksekusi akan mengembalikan null untuk BAL, dan klien konsensus tidak lagi dapat membangun ulang payload yang masih diharapkan untuk disajikan. Satu-satunya pilihan mereka adalah mulai menyimpan BAL sendiri, yang berarti data yang sama tersimpan dua kali di disk. Perbaikan ini membuat retensi BAL mengikuti jendela badan blok, 14.299 epoch, sedikit lebih dari dua bulan. Ini tidak gratis. Dengan ukuran BAL rata-rata sekitar 70 KiB yang disebutkan dalam diskusi tersebut, perkiraan kasar saya adalah sekitar 30 GiB BAL per node, naik dari sekitar 7,5 GiB. Tidak ada yang berubah dalam hal keamanan konsensus. Dua lapisan hanya memiliki pemahaman berbeda tentang apa artinya "menyimpannya".