ஒரு sandbox சூழலில் STON.fi டோக்கன் ஸ்வாப் (token swap) செயல்பாட்டைச் செய்து முடித்த டெவலப்பர்கள், குறியீட்டில் (code) சில சிறிய தவறுகளைத் தொடர்ந்தால், மெயின்நெட்டிற்கு (mainnet) மாறும்போது பயனர்களின் நிதியை இழக்க நேரிடும் என்று எச்சரிக்கப்படுகிறார்கள். ஒரு டெவலப்பர் பிளாக்கில் வெளியிடப்பட்ட சமூகத்தால் உருவாக்கப்பட்ட சரிபார்ப்புப் பட்டியல் (checklist), பெரும்பாலான ஒருங்கிணைப்புகள் (integrations) எங்கே தோல்வியடைகின்றன என்பதையும், தயாரிப்புத் தயார் நிலையில் (production-ready) வெற்றிகரமாகத் தொடங்குவதற்கான ஒரு தெளிவான வழிமுறைகளையும் விளக்குகிறது.
இந்த மாற்றம் ஏன் முக்கியமானது
TON பிளாக்செயினில் உள்ள பல DEX-களுக்கு இடையே திரவத்தன்மையை (liquidity) ஒருங்கிணைக்கும் ஒரு ரூட்டரை (router) STON.fi வழங்குகிறது. பயனர்களுக்கு ஒரே கிளிக்கில் ஸ்வாப் வசதியை வழங்க விரும்பும் திட்டங்கள், பொதுவாக ஒரு front-end அல்லது smart-contract wrapper மூலம் இந்த ரூட்டரை அழைக்கின்றன. ஒரு சோதனைச் சூழலில் (test environment), ரூட்டர் முகவரி நிலையானது (static), கட்டண அட்டவணை (fee schedule) முன்கூட்டியே அறியப்பட்டது, மேலும் sandbox தவறான பரிவர்த்தனைகளைத் தாங்கும். ஆனால், mainnet-இல், ரூட்டர் மேம்படுத்தப்படலாம் (upgraded), கட்டண அளவுருக்கள் (fee parameters) மாறலாம், மேலும் ஒரு தவறான முகவரி உண்மையான டோக்கன்களைச் செயல்படாத ஒரு ஒப்பந்தத்திற்கு (dead contract) அனுப்பிவிடும். எனவே, நிதி ரீதியான பாதிப்புகள், ஒரு சுமூகமான பயனர் அனுபவத்திற்கும், திட்டத்தின் நற்பெயரை ஒரே இரவில் பாதிக்கும் இழப்பிற்கும் இடையிலான வேறுபாடாக அமைகின்றன.
மிகவும் பொதுவான தவறு: மதிப்புகளை ஹார்ட்-கோடிங் (hard-coding) செய்தல்
தோல்வியடைந்த தொடக்கங்களில் மீண்டும் மீண்டும் காணப்படும் ஒரு முறை, சோதனைச் சமயத்தில் சரியாக இருந்த ரூட்டர் முகவரி அல்லது கட்டண மாறிலிகளை (fee constants) ஹார்ட்-கோடிங் (hard-coding) செய்வதாகும். STON.fi தனது ரூட்டரை மேம்படுத்தும்போது—செயல்திறனை மேம்படுத்த அல்லது பிழைகளைச் சரிசெய்ய இது ஒரு வழக்கமான நிகழ்வு—ஹார்ட்-கோட் செய்யப்பட்ட முகவரி இனிச் செயல்படும் ஒப்பந்தத்தைக் குறிக்காது. இந்த ஒருங்கிணைப்பு பயனர்களுக்குத் தெரியாத ஒரு பிழையைத் தூண்டலாம் அல்லது மோசமான நிலையில், நிதியைச் செயல்படுத்த முடியாத ஒரு முகவரிக்கு அமைதியாக (silently) அனுப்பிவிடும். சமூக வழிகாட்டி ஒரு விதியைப் வலியுறுத்துகிறது: எந்த ரூட்டரைப் பயன்படுத்த வேண்டும் என்பதை STON.fi REST API தீர்மானிக்கட்டும்.
படிப்படியான பாதுகாப்பு சரிபார்ப்புப் பட்டியல்
இந்தச் சரிபார்ப்புப் பட்டியல் இடப்பெயர்வுச் செயல்முறையை நான்கு தர்க்கரீதியான அடுக்குகளாகப் பிரிக்கிறது—சுற்றுச்சூழல் (environment), ஒப்பந்தத் தொடர்பு (contract interaction), கட்டணக் கணக்கீடு (fee calculation) மற்றும் விளிம்பு நிலை கையாளுதல் (edge-case handling).
சுற்றுச்சூழல் மாறிகளை (environment variables) முன்கூட்டியே சரிபார்க்கவும். சோதனைச் செய்யும் போது WebSocket endpoint மற்றும் REST API base URL ஆகியவற்றை sandbox-ஐ நோக்கி அமைக்கவும்; தொடங்குவதற்கு முன் அவற்றை mainnet nodes-க்கு மாற்றவும். இதில் ஏற்படும் ஒரு எழுத்துப் பிழை (typo), உண்மையான ஸ்வாப்பை சோதனை ரூட்டருக்குத் திருப்பி அனுப்பி, டோக்கன்களை நிரந்தரமாக முடக்கிவிடக்கூடும்.
ஒப்பந்த முகவரிகளை (contract addresses) ஒருபோதும் உட்பொதிக்க வேண்டாம். STON.fi API-க்கு ஒரு simulation கோரிக்கையை அனுப்பி, பதிலிலிருந்து தற்போதைய ரூட்டர் முகவரியைப் பெற்று, அதை runtime-இல் உங்கள்
dexFactory(அல்லது அதற்கு இணையான contract-factory) மூலம் பயன்படுத்தவும். இது எதிர்கால ரூட்டர் மேம்படுத்தல்களுக்குத் தானாகவே ஒத்துப்போகும்.கட்டணங்களை உடனுக்குடன் கணக்கிடுங்கள் (Compute fees on the fly). API-இன் configuration payload-லிருந்து கட்டண அளவுருக்களைப் பெற்று, அவற்றை உங்கள் fee-math முறையில் பயன்படுத்தவும். தளம் தனது பொருளாதார முறையை மாற்றிய அடுத்த கணமே, ஹார்ட்-கோட் செய்யப்பட்ட சதவீதங்கள் பயனற்றதாகிவிடும்.
அதிகாரப்பூர்வ SDK மற்றும் TonConnect-ஐப் பயன்படுத்தவும். SDK உங்களுக்காக BOC (Bag of Cells) கட்டமைப்புகளை உருவாக்குகிறது மற்றும் gas limits, தரவு குறியாக்கம் (data encoding) மற்றும் கையொப்பச் சரிபார்ப்பு (signature validation) ஆகியவற்றிற்கான சோதனைகளை உள்ளடக்கியது. SDKவால் கையாள முடியாத மிகவும் சிறப்பு வாய்ந்த பயன்பாட்டுத் தேவைகளுக்கு மட்டுமே கைமுறையாக BOC தொகுப்பைப் (manual BOC compilation) பயன்படுத்த வேண்டும்.
தோல்வி முறைகளைச் சோதிக்கவும் (failure-mode testing). sandbox-இல் out-of-gas சூழல்கள், போதுமான அனுமதி இல்லாமை (insufficient allowance) மற்றும் தவறான பதில்கள் (malformed replies) போன்றவற்றைச் செய்து பார்க்கவும். உங்கள் ஒப்பந்தம் பயனருக்குத் திரும்பப் பணத்தைத் தருகிறதா அல்லது தெளிவான பிழை நிகழ்வை (error event) வெளியிடுகிறதா என்பதைச் சரிபார்க்கவும். தயாரிப்புச் சூழலில் (production) பயனர்களைக் கொண்டு இந்த பிழைகளைக் கண்டறியச் சொல்வது பயனர்கள் வெளியேறுவதற்கு வழிவகுக்கும்.
பரிந்துரைத் திரும்பப் பெறுதல் பாதைகளை (referral withdrawal paths) உறுதிப்படுத்தவும். DEX-இன் இரண்டாவது பதிப்பில், பரிந்துரை கட்டணங்கள் (referral fees) ஒரு வாலட்டிற்குப் பதிலாக ஒரு பிரத்யேக Vault ஒப்பந்தத்திற்குச் செல்கின்றன. பரிந்துரைப்பவரின் கணக்கில் வரவு வைப்பதற்கு முன், உங்கள் ஒருங்கிணைப்பு Vault-இன் withdrawal முறையை அழைக்க வேண்டும் மற்றும் பெறப்பட்ட டோக்கன்களைக் கையாள வேண்டும்.
டெவலப்பர்கள் விவாதிப்பது என்ன
சில டெவலப்பர்கள் SDK தேவையற்ற கூடுதல் சுமையை (overhead) ஏற்படுத்துகிறது என்றும், கைமுறையாக உருவாக்கப்பட்ட BOC payload சிறியதாகவும் மற்றும் gas செலவில் குறைவாகவும் இருக்கும் என்றும் வாதிடுகின்றனர். வழிகாட்டி இந்தத் பார்வையை ஏற்றுக்கொண்டாலும், SDK ரூட்டர் முகவரி மற்றும் கட்டணத் திட்டத்திற்கான (fee schema) புதுப்பிப்புகளையும் உள்ளடக்கியுள்ளது என்பதையும் சுட்டிக்காட்டுகிறது. அதாவது, கைமுறையாக உருவாக்கப்பட்ட payload ஒவ்வொரு STON.fi மேம்படுத்தலுக்குப் பிறகும் மீண்டும் சரிபார்க்கப்பட வேண்டும். எனவே, இது மிகச்சிறிய அளவு gas சேமிப்பிற்கும், அமைதியான செயலிழப்பு அபாயத்திற்கும் (silent breakage) இடையிலான ஒரு சமநிலையாகும்.
அடுத்து கவனிக்க வேண்டியவை
- ரூட்டர் மேம்படுத்தல் அறிவிப்புகள். STON.fi தனது டெவலப்பர் சேனலில் வரவிருக்கும் ரூட்டர் மாற்றங்களைப் பதிவிடுகிறது. அந்தத் தகவல்களைப் பின்தொடர்வதன் மூலம், mainnet-க்கு மாறுவதற்கு முன் sandbox-இல் புதிய முகவரியை முன்கூட்டியே சோதிக்க முடியும்.
- கட்டண அளவுரு திருத்தங்கள். சந்தை நிலவரங்களுக்கு ஏற்ப கட்டண சதவீதங்கள் மாற்றப்படலாம் என்பதால், எந்தவொரு கண்காணிப்புச் சேவையிலும் (monitoring service) அவ்வப்போது configuration endpoint-லிருந்து தகவல்களைப் பெறும் வசதியைச் சேர்த்துக்கொள்ளுங்கள்.
- SDK பதிப்பு வெளியீடுகள். புதிய SDK வெளியீடுகள் பெரும்பாலும் mainnet தொடக்கத்திற்குப் பிறகு கண்டறியப்பட்ட விளிம்பு நிலை பிழைகளுக்கான (edge cases) திருத்தங்களை உள்ளடக்கியிருக்கும். ரூட்டர் முகவரியைப் புதுப்பிப்பது போலவே SDK-ஐப் புதுப்பித்த நிலையில் வைத்திருப்பதும் முக்கியமானது.
இதிலிருந்து நாம் அறியும் பாடம் தெளிவானது: "சோதனையில் (testing) சரியாகச் செயல்படும்" ஒரு ஸ்வாப் (swap), தானாகவே பாதுகாப்பான மெயின்நெட் (mainnet) அனுபவத்திற்கு வழிவகுத்துவிடாது. ரூட்டர் முகவரி (router address) முதல் கட்டண அட்டவணை (fee schedule) வரை ஒவ்வொரு முக்கியமான மதிப்பையும் நேரடி STON.fi API மூலம் பெறுவதன் மூலமும், பயனர்கள் இடைமுகத்தைப் (interface) பார்ப்பதற்கு முன்பே பிழைப் பாதைகளை (error paths) கடுமையாகச் சோதிப்பதன் மூலமும், டெவலப்பர்கள் தயாரிப்பு நிலையை (production) அடையும் இறுதிப் பயணத்தில் பயனர்களின் நிதியை பாதுகாக்கவும் மற்றும் நம்பிக்கையைத் தக்கவைக்கவும் முடியும்.
மூலம்: https://dev.to/web3kd/the-last-mile-taking-a-stonfi-integration-from-test-network-to-real-users-2ho0