मुख्य आशयावर जा

Vyper ERC-721 कॉन्ट्रॅक्ट वॉकथ्रू

Vyper
erc-721
Python
नवशिक्या
Ori Pomerantz
1 एप्रिल, 2021
18 मिनिट वाचन

प्रस्तावना

ERC-721 मानक हे नॉन-फंजिबल टोकन्स (NFT) ची मालकी ठेवण्यासाठी वापरले जाते. ERC-20 टोकन्स एका वस्तू (कमोडिटी) सारखे वागतात, कारण वैयक्तिक टोकन्समध्ये काहीही फरक नसतो. याउलट, ERC-721 टोकन्स अशा मालमत्तेसाठी डिझाइन केलेले आहेत जे समान आहेत परंतु एकसारखे नाहीत, जसे की भिन्न मांजर कार्टून किंवा रिअल इस्टेटच्या वेगवेगळ्या तुकड्यांची मालकी हक्क.

या लेखात आपण Ryuya Nakamura च्या ERC-721 कॉन्ट्रॅक्टचे (opens in a new tab) विश्लेषण करू. हे कॉन्ट्रॅक्ट Vyper (opens in a new tab) मध्ये लिहिलेले आहे, जी एक Python-सारखी कॉन्ट्रॅक्ट भाषा आहे, जी Solidity पेक्षा असुरक्षित कोड लिहिणे अधिक कठीण करण्यासाठी डिझाइन केलेली आहे.

कॉन्ट्रॅक्ट

# @dev ERC-721 नॉन-फंजिबल टोकन मानकाची अंमलबजावणी.
# @author Ryuya Nakamura (@nrryuya)
# येथून सुधारित: https://github.com/vyperlang/vyper/blob/de74722bf2d8718cca46902be165f9fe0e3641dd/examples/tokens/ERC721.vy

Vyper मध्ये, Python प्रमाणेच, कमेंट्स हॅश (#) ने सुरू होतात आणि ओळीच्या शेवटपर्यंत चालू राहतात. @<keyword> समाविष्ट असलेल्या कमेंट्स NatSpec (opens in a new tab) द्वारे मानवासाठी वाचनीय डॉक्युमेंटेशन तयार करण्यासाठी वापरल्या जातात.

from vyper.interfaces import ERC721

implements: ERC721

ERC-721 इंटरफेस Vyper भाषेमध्ये अंगभूत आहे. तुम्ही कोडची व्याख्या येथे पाहू शकता (opens in a new tab). इंटरफेसची व्याख्या Vyper ऐवजी Python मध्ये लिहिलेली आहे, कारण इंटरफेस केवळ ब्लॉकचेनमध्येच नव्हे, तर बाह्य क्लायंटकडून ब्लॉकचेनला व्यवहार पाठवताना देखील वापरले जातात, जे Python मध्ये लिहिलेले असू शकतात.

पहिली ओळ इंटरफेस इम्पोर्ट करते आणि दुसरी ओळ नमूद करते की आम्ही येथे त्याची अंमलबजावणी करत आहोत.

ERC721Receiver इंटरफेस

# safeTransferFrom() द्वारे कॉल केलेल्या कॉन्ट्रॅक्टसाठी इंटरफेस
interface ERC721Receiver:
    def onERC721Received(

ERC-721 दोन प्रकारच्या ट्रान्सफरला समर्थन देते:

  • transferFrom, जे प्रेषकाला (sender) कोणतेही डेस्टिनेशन ॲड्रेस निर्दिष्ट करण्याची परवानगी देते आणि हस्तांतरणाची जबाबदारी प्रेषकावर टाकते. याचा अर्थ असा की आपण अवैध ॲड्रेसवर हस्तांतरण करू शकता, अशा परिस्थितीत NFT कायमचा गमावला जातो.
  • safeTransferFrom, जे डेस्टिनेशन ॲड्रेस हे कॉन्ट्रॅक्ट आहे की नाही हे तपासते. तसे असल्यास, ERC-721 कॉन्ट्रॅक्ट प्राप्त करणाऱ्या कॉन्ट्रॅक्टला विचारतो की त्याला NFT प्राप्त करायचा आहे का.

safeTransferFrom विनंत्यांना उत्तर देण्यासाठी प्राप्त करणाऱ्या कॉन्ट्रॅक्टला ERC721Receiver लागू करावे लागते.

            _operator: address,
            _from: address,

_from ॲड्रेस हा टोकनचा सध्याचा मालक आहे. _operator ॲड्रेस तो आहे ज्याने हस्तांतरणाची विनंती केली (अलाउन्समुळे हे दोघे समान नसतील).

            _tokenId: uint256,

ERC-721 टोकन आयडी 256 बिटचे असतात. सामान्यतः टोकन ज्याचे प्रतिनिधित्व करते त्याच्या वर्णनाचे हॅशिंग करून ते तयार केले जातात.

            _data: Bytes[1024]

विनंतीमध्ये 1024 बाइट्सपर्यंत वापरकर्ता डेटा असू शकतो.

        ) -> bytes32: view

एखादा कॉन्ट्रॅक्ट चुकून हस्तांतरण स्वीकारतो अशा प्रकरणांना टाळण्यासाठी, रिटर्न व्हॅल्यू बुलियन नसते, तर एका विशिष्ट व्हॅल्यूसह 256 बिट्स असते.

हे फंक्शन एक view आहे, याचा अर्थ ते ब्लॉकचेनची स्थिती (state) वाचू शकते, परंतु त्यात बदल करू शकत नाही.

इव्हेंट्स

इव्हेंट्स (opens in a new tab) हे ब्लॉकचेनच्या बाहेरील वापरकर्त्यांना आणि सर्व्हरना इव्हेंट्सबद्दल माहिती देण्यासाठी उत्सर्जित केले जातात. लक्षात घ्या की इव्हेंट्सची सामग्री ब्लॉकचेनवरील कॉन्ट्रॅक्टसाठी उपलब्ध नसते.

हे ERC-20 ट्रान्सफर इव्हेंटसारखेच आहे, फक्त आपण रकमेऐवजी tokenId कळवतो. कोणीही शून्य पत्त्याचा मालक नाही, म्हणून प्रथेनुसार आपण त्याचा वापर टोकनची निर्मिती आणि नाश कळवण्यासाठी करतो.

ERC-721 मंजुरी ERC-20 अलाउन्स सारखीच आहे. एका विशिष्ट पत्त्याला एक विशिष्ट टोकन हस्तांतरित करण्याची परवानगी दिली जाते. यामुळे करारांना टोकन स्वीकारल्यावर प्रतिसाद देण्यासाठी एक यंत्रणा मिळते. कॉन्ट्रॅक्ट इव्हेंट ऐकू शकत नाहीत, म्हणून जर तुम्ही फक्त त्यांना टोकन हस्तांतरित केले तर त्यांना त्याबद्दल 'माहित' होत नाही. या प्रकारे मालक प्रथम एक मंजुरी सादर करतो आणि नंतर कॉन्ट्रॅक्टला विनंती पाठवतो: 'मी तुम्हाला टोकन X हस्तांतरित करण्यासाठी मंजूर केले आहे, कृपया ... करा'.

ERC-721 मानकाला ERC-20 मानकासारखे बनवण्यासाठी ही एक डिझाइन निवड आहे. कारण ERC-721 टोकन फंजिबल नाहीत, एक कॉन्ट्रॅक्ट टोकनच्या मालकीकडे पाहून ओळखू शकतो की त्याला एक विशिष्ट टोकन मिळाले आहे.

कधीकधी एक ऑपरेटर असणे उपयुक्त ठरते जो एखाद्या खात्याच्या विशिष्ट प्रकारच्या सर्व टोकनचे व्यवस्थापन करू शकतो (जे विशिष्ट कॉन्ट्रॅक्टद्वारे व्यवस्थापित केले जातात), मुखत्यारपत्राप्रमाणे. उदाहरणार्थ, मला कदाचित अशा कॉन्ट्रॅक्टला अशी शक्ती द्यायची असेल जो तपासतो की मी सहा महिन्यांपासून त्याच्याशी संपर्क साधला आहे की नाही, आणि तसे असल्यास, माझी मालमत्ता माझ्या वारसांना वितरीत करतो (जर त्यापैकी कोणीतरी विचारले, तर कॉन्ट्रॅक्ट व्यवहाराद्वारे कॉल केल्याशिवाय काहीही करू शकत नाहीत). ERC-20 मध्ये आपण फक्त एका वारसा कॉन्ट्रॅक्टला उच्च अलाउन्स देऊ शकतो, परंतु ते ERC-721 साठी काम करत नाही कारण टोकन फंजिबल नाहीत. हे त्याच्या समकक्ष आहे.

approved मूल्य आपल्याला सांगते की इव्हेंट मंजुरीसाठी आहे की मंजुरी मागे घेण्यासाठी आहे.

स्टेट व्हेरिएबल्स

या व्हेरिएबल्समध्ये टोकनची सध्याची स्थिती असते: कोणते उपलब्ध आहेत आणि त्यांचे मालक कोण आहेत. यापैकी बहुतेक HashMap ऑब्जेक्ट्स आहेत, दोन प्रकारांमध्ये अस्तित्वात असलेले एकदिशीय मॅपिंग (opens in a new tab).

# @dev NFT आयडी वरून त्याच्या मालकाच्या पत्त्यावर मॅपिंग.
idToOwner: HashMap[uint256, address]

# @dev NFT आयडी वरून मंजूर केलेल्या पत्त्यावर मॅपिंग.
idToApprovals: HashMap[uint256, address]

Ethereum मध्ये वापरकर्ता आणि कॉन्ट्रॅक्ट ओळख 160-बिट पत्त्यांद्वारे दर्शविली जाते. हे दोन व्हेरिएबल्स टोकन आयडी वरून त्यांच्या मालकांना आणि त्यांना हस्तांतरित करण्यास मंजूर असलेल्यांना (प्रत्येकासाठी जास्तीत जास्त एक) मॅप करतात. Ethereum मध्ये, अनइनिशियलाइज्ड डेटा नेहमी शून्य असतो, म्हणून जर मालक किंवा मंजूर हस्तांतरणकर्ता नसेल तर त्या टोकनसाठी मूल्य शून्य असते.

# @dev मालकाच्या पत्त्यावरून त्याच्या टोकनच्या संख्येवर मॅपिंग.
ownerToNFTokenCount: HashMap[address, uint256]

हे व्हेरिएबल प्रत्येक मालकासाठी टोकनची संख्या ठेवते. मालकांकडून टोकनपर्यंत कोणतेही मॅपिंग नाही, म्हणून विशिष्ट मालकाचे टोकन ओळखण्याचा एकमेव मार्ग म्हणजे ब्लॉकचेनच्या इव्हेंट इतिहासात मागे पाहणे आणि योग्य Transfer इव्हेंट पाहणे. आपल्याकडे सर्व NFTs आहेत आणि आपल्याला वेळेत आणखी मागे पाहण्याची गरज नाही हे जाणून घेण्यासाठी आपण या व्हेरिएबलचा वापर करू शकतो.

लक्षात घ्या की हा अल्गोरिदम फक्त वापरकर्ता इंटरफेस आणि बाह्य सर्व्हरसाठी काम करतो. ब्लॉकचेनवर चालणारा कोड स्वतः मागील इव्हेंट वाचू शकत नाही.

# @dev मालकाच्या पत्त्यावरून ऑपरेटर पत्त्यांच्या मॅपिंगवर मॅपिंग.
ownerToOperators: HashMap[address, HashMap[address, bool]]

एका खात्यात एकापेक्षा जास्त ऑपरेटर असू शकतात. त्यांचा मागोवा ठेवण्यासाठी एक साधे HashMap पुरेसे नाही, कारण प्रत्येक की एकाच मूल्याकडे नेते. त्याऐवजी, तुम्ही मूल्य म्हणून HashMap[address, bool] वापरू शकता. डीफॉल्टनुसार प्रत्येक पत्त्यासाठी मूल्य False असते, याचा अर्थ तो ऑपरेटर नाही. तुम्ही आवश्यकतेनुसार मूल्ये True वर सेट करू शकता.

# @dev मिन्टरचा पत्ता, जो टोकन मिंट करू शकतो
minter: address

नवीन टोकन कोणत्यातरी प्रकारे तयार करावे लागतात. या कॉन्ट्रॅक्टमध्ये एकच संस्था आहे जिला तसे करण्याची परवानगी आहे, ती म्हणजे minter. उदाहरणार्थ, एका खेळासाठी हे पुरेसे असण्याची शक्यता आहे. इतर उद्देशांसाठी, अधिक क्लिष्ट व्यवसाय तर्क तयार करणे आवश्यक असू शकते.

# @dev इंटरफेस आयडी वरून ते समर्थित आहे की नाही याबद्दलच्या bool वर मॅपिंग
supportedInterfaces: HashMap[bytes32, bool]

# @dev ERC165 चा ERC165 इंटरफेस आयडी
ERC165_INTERFACE_ID: constant(bytes32) = 0x0000000000000000000000000000000000000000000000000000000001ffc9a7

# @dev ERC721 चा ERC165 इंटरफेस आयडी
ERC721_INTERFACE_ID: constant(bytes32) = 0x0000000000000000000000000000000000000000000000000000000080ac58cd

ERC-165 (opens in a new tab) एक यंत्रणा निर्दिष्ट करते ज्याद्वारे कॉन्ट्रॅक्ट उघड करू शकतो की ॲप्लिकेशन्स त्याच्याशी कसे संवाद साधू शकतात, तो कोणत्या ERCs चे पालन करतो. या प्रकरणात, कॉन्ट्रॅक्ट ERC-165 आणि ERC-721 चे पालन करतो.

फंक्शन्स

ही ती फंक्शन्स आहेत जी प्रत्यक्षात ERC-721 ची अंमलबजावणी करतात.

कन्स्ट्रक्टर

@external
def __init__():

Vyper मध्ये, Python प्रमाणेच, कन्स्ट्रक्टर फंक्शनला __init__ म्हणतात.

    """
    @dev कॉन्ट्रॅक्ट कन्स्ट्रक्टर.
    """

Python मध्ये, आणि Vyper मध्ये, तुम्ही एक मल्टी-लाइन स्ट्रिंग (जी """ ने सुरू होते आणि संपते) निर्दिष्ट करून आणि कोणत्याही प्रकारे तिचा वापर न करून देखील एक कमेंट तयार करू शकता. या कमेंट्समध्ये NatSpec (opens in a new tab) देखील समाविष्ट असू शकते.

    self.supportedInterfaces[ERC165_INTERFACE_ID] = True
    self.supportedInterfaces[ERC721_INTERFACE_ID] = True
    self.minter = msg.sender

स्टेट व्हेरिएबल्स ऍक्सेस करण्यासाठी तुम्ही self.<variable name> वापरता (पुन्हा, Python प्रमाणेच).

व्ह्यू फंक्शन्स

ही अशी फंक्शन्स आहेत जी ब्लॉकचेनची स्थिती बदलत नाहीत, आणि म्हणून जर त्यांना बाह्यरित्या कॉल केले तर ते विनामूल्य कार्यान्वित केले जाऊ शकतात. जर व्ह्यू फंक्शन्सना कॉन्ट्रॅक्टद्वारे कॉल केले गेले तर त्यांना अजूनही प्रत्येक नोडवर कार्यान्वित करावे लागते आणि म्हणून गॅस खर्च येतो.

@view
@external

फंक्शनच्या व्याख्येपूर्वी हे कीवर्ड जे ऍट चिन्हासह (@) सुरू होतात, त्यांना डेकोरेशन्स म्हणतात. ते फंक्शन कोणत्या परिस्थितीत कॉल केले जाऊ शकते हे निर्दिष्ट करतात.

  • @view निर्दिष्ट करते की हे फंक्शन एक व्ह्यू आहे.
  • @external निर्दिष्ट करते की हे विशिष्ट फंक्शन व्यवहार आणि इतर कॉन्ट्रॅक्टद्वारे कॉल केले जाऊ शकते.
def supportsInterface(_interfaceID: bytes32) -> bool:

Python च्या उलट, Vyper ही एक स्टॅटिक टाइप केलेली भाषा (opens in a new tab) आहे. तुम्ही डेटा प्रकार (opens in a new tab) ओळखल्याशिवाय व्हेरिएबल किंवा फंक्शन पॅरामीटर घोषित करू शकत नाही. या प्रकरणात इनपुट पॅरामीटर bytes32 आहे, जे 256-बिट मूल्य आहे (256 बिट्स हे Ethereum व्हर्च्युअल मशीन चा मूळ शब्द आकार आहे). आउटपुट एक बुलियन मूल्य आहे. प्रथेनुसार, फंक्शन पॅरामीटर्सची नावे अंडरस्कोर (_) ने सुरू होतात.

    """
    @dev इंटरफेस ओळख ERC-165 मध्ये निर्दिष्ट आहे.
    @param _interfaceID इंटरफेसचा आयडी
    """
    return self.supportedInterfaces[_interfaceID]

self.supportedInterfaces HashMap मधून मूल्य परत करा, जे कन्स्ट्रक्टर (__init__) मध्ये सेट केलेले आहे.

### व्ह्यू फंक्शन्स ###

ही व्ह्यू फंक्शन्स आहेत जी टोकनबद्दलची माहिती वापरकर्त्यांना आणि इतर कॉन्ट्रॅक्टसना उपलब्ध करून देतात.

ही ओळ asserts (opens in a new tab) करते की _owner शून्य नाही. जर ते असेल, तर एक त्रुटी आहे आणि ऑपरेशन परत घेतले जाते.

Ethereum व्हर्च्युअल मशीनमध्ये (evm) कोणतेही स्टोरेज ज्यामध्ये मूल्य संग्रहित नाही ते शून्य असते. जर _tokenId वर कोणतेही टोकन नसेल तर self.idToOwner[_tokenId] चे मूल्य शून्य असते. त्या प्रकरणात फंक्शन परत जाते.

लक्षात घ्या की getApproved शून्य परत करू शकते. जर टोकन वैध असेल तर ते self.idToApprovals[_tokenId] परत करते. जर कोणताही मंजूर करणारा नसेल तर ते मूल्य शून्य असते.

हे फंक्शन तपासते की _operator ला या कॉन्ट्रॅक्टमधील _owner च्या सर्व टोकनचे व्यवस्थापन करण्याची परवानगी आहे की नाही. कारण एकापेक्षा जास्त ऑपरेटर असू शकतात, हे दोन-स्तरीय HashMap आहे.

हस्तांतरण सहाय्यक फंक्शन्स

ही फंक्शन्स टोकन हस्तांतरित करण्याच्या किंवा व्यवस्थापित करण्याच्या भागाच्या क्रियांची अंमलबजावणी करतात.


### हस्तांतरण फंक्शन सहाय्यक ###

@view
@internal

हे डेकोरेशन, @internal, याचा अर्थ असा की फंक्शन फक्त त्याच कॉन्ट्रॅक्टमधील इतर फंक्शन्समधूनच ऍक्सेसिबल आहे. प्रथेनुसार, या फंक्शनची नावे देखील अंडरस्कोर (_) ने सुरू होतात.

एका पत्त्याला टोकन हस्तांतरित करण्याची परवानगी देण्याचे तीन मार्ग आहेत:

  1. पत्ता टोकनचा मालक आहे
  2. ते टोकन खर्च करण्यासाठी पत्त्याला मंजुरी आहे
  3. पत्ता टोकनच्या मालकासाठी एक ऑपरेटर आहे

वरील फंक्शन एक व्ह्यू असू शकते कारण ते स्थिती बदलत नाही. कार्य खर्च कमी करण्यासाठी, जे कोणतेही फंक्शन व्ह्यू असू शकते ते व्ह्यू असले पाहिजे.

जेव्हा हस्तांतरणामध्ये समस्या येते तेव्हा आम्ही कॉल परत घेतो.

आवश्यक असल्यास फक्त मूल्य बदला. स्टेट व्हेरिएबल्स स्टोरेजमध्ये राहतात. स्टोरेजमध्ये लिहिणे ही EVM (Ethereum व्हर्च्युअल मशीन) च्या सर्वात महागड्या क्रियांपैकी एक आहे (gas च्या बाबतीत). म्हणून, ते कमी करणे ही एक चांगली कल्पना आहे, अगदी विद्यमान मूल्य लिहिण्याचा खर्चही जास्त आहे.

आपल्याकडे हे अंतर्गत फंक्शन आहे कारण टोकन हस्तांतरित करण्याचे दोन मार्ग आहेत (नियमित आणि सुरक्षित), परंतु आम्हाला कोडमध्ये फक्त एकच स्थान हवे आहे जेथे आपण ते करतो जेणेकरून ऑडिट करणे सोपे होईल.

Vyper मध्ये इव्हेंट उत्सर्जित करण्यासाठी तुम्ही log स्टेटमेंट वापरता (अधिक तपशिलांसाठी येथे पहा (opens in a new tab)).

हस्तांतरण फंक्शन्स

हे फंक्शन तुम्हाला एका अनियंत्रित पत्त्यावर हस्तांतरित करण्याची परवानगी देते. जोपर्यंत पत्ता वापरकर्त्याचा किंवा टोकन कसे हस्तांतरित करायचे हे जाणणाऱ्या कॉन्ट्रॅक्टचा नसेल, तोपर्यंत तुम्ही हस्तांतरित केलेले कोणतेही टोकन त्या पत्त्यात अडकून निरुपयोगी होईल.

प्रथम हस्तांतरण करणे ठीक आहे कारण जर काही समस्या आली तर आपण तरीही परत घेणार आहोत, त्यामुळे कॉलमध्ये केलेले सर्वकाही रद्द होईल.

        if _to.is_contract: # `_to` हा कॉन्ट्रॅक्ट पत्ता आहे की नाही हे तपासा

प्रथम पत्ता कॉन्ट्रॅक्ट आहे की नाही हे तपासा (त्यात कोड आहे का). नसल्यास, तो वापरकर्त्याचा पत्ता आहे असे समजा आणि वापरकर्ता टोकन वापरू शकेल किंवा हस्तांतरित करू शकेल. पण ते तुम्हाला खोट्या सुरक्षिततेच्या भावनेत अडकू देऊ नका. तुम्ही टोकन गमावू शकता, अगदी safeTransferFrom सह देखील, जर तुम्ही त्यांना अशा पत्त्यावर हस्तांतरित केले ज्याची खाजगी की कोणालाही माहित नाही.

        returnValue: bytes32 = ERC721Receiver(_to).onERC721Received(msg.sender, _from, _tokenId, _data)

लक्ष्य कॉन्ट्रॅक्टला ERC-721 टोकन प्राप्त करू शकतो की नाही हे पाहण्यासाठी कॉल करा.

# हस्तांतरणाचे गंतव्यस्थान असा कॉन्ट्रॅक्ट असल्यास जो 'onERC721Received' लागू करत नाही, तर थ्रो करते
        assert returnValue == method_id("onERC721Received(address,address,uint256,bytes)", output_type=bytes32)

जर गंतव्यस्थान एक कॉन्ट्रॅक्ट असेल, परंतु जो ERC-721 टोकन स्वीकारत नाही (किंवा ज्याने हे विशिष्ट हस्तांतरण न स्वीकारण्याचा निर्णय घेतला आहे), तर परत घ्या.

प्रथेनुसार, जर तुम्हाला मंजूर करणारा नको असेल तर तुम्ही शून्य पत्ता नियुक्त करता, स्वतःला नाही.

    # आवश्यकता तपासा
    senderIsOwner: bool = self.idToOwner[_tokenId] == msg.sender
    senderIsApprovedForAll: bool = (self.ownerToOperators[owner])[msg.sender]
    assert (senderIsOwner or senderIsApprovedForAll)

मंजुरी सेट करण्यासाठी तुम्ही एकतर मालक असू शकता किंवा मालकाने अधिकृत केलेला ऑपरेटर असू शकता.

नवीन टोकन मिंट करणे आणि विद्यमान टोकन नष्ट करणे

ज्या खात्याने कॉन्ट्रॅक्ट तयार केले आहे तो minter आहे, जो नवीन NFTs मिंट करण्यासाठी अधिकृत सुपर वापरकर्ता आहे. तथापि, त्यालाही विद्यमान टोकन बर्न करण्याची परवानगी नाही. फक्त मालक, किंवा मालकाने अधिकृत केलेली संस्था, ते करू शकते.

### मिंट आणि बर्न फंक्शन्स ###

@external
def mint(_to: address, _tokenId: uint256) -> bool:

हे फंक्शन नेहमी True परत करते, कारण जर ऑपरेशन अयशस्वी झाले तर ते परत घेतले जाते.

फक्त मिन्टर (ज्या खात्याने ERC-721 कॉन्ट्रॅक्ट तयार केले आहे) नवीन टोकन मिंट करू शकतो. भविष्यात जर आपल्याला मिन्टरची ओळख बदलायची असेल तर ही एक समस्या असू शकते. एका प्रोडक्शन कॉन्ट्रॅक्टमध्ये तुम्हाला कदाचित असे फंक्शन हवे असेल जे मिन्टरला मिन्टरचे विशेषाधिकार दुसऱ्या कोणालातरी हस्तांतरित करण्याची परवानगी देईल.

    # `_to` शून्य पत्ता असल्यास थ्रो करते
    assert _to != ZERO_ADDRESS
    # NFT जोडा. `_tokenId` कोणाच्यातरी मालकीचा असल्यास थ्रो करते
    self._addTokenTo(_to, _tokenId)
    log Transfer(ZERO_ADDRESS, _to, _tokenId)
    return True

प्रथेनुसार, नवीन टोकनचे मिंटिंग शून्य पत्त्यावरून हस्तांतरण म्हणून गणले जाते.

ज्यालाही टोकन हस्तांतरित करण्याची परवानगी आहे त्याला ते बर्न करण्याची परवानगी आहे. बर्न हे शून्य पत्त्यावर हस्तांतरणासारखे दिसत असले तरी, शून्य पत्त्याला प्रत्यक्षात टोकन मिळत नाही. हे आपल्याला टोकनसाठी वापरलेले सर्व स्टोरेज मोकळे करण्याची परवानगी देते, ज्यामुळे व्यवहाराचा गॅस खर्च कमी होऊ शकतो.

हे कॉन्ट्रॅक्ट वापरणे

Solidity च्या उलट, Vyper मध्ये इनहेरिटन्स नाही. कोड अधिक स्पष्ट आणि त्यामुळे सुरक्षित करणे सोपे करण्यासाठी ही एक जाणीवपूर्वक केलेली डिझाइन निवड आहे. म्हणून तुमचा स्वतःचा Vyper ERC-721 कॉन्ट्रॅक्ट तयार करण्यासाठी तुम्ही हा कॉन्ट्रॅक्ट (opens in a new tab) घ्या आणि तुम्हाला हव्या असलेल्या व्यवसाय तर्काची अंमलबजावणी करण्यासाठी त्यात बदल करा.

निष्कर्ष

पुनरावलोकनासाठी, या कॉन्ट्रॅक्टमधील काही सर्वात महत्त्वाचे विचार येथे आहेत:

  • सुरक्षित हस्तांतरणासह ERC-721 टोकन प्राप्त करण्यासाठी, कॉन्ट्रॅक्ट्सना ERC721Receiver इंटरफेस लागू करावा लागतो.
  • तुम्ही सुरक्षित हस्तांतरण वापरत असलात तरीही, टोकन अडकू शकतात जर तुम्ही त्यांना अशा पत्त्यावर पाठवले ज्याची खाजगी की अज्ञात आहे.
  • जेव्हा ऑपरेशनमध्ये समस्या येते तेव्हा फक्त अयशस्वी मूल्य परत करण्याऐवजी कॉल revert करणे ही एक चांगली कल्पना आहे.
  • ERC-721 टोकन तेव्हा अस्तित्वात असतात जेव्हा त्यांचा मालक असतो.
  • NFT हस्तांतरित करण्यासाठी अधिकृत होण्याचे तीन मार्ग आहेत. तुम्ही मालक असू शकता, विशिष्ट टोकनसाठी मंजूर असू शकता, किंवा मालकाच्या सर्व टोकनसाठी ऑपरेटर असू शकता.
  • मागील इव्हेंट फक्त ब्लॉकचेनच्या बाहेर दिसतात. ब्लॉकचेनच्या आत चालणारा कोड ते पाहू शकत नाही.

आता जा आणि सुरक्षित Vyper कॉन्ट्रॅक्ट्स लागू करा.

माझ्या कामाबद्दल अधिक माहितीसाठी येथे पहा (opens in a new tab).

पृष्ठ शेवटचे अपडेट: 28 एप्रिल, 2026

हे ट्युटोरियल उपयुक्त होते का?