সোমবার রাতে, EIP-7928-এ এক লাইনের পরিবর্তন মার্জ করা হয়েছে, এবং সেই লাইনের পেছনের গল্পটি ভালোভাবে দেখায় কীভাবে ইথেরিয়ামের দুইটি ক্লায়েন্ট লেয়ার একে অন্যের ওপর নির্ভর করে। EIP-7928 Glamsterdam-এ ব্লক-লেভেল অ্যাক্সেস লিস্ট যোগ করে। একটি BAL রেকর্ড করে কোন কোন অ্যাকাউন্ট এবং স্টোরেজ স্লট একটি ব্লক স্পর্শ করেছে, সাথে প্রতিটি ট্রানজ্যাকশনের পর স্টেট পরিবর্তনগুলো, যাতে ক্লায়েন্টরা সমান্তরালভাবে পড়তে ও যাচাই করতে পারে। মূল নিয়মে বলা হয়েছিল এক্সিকিউশন ক্লায়েন্টদের শুধু 3,533 epoch পর্যন্ত, অর্থাৎ প্রায় ১৬ দিন, BAL রাখতে হবে। ওটাই দুর্বল subjectivity উইন্ডো, এবং এক্সিকিউশন লেয়ারের জন্য সেটা যথেষ্ট। একজন এক্সিকিউশন ক্লায়েন্ট ডেভেলপার PR-এ যথাযথভাবে বলেছেন যে একটি নোড BAL ছাড়াও একটি ব্লক যাচাই করতে পারে। কাঠিন্যটা ছিল consensus পাশে। কিছু consensus ক্লায়েন্ট পূর্ণ payload সংরক্ষণ করে না। তারা একটি “blinded” ভার্সন রাখে এবং যখন কোনো peer ব্লক চায়, তারা এক্সিকিউশন ক্লায়েন্টে engine_getPayloadBodiesBy*V2 কল করে বাকিটা আবার পূরণ করে। এটা ট্রানজ্যাকশন এবং withdrawal-এর ক্ষেত্রে কাজ করে, কারণ এক্সিকিউশন ক্লায়েন্টরা 14,299 epoch পর্যন্ত ব্লক বডি রাখে। কিন্তু Gloas-এর অধীনে BAL-ও এক্সিকিউশন payload-এর অংশ। তাই ১৬ দিনের পর এক্সিকিউশন ক্লায়েন্ট BAL-এর জন্য null রিটার্ন করবে, এবং consensus ক্লায়েন্ট আর সেই payload পুনর্গঠন করতে পারবে না, যেটা সে এখনও সার্ভ করার কথা। তার একমাত্র বিকল্প হবে নিজে BAL সংরক্ষণ শুরু করা, যার মানে একই ডেটা ডিস্কে দু’বার বসে থাকা। সমাধানটি BAL retention-কে ব্লক বডি উইন্ডোর সাথে সমান করেছে, 14,299 epoch, অর্থাৎ একটু বেশি দুই মাস। এটা বিনা খরচে নয়। আলোচনায় উল্লেখ করা প্রায় 70 KiB সাধারণ BAL সাইজ ব্যবহার করে, আমার আনুমানিক হিসাব অনুযায়ী প্রতিটি নোডে প্রায় 30 GiB BAL থাকতে হবে, যা আগে ছিল প্রায় 7.5 GiB। এখানে consensus নিরাপত্তা সম্পর্কে কিছুই পরিবর্তন হয়নি। শুধু দুইটি লেয়ার “keep it around” বলতে কী বোঝায়, সে বিষয়ে ভিন্ন ধারণা রেখেছিল।