NFTs (नॉन-फंजिबल टोकन) के लिए ERC-721 मानक प्रस्तावित किया गया था। एनएफटी उन टोकन को संदर्भित करता है जो अद्वितीय हैं, जिसका अर्थ है कि स्मार्ट अनुबंध के अंदर प्रत्येक टोकन दूसरों से अलग होगा। इसका उपयोग अनूठी चीजों की पहचान करने के लिए किया जा सकता है, उदाहरण के लिए, किसी प्रकार की छवि, लॉटरी टिकट, संग्रहणता, पेंटिंग, या यहां तक कि संगीत आदि। ERC-20 पर लेख तो पहले इसे पढ़ने पर विचार करें। ERC-721 उदाहरण के लिए सबसे अच्छी वास्तविक दुनिया की परियोजना क्रिप्टोकरंसी है। यह ब्लॉकचेन के शीर्ष पर एक गेम है, आनंद के साथ ज्ञान के लिए इस अद्भुत गेम को देखें।

लेकिन यह कैसे काम करता है? स्मार्ट अनुबंधों में ये चित्र, संगीत और चित्र कैसे संग्रहीत किए जाते हैं?

ठीक है, इन चीजों को अनुबंध के अंदर संग्रहीत नहीं किया जाता है, बल्कि अनुबंध केवल बाहरी संपत्ति की ओर इशारा करता है। एक संख्या है, tokenId स्वामित्व दिखा रहा है। मुख्य संपत्ति छवि या कुछ अन्य डेटा है जो यूआरआई के माध्यम से टोकन आईडी से जुड़ा हुआ है। आइए थोड़ा और गोता लगाएँ।

हम टोकन आईडी के लिए एक यूआरआई, जो एक JSON टेक्स्ट है, असाइन करते हैं। और उस JSON टेक्स्ट में छवि या किसी अन्य संपत्ति का विवरण और पथ शामिल है। और उपयोगकर्ता केवल tokenid मालिक है। उदाहरण के लिए, मेरे पते में tokenid 4 का संतुलन है, अब उस tokenid से जुड़ी छवि या किसी भी प्रकार का डेटा मेरा होगा। मैं उस डेटा का स्वामी हूं क्योंकि मेरे पास tokenid है।

अब हमें इन दो चीजों यानी इमेज और JSON टेक्स्ट (URI) को कहीं स्टोर करना होगा ताकि कोई भी NFT मार्केटप्लेस इमेज को प्राप्त कर सके और इसे अपनी वेबसाइट पर प्रदर्शित कर सके। आप सोच रहे होंगे कि हमें मेटाडेटा यूआरआई की आवश्यकता क्यों है, क्यों न सीधे छवि यूआरआई को टोकन आईडी पर असाइन किया जाए? ठीक है, आपको याद होगा कि हमें पहले ईआरसी मानकों की आवश्यकता क्यों थी, हां, ताकि क्लाइंट-साइड एप्लिकेशन के लिए अनुबंधों से जुड़ना आसान हो जाए। इसी तरह, एनएफटी के लिए हम जो मेटाडेटा लिखते हैं, वह एनएफटी मार्केटप्लेस द्वारा अनुशंसित उचित प्रारूप में होना चाहिए ताकि वे आसानी से उस JSON फ़ाइल से डेटा प्राप्त कर सकें और डेटा को अपनी साइट पर प्रदर्शित कर सकें।

आइए अब स्टोरेज चीज देखें।

डेटा संग्रहीत करना

इमेज और URI को स्टोर करने के दो तरीके हैं। हम या तो इसे ऑन-चेन (ब्लॉकचैन के अंदर) या ऑफ-चेन (ब्लॉकचेन के बाहर) होस्ट कर सकते हैं।

ऑन-चेन डेटा को ब्लॉकचेन में संग्रहीत किया जाता है लेकिन यह बहुत अधिक स्थान लेता है जो कि वहन करने योग्य नहीं है। अपने अनुबंध की तैनाती के समय हजारों डॉलर का भुगतान करने के बारे में सोचें। अच्छा नहीं लगता। इसके अलावा ब्लॉकचेन सीमित स्टोरेज भी प्रदान करता है, इसमें आप बड़ी फाइल्स को स्टोर नहीं कर सकते हैं।

इसलिए हमारे पास ब्लॉकचेन के बाहर डेटा को होस्ट करने का विकल्प है। AWS या किसी अन्य क्लाउड सेवा का उपयोग करके हमारी वेबसाइट के माध्यम से। लेकिन यह एक ब्लॉकचेन यानी विकेंद्रीकरण के मुख्य विचार को खत्म कर देता है। क्या होगा अगर सर्वर क्रैश हो जाए या कोई इसे हैक कर ले? चूंकि सभी डेटा को होस्ट करने वाला एक ही सर्वर होगा। इसलिए हमें कुछ और चाहिए जो हमलों के लिए मजबूत हो और विकेंद्रीकृत भी हो और वह कुछ आईपीएफएस (इंटर प्लैनेटरी फाइल सिस्टम) है जो एक वितरित भंडारण प्रणाली है। IPFS में डेटा को स्टोर करने वाले ब्लॉकचेन के विचार के समान कई नोड हैं। लेकिन आपको कोई फीस नहीं देनी होगी। हम IPFS पर अपनी छवियों और JSON फ़ाइल (URI) को भी होस्ट कर सकते हैं और ऐसा करने से एक विशिष्ट CID (रैंडम जिबरिश) मिलेगी जो सीधे डेटा की ओर इशारा करती है और हम एक विशेष टोकन Id को एक विशेष CID निर्दिष्ट करते हैं। हम बाद में तकनीकी भाग के बारे में अधिक बात करेंगे, पहले ERC-721 मानक के लिए इंटरफ़ेस को समझते हैं।

ईआरसी-721 इंटरफ़ेस

आइए देखें कि ERC-721 इंटरफ़ेस कैसा दिखता है।

इस मानक में निम्नलिखित कार्य हैं:

1. टोकन को एक खाते से दूसरे खाते में स्थानांतरित करना।

2. किसी खाते का वर्तमान टोकन शेष प्राप्त करना।

3. एक विशिष्ट टोकन के स्वामी को प्राप्त करना।

4. नेटवर्क पर उपलब्ध टोकन की कुल आपूर्ति।

5. इनके अलावा, इसकी कुछ अन्य कार्यात्मकताएँ भी हैं जैसे यह स्वीकृति देना कि किसी खाते से टोकन की राशि को किसी तीसरे पक्ष के खाते द्वारा स्थानांतरित किया जा सकता है।

   
   

आइए अब ERC-721 के इंटरफ़ेस पर एक नज़र डालते हैं।

 pragma solidity ^0.4.20; interface ERC721 { event Transfer(address indexed _from, address indexed _to, uint256 indexed _tokenId); event Approval(address indexed _owner, address indexed _approved, uint256 indexed _tokenId); event ApprovalForAll(address indexed _owner, address indexed _operator, bool _approved); function balanceOf(address _owner) external view returns (uint256); function ownerOf(uint256 _tokenId) external view returns (address); function safeTransferFrom(address _from, address _to, uint256 _tokenId, bytes data) external payable; function safeTransferFrom(address _from, address _to, uint256 _tokenId) external payable; function transferFrom(address _from, address _to, uint256 _tokenId) external payable; function approve(address _approved, uint256 _tokenId) external payable; function setApprovalForAll(address _operator, bool _approved) external; function getApproved(uint256 _tokenId) external view returns (address); function isApprovedForAll(address _owner, address _operator) external view returns (bool); } Break

टूट - फूट

1. बैलेंसऑफ मालिक के खाते में टोकन की संख्या लौटाता है। हम संतुलन का ट्रैक कैसे रखते हैं? ठीक है, यह हमेशा समान होता है, हम एक मैपिंग को परिभाषित करते हैं जो बटुए में टोकन की कुल संख्या को ट्रैक करता है। मैपिंग (पता => uint) सार्वजनिक शेष राशि; याद रखें, यह सिर्फ टोकन की कुल संख्या का योग करता है और उसी को लौटाता है, यह मैपिंग टोकन के मालिकों के बारे में नहीं जानता है क्योंकि यह सिर्फ टोकन आईडी की संख्या बताता है जो एक पते पर है।

function balanceOf(address _owner) external view returns (uint256);

2. OwnerOf एनएफटी के मालिक को ढूंढता है। अब, यह फ़ंक्शन हमें किसी विशेष NFT के स्वामी के बारे में बताता है। हम इस डेटा को उपरोक्त के समान रखते हैं। मानचित्रण (uint => पता) सार्वजनिक शेष राशि; शून्य पतों को सौंपे गए एनएफटी को अमान्य माना जाता है, और उनके बारे में पूछताछ में त्रुटि होनी चाहिए।

function ownerOf(uint256 _tokenId) external view returns (address);

3. safeTransferFrom एनएफटी के स्वामित्व को एक पते से दूसरे पते पर स्थानांतरित करता है। इसे सिर्फ एक टोकन आईडी के मालिक को नए पते पर सेट करना चाहिए और balances मैपिंग को भी अपडेट करना चाहिए। इसे निम्नलिखित मामलों में एक त्रुटि फेंकनी चाहिए:

• msg.sender वर्तमान स्वामी, एक अधिकृत ऑपरेटर या इस NFT के लिए स्वीकृत पता है
• _from वर्तमान स्वामी नहीं है
• __to_ शून्य पता है।
• __tokenId_ मान्य NFT नहीं है

जब स्थानांतरण पूरा हो जाता है, तो यह फ़ंक्शन जाँचता है कि क्या __to_ एक स्मार्ट अनुबंध है (कोड आकार> 0)। यदि ऐसा है, तो यह __to_ पर onERC721Received फ़ंक्शन को कॉल करता है और यदि वापसी मान इसके बराबर नहीं है तो फेंकता है: bytes4(keccak256("onERC721Received(address, address,uint256, bytes)")).

यह क्या था? इसलिए फ़ंक्शन को सुरक्षित स्थानांतरण कहा जाता है, हम इसके बारे में बाद में बात करेंगे।

function safeTransferFrom(address _from, address _to, uint256 _tokenId, bytes data) external payable;

4. safeTransferFrom : यह एक अतिरिक्त डेटा पैरामीटर के साथ उपरोक्त फ़ंक्शन के समान ही काम करता है, सिवाय इसके कि यह फ़ंक्शन डेटा को "" पर सेट करता है।

function safeTransferFrom(address _from, address _to, uint256 _tokenId) external payable;

इन दो कार्यों का एक ही नाम कैसे है?

मजेदार तथ्य: जावास्क्रिप्ट के विपरीत, सॉलिडिटी फंक्शन ओवरलोडिंग का समर्थन करती है। इसका मतलब है कि हम दो कार्यों को एक ही नाम से परिभाषित कर सकते हैं, केवल शर्त यह है कि पैरामीटर अलग-अलग होने चाहिए, जिससे फ़ंक्शन हस्ताक्षर में फर्क पड़ता है। पता नहीं क्या समारोह हस्ताक्षर हैं? हेयर यू गो। उत्तर देने के लिए लिंक

5. ट्रांसफरफ्रॉम एक एनएफटी के स्वामित्व को स्थानांतरित करता है। safeTransferFrom फ़ंक्शन के समान काम करता है, केवल अंतर यह प्राप्तकर्ता पर सुरक्षा कॉल ( onERC721Received ) को कॉल नहीं करता है। इस प्रकार, NFT को खोने का जोखिम पैदा करता है।

function transferFrom(address _from, address _to, uint256 _tokenId) external payable;

6. ERC20 अनुमोदन समारोह के समान अवधारणा को अनुमोदित करें लेकिन अधिक कार्यक्षमता और तर्क के साथ। इस फ़ंक्शन के काम करने के लिए हम नेस्टेड मैपिंग को परिभाषित करते हैं: mapping(uint =>address) internal allowance; इस मैपिंग में, uint टोकन आईडी और उस विशेष टोकन आईडी पर संचालन करने के लिए स्वीकृत पते को संदर्भित करता है। इस अनुमोदन समारोह को यह जांचना चाहिए कि msg.sender टोकन के मालिक के लिए मौजूदा मालिक या ऑपरेटर है। अगर यह चेक पास हो जाता है तभी मैपिंग को अपडेट किया जाना चाहिए। यहाँ ऑपरेटर क्या है? अगला समारोह देखें।

function approve(address _approved, uint256 _tokenId) external payable;

7. setApprovalForAll पिछले अनुमोदन फ़ंक्शन की तरह काम करता है, लेकिन एक टोकन आईडी के लिए एक पते को मंजूरी देने के बजाय, इस फ़ंक्शन को एक विशेष पते के स्वामित्व वाले सभी टोकन को संभालने के लिए स्वीकृति और पता होना चाहिए। इसका मतलब क्या है? इसका मतलब है कि आप अपने एनएफटी के लिए एक एड्रेस ऑपरेटर बना सकते हैं। जब तक आप स्वामित्व को रद्द नहीं करते तब तक वह पता आपके एनएफटी का स्वामी होगा। इस बार हम फिर से मैपिंग का उपयोग करते हैं: mapping(address => mapping(address=>bool))internal operator; पहला पता क्रमशः स्वीकृत या निरस्त करने के लिए दूसरे पते के लिए बूलियन को सही या गलत सेट करता है।

function setApprovalForAll(address _operator, bool _approved) external;

8. GetApproved ERC-20 इंटरफ़ेस में अलाउंस फ़ंक्शन के समान है। एकल NFT के लिए स्वीकृत address लौटाता है। यह उस मैपिंग की जांच करता है जिसे हमने उपरोक्त स्वीकृति समारोह में अपडेट किया था।

function getApproved(uint256 _tokenId) external view returns (address);

9. isApprovedForAll उपरोक्त फ़ंक्शन के समान है। यह पूछताछ करता है कि क्या कोई address किसी अन्य address के लिए अधिकृत operator है। किसी विशेष tokenId के स्वीकृत address वापस करने के बजाय, इस फ़ंक्शन को दिए गए address के लिए operator का address वापस करना चाहिए जिसे हमने setApprovalForAll फ़ंक्शन पर अपडेट किया था

function isApprovedForAll(address _owner, address _operator) external view returns (bool);

ईआरसी-721 के लिए घटनाक्रम

स्थानांतरण: किसी तंत्र द्वारा किसी NFT के स्वामित्व में परिवर्तन होने पर उत्सर्जित होता है। यह घटना तब निकलती है जब NFTs (from == 0) बनते हैं और नष्ट हो जाते हैं (to == 0). अपवाद : अनुबंध निर्माण के दौरान, किसी भी संख्या में NFTs बनाए जा सकते हैं और ट्रांसफर किए बिना असाइन किए जा सकते हैं। किसी भी हस्तांतरण के समय, उस एनएफटी (यदि कोई हो) के लिए स्वीकृत पता शून्य पर रीसेट हो जाता है।

event Transfer(address indexed _from, address indexed _to, uint256 indexed _tokenId);

स्वीकृति तब निकलती है जब एनएफटी के लिए स्वीकृत पता बदल दिया जाता है या फिर से पुष्टि की जाती है। शून्य पता इंगित करता है कि कोई स्वीकृत पता नहीं है। जब एक स्थानांतरण घटना निकलती है, तो यह भी इंगित करता है कि उस एनएफटी (यदि कोई हो) के लिए स्वीकृत पता शून्य पर रीसेट हो गया है।

event Approval(address indexed _owner, address indexed _approved, uint256 indexed _tokenId);

जब कोई ऑपरेटर किसी स्वामी के लिए सक्षम या अक्षम होता है तो ApproveForAll उत्सर्जित होता है। ऑपरेटर स्वामी के सभी एनएफटी का प्रबंधन कर सकता है।

event ApprovalForAll(address indexed _owner, address indexed _operator, bool _approved);

यह ERC 721 अनुबंधों के लिए इंटरफ़ेस था। आइए अब इसके कार्यान्वयन और नियमों के बारे में और जानें।

ERC721 टोकन रिसीवर

लागू करने से पहले एक बात और है। याद रखें जब हमने टोकन स्थानांतरित करने के बारे में बात की थी तो हमने onERC721Received नामक फ़ंक्शन के बारे में बात की थी? चलिए अब इसके बारे में बात करते हैं। यदि ERC-721 टोकन का प्राप्तकर्ता एक अनुबंध है तो उसे ERC-721 टोकन के साथ कार्य करने की आवश्यकता है। क्योंकि उस रिसीवर अनुबंध में टोकन के साथ बातचीत करने के लिए कोई कार्यक्षमता नहीं होने पर क्या होगा? टोकन उस अनुबंध में हमेशा के लिए बंद हो जाएंगे। कोई भी उन टोकन को किसी भी पते पर नहीं ले जा सकता क्योंकि कोई कार्यक्षमता नहीं है। इस भेद्यता को दूर करने के लिए, ERC-721 टोकन के प्राप्तकर्ता को रिसीवर इंटरफ़ेस लागू करना चाहिए, यदि नहीं तो गैर अनुबंध उस अनुबंध को कोई ERC-721 टोकन भेज सकते हैं। आइए रिसीवर इंटरफ़ेस देखें।

इस इंटरफ़ेस में लागू करने के लिए केवल एक फ़ंक्शन है और वह onERC721Received है, इस फ़ंक्शन को NFT की प्राप्ति को संभालना चाहिए। ERC-721 स्मार्ट अनुबंध transfer के बाद प्राप्तकर्ता पर इस फ़ंक्शन को कॉल करता है। यह फ़ंक्शन स्थानांतरण को वापस करने और अस्वीकार करने के लिए फेंक सकता है। जादुई मूल्य के अलावा अन्य रिटर्न के परिणामस्वरूप लेन-देन वापस किया जाना चाहिए।

 interface ERC721TokenReceiver { function onERC721Received(address _operator,address _from,uint256 _tokenId,bytes _data) external returns(bytes4); }

यहाँ आप सोच रहे होंगे कि टोकन अनुबंध को कैसे पता चलेगा कि रिसीवर ने ERC721TokenReceiver इंटरफ़ेस लागू किया है या नहीं? इसलिए टोकन भेजने से पहले आपको पहले इस हिस्से की जांच करनी होगी। इसके लिए आइए ERC-721 के openzeppelin कार्यान्वयन को देखें। यहां निजी कार्य है जिसे आपको टोकन भेजने से पहले safeTransfer() के अंदर कॉल करना चाहिए। यदि यह सही होता है तभी लेन-देन होना चाहिए।

ठीक है, यह एनएफटी को रिसीवर अनुबंध से बाहर करने की कार्यक्षमता की गारंटी नहीं देता है क्योंकि यह केवल रिसीवर फ़ंक्शन के कार्यान्वयन की जांच कर रहा है, लेकिन एनएफटी को अनुबंध से बाहर स्थानांतरित करने की कार्यक्षमता नहीं है। तो इसका क्या महत्व है? यह विधि हमें बता सकती है कि प्राप्तकर्ता अनुबंध के लेखक को कम से कम इस विधि के बारे में पता था, जिसका अर्थ है कि उन्होंने एनएफटी को अनुबंध से बाहर स्थानांतरित करने की कार्यक्षमता को लागू किया होगा। और निश्चित रूप से, कोई भी नहीं चाहेगा कि उनके टोकन अनुबंध के अंदर फंस जाएं।

ERC721मेटाडेटा और ERC721गणनीय

ERC-721 टोकन अनुबंध के लिए उपरोक्त इंटरफेस अनिवार्य थे। अब, कुछ इंटरफेस सैद्धांतिक रूप से वैकल्पिक हैं लेकिन अनुबंध को अधिक स्पष्ट और अधिक प्रयोग करने योग्य बनाते हैं।

ये ERC721Metadata और ERC721Enumerable हैं। आइए उन्हें एक-एक करके पकड़ें।

1. ERC721 मेटाडेटा: मेटाडेटा एक्सटेंशन का उपयोग मुख्य रूप से टोकन नाम के अनुबंध की पूछताछ के लिए किया जाता है। अब आइए मेटाडेटा इंटरफ़ेस देखें। यह समझने में काफी सरल है।

 interface ERC721Metadata/* is ERC721 */ { /// @notice A descriptive name for a collection of NFTs in this /// contract function name()external view returns (string _name); /// @notice An abbreviated name for NFTs in this contract function symbol()external view returns (string _symbol); /// @notice A distinct Uniform Resource Identifier (URI) for a given /// asset. /// @dev Throws if `_tokenId` is not a valid NFT. URIs are defined /// in RFC3986. The URI may point to a JSON file that conforms to /// the "ERC721Metadata JSON Schema". function tokenURI(uint256 _tokenId)external view returns (string);

2. ERC721Enumerable- यह सिर्फ NFTs के बारे में डेटा देता है।

    interface ERC721Enumerable/* is ERC721 */ { /// @notice Count NFTs tracked by this contract /// @return A count of valid NFTs tracked by this contract, where /// each one of them has an assigned and queryable owner not equal /// to the zero address function totalSupply()external view returns (uint256); /// @notice Enumerate valid NFTs /// @dev Throws if `_index` >= `totalSupply()`. /// @param _index A counter less than `totalSupply()` /// @return The token identifier for the `_index`th NFT, /// (sort order not specified) function tokenByIndex(uint256 _index)external view returns (uint256); /// @notice Enumerate NFTs assigned to an owner /// @dev Throws if `_index` >= `balanceOf(_owner)` or if /// `_owner` is the zero address, representing invalid NFTs. /// @param _owner An address where we are interested in NFTs owned /// by them /// @param _index A counter less than `balanceOf(_owner)` /// @return The token identifier for the `_index`th NFT assigned to /// `_owner`, /// (sort order not specified) function tokenOfOwnerByIndex(address _owner,uint256 _index)external view returns(uint256);

ईआरसी 165

अब, हम कैसे जानेंगे कि एक अनुबंध द्वारा एक इंटरफ़ेस लागू किया गया है या नहीं? इसके लिए हमें विषय यानी ERC-165 से हटना होगा, जिसका एक कार्य है:

function supportsInterface(bytes4 interfaceID) external view returns (bool);

यह फ़ंक्शन उस इंटरफ़ेस को लेता है जिसे आप एक तर्क के रूप में जांचना चाहते हैं और इसे उस इंटरफ़ेस से मिलाता है जिसे आप जांचना चाहते हैं। मैं आपको बताउंगा कि इंटरफ़ेस आईडी क्या है, मेरे साथ रहें। पहले openzeppelin द्वारा इस फ़ंक्शन के कार्यान्वयन को देखें।

आइए इस फ़ंक्शन type(IERC721).interfaceId Id में इंटरफ़ेस आईडी के बारे में अधिक समझें;

इंटरफ़ेस आईडी दो मुख्य परिचालनों द्वारा प्राप्त किया जाता है।

1. केकेक 256 हैश

2. एक्सओआर ऑपरेशन

keccak256 एक एल्गोरिथ्म है जो एक इनपुट लेता है और बाइट्स में कुछ यादृच्छिक स्ट्रिंग बाहर निकालता है। अब आइए इस फ़ंक्शन के लिए केकेक हैश का पता लगाएं।

function supportsInterface(bytes4 interfaceID) external view returns (bool);

वाक्य-विन्यास कुछ इस तरह दिखता है।

bytes4(keccak256('supportsInterface(bytes4)') ;

अब हमारे पास इस कार्य के लिए कीकेक हैश है। याद रखें, आपको keccak256 के पैरामीटर के अंदर पूरे फ़ंक्शन को पास करने की ज़रूरत नहीं है, लेकिन केवल हस्ताक्षर। हस्ताक्षर का अर्थ केवल नाम और पैरामीटर प्रकार है, पैरामीटर का नाम भी शामिल नहीं है। सभी कार्यों के keccak256 हैश प्राप्त करने के बाद हम उनके बीच XOR ऑपरेशन करते हैं और परिणाम हमें प्राप्त होता है जो कि इंटरफ़ेसआईड है। आइए देखें कैसे। XOR ऑपरेशन इनपुट लेते हैं और उनकी तुलना करने के बाद कुछ आउटपुट देते हैं। यह true आउटपुट करता है यदि एक, और केवल एक इनपुट सत्य है। यदि दोनों इनपुट असत्य हैं या दोनों सत्य हैं, तो आउटपुट false निकलता है।

आपको XOR के गणित को समझने की ज़रूरत नहीं है। बस याद रखें, आप प्रत्येक फ़ंक्शन का keccak256 हैश लेते हैं और उन्हें XOR गेट पर पास करते हैं और आपको जो मूल्य मिलता है वह इंटरफ़ेसआईडी है। तो मुख्य विचार कार्यों के केकेक हैश लेना और उनका एक्सओआर आउटपुट प्राप्त करना है। वह आउटपुट इंटरफ़ेस आईडी है और उसके बाद, आप एक अनुबंध की जांच कर सकते हैं कि क्या उसके पास एक ही इंटरफ़ेस आईडी है, यदि हाँ, तो इसका मतलब है कि अनुबंध वांछित इंटरफ़ेस को लागू कर रहा है।

चिंता मत करो दृढ़ता ने आपके लिए यह आसान बना दिया है। आइए एक उदाहरण के रूप में ERC721मेटाडेटा के लिए इंटरफ़ेस लेकर सीखें।

 interface ERC721Metadata/* is ERC721 */ { function name()external view returns (string _name); function symbol()external view returns (string _symbol); function tokenURI(uint256 _tokenId)external view returns (string); }

यहां हमारे तीन कार्य हैं। इसलिए मैंने आपको समझने के लिए कोड का यह टुकड़ा लिखा है। यहां ध्यान दें कैरेट प्रतीक ^ । यह प्रतीक दो मानों के बीच एक्सओआर ऑपरेशन का प्रतिनिधित्व कर रहा है।

 // SPDX-License-Identifier: MIT pragma solidity ^0.8.16 ; interface metadata { function name()external view returns (string memory _name ); function symbol()external view returns (string memory _symbol); function tokenURI(uint256 _tokenId)external view returns (string memory a); } contract { //old and lengthy way by applying the keccak256 algorithm and performing XOR. function getHashOldWay ()public pure returns(bytes4){ return bytes4(keccak256('name()')) ^ bytes4(keccak256('symbol()'))^ bytes4(keccak256('tokenURI(uint256)')); } //Improved way function getHashNewWay ()public pure returns(bytes4){ metadata a; return a.name.selector ^ a.symbol.selector ^ a.tokenURI.selector; } //this is the latest simplest way to get the interfaceId function getHashLatestWay ()public pure returns(bytes4){ return type(metadata).interfaceId; } }

ओह, हम ERC165 में इतना अधिक चले गए कि हम ERC721 के बारे में भूल गए, आइए इसे वापस लें।

ओपनसी (या कोई अन्य मार्केटप्लेस) स्मार्ट कॉन्ट्रैक्ट से डेटा कैसे प्राप्त करता है?

टोकन यूआरआई को समझने का यह सही समय है जो विभिन्न एनएफटी मार्केटप्लेस को आपके द्वारा निर्दिष्ट टोकन आईडी के साथ निर्दिष्ट डेटा की पहचान करने में मदद करता है। जैसा कि Opensea सबसे प्रसिद्ध बाज़ार है, हम इसे एक उदाहरण के रूप में लेंगे। Opensea अपेक्षा करता है कि आपका ERC721 अनुबंध एक tokenURI() फ़ंक्शन को कॉल करके एक tokenURI लौटाएगा। आइए इसके लिए ओपनज़ेपेलिन अनुबंध देखें।

TokenURI दो प्रकार के हो सकते हैं।

1. सभी टोकन के लिए एक ही आधार यूआरआई, टोकन आईडी के अनुसार अलग-अलग।

इस तरह हम सभी टोकन के लिए एक बेस यूआरआई असाइन करते हैं और फिर मेटाडेटा यूआरआई प्राप्त करते हुए टोकन आईडी को जोड़ते हैं। यह तभी संभव है जब आपने अपने संग्रह को इस तरह से असाइन किया हो जहां हर मेटाडेटा JSON फ़ाइल के लिए लिंक समान हो, केवल अंतर टोकनआईड होगा। उदाहरण के लिए,

https://gateway.pinata.cloud/ipfs/QmYLwrqMmzC3k4eZu7qJ4MZJ4SNYMgqbRJFLkyiPtUBZUP/ यह लिंक फ़ोल्डर की ओर इशारा करता है, जिसका अर्थ है कि यह बेसयूआरआई है।

एकल मेटाडेटा प्राप्त करने के लिए हमें https://gateway.pinata.cloud/ipfs/QmYLwrqMmzC3k4eZu7qJ4MZJ4SNYMgqbRJFLkyiPtUBZUP/1.json पर जाना होगा

और अब आपको टोकनयूआरआई को अनुबंध से इस तरह से वापस करना होगा कि यह सीधे उस विशेष टोकन के मेटाडेटा में जाता है, और बाज़ार इसे प्राप्त कर सकता है। हम ऐसा करते हैं कि बेसयूआरआई को टोकनआईड और अबी एन्कोडिंग के साथ जोड़कर। इस समारोह को नीचे देखें।

 function tokenURI(uint tokenId) override public view returns(string memory) { return (string(abi.encodePacked( "https://gateway.pinata.cloud/ipfs/QmYLwrqMmzC3k4eZu7qJ4MZJ4SNYMgqbRJFLkyiPtUBZUP/",Strings.toString(tokenId),".json")) ); }

यह वह कार्य है जिसे बाज़ार URI प्राप्त करने के लिए कॉल करेगा और हमारे द्वारा JSON फ़ाइल में प्रदान किए गए सभी डेटा को प्रदर्शित करेगा।

2. प्रत्येक टोकन के लिए अलग-अलग यूआरआई।

यह एक और तरीका है जहां हम अलग-अलग स्थानों में स्थित यूआरआई को असाइन कर सकते हैं। और एक व्यक्तिगत फाइल के लिए आईपीएफएस लिंक इस तरह दिखता है। https://ipfs.filebase.io/ipfs/Qma65D75em77UTgP5TYXT4ZK5Scwv9ZaNyJPdX9DNCXRWc इस तरह आप इस लिंक को प्राप्त करने के लिए बेसयूआरआई के साथ टोकनआईडी को जोड़ नहीं सकते हैं, इसके बजाय, यह लिंक सीधे टोकनआईड ऑन-चेन से जुड़ा होना चाहिए। और इसके लिए उपरोक्त ERC721URIStorage अनुबंध को देखें जहां हम एक विशेष टोकन आईडी को URI असाइन करने के लिए एक निजी मैपिंग को परिभाषित कर रहे हैं। और बाद में एक फ़ंक्शन को भी परिभाषित करता है जो किसी दिए गए यूआरआई के साथ मैपिंग को पॉप्युलेट करता है। और tokenURI फ़ंक्शन मैप किए गए यूआरआई को वापस करने की एक नई कार्यक्षमता जोड़कर पैरेंट फ़ंक्शन को ओवरराइड करता है।

ध्यान देने योग्य एक और बात JSON स्कीमा का प्रारूप है। JSON में एक मानकीकृत तरीके से डेटा होना चाहिए ताकि बाज़ार वांछित डेटा प्राप्त कर सके और उसे प्रदर्शित कर सके।

ERC721 के लिए मानक JSON स्कीमा।

 { "title": "Asset Metadata", "type": "object", "properties": { "name": { "type": "string", "description": "Identifies the asset to which this NFT represents" }, "description": { "type": "string", "description": "Describes the asset to which this NFT represents" }, "image": { "type": "string", "description": "A URI pointing to a resource with mime type image/* representing the asset to which this NFT represents. Consider making any images at a width between 320 and 1080 pixels and aspect ratio between 1.91:1 and 4:5 inclusive." } } }

यदि आप ERC-721 (NFT) स्मार्ट अनुबंधों के विकास में रुचि रखते हैं, तो ये बातें आपको अवश्य जाननी चाहिए।

समस्याएं :

ERC721 मानक में मापनीयता के साथ कई समस्याएँ हैं। टोकन ट्रांसफर करते समय समस्या आती है क्योंकि ERC-721 आपको एक बार में एक टोकन ट्रांसफर करने की अनुमति देता है। इसका मतलब है कि अगर आप किसी को 5 एनएफटी भेजना चाहते हैं तो आपको 5 लेनदेन करने होंगे। यह आपके लिए बिल्कुल स्पष्ट है कि यह ब्लॉकचेन में कितनी जगह लेगा। यही कारण है कि बुल रन में नेटवर्क को दिक्कतों का सामना करना पड़ता है, क्योंकि नेटवर्क में बहुत ज्यादा भीड़ होती है और गैस की फीस तेजी से बढ़ती है।

ERC-1155 इन समस्याओं को हल करता है। कैसे? इसके बारे में एक अलग पोस्ट में बात करते हैं। अगर आपने ERC721 मानक को पूरी तरह से समझ लिया है तो ERC1155 को समझना ज्यादा मुश्किल नहीं होगा।

यहाँ भी प्रकाशित हुआ।