सोमवार की रात, EIP-7928 में एक पंक्ति का बदलाव मर्ज कर दिया गया, और उस पंक्ति के पीछे की कहानी ईथेरियम के दो क्लाइंट स्तरों के एक-दूसरे पर निर्भरता का एक अच्छा नज़ारा है। EIP-7928 Glamsterdam में ब्लॉक-स्तरीय एक्सेस सूचियाँ जोड़ता है। एक BAL यह दर्ज करता है कि एक ब्लॉक किन खातों और स्टोरेज स्लॉट्स को स्पर्श करता है, साथ ही प्रत्येक लेनदेन के बाद स्थिति में हुए बदलाव, ताकि क्लाइंट समानांतर रूप से पढ़ सकें और सत्यापित कर सकें। मूल नियम कहता था कि एक्सीक्यूशन क्लाइंट्स को केवल 3,533 ईपोक्स, लगभग 16 दिनों के लिए BALs रखने की आवश्यकता है। यह कमजोर विषयवस्तु खिड़की है, और एक्सीक्यूशन परत के लिए यह पर्याप्त है। एक एक्सीक्यूशन क्लाइंट डेवलपर ने PR पर यह सही बात रखी कि एक नोड BAL के बिना भी एक ब्लॉक को सत्यापित कर सकता है। समझौता परत पर समस्या थी। कुछ समझौता क्लाइंट्स पूरे पेलोड को संग्रहित नहीं करते। वे "अंधे" संस्करण को रखते हैं, और जब कोई पीयर ब्लॉक माँगता है, तो वे execution client पर engine_getPayloadBodiesBy*V2 कोल करते हैं, ताकि शेष हिस्से को पुनः भर सकें। यह लेनदेन और निकासी के लिए काम करता है, क्योंकि execution clients 14,299 epochs के लिए ब्लॉक बॉडीज़ को संग्रहित करते हैं। हालाँकि, Gloas के अनुसार, BAL भी execution payload का हिस्सा है। इसलिए 16 दिनों के बाद execution client BAL के लिए null लौटाएगा, और consensus client पुनः पेलोड बनाने में सक्षम नहीं होगा, हालाँकि इसे सेवा करने की अपेक्षा की जा रही है। इसका एकमात्र विकल्प BALs को स्वयं संग्रहित करना होगा, जिसका मतलब है कि डिस्क पर एक ही डेटा दोबारा संग्रहित होगा। इस समाधान से BAL संग्रहण block body window, 14,299 epochs, यानी दो महीने से थोड़ा अधिक, के साथ ही होगा। यह मुफ़्त नहीं है। उस चर्चा में उल्लिखित 70 KiB के सामान्य BAL 사이ज़ का प्रयोग करते हुए, मेरी प्रारंभिक प्रतिक्रिया है कि प्रति node BALs की मात्रा 7.5 GiB से 30 GiB होगी। यहाँ समझौता सुरक्षा में कोई परिवर्तन नहीं हुआ है। दो परतों के पास "इसे संग्रहित करना" का मतलब समझने में अलग-अलग सोच है।