في ليلة الاثنين، تم دمج تغيير مكوّن من سطر واحد في EIP-7928، وتلك اللحظة تقدم نظرة جميلة على كيفية اعتماد طبقتي العميل في إيثريوم على بعضهما البعض. يضيف EIP-7928 قوائم وصول على مستوى الكتلة إلى Glamsterdam. تسجّل BAL الحسابات وفتحات التخزين التي تلامسها الكتلة، بالإضافة إلى التغييرات في الحالة بعد كل معاملة، بحيث يمكن للعملاء قراءة والتحقق من صحتها بالتوازي. كان القانون الأصلي ينص على أن عملاء التنفيذ يجب أن يحتفظوا بـ BALs فقط لمدة 3,533 فترة، أي حوالي 16 يومًا. هذا هو نافذة التحديد الضعيف، وهو ما يكفي تمامًا لطبقة التنفيذ. أشار أحد مطوري عميل التنفيذ إلى نقطة عادلة في طلب السحب: يمكن لعقدة التحقق من كتلة دون الحاجة إلى BAL على الإطلاق. لكن المشكلة كانت من جانب التوافق. بعض عملاء التوافق لا يخزّنون الحمولات الكاملة. إنهم يحتفظون بإصدار "مُخفّى" وعندما يطلب زميل الكتلة، فإنهم يستدعيون engine_getPayloadBodiesBy*V2 على عميل التنفيذ لإعادة ملء الباقي. هذا يعمل مع المعاملات والسحب، لأن عملاء التنفيذ يحتفظون بجسم الكتلة لمدة 14,299 فترة. لكن تحت Gloas، فإن BAL جزء من حمل التنفيذ أيضًا. لذلك، بعد 16 يومًا، كان عميل التنفيذ سيُرجع قيمة فارغة للـ BAL، مما يعني أن عميل التوافق لم يعد قادرًا على إعادة بناء حمل لا يزال مطلوبًا منه تقديمه. خياره الوحيد كان أن يبدأ في تخزين BALs بنفسه، مما يعني تخزين نفس البيانات مرتين على القرص. الإصلاح يجعل الاحتفاظ بـ BALs يتبع نافذة جسم الكتلة، أي 14,299 فترة، أي قليلاً أكثر من شهرين. ولكنه ليس مجانيًا. باستخدام حجم BAL النموذجي البالغ حوالي 70 كيلوبايت المذكور في تلك المناقشة، فإن تقديراتي الأولية تشير إلى حوالي 30 جيجابايت من BALs لكل عقدة، بزيادة من حوالي 7.5 جيجابايت. لم يتغير شيء فيما يتعلق بسلامة التوافق. ببساطة، كان لدى الطبقتين تفسيران مختلفان لما يعنيه "الاحتفاظ به".