月曜の夜、EIP-7928に一行の変更がマージされ、その一行の背後には、Ethereumの二つのクライアント層が互いにどのように依存しているかを示す良い例となっている。 EIP-7928はGlamsterdamにブロックレベルのアクセスリストを追加する。 BALは、ブロックがアクセスするアカウントとストレージスロット、および各トランザクション後のステート変更を記録し、クライアントが並列に読み取りと検証を実行できるようにする。 元のルールでは、実行クライアントは3,533エポック（約16日）分のBALのみを保持すればよかった。 これは弱主観性ウィンドウであり、実行層にとっては十分である。 ある実行クライアント開発者がPRで正当な指摘をしたところ、ノードはBALなしでもブロックを検証できるという点だった。 しかし、問題はコンセンサス側にあった。 一部のコンセンサスクライアントは完全なペイロードを保存しない。 代わりに「ブラインド」バージョンを保持し、ピアがブロックを要求した際に、実行クライアントにengine_getPayloadBodiesBy*V2を呼び出して残りの部分を再構成する。 トランザクションと引き出しについては、実行クライアントが14,299エポック分のブロックボディを保持しているため、この仕組みは機能する。 しかしGloasでは、BALも実行ペイロードの一部である。 そのため、16日経過後、実行クライアントはBALに対してnullを返し、コンセンサスクライアントはまだ提供すべきペイロードを再構成できなくなる。 その場合の唯一の選択肢は、自らBALを保存し始めるということであり、それはディスク上に同じデータを二重に保存することを意味する。 この修正により、BALの保持期間がブロックボディのウィンドウである14,299エポック（約2か月余り）に統一された。 これは無料ではない。 議論で挙げられた約70 KiBの典型的なBALサイズを基に計算すると、ノードあたりのBALサイズは約7.5 GiBから約30 GiBに増加する。 コンセンサスの安全性には一切変更はない。 単に二つの層が「保持する」という意味について異なる解釈をしていただけである。