சூழல் மாற்றம் (Context switching) வேகத்தைக் குறைக்கிறது. ஒரு AI உதவியாளர் திட்டத்தின் நடுவே வெளியேறும்போது, அடுத்த அமர்வு (session) எந்தத் தகவலும் இன்றித் தொடங்குகிறது. களஞ்சியக் கட்டமைப்பைப் (repository structure) பற்றிய நினைவிருக்காது. எந்த போர்ட்கள் (ports) செயல்பாட்டில் உள்ளன என்பது தெரியாது. நேற்று Monero RPC சரியாகச் செயல்படவில்லை என்பது தெரியாது. Daniel Ioni ஒரு நேரடியான மற்றும் பயனுள்ள ஒன்றை உருவாக்கினார்: AI அமைப்புகளுக்காகவே பிரத்யேகமாக எழுதப்பட்ட ஒரு தொழில்நுட்ப வழிகாட்டி, இதன் மூலம் அவை MyZubster Gateway பணிகளை எவ்வித உதவியுமின்றித் தொடர முடியும். இது ஒரு நிலையான செயற்கை நினைவகமாக (persistent synthetic memory) செயல்படுகிறது. வெறும் மூலக் குறியீட்டை (raw source code) மட்டும் வழங்காமல், அமைப்பை எவ்வாறு இயக்குவது, தோல்விகளைக் கண்டறிந்து சரிசெய்வது (troubleshoot), மற்றும் அழிவுகரமான மாற்றங்களைச் செய்வதற்கு முன் இயக்குபவரின் அதிகாரத்தை எவ்வாறு மதிப்பது என்பதைக் கற்றுக்கொடுக்கிறது.
MyZubster உண்மையில் எதை உருவாக்குகிறது
MyZubster Gateway என்பது நிஜ உலக சொத்துக்களின் டோக்கனாக்கலை (real-world asset tokenization) அடிப்படையாகக் கொண்ட ஒரு பரவலாக்கப்பட்ட சந்தை (decentralized marketplace) ஆகும். எளிமையாகச் சொன்னால், இது இயற்பியல் அல்லது பாரம்பரிய சொத்துக்களை வரையறுக்கப்பட்ட மெட்டாடேட்டா (metadata) மற்றும் உரிமையாளர் விதிகளுடன் ஆன்-செயினில் (on-chain) நகர்த்த அனுமதிக்கும் ஒரு உள்கட்டமைப்பு ஆகும். இந்தத் தளம் fungible asset tokenization-ஐக் கையாள்கிறது, அதாவது சொத்துக்களைப் பிரிக்கவும், வர்த்தகம் செய்யவும் மற்றும் ஒவ்வொரு அலகிற்கும் இணைக்கப்பட்ட தரப்படுத்தப்பட்ட மெட்டாடேட்டாவைப் பயன்படுத்தி அவற்றைக் கண்காணிக்கவும் முடியும்.
வடிவமைப்பின் மையப்பகுதியில் தனியுரிமை (Privacy) உள்ளது. பரிவர்த்தனைகள் Monero-வில் முடிவடைகின்றன. Programmable assets மற்றும் NFTs ஆகியவை Tari-இல் இயங்குகின்றன. ஒட்டுமொத்தச் செயல்பாடும் ஒரு Tor Onion Service மூலம் பாதுகாக்கப்படுகிறது, இது கேட்வேயை தணிக்கை (censorship) மற்றும் புவியியல் ரீதியானத் தடைகளிலிருந்து (geographic blocking) பாதுகாக்கிறது. ஒரு பாதுகாப்பு அடுக்கு Kali Linux-இல் இயங்குகிறது மற்றும் DeepSeek AI பாதுகாப்பு பாட்களைப் (security bots) பயன்படுத்துகிறது; இது வெறும் லாக் சுழற்சிக்கு (log rotation) பதிலாக, தானியங்கி ஊடுருவல் கண்டறிதல் (automated intrusion detection) அல்லது அசாதாரண ஸ்கேனிங் (anomaly scanning) செய்வதைக் குறிக்கிறது. எஸ்க்ரோ (Escrow) மற்றும் தகராறு தீர்வு (dispute resolution) ஆகியவை கைமுறையாகச் செய்யப்படும் அலுவலகப் பணிகள் அல்ல. வர்த்தக நிபந்தனைகள் மோதலைத் தூண்டும்போது AI தலையிட்டுத் தீர்த்து வைக்கும் வகையில் இவை தானியக்கமாக்கப்பட்டுள்ளன.
இது மேலோட்டமான பார்வை மட்டுமே. இதன் அடியில், RPC எண்ட்பாயிண்ட்கள் (endpoints), உள்ளூர் தரவுத்தளங்கள் (local databases) மற்றும் Node.js செயல்முறைகளின் (processes) வலைப்பின்னல் உள்ளது; இவை ஒருங்கிணைந்து (synchronized) இல்லையெனில் சந்தை வர்த்தகங்களைச் சரிசெய்வதை நிறுத்திவிடும்.
தொழில்நுட்ப அடுக்கு (Technical Stack) மற்றும் அதன் முக்கியத்துவம்
கேட்வே போர்ட் 3002-இல் இயங்குகிறது. அதுதான் நுழைவாயில். Monero-வின் Wallet RPC localhost:18083-இல் உள்ளது, இது பயனர் தரவை பொதுச் சங்கிலி பகுப்பாய்விற்கு (public chain analytics) வெளிப்படுத்தாமல், தனிப்பட்ட வாலட் செயல்பாடுகள், இருப்பு வினவல்கள் (balance queries) மற்றும் வெளிச்செல்லும் பரிமாற்றங்களைக் கையாள்கிறது. Tari-இன் RPC localhost:12820-இல் பதிலளிக்கிறது, இது programmable asset அடுக்கை நிர்வகிக்கிறது. இந்த எண்ட்பாயிண்ட்களில் ஏதேனும் ஒன்று விலகினாலோ அல்லது செயலிழந்தாலோ, சந்தை இயக்கம் முற்றிலும் நின்றுவிடும்.
MongoDB பின்னணியில் செயல்பாட்டுத் தரவுச் சேமிப்பகமாக (operational data store) உள்ளது. Node.js கேட்வே சேவையே இயங்குகிறது. Frontend குறியீடு ~/myzubster-frontend என்ற பிரத்யேகக் கோப்பகத்தில் உள்ளது. இது ஒரு பாரம்பரிய பரவலாக்கப்பட்ட அடுக்கு (decentralized stack): தீர்வு காண blockchain nodes, நிலையைச் சேமிக்க ஒரு உள்ளூர் தரவுத்தளம் மற்றும் தொடர்புகொள்ள ஒரு மெல்லிய வலை அடுக்கு (thin web layer), இவை அனைத்தும் தனியுரிமை கருவிகளால் சூழப்பட்டுள்ளன. இதில் எதுவும் அலங்காரத்திற்காகச் செய்யப்படவில்லை. அமைப்பைத் தன்னிறைவாகவும் (self-contained) பாதுகாப்பிற்குரியதாகவும் வைத்திருக்க ஒவ்வொரு போர்ட்டும் பாதையும் தேர்ந்தெடுக்கப்பட்டுள்ளன.
அமைப்பை இயக்குதல்
கேட்வேயைத் தொடங்குவதற்கு ஒரு systemd கட்டளை போதுமானது: systemctl start myzubster-gateway. கவனிக்கப்படாத ரீபூட் (reboot) செய்த பிறகு சேவை அமைதியுடன் செயலிழக்கும் வரை இது எளிதாகத் தோன்றலாம். அப்போது, தேவையற்ற தகவல்கள் இன்றி கடைசி ஐம்பது லாக் வரிகளைப் பெற journalctl -u myzubster-gateway -n 50 --no-pager தேவைப்படும். அந்த ஐம்பது வரிகளில்தான் பெரும்பாலும் விடை இருக்கும். ஒருவேளை Monero RPC இணைப்பை மறுத்திருக்கலாம் அல்லது சிஸ்டம் அப்டேட்டிற்குப் பிறகு MongoDB மீண்டும் ஆன்லைனுக்கு வந்திருக்காமல் இருக்கலாம்.
Security bot /root/security_bot.py-இல் உள்ளது மற்றும் python3 /root/security_bot.py மூலம் தொடங்கப்படுகிறது. ஒரு பாதுகாப்பு ஸ்கிரிப்டை root பயனராக இயக்குவது என்பது பொதுவான பயன்பாட்டுச் சேவையகத்தில் (general-purpose server) செய்யக்கூடிய ஒன்றல்ல. கண்காணிப்பு மற்றும் தானியங்கி பதிலளிப்பிற்காக அர்ப்பணிக்கப்பட்ட ஒரு வலுவூட்டப்பட்ட (hardened) Kali சூழலில், இது செயல்பாட்டு மாதிரியில் சரியாகப் பொருந்துகிறது. DeepSeek AI ஒருங்கிணைப்பு என்பது பாட் வெறும் லாக்ஸ்களை ஸ்கேன் செய்வதோடு மட்டும் நின்றுவிடவில்லை என்பதைக் குறிக்கிறது; இது நெட்வொர்க் நடத்தை அல்லது பரிவர்த்தனை முறைகளில் ஊடுருவல் அறிகுறிகளைக் கண்டறிய மதிப்பீடு செய்கிறது என்பதையும் இது உணர்த்துகிறது.
Frontend பணிகளுக்காக, இந்த வழிகாட்டி யூகங்களை முற்றிலும் நீக்குகிறது. AI சரியான இடத்தைத் துல்லியமாகத் தெரியும்: cd ~/myzubster-frontend. /var/www, /opt அல்லது சிதறிக்கிடக்கும் home கோப்பகங்களைத் தேட வேண்டிய அவசியம் இல்லை. இந்த வழிகாட்டி இந்தப் பாதைகளைத் துல்லியமாகத் தீர்மானிப்பதன் மூலம் ஒரு சீரான தன்மையை (consistency) உறுதி செய்கிறது; வாரக்கணக்கில் பல அமர்வுகள் அல்லது வெவ்வேறு AI இன்ஸ்டன்ஸ்கள் ஒரே சேவையகத்தைப் பயன்படுத்தும்போது இது மிகவும் முக்கியமானது.
ஏதேனும் சிக்கல்கள் ஏற்படும் போது
கேட்வே இயங்காமல் போகும்போது, முதலில் செய்ய வேண்டியது செயல்முறை ஆய்வு (process reconnaissance) ஆகும். Node.js செயல்முறை இன்னும் இயங்குகிறதா என்பதைப் பார்க்க ps aux | grep node என்பதை இயக்கவும். அது காணாமல் போயிருந்தால், லாக்ஸ்களைச் சரிபார்க்கவும். லாக்ஸ்களில் தரவுத்தள இணைப்புப் பிழை (database connection error) காட்டப்பட்டால், அதற்கு MongoDB தான் காரணம். அதை systemctl start mongod மூலம் மீண்டும் தொடங்கவும். பல பரவலாக்கப்பட்ட செயலிகள் blockchain nodes-களை மிகவும் பலவீனமான அங்கமாகக் கருதுகின்றன, ஆனால் நடைமுறையில், முறையற்ற ஷட்டவுன் (unclean shutdown) அல்லது வழக்கமான பேக்கேஜ் அப்டேட்டிற்குப் பிறகு உள்ளூர் MongoDB இன்ஸ்டன்ஸ் தான் பெரும்பாலும் முதலில் செயலிழக்கிறது.
Monero RPC சிக்கல்கள் ஒரு மாறுபட்ட முறையைப் பின்பற்றுகின்றன. இருப்புப் பட்டியல்கள் (balances) புதுப்பிக்கப்படுவதை நிறுத்தினால் அல்லது பணம் செலுத்தும் பரிவர்த்தனைகள் (payout transactions) நிலுவையில் (pending state) இருந்தால், monero-wallet-rpc நிலையைச் சரிபார்க்க வழிகாட்டி அறிவுறுத்துகிறது. இது பொதுவாக wallet RPC செயல்முறை இயங்குவதை உறுதிப்படுத்துவது, அது சரியான daemon உடன் இணைக்கப்பட்டுள்ளதா (synced) என்பதை உறுதிப்படுத்துவது மற்றும் authentication flags ஆகியவை gateway எதிர்பார்க்கும்வற்றுடன் ஒத்துப்போகின்றனவா என்பதைச் சரிபார்ப்பதைக் குறிக்கும். இங்கு சிக்கலைத் தீர்க்கும் முறை (Triage) எளிமையானது: முதலில் blockchain settlement layer, அடுத்து database, இறுதியாக application. இந்த வரிசையை நீங்கள் புறக்கணித்தால், உண்மையான தோல்வி ஒரு dead RPC port ஆக இருக்கும்போது, நீங்கள் Node.js logs-இல் தேவையற்றத் தேடல்களில் நேரத்தை வீணடிப்பீர்கள்.
AI இந்த கையேட்டை எவ்வாறு பயன்படுத்த வேண்டும்
இந்த வழிகாட்டி AI-க்கு நான்கு நடத்தை விதிகளை விதிக்கிறது, மேலும் தானியங்கி உதவியாளர்கள் (automated assistants) உற்பத்திச் சூழல்களில் (production environments) எவ்வாறு தோல்வியடைகிறார்கள் என்பதைப் பற்றிய புரிதலை இவை வெளிப்படுத்துகின்றன.
முதலாவதாக, குறிப்பிட்ட பகுதிகளைக் குறிப்பிட வேண்டும். பயனர் ஒரு கட்டணத் தோல்வியைத் தீர்க்க முயலும்போது, எந்தப் பகுதி சிக்கலாக உள்ளது என்பதைப் பயனர் துல்லியமாகத் தெரிந்துகொள்ள, AI Monero RPC அல்லது escrow subsystem-ஐத் தெளிவாகக் குறிப்பிட வேண்டும். இரண்டாவதாக, துல்லியமான கட்டளைகளை (commands) வழங்க வேண்டும். flags-களைத் தழுவிச் சொல்லவோ அல்லது பாதைகளைக் (paths) guesswork செய்யவோ கூடாது. மூன்றாவதாக, அடுத்த தர்க்கரீதியான படியைப் பரிந்துரைக்க வேண்டும். திட்ட மீட்பு (Project recovery) என்பது ஒரு தொடர்ச்சியான வரிசை; port checks மற்றும் security bots ஆகியவற்றிற்கு இடையே சீரற்ற முறையில் தாவுவது நேரத்தை வீணாக்குவதோடு சிக்கலை மோசமாக்கவும் வாய்ப்புள்ளது. நான்காவதாக, சேவைகளை மீண்டும் தொடங்குவதற்கு (restarting services) அல்லது தரவை அழிப்பதற்கு (deleting data) முன் பயனரின் உறுதிப்படுத்தலைக் கேட்க வேண்டும். தன்னாட்சி (Autonomy) பயனுள்ளது, ஆனால் அது தவறுதலாக ஒரு wallet cache-ஐ அழிப்பதற்கோ அல்லது வர்த்தகம் நடந்து கொண்டிருக்கும்போது gateway-ஐ முடக்குவதற்கோ வழிவகுக்கக் கூடாது.
ஒரு வாழும் ஆவணம்
இந்த வழிகாட்டி பரிணாம வளர்ச்சியடைவதற்காகவே பிரத்யேகமாக வடிவமைக்கப்பட்டுள்ளது. MyZubster திட்டம் வளர வளர, AI இந்த ஆவணத்தைப் புதுப்பிக்கும். இது ஒரு feedback loop-ஐ உருவாக்குகிறது, அங்கு செயல்பாட்டு அனுபவம் (operational experience) நிறுவன நினைவகமாக (institutional memory) மாறுகிறது. ஒரு சிறிய குழுவிலோ அல்லது வெவ்வேறு நேர மண்டலங்கள் மற்றும் தூக்கச் சுழற்சிகளில் இயங்கும் தனிநபர் திட்டத்திலோ, இது வழக்கமாக மூத்த பொறியாளர்களின் மனதில் இருக்கும் தகவல்களுக்கு மாற்றாக அமைகிறது. ஒவ்வொரு முடங்கலிலும் (outage) இந்த ஆவணம் கற்றுக்கொள்கிறது.
உண்மையான பயன்
இது போன்ற AI திட்ட மீட்பு வழிகாட்டிகள் ஒரு குறிப்பிட்ட, கடினமான சிக்கலைத் தீர்க்கின்றன. இவை வெறும் ஆவணங்களுக்கும் (raw documentation) சூழல் சார்ந்த புரிதலுக்கும் (contextual understanding) இடையிலான இடைவெளியைக் குறைக்கின்றன. MyZubster-க்கு, இதன் பொருள் சந்தையானது (marketplace) சூழல் இழப்பு, ரீபூட்கள் (reboots) மற்றும் குழு மாற்றங்களைத் தாங்கி இயங்க முடியும் என்பதாகும். ஒவ்வொரு முறையும் ஒரு புதிய session தொடங்கும்போது, இயந்திரம் அந்த stack-ஐ மீண்டும் ஆரம்பத்திலிருந்து கற்க வேண்டிய அவசியமில்லை. அது கையேட்டைப் படிக்கவும், துல்லியமான கட்டளைகளைப் பின்பற்றவும், எப்போது நிறுத்திவிட்டு கேட்க வேண்டும் என்பதைத் தெரிந்து வைத்திருக்கவும் போதுமானது.
மூலம்: AI Technical Guide: MyZubster Project Recovery - Daniel Ioni
விருப்பத்தேர்வு கற்றல் சமூகம்: GyaanSetu AI on Telegram