ERC-1155 मल्टी-टोकन स्टँडर्ड

प्रस्तावना

अनेक टोकन प्रकारांचे व्यवस्थापन करणाऱ्या कॉन्ट्रॅक्टसाठी एक स्टँडर्ड इंटरफेस. एकाच तैनात केलेल्या कॉन्ट्रॅक्टमध्ये फंजिबल टोकन, नॉन-फंजिबल टोकन किंवा इतर कॉन्फिगरेशन्सचे (उदा., सेमी-फंजिबल टोकन) कोणतेही संयोजन समाविष्ट असू शकते.

मल्टी-टोकन स्टँडर्ड याचा अर्थ काय आहे?

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

ERC-1155 टोकनचे पूर्ण वर्णन EIP-1155 (opens in a new tab) मध्ये केले आहे.

पूर्वतयारी

हे पेज अधिक चांगल्या प्रकारे समजून घेण्यासाठी, आम्ही शिफारस करतो की तुम्ही प्रथम टोकन स्टँडर्ड, ERC-20, आणि ERC-721 बद्दल वाचा.

ERC-1155 फंक्शन्स आणि वैशिष्ट्ये:

• बॅच ट्रान्सफर: एकाच कॉलमध्ये एकाधिक मालमत्ता हस्तांतरित करा.
• बॅच बॅलन्स: एकाच कॉलमध्ये एकाधिक मालमत्तांची शिल्लक मिळवा.
• बॅच अप्रूव्हल: सर्व टोकन एका अॅड्रेससाठी मंजूर करा.
• हुक्स: टोकन प्राप्त करण्यासाठी हुक.
• NFT सपोर्ट: पुरवठा फक्त 1 असल्यास, त्याला NFT म्हणून माना.
• सुरक्षित हस्तांतरण नियम: सुरक्षित हस्तांतरणासाठी नियमांचा संच.

बॅच ट्रान्सफर

बॅच हस्तांतरण नियमित ERC-20 हस्तांतरणासारखेच कार्य करते. चला नियमित ERC-20 transferFrom फंक्शन पाहूया:

1// ERC-20
2function transferFrom(address from, address to, uint256 value) external returns (bool);
3
4// ERC-1155
5function safeBatchTransferFrom(
6    address _from,
7    address _to,
8    uint256[] calldata _ids,
9    uint256[] calldata _values,
10    bytes calldata _data
11) external;
सर्व दाखवा
कॉपी

ERC-1155 मध्ये फक्त फरक हा आहे की आपण व्हॅल्यूज एका अॅरे म्हणून पास करतो आणि आपण आयडींचा अॅरे देखील पास करतो. उदाहरणार्थ, ids=[3, 6, 13] आणि values=[100, 200, 5] दिल्यास, परिणामी हस्तांतरणे अशी असतील

1. _from पासून _to कडे आयडी 3 असलेले 100 टोकन हस्तांतरित करा.
2. _from पासून _to कडे आयडी 6 असलेले 200 टोकन हस्तांतरित करा.
3. _from पासून _to कडे आयडी 13 असलेले 5 टोकन हस्तांतरित करा.

ERC-1155 मध्ये आपल्याकडे फक्त transferFrom आहे, transfer नाही. याचा नियमित transfer सारखा वापर करण्यासाठी, फक्त 'from' अॅड्रेस फंक्शन कॉल करणाऱ्या अॅड्रेसवर सेट करा.

बॅच बॅलन्स

संबंधित ERC-20 balanceOf कॉलला देखील बॅच सपोर्टसह त्याचे पार्टनर फंक्शन आहे. एक आठवण म्हणून, ही ERC-20 आवृत्ती आहे:

1// ERC-20
2function balanceOf(address owner) external view returns (uint256);
3
4// ERC-1155
5function balanceOfBatch(
6    address[] calldata _owners,
7    uint256[] calldata _ids
8) external view returns (uint256[] memory);
कॉपी

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

उदाहरणार्थ _ids=[3, 6, 13] आणि _owners=[0xbeef..., 0x1337..., 0x1111...] दिल्यास, रिटर्न व्हॅल्यू अशी असेल

1[
2    balanceOf(0xbeef...),
3    balanceOf(0x1337...),
4    balanceOf(0x1111...)
5]
कॉपी

बॅच अप्रूव्हल

1// ERC-1155
2function setApprovalForAll(
3    address _operator,
4    bool _approved
5) external;
6
7function isApprovedForAll(
8    address _owner,
9    address _operator
10) external view returns (bool);
सर्व दाखवा
कॉपी

मंजुरी ERC-20 पेक्षा थोड्या वेगळ्या आहेत. विशिष्ट रकमेला मंजुरी देण्याऐवजी, तुम्ही setApprovalForAll द्वारे ऑपरेटरला मंजूर किंवा नामंजूर म्हणून सेट करता.

सध्याची स्थिती isApprovedForAll द्वारे वाचता येते. तुम्ही पाहू शकता की, हे एक 'ऑल-ऑर-नथिंग' ऑपरेशन आहे. तुम्ही किती टोकन मंजूर करायचे किंवा कोणता टोकन वर्ग मंजूर करायचा हे परिभाषित करू शकत नाही.

हे सोपेपणा लक्षात घेऊन हेतुपुरस्सर डिझाइन केले आहे. तुम्ही फक्त एका अॅड्रेससाठी सर्वकाही मंजूर करू शकता.

रिसीव्ह हुक

1function onERC1155BatchReceived(
2    address _operator,
3    address _from,
4    uint256[] calldata _ids,
5    uint256[] calldata _values,
6    bytes calldata _data
7) external returns(bytes4);
कॉपी

EIP-165 (opens in a new tab) सपोर्टमुळे, ERC-1155 केवळ स्मार्ट कॉन्ट्रॅक्ट्ससाठी रिसीव्ह हुक्सना सपोर्ट करते. हुक फंक्शनने एक मॅजिक पूर्वनिर्धारित bytes4 व्हॅल्यू परत करणे आवश्यक आहे, जे खालीलप्रमाणे दिले आहे:

1bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))
कॉपी

जेव्हा प्राप्त करणारा कॉन्ट्रॅक्ट ही व्हॅल्यू परत करतो, तेव्हा असे मानले जाते की कॉन्ट्रॅक्ट हस्तांतरण स्वीकारतो आणि ERC-1155 टोकन कसे हाताळायचे हे त्याला माहीत आहे. उत्तम, आता कॉन्ट्रॅक्टमध्ये टोकन अडकणार नाहीत!

NFT सपोर्ट

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

सुरक्षित हस्तांतरण नियम

आपण मागील स्पष्टीकरणांमध्ये आधीच काही सुरक्षित हस्तांतरण नियमांवर चर्चा केली आहे. पण चला सर्वात महत्त्वाच्या नियमांवर नजर टाकूया:

1. कॉलरला _from अॅड्रेससाठी टोकन खर्च करण्याची परवानगी असणे आवश्यक आहे किंवा कॉलर स्वतः _from असणे आवश्यक आहे.
2. हस्तांतरण कॉल रिव्हर्ट होणे आवश्यक आहे जर
   1. _to अॅड्रेस 0 आहे.
   2. _ids ची लांबी _values च्या लांबी समान नाही.
   3. _ids मधील टोकनसाठी धारकाची कोणतीही शिल्लक प्राप्तकर्त्याला पाठवलेल्या _values मधील संबंधित रकमेपेक्षा कमी असेल.
   4. इतर कोणतीही त्रुटी उद्भवल्यास.

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

पुढील वाचन

• EIP-1155: मल्टी टोकन स्टँडर्ड (opens in a new tab)
• ERC-1155: Openzeppelin डॉक्स (opens in a new tab)
• ERC-1155: GitHub रेपो (opens in a new tab)
• Alchemy NFT API (opens in a new tab)