જે ડેવલપર્સે સેન્ડબોક્સમાં STON.fi ટોકન સ્વેપ ચલાવવામાં સફળતા મેળવી છે, તેમને હવે ચેતવણી આપવામાં આવી રહી છે કે જો કોડમાં કેટલાક દેખીતી રીતે હાનિકારક ન લાગે તેવા શોર્ટકટ્સ રાખવામાં આવે, તો મેઈન નેટ (mainnet) પર જતાં યુઝરના ફંડ્સ સાફ થઈ શકે છે. ડેવલપર બ્લોગ પર બહાર પાડવામાં આવેલી એક સમુદાય-લેખિત ચેકલિસ્ટ એ ચોક્કસ મુદ્દાઓ દર્શાવે છે જ્યાં મોટાભાગના ઇન્ટિગ્રેશન નિષ્ફળ જાય છે અને પ્રોડક્શન-રેડી લોન્ચ માટે એક નક્કર માર્ગદર્શિકા આપે છે.
ટ્રાન્ઝિશન (transition) શા માટે મહત્વનું છે
STON.fi એક એવું રાઉટર પૂરું પાડે છે જે TON બ્લોકચેન પરના અનેક DEXes પર લિક્વિડિટી (liquidity) એકત્રિત કરે છે. જે પ્રોજેક્ટ્સ યુઝર્સને વન-ક્લિક સ્વેપ ઓફર કરવા માંગે છે, તેઓ સામાન્ય રીતે ફ્રન્ટ-એન્ડ અથવા સ્માર્ટ-કોન્ટ્રાક્ટ રેપર (wrapper) દ્વારા રાઉટરને કોલ કરે છે. ટેસ્ટ એન્વાયરમેન્ટમાં રાઉટર એડ્રેસ સ્ટેટિક હોય છે, ફી શેડ્યૂલ જાણીતું હોય છે, અને સેન્ડબોક્સ ખોટી રીતે નિર્દેશિત ટ્રાન્ઝેક્શનને સહન કરી લે છે. જોકે, મેઈન નેટ પર, રાઉટર અપગ્રેડ થઈ શકે છે, ફી પેરામીટર્સ બદલાઈ શકે છે, અને એક ખોટું એડ્રેસ વાસ્તવિક ટોકન્સને ડેડ કોન્ટ્રાક્ટમાં મોકલી શકે છે. તેથી, આર્થિક જોખમ એ એક સરળ યુઝર એક્સપિરિયન્સ અને એવા નુકસાન વચ્ચેનો તફાવત છે જે રાતોરાત પ્રોજેક્ટની પ્રતિષ્ઠાને નુકસાન પહોંચાડી શકે છે.
સૌથી સામાન્ય ભૂલ: હાર્ડ-કોડિંગ (hard-coding) વેલ્યુઝ
નિષ્ફળ લોન્ચમાં વારંવાર જોવા મળતું એક પેટર્ન એ રાઉટર એડ્રેસ અથવા ફી કોન્સ્ટન્ટ્સનું હાર્ડ-કોડિંગ છે જે ટેસ્ટિંગ દરમિયાન માન્ય હતા. જ્યારે STON.fi તેના રાઉટરને અપગ્રેડ કરે છે—જે પર્ફોર્મન્સ સુધારવા અથવા બગ્સ પેચ કરવા માટેની એક નિયમિત પ્રક્રિયા છે—ત્યારે હાર્ડ-કોડેડ એડ્રેસ હવે કાર્યરત કોન્ટ્રાક્ટ તરફ નિર્દેશ કરતું નથી. આનાથી ઇન્ટિગ્રેશન કાં તો એવી ભૂલ (error) બતાવશે જે યુઝર્સ ક્યારેય જોઈ શકતા નથી અથવા તેનાથી પણ ખરાબ રીતે, તે ફંડને એવા એડ્રેસ પર સાયલન્ટલી મોકલી દેશે જે તેને પ્રોસેસ કરી શકતું નથી. સમુદાયની માર્ગદર્શિકા એક જ નિયમ પર ભાર મૂકે છે: કયું રાઉટર વાપરવું તે STON.fi REST API ને નક્કી કરવા દો.
સ્ટેપ-બાય-સ્ટેપ સુરક્ષા ચેકલિસ્ટ
આ ચેકલિસ્ટ માઈગ્રેશન પ્રક્રિયાને ચાર તાર્કિક સ્તરોમાં વહેંચે છે—એન્વાયરમેન્ટ, કોન્ટ્રાક્ટ ઇન્ટરેક્શન, ફી કેલ્ક્યુલેશન અને એજ-કેસ હેન્ડલિંગ.
એન્વાયરમેન્ટ વેરિયેબલ્સને વહેલા વેલિડેટ કરો. ટેસ્ટિંગ દરમિયાન WebSocket એન્ડપોઈન્ટ અને REST API બેઝ URL ને સેન્ડબોક્સ પર સેટ કરો; લોન્ચ કરતા પહેલા તેને મેઈન નેટ નોડ્સ પર સ્વિચ કરો. અહીં થયેલી એક ટાઈપો (typo) વાસ્તવિક સ્વેપને ટેસ્ટ રાઉટર પર રીડાયરેક્ટ કરી શકે છે, જેનાથી ટોકન્સ કાયમ માટે લોક થઈ શકે છે.
કોન્ટ્રાક્ટ એડ્રેસ ક્યારેય એમ્બેડ (embed) ન કરો. STON.fi API સામે સિમ્યુલેશન રિક્વેસ્ટ રન કરો, રિસ્પોન્સમાંથી વર્તમાન રાઉટર એડ્રેસ મેળવો, અને તેને રન-ટાઇમ પર તમારા
dexFactory(અથવા સમાન કોન્ટ્રાક્ટ-ફેક્ટરી) માં ફીડ કરો. આ આપમેળે ભવિષ્યના કોઈપણ રાઉટર અપગ્રેડ સાથે અનુકૂલિત થઈ જશે.ફી ઓન ધ ફ્લાય (on the fly) ગણો. API ના કોન્ફિગરેશન પેલોડમાંથી ફી પેરામીટર્સ મેળવો અને તમારા ફી-મેથ રૂટિનમાં તેનો ઉપયોગ કરો. પ્લેટફોર્મ તેની ઇકોનોમિક્સમાં ફેરફાર કરે તે ક્ષણે હાર્ડ-કોડેડ ટકાવારી નકામી બની જાય છે.
સત્તાવાર SDK અને TonConnect ને પ્રાધાન્ય આપો. SDK તમારા માટે BOC (Bag of Cells) સ્ટ્રક્ચર્સ બનાવે છે અને તેમાં ગેસ લિમિટ્સ, ડેટા એન્કોડિંગ અને સિગ્નેચર વેલિડેશન માટેની તપાસ સામેલ હોય છે. મેન્યુઅલ BOC કમ્પાઈલેશન ફક્ત એવા અત્યંત વિશિષ્ટ ઉપયોગો માટે જ રાખવું જોઈએ જે SDK કવર કરી શકતું નથી.
ફેઈલ્યોર-મોડ ટેસ્ટિંગ કરો. સેન્ડબોક્સમાં out-of-gas પરિસ્થિતિઓ, અપૂરતી એલાઉન્સ (insufficient allowance) અને ખોટા જવાબો (malformed replies) નું સિમ્યુલેશન કરો. ખાતરી કરો કે તમારો કોન્ટ્રાક્ટ યુઝરને રિફંડ આપે છે અથવા સ્પષ્ટ એરર ઇવેન્ટ ઇમિટ કરે છે. પ્રોડક્શનમાં આ બગ્સ શોધવા માટે યુઝર્સ પર નિર્ભર રહેવું એ યુઝર લોસ (churn) નો ખતરો વધારે છે.
રેફરલ વિડ્રોઅલ પાથની પુષ્ટિ કરો. DEX ના બીજા વર્ઝનમાં, રેફરલ ફી વોલેટને બદલે સમર્પિત Vault કોન્ટ્રાક્ટમાં જાય છે. તમારા ઇન્ટિગ્રેશને રેફરરના ખાતામાં ક્રેડિટ કરતા પહેલા Vault ની વિડ્રોઅલ મેથડને કોલ કરવી જોઈએ અને પ્રાપ્ત થયેલા ટોકન્સને હેન્ડલ કરવા જોઈએ.
ડેવલપર્સ શેના પર ચર્ચા કરી રહ્યા છે
કેટલાક ડેવલપર્સ દલીલ કરે છે કે SDK બિનજરૂરી ઓવરહેડ ઉમેરે છે અને હેન્ડક્રાફ્ટેડ BOC પેલોડ ગેસમાં નાનું અને સસ્તું હોઈ શકે છે. માર્ગદર્શિકા આ દૃષ્ટિકોણને સ્વીકારે છે પરંતુ જણાવે છે કે SDK રાઉટર એડ્રેસ અને ફી સ્કીમાના અપડેટ્સને પણ સાથે લાવે છે, જેનો અર્થ છે કે દરેક STON.fi અપગ્રેડ પછી મેન્યુઅલી બનાવેલા પેલોડને ફરીથી તપાસવી પડશે. તેથી, આ ટ્રેડ-ઓફ (trade-off) મામૂલી ગેસ બચત અને સાયલન્ટ બ્રેકેજ (silent breakage) ના જોખમ વચ્ચે છે.
આગળ શું ધ્યાન રાખવું
- રાઉટર અપગ્રેડની જાહેરાતો. STON.fi તેના ડેવલપર ચેનલ પર આગામી રાઉટર ફેરફારો પોસ્ટ કરે છે. આ ફીડ્સ સબ્સ્ક્રાઇબ કરવાથી તમે મેઈન નેટ સ્વિચ કરતા પહેલા સેન્ડબોક્સમાં નવા એડ્રેસનું અગાઉથી પરીક્ષણ કરી શકો છો.
- ફી-પેરામીટર સુધારા. બજારની સ્થિતિ મુજબ ફીના ટકાવારીમાં ફેરફાર થઈ શકે છે, તેથી કોઈપણ મોનિટરિંગ સર્વિસમાં કોન્ફિગરેશન એન્ડપોઈન્ટમાંથી સમયાંતરે ડેટા મેળવવાની સુવિધા સામેલ કરો.
- SDK વર્ઝન રિલીઝ. નવા SDK રિલીઝમાં ઘણીવાર મેઈન નેટ લોન્ચ પછી શોધાયેલા એજ કેસો માટે બગ ફિક્સ સામેલ હોય છે. રાઉટર એડ્રેસ અપડેટ કરવા જેટલું જ મહત્વનું SDK ને અપ-ટુ-ડેટ રાખવું છે.
મુખ્ય તારણ સ્પષ્ટ છે: "ટેસ્ટિંગમાં કામ કરે છે" એવો સ્વેપ આપોઆપ સુરક્ષિત મેઈન નેટ (mainnet) અનુભવમાં પરિવર્તિત થતો નથી. રૂટર એડ્રેસથી લઈને ફી શેડ્યૂલ સુધીના દરેક મહત્વપૂર્ણ મૂલ્યોને લાઈવ STON.fi API માંથી મેળવીને, અને વપરાશકર્તાઓ ઇન્ટરફેસ જુએ તે પહેલાં ભૂલના માર્ગો (error paths) નું કડક પરીક્ષણ કરીને, ડેવલપર્સ યુઝરના ભંડોળનું રક્ષણ કરી શકે છે અને જ્યારે તેઓ પ્રોડક્શનના અંતિમ તબક્કામાં પહોંચે ત્યારે વિશ્વાસ જાળવી શકે છે.
સ્ત્રોત: https://dev.to/web3kd/the-last-mile-taking-a-stonfi-integration-from-test-network-to-real-users-2ho0
