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

⁦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 कार्ये आणि वैशिष्ट्ये:

बॅच हस्तांतरण

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

ERC-1155 मधील एकमेव फरक हा आहे की आपण मूल्ये अ‍ॅरे (array) म्हणून पास करतो आणि आपण आयडींचा (ids) अ‍ॅरे देखील पास करतो. उदाहरणार्थ 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 आवृत्ती आहे:

// ERC-20
function balanceOf(address owner) external view returns (uint256);

// ERC-1155
function balanceOfBatch(
    address[] calldata _owners,
    uint256[] calldata _ids
) external view returns (uint256[] memory);

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

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

[
    balanceOf(0xbeef...),
    balanceOf(0x1337...),
    balanceOf(0x1111...)
]

बॅच मंजुरी

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

सध्याची स्थिती isApprovedForAll द्वारे वाचली जाऊ शकते. जसे तुम्ही पाहू शकता, हे सर्व-किंवा-काहीही नाही (all-or-nothing) असे ऑपरेशन आहे. तुम्ही किती टोकन्स मंजूर करायचे किंवा कोणता टोकन क्लास मंजूर करायचा हे परिभाषित करू शकत नाही.

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

रिसिव्ह हुक

function onERC1155BatchReceived(
    address _operator,
    address _from,
    uint256[] calldata _ids,
    uint256[] calldata _values,
    bytes calldata _data
) external returns(bytes4);

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

bytes4(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' काढून टाका.

पुढील वाचन