স্মার্ট চুক্তি বিশেষজ্ঞদের জন্য, আপনার সলিডিটি কম্পাইলার সম্ভবত একটি প্রয়োজনীয় স্টোরকে চুপচাপ মুছে ফেলেছে, এবং আপনি আপনার সোর্স কোডে এটি কখনই দেখতে পাবেন না। সলিডিটি 0.8.38 গত বৃহস্পতিবার প্রকাশিত হয়েছে। এটি Yul অপ্টিমাইজারের একটি বাগ ঠিক করে, যা 0.8.19 থেকে 0.8.37 পর্যন্ত প্রতিটি রিলিজে ছিল। অপ্টিমাইজার মেমোরি এবং স্টোরেজে কী আছে তা নোট করে রাখে। এটি সেই নোটগুলির ভিত্তিতে, একটি লোডকে একটি মান দিয়ে প্রতিস্থাপন করে, যা এটি ইতিমধ্যেই জানে, এবং যে স্টোরটি ইতিমধ্যেই সেখানে থাকা ডেটা লিখছে, তা লাফিয়ে যায়। দুটি ঠিকানা কি ওভারল্যাপ করতে পারে, তা সিদ্ধান্ত নেওয়ার জন্য, এটি প্রতিটি ঠিকানাকে একটি বেসভ্যারিয়েবল + অফসেট হিসাবে বর্ণনা করে। একই বেস, ভিন্ন অফসেট, তাই তাদেরকেই ভিন্ন স্লট হতে হবে। এই বর্ণনাগুলি ক্যাশেড ছিল। তারপর, কেউ বেসভ্যারিয়েবলকে punরাইনাইট (reassign) করল। অপ্টিমাইজারটি সবসময়ই এটিরা। এখন, it compares an address built from the old value with one built from the new value as if they shared a base. It decides they're different, but at runtime they point to the same place. The result is a stale note. A later load can return an old value. A store you needed can get removed. A keccak256 over that location can hash outdated data. Only code compiled with the optimizer on is exposed. With via-IR, any code can hit it, even without inline assembly. With the default legacy pipeline, only some inline assembly and compiler-generated helpers. Unoptimized builds are safe. The team rates it low severity, and they did something I wish every compiler team did. They recompiled every verified contract in the Sourcify database with and without the fix, and the bytecode was identical for all of them. So it's rare. Rare isn't the same as never, especially if your code is fresh and not deployed yet. The bug came in through the Ethereum Foundation bug bounty, and a second report showed plain Solidity without assembly can trigger it.