क्या Solidity को सीखना मुश्किल है?

एक भाषा के रूप में Learning solidity को सीखना यकीनन सबसे आसान भाषाओं में से एक है। हालाँकि, Ethereum वातावरण को सीखना मुश्किल है।

यह Javascript, या C से प्राप्त किसी भी curly bracket भाषा के काफी समान दिखता है।

If statements, for loops, class inheritance, variable types, ये सभी बहुत परिचित हैं।

Solidity में cryptocurrency को ट्रांसफर करने से जुड़ी कुछ अनूठी अजीबोगरीब चीजें (oddities) हैं। उदाहरण के लिए, प्रत्येक function call में एक environment variable होता है जो यह दर्शाता है कि function call के साथ कितना ether भेजा गया था और अन्य smart contracts के साथ इंटरैक्ट करने के लिए इसमें कुछ विशिष्ट APIs हैं। Solidity में delegatecall और selfdestruct जैसे अजीब निर्देश (instructions) भी हैं जो अन्य भाषाओं में नहीं पाए जाते हैं, लेकिन दस्तावेज़ (documentation) पर थोड़ा विचार करने के बाद इन्हें समझना आसान है।

हालाँकि, Solidity और Ethereum डेवलपमेंट आश्चर्यों (surprises) से भरा हो सकता है। यहाँ केवल तीन उदाहरण दिए गए हैं।

मामूली लगने वाले बदलावों के परिणामस्वरूप gas cost में बहुत बड़ा अंतर आ सकता है

यह contract जो करता है वह बहुत सरल है। यह किसी अन्य contract से tokens को अपने पास ट्रांसफर करता है, फिर यह उसी transaction में इसे caller को ट्रांसफर कर देता है।

हालाँकि, openFaucetInefficient और openFaucetMoreEfficient की gas costs में बहुत बड़ा अंतर हो सकता है। ऐसा क्यों? आंतरिक रूप से, ERC20 tokens उपयोगकर्ता के balance को एक storage variable के रूप में स्टोर करते हैं। जब कोई storage variable शून्य (zero) से गैर-शून्य (non-zero) हो जाता है, तो इसके कारण यह variable ब्लॉकचेन पर क्रिएट हो जाता है। और इस creation स्टेप से जुड़ी cost बहुत अधिक होती है। जब किसी variable को शून्य पर सेट किया जाता है, तो यह अंतर्निहित (implicitly) रूप से मिटा दिया जाता है। इसलिए पहला function बार-बार एक storage variable बना रहा है और मिटा रहा है।

दूसरा function बहुत अधिक कुशल (efficient) है। यह अपने स्वयं के balance के लिए storage variable बनाता है, फिर यह सुनिश्चित करता है कि यह तब तक नष्ट न हो जब तक कि यह अंत में अंतिम token ट्रांसफर न कर दे। यह storage variables के अनावश्यक creation को रोकता है।

तीसरा function, जिसमें एक अजीब for-loop कंस्ट्रक्शन है, और भी अधिक कुशल है। Solidity compiler की विचित्रताओं के कारण, for loop को इस तरीके से पुनर्व्यवस्थित (re-arrange) करना अधिक कुशल होता है, यहाँ तक कि जब आप compiler को अपने कोड पर स्वचालित दक्षता सुधार (automatic efficiency improvements) चलाने के लिए कहते हैं तब भी।

आप यह कैसे जानेंगे? खैर, इसे जानने का कोई सीधा तरीका नहीं है। यही कारण है कि Solidity को मास्टर करना आसान नहीं है।

I/O operations को अनडू (undone) किया जा सकता है

x और y दोनों storage variables हैं, और आप उन्हें persistent disk पर स्टोर होने के रूप में सोच सकते हैं। वे transactions के बीच अपनी values को बनाए रखते हैं।

जब पूछा जाता है, तो कई डेवलपर्स यह मान लेते हैं कि यदि x 10 से कम या उसके बराबर है, तो x को newValue पर सेट किया जाएगा और y को x के 2 गुना पर सेट किया जाएगा। उदाहरण के लिए, यदि newValue 5 है, तो x 5 होगा और y 10 होगा। यदि newValue 20 है, तो x 20 होगा और newValue को बदला नहीं जाएगा।

लेकिन ऐसा नहीं होता है। यदि transaction में कहीं भी revert होता है, तो x पर किया गया write अनडू (undone) हो जाता है।

डेवलपर्स के लिए यह बहुत ही अप्रत्याशित (counter-intuitive) है, क्योंकि अधिकांश I/O operations revert नहीं होते हैं। हालाँकि, Ethereum पर सभी transactions atomic होते हैं। इसलिए x कभी भी 10 से अधिक नहीं हो सकता है, और x और y दोनों को एक साथ (in tandem) ही बदलना चाहिए।

हानिरहित (Innocuous) दिखने वाले functions re-entrancy attacks का कारण बन सकते हैं

उपरोक्त कोड लोगों को एक ERC20 token और एक ERC1155 token भेजता हुआ प्रतीत होता है जब वे mintTokens को कॉल करते हैं। जाहिर तौर पर, alreadyClaimed चेक के कारण प्रत्येक एड्रेस केवल एक बार ही mint कर सकता है।

हालाँकि, एक ही transaction में contract से सभी tokens को निकालना (drain) संभव है। ERC1155 में _mint function केवल एक token को mint ही नहीं करता है, यह transaction के sender को नियंत्रण (control) भी सौंप देता है — इससे पहले कि यह अपडेट किया जाए कि sender ने अपने tokens क्लेम कर लिए हैं। यह sender को _mint द्वारा नियंत्रण वापस सौंपे जाने पर recursively mintTokens को कॉल करके अपने लिए सभी tokens क्लेम करने की अनुमति देता है।

कौन से functions अन्य contracts को नियंत्रण सौंपते हैं, इसका कोई स्पष्ट तर्क या कारण नहीं है। व्यक्ति को बस उन्हें याद रखना पड़ता है।

निष्कर्ष

जैसा कि आप ऊपर देख सकते हैं, एक दिखने में सरल भाषा आश्चर्यों से भरी हो सकती है। हमने यहाँ केवल एक छोटी सी झलक देखी है। क्या आप जानते हैं कि “immutable” smart contracts के लिए अपना bytecode बदलना संभव है? उन खराब कोड डिज़ाइनों के बारे में क्या खयाल है जो खरीदारों को बिना किसी re-entrancy attack के अपने ether को double-spend करने की अनुमति देते हैं? ब्लॉकचेन के पूरी तरह से deterministic और transparent होने के बावजूद क्या आप सुरक्षित रूप से random numbers जनरेट कर सकते हैं?

एक ऐसी प्रोग्रामिंग भाषा का उपयोग करने के बावजूद जो सीखने में “आसान” है, ब्लॉकचेन अज्ञात रहस्यों (unknown unknowns) से भरा है। यही कारण है कि यहाँ hacks इतने आम हैं।

Solidity को एक वीकेंड में समझा जा सकता है। यदि आप पहले से ही कोई अन्य प्रोग्रामिंग भाषा जानते हैं, तो तेज़ी से Learn Solidity के लिए यहाँ हमारा मुफ़्त ट्यूटोरियल है।

लेकिन इकोसिस्टम को मास्टर करना कुछ दिनों का काम नहीं है।

क्या आप इकोसिस्टम को मास्टर करना चाहते हैं? हमारे पूरी तरह से रिमोट Solidity Bootcamp के लिए अभी अप्लाई करें।

मूल रूप से 8 नवंबर, 2022 को प्रकाशित