आप एक ऐसा कन्ट्रैक्ट चाहते हैं जो तलवारें, पोटियंस और कुंजी जारी करे, जिनमें प्रत्येक का अपना टोकन ID हो, और आप यह जानना चाहते हैं कि नए टोकन बनाने की अनुमति किसके पास है। एजेंट Solidity कोड लिखता है, आपके कंपाइल और टेस्ट कमांड्स को लोकल चेन या टेस्ट नेटवर्क पर चलाता है, और हर कदम को असल नतीजे के साथ एक कार्ड के रूप में दिखाता है। यह गाइड मिंटिंग फ़ंक्शन पर ध्यान केंद्रित करती है, क्योंकि जो भी इसे कॉल कर सकता है, वह तय करता है कि कितने टोकन मौजूद होंगे। एक डिप्लॉय किए गए कन्ट्रैक्ट को बदला नहीं जा सकता, इसलिए यहाँ सब कुछ एक लोकल चेन या टेस्ट नेटवर्क पर रहता है, जिनके सिक्कों की कोई वैल्यू नहीं होती। शुरुआत करने वाले चारों स्टेप्स को क्रम में फॉलो कर सकते हैं, और अनुभवी पाठक आगे दिए गए वॉकथ्रू पर सीधे जा सकते हैं। टिकट सेट के लिए भी ये चारों स्टेप्स समान रूप से काम करते हैं, जहाँ प्रत्येक टिकट टाइप को अपना ID मिलता है और मिंटिंग फ़ंक्शन तय करता है कि प्रत्येक की कितनी इकाइयाँ मौजूद होंगी।
WaveClamp शुरू करें, अपने .sol फ़ाइलों और टेस्ट्स वाले फ़ोल्डर को चैट के वर्किंग फ़ोल्डर के रूप में चुनें, और 'Ask first' चुनें ताकि हर बदलाव एक डिफ़ के रूप में आए जिसे आप स्वीकार या अस्वीकार कर सकें। फ़ाइल टूल्स उसी फ़ोल्डर के अंदर काम करते हैं, इसलिए प्रोजेक्ट को एक ही जगह रखें। अगर आप सिर्फ प्रैक्टिस करना चाहते हैं, तो पहली रन के लिए एक अस्थायी फ़ोल्डर बनाएं।
तीन आइटम टाइप्स वाले एक गेम आइटम कन्ट्रैक्ट, एक मिंटिंग फ़ंक्शन जिसकेवल एक ओनर अकाउंट कॉल कर सके, और बैच ट्रांसफर्स के लिए पूछें, और एजेंट को write_file के साथ फ़ाइल बनाने दें। फ़ाइल का नाम कन्ट्रैक्ट के अनुसार रखें ताकि बाद के स्टेप्स उसका हवाला दे सकें। पहली रिक्वेस्ट छोटी रखें, क्योंकि एक बार डिफ़ स्वीकार करने के बाद दूसरी रिक्वेस्ट में बैच ट्रांसफर्स जोड़े जा सकते हैं।
एजेंट को कहें कि वह आपके कंपाइल कमांड और टेस्ट कमांड को Shell के माध्यम से चलाए, फिर विस्तारित कार्ड पर एग्जिट कोड और किसी भी फेल टेस्ट के नाम पढ़े। सफलता का निर्णय असल एग्जिट कोड के आधार पर लगाया जाता है, किसी सारांश के आधार पर नहीं। अगर कंपाइल कमांड फेल होता है, तो कार्ड एरर टेक्स्ट दिखाता है, और एजेंट उसे पढ़ सकता है और एक नए डिफ़ के रूप में फिक्स का प्रस्ताव दे सकता है।
विस्तारित कार्ड खोलें, डिफ़ और कमांड आउटपुट पढ़ें, जो सही है उसे स्वीकार करें, बाकी को अस्वीकार करें, और जहाँ टेस्ट अभी भी फेल हो रहा है वहाँ फिक्स मांगें। टेस्ट्स पास होने तक दोहराएं, फिर मिंटिंग फ़ंक्शन को एक बार फिर पढ़ें। प्रत्येक स्वीकृत डिफ़ को छोटा रखें, ताकि बाद में कोई फेलियर एक ही बदलाव की ओर इशारा करे, दस के नहीं।
MultiTokenMinimal.solसहेजा गयाMultiTokenMinimal.sol14 लाइनेंbalanceOf1 मेलyour compile commandएग्जिट 0// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
interface IMultiTokenMinimal {
event TransferSingle(address indexed operator,
address indexed from, address indexed to,
uint256 id, uint256 value);
function balanceOf(address account, uint256 id)
external view returns (uint256);
function uri(uint256 id)
external view returns (string memory);
}यह रीड-ओनली इंटरफ़ेस मल्टी-टोकन स्टैंडर्ड के TransferSingle इवेंट और balanceOf व uri फंक्शन्स को घोषित करता है। इसमें कोई स्टेट, कोई मिंटिंग लॉजिक और कोई कीज़ नहीं हैं, जो इसे असल लॉजिक जोड़ने से पहले पढ़ने के लिए एक छोटी फ़ाइल बनाता है। पहले इस पर अपना कंपाइल कमांड चलाएं। पहले कंपाइल करें, फिर एजेंट को एक-एक समीक्षित डिफ़ के साथ विस्तारित होने दें, मिंटिंग फ़ंक्शन से शुरू करते हुए। फ़ाइल का नाम उदाहरण लेबल से मेल खाता है, ताकि आप बाद में एजेंट से इसे खोलने के लिए कह सकें।
कन्ट्रैक्ट खोलें और एजेंट से कहें कि वह ERC1155 _mint हेल्पर को एक पब्लिक फंक्शन में घेरें जो केवल ओनर अकाउंट कॉल कर सके। एजेंट read_file का उपयोग करके वर्तमान कोड देखता है और edit_file का उपयोग करके फंक्शन डालता है, और बदलाव को एक डिफ़ के रूप में दिखाता है। सामान्य ओपन-सोर्स इम्प्लीमेंटेशन में _mint और _mintBatch नाम के इंटरनल हेल्पर एक्सपोज़ किए जाते हैं, और एक इंटरनल हेल्पर के पास अपना एक्सेस चेक नहीं होता, जिसकी वजह से वrapper मायने रखता है। आप इसी विधि से एक ERC20 टोकन चरण-दर-चरण बना सकते हैं, लेकिन गेम आइटम सेट को ID की जरूरत होती है, इसलिए मल्टी-टोकन लेआउट से शुरू करें। Shell फिर आपके कंपाइल कमांड और टेस्ट कमांड को चलाता है, और प्रत्येक कार्ड एक असल एग्जिट कोड दिखाता है। टेस्ट्स को पढ़ लेने के बाद ही डिफ़ स्वीकार करें।
अपने प्रोजेक्ट से एक ERC721 कन्ट्रैक्ट उदाहरण खोलें, या एजेंट से write_file के साथ एक लिखने को कहें, और इसे अपने आइटम सेट के बगल में रखें। एजेंट grep का उपयोग करके दोनों फ़ाइलों में फंक्शन्स की सूची बनाता है और read_file का उपयोग करके यह तुलना करता है कि ओनरशिप कैसे स्टोर की जाती है: यूनिक-टोकन फ़ाइल में प्रत्येक टोकन के लिए एक ओनर, और मल्टी-टोकन फ़ाइल में प्रत्येक अकाउंट और ID के लिए बैलेंस। सोलबौंड NFTs का उपयोग करके डिसेंट्रलाइज्ड प्रोफाइल्स के लिए एक स्टैंडर्ड की जरूरत होती है जिसमें टोकन ट्रांसफर नहीं किए जा सकते, जो कि उन आइटम्स से अलग डिज़ाइन है जिन्हें खिलाड़ी बांटते हैं। एजेंट से अंतरों को एक छोटी टेबल में डालने को कहें। आप चैट में तुलना पढ़ते हैं, तय करते हैं कि आपका डिज़ाइन किस स्टैंडर्ड के लिए उपयुक्त है, और तभी कोड बदलाव के लिए कहते हैं।
खिलाड़ी अक्सर एक साथ कई आइटम टाइप्स खाली करते हैं, इसलिए एजेंट से कन्ट्रैक्ट में safeBatchTransferFrom और balanceOfBatch जोड़ने को कहें। एजेंट बदलाव के लिए edit_file का उपयोग करता है, टेस्ट फ़ाइलों को खोजने के लिए glob का उपयोग करता है, और हर एडिट के बाद आपके टेस्ट कमांड को Shell के माध्यम से चलाता है। बैच फंक्शन्स एक ही ट्रांज़ैक्शन में कई टोकन IDज़ को खाली करते हैं, जिसका मतलब है कि एक टेस्ट कई बैलेंस चेक कर सकता है। ERC4337 गैसलेस ऑनबोर्डिंग को समझना एक अलग विषय है, इसलिए इसे पहले कन्ट्रैक्ट में न रखें और इसे अलग से टेस्ट करें। 'Ask first' में डिफ़ पढ़ें, टेस्ट फिर से चलाएं, और बदलाव स्वीकार करने से पहले आउटपुट में TransferBatch इवेंट की तलाश करें।
एक कन्ट्रैक्ट जो टोकन प्राप्त करता है, उसे onERC1155Received और onERC1155BatchReceived लागू करना चाहिए और टोकन स्वीकार करने चाहिए, वरना सेफ ट्रांसफर रिजेक्ट हो जाता है। एजेंट से दोनों नामों के लिए grep चलाने और read_file के साथ रिसीविंग कन्ट्रैक्ट खोलने को कहें, फिर सूची बनाएं कि कौन सा फंक्शन गायब है। फिर uri(id) वैल्यू पर edit_file का उपयोग करने को कहें ताकि इसमें {id} हो, जिसे क्लाइंट्स टोकन ID के लोअरकेस हेक्सडेसिमल में बदलते हैं, 64 अंकों तक पैड किया गया। प्रत्येक ID के लिए एक JSON फ़ाइल लिखने के लिए write_file का उपयोग करें। अपना कंपाइल कमांड और टेस्ट कमांड चलाएं, दोनों एग्जिट कोड पढ़ें, और स्वीकार करने से पहले अंतिम डिफ़ की समीक्षा करें।
