సాండ్‌బాక్స్‌లో (sandbox) STON.fi టోకెన్ స్వాప్‌ను విజయవంతంగా నడపగలిగిన డెవలపర్లు, కోడ్‌లో కొన్ని చిన్నపాటి షార్ట్‌కట్‌లను వదిలేస్తే మెయిన్‌నెట్‌కు (mainnet) మారే క్రమంలో వినియోగదారుల నిధులు పోయే ప్రమాదం ఉందని హెచ్చరిస్తున్నారు. డెవలపర్ బ్లాగ్‌లో విడుదల చేయబడిన కమ్యూనిటీ రూపొందించిన చెక్‌లిస్ట్, చాలా ఇంటెగ్రేషన్లు ఎక్కడ విఫలమవుతాయో మరియు ప్రొడక్షన్-రెడీ లాంచ్ కోసం ఒక స్పష్టమైన మార్గాన్ని వివరిస్తుంది.

ఈ మార్పు ఎందుకు ముఖ్యం

STON.fi అనేది TON బ్లాక్‌చైన్‌లోని బహుళ DEXల ద్వారా లిక్విడిటీని ఏకీకృతం చేసే ఒక రూటర్ (router)ను అందిస్తుంది. వినియోగదారులకు వన్-క్లిక్ స్వాప్ సౌకర్యాన్ని అందించాలనుకునే ప్రాజెక్టులు సాధారణంగా ఫ్రంట్-ఎండ్ లేదా స్మార్ట్-కాంట్రాక్ట్ రాపర్ నుండి రూటర్‌ను పిలుస్తాయి. టెస్ట్ ఎన్విరాన్మెంట్‌లో రూటర్ అడ్రస్ స్థిరంగా ఉంటుంది, ఫీజు షెడ్యూల్ ముందే తెలుస్తుంది మరియు సాండ్‌బాక్స్ తప్పుగా పంపిన లావాదేవీలను కూడా అనుమతిస్తుంది. అయితే, మెయిన్‌నెట్‌లో రూటర్‌ను అప్‌గ్రేడ్ చేయవచ్చు, ఫీజు పారామీటర్లు మారవచ్చు మరియు ఒక చిన్న అడ్రస్ తప్పు జరిగినా, నిజమైన టోకెన్లు పని చేయని (dead) కాంట్రాక్ట్‌కు వెళ్ళిపోతాయి. కాబట్టి, ఇక్కడ ఆర్థిక నష్టాలు చాలా ఎక్కువగా ఉంటాయి; ఇది ఒక సాఫీగా సాగే యూజర్ ఎక్స్‌పీరియన్స్ లేదా ప్రాజెక్ట్ ప్రతిష్టను రాత్రికి రాత్రే దెబ్బతీసే నష్టం మధ్య తేడాను నిర్ణయిస్తుంది.

అత్యంత సాధారణ తప్పు: హార్డ్-కోడింగ్ వాల్యూస్ (hard-coding values)

విఫలమైన లాంచ్‌లలో తరచుగా కనిపించే ఒక అంశం ఏమిటంటే, టెస్టింగ్ సమయంలో ఉపయోగించిన రూటర్ అడ్రస్ లేదా ఫీజు కాన్స్టెంట్లను హార్డ్-కోడ్ చేయడం. STON.fi తన రూటర్‌ను అప్‌గ్రేడ్ చేసినప్పుడు—పెర్ఫార్మెన్స్ మెరుగుపరచడానికి లేదా బగ్స్ సరిచేయడానికి ఇది ఒక సాధారణ ప్రక్రియ—ఆ హార్డ్-కోడ్ చేసిన అడ్రస్ ఇకపై పనిచేసే కాంట్రాక్ట్‌ను సూచించదు. దీనివల్ల ఇంటెగ్రేషన్ ఒక ఎర్రర్‌ను చూపిస్తుంది (దీనిని వినియోగదారులు గమనించలేకపోవచ్చు) లేదా మరింత దారుణంగా, నిధులను ప్రాసెస్ చేయలేని అడ్రస్‌కు నిశ్శబ్దంగా పంపిస్తుంది. కమ్యూనిటీ గైడ్ ఒకే ఒక నియమాన్ని నొక్కి చెబుతోంది: ఏ రూటర్‌ను ఉపయోగించాలో STON.fi REST APIని నిర్ణయించనివ్వండి.

దశలవారీ భద్రతా చెక్‌లిస్ట్

ఈ చెక్‌లిస్ట్ మైగ్రేషన్ ప్రక్రియను నాలుగు తార్కిక పొరలుగా విభజిస్తుంది—ఎన్విరాన్మెంట్ (environment), కాంట్రాక్ట్ ఇంటరాక్షన్ (contract interaction), ఫీజు కాలిక్యులేషన్ (fee calculation), మరియు ఎడ్జ్-కేస్ హ్యాండ్లింగ్ (edge-case handling).

  • ఎన్విరాన్మెంట్ వేరియబుల్స్‌ను ముందుగానే ధృవీకరించండి. టెస్టింగ్ సమయంలో WebSocket ఎండ్‌పాయింట్ మరియు REST API బేస్ URLలను సాండ్‌బాక్స్‌కు అనుసంధానించండి; లాంచ్ చేసే ముందు వాటిని మెయిన్‌నెట్ నోడ్స్‌కు మార్చండి. ఇక్కడ చిన్న టైపో (typo) జరిగినా, నిజమైన స్వాప్ టెస్ట్ రూటర్‌కు వెళ్ళిపోయి, టోకెన్లు శాశ్వతంగా లాక్ అయిపోయే ప్రమాదం ఉంది.

  • కాంట్రాక్ట్ అడ్రస్‌లను ఎప్పుడూ ఎంబెడ్ చేయకండి. STON.fi API ద్వారా ఒక సిమ్యులేషన్ రిక్వెస్ట్‌ను రన్ చేయండి, రెస్పాన్స్ నుండి ప్రస్తుత రూటర్ అడ్రస్‌ను పొందండి మరియు రన్‌టైమ్‌లో దానిని మీ dexFactory (లేదా సమానమైన కాంట్రాక్ట్-ఫ్యాక్టరీ)లోకి పంపండి. ఇది భవిష్యత్తులో జరిగే రూటర్ అప్‌గ్రేడ్‌లకు ఆటోమేటిక్‌గా అనుగుణంగా మారుతుంది.

  • ఫీజులను రియల్ టైమ్‌లో లెక్కించండి. API యొక్క కాన్ఫిగరేషన్ పేలోడ్ నుండి ఫీజు పారామీటర్లను తీసుకుని, మీ ఫీజు-మ్యాథ్ (fee-math) రూటీన్‌లో ఉపయోగించండి. ప్లాట్‌ఫారమ్ తన ఎకనామిక్స్‌ను మార్చిన వెంటనే హార్డ్-కోడ్ చేసిన శాతాలు (percentages) పనికిరాకుండా పోతాయి.

  • అధికారిక SDK మరియు TonConnectను ఉపయోగించండి. SDK మీ కోసం BOC (Bag of Cells) స్ట్రక్చర్లను నిర్మిస్తుంది మరియు గ్యాస్ లిమిట్స్ (gas limits), డేటా ఎన్‌కోడింగ్, మరియు సిగ్నేచర్ వాలిడేషన్ కోసం తనిఖీలను కలిగి ఉంటుంది. SDK కవర్ చేయలేని అత్యంత ప్రత్యేకమైన సందర్భాల కోసం మాత్రమే మాన్యువల్ BOC కంపైలేషన్‌ను ఉపయోగించాలి.

  • ఫెయిల్యూర్-మోడ్ టెస్టింగ్‌ను నిర్వహించండి. సాండ్‌బాక్స్‌లో out-of-gas సందర్భాలు, తగినంత అలవెన్స్ లేకపోవడం (insufficient allowance), మరియు తప్పుగా ఉన్న రిప్లైలను (malformed replies) సిమ్యులేట్ చేయండి. మీ కాంట్రాక్ట్ వినియోగదారుడికి రీఫండ్ ఇస్తుందో లేదా స్పష్టమైన ఎర్రర్ ఈవెంట్‌ను విడుదల చేస్తుందో లేదో ధృవీకరించండి. ప్రొడక్షన్‌లో ఈ బగ్‌లను కనుగొనడానికి వినియోగదారులపై ఆధారపడటం వల్ల వినియోగదారులు తగ్గిపోయే అవకాశం ఉంది.

  • రిఫరల్ విత్‌డ్రాయల్ మార్గాలను ధృవీకరించండి. DEX యొక్క రెండవ వెర్షన్‌లో, రిఫరల్ ఫీజులు వాలెట్‌కు బదులుగా ప్రత్యేకమైన Vault కాంట్రాక్ట్‌లోకి చేరుతాయి. మీ ఇంటెగ్రేషన్ తప్పనిసరిగా Vault యొక్క విత్‌డ్రాయల్ మెథడ్‌ను పిలవాలి మరియు రిఫరర్ ఖాతాలో క్రెడిట్ చేసే ముందు అందుకున్న టోకెన్లను హ్యాండిల్ చేయాలి.

డెవలపర్లు దేని గురించి చర్చించుకుంటున్నారు

SDK అనవసరమైన ఓవర్‌హెడ్‌ను (overhead) జోడిస్తుందని మరియు స్వయంగా తయారు చేసిన BOC పేలోడ్ చిన్నదిగా మరియు తక్కువ గ్యాస్‌తో (gas) పనిచేస్తుందని కొందరు డెవలపర్లు వాదిస్తారు. ఈ అభిప్రాయాన్ని గైడ్ అంగీకరిస్తుంది, కానీ SDK రూటర్ అడ్రస్ మరియు ఫీజు స్కీమాకు సంబంధించిన అప్‌డేట్‌లను కూడా కలిగి ఉంటుందని పేర్కొంది. అంటే, మాన్యువల్‌గా తయారు చేసిన పేలోడ్‌ను ప్రతి STON.fi అప్‌గ్రేడ్ తర్వాత మళ్ళీ మార్చాల్సి ఉంటుంది. కాబట్టి, ఇది స్వల్ప గ్యాస్ ఆదా మరియు నిశ్శబ్దంగా జరిగే విఫలమయ్యే ప్రమాదం (silent breakage) మధ్య ఎంచుకోవాల్సిన విషయం.

తదుపరి గమనించవలసినవి

  • రూటర్ అప్‌గ్రేడ్ ప్రకటనలు. STON.fi తన డెవలపర్ ఛానెల్‌లో రాబోయే రూటర్ మార్పులను పోస్ట్ చేస్తుంది. ఆ ఫీడ్‌లను సబ్‌స్క్రైబ్ చేసుకోవడం ద్వారా, మెయిన్‌నెట్‌కు మారకముందే కొత్త అడ్రస్‌ను సాండ్‌బాక్స్‌లో ముందుగానే పరీక్షించవచ్చు.
  • ఫీజు-పారామీటర్ల సవరణలు. మార్కెట్ పరిస్థితులకు అనుగుణంగా ఫీజు శాతాలను సర్దుబాటు చేయవచ్చు కాబట్టి, ఏదైనా మానిటరింగ్ సర్వీస్‌లో కాన్ఫిగరేషన్ ఎండ్‌పాయింట్‌ను క్రమ పద్ధతిలో తనిఖీ చేసేలా (periodic pull) ఏర్పాటు చేసుకోండి.
  • SDK వెర్షన్ విడుదలలు. మెయిన్‌నెట్ లాంచ్ తర్వాత కనుగొనబడిన ఎడ్జ్ కేసుల కోసం కొత్త SDK విడుదలలు తరచుగా బగ్ ఫిక్స్‌లను కలిగి ఉంటాయి. రూటర్ అడ్రస్‌ను అప్‌డేట్ చేయడం ఎంత ముఖ్యమో, SDKని కూడా అప్‌డేట్‌గా ఉంచుకోవడం అంతే ముఖ్యం.

దీని నుండి మనం గ్రహించాల్సింది ఏమిటంటే: "టెస్టింగ్‌లో పనిచేస్తుంది" అనిపించే ఒక స్వాప్ (swap), ఆటోమేటిక్‌గా సురక్షితమైన మెయిన్‌నెట్ (mainnet) అనుభవాన్ని అందించదు. రూటర్ అడ్రస్ నుండి ఫీ షెడ్యూల్ వరకు ప్రతి కీలకమైన విలువను లైవ్ STON.fi API నుండి పొందడం ద్వారా, మరియు వినియోగదారులు ఇంటర్‌ఫేస్‌ను చూడకముందే ఎర్రర్ పాత్‌లను (error paths) కఠినంగా పరీక్షించడం ద్వారా, డెవలపర్‌లు ప్రొడక్షన్ దశకు చేరుకున్నప్పుడు వినియోగదారుల నిధులను రక్షించగలరు మరియు నమ్మకాన్ని నిలబెట్టుకోగలరు.

Source: https://dev.to/web3kd/the-last-mile-taking-a-stonfi-integration-from-test-network-to-real-users-2ho0