स्मार्ट कॉन्ट्रैक्ट मैक्सिस, आपका सॉलिडिटी कंपाइलर शायद एक स्टोर को चुपचाप हटा दिया होगा जिसकी आपको आवश्यकता थी, और आप इसे अपने स्रोत में कभी नहीं देख पाए। सॉलिडिटी 0.8.38 का पिछले गुरुवार को अपडेट आया। इसमें Yul ऑप्टिमाइज़र में एक बग को ठीक किया गया है, जो 0.8.19 से 0.8.37 तक के हर रिलीज़ में मौजूद था। ऑप्टिमाइज़र मेमोरी और स्टोरेज में क्या है, इसके बारे में नोट्स रखता है। वह इन नोट्स का उपयोग करके एक लोड को उस मान से प्रतिस्थापित करता है जिसे वह पहले से जानता है, और उस स्टोर को छोड़ देता है जो पहले से मौजूद मान को फिर से लिखता है। यह तय करने के लिए कि दो पते ओवरलैप हो सकते हैं या नहीं, वह प्रत्येक पते को एक बेस वेरिएबल प्लस ऑफसेट के रूप में वर्णित करता है। एक ही बेस, अलग-अलग ऑफसेट, इसलिए वे अलग-अलग स्लॉट होने चाहिए। ये वर्णन कैश किए गए थे। फिर किसी ने बेस वेरिएबल को पुनः असाइन कर दिया। ऑप्टिमाइज़र हमेशा इसे महसूस नहीं करता। अब यह पुराने मान से बनाए गए पते की तुलना नए मान से बनाए गए पते से करता है, मानते हुए कि वे एक ही बेस साझा करते हैं। वह तय करता है कि वे अलग हैं, लेकिन रनटाइम पर वे एक ही स्थान को संदर्भित करते हैं। परिणाम है—एक पुराना (stale) नोट। बाद में किया गया लोड पुराना मान लौटा सकता है। आपकी आवश्यकता वाला स्टोर हटा सकता है। उस स्थान पर keccak256 पुराने डेटा को हैश कर सकता है। केवल ऑप्टिमाइज़र सक्रिय होने पर कंपाइल किया गया कोड प्रभावित होता है। via-IR के साथ, कोई भी कोड प्रभावित हो सकता है, حتى inline assembly के बिना। डिफ़ॉल्ट पुरानी पाइपलाइन के साथ, केवल कुछ inline assembly और कंपाइलर-जनित हेल्पर्स। अनऑप्टिमाइज़्ड बिल्ड सुरक्षित हैं। टीम इसे कम सीवेरिटी मानती है, और उन्होंने कुछऐसा किया,जो मैं हर कंपाइलर टीम की कामना करता हूँ— उन्होंने Sourcify डेटाबेस में प्रत्येक प्रमाणित कॉन्ट्रैक्ट को, सुधार के साथ-साथ सुधार के बिना, पुनः कंपाइल किया,और सभी में bytecode समान पाया गया। इसलिए,यह rare है। rare ka matlab never nahi hai,खासकर agar aapka code naya hai aur abhi tak deploy nahi kiya gaya hai। यह bug Ethereum Foundation bug bounty के माध्यम से aaya, aur ek doosri report ne dikhaya ki inline assembly ke bina bhi plain Solidity isse trigger kar sakti hai।