Vyper ERC-721 ஒப்பந்த வழிகாட்டி
அறிமுகம்
ERC-721 தரநிலையானது பூஞ்சையற்ற டோக்கன்களின் (NFT) உரிமையை வைத்திருக்கப் பயன்படுகிறது. ERC-20 டோக்கன்கள் ஒரு பொருளைப் போல செயல்படுகின்றன, ஏனெனில் தனிப்பட்ட டோக்கன்களுக்கு இடையே எந்த வித்தியாசமும் இல்லை. அதற்கு மாறாக, ERC-721 டோக்கன்கள் ஒரே மாதிரியான ஆனால் முற்றிலும் ஒன்றல்லாத சொத்துகளுக்காக வடிவமைக்கப்பட்டுள்ளன, அதாவது வெவ்வேறு பூனை கார்ட்டூன்கள் (opens in a new tab) அல்லது வெவ்வேறு ரியல் எஸ்டேட் சொத்துகளின் பத்திரங்கள் போன்றவை.
இந்தக் கட்டுரையில் ரியுயா நகமுராவின் ERC-721 ஒப்பந்தத்தை (opens in a new tab) நாங்கள் பகுப்பாய்வு செய்வோம். இந்த ஒப்பந்தம் Vyper (opens in a new tab)-இல் எழுதப்பட்டுள்ளது, இது Solidity-ஐ விட பாதுகாப்பற்ற குறியீட்டை எழுதுவதை கடினமாக்கும் வகையில் வடிவமைக்கப்பட்ட பைதான் போன்ற ஒப்பந்த மொழியாகும்.
ஒப்பந்தம்
1# @dev ERC-721 நான்-பஞ்சிபிள் டோக்கன் (non-fungible token) தரநிலையின் செயலாக்கம்.2# @author ரியுயா நகமுரா (@nrryuya)3# இதிலிருந்து மாற்றியமைக்கப்பட்டது: https://github.com/vyperlang/vyper/blob/de74722bf2d8718cca46902be165f9fe0e3641dd/examples/tokens/ERC721.vyபைத்தானைப் போலவே Vyper-இலும் கருத்துகள் (Comments) ஒரு ஹாஷ் (#) குறியீட்டுடன் தொடங்கி வரியின் இறுதி வரை தொடரும். @<keyword>-ஐ உள்ளடக்கிய கருத்துகள் மனிதர்கள் படிக்கக்கூடிய ஆவணங்களை உருவாக்க NatSpec (opens in a new tab)-ஆல் பயன்படுத்தப்படுகின்றன.
1from vyper.interfaces import ERC72123implements: ERC721ERC-721 இடைமுகம் Vyper மொழியில் கட்டமைக்கப்பட்டுள்ளது. குறியீட்டு வரையறையை நீங்கள் இங்கே பார்க்கலாம் (opens in a new tab). இடைமுக வரையறை Vyper-க்கு பதிலாக பைத்தானில் எழுதப்பட்டுள்ளது, ஏனெனில் இடைமுகங்கள் பிளாக்செயினுக்குள் மட்டுமல்லாமல், பைத்தானில் எழுதப்பட்டிருக்கக்கூடிய வெளிப்புற கிளையண்டிலிருந்து பிளாக்செயினுக்கு ஒரு பரிவர்த்தனையை அனுப்பும்போதும் பயன்படுத்தப்படுகின்றன.
முதல் வரி இடைமுகத்தை இறக்குமதி செய்கிறது, இரண்டாவது வரி அதை நாங்கள் இங்கே செயல்படுத்துகிறோம் என்பதைக் குறிப்பிடுகிறது.
ERC721Receiver இடைமுகம்
1# safeTransferFrom() மூலம் அழைக்கப்படும் ஒப்பந்தத்திற்கான இடைமுகம் (Interface)2interface ERC721Receiver:3 def onERC721Received(ERC-721 இரண்டு வகையான பரிமாற்றங்களை ஆதரிக்கிறது:
transferFrom, இது அனுப்புநரை எந்தவொரு இலக்கு முகவரியையும் குறிப்பிட அனுமதிக்கிறது மற்றும் பரிமாற்றத்திற்கான பொறுப்பை அனுப்புநரின் மீது வைக்கிறது. இதன் பொருள் நீங்கள் செல்லுபடியாகாத முகவரிக்கு மாற்றலாம், அவ்வாறு செய்தால் NFT நிரந்தரமாக இழக்கப்படும்.safeTransferFrom, இது இலக்கு முகவரி ஒரு ஒப்பந்தமா என்பதைச் சரிபார்க்கிறது. அப்படியானால், ERC-721 ஒப்பந்தம் பெறும் ஒப்பந்தத்திடம் NFT-ஐப் பெற விரும்புகிறதா என்று கேட்கும்.
safeTransferFrom கோரிக்கைகளுக்கு பதிலளிக்க, பெறும் ஒப்பந்தம் ERC721Receiver-ஐ செயல்படுத்த வேண்டும்.
1 _operator: address,2 _from: address,_from முகவரி என்பது டோக்கனின் தற்போதைய உரிமையாளர். _operator முகவரி என்பது பரிமாற்றத்தைக் கோரியவர் (அனுமதிகள் காரணமாக, இவை இரண்டும் ஒன்றாக இருக்க வேண்டியதில்லை).
1 _tokenId: uint256,ERC-721 டோக்கன் ID-கள் 256 பிட்கள் ஆகும். பொதுவாக அவை டோக்கன் எதைக் குறிக்கிறதோ அதன் விளக்கத்தை ஹாஷ் செய்வதன் மூலம் உருவாக்கப்படுகின்றன.
1 _data: Bytes[1024]கோரிக்கையானது 1024 பைட்டுகள் வரையிலான பயனர் தரவைக் கொண்டிருக்கலாம்.
1 ) -> bytes32: viewஒரு ஒப்பந்தம் தற்செயலாக ஒரு பரிமாற்றத்தை ஏற்கும் நிகழ்வுகளைத் தடுக்க, திரும்பப் பெறும் மதிப்பு பூலியன் அல்ல, ஆனால் ஒரு குறிப்பிட்ட மதிப்புடன் கூடிய 256 பிட்கள் ஆகும்.
இந்தச் செயல்பாடு ஒரு view ஆகும், அதாவது இது பிளாக்செயினின் நிலையைப் படிக்க முடியும், ஆனால் அதை மாற்ற முடியாது.
நிகழ்வுகள்
பிளாக்செயினுக்கு வெளியே உள்ள பயனர்கள் மற்றும் சேவையகங்களுக்கு நிகழ்வுகளைத் தெரிவிக்க நிகழ்வுகள் (opens in a new tab) வெளியிடப்படுகின்றன. நிகழ்வுகளின் உள்ளடக்கம் பிளாக்செயினில் உள்ள ஒப்பந்தங்களுக்குக் கிடைக்காது என்பதை நினைவில் கொள்ளவும்.
1# @dev எந்தவொரு முறையிலும் NFT-இன் உரிமை மாறும்போது இது வெளியிடப்படும். NFT-கள்2# உருவாக்கப்படும்போதும் (`from` == 0) மற்றும் அழிக்கப்படும்போதும் (`to` == 0) இந்த நிகழ்வு வெளியிடப்படும். விதிவிலக்கு: ஒப்பந்தம் உருவாக்கப்படும்போது, எந்தவொரு3# எண்ணிக்கையிலான NFT-களும் Transfer நிகழ்வை வெளியிடாமலேயே உருவாக்கப்பட்டு ஒதுக்கப்படலாம். எந்தவொரு4# பரிமாற்றத்தின்போதும், அந்த NFT-க்கான அங்கீகரிக்கப்பட்ட முகவரி (ஏதேனும் இருந்தால்) ஏதுமில்லை என மீட்டமைக்கப்படும்.5# @param _from NFT-ஐ அனுப்புபவர் (முகவரி பூஜ்ஜிய முகவரியாக இருந்தால் அது டோக்கன் உருவாக்கத்தைக் குறிக்கும்).6# @param _to NFT-ஐ பெறுபவர் (முகவரி பூஜ்ஜிய முகவரியாக இருந்தால் அது டோக்கன் அழிப்பைக் குறிக்கும்).7# @param _tokenId பரிமாற்றம் செய்யப்பட்ட NFT.8event Transfer:9 sender: indexed(address)10 receiver: indexed(address)11 tokenId: indexed(uint256)அனைத்தையும் காட்டுஇது ERC-20 பரிமாற்ற நிகழ்வைப் போன்றது, ஆனால் நாங்கள் ஒரு தொகைக்கு பதிலாக tokenId-ஐப் புகாரளிக்கிறோம். பூஜ்ஜிய முகவரி யாருக்கும் சொந்தமில்லை, எனவே வழக்கப்படி டோக்கன்களின் உருவாக்கம் மற்றும் அழிவைப் புகாரளிக்க அதைப் பயன்படுத்துகிறோம்.
1# @dev ஒரு NFT-க்கான அங்கீகரிக்கப்பட்ட முகவரி மாற்றப்படும்போது அல்லது உறுதிப்படுத்தப்படும்போது இது வெளியிடப்படும். பூஜ்ஜிய2# முகவரி என்பது அங்கீகரிக்கப்பட்ட முகவரி ஏதுமில்லை என்பதைக் குறிக்கிறது. Transfer நிகழ்வு வெளியிடப்படும்போது, இது3# அந்த NFT-க்கான அங்கீகரிக்கப்பட்ட முகவரி (ஏதேனும் இருந்தால்) ஏதுமில்லை என மீட்டமைக்கப்படுவதையும் குறிக்கிறது.4# @param _owner NFT-இன் உரிமையாளர்.5# @param _approved நாம் அங்கீகரிக்கும் முகவரி.6# @param _tokenId நாம் அங்கீகரிக்கும் NFT.7event Approval:8 owner: indexed(address)9 approved: indexed(address)10 tokenId: indexed(uint256)அனைத்தையும் காட்டுஒரு ERC-721 ஒப்புதல் என்பது ERC-20 அனுமதியைப் போன்றது. ஒரு குறிப்பிட்ட முகவரி ஒரு குறிப்பிட்ட டோக்கனை மாற்ற அனுமதிக்கப்படுகிறது. இது ஒப்பந்தங்கள் ஒரு டோக்கனை ஏற்கும் போது பதிலளிக்க ஒரு வழிமுறையை வழங்குகிறது. ஒப்பந்தங்களால் நிகழ்வுகளைக் கேட்க முடியாது, எனவே நீங்கள் டோக்கனை அவர்களுக்கு மாற்றினால் அவர்களுக்கு அது "தெரியாது". இந்த வழியில் உரிமையாளர் முதலில் ஒரு ஒப்புதலைச் சமர்ப்பித்து, பின்னர் ஒப்பந்தத்திற்கு ஒரு கோரிக்கையை அனுப்புகிறார்: "டோக்கன் X-ஐ மாற்றுவதற்கு நான் உங்களுக்கு ஒப்புதல் அளித்துள்ளேன், தயவுசெய்து செய்யுங்கள் ...".
இது ERC-721 தரநிலையை ERC-20 தரநிலைக்கு ஒத்ததாக மாற்றுவதற்கான ஒரு வடிவமைப்புத் தேர்வாகும். ERC-721 டோக்கன்கள் பூஞ்சையற்றவை என்பதால், ஒரு ஒப்பந்தம் டோக்கனின் உரிமையைப் பார்ப்பதன் மூலம் ஒரு குறிப்பிட்ட டோக்கனைப் பெற்றதை அடையாளம் காண முடியும்.
1# @dev உரிமையாளருக்கான ஆபரேட்டர் (operator) செயல்படுத்தப்படும்போது அல்லது முடக்கப்படும்போது இது வெளியிடப்படும். ஆபரேட்டரால்2# உரிமையாளரின் அனைத்து NFT-களையும் நிர்வகிக்க முடியும்.3# @param _owner NFT-இன் உரிமையாளர்.4# @param _operator நாம் ஆபரேட்டர் உரிமைகளை அமைக்கும் முகவரி.5# @param _approved ஆபரேட்டர் உரிமைகளின் நிலை (ஆபரேட்டர் உரிமைகள் வழங்கப்பட்டால் true, மற்றும்6# திரும்பப் பெறப்பட்டால் false).7event ApprovalForAll:8 owner: indexed(address)9 operator: indexed(address)10 approved: boolஅனைத்தையும் காட்டுபவர் ஆஃப் அட்டர்னியைப் போலவே, ஒரு குறிப்பிட்ட வகையின் (ஒரு குறிப்பிட்ட ஒப்பந்தத்தால் நிர்வகிக்கப்படுபவை) கணக்கின் அனைத்து டோக்கன்களையும் நிர்வகிக்கக்கூடிய ஒரு ஆபரேட்டரை வைத்திருப்பது சில நேரங்களில் பயனுள்ளதாக இருக்கும். எடுத்துக்காட்டாக, நான் ஆறு மாதங்களாகத் தொடர்புகொள்ளவில்லையா என்பதைச் சரிபார்க்கும் ஒரு ஒப்பந்தத்திற்கு அத்தகைய அதிகாரத்தை வழங்க விரும்பலாம், அவ்வாறு இருந்தால் எனது சொத்துக்களை எனது வாரிசுகளுக்கு விநியோகிக்கலாம் (அவர்களில் ஒருவர் அதைக் கேட்டால், ஒரு பரிவர்த்தனையால் அழைக்கப்படாமல் ஒப்பந்தங்களால் எதையும் செய்ய முடியாது). ERC-20-இல் நாம் ஒரு பரம்பரை ஒப்பந்தத்திற்கு அதிக அனுமதியை வழங்க முடியும், ஆனால் டோக்கன்கள் பூஞ்சையற்றவை என்பதால் இது ERC-721-க்கு வேலை செய்யாது. இது அதற்குச் சமமானதாகும்.
approved மதிப்பு, நிகழ்வு ஒரு ஒப்புதலுக்கானதா அல்லது ஒப்புதலைத் திரும்பப் பெறுவதற்கானதா என்பதை நமக்குச் சொல்கிறது.
நிலை மாறிகள் (State Variables)
இந்த மாறிகள் டோக்கன்களின் தற்போதைய நிலையைக் கொண்டுள்ளன: எவை கிடைக்கின்றன மற்றும் அவற்றை யார் வைத்திருக்கிறார்கள். இவற்றில் பெரும்பாலானவை HashMap பொருள்கள், இரண்டு வகைகளுக்கு இடையே இருக்கும் ஒரு திசை மேப்பிங்குகள் (opens in a new tab).
1# @dev NFT ID-யிலிருந்து அதைச் சொந்தமாகக் கொண்ட முகவரிக்கான மேப்பிங் (Mapping).2idToOwner: HashMap[uint256, address]34# @dev NFT ID-யிலிருந்து அங்கீகரிக்கப்பட்ட முகவரிக்கான மேப்பிங்.5idToApprovals: HashMap[uint256, address]Ethereum-இல் பயனர் மற்றும் ஒப்பந்த அடையாளங்கள் 160-பிட் முகவரிகளால் குறிக்கப்படுகின்றன. இந்த இரண்டு மாறிகளும் டோக்கன் ID-களிலிருந்து அவற்றின் உரிமையாளர்களுக்கும் அவற்றை மாற்றுவதற்கு அங்கீகரிக்கப்பட்டவர்களுக்கும் (ஒவ்வொன்றுக்கும் அதிகபட்சம் ஒன்று) மேப் செய்கின்றன. Ethereum-இல், துவக்கப்படாத தரவு எப்போதும் பூஜ்ஜியமாக இருக்கும், எனவே உரிமையாளர் அல்லது அங்கீகரிக்கப்பட்ட பரிமாற்றுபவர் இல்லை என்றால் அந்த டோக்கனுக்கான மதிப்பு பூஜ்ஜியமாகும்.
1# @dev உரிமையாளர் முகவரியிலிருந்து அவரது டோக்கன்களின் எண்ணிக்கைக்கு மேப்பிங்.2ownerToNFTokenCount: HashMap[address, uint256]இந்த மாறி ஒவ்வொரு உரிமையாளருக்குமான டோக்கன்களின் எண்ணிக்கையைக் கொண்டுள்ளது. உரிமையாளர்களிடமிருந்து டோக்கன்களுக்கு எந்த மேப்பிங்கும் இல்லை, எனவே ஒரு குறிப்பிட்ட உரிமையாளர் வைத்திருக்கும் டோக்கன்களை அடையாளம் காண ஒரே வழி, பிளாக்செயினின் நிகழ்வு வரலாற்றைத் திரும்பிப் பார்த்து பொருத்தமான Transfer நிகழ்வுகளைப் பார்ப்பதுதான். எங்களிடம் அனைத்து NFT-களும் எப்போது உள்ளன என்பதை அறிய இந்த மாறியைப் பயன்படுத்தலாம், மேலும் காலப்போக்கில் மேலும் பார்க்க வேண்டியதில்லை.
இந்த அல்காரிதம் பயனர் இடைமுகங்கள் மற்றும் வெளிப்புற சேவையகங்களுக்கு மட்டுமே வேலை செய்யும் என்பதை நினைவில் கொள்ளவும். பிளாக்செயினிலேயே இயங்கும் குறியீட்டால் கடந்த கால நிகழ்வுகளைப் படிக்க முடியாது.
1# @dev உரிமையாளர் முகவரியிலிருந்து ஆபரேட்டர் முகவரிகளின் மேப்பிங்கிற்கு மேப்பிங்.2ownerToOperators: HashMap[address, HashMap[address, bool]]ஒரு கணக்கில் ஒன்றுக்கு மேற்பட்ட ஆபரேட்டர்கள் இருக்கலாம். அவற்றைக் கண்காணிக்க ஒரு எளிய HashMap போதுமானதாக இல்லை, ஏனெனில் ஒவ்வொரு திறவுகோலும் (key) ஒரு மதிப்பிற்கு வழிவகுக்கிறது. அதற்குப் பதிலாக, நீங்கள் HashMap[address, bool]-ஐ மதிப்பாகப் பயன்படுத்தலாம். இயல்பாக ஒவ்வொரு முகவரிக்கான மதிப்பும் False ஆகும், அதாவது அது ஒரு ஆபரேட்டர் அல்ல. தேவைக்கேற்ப மதிப்புகளை True என அமைக்கலாம்.
1# @dev டோக்கனை உருவாக்க (mint) கூடிய மின்ட்டரின் (minter) முகவரி2minter: addressபுதிய டோக்கன்கள் எப்படியாவது உருவாக்கப்பட வேண்டும். இந்த ஒப்பந்தத்தில் அவ்வாறு செய்ய அனுமதிக்கப்பட்ட ஒரே ஒரு நிறுவனம் உள்ளது, அது minter. எடுத்துக்காட்டாக, ஒரு விளையாட்டுக்கு இது போதுமானதாக இருக்கலாம். பிற நோக்கங்களுக்காக, மிகவும் சிக்கலான வணிக தர்க்கத்தை உருவாக்குவது அவசியமாக இருக்கலாம்.
1# @dev இடைமுக (interface) ID ஆதரிக்கப்படுகிறதா இல்லையா என்பது குறித்த பூலியனுக்கான (bool) மேப்பிங்2supportedInterfaces: HashMap[bytes32, bool]34# @dev ERC165-இன் ERC165 இடைமுக ID5ERC165_INTERFACE_ID: constant(bytes32) = 0x0000000000000000000000000000000000000000000000000000000001ffc9a767# @dev ERC721-இன் ERC165 இடைமுக ID8ERC721_INTERFACE_ID: constant(bytes32) = 0x0000000000000000000000000000000000000000000000000000000080ac58cdERC-165 (opens in a new tab) ஒரு ஒப்பந்தம் பயன்பாடுகள் அதனுடன் எவ்வாறு தொடர்பு கொள்ள முடியும், எந்த ERC-களுக்கு அது இணங்குகிறது என்பதை வெளிப்படுத்துவதற்கான ஒரு வழிமுறையைக் குறிப்பிடுகிறது. இந்த வழக்கில், ஒப்பந்தம் ERC-165 மற்றும் ERC-721-க்கு இணங்குகிறது.
செயல்பாடுகள் (Functions)
இவை உண்மையில் ERC-721-ஐ செயல்படுத்தும் செயல்பாடுகள் ஆகும்.
கன்ஸ்ட்ரக்டர் (Constructor)
1@external2def __init__():பைத்தானைப் போலவே Vyper-இலும், கன்ஸ்ட்ரக்டர் செயல்பாடு __init__ என்று அழைக்கப்படுகிறது.
1 # @dev ஒப்பந்த கன்ஸ்ட்ரக்டர் (Contract constructor).பைத்தான் மற்றும் Vyper-இல், பல வரி சரத்தைக் குறிப்பிடுவதன் மூலமும் (இது """ உடன் தொடங்கி முடிவடையும்), அதை எந்த வகையிலும் பயன்படுத்தாமலும் நீங்கள் ஒரு கருத்தை உருவாக்கலாம். இந்தக் கருத்துகளில் NatSpec (opens in a new tab)-உம் அடங்கும்.
1 self.supportedInterfaces[ERC165_INTERFACE_ID] = True2 self.supportedInterfaces[ERC721_INTERFACE_ID] = True3 self.minter = msg.senderநிலை மாறிகளை அணுக நீங்கள் self.<variable name>-ஐப் பயன்படுத்துகிறீர்கள் (மீண்டும், பைத்தானைப் போலவே).
வியூ செயல்பாடுகள் (View Functions)
இவை பிளாக்செயினின் நிலையை மாற்றாத செயல்பாடுகள் ஆகும், எனவே அவை வெளிப்புறமாக அழைக்கப்பட்டால் இலவசமாகச் செயல்படுத்தப்படலாம். வியூ செயல்பாடுகள் ஒரு ஒப்பந்தத்தால் அழைக்கப்பட்டால், அவை இன்னும் ஒவ்வொரு முனையிலும் செயல்படுத்தப்பட வேண்டும், எனவே எரிவாயு (gas) செலவாகும்.
1@view2@externalஒரு செயல்பாட்டு வரையறைக்கு முன்னதாக அட் குறியீட்டுடன் (@) தொடங்கும் இந்த முக்கிய வார்த்தைகள் அலங்காரங்கள் (decorations) என்று அழைக்கப்படுகின்றன. ஒரு செயல்பாட்டை அழைக்கக்கூடிய சூழ்நிலைகளை அவை குறிப்பிடுகின்றன.
@viewஇந்தச் செயல்பாடு ஒரு வியூ என்பதைக் குறிப்பிடுகிறது.@externalஇந்த குறிப்பிட்ட செயல்பாட்டைப் பரிவர்த்தனைகள் மற்றும் பிற ஒப்பந்தங்கள் மூலம் அழைக்கலாம் என்பதைக் குறிப்பிடுகிறது.
1def supportsInterface(_interfaceID: bytes32) -> bool:பைத்தானுக்கு மாறாக, Vyper ஒரு நிலையான தட்டச்சு செய்யப்பட்ட மொழி (static typed language) (opens in a new tab) ஆகும். தரவு வகையை (data type) (opens in a new tab) அடையாளம் காணாமல் நீங்கள் ஒரு மாறியையோ அல்லது ஒரு செயல்பாட்டு அளவுருவையோ அறிவிக்க முடியாது. இந்த வழக்கில் உள்ளீட்டு அளவுரு bytes32 ஆகும், இது 256-பிட் மதிப்பு (256 பிட்கள் என்பது Ethereum Virtual Machine-இன் சொந்த சொல் அளவு). வெளியீடு ஒரு பூலியன் மதிப்பு. வழக்கப்படி, செயல்பாட்டு அளவுருக்களின் பெயர்கள் அடிக்கோடிட்டு (_) தொடங்குகின்றன.
1 # @dev இடைமுக அடையாளம் ERC-165-இல் குறிப்பிடப்பட்டுள்ளது.2 @param _interfaceID இடைமுகத்தின் Id3 return self.supportedInterfaces[_interfaceID]கன்ஸ்ட்ரக்டரில் (__init__) அமைக்கப்பட்ட self.supportedInterfaces HashMap-இலிருந்து மதிப்பைத் திருப்பி அனுப்பவும்.
1# ## வியூ செயல்பாடுகள் (VIEW FUNCTIONS) ###இவை பயனர்களுக்கும் பிற ஒப்பந்தங்களுக்கும் டோக்கன்கள் பற்றிய தகவல்களைக் கிடைக்கச் செய்யும் வியூ செயல்பாடுகள் ஆகும்.
1@view2@external3def balanceOf(_owner: address) -> uint256:4 # @dev `_owner` வைத்திருக்கும் NFT-களின் எண்ணிக்கையை வழங்கும்.5 `_owner` பூஜ்ஜிய முகவரியாக இருந்தால் பிழையை ஏற்படுத்தும். பூஜ்ஜிய முகவரிக்கு ஒதுக்கப்பட்ட NFT-கள் செல்லாதவையாகக் கருதப்படும்.6 @param _owner யாருடைய இருப்பை (balance) வினவ வேண்டுமோ அந்த முகவரி.7 assert _owner != ZERO_ADDRESSஇந்த வரி _owner பூஜ்ஜியம் அல்ல என்பதை உறுதிப்படுத்துகிறது (asserts) (opens in a new tab). அது பூஜ்ஜியமாக இருந்தால், ஒரு பிழை உள்ளது மற்றும் செயல்பாடு திரும்பப் பெறப்படும்.
1 return self.ownerToNFTokenCount[_owner]23@view4@external5def ownerOf(_tokenId: uint256) -> address:6 # @dev NFT-இன் உரிமையாளர் முகவரியை வழங்கும்.7 `_tokenId` சரியான NFT ஆக இல்லாவிட்டால் பிழையை ஏற்படுத்தும்.8 @param _tokenId ஒரு NFT-க்கான அடையாளங்காட்டி.9 owner: address = self.idToOwner[_tokenId]10 # `_tokenId` சரியான NFT ஆக இல்லாவிட்டால் பிழையை ஏற்படுத்தும்11 assert owner != ZERO_ADDRESS12 return ownerஅனைத்தையும் காட்டுEthereum Virtual Machine (EVM)-இல் மதிப்பு சேமிக்கப்படாத எந்தவொரு சேமிப்பகமும் பூஜ்ஜியமாகும். _tokenId-இல் டோக்கன் இல்லை என்றால், self.idToOwner[_tokenId]-இன் மதிப்பு பூஜ்ஜியமாகும். அந்த வழக்கில் செயல்பாடு திரும்பப் பெறப்படும்.
1@view2@external3def getApproved(_tokenId: uint256) -> address:4 # @dev ஒரு குறிப்பிட்ட NFT-க்கான அங்கீகரிக்கப்பட்ட முகவரியைப் பெறவும்.5 `_tokenId` சரியான NFT ஆக இல்லாவிட்டால் பிழையை ஏற்படுத்தும்.6 @param _tokenId எந்த NFT-இன் அங்கீகாரத்தை வினவ வேண்டுமோ அதன் ID.7 # `_tokenId` சரியான NFT ஆக இல்லாவிட்டால் பிழையை ஏற்படுத்தும்8 assert self.idToOwner[_tokenId] != ZERO_ADDRESS9 return self.idToApprovals[_tokenId]அனைத்தையும் காட்டுgetApproved பூஜ்ஜியத்தைத் திருப்பி அனுப்ப முடியும் என்பதை நினைவில் கொள்ளவும். டோக்கன் செல்லுபடியாகும் என்றால் அது self.idToApprovals[_tokenId]-ஐத் திருப்பி அனுப்பும். அங்கீகரிப்பவர் இல்லை என்றால் அந்த மதிப்பு பூஜ்ஜியமாகும்.
1@view2@external3def isApprovedForAll(_owner: address, _operator: address) -> bool:4 # @dev `_owner`-க்கு `_operator` ஒரு அங்கீகரிக்கப்பட்ட ஆபரேட்டரா என்பதைச் சரிபார்க்கும்.5 @param _owner NFT-களைச் சொந்தமாகக் கொண்ட முகவரி.6 @param _operator உரிமையாளரின் சார்பாகச் செயல்படும் முகவரி.7 return (self.ownerToOperators[_owner])[_operator]இந்த ஒப்பந்தத்தில் _owner-இன் அனைத்து டோக்கன்களையும் நிர்வகிக்க _operator அனுமதிக்கப்படுகிறாரா என்பதை இந்தச் செயல்பாடு சரிபார்க்கிறது. பல ஆபரேட்டர்கள் இருக்க முடியும் என்பதால், இது இரண்டு நிலை HashMap ஆகும்.
பரிமாற்ற உதவி செயல்பாடுகள் (Transfer Helper Functions)
இந்தச் செயல்பாடுகள் டோக்கன்களை மாற்றுவது அல்லது நிர்வகிப்பதன் ஒரு பகுதியாக இருக்கும் செயல்பாடுகளைச் செயல்படுத்துகின்றன.
12# ## பரிமாற்ற செயல்பாட்டு உதவியாளர்கள் (TRANSFER FUNCTION HELPERS) ###34@view5@internalஇந்த அலங்காரம், @internal, அதாவது இந்தச் செயல்பாடு அதே ஒப்பந்தத்திற்குள் உள்ள பிற செயல்பாடுகளிலிருந்து மட்டுமே அணுகக்கூடியது. வழக்கப்படி, இந்தச் செயல்பாட்டுப் பெயர்களும் அடிக்கோடிட்டு (_) தொடங்குகின்றன.
1def _isApprovedOrOwner(_spender: address, _tokenId: uint256) -> bool:2 # @dev குறிப்பிட்ட டோக்கன் ID-ஐ குறிப்பிட்ட ஸ்பெண்டரால் (spender) பரிமாற்றம் செய்ய முடியுமா என்பதை வழங்கும்3 @param spender வினவ வேண்டிய ஸ்பெண்டரின் முகவரி4 @param tokenId பரிமாற்றம் செய்யப்பட வேண்டிய டோக்கனின் uint256 ID5 @return bool msg.sender குறிப்பிட்ட டோக்கன் ID-க்கு அங்கீகரிக்கப்பட்டவரா,6 உரிமையாளரின் ஆபரேட்டரா, அல்லது டோக்கனின் உரிமையாளரா என்பது7 owner: address = self.idToOwner[_tokenId]8 spenderIsOwner: bool = owner == _spender9 spenderIsApproved: bool = _spender == self.idToApprovals[_tokenId]10 spenderIsApprovedForAll: bool = (self.ownerToOperators[owner])[_spender]11 return (spenderIsOwner or spenderIsApproved) or spenderIsApprovedForAllஅனைத்தையும் காட்டுஒரு முகவரி ஒரு டோக்கனை மாற்ற அனுமதிக்கப்படும் மூன்று வழிகள் உள்ளன:
- முகவரி டோக்கனின் உரிமையாளர்
- அந்த டோக்கனைச் செலவிட முகவரி அங்கீகரிக்கப்பட்டுள்ளது
- முகவரி டோக்கனின் உரிமையாளருக்கான ஆபரேட்டர்
மேலே உள்ள செயல்பாடு ஒரு வியூவாக இருக்கலாம், ஏனெனில் அது நிலையை மாற்றாது. இயக்கச் செலவுகளைக் குறைக்க, ஒரு வியூவாக இருக்க முடியும் எந்தவொரு செயல்பாடும் ஒரு வியூவாக இருக்க வேண்டும்.
1@internal2def _addTokenTo(_to: address, _tokenId: uint256):3 # @dev குறிப்பிட்ட முகவரிக்கு ஒரு NFT-ஐச் சேர்க்கவும்4 `_tokenId` வேறொருவருக்குச் சொந்தமானதாக இருந்தால் பிழையை ஏற்படுத்தும்.5 # `_tokenId` வேறொருவருக்குச் சொந்தமானதாக இருந்தால் பிழையை ஏற்படுத்தும்6 assert self.idToOwner[_tokenId] == ZERO_ADDRESS7 # உரிமையாளரை மாற்றவும்8 self.idToOwner[_tokenId] = _to9 # எண்ணிக்கை கண்காணிப்பை மாற்றவும்10 self.ownerToNFTokenCount[_to] += 1111213@internal14def _removeTokenFrom(_from: address, _tokenId: uint256):15 # @dev குறிப்பிட்ட முகவரியிலிருந்து ஒரு NFT-ஐ அகற்றவும்16 `_from` தற்போதைய உரிமையாளராக இல்லாவிட்டால் பிழையை ஏற்படுத்தும்.17 # `_from` தற்போதைய உரிமையாளராக இல்லாவிட்டால் பிழையை ஏற்படுத்தும்18 assert self.idToOwner[_tokenId] == _from19 # உரிமையாளரை மாற்றவும்20 self.idToOwner[_tokenId] = ZERO_ADDRESS21 # எண்ணிக்கை கண்காணிப்பை மாற்றவும்22 self.ownerToNFTokenCount[_from] -= 1அனைத்தையும் காட்டுபரிமாற்றத்தில் சிக்கல் ஏற்படும் போது நாங்கள் அழைப்பைத் திரும்பப் பெறுகிறோம்.
1@internal2def _clearApproval(_owner: address, _tokenId: uint256):3 # @dev குறிப்பிட்ட முகவரியின் அங்கீகாரத்தை அழிக்கவும்4 `_owner` தற்போதைய உரிமையாளராக இல்லாவிட்டால் பிழையை ஏற்படுத்தும்.5 # `_owner` தற்போதைய உரிமையாளராக இல்லாவிட்டால் பிழையை ஏற்படுத்தும்6 assert self.idToOwner[_tokenId] == _owner7 if self.idToApprovals[_tokenId] != ZERO_ADDRESS:8 # அங்கீகாரங்களை மீட்டமைக்கவும்9 self.idToApprovals[_tokenId] = ZERO_ADDRESSஅனைத்தையும் காட்டுதேவைப்பட்டால் மட்டுமே மதிப்பை மாற்றவும். நிலை மாறிகள் சேமிப்பகத்தில் வாழ்கின்றன. சேமிப்பகத்தில் எழுதுவது EVM (Ethereum Virtual Machine) செய்யும் மிகவும் விலையுயர்ந்த செயல்பாடுகளில் ஒன்றாகும் (எரிவாயு (gas) அடிப்படையில்). எனவே, அதைக் குறைப்பது நல்லது, இருக்கும் மதிப்பை எழுதுவது கூட அதிக செலவைக் கொண்டுள்ளது.
1@internal2def _transferFrom(_from: address, _to: address, _tokenId: uint256, _sender: address):3 # @dev ஒரு NFT-இன் பரிமாற்றத்தைச் செயல்படுத்தவும்.4 `msg.sender` தற்போதைய உரிமையாளராகவோ, அங்கீகரிக்கப்பட்ட ஆபரேட்டராகவோ அல்லது இந்த NFT-க்கான அங்கீகரிக்கப்பட்ட5 முகவரியாகவோ இல்லாவிட்டால் பிழையை ஏற்படுத்தும். (குறிப்பு: தனிப்பட்ட செயல்பாட்டில் `msg.sender` அனுமதிக்கப்படாது, எனவே `_sender`-ஐ அனுப்பவும்.)6 `_to` பூஜ்ஜிய முகவரியாக இருந்தால் பிழையை ஏற்படுத்தும்.7 `_from` தற்போதைய உரிமையாளராக இல்லாவிட்டால் பிழையை ஏற்படுத்தும்.8 `_tokenId` சரியான NFT ஆக இல்லாவிட்டால் பிழையை ஏற்படுத்தும்.டோக்கன்களை மாற்றுவதற்கு இரண்டு வழிகள் (வழக்கமான மற்றும் பாதுகாப்பான) இருப்பதால் இந்த உள் செயல்பாடு எங்களிடம் உள்ளது, ஆனால் தணிக்கையை எளிதாக்க குறியீட்டில் ஒரே ஒரு இடத்தில் மட்டுமே அதைச் செய்ய விரும்புகிறோம்.
1 # தேவைகளைச் சரிபார்க்கவும்2 assert self._isApprovedOrOwner(_sender, _tokenId)3 # `_to` பூஜ்ஜிய முகவரியாக இருந்தால் பிழையை ஏற்படுத்தும்4 assert _to != ZERO_ADDRESS5 # அங்கீகாரத்தை அழிக்கவும். `_from` தற்போதைய உரிமையாளராக இல்லாவிட்டால் பிழையை ஏற்படுத்தும்6 self._clearApproval(_from, _tokenId)7 # NFT-ஐ அகற்றவும். `_tokenId` சரியான NFT ஆக இல்லாவிட்டால் பிழையை ஏற்படுத்தும்8 self._removeTokenFrom(_from, _tokenId)9 # NFT-ஐச் சேர்க்கவும்10 self._addTokenTo(_to, _tokenId)11 # பரிமாற்றத்தைப் பதிவு செய்யவும் (Log)12 log Transfer(_from, _to, _tokenId)அனைத்தையும் காட்டுVyper-இல் ஒரு நிகழ்வை வெளியிட நீங்கள் log அறிக்கையைப் பயன்படுத்துகிறீர்கள் (மேலும் விவரங்களுக்கு இங்கே பார்க்கவும் (opens in a new tab)).
பரிமாற்ற செயல்பாடுகள் (Transfer Functions)
12# ## பரிமாற்ற செயல்பாடுகள் (TRANSFER FUNCTIONS) ###34@external5def transferFrom(_from: address, _to: address, _tokenId: uint256):6 # @dev `msg.sender` தற்போதைய உரிமையாளராகவோ, அங்கீகரிக்கப்பட்ட ஆபரேட்டராகவோ அல்லது இந்த NFT-க்கான அங்கீகரிக்கப்பட்ட7 முகவரியாகவோ இல்லாவிட்டால் பிழையை ஏற்படுத்தும்.8 `_from` தற்போதைய உரிமையாளராக இல்லாவிட்டால் பிழையை ஏற்படுத்தும்.9 `_to` பூஜ்ஜிய முகவரியாக இருந்தால் பிழையை ஏற்படுத்தும்.10 `_tokenId` சரியான NFT ஆக இல்லாவிட்டால் பிழையை ஏற்படுத்தும்.11 @notice `_to` முகவரி NFT-களைப் பெறும் திறன் கொண்டதா என்பதை உறுதிப்படுத்துவது அழைப்பாளரின் பொறுப்பாகும், இல்லையெனில்12 அவை நிரந்தரமாக இழக்கப்படலாம்.13 @param _from NFT-இன் தற்போதைய உரிமையாளர்.14 @param _to புதிய உரிமையாளர்.15 @param _tokenId பரிமாற்றம் செய்ய வேண்டிய NFT.16 self._transferFrom(_from, _to, _tokenId, msg.sender)அனைத்தையும் காட்டுஇந்தச் செயல்பாடு தன்னிச்சையான முகவரிக்கு மாற்ற உங்களை அனுமதிக்கிறது. முகவரி ஒரு பயனராகவோ அல்லது டோக்கன்களை எவ்வாறு மாற்றுவது என்று தெரிந்த ஒப்பந்தமாகவோ இல்லாவிட்டால், நீங்கள் மாற்றும் எந்த டோக்கனும் அந்த முகவரியில் சிக்கிக்கொள்ளும் மற்றும் பயனற்றதாகிவிடும்.
1@external2def safeTransferFrom(3 _from: address,4 _to: address,5 _tokenId: uint256,6 _data: Bytes[1024]=b""7 ):8 # @dev ஒரு NFT-இன் உரிமையை ஒரு முகவரியிலிருந்து மற்றொரு முகவரிக்கு மாற்றும்.9 `msg.sender` தற்போதைய உரிமையாளராகவோ, அங்கீகரிக்கப்பட்ட ஆபரேட்டராகவோ அல்லது இந்த NFT-க்கான10 அங்கீகரிக்கப்பட்ட முகவரியாகவோ இல்லாவிட்டால் பிழையை ஏற்படுத்தும்.11 `_from` தற்போதைய உரிமையாளராக இல்லாவிட்டால் பிழையை ஏற்படுத்தும்.12 `_to` பூஜ்ஜிய முகவரியாக இருந்தால் பிழையை ஏற்படுத்தும்.13 `_tokenId` சரியான NFT ஆக இல்லாவிட்டால் பிழையை ஏற்படுத்தும்.14 `_to` ஒரு ஸ்மார்ட் ஒப்பந்தமாக இருந்தால், அது `_to`-வில் `onERC721Received`-ஐ அழைக்கும், மேலும்15 திரும்பப் பெறும் மதிப்பு `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))` ஆக இல்லாவிட்டால் பிழையை ஏற்படுத்தும்.16 குறிப்பு: bytes4 என்பது பேடிங் (padding) உடன் bytes32 மூலம் குறிக்கப்படுகிறது17 @param _from NFT-இன் தற்போதைய உரிமையாளர்.18 @param _to புதிய உரிமையாளர்.19 @param _tokenId பரிமாற்றம் செய்ய வேண்டிய NFT.20 @param _data `_to`-க்கான அழைப்பில் அனுப்பப்படும், குறிப்பிட்ட வடிவமைப்பு இல்லாத கூடுதல் தரவு.21 self._transferFrom(_from, _to, _tokenId, msg.sender)அனைத்தையும் காட்டுமுதலில் பரிமாற்றத்தைச் செய்வது பரவாயில்லை, ஏனென்றால் ஏதேனும் சிக்கல் இருந்தால் நாங்கள் எப்படியும் திரும்பப் பெறப் போகிறோம், எனவே அழைப்பில் செய்யப்பட்ட அனைத்தும் ரத்து செய்யப்படும்.
1 if _to.is_contract: # `_to` ஒரு ஒப்பந்த முகவரியா என்பதைச் சரிபார்க்கவும்முதலில் முகவரி ஒரு ஒப்பந்தமா என்பதைச் சரிபார்க்கவும் (அதில் குறியீடு இருந்தால்). இல்லையென்றால், அது ஒரு பயனர் முகவரி என்று கருதுங்கள், மேலும் பயனர் டோக்கனைப் பயன்படுத்தவோ அல்லது மாற்றவோ முடியும். ஆனால் அது உங்களை ஒரு தவறான பாதுகாப்பு உணர்வுக்குள் தள்ள விடாதீர்கள். யாருக்கும் தனிப்பட்ட விசை (private key) தெரியாத முகவரிக்கு நீங்கள் அவற்றை மாற்றினால், safeTransferFrom மூலம் கூட நீங்கள் டோக்கன்களை இழக்க நேரிடும்.
1 returnValue: bytes32 = ERC721Receiver(_to).onERC721Received(msg.sender, _from, _tokenId, _data)இலக்கு ஒப்பந்தம் ERC-721 டோக்கன்களைப் பெற முடியுமா என்பதைப் பார்க்க அதை அழைக்கவும்.
1 # பரிமாற்ற இலக்கு 'onERC721Received'-ஐச் செயல்படுத்தாத ஒரு ஒப்பந்தமாக இருந்தால் பிழையை ஏற்படுத்தும்2 assert returnValue == method_id("onERC721Received(address,address,uint256,bytes)", output_type=bytes32)இலக்கு ஒரு ஒப்பந்தமாக இருந்தால், ஆனால் ERC-721 டோக்கன்களை ஏற்காத ஒன்றாக இருந்தால் (அல்லது இந்த குறிப்பிட்ட பரிமாற்றத்தை ஏற்க வேண்டாம் என்று முடிவு செய்திருந்தால்), திரும்பப் பெறவும்.
1@external2def approve(_approved: address, _tokenId: uint256):3 # @dev ஒரு NFT-க்கான அங்கீகரிக்கப்பட்ட முகவரியை அமைக்கவும் அல்லது உறுதிப்படுத்தவும். பூஜ்ஜிய முகவரி என்பது அங்கீகரிக்கப்பட்ட முகவரி ஏதுமில்லை என்பதைக் குறிக்கிறது.4 `msg.sender` தற்போதைய NFT உரிமையாளராகவோ அல்லது தற்போதைய உரிமையாளரின் அங்கீகரிக்கப்பட்ட ஆபரேட்டராகவோ இல்லாவிட்டால் பிழையை ஏற்படுத்தும்.5 `_tokenId` சரியான NFT ஆக இல்லாவிட்டால் பிழையை ஏற்படுத்தும். (குறிப்பு: இது EIP-இல் எழுதப்படவில்லை)6 `_approved` தற்போதைய உரிமையாளராக இருந்தால் பிழையை ஏற்படுத்தும். (குறிப்பு: இது EIP-இல் எழுதப்படவில்லை)7 @param _approved குறிப்பிட்ட NFT ID-க்கு அங்கீகரிக்கப்பட வேண்டிய முகவரி.8 @param _tokenId அங்கீகரிக்கப்பட வேண்டிய டோக்கனின் ID.9 owner: address = self.idToOwner[_tokenId]10 # `_tokenId` சரியான NFT ஆக இல்லாவிட்டால் பிழையை ஏற்படுத்தும்11 assert owner != ZERO_ADDRESS12 # `_approved` தற்போதைய உரிமையாளராக இருந்தால் பிழையை ஏற்படுத்தும்13 assert _approved != ownerஅனைத்தையும் காட்டுவழக்கப்படி நீங்கள் ஒரு அங்கீகரிப்பாளரைக் கொண்டிருக்க விரும்பவில்லை என்றால், உங்களை அல்ல, பூஜ்ஜிய முகவரியை நியமிக்கிறீர்கள்.
1 # தேவைகளைச் சரிபார்க்கவும்2 senderIsOwner: bool = self.idToOwner[_tokenId] == msg.sender3 senderIsApprovedForAll: bool = (self.ownerToOperators[owner])[msg.sender]4 assert (senderIsOwner or senderIsApprovedForAll)ஒரு ஒப்புதலை அமைக்க நீங்கள் உரிமையாளராகவோ அல்லது உரிமையாளரால் அங்கீகரிக்கப்பட்ட ஆபரேட்டராகவோ இருக்கலாம்.
1 # அங்கீகாரத்தை அமைக்கவும்2 self.idToApprovals[_tokenId] = _approved3 log Approval(owner, _approved, _tokenId)456@external7def setApprovalForAll(_operator: address, _approved: bool):8 # @dev `msg.sender`-இன் அனைத்து சொத்துகளையும் நிர்வகிக்க மூன்றாம் தரப்பினருக்கான ("ஆபரேட்டர்") அங்கீகாரத்தைச் செயல்படுத்துகிறது அல்லது முடக்குகிறது.9 இது ApprovalForAll நிகழ்வையும் வெளியிடுகிறது.10 `_operator` என்பது `msg.sender` ஆக இருந்தால் பிழையை ஏற்படுத்தும். (குறிப்பு: இது EIP-இல் எழுதப்படவில்லை)11 @notice அந்த நேரத்தில் அனுப்புநரிடம் எந்த டோக்கன்களும் இல்லாவிட்டாலும் இது செயல்படும்.12 @param _operator அங்கீகரிக்கப்பட்ட ஆபரேட்டர்களின் தொகுப்பில் சேர்க்க வேண்டிய முகவரி.13 @param _approved ஆபரேட்டர்கள் அங்கீகரிக்கப்பட்டால் True, அங்கீகாரத்தைத் திரும்பப் பெற False.14 # `_operator` என்பது `msg.sender` ஆக இருந்தால் பிழையை ஏற்படுத்தும்15 assert _operator != msg.sender16 self.ownerToOperators[msg.sender][_operator] = _approved17 log ApprovalForAll(msg.sender, _operator, _approved)அனைத்தையும் காட்டுபுதிய டோக்கன்களை உருவாக்குதல் மற்றும் ஏற்கனவே உள்ளவற்றை அழித்தல்
ஒப்பந்தத்தை உருவாக்கிய கணக்கு minter ஆகும், இது புதிய NFT-களை உருவாக்க அங்கீகரிக்கப்பட்ட சூப்பர் பயனராகும். இருப்பினும், ஏற்கனவே உள்ள டோக்கன்களை அழிக்க அது கூட அனுமதிக்கப்படவில்லை. உரிமையாளர் அல்லது உரிமையாளரால் அங்கீகரிக்கப்பட்ட நிறுவனம் மட்டுமே அதைச் செய்ய முடியும்.
1# ## மின்ட் மற்றும் பர்ன் செயல்பாடுகள் (MINT & BURN FUNCTIONS) ###23@external4def mint(_to: address, _tokenId: uint256) -> bool:இந்தச் செயல்பாடு எப்போதும் True-ஐத் திருப்பி அனுப்பும், ஏனெனில் செயல்பாடு தோல்வியுற்றால் அது திரும்பப் பெறப்படும்.
1 # @dev டோக்கன்களை உருவாக்குவதற்கான (mint) செயல்பாடு2 `msg.sender` மின்ட்டராக (minter) இல்லாவிட்டால் பிழையை ஏற்படுத்தும்.3 `_to` பூஜ்ஜிய முகவரியாக இருந்தால் பிழையை ஏற்படுத்தும்.4 `_tokenId` வேறொருவருக்குச் சொந்தமானதாக இருந்தால் பிழையை ஏற்படுத்தும்.5 @param _to உருவாக்கப்பட்ட டோக்கன்களைப் பெறும் முகவரி.6 @param _tokenId உருவாக்க வேண்டிய டோக்கன் id.7 @return செயல்பாடு வெற்றிகரமாக நடந்ததா என்பதைக் குறிக்கும் பூலியன் (boolean).8 # `msg.sender` மின்ட்டராக (minter) இல்லாவிட்டால் பிழையை ஏற்படுத்தும்9 assert msg.sender == self.minterஅனைத்தையும் காட்டுமின்டர் (ERC-721 ஒப்பந்தத்தை உருவாக்கிய கணக்கு) மட்டுமே புதிய டோக்கன்களை உருவாக்க முடியும். எதிர்காலத்தில் மின்டரின் அடையாளத்தை மாற்ற விரும்பினால் இது ஒரு சிக்கலாக இருக்கலாம். ஒரு தயாரிப்பு ஒப்பந்தத்தில், மின்டர் சலுகைகளை வேறொருவருக்கு மாற்ற மின்டரை அனுமதிக்கும் ஒரு செயல்பாட்டை நீங்கள் விரும்பலாம்.
1 # `_to` பூஜ்ஜிய முகவரியாக இருந்தால் பிழையை ஏற்படுத்தும்2 assert _to != ZERO_ADDRESS3 # NFT-ஐச் சேர்க்கவும். `_tokenId` வேறொருவருக்குச் சொந்தமானதாக இருந்தால் பிழையை ஏற்படுத்தும்4 self._addTokenTo(_to, _tokenId)5 log Transfer(ZERO_ADDRESS, _to, _tokenId)6 return Trueவழக்கப்படி, புதிய டோக்கன்களை உருவாக்குவது பூஜ்ஜிய முகவரியிலிருந்து ஒரு பரிமாற்றமாகக் கணக்கிடப்படுகிறது.
12@external3def burn(_tokenId: uint256):4 # @dev ஒரு குறிப்பிட்ட ERC721 டோக்கனை அழிக்கும் (Burn).5 `msg.sender` தற்போதைய உரிமையாளராகவோ, அங்கீகரிக்கப்பட்ட ஆபரேட்டராகவோ அல்லது இந்த NFT-க்கான அங்கீகரிக்கப்பட்ட6 முகவரியாகவோ இல்லாவிட்டால் பிழையை ஏற்படுத்தும்.7 `_tokenId` சரியான NFT ஆக இல்லாவிட்டால் பிழையை ஏற்படுத்தும்.8 @param _tokenId அழிக்கப்பட வேண்டிய ERC721 டோக்கனின் uint256 id.9 # தேவைகளைச் சரிபார்க்கவும்10 assert self._isApprovedOrOwner(msg.sender, _tokenId)11 owner: address = self.idToOwner[_tokenId]12 # `_tokenId` சரியான NFT ஆக இல்லாவிட்டால் பிழையை ஏற்படுத்தும்13 assert owner != ZERO_ADDRESS14 self._clearApproval(owner, _tokenId)15 self._removeTokenFrom(owner, _tokenId)16 log Transfer(owner, ZERO_ADDRESS, _tokenId)அனைத்தையும் காட்டுஒரு டோக்கனை மாற்ற அனுமதிக்கப்பட்ட எவரும் அதை அழிக்கவும் அனுமதிக்கப்படுவார்கள். அழிப்பது பூஜ்ஜிய முகவரிக்கு மாற்றுவதற்குச் சமமாகத் தோன்றினாலும், பூஜ்ஜிய முகவரி உண்மையில் டோக்கனைப் பெறுவதில்லை. டோக்கனுக்காகப் பயன்படுத்தப்பட்ட அனைத்து சேமிப்பகத்தையும் விடுவிக்க இது நம்மை அனுமதிக்கிறது, இது பரிவர்த்தனையின் எரிவாயு செலவைக் குறைக்கும்.
இந்த ஒப்பந்தத்தைப் பயன்படுத்துதல்
Solidity-க்கு மாறாக, Vyper-இல் பரம்பரை (inheritance) இல்லை. இது குறியீட்டைத் தெளிவாக்குவதற்கும், எனவே பாதுகாப்பதை எளிதாக்குவதற்கும் ஒரு வேண்டுமென்றே செய்யப்பட்ட வடிவமைப்புத் தேர்வாகும். எனவே உங்கள் சொந்த Vyper ERC-721 ஒப்பந்தத்தை உருவாக்க, நீங்கள் இந்த ஒப்பந்தத்தை (opens in a new tab) எடுத்து, நீங்கள் விரும்பும் வணிக தர்க்கத்தைச் செயல்படுத்த அதை மாற்றியமைக்கலாம்.
முடிவுரை
மதிப்பாய்வுக்காக, இந்த ஒப்பந்தத்தில் உள்ள சில மிக முக்கியமான யோசனைகள் இங்கே:
- பாதுகாப்பான பரிமாற்றத்துடன் ERC-721 டோக்கன்களைப் பெற, ஒப்பந்தங்கள்
ERC721Receiverஇடைமுகத்தைச் செயல்படுத்த வேண்டும். - நீங்கள் பாதுகாப்பான பரிமாற்றத்தைப் பயன்படுத்தினாலும், தனிப்பட்ட விசை தெரியாத முகவரிக்கு டோக்கன்களை அனுப்பினால் அவை இன்னும் சிக்கிக்கொள்ளலாம்.
- ஒரு செயல்பாட்டில் சிக்கல் ஏற்படும் போது, தோல்வி மதிப்பைத் திருப்பி அனுப்புவதை விட, அழைப்பை
revertசெய்வது நல்லது. - ERC-721 டோக்கன்கள் ஒரு உரிமையாளரைக் கொண்டிருக்கும் போது இருக்கும்.
- ஒரு NFT-ஐ மாற்றுவதற்கு அங்கீகரிக்கப்பட மூன்று வழிகள் உள்ளன. நீங்கள் உரிமையாளராக இருக்கலாம், ஒரு குறிப்பிட்ட டோக்கனுக்கு அங்கீகரிக்கப்படலாம் அல்லது உரிமையாளரின் அனைத்து டோக்கன்களுக்கும் ஆபரேட்டராக இருக்கலாம்.
- கடந்த கால நிகழ்வுகள் பிளாக்செயினுக்கு வெளியே மட்டுமே தெரியும். பிளாக்செயினுக்குள் இயங்கும் குறியீட்டால் அவற்றைப் பார்க்க முடியாது.
இப்போது சென்று பாதுகாப்பான Vyper ஒப்பந்தங்களைச் செயல்படுத்துங்கள்.
எனது மேலும் பல பணிகளுக்கு இங்கே பார்க்கவும் (opens in a new tab).
பக்கம் கடைசியாகப் புதுப்பிக்கப்பட்டது: 22 ஆகஸ்ட், 2025