હું એવું માનતો હતો કે Solana પર NFT બનાવવાનો અર્થ Metaplex સાથે માથાકૂટ કરવી એવો હતો. દરેક ટ્યુટોરિયલ આ જ રસ્તો સૂચવતું હતું: Candy Machine શરૂ કરો, metadata accounts મેનેજ કરો, અને ટોકન સાથે નામ અને ઈમેજ જોડવા માટે અલગ-અલગ પ્રોગ્રામ્સ સંભાળો. હવે ખબર પડી કે એ ધારણા જૂની થઈ ગઈ છે. Token Extensions પ્રોગ્રામ, જેને Token-2022 તરીકે પણ ઓળખવામાં આવે છે, તેણે આ જટિલતાને સીધી mint માં જ સમાવી દીધી છે. હવે તમે કોઈ metadata પ્રોગ્રામને અડક્યા વગર અથવા વધારાના એકાઉન્ટ્સમાં ફંડિંગ કર્યા વગર સંપૂર્ણ રીતે કાર્યરત NFT બનાવી શકો છો. તમે ફક્ત થોડા ફ્લેગ્સ બદલો છો, ડેટા સીધો mint account માં લખો છો, અને તમારું કામ પૂરું.

આ Solana પર ડિજિટલ એસેટ્સ વિશે ડેવલપર્સે કેવી રીતે વિચારવું જોઈએ તે બદલી નાખે છે. પરંપરાગત વેબ ડેવલપમેન્ટમાં, NFT એક અલગ ડેટા સ્ટ્રક્ચર જેવું લાગે છે, જે પોતાની અલગ ટેબલ અને સ્કીમાની માંગ કરે છે. Solana પર, વાસ્તવિકતા વધુ સરળ અને સુંદર છે. NFT એ કોઈ બાહ્ય પ્રોટોકોલ દ્વારા સંચાલિત વિશેષ ઓબ્જેક્ટ નથી. તે ફક્ત એક mint account છે જેને બરાબર એક સપ્લાય અને શૂન્ય ડેસિમલ (decimals) સાથે કોન્ફિગર કરવામાં આવ્યું છે. એક સ્ટાન્ડર્ડ ટોકન તમને યુનિટ્સ વહેંચવાની મંજૂરી આપે છે કારણ કે તેની પાસે મોટી સપ્લાય અને મલ્ટિપલ ડેસિમલ્સ હોય છે. એક NFT સપ્લાયને એક જ, અવિભાજ્ય યુનિટ પર લોક કરે છે. જે કંઈ પણ તેને અનન્ય બનાવે છે તે બધું જ તે મુખ્ય mint account ની સાથે ચાલતા extensions માં રહેલું છે.

જૂની રીત અને નવી રીત

Token Extensions પહેલાં, પ્રમાણભૂત સ્ટેક (canonical stack) માં mint માટે SPL Token પ્રોગ્રામ, અને metadata, collections અને ક્યારેક off-chain indexing માટે Metaplex નો સમાવેશ થતો હતો. Metadata અલગ એકાઉન્ટ્સમાં રહેતું હતું, જે એડ્રેસ દ્વારા જોડાયેલું હતું જેને તમારે ટ્રેક કરવું પડતું હતું. તે કામ તો કરતું હતું, પરંતુ તે જટિલતા વધારતું હતું. વધુ એકાઉન્ટ્સ એટલે વધુ રેન્ટ (rent), વધુ સાઇનિંગ પાથ્સ (signing paths), અને ટોકનની સંપૂર્ણ માહિતી મેળવવા માટે વધુ ક્લાયન્ટ-સાઇડ લોજિક.

Token Extensions આ વિખરાયેલી પદ્ધતિને બદલે ક્ષમતાઓને સીધી mint માં જ સામેલ કરીને તેને બદલી નાખે છે. નામ, સિમ્બોલ અને off-chain મીડિયા માટે પોઇન્ટર જોઈએ છે? metadata extension સક્ષમ કરો. ટોકન્સને કલેક્શનમાં ગ્રુપ કરવા છે? Group અને Member extensions નો ઉપયોગ કરો. Mint એ સત્યનો એકમાત્ર સ્ત્રોત (single source of truth) બની જાય છે. રિલેશનલ ડેટાબેઝના ઉપયોગમાં રહેલા ડેવલપર્સ માટે, આ ફેરફાર એવું લાગે છે કે જાણે તમે ડિસ્ટ્રિબ્યુટેડ માઇક્રોસર્વિસ આર્કિટેક્ચરથી પાછા આવીને સારી રીતે ડિઝાઇન કરેલી ફોરેન કી (foreign keys) ધરાવતા નોર્મલાઇઝ્ડ ટેબલ પર આવી ગયા હોવ.

Extension-આધારિત NFT ની રચના

Token Extensions સાથે NFT બનાવવા માટે આ ચેઇન પર ટોકનને નોન-ફંગિબલ (non-fungible) શું બનાવે છે તે સમજવું જરૂરી છે. સપ્લાય (supply) એક હોવી જોઈએ. ડેસિમલ્સ (decimals) શૂન્ય હોવા જોઈએ. આ બે શરતો તેને ભાગલા પાડી શકાય તેવું (fractionalization) બનતા અટકાવે છે. એકવાર આ પેરામીટર્સ સેટ થઈ જાય પછી, તમે એવા extensions સક્ષમ કરો છો જે સીધા mint account પર વધારાના ફીલ્ડ્સ સ્ટોર કરે છે.

Metadata extension નામ, સિમ્બોલ અને URI ધરાવે છે. તે URI એક JSON ફાઇલ તરફ નિર્દેશ કરે છે, જે સામાન્ય રીતે ડિસેન્ટ્રલાઇઝ્ડ સ્ટોરેજ અથવા સ્ટાન્ડર્ડ વેબ સર્વર પર હોસ્ટ કરેલી હોય છે, જે ઈમેજ, એટ્રિબ્યુટ્સ અને ટ્રેટ્સનું વર્ણન કરે છે. શોધવા અને ડી-સીરીયલાઈઝ (deserialize) કરવા માટે કોઈ અલગ metadata એકાઉન્ટ હોતું નથી. ડેટા સીધો mint પર જ હોય છે, જેનો અર્થ છે કે એક્સપ્લોરર્સ (explorers), વોલેટ્સ (wallets) અને ક્લાયન્ટ સોફ્ટવેર માત્ર એક જ એકાઉન્ટની તપાસ કરીને ટોકનની મુખ્ય ઓળખ વાંચી શકે છે.

મેં આનુંផ្ទ્યત પરીક્ષણ devnet પર કર્યું. મેં metadata extension સક્ષમ કરીને એક નવું mint બનાવ્યું, પછી સીધું જ mint state માં નામ અને સિમ્બોલ લખ્યું. ટ્રાન્ઝેક્શન સફળ રહ્યું અને પરિણામ તરત જ Solana Explorer માં દેખાયું. ફંડિંગ કરવા માટે કે શોધવા માટે કોઈ બીજું એકાઉન્ટ નહોતું. મલ્ટી-એકાઉન્ટ Metaplex metadata સાથે અઠવાડિયા સુધી કામ કર્યા પછી, આ સરળતા લગભગ આશ્ચર્યજનક હતી.

ડેટાબેઝ રો (Rows) ની જેમ કલેક્શન બનાવવું

કલેક્શન એ આગામી તાર્કિક પગલું હતું. જૂના મોડેલમાં, NFTs ને ગ્રુપ કરવા માટે સામાન્ય રીતે Metaplex Certified Collections અથવા off-chain રજિસ્ટ્રીઝ પર આધાર રાખવો પડતો હતો. Token Extensions બે ચોક્કસ પ્રિમીટિવ્સ (primitives) રજૂ કરે છે: Group extension અને Member extension.

લોજિક આ રીતે કામ કરે છે. તમે એક સિંગલ mint બનાવો છો જે કલેક્શન હેડર તરીકે કામ કરે છે અને તેના પર Group extension સક્ષમ કરો છો. પછી, કલેક્શનમાં રહેલા દરેક વ્યક્તિગત NFT માટે, તમે Member extension સક્ષમ કરીને એક mint બનાવો છો. દરેક મેમ્બર mint કલેક્શન mint એડ્રેસ તરફનો પોઇન્ટર સ્ટોર કરે છે. આ સંબંધ રિલેશનલ ડેટાબેઝમાં ફોરેન કી (foreign key) ની જેમ જ કામ કરે છે. કલેક્શન રો એક જ વાર અસ્તિત્વમાં હોય છે, અને દરેક મેમ્બર રો કલેક્શનની ઓળખનું ડુપ્લીકેટ કર્યા વગર તેને રેફરન્સ કરે છે.

મેં devnet પર આ રીતે એક નાનું ટેસ્ટ કલેક્શન બનાવ્યું. મુખ્ય કલેક્શન mint માં group flag હતો. વ્યક્તિગત ટોકન્સમાં member flag હતો અને તે પેરેન્ટ એડ્રેસને રેફરન્સ કરતા હતા. ચેઇન પર ક્વેરી કરવાથી મને એક સ્વચ્છ, ટ્રેવર્સિબલ (traversable) સ્ટ્રક્ચર મળ્યું. ટોકન્સ સાથે જોડાયેલા છે કે નહીં તે અનુમાન લગાવવા માટે કોઈ થર્ડ-પાર્ટી ઇન્ડેક્સરની જરૂર નહોતી. આ સંબંધ સ્પષ્ટ અને on-chain છે.

ઓપન સ્કીમા અને ઓન-ચેન પ્રયોગો

એક વિગત જે અલગ તરી આવે છે તે મેટાડેટા એક્સટેન્શનનું ઓપન સ્કીમા છે. જૂના ધોરણો ઘણીવાર નિશ્ચિત ફિલ્ડ લિસ્ટ લાદે છે. જો તમે ઓન-ચેન પર કંઈક નોન-સ્ટાન્ડર્ડ સ્ટોર કરવા માંગતા હોવ, તો તમારે તેને ઓફ-ચેન JSON માં મૂકવું પડતું અથવા કડક એકાઉન્ટ લેઆઉટમાં ફેરફાર કરવા પડતા.

Token Extensions એક અલગ અભિગમ અપનાવે છે. કારણ કે મેટાડેટા એક્સટેન્શન કસ્ટમ ફિલ્ડ્સ સ્વીકારે છે, હું સીધું જ મિન્ટ એકાઉન્ટમાં રેરિટી એટ્રિબ્યુટ ઉમેરી શક્યો. મેં ફિલ્ડ લખ્યું, ટ્રાન્ઝેક્શન મોકલ્યું અને Solana Explorer રિફ્રેશ કર્યું. નામ અને સિમ્બોલની સાથે રેરિટી વેલ્યુ તરત જ દેખાઈ ગઈ. ગેમ ડેવલપર્સ અથવા ડાયનેમિક એસેટ્સ બનાવતા કોઈપણ વ્યક્તિ માટે, આ લવચીકતા મહત્વની છે. તમે JSON પાર્સ કરવા માટે કોઈ એક્સટર્નલ વેરિફાયરની જરૂરિયાત વિના ઓન-ચેન પર મહત્વપૂર્ણ લક્ષણો દર્શાવી શકો છો.

ઓફ-ચેન ગેપ: URIs અને કેશિંગ

ઓન-ચેન સ્ટોરેજની તમામ સુંદરતા છતાં, એક પાઠ સ્પષ્ટ રીતે સમજાયો: ઓળખ હજુ પણ ઓફ-ચેન રહે છે. મિન્ટ તમારી ઈમેજ સ્ટોર કરતું નથી. તે એક URI સ્ટોર કરે છે. જ્યારે મેં તે URI અપડેટ કર્યું અને devnet પર ફેરફાર કમિટ કર્યો, ત્યારે ચેઈને તરત જ નવો પોઇન્ટર દર્શાવ્યો. બ્લોક એક્સપ્લોરર્સમાં કોઈ વિલંબ વિના અપડેટ કરેલી લિંક દેખાઈ.

પરંતુ મારું વોલેટ લેગ (lag) થયું. ઓન-ચેન પરનો મૂળ ડેટા બદલાઈ ગયો હોવા છતાં, તે મિનિટો સુધી જૂની ઈમેજ બતાવતું રહ્યું અને જીદપૂર્વક કેશ્ડ (cached) વર્ઝન સર્વ કરતું રહ્યું. આ એક વ્યવહારિક વાસ્તવિકતા છે જેના માટે ડેવલપર્સે આયોજન કરવું જોઈએ. Solana લેજર ઝડપી છે. કન્ફર્મેશન સમય ઓછો છે. તેમ છતાં, વપરાશકર્તાઓ જે વિઝ્યુઅલ લેયર સાથે સંપર્ક કરે છે તે HTTP કેશ, CDN પ્રોપેગેશન અને વોલેટ-વિશિષ્ટ રિફ્રેશ ઇન્ટરવલ પર આધારિત છે. જો તમે વાસ્તવિક દુનિયાની ઘટનાઓના આધારે બદલાતું ડાયનેમિક NFT બનાવો છો, તો તમે એવું માની શકતા નથી કે ટ્રાન્ઝેક્શન થતાની સાથે જ વપરાશકર્તા ફેરફાર જોઈ લેશે. તમારે કેશ-બસ્ટિંગ વ્યૂહરચનાઓ, તમારા URI પાથમાં વર્ઝનિંગ અથવા તમારા ફ્રન્ટએન્ડમાં સ્પષ્ટ રિફ્રેશ ટ્રિગર્સની જરૂર પડશે.

આગળ શું આવશે

મારા devnet પ્રયોગોએ વધુ ડાયનેમિક પ્રોજેક્ટ માટે પાયો નાખ્યો છે. આગલું પગલું એક કલેક્શન