സാൻഡ്ബോക്സിൽ (sandbox) ഒരു STON.fi ടോക്കൺ സ്വാപ്പ് പ്രവർത്തിപ്പിക്കാൻ തയ്യാറാക്കിയ ഡെവലപ്പർമാർക്ക് ഇപ്പോൾ ഒരു മുന്നറിയിപ്പ് ലഭിച്ചിരിക്കുന്നു; കോഡിൽ നിസ്സാരമെന്ന് തോന്നുന്ന ചില കുറുക്കുവഴികൾ (shortcuts) അവശേഷിപ്പിച്ചാൽ മെയിൻനെറ്റിലേക്കുള്ള (mainnet) മാറ്റം ഉപയോക്താക്കളുടെ ഫണ്ട് നഷ്ടപ്പെടുത്താൻ കാരണമായേക്കാം. ഒരു ഡെവലപ്പർ ബ്ലോഗിൽ പുറത്തിറക്കിയ കമ്മ്യൂണിറ്റി തയ്യാറാക്കിയ ചെക്ക്ലിസ്റ്റ്, മിക്ക ഇന്റഗ്രേഷനുകളും പരാജയപ്പെടുന്ന കൃത്യമായ പോയിന്റുകൾ വിവരിക്കുകയും, പ്രൊഡക്ഷൻ റെഡി ആയ ഒരു ലോഞ്ചിനായി വ്യക്തമായ നിർദ്ദേശങ്ങൾ നൽകുകയും ചെയ്യുന്നു.
എന്തുകൊണ്ടാണ് ഈ മാറ്റം പ്രധാനമാകുന്നത്
TON ബ്ലോക്ക്ചെയിനിലെ ഒന്നിലധികം DEX-കളിലായി ലിക്വിഡിറ്റി ഏകീകരിക്കുന്ന ഒരു റൂട്ടർ (router) ആണ് STON.fi നൽകുന്നത്. ഉപയോക്താക്കൾക്ക് വൺ-ക്ലിക് സ്വാപ്പ് സൗകര്യം നൽകാൻ ആഗ്രഹിക്കുന്ന പ്രോജക്റ്റുകൾ സാധാരണയായി ഒരു ഫ്രണ്ട്-എൻഡിൽ നിന്നോ സ്മാർട്ട്-കോൺട്രാക്റ്റ് റാപ്പറിൽ നിന്നോ ആണ് റൂട്ടറിനെ വിളിക്കുന്നത്. ഒരു ടെസ്റ്റ് എൻവയോൺമെന്റിൽ റൂട്ടർ അഡ്രസ് സ്ഥിരമാണ് (static), ഫീ ഷെഡ്യൂൾ അറിയാവുന്നതാണ്, കൂടാതെ തെറ്റായ ദിശയിലുള്ള ഇടപാടുകൾ സാൻഡ്ബോക്സ് അനുവദിക്കുകയും ചെയ്യുന്നു. എന്നാൽ മെയിൻനെറ്റിൽ, റൂട്ടർ അപ്ഗ്രേഡ് ചെയ്യപ്പെട്ടേക്കാം, ഫീ പാരാമീറ്ററുകൾ മാറാം, കൂടാതെ ഒരു തെറ്റായ അഡ്രസ് നൽകിയാൽ യഥാർത്ഥ ടോക്കണുകൾ പ്രവർത്തിക്കാത്ത ഒരു കോൺട്രാക്റ്റിലേക്ക് അയക്കപ്പെട്ടേക്കാം. അതിനാൽ, സാമ്പത്തികമായ നഷ്ടസാധ്യതകൾ ഒരു പ്രോജക്റ്റിന്റെ സൽപ്പേരിനെ ഒറ്റരാത്രികൊണ്ട് തകർക്കാൻ ശേഷിയുള്ളതാണ്.
ഏറ്റവും സാധാരണമായ തെറ്റ്: ഹാർഡ്-കോഡിംഗ് (hard-coding)
പരാജയപ്പെട്ട ലോഞ്ചുകളിൽ ആവർത്തിച്ചു കാണുന്ന ഒരു രീതിയാണ് ടെസ്റ്റിംഗ് സമയത്ത് ഉപയോഗിച്ച റൂട്ടർ അഡ്രസ്സോ ഫീ കോൺസ്റ്റന്റുകളോ (fee constants) ഹാർഡ്-കോഡ് ചെയ്യുന്നത്. STON.fi അതിന്റെ റൂട്ടർ അപ്ഗ്രേഡ് ചെയ്യുമ്പോൾ—പ്രകടനം മെച്ചപ്പെടുത്തുന്നതിനോ ബഗുകൾ പരിഹരിക്കുന്നതിനോ വേണ്ടിയുള്ള സാധാരണമായ ഒരു നടപടിയാണിത്—ഹാർഡ്-കോഡ് ചെയ്ത അഡ്രസ് പിന്നീട് ഒരു ഫങ്ഷണൽ കോൺട്രാക്റ്റിലേക്ക് വിരൽ ചൂണ്ടില്ല. ഇത് ഉപയോക്താക്കൾക്ക് കാണാൻ കഴിയാത്ത ഒരു എറർ (error) ഉണ്ടാക്കുകയോ, അല്ലെങ്കിൽ കൂടുതൽ മോശമായ രീതിയിൽ, ഫണ്ട് പ്രോസസ്സ് ചെയ്യാൻ കഴിയാത്ത ഒരു അഡ്രസ്സിലേക്ക് നിശബ്ദമായി അയക്കുകയോ ചെയ്തേക്കാം. കമ്മ്യൂണിറ്റി ഗൈഡ് ഒരു നിയമം ഊന്നിപ്പറയുന്നു: ഏത് റൂട്ടർ ഉപയോഗിക്കണമെന്ന് STON.fi REST API തീരുമാനിക്കട്ടെ.
ഘട്ടം ഘട്ടമായുള്ള സുരക്ഷാ ചെക്ക്ലിസ്റ്റ്
ഈ ചെക്ക്ലിസ്റ്റ് മൈഗ്രേഷൻ പ്രക്രിയയെ നാല് ഘട്ടങ്ങളായി തിരിക്കുന്നു—എൻവയോൺമെന്റ്, കോൺട്രാക്റ്റ് ഇന്ററാക്ഷൻ, ഫീ കാൽക്കുലേഷൻ, ഫെയിലിയർ-മോഡ് ഹാൻഡ്ലിംഗ്.
എൻവയോൺമെന്റ് വേരിയബിളുകൾ നേരത്തെ തന്നെ പരിശോധിക്കുക. ടെസ്റ്റിംഗ് സമയത്ത് WebSocket എൻഡ്പോയിന്റും REST API ബേസ് URL-ഉം സാൻഡ്ബോക്സിലേക്ക് തിരിച്ചുവിടുക; ലോഞ്ചിന് മുമ്പ് അവ മെയിൻനെറ്റ് നോഡുകളിലേക്ക് മാറ്റുക. ഇവിടെ സംഭവിക്കുന്ന ഒരു ചെറിയ ടൈപ്പോ (typo) പോലും യഥാർത്ഥ സ്വാപ്പിനെ ടെസ്റ്റ് റൂട്ടറിലേക്ക് തിരിച്ചുവിട്ടേക്കാം, ഇത് ടോക്കണുകൾ എന്നെന്നേക്കുമായി ലോക്ക് ചെയ്യപ്പെടാൻ കാരണമാകും.
കോൺട്രാക്റ്റ് അഡ്രസ്സുകൾ ഒരിക്കലും എംബെഡ് (embed) ചെയ്യരുത്. STON.fi API-ൽ ഒരു സിമുലേഷൻ റിക്വസ്റ്റ് നടത്തി, റെസ്പോൺസിൽ നിന്ന് നിലവിലെ റൂട്ടർ അഡ്രസ് എടുത്ത്, അത് റൺടൈമിൽ നിങ്ങളുടെ
dexFactory-ലേക്ക് (അല്ലെങ്കിൽ തുല്യമായ കോൺട്രാക്റ്റ് ഫാക്ടറിയിലേക്ക്) നൽകുക. ഇത് ഭാവിയിലെ ഏത് റൂട്ടർ അപ്ഗ്രേഡിനും സ്വയം അനുരൂപപ്പെടാൻ സഹായിക്കും.ഫീസുകൾ തത്സമയം കണക്കാക്കുക. API-യുടെ കോൺഫിഗറേഷൻ പേലോഡിൽ നിന്ന് ഫീ പാരാമീറ്ററുകൾ എടുത്ത് അവ നിങ്ങളുടെ ഫീ-മാത്ത് (fee-math) റൂട്ടീനിൽ ഉപയോഗിക്കുക. പ്ലാറ്റ്ഫോം അതിന്റെ സാമ്പത്തിക ക്രമീകരണങ്ങളിൽ മാറ്റം വരുത്തുന്ന നിമിഷം തന്നെ ഹാർഡ്-കോഡ് ചെയ്ത ശതമാനങ്ങൾ കാലഹരണപ്പെട്ടതാകും.
ഔദ്യോഗിക SDK-യും TonConnect-ഉം ഉപയോഗിക്കുക. SDK നിങ്ങൾക്കായി BOC (Bag of Cells) സ്ട്രക്ചറുകൾ നിർമ്മിക്കുന്നു കൂടാതെ ഗ്യാസ് ലിമിറ്റുകൾ, ഡാറ്റ എൻകോഡിംഗ്, സിഗ്നേച്ചർ വാലിഡേഷൻ എന്നിവയ്ക്കുള്ള പരിശോധനകളും ഉൾപ്പെടുത്തുന്നു. SDK ഉപയോഗിച്ച് ചെയ്യാൻ കഴിയാത്ത വളരെ പ്രത്യേകമായ കാര്യങ്ങൾക്കായി മാത്രം മാനുവൽ BOC കംപൈലേഷൻ ഉപയോഗിക്കുക.
ഫെയിലിയർ-മോഡ് ടെസ്റ്റിംഗ് (failure-mode testing) നടത്തുക. സാൻഡ്ബോക്സിൽ ഔട്ട്-ഓഫ്-ഗ്യാസ് (out-of-gas) സാഹചര്യങ്ങൾ, അപര്യാപ്തമായ അലവൻസ് (insufficient allowance), തെറ്റായ മറുപടികൾ എന്നിവ സിമുലേറ്റ് ചെയ്യുക. നിങ്ങളുടെ കോൺട്രാക്റ്റ് ഉപയോക്താവിന് പണം തിരികെ നൽകുന്നുണ്ടോ അല്ലെങ്കിൽ വ്യക്തമായ ഒരു എറർ ഇവന്റ് പുറപ്പെടുവിക്കുന്നുണ്ടോ എന്ന് പരിശോധിക്കുക. പ്രൊഡക്ഷനിൽ ഇത്തരം ബഗുകൾ കണ്ടെത്താൻ ഉപയോക്താക്കളെ ആശ്രയിക്കുന്നത് ഉപയോക്താക്കളുടെ കുറവിന് കാരണമാകും.
റഫറൽ വിത്ത്ഡ്രോവൽ പാത്തുകൾ സ്ഥിരീകരിക്കുക. DEX-ന്റെ രണ്ടാം പതിപ്പിൽ, റഫറൽ ഫീസുകൾ ഒരു വാലറ്റിലേക്ക് പകരം ഒരു പ്രത്യേക Vault കോൺട്രാക്റ്റിലേക്കാണ് എത്തുന്നത്. റഫററുടെ അക്കൗണ്ടിലേക്ക് ക്രെഡിറ്റ് ചെയ്യുന്നതിന് മുമ്പ് നിങ്ങളുടെ ഇന്റഗ്രേഷൻ Vault-ന്റെ വിത്ത്ഡ്രോവൽ മെത്തേഡ് വിളിക്കുകയും ലഭിച്ച ടോക്കണുകൾ കൈകാര്യം ചെയ്യുകയും വേണം.
ഡെവലപ്പർമാർക്കിടയിലെ ചർച്ചകൾ
SDK അനാവശ്യമായ അധികഭാരം (overhead) ഉണ്ടാക്കുന്നുവെന്നും, കൈകൊണ്ട് നിർമ്മിച്ച ഒരു BOC പേലോഡ് കുറച്ചുകൂടി ചെറുതും ഗ്യാസ് ചിലവ് കുറഞ്ഞതും ആകുമെന്നും ചില ഡെവലപ്പർമാർ വാദിക്കുന്നു. ഗൈഡ് ഈ കാഴ്ചപ്പാടിനെ അംഗീകരിക്കുന്നുണ്ടെങ്കിലും, റൂട്ടർ അഡ്രസ്സിനും ഫീ സ്കീമയ്ക്കും വേണ്ടിയുള്ള അപ്ഡേറ്റുകളും SDK-യിൽ ഉൾപ്പെടുത്തിയിട്ടുണ്ടെന്ന് ചൂണ്ടിക്കാട്ടുന്നു. ഇതിനർത്ഥം മാനുവലായി നിർമ്മിച്ച പേലോഡ് ഓരോ STON.fi അപ്ഗ്രേഡിന് ശേഷവും വീണ്ടും പരിശോധിക്കേണ്ടി വരും എന്നാണ്. അതിനാൽ, നേരിയ ഗ്യാസ് ലാഭവും അപ്രതീക്ഷിതമായ തകരാറുകൾ സംഭവിക്കാനുള്ള സാധ്യതയും തമ്മിലുള്ള ഒരു തിരഞ്ഞെടുപ്പാണ് ഇവിടെയുള്ളത്.
ശ്രദ്ധിക്കേണ്ട കാര്യങ്ങൾ
- റൂട്ടർ അപ്ഗ്രേഡ് അറിയിപ്പുകൾ. STON.fi അതിന്റെ ഡെവലപ്പർ ചാനലിൽ വരാനിരിക്കുന്ന റൂട്ടർ മാറ്റങ്ങൾ പോസ്റ്റ് ചെയ്യുന്നു. ഈ ഫീഡുകൾ സബ്സ്ക്രൈബ് ചെയ്യുന്നത് വഴി മെയിൻനെറ്റിലേക്ക് മാറുന്നതിന് മുമ്പ് തന്നെ പുതിയ അഡ്രസ് സാൻഡ്ബോക്സിൽ പരിശോധിക്കാൻ നിങ്ങൾക്ക് സാധിക്കും.
- ഫീ പാരാമീറ്റർ പരിഷ്കരണങ്ങൾ. വിപണി സാഹചര്യങ്ങളോട് പ്രതികരിക്കുന്നതിനായി ഫീ ശതമാനങ്ങളിൽ മാറ്റം വരുത്താൻ സാധ്യതയുള്ളതിനാൽ, ഏതെങ്കിലും മോണിറ്ററിംഗ് സർവീസിലേക്ക് കോൺഫിഗറേഷൻ എൻഡ്പോയിന്റിൽ നിന്നുള്ള കൃത്യമായ ഇടവേളകളിലുള്ള വിവരശേഖരണം ഉൾപ്പെടുത്തുക.
- SDK പതിപ്പുകളുടെ റിലീസ്. മെയിൻനെറ്റ് ലോഞ്ചിന് ശേഷം കണ്ടെത്തുന്ന എഡ്ജ് കേസുകൾക്കുള്ള (edge cases) ബഗ് ഫിക്സുകൾ പലപ്പോഴും പുതിയ SDK റിലീസുകളിൽ ഉൾപ്പെടുത്താറുണ്ട്. റൂട്ടർ അഡ്രസ് അപ്ഡേറ്റ് ചെയ്യുന്നത് പോലെ തന്നെ പ്രധാനമാണ് SDK അപ്ഡേറ്റ് ചെയ്ത് സൂക്ഷിക്കുന്നതും.
ഇതിൽ നിന്നുള്ള പാഠം വ്യക്തമാണ്: "ടെസ്റ്റിംഗിൽ പ്രവർത്തിക്കുന്നു" എന്നത് കൊണ്ട് മാത്രം ഒരു മെയിൻനെറ്റ് (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