ज्या डेव्हलपर्सनी STON.fi टोकन स्वॅप सँडबॉक्समध्ये (sandbox) यशस्वीरित्या चालवले आहे, त्यांना आता असा इशारा दिला जात आहे की, कोडमध्ये काही किरकोळ त्रुटी राहिल्यास मेननेटवर (mainnet) जाताना वापरकर्त्यांचे फंड गमावले जाऊ शकतात. डेव्हलपर ब्लॉगवर प्रसिद्ध झालेल्या कम्युनिटी-लिखित चेकलिस्टमध्ये नेमके कोणते मुद्दे अपयशी ठरतात आणि प्रॉडक्शन-रेडी (production-ready) लाँचसाठी नेमकी काय प्रक्रिया असावी, याचे मार्गदर्शन दिले आहे.

हा बदल का महत्त्वाचा आहे

STON.fi एक राउटर (router) प्रदान करते जो TON ब्लॉकचेनवरील अनेक DEX मध्ये लिक्विडिटी एकत्रित करतो. जे प्रोजेक्ट्स वापरकर्त्यांना 'वन-क्लिक स्वॅप' (one-click swap) सुविधा देऊ इच्छितात, ते सहसा फ्रंट-एंड किंवा स्मार्ट-कॉन्ट्रॅक्ट रॅपरद्वारे राउटरला कॉल करतात. टेस्ट एन्व्हायरमेंटमध्ये राउटरचा पत्ता स्थिर असतो, फीचे वेळापत्रक माहित असते आणि सँडबॉक्स चुकीच्या व्यवहारांना (mis-directed transactions) सहन करतो. मात्र, मेननेटवर राउटर अपडेट होऊ शकतो, फीचे पॅरामीटर्स बदलू शकतात आणि एक चुकीचा पत्ता खऱ्या टोकन्सना अशा कॉन्ट्रॅक्टकडे पाठवू शकतो जे आता कार्यरत नाही. त्यामुळे, आर्थिक जोखीम ही एक सुरळीत युजर एक्सपिरियन्स आणि प्रोजेक्टची प्रतिष्ठा एका रात्रीत खराब करू शकणारे नुकसान, यामधील फरक ठरवते.

सर्वात सामान्य चूक: व्हॅल्यूज हार्ड-कोड करणे (hard-coding values)

अपयशी लाँचमध्ये वारंवार दिसून येणारी एक पद्धत म्हणजे राउटरचा पत्ता किंवा फीचे कॉन्स्टंट्स (constants) हार्ड-कोड करणे, जे टेस्टिंग दरम्यान वैध होते. जेव्हा STON.fi त्याचा राउटर अपडेट करते—जे परफॉर्मन्स सुधारण्यासाठी किंवा बग्स फिक्स करण्यासाठी नियमितपणे केले जाते—तेव्हा तो हार्ड-कोड केलेला पत्ता कार्यान्वित कॉन्ट्रॅक्टकडे निर्देश करत नाही. यामुळे एकतर इंटिग्रेशनमध्ये एरर येईल जो वापरकर्त्यांना दिसणार नाही किंवा अधिक वाईट म्हणजे, फंड अशा पत्त्यावर पाठवले जातील जो त्यांना प्रोसेस करू शकत नाही. कम्युनिटी गाईड एकच नियम सांगते: कोणता राउटर वापरायचा हे ठरवण्यासाठी STON.fi REST API चा वापर करा.

स्टेप-बाय-स्टेप सुरक्षा चेकलिस्ट

ही चेकलिस्ट मायग्रेशन प्रक्रियेचे चार तार्किक स्तरांमध्ये विभाजन करते—एन्व्हायर्नमेंट (environment), कॉन्ट्रॅक्ट इंटरेक्शन (contract interaction), फी कॅल्क्युलेशन (fee calculation) आणि एज-केस हँडलिंग (edge-case handling).

  • एन्व्हायर्नमेंट व्हेरिएबल्सची (environment variables) लवकर पडताळणी करा. टेस्टिंग करताना WebSocket एंडपॉइंट आणि REST API बेस URL सँडबॉक्सकडे वळवा; लाँच करण्यापूर्वी ते मेननेट नोड्सवर स्विच करा. येथे झालेली एक छोटी चूक खऱ्या स्वॅपला टेस्ट राउटरकडे वळवू शकते, ज्यामुळे टोकन्स कायमचे लॉक होऊ शकतात.

  • कॉन्ट्रॅक्ट ॲड्रेस कधीही एम्बेड (embed) करू नका. STON.fi API विरुद्ध सिम्युलेशन रिक्वेस्ट चालवा, प्रतिसादातून (response) सध्याचा राउटर ॲड्रेस मिळवा आणि रनटाइममध्ये तो तुमच्या dexFactory (किंवा समकक्ष कॉन्ट्रॅक्ट-फॅक्टरी) मध्ये वापरा. यामुळे भविष्यातील कोणत्याही राउटर अपडेटनुसार सिस्टीम आपोआप जुळवून घेईल.

  • फी ऑन द फ्लाई (on the fly) मोजा. API च्या कॉन्फिगरेशन पेलोडमधून फी पॅरामीटर्स मिळवा आणि तुमच्या फी-मॅथ रूटीनमध्ये त्यांचा वापर करा. प्लॅटफॉर्मने त्याच्या इकॉनॉमिक्समध्ये बदल केल्याबरोबर हार्ड-कोड केलेले टक्केवारीचे आकडे कालबाह्य ठरतात.

  • अधिकृत SDK आणि TonConnect ला प्राधान्य द्या. SDK तुमच्यासाठी BOC (Bag of Cells) स्ट्रक्चर्स तयार करते आणि यामध्ये गॅस लिमिट्स (gas limits), डेटा एन्कोडिंग आणि सिग्नेचर व्हॅलिडेशनसाठी आवश्यक तपासण्यांचा समावेश असतो. मॅन्युअल BOC कंपायलेशन फक्त अशा विशेष वापरांसाठी ठेवा जिथे SDK पुरेसे नाही.

  • फेल्युअर-मोड टेस्टिंग (failure-mode testing) करा. सँडबॉक्समध्ये 'आउट-ऑफ-गॅस' (out-of-gas) परिस्थिती, अपुरी अलाउन्स (insufficient allowance) आणि चुकीचे रिप्लाय यांसारख्या परिस्थितींचे सिम्युलेशन करा. तुमचे कॉन्ट्रॅक्ट वापरकर्त्याला रिफंड देते किंवा स्पष्ट एरर इव्हेंट पाठवते याची खात्री करा. प्रॉडक्शनमध्ये हे बग्स शोधण्यासाठी वापरकर्त्यांवर अवलंबून राहणे म्हणजे व्यवसायाचे नुकसान करून घेणे होय.

  • रेफरल विड्रॉवल पाथ कन्फर्म करा. DEX च्या दुसऱ्या व्हर्जनमध्ये, रेफरल फी वॉलेटऐवजी एका समर्पित Vault कॉन्ट्रॅक्टमध्ये जमा होते. रेफररच्या खात्यात क्रेडिट करण्यापूर्वी तुमच्या इंटिग्रेशनने Vault च्या विड्रॉवल मेथडला कॉल करणे आणि प्राप्त झालेले टोकन्स हाताळणे आवश्यक आहे.

डेव्हलपर्समध्ये काय चर्चा सुरू आहे

काही डेव्हलपर्सचे असे मत आहे की SDK मुळे अनावश्यक ओव्हरहेड (overhead) वाढतो आणि मॅन्युअली तयार केलेला BOC पेलोड गॅसच्या दृष्टीने लहान आणि स्वस्त असू शकतो. गाईड हे मत मान्य करते, परंतु असेही स्पष्ट करते की SDK राउटर ॲड्रेस आणि फी स्कीमामधील अपडेट्स देखील एकत्र करते, याचा अर्थ असा की मॅन्युअली तयार केलेला पेलोड प्रत्येक STON.fi अपडेटनंतर पुन्हा तपासावा लागेल. त्यामुळे, हा निर्णय थोड्या प्रमाणात गॅसची बचत करणे आणि सिस्टीम अचानक बंद पडण्याचा धोका यामधील आहे.

पुढे काय लक्ष ठेवावे

  • राउटर अपडेटच्या घोषणा. STON.fi त्यांच्या डेव्हलपर चॅनेलवर आगामी राउटर बदलांची माहिती पोस्ट करते. त्या फीड्सला सबस्क्राईब केल्यामुळे तुम्हाला मेननेट स्विच करण्यापूर्वी सँडबॉक्समध्ये नवीन ॲड्रेसची आगाऊ चाचणी घेता येईल.
  • फी-पॅरामीटरमधील बदल. बाजारपेठेतील परिस्थितीनुसार फीचे टक्केवारी बदलली जाऊ शकते, म्हणून कोणत्याही मॉनिटरिंग सर्व्हिसमध्ये कॉन्फिगरेशन एंडपॉइंटमधून वेळोवेळी माहिती घेण्याची सोय ठेवा.
  • SDK व्हर्जन रिलीज. नवीन SDK रिलीजमध्ये अनेकदा मेननेट लाँच नंतर आढळलेल्या एज केसेससाठी बग फिक्सेस समाविष्ट असतात. राउटर ॲड्रेस अपडेट करण्याइतकेच SDK अपडेट ठेवणे महत्त्वाचे आहे.

निष्कर्ष स्पष्ट आहे: "टेस्टिंगमध्ये काम करणारे" स्वॅप म्हणजे आपोआप सुरक्षित मेननेट (mainnet) अनुभव मिळेलच असे नाही. राउटर ॲड्रेसपासून ते फी शेड्युलपर्यंतचे प्रत्येक महत्त्वाचे मूल्य थेट लाइव्ह STON.fi API मधून घेऊन आणि वापरकर्त्यांना इंटरफेस दिसण्यापूर्वी त्रुटींच्या मार्गांचा (error paths) काटेकोरपणे सराव करून, डेव्हलपर्स वापरकर्त्यांचे फंड सुरक्षित ठेवू शकतात आणि प्रोडक्शनच्या (production) अंतिम टप्प्यात प्रवेश करताना विश्वास टिकवून ठेवू शकतात.

स्रोत: https://dev.to/web3kd/the-last-mile-taking-a-stonfi-integration-from-test-network-to-real-users-2ho0