Solana ನಲ್ಲಿ NFT ಅನ್ನು ನಿರ್ಮಿಸುವುದು ಎಂದರೆ Metaplex ನೊಂದಿಗೆ ಹೋರಾಡುವುದು ಎಂದು ನಾನು ಭಾವಿಸುತ್ತಿದ್ದೆ. ಪ್ರತಿಯೊಂದು ಟ್ಯುಟೋರಿಯಲ್ ಸೂಚಿಸುವ ಹಾದಿ ಇದೇ ಆಗಿತ್ತು: Candy Machine ಅನ್ನು ಪ್ರಾರಂಭಿಸುವುದು, metadata accounts ಅನ್ನು ನಿರ್ವಹಿಸುವುದು, ಮತ್ತು ಕೇವಲ ಒಂದು ಟೋಕನ್ಗೆ ಹೆಸರು ಮತ್ತು ಚಿತ್ರವನ್ನು ಜೋಡಿಸಲು ಪ್ರತ್ಯೇಕ ಪ್ರೋಗ್ರಾಂಗಳನ್ನು ನಿಭಾಯಿಸುವುದು. ಆ ಊಹೆಯು ಹಳೆಯದಾಗಿತ್ತು ಎಂಬುದು ಈಗ ತಿಳಿದುಬಂದಿದೆ. Token Extensions ಪ್ರೋಗ್ರಾಂ (ಇದನ್ನು Token-2022 ಎಂದೂ ಕರೆಯಲಾಗುತ್ತದೆ), ಆ ಸಂಕೀರ್ಣತೆಯನ್ನು ಮೆಂಟ್ (mint) ಒಳಗೇ ಕುಗ್ಗಿಸಿದೆ. ಈಗ ನೀವು metadata ಪ್ರೋಗ್ರಾಂ ಅನ್ನು ಮುಟ್ಟದೆಯೇ ಅಥವಾ ಹೆಚ್ಚುವರಿ accounts ಗೆ ಹಣ ತುಂಬದೆಯೇ ಸಂಪೂರ್ಣವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ NFT ಅನ್ನು ರಚಿಸಬಹುದು. ನೀವು ಕೆಲವು ಫ್ಲಾಗ್ಗಳನ್ನು (flags) ಬದಲಾಯಿಸಿ, ಮೆಂಟ್ ಅಕೌಂಟ್ಗೆ ನೇರವಾಗಿ ಡೇಟಾವನ್ನು ಬರೆದರೆ ಸಾಕು.
ಇದು Solana ನಲ್ಲಿ ಡಿಜಿಟಲ್ ಅಸೆಟ್ಗಳ ಬಗ್ಗೆ ಡೆವಲಪರ್ಗಳು ಹೇಗೆ ಯೋಚಿಸಬೇಕು ಎಂಬುದನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ. ಸಾಂಪ್ರದಾಯಿಕ ವೆಬ್ ಡೆವಲಪ್ಮೆಂಟ್ನಲ್ಲಿ, NFT ಎಂಬುದು ಒಂದು ವಿಭಿನ್ನ ಡೇಟಾ ಸ್ಟ್ರಕ್ಚರ್ನಂತೆ ಕಾಣುತ್ತದೆ, ಅಂದರೆ ಅದಕ್ಕೆ ತನ್ನದೇ ಆದ ಟೇಬಲ್ ಮತ್ತು ಸ್ಕೀಮಾ ಬೇಕಾಗುತ್ತದೆ. Solana ನಲ್ಲಿ, ವಾಸ್ತವವು ಹೆಚ್ಚು ಸರಳ ಮತ್ತು ಸುಂದರವಾಗಿದೆ. NFT ಎಂಬುದು ಬಾಹ್ಯ ಪ್ರೋಟೋಕಾಲ್ನಿಂದ ನಿರ್ವಹಿಸಲ್ಪಡುವ ವಿಶೇಷ ಆಬ್ಜೆಕ್ಟ್ ಅಲ್ಲ. ಇದು ಕೇವಲ ನಿಖರವಾಗಿ ಒಂದು ಸಪ್ಲೈ (supply) ಮತ್ತು ಸೊನ್ನೆ ಡೆಸಿಮಲ್ಸ್ (decimals) ಹೊಂದಿರುವಂತೆ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾದ ಮೆಂಟ್ ಅಕೌಂಟ್ ಆಗಿದೆ. ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಟೋಕನ್ ದೊಡ್ಡ ಸಪ್ಲೈ ಮತ್ತು ಬಹು ಡೆಸಿಮಲ್ಸ್ಗಳನ್ನು ಹೊಂದಿರುವುದರಿಂದ ನೀವು ಯುನಿಟ್ಗಳನ್ನು ವಿಂಗಡಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. NFT ಸಪ್ಲೈ ಅನ್ನು ಒಂದೇ ಒಂದು, ವಿಭಜಿಸಲಾಗದ ಯುನಿಟ್ಗೆ ಲಾಕ್ ಮಾಡುತ್ತದೆ. ಅದನ್ನು ವಿಶಿಷ್ಟವಾಗಿಸುವ ಎಲ್ಲವೂ ಆ ಕೋರ್ ಮೆಂಟ್ ಅಕೌಂಟ್ನೊಂದಿಗೆ ಇರುವ ಎಕ್ಸ್ಟೆನ್ಶನ್ಗಳಲ್ಲಿ (extensions) ಇರುತ್ತವೆ.
ಹಳೆಯ ವಿಧಾನ ಮತ್ತು ಹೊಸ ವಿಧಾನ
Token Extensions ಗಿಂತ ಮೊದಲು, ಮೆಂಟ್ ಗಾಗಿ SPL Token ಪ್ರೋಗ್ರಾಂ ಮತ್ತು metadata, collections ಹಾಗೂ ಕೆಲವೊಮ್ಮೆ off-chain indexing ಗಾಗಿ Metaplex ಅನ್ನು ಬಳಸಲಾಗುತ್ತಿತ್ತು. Metadata ಎಂಬುದು ನೀವು ಟ್ರ್ಯಾಕ್ ಮಾಡಬೇಕಾದ ಅಡ್ರೆಸ್ಗಳ ಮೂಲಕ ಲಿಂಕ್ ಮಾಡಲಾದ ಪ್ರತ್ಯೇಕ ಅಕೌಂಟ್ಗಳಲ್ಲಿ ಇರುತ್ತಿತ್ತು. ಇದು ಕೆಲಸ ಮಾಡುತ್ತಿತ್ತು, ಆದರೆ ಇದು ಹೆಚ್ಚಿನ ಸಂಕೀರ್ಣತೆಯನ್ನು ತರುತ್ತಿತ್ತು. ಹೆಚ್ಚು ಅಕೌಂಟ್ಗಳು ಎಂದರೆ ಹೆಚ್ಚು ಬಾಡಿಗೆ (rent), ಹೆಚ್ಚು ಸೈನಿಂಗ್ ಪಥಗಳು (signing paths) ಮತ್ತು ಒಂದು ಟೋಕನ್ನ ಸಂಪೂರ್ಣ ಚಿತ್ರಣವನ್ನು ಪಡೆಯಲು ಹೆಚ್ಚಿನ ಕ್ಲೈಂಟ್-ಸೈಡ್ ಲಾಜಿಕ್ ಬೇಕಾಗುತ್ತದೆ ಎಂದರ್ಥ.
Token Extensions ಆ ಎಲ್ಲಾ ಚದುರಿದ ವ್ಯವಸ್ಥೆಯನ್ನು ಮೆಂಟ್ನಲ್ಲೇ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಸೇರಿಸುವ ಮೂಲಕ ಬದಲಾಯಿಸುತ್ತದೆ. ಹೆಸರು, ಸಿಂಬಲ್ ಮತ್ತು off-chain ಮೀಡಿಯಾ ಪಾಯಿಂಟರ್ ಬೇಕೆ? metadata extension ಅನ್ನು ಎನೇಬಲ್ ಮಾಡಿ. ಟೋಕನ್ಗಳನ್ನು ಒಂದು ಕಲೆಕ್ಷನ್ನಲ್ಲಿ ಗುಂಪು ಮಾಡಬೇಕೆ? Group ಮತ್ತು Member extensions ಬಳಸಿ. ಮೆಂಟ್ ಈಗ ಏಕೈಕ ಮೂಲ ಸತ್ಯ (single source of truth) ಆಗುತ್ತದೆ. ರಿಲೇಶನಲ್ ಡೇಟಾಬೇಸ್ಗಳಿಗೆ ಅಭ್ಯಾಸವಿರುವ ಡೆವಲಪರ್ಗಳಿಗೆ, ಈ ಬದಲಾವಣೆಯು ಡಿಸ್ಟ್ರಿಬ್ಯೂಟೆಡ್ ಮೈಕ್ರೋಸರ್ವಿಸ್ ಆರ್ಕಿಟೆಕ್ಚರ್ನಿಂದ ಸುಸಜ್ಜಿತ ಫಾರೆನ್ ಕೀಗಳನ್ನು ಹೊಂದಿರುವ ನಾರ್ಮಲೈಸ್ಡ್ ಟೇಬಲ್ಗೆ ಮರಳಿದಂತೆ ಅನಿಸುತ್ತದೆ.
ಎಕ್ಸ್ಟೆನ್ಶನ್ ಆಧಾರಿತ NFT ನ ರಚನೆ
Token Extensions ಬಳಸಿ NFT ರಚಿಸಲು, ಈ ಚೈನ್ನಲ್ಲಿ ಒಂದು ಟೋಕನ್ ಅನ್ನು 'ನಾನ್-ಫಂಗಿಬಲ್' (non-fungible) ಆಗಿ ಮಾಡುವುದು ಯಾವುದು ಎಂಬುದನ್ನು ನಿಖರವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಅಗತ್ಯವಾಗಿದೆ. ಸಪ್ಲೈ (supply) ಒಂದಕ್ಕೆ ಸಮನಾಗಿರಬೇಕು. ಡೆಸಿಮಲ್ಸ್ (decimals) ಸೊನ್ನೆಗೆ ಸಮನಾಗಿರಬೇಕು. ಈ ಎರಡು ನಿರ್ಬಂಧಗಳು ಫ್ರ್ಯಾಕ್ಷನಲೈಸೇಶನ್ ಅನ್ನು (fractionalization) ತಡೆಯುತ್ತವೆ. ಈ ಪ್ಯಾರಾಮೀಟರ್ಗಳನ್ನು ಸೆಟ್ ಮಾಡಿದ ನಂತರ, ನೀವು ಮೆಂಟ್ ಅಕೌಂಟ್ನಲ್ಲಿ ನೇರವಾಗಿ ಹೆಚ್ಚುವರಿ ಫೀಲ್ಡ್ಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ಎಕ್ಸ್ಟೆನ್ಶನ್ಗಳನ್ನು ಎನೇಬಲ್ ಮಾಡಬಹುದು.
Metadata extension ಹೆಸರು, ಸಿಂಬಲ್ ಮತ್ತು URI ಅನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಆ URI ಒಂದು JSON ಫೈಲ್ ಅನ್ನು ಸೂಚಿಸುತ್ತದೆ, ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಡಿಸೆಂಟ್ರಲೈಸ್ಡ್ ಸ್ಟೋರೇಜ್ ಅಥವಾ ಸ್ಟ್ಯಾಂಡರ್ಡ್ ವೆಬ್ ಸರ್ವರ್ನಲ್ಲಿ ಇರುತ್ತದೆ ಮತ್ತು ಚಿತ್ರ, ಅಟ್ರಿಬ್ಯೂಟ್ಸ್ ಹಾಗೂ ಟ್ರೇಟ್ಸ್ಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ. ಇದನ್ನು ಹುಡುಕಲು ಅಥವಾ ಡಿಸೆರಿಯಲೈಸ್ ಮಾಡಲು ಯಾವುದೇ ಪ್ರತ್ಯೇಕ metadata ಅಕೌಂಟ್ ಇರುವುದಿಲ್ಲ. ಡೇಟಾ ಮೆಂಟ್ನಲ್ಲೇ ಇರುತ್ತದೆ, ಅಂದರೆ ಎಕ್ಸ್ಪ್ಲೋರರ್ಗಳು, ವ್ಯಾಲೆಟ್ಗಳು ಮತ್ತು ಕ್ಲೈಂಟ್ ಸಾಫ್ಟ್ವೇರ್ಗಳು ಕೇವಲ ಒಂದು ಅಕೌಂಟ್ ಅನ್ನು ಪರಿಶೀಲಿಸುವ ಮೂಲಕ ಟೋಕನ್ನ ಮೂಲ ಗುರುತನ್ನು ಓದಬಹುದು.
ನಾನು ಇದನ್ನು ನೇರವಾಗಿ devnet ನಲ್ಲಿ ಪರೀಕ್ಷಿಸಿದೆ. ನಾನು metadata extension ಎನೇಬಲ್ ಮಾಡಲಾದ ಹೊಸ ಮೆಂಟ್ ಅನ್ನು ರಚಿಸಿದೆ, ನಂತರ ಹೆಸರು ಮತ್ತು ಸಿಂಬಲ್ ಅನ್ನು ನೇರವಾಗಿ ಮೆಂಟ್ ಸ್ಟೇಟ್ಗೆ ಬರೆದೆ. ಟ್ರಾನ್ಸಾಕ್ಷನ್ ಯಶಸ್ವಿಯಾಯಿತು ಮತ್ತು ಅದರ ಫಲಿತಾಂಶವು ತಕ್ಷಣವೇ Solana Explorer ನಲ್ಲಿ ಕಾಣಿಸಿಕೊಂಡಿತು. ಹಣ ತುಂಬಲು ಅಥವಾ ಹುಡುಕಲು ಯಾವುದೇ ಎರಡನೇ ಅಕೌಂಟ್ ಇರಲಿಲ್ಲ. ವಾರಗಟ್ಟಲೆ ಮಲ್ಟಿ-ಅಕೌಂಟ್ Metaplex metadata ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಿದ ನಂತರ, ಈ ಸರಳತೆಯು ಅಚ್ಚರಿ ಮೂಡಿಸಿತು.
ಡೇಟಾಬೇಸ್ ರೋಗಳಂತೆ ಕಲೆಕ್ಷನ್ಗಳನ್ನು ನಿರ್ಮಿಸುವುದು
ಕಲೆಕ್ಷನ್ಗಳು ಮುಂದಿನ ತಾರ್ಕಿಕ ಹಂತವಾಗಿದ್ದವು. ಹಳೆಯ ಮಾದರಿಯಲ್ಲಿ, NFTಗಳನ್ನು ಗುಂಪು ಮಾಡುವುದು ಎಂದರೆ ಸಾಮಾನ್ಯವಾಗಿ Metaplex Certified Collections ಅಥವಾ off-chain registries ಮೇಲೆ ಅವಲಂಬಿತವಾಗುವುದು ಎಂದರ್ಥವಾಗಿತ್ತು. Token Extensions ಎರಡು ನಿರ್ದಿಷ್ಟ ಪ್ರಿಮಿಟಿವ್ಗಳನ್ನು (primitives) ಪರಿಚಯಿಸುತ್ತದೆ: Group extension ಮತ್ತು Member extension.
ಇದರ ಲಾಜಿಕ್ ಹೀಗಿದೆ: ನೀವು ಕಲೆಕ್ಷನ್ ಹೆಡರ್ ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಒಂದು ಸಿಂಗಲ್ ಮೆಂಟ್ ಅನ್ನು ರಚಿಸಿ ಅದರ ಮೇಲೆ Group extension ಅನ್ನು ಎನೇಬಲ್ ಮಾಡಬೇಕು. ನಂತರ, ಕಲೆಕ್ಷನ್ನಲ್ಲಿರುವ ಪ್ರತಿಯೊಂದು ವೈಯಕ್ತಿಕ NFT ಗಾಗಿ, Member extension ಎನೇಬಲ್ ಮಾಡಲಾದ ಮೆಂಟ್ ಅನ್ನು ರಚಿಸಬೇಕು. ಪ್ರತಿಯೊಂದು ಮಂಬರ್ ಮೆಂಟ್ ಕಲೆಕ್ಷನ್ ಮೆಂಟ್ ಅಡ್ರೆಸ್ಗೆ ಪಾಯಿಂಟರ್ ಅನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ. ಈ ಸಂಬಂಧವು ರಿಲೇಶನಲ್ ಡೇಟಾಬೇಸ್ನಲ್ಲಿನ ಫಾರೆನ್ ಕೀ (foreign key) ನಂತೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಕಲೆಕ್ಷನ್ ರೋ (row) ಒಂದೇ ಬಾರಿಗೆ ಇರುತ್ತದೆ ಮತ್ತು ಪ್ರತಿ ಮಂಬರ್ ರೋ ಕಲೆಕ್ಷನ್ ಗುರುತನ್ನು ಡ್ಯುಪ್ಲಿಕೇಟ್ ಮಾಡದೆ ಅದನ್ನು ಉಲ್ಲೇಖಿಸುತ್ತದೆ.
ನಾನು devnet ನಲ್ಲಿ ಈ ರೀತಿಯಾಗಿ ಒಂದು ಸಣ್ಣ ಟೆಸ್ಟ್ ಕಲೆಕ್ಷನ್ ಅನ್ನು ನಿರ್ಮಿಸಿದೆ. ಮುಖ್ಯ ಕಲೆಕ್ಷನ್ ಮೆಂಟ್ group flag ಅನ್ನು ಹೊಂದಿತ್ತು. ವೈಯಕ್ತಿಕ ಟೋಕನ್ಗಳು member flag ಅನ್ನು ಹೊಂದಿದ್ದವು ಮತ್ತು ಪೇರೆಂಟ್ ಅಡ್ರೆಸ್ ಅನ್ನು ಉಲ್ಲೇಖಿಸಿದ್ದವು. ಚೈನ್ ಅನ್ನು ಕ್ವೆರಿ ಮಾಡುವುದು ನನಗೆ ಒಂದು ಸ್ವಚ್ಛವಾದ, ಸುಲಭವಾಗಿ ಸಂಚರಿಸಬಹುದಾದ (traversable) ರಚನೆಯನ್ನು ನೀಡಿತು. ಟೋಕನ್ಗಳು ಒಟ್ಟಿಗೆ ಸೇರಿವೆಯೇ ಎಂದು ಊಹಿಸಲು ಯಾವುದೇ ಥರ್ಡ್-ಪಾರ್ಟಿ ಇಂಡೆಕ್ಸರ್ ಅಗತ್ಯವಿರಲಿಲ್ಲ. ಈ ಸಂಬಂಧವು ಸ್ಪಷ್ಟವಾಗಿದೆ ಮತ್ತು ಆನ್-ಚೈನ್ (on-chain) ಆಗಿದೆ.
Open Schema and On-Chain Experimentation
One detail that stands out is the open schema of the metadata extension. Older standards often enforce a fixed field list. If you wanted to store something non-standard on-chain, you were stuck putting it in off-chain JSON or hacking around rigid account layouts.
Token Extensions takes a different approach. Because the metadata extension accepts custom fields, I was able to add a rarity attribute directly to the mint account. I wrote the field, sent the transaction, and refreshed the Solana Explorer. The rarity value appeared instantly alongside the name and symbol. For game developers or anyone building dynamic assets, this flexibility matters. You can surface critical traits on-chain without needing an external verifier to parse JSON.
The Off-Chain Gap: URIs and Caching
For all the elegance of on-chain storage, one lesson cut through clearly: identity still lives off-chain. The mint does not store your image. It stores a URI. When I updated that URI and committed the change to devnet, the chain reflected the new pointer immediately. Block explorers showed the updated link without delay.
But my wallet lagged. It continued displaying the old image for minutes, stubbornly serving a cached version while the underlying data on-chain had already changed. This is a practical reality developers must plan for. The Solana ledger is fast. Confirmation times are short. Yet the visual layer that users interact with depends on HTTP caches, CDN propagation, and wallet-specific refresh intervals. If you build a dynamic NFT that changes based on real-world events, you cannot assume the user sees the change the moment the transaction lands. You need cache-busting strategies, versioning in your URI paths, or explicit refresh triggers in your frontend.
What Comes Next
My devnet experiments have laid the groundwork for a more dynamic project. The next step is a collection