मुझे लगता था कि Solana पर NFT बनाने का मतलब Metaplex के साथ जूझना है। हर ट्यूटोरियल यही रास्ता बताता था

मैं पहले यह मानकर चलता था कि Solana पर NFT बनाने का मतलब Metaplex के साथ संघर्ष करना है। हर ट्यूटोरियल यही रास्ता सुझाता था: एक Candy Machine शुरू करना, metadata accounts को मैनेज करना, और सिर्फ एक टोकन के साथ नाम और इमेज जोड़ने के लिए अलग-अलग प्रोग्राम्स को संभालना। पता चला कि वह धारणा पुरानी हो चुकी थी। Token Extensions प्रोग्राम, जिसे Token-2022 के रूप में भी जाना जाता है, ने उस जटिलता को सीधे mint के भीतर ही समेट दिया है। अब आप किसी metadata प्रोग्राम को छुए बिना या अतिरिक्त accounts को फंड किए बिना एक पूरी तरह से काम करने वाला NFT बना सकते हैं। आप बस कुछ flags बदलते हैं, सीधे mint account में डेटा लिखते हैं, और आपका काम हो जाता है।

यह डेवलपर्स के सोचने के तरीके को बदल देता है कि Solana पर डिजिटल एसेट्स के बारे में कैसे सोचा जाए। पारंपरिक वेब डेवलपमेंट में, एक NFT एक अलग डेटा स्ट्रक्चर की तरह महसूस होता है, कुछ ऐसा जिसे अपने स्वयं के table और schema की आवश्यकता होती है। Solana पर, वास्तविकता अधिक सरल और सुरुचिपूर्ण है। एक NFT किसी बाहरी प्रोटोकॉल द्वारा प्रबंधित कोई विशेष ऑब्जेक्ट नहीं है। यह केवल एक mint account है जिसे ठीक एक की supply और शून्य decimals के साथ कॉन्फ़िगर किया गया है। एक standard token आपको इकाइयों (units) को विभाजित करने की अनुमति देता है क्योंकि इसमें बड़ी supply और कई decimals होते हैं। एक NFT supply को एक एकल, अविभाज्य इकाई (indivisible unit) तक सीमित कर देता है। वह सब कुछ जो इसे अद्वितीय बनाता है, उन extensions में रहता है जो उस मुख्य mint account के साथ चलते हैं।

पुराना तरीका और नया तरीका

Token Extensions से पहले, मानक स्टैक (canonical stack) में mint के लिए SPL Token प्रोग्राम, और metadata, collections और कभी-कभी off-chain indexing के लिए Metaplex शामिल था। Metadata अलग-अलग accounts में रहता था, जो उन addresses से जुड़े होते थे जिन्हें आपको ट्रैक करना पड़ता था। यह काम तो करता था, लेकिन इसने जटिलता (surface area) बढ़ा दी थी। अधिक accounts का मतलब था अधिक rent, अधिक signing paths, और एक टोकन की पूरी तस्वीर समझने के लिए अधिक client-side logic।

Token Extensions उन क्षमताओं को सीधे mint में शामिल करके उस बिखराव (sprawl) को समाप्त कर देता है। नाम, symbol और off-chain media के लिए एक pointer चाहिए? metadata extension को enable करें। टोकन को एक collection में समूहबद्ध (group) करना है? Group और Member extensions का उपयोग करें। Mint ही 'single source of truth' बन जाता है। relational databases के आदी डेवलपर्स के लिए, यह बदलाव एक distributed microservices architecture से वापस well-designed foreign keys वाले एक normalized table पर जाने जैसा महसूस होता है।

Extension-आधारित NFT की संरचना (Anatomy)

Token Extensions के साथ NFT बनाने के लिए यह समझना आवश्यक है कि इस chain पर एक टोकन को non-fungible क्या बनाता है। Supply ठीक एक होनी चाहिए। Decimals शून्य होने चाहिए। ये दो प्रतिबंध (constraints) fractionalization को रोकते हैं। एक बार जब ये पैरामीटर सेट हो जाते हैं, तो आप उन extensions को enable करते हैं जो अतिरिक्त fields को सीधे mint account पर स्टोर करते हैं।

Metadata extension में name, symbol और URI होता है। वह URI एक JSON file की ओर इशारा करता है, जो आमतौर पर decentralized storage या एक standard web server पर होस्ट की जाती है, जो image, attributes और traits का वर्णन करती है। इसे खोजने और deserialize करने के लिए कोई अलग metadata account नहीं होता है। डेटा स्वयं mint पर होता है, जिसका अर्थ है कि explorers, wallets और client software केवल एक account का निरीक्षण करके टोकन की मूल पहचान पढ़ सकते हैं।

मैंने इसे devnet पर स्वयं टेस्ट किया। मैंने metadata extension को enable करके एक नया mint बनाया, फिर सीधे mint state में name और symbol लिख दिया। Transaction सफल रहा, और परिणाम तुरंत Solana Explorer में दिखाई दिया। फंड करने या खोजने के लिए कोई दूसरा account नहीं था। multi-account Metaplex metadata के साथ हफ्तों काम करने के बाद, इसकी सरलता लगभग हैरान कर देने वाली थी।

Database Rows की तरह Collections बनाना

Collections अगला तार्किक कदम थे। पुराने मॉडल में, NFTs को समूहबद्ध करने का मतलब आमतौर पर Metaplex Certified Collections या off-chain registries पर निर्भर रहना होता था। Token Extensions दो विशिष्ट primitives पेश करता है: Group extension और Member extension।

यहाँ तर्क (logic) इस प्रकार काम करता है: आप एक एकल mint बनाते हैं जो collection header के रूप में कार्य करता है और उस पर Group extension को enable करते हैं। फिर, collection के प्रत्येक व्यक्तिगत NFT के लिए, आप Member extension को enable करके एक mint बनाते हैं। प्रत्येक member mint collection mint address पर वापस एक pointer स्टोर करता है। यह संबंध ठीक एक relational database में foreign key की तरह व्यवहार करता है। Collection row एक ही बार मौजूद होती है, और प्रत्येक member row collection identity को डुप्लिकेट किए बिना उसे reference करती है।

मैंने devnet पर इस तरह से एक छोटा टेस्ट collection बनाया। मुख्य collection mint में group flag था। व्यक्तिगत टोकन में member flag था और वे parent address को reference करते थे। Chain को query करने से मुझे एक साफ और traversable structure मिला। यह अनुमान लगाने के लिए किसी तीसरे पक्ष के indexer की आवश्यकता नहीं थी कि टोकन एक साथ संबंधित हैं या नहीं। यह संबंध स्पष्ट (explicit) और on-chain है।

ओपन स्कीमा और ऑन-चैन प्रयोग

एक बात जो विशेष रूप से ध्यान खींचती है, वह है मेटाडेटा एक्सटेंशन का ओपन स्कीमा। पुराने मानक अक्सर एक निश्चित फ़ील्ड सूची लागू करते हैं। यदि आप ऑन-चैन कुछ गैर-मानक (non-standard) स्टोर करना चाहते थे, तो आप उसे ऑफ-चैन JSON में रखने या कठोर अकाउंट लेआउट के साथ जुगाड़ करने के लिए मजबूर थे।

Token Extensions एक अलग दृष्टिकोण अपनाता है। क्योंकि मेटाडेटा एक्सटेंशन कस्टम फ़ील्ड स्वीकार करता है, मैं सीधे मिंट अकाउंट (mint account) में एक 'रैरिटी एट्रीब्यूट' (rarity attribute) जोड़ सका। मैंने फ़ील्ड लिखा, ट्रांजेक्शन भेजा, और Solana Explorer को रिफ्रेश किया। नाम और सिंबल के साथ ही 'रैरिटी वैल्यू' तुरंत दिखाई देने लगी। गेम डेवलपर्स या डायनेमिक एसेट्स बनाने वाले किसी भी व्यक्ति के लिए, यह लचीलापन महत्वपूर्ण है। आप JSON को पार्स करने के लिए किसी बाहरी सत्यापनकर्ता (external verifier) की आवश्यकता के बिना ऑन-चैन महत्वपूर्ण गुणों (traits) को प्रदर्शित कर सकते हैं।

ऑफ-चैन गैप: URIs और कैशिंग

ऑन-चैन स्टोरेज की तमाम खूबियों के बावजूद, एक सबक स्पष्ट रूप से सामने आया: पहचान अभी भी ऑफ-चैन रहती है। मिंट आपकी इमेज स्टोर नहीं करता है। यह एक URI स्टोर करता है। जब मैंने उस URI को अपडेट किया और devnet पर बदलाव कमिट किया, तो चेन ने तुरंत नए पॉइंटर को दर्शाया। ब्लॉक एक्सप्लोरर्स ने बिना किसी देरी के अपडेट किया हुआ लिंक दिखाया।

लेकिन मेरे वॉलेट में देरी (lag) हुई। यह मिनटों तक पुरानी इमेज दिखाता रहा, और ज़िद पर अड़ा रहा कि वह कैश किया हुआ वर्शन ही दिखाए, जबकि ऑन-चैन मूल डेटा पहले ही बदल चुका था। यह एक व्यावहारिक वास्तविकता है जिसके लिए डेवलपर्स को योजना बनानी चाहिए। Solana लेजर तेज़ है। कन्फर्मेशन समय कम है। फिर भी, वह विजुअल लेयर जिसके साथ उपयोगकर्ता इंटरैक्ट करते हैं, वह HTTP कैश, CDN प्रोपेगेशन और वॉलेट-विशिष्ट रिफ्रेश इंटरवल पर निर्भर करती है। यदि आप एक डायनेमिक NFT बनाते हैं जो वास्तविक दुनिया की घटनाओं के आधार पर बदलता है, तो आप यह मानकर नहीं चल सकते कि ट्रांजेक्शन होते ही उपयोगकर्ता को बदलाव दिख जाएगा। आपको कैश-बस्टिंग रणनीतियों (cache-busting strategies), अपने URI पाथ में वर्जनिंग, या अपने फ्रंटएंड में स्पष्ट रिफ्रेश ट्रिगर्स की आवश्यकता होगी।

आगे क्या

मेरे devnet प्रयोगों ने एक अधिक डायनेमिक प्रोजेक्ट के लिए आधार तैयार कर दिया है। अगला कदम एक कलेक्शन है