जब कोई वेब2 और वेब3 के बीच अंतर करना चाहता है, तो एक महत्वपूर्ण मूल्य जो दोनों को अलग करता है वह स्वामित्व की अवधारणा है।
सीधे शब्दों में कहें, तो आप जो बनाते हैं वह आपके पास होता है और आप उससे कमाई कर सकते हैं। बस इसे जैसा होना चाहिए। कुछ कम नहीं, कुछ ज्यादा नहीं। वास्तव में, जिस दिन आप अपना पहला NFT मिंट करते हैं, जब आपने इसे Web3 में एक मालिक के रूप में बनाया है, ब्लॉकचेन की अपरिवर्तनीयता के लिए धन्यवाद। कुछ भी हो, संरक्षित होने की भावना अनमोल है।
जिसके बारे में बोलते हुए, स्वामित्व की यह अवधारणा सुलभ कार्यों और अनुमत राज्य परिवर्तन के संबंध में स्मार्ट अनुबंधों के लिए उतनी ही महत्वपूर्ण है।
तो, यह क्यों मायने रखता है कि आपने जो स्मार्ट अनुबंध लिखा है, उसके आप 'स्वामित्व' रखते हैं?
इसके बारे में सोचें: यदि आपके पास बाइक है, तो क्या आप स्वामित्व रिकॉर्ड रखने में संकोच करेंगे? अगर किसी ने इसे चुरा लिया है और इसे नापाक उद्देश्यों के लिए इस्तेमाल किया है? बिल्कुल नहीं।
यह उसी कारण से है कि आप एनएफटी या स्मार्ट अनुबंध के अपने स्वामित्व को क्यों साबित करना चाहते हैं। खैर, हो सकता है कि कोई अनाधिकृत पहुंच हासिल कर ले और इससे आर्थिक रूप से लाभान्वित हो जाए, है ना?
मान लें कि आप Dunzo के साथ काम करते हैं और आपने यह स्मार्ट अनुबंध लिखा है, जहां आप पैकेज की कीमत और वितरण शुल्क के साथ-साथ खरीदार द्वारा भुगतान किया गया था या नहीं, यह निर्धारित कर सकते हैं।
आदर्श परिदृश्य में, आप खरीदार का नाम, पैकेज की कुल कीमत और डिलीवरी को एक निश्चित राशि पर सेट कर सकते हैं और सेटपैकेजडिलीवर को सही पर सेट कर सकते हैं। एक बार जब आप पैकेज वितरित कर लेंगे, तो निश्चित रूप से।
लेकिन, जैसा कि हम सभी जानते हैं, योजना के अनुसार कुछ भी नहीं होता है।
अब, क्या होगा यदि खरीदार के पास अनुबंध कार्यों तक पहुंच हो और packageDelivered मान को गलत पर रीसेट करने या packageDeliveryPrice मान को कम करने की क्षमता हो? न केवल वे उत्पाद के लिए कम भुगतान कर सकते हैं बल्कि कुछ भी भुगतान नहीं कर सकते हैं।
स्पष्ट रूप से, डंज़ो के अलावा, किसी और के पास इस तरह के बदलाव करने की पहुंच नहीं होनी चाहिए, और यही कारण है कि एक्सेस कंट्रोल सेट करना मायने रखता है।
अब, आइए इस स्मार्ट अनुबंध को तैनात करें और देखें कि घुसपैठिए के लिए राज्य चर में मूल्यों को बदलना कितना आसान है।
दोनों सेटप्राइस और सेटपैकेजडिलीवर फंक्शन एक्सेस करने योग्य हैं, कोई भी परिवर्तन कर सकता है जिसके परिणामस्वरूप डंजो डिलीवरी को वित्तीय नुकसान हो सकता है।
अगर डंजो ने वस्तु की मूल कीमत 5 ईटीएच पर निर्धारित की थी, तो ग्राहक अब उस मूल्य को 3 ईटीएच में बदल सकता है। बेशक, चूंकि ग्राहक भी सेटपैकेजडिलीवर फ़ंक्शन का उपयोग कर सकता है और बूलियन मान को गलत में बदल सकता है, वह उसी आइटम की दूसरी डिलीवरी प्राप्त कर सकता है। तो, किसी भी मामले में, Dunzo पैसे खोने के लिए खड़ा है, और बहुत देर होने तक इसका एहसास भी नहीं हो सकता है।
उदाहरण के लिए, मान लें कि डिलीवर किया जा रहा उत्पाद 5 ETH का है, जैसा कि नीचे दिखाया गया है:
परिनियोजन पर, Dunzo के अलावा कोई भी अनुबंध की शर्तों को संशोधित करने में सक्षम नहीं होना चाहिए। फिर भी, जब हम रीमिक्स में पते स्विच करते हैं और मूल्य को 3 पर रीसेट करते हैं, तो यह संभव नहीं है क्योंकि कोई सुरक्षा नहीं है।
हम सेटपैकेजडिलीवर स्थिति को सही से गलत में भी बदल सकते हैं। भले ही ग्राहक को पैकेज पहले ही डिलीवर कर दिया गया हो।
जैसा कि आप बता सकते हैं, उक्त स्मार्ट अनुबंध के लिए स्वामी और अन्य उपयोगकर्ताओं के बीच अंतर करना महत्वपूर्ण है। तो, आइए 4 सुधारों पर गौर करें जो इस स्मार्ट अनुबंध के लिए उचित अभिगम नियंत्रण स्थापित करेंगे और परिणामस्वरूप इसकी सुरक्षा सुनिश्चित करेंगे।
तो, स्मार्ट अनुबंध लिखते समय कोई स्वामी और अन्य उपयोगकर्ताओं के बीच अंतर कैसे कर सकता है?
स्पष्ट रूप से, वित्तीय नुकसान के कारण यह आवश्यक है जिसे नजरअंदाज करने पर हो सकता है।
विधि # 1: आवश्यकता कथन का प्रयोग करें
जैसा कि आप नीचे दिए गए कोड में देख सकते हैं, 'require' स्टेटमेंट के साथ एड्रेस टाइप का एक नया स्टेट वेरिएबल ओनर जोड़ा गया है। कंस्ट्रक्टर में, मालिक राज्य चर उस पते को संग्रहीत करता है जिसका उपयोग अनुबंध को तैनात करते समय किया जाता है। जैसा कि आप जानते हैं कि स्मार्ट कॉन्ट्रैक्ट्स में कंस्ट्रक्टर्स को केवल एक बार इनवॉइस किया जाता है, इसलिए पता नहीं बदला जा सकता है।
अब, जब आप कम मूल्य और एक अलग पते के साथ सेटप्राइस फ़ंक्शन का आह्वान करते हैं, तो लेन-देन प्रारंभिक स्थिति में वापस आ जाता है, जैसा कि नीचे दिए गए संदेश में है:
जैसा कि आप देख सकते हैं, अनुबंध द्वारा प्रदान किए गए कारण में त्रुटि संदेश शामिल है जिसे हमने 'आवश्यकता' कथन में जोड़ा है। उस ने कहा, इस मामले में अनुबंध के मालिक — Dunzo के अलावा कोई नहीं — बिक्री की शर्तों को बदल सकता है।
विधि #2: फ़ंक्शन संशोधक का उपयोग करें
सही स्थिति के साथ एक 'आवश्यकता' कथन जोड़ना जितना आसान है, एक संशोधक कोड का एक ब्लॉक है जिसे आप बार-बार उपयोग कर सकते हैं। यह निश्चित रूप से इस तरह के चेक के लिए कई 'आवश्यकताएं' बयान लिखने से कहीं अधिक समझ में आता है।
पहले साझा किए गए कोड में, केवल सेटप्राइस फ़ंक्शन को 'आवश्यकता' कथन द्वारा संरक्षित किया गया है, लेकिन यहां सेटपैकेजडिलीवर फ़ंक्शन के लिए कुछ भी नहीं किया गया है। एक संशोधक का उपयोग करना चाहिए, जैसा कि नीचे सॉलिडिटी कोड में दिखाया गया है:
अब, यदि आप या तो setPrice या setPackageDelivered फ़ंक्शंस तक पहुँचने का प्रयास करते हैं, तो आपको वही त्रुटि संदेश मिलेगा जो पहले प्राप्त हुआ था, और जैसा कि नीचे दिखाया गया है:
विधि #3: स्वामित्व
इस सुधार के लिए आपको OpenZeppelin द्वारा प्रदान किए जाने योग्य स्मार्ट अनुबंध का उपयोग करने की आवश्यकता है। सबसे पहले, आपको ओनेबल स्मार्ट कॉन्ट्रैक्ट इम्पोर्ट करना होगा और फिर उन फंक्शन्स में onlyOwner मॉडिफायर जोड़ना होगा जिन्हें आप सुरक्षित करना चाहते हैं। इसलिए, जैसा कि नीचे दिखाया गया है, दोनों setPrice और setPackageDelivered फ़ंक्शंस में नीचे onlyOwner संशोधक है।
अब, चूंकि dunzoDelivery स्मार्ट अनुबंध Ownerable.sol में कुछ कार्यों का उपयोग करेगा, इसलिए अनुबंध के नाम में "स्वामित्व योग्य है" भी जोड़ा गया है।
उस ने कहा, दो अन्य कार्य हैं जो स्वामित्व वाले स्मार्ट अनुबंध का उपयोग करते समय उपयोग कर सकते हैं: स्वामित्व त्यागें और स्वामित्व स्थानांतरित करें। जबकि जिस खाते का उपयोग अनुबंध को तैनात करने के लिए किया गया था, उसे आमतौर पर मालिक माना जाता है, इसे इन कार्यों का उपयोग करके बदला जा सकता है।
स्वामी का पता और अन्य अनुबंध विवरण देखने के अलावा, आप नीचे उपयोग के लिए त्याग स्वामित्व और हस्तांतरण स्वामित्व कार्य देख सकते हैं:
अपेक्षा के अनुरूप, जब आप किसी अन्य पते का उपयोग करके सेटप्राइस फ़ंक्शन को प्रारंभ करने का प्रयास करते हैं, तो लेन-देन पूरा नहीं होगा। इसके बजाय, यह नीचे दिए गए कारण के साथ मूल स्थिति में वापस आ जाता है:
ओनेबल स्मार्ट कॉन्ट्रैक्ट का उपयोग करना अच्छा है यदि आपको अन्य उपयोगकर्ताओं के बीच केवल एक मालिक की आवश्यकता है। यदि आप अधिक पदानुक्रम की तलाश कर रहे हैं, तो AccessControl.sol स्मार्ट अनुबंध का उपयोग किया जाना चाहिए।
विधि #4: AccessControl
इस अंतिम सुधार के लिए आपको Open Zeppelin द्वारा AccessControl स्मार्ट अनुबंध का उपयोग करने की आवश्यकता है।
शुरुआत करने वालों के लिए, आपको आयात विवरण में एक्सेस कंट्रोल हाइपरलिंक जोड़ना होगा और साथ ही अनुबंध विवरण में "एक्सेसकंट्रोल है" जोड़ना होगा।
जैसा कि पहले उल्लेख किया गया है, यह स्मार्ट अनुबंध आपको एक पदानुक्रम के भीतर कई भूमिकाएँ जोड़ने की अनुमति देता है और जिन्हें आपको घोषित करना होगा, जैसा कि नीचे दिखाए गए स्मार्ट अनुबंध की पहली दो पंक्तियों में है:
इस अनुबंध में, डंज़ो और ग्राहक नाम से दो भूमिकाएँ हैं। अब, जब आप अनुबंध को लागू करते हैं, तो आपको उक्त पतों पर पूर्वोक्त घोषित भूमिकाओं को असाइन करना होगा, ताकि यह निर्धारित किया जा सके कि कौन क्या एक्सेस कर सकता है। इसके अलावा, दो 'require' कथनों को setPrice और setPackageDelivered प्रकार्यों में जोड़ा गया है।
जैसा कि आप बता सकते हैं, केवल वह खाता जिसे डंज़ो भूमिका सौंपी गई है, परिनियोजन के समय उल्लिखित बिक्री शर्तों को बदलने में सक्षम होगा, कोई अन्य नहीं। उस ने कहा, आप AccessControl.sol का उपयोग करके एक स्मार्ट अनुबंध के कार्यों तक पहुंच के विभिन्न स्तरों के साथ कई भूमिकाएँ सौंप सकते हैं, जबकि Ownerable.sol इतनी गहराई में नहीं जाएगा।
अब, स्मार्ट अनुबंधों में अभिगम नियंत्रण लागू करने के लिए ये एकमात्र समाधान उपलब्ध नहीं हैं। RBAC.sol और WhitelistCrowdSale.sol भी अतीत में उपलब्ध रहे हैं और जो AccessControl.sol और Ownerable.sol की तरह भूमिकाओं को भी पतों से जोड़ सकते हैं।
इसलिए, यदि आप अभिगम नियंत्रण को लागू करने के विकास के रूप में पूरी तरह से समझ हासिल करना चाहते हैं, तो यह आपके समय के लायक होगा, इन दो स्मार्ट अनुबंधों में भी कोड पर जा रहा है।
इस लेख की मुख्य छविहैकरनून के एआई इमेज जेनरेटर द्वारा "पहुंच से वंचित बायोमेट्रिक स्कैन" के माध्यम से तैयार की गई थी।