கடந்த வாரம் .night டொமைன்கள் (domains) உண்மையில் எவ்வாறு செயல்படுகின்றன என்பதைப் புரிந்துகொள்ள முயற்சி செய்தேன். ஒரு விவரக்குறிப்புத் தாளைப் (spec sheet) பார்த்து அல்ல, நேரடியாக செயினுடன் (chain) தொடர்பு கொள்ளும் ஒன்றை உருவாக்குவதன் மூலம். அதன் முடிவு ஒரு சிறிய ப்ரொபைல் வியூவர் (profile viewer). நீங்கள் tomin.night போன்ற ஒரு பெயரைத் தட்டச்சு செய்தால், அது பிளாக்செயினிலிருந்து நேரடியாக அந்தப் ப்ரொஃபைலைத் தீர்மானிக்கும் (resolves). எந்த பதிவாளர் API-யும் இல்லை. எந்த அங்கீகாரத் தடையும் (auth wall) இல்லை. ஒரு ஸ்மார்ட் கான்ட்ராக்ட் மற்றும் சில JavaScript மட்டுமே உள்ளன.
அடுத்து இது எவ்வாறு செயல்படுகிறது, நான் என்ன கற்றுக்கொண்டேன் மற்றும் எனது ஒரு மதிய நேரத்தை வீணடித்த அந்த இரண்டு குறிப்பிட்ட சிக்கல்கள் என்ன என்பது பற்றிய விவரங்கள்.
ஆன்-செயின் (On-Chain) பெயர்கள் ஏன் முக்கியம்
Midnight-இல், .night டொமைன்கள் Midnames மூலம் நிர்வகிக்கப்படுகின்றன. ஒரு நிறுவனத்தின் மையத் சேவையகத்தை (central server) அணுகுவதற்குப் பதிலாக, செயினில் உள்ள ஒரு ஸ்மார்ட் கான்ட்ராக்ட்டிலிருந்து நீங்கள் நேரடியாகப் படிக்கலாம். அந்தப் பதிவேடு (registry) டொமைன், அதன் உரிமையாளர் மற்றும் உரிமையாளர் இணைத்துள்ள ப்ரொபைல் புலங்கள் (profile fields) அனைத்தையும் வைத்திருக்கும். அந்தத் தரவு ஆன்-செயினில் இருப்பதால், அடையாளம் (identity) எளிதில் மாற்றத்தக்கது (portable). நிபந்தனைகளை மாற்றக்கூடிய அல்லது சேவையை நிறுத்தக்கூடிய ஒரு தளத்திலிருந்து நீங்கள் அதை வாடகைக்கு எடுக்கவில்லை. உங்களிடம் சாவிகள் (keys) இருந்தால், அந்தப் பெயரும் உங்களுடையது.
இந்த மாற்றம் டெவலப்பர்களுக்கும் முக்கியமானது. நீங்கள் ஒரு பாரம்பரிய DNS அமைப்பைக் கொண்டு உருவாக்கும்போது, ரேட் லிமிட்கள் (rate limits), API சாவிகள் மற்றும் இயங்கும் நேரம் (uptime) குறித்த வாக்குறுதிகளுடன் போராட வேண்டியிருக்கும். இங்கே, கான்ட்ராக்ட் நிலை (contract state) தான் உண்மையான ஆதாரம் (source of truth). உங்கள் பயன்பாடு (application) மற்ற அனைத்து பயன்பாடுகளையும் போலவே இதைப் படிக்கிறது. இங்கே எந்த முன்னுரிமை பெற்ற API அடுக்குத் தேவையில்லை.
குறியீடு (Code) மிகவும் எளிமையானது
@midnames/sdk கடினமான வேலைகளைச் செய்கிறது. ஒரு டொமைனை ஒரு முகவரி மற்றும் ப்ரொஃபைலாகத் தீர்மானிக்க சரியாக இரண்டு வரிகள் போதும்:
const provider = createDefaultProvider({ networkId: "mainnet" });
const result = await resolveDomain(provider, "tomin.night");
அவ்வளவுதான். ப்ரொவைடர் (provider) நெட்வொர்க்கை இலக்கு வைக்கிறது, மேலும் ரெசல்வர் (resolver) கான்ட்ராக்ட்டுடன் பேசுகிறது. SDK ஒரு வெற்றிக் கொடியுடன் (success flag) கூடிய முடிவுப் பொருளைத் (result object) திருப்பித் தருகிறது. டொமைன் இல்லை என்றால், RPC தோல்விகளுக்காக நீங்கள் பல அடுக்கு பிழை கையாளுதல்களை (error handling) அல்லது try-catch பிளாக்குகளை உருவாக்கத் தேவையில்லை. அங்கு எதுவும் இல்லை என்பதை SDK தெளிவாகத் தெரிவித்துவிடும். இது UI-களை உருவாக்குவதை வியக்கத்தக்க வகையில் எளிதாக்குகிறது. தோல்வி என்பது பெயர் இல்லாததா அல்லது நோட் (node) செயலிழந்ததா என்று யூகிக்காமல், வெற்றிக் கொடியைப் பயன்படுத்தி “not found” என்ற நிலையை நீங்கள் காட்ட முடியும்.
உங்களுக்கு என்ன கிடைக்கும்
தேடல் (lookup) வெற்றி பெறும்போது, அதில் முக்கியமான இரண்டு பகுதிகள் இருக்கும்.
Target என்பது டொமைன் எந்த வாலட் முகவரியைக் குறிக்கிறதோ அதுவாகும். இதுதான் இதன் முக்கியப் பயன்பாடு. இது ஒரு நீண்ட ஹெக்ஸ் முகவரியை (hex address) மனிதர்கள் படிக்கக்கூடிய, தட்டச்சு செய்யக்கூடிய மற்றும் நினைவில் கொள்ளக்கூடிய ஒன்றாக மாற்றுகிறது.
Fields ப்ரொஃபைல் விவரங்களைக் கொண்டுள்ளது. உரிமையாளர் டொமைனுடன் இணைத்துள்ள சமூக வலைதள இணைப்புகள், அவதாரங்கள், உரை பதிவுகள் எதுவாக இருந்தாலும், அவை இந்த அமைப்பிற்குள் இருக்கும். இந்தத் தரவுகள் ஏதேனும் ஒரு நிறுவனத்தின் MongoDB கிளஸ்டரில் சேமிக்கப்படுவதில்லை. அவை கான்ட்ராக்ட் நிலையில் உள்ள புலங்கள், அதாவது பதிவேட்டை எவ்வாறு படிக்க வேண்டும் என்று தெரிந்த எந்தவொரு பயன்பாடும் அதே ப்ரொஃபைலைத் திரையில் காட்ட முடியும். தரவுத்தள ஒத்திசைவு (database sync) தேவையில்லை.
எனது வேகத்தைக் குறைத்த இரண்டு சிக்கல்கள்
இந்தக் கட்டுமானத்தில் அனைத்தும் இரண்டு வரிகள் மற்றும் ஒரு வெற்றிக் கொடி போல எளிதாக இருக்கவில்லை. நீங்கள் மீண்டும் அதே தவறு செய்யாமல் இருக்க, நான் சந்தித்த இரண்டு குறிப்பிட்ட தடைகளை இங்கே விளக்குகிறேன்.
நெட்வொர்க் முரண்பாடு (Network Mismatch)
SDK ஆனது mainnet மற்றும் preprod ஆகிய இரண்டு சூழல்களையும் ஆதரிக்கிறது. “டொமைன் இல்லை” என்று காட்டும் ஒரு டொமைனைச் சரிசெய்ய நான் கணிசமான நேரத்தைச் செலவிட்டேன். பெயர் சரியாக இருந்தது. குறியீடு சரியாக இருந்தது. ப்ரொவைடர் இயங்கிக் கொண்டிருந்தது. பிரச்சனை என்னவென்றால், எனது ஸ்கிரிப்ட் preprod-இல் தேடிக்கொண்டிருந்தது, ஆனால் டொமைன் உண்மையில் mainnet-இல் பதிவு செய்யப்பட்டிருந்தது. பிழை என்பது டொமைன் இல்லாதது போலத் தோன்றியது, ஆனால் உண்மையில் அது நெட்வொர்க் சூழல் (network context) இல்லாததுதான்.
நீங்கள் ஒரு பெயரைத் தேடும்போது தோல்வி கிடைத்தால், வேறு எதையும் சரிசெய்வதற்கு முன் ப்ரொவைடர் அமைப்புகளைச் சரிபார்க்கவும். உங்கள் networkId, டொமைன் உண்மையில் எந்த நெட்வொர்க்கில் உருவாக்கப்பட்டுள்ளதோ (minted) அதனுடன் ஒத்துப்போவதை உறுதி செய்யவும். கான்ட்ராக்ட் லாஜிக் தான் பிரச்சனை என்று நீங்கள் நினைக்கும் போது, இது கண்டறிவதற்கு மிகவும் கடினமாகத் தோன்றும், ஆனால் பின்னோக்கிப் பார்க்கும்போது இது மிகவும் எளிமையான தவறு.
சீரியலைசேஷன் சிரமம் (Serialization Pain)
SDK-லிருந்து வரும் தரவு நிலையான JavaScript அல்ல. அதில் BigInt மதிப்புகள் மற்றும் Map பொருள்கள் உள்ளன. அதை அப்படியே உலாவியில் (browser) அனுப்ப JSON.stringify-இல் பயன்படுத்த முயன்றால், அது பிழையை ஏற்படுத்தும் அல்லது தரவைச் silent-ஆகத் தொலைத்துவிடும். BigInt-க்கு நேரடி JSON பிரதிநிதித்துவம் இல்லை, மேலும் Map சாதாரணப் பொருட்களைப் போலச் சீரியலைஸ் (serialize) செய்யாது.
இறுதியில் நான் ஒரு தனிப்பயன் சீரியலைசரை (custom serializer) எழுத வேண்டியதாயிற்று. இது முடிவுப் பொருளைச் சுலபமாகச் சென்று, BigInt மதிப்புகளை சரங்களாக (strings) மாற்றுகிறது, மேலும் பதில் சர்வரை விட்டு வெளியேறுவதற்கு முன் Map இன்ஸ்டன்ஸ்களை சாதாரணப் பொருட்களாக மாற்றுகிறது. நீங்கள் Midnight தரவை ஒரு பிரண்ட்எண்டிற்கு (frontend) வழங்கும் API-ஐ உருவாக்குகிறீர்கள் என்றால், இந்தத் திட்டத்தை முன்கூட்டியே வகுத்துக் கொள்ளுங்கள். SDK வெளியீடு JavaScript என்பதால் அது உடனடியாக பிரண்ட்எண்டிற்குப் பயன்படும் என்று assumptions வைத்துவிடாதீர்கள்.
கட்டமைப்பு (Architecture)
நான் இந்தத் தொழில்நுட்பத் தொகுப்பை (stack) வேண்டுமென்றே எளிமையாக வைத்திருந்தேன். இதன் பின்னணி (backend) Express இயங்கும் ஒரு Node சேவையகம் ஆகும். இது @midnames/sdk-ஐ இறக்குமதி செய்து, தீர்மானிக்கும் தர்க்கத்தை (resolution logic) இயக்கி, தரவு வரிசைப்படுத்தல் (serialization) சிக்கல்களைக் கையாண்டு, தெளிவான JSON தரவை வழங்குகிறது. இதன் முன்முனை (frontend) சாதாரண HTML மற்றும் vanilla JavaScript ஆகும். இதில் எந்த build step-உம் இல்லை, எந்த framework-உம் இல்லை, மற்றும் எந்த wallet adapter-உம் இல்லை.
சில நடைமுறை காரணங்களுக்காக, SDK-வை உலாவியில் (browser) இயக்குவதற்குப் பதிலாக பின்னணியில் (backend) இயக்கத் தேர்ந்தெடுத்தேன். இது provider அமைப்புகளை (configuration) கிளையண்டிற்கு வெளியே வைக்க உதவுகிறது, serialization சிக்கல்களைச் சரிசெய்ய ஒரே இடத்தைத் தருகிறது, மேலும் முன்முனை (frontend) தரவைப் பெற்று அதைத் திரையிட (render) மட்டுமே போதுமானதாக இருப்பதை உறுதி செய்கிறது.
என்னை மிகவும் ஆச்சரியப்படுத்திய விஷயம் இதுதான்: ஒரு பெயரைத் தீர்மானிப்பது (resolving a name) என்பது ஒரு பொதுவான வாசிப்புச் செயலாகும் (public read operation). இதற்கு wallet இணைப்பு தேவையில்லை. கையொப்பம் (signature) தேவையில்லை. பயனர் எதைக் கொண்டு உள்நுழையவும் (log in) தேவையில்லை. டொமைன் இருந்தால், ஒப்பந்த நிலை (contract state) கேட்பவர்களுக்குத் தெரியும். ஒவ்வொரு தொடர்பும் “connect wallet” என்பதிலிருந்து தொடங்கும் வழக்கமான web3 முறையிலிருந்து இது ஒரு குறிப்பிடத்தக்க வேறுபாடாகும். ஒரு பொது இணையதளத்தைப் படிப்பது எப்படி அனுமதி இல்லாமலோ (permissionless) செய்ய முடியுமோ, அதேபோல Midnight-இல் அடையாளத்தைப் படிப்பதுவும் அனுமதி இல்லாமலேயே செய்ய முடியும்.
உண்மையான பாடம்
இந்த வியூவரை (viewer) உருவாக்கியது, பிளாக்செயின் மேம்பாட்டில் (blockchain development) கடினமான பகுதி அரிதாகவே பிளாக்செயின் தானாகும் என்பதை எனக்கு நினைவூட்டியது. Midnight ஏற்கனவே கடினமான சிக்கலைத் தீர்த்துவிட்டது: ஒரு மையத் தரவுத்தளம் (central database) இல்லாமல் மக்கள் தங்கள் பெயர் மற்றும் சுயவிவரத்தை (profile) சொந்தமாக வைத்திருக்க அனுமதிப்பது. ஒரு உருவாக்குநரின் (builder) பார்வையில், கடினமான பகுதி நான் எந்த நெட்வொர்க்கைக் குறிப்பிடுகிறேன் என்பதை நினைவில் வைத்துக்கொள்வதும், தரவு வகைகளைச் (data types) சீரமைக்க ஒரு உதவியாளர் செயல்பாட்டை (helper function) எழுதுவதும் ஆகும்.
இந்த நெறிமுறை (protocol) உங்களுக்கு இடமாற்றத்தக்க அடையாளத்தை (portable identity) வழங்குகிறது. ஒரு டெவலப்பராக உங்கள் வேலை அதைச் சரியாகப் படிப்பது மற்றும் பயனருக்கு இடையூறு இல்லாமல் இருப்பது மட்டுமே. கட்டமைப்பை (architecture) எளிமையாக வைத்திருங்கள், சங்கிலித் தொடர் சார்ந்த தர்க்கத்தை (chain-facing logic) UI-லிருந்து பிரித்து வையுங்கள், மேலும் பொதுவான வாசிப்புகளை (public reads) அவை என்னவோ அவ்வாறே கருதுங்கள்: ஒரு பரவலாக்கப்பட்ட பதிவேட்டில் (distributed ledger) இருக்கும் சாதாரண தரவுத்தள வினவல்கள் (database queries) மட்டுமே அவை.
நீங்கள் குறியீட்டைப் பார்க்க விரும்பினால் அல்லது அதை நீங்களே இயக்க விரும்பினால், முழு மூலக் குறியீடும் (full source) https://github.com/tomiin/midnames-profile-viewer என்ற முகவரியில் கிடைக்கிறது.