توسعهدهندگانی که اجرای سواپ توکن STON.fi را در یک sandbox به اتمام رساندهاند، اکنون هشدار دریافت میکنند که انتقال به mainnet میتواند در صورت باقی ماندن چند میانبر بهظاهر بیضرر در کد، منجر به از دست رفتن دارایی کاربران شود. یک چکلیست تهیه شده توسط جامعه کاربری که در یک وبلاگ توسعهدهنده منتشر شده، دقیقاً نقاطی را که اکثر ادغامها (integrations) در آنها شکست میخورند مشخص کرده و دستورالعملی مشخص برای یک لانچ آمادهی تولید (production-ready) ارائه میدهد.
چرا این انتقال اهمیت دارد
STON.fi یک روتر (router) ارائه میدهد که نقدینگی را در چندین DEX در بلاکچین TON تجمیع میکند. پروژههایی که میخواهند سواپ تککلیکی به کاربران ارائه دهند، معمولاً روتر را از طریق یک فرانتاند یا یک wrapper قرارداد هوشمند فراخوانی میکنند. در یک محیط تست، آدرس روتر ثابت است، جدول کارمزدها مشخص است و sandbox تراکنشهای اشتباه را تحمل میکند. اما در mainnet، روتر میتواند ارتقا یابد، پارامترهای کارمزد تغییر کنند و یک آدرس اشتباه، توکنهای واقعی را به یک قرارداد غیرفعال (dead contract) میفرستد. بنابراین، ریسک مالی تفاوت بین یک تجربه کاربری روان و از دست رفتن سرمایهای است که میتواند اعتبار یک پروژه را یکشبه نابود کند.
رایجترین اشتباه: هاردکد کردن مقادیر
یک الگوی تکراری در لانچهای ناموفق، هاردکد کردن آدرس روتر یا ثابتهای کارمزد است که در طول تست معتبر بودهاند. وقتی STON.fi روتر خود را ارتقا میدهد — که یک رویداد روتین برای بهبود عملکرد یا رفع باگها است — آدرس هاردکد شده دیگر به یک قرارداد فعال اشاره نمیکند. در این حالت، ادغام یا خطایی میدهد که کاربران هرگز آن را نمیبینند، یا بدتر از آن، مخفیانه داراییها را به آدرسی هدایت میکند که قادر به پردازش آنها نیست. راهنمای جامعه بر یک قانون تأکید دارد: اجازه دهید STON.fi REST API تصمیم بگیرد که از کدام روتر استفاده شود.
چکلیست ایمنی مرحلهبهمرحله
این چکلیست فرآیند مهاجرت را به چهار لایه منطقی تقسیم میکند: محیط (environment)، تعامل با قرارداد (contract interaction)، محاسبه کارمزد (fee calculation) و مدیریت موارد خاص (edge-case handling).
متغیرهای محیطی را در مراحل اولیه تأیید کنید. هنگام تست، نقطه پایانی WebSocket و URL پایه REST API را روی sandbox تنظیم کنید؛ قبل از لانچ، آنها را به نودهای mainnet تغییر دهید. یک غلط تایپی در اینجا میتواند یک سواپ واقعی را به روتر تست هدایت کند و توکنها را برای همیشه قفل کند.
هرگز آدرس قراردادها را در کد قرار ندهید. یک درخواست شبیهسازی (simulation) در برابر STON.fi API اجرا کنید، آدرس فعلی روتر را از پاسخ استخراج کنید و آن را در زمان اجرا (runtime) به
dexFactory(یا معادل قرارداد-فکتوری خود) بدهید. این کار به طور خودکار با هر ارتقای آتی روتر سازگار میشود.کارمزدها را در لحظه محاسبه کنید. پارامترهای کارمزد را از payload پیکربندی API دریافت کرده و در روتین محاسبات کارمزد خود استفاده کنید. درصدهای هاردکد شده به محض اینکه پلتفرم اقتصاد خود را تغییر دهد، منسوخ میشوند.
استفاده از SDK رسمی و TonConnect را در اولویت قرار دهید. SDK ساختارهای BOC (Bag of Cells) را برای شما میسازد و شامل بررسیهایی برای محدودیتهای gas، کدگذاری دادهها و اعتبارسنجی امضا است. کامپایل دستی BOC باید تنها برای موارد بسیار تخصصی که SDK قادر به پوشش آنها نیست، رزرو شود.
تست حالتهای شکست (failure-mode testing) را انجام دهید. سناریوهای کمبود gas، موجودی ناکافی (insufficient allowance) و پاسخهای ناقص را در sandbox شبیهسازی کنید. تأیید کنید که قرارداد شما وجه را به کاربر بازمیگرداند یا یک رویداد خطای واضح صادر میکند. تکیه بر کاربران برای کشف این باگها در محیط تولید، باعث ریزش کاربران میشود.
مسیرهای برداشت معرف (referral) را تأیید کنید. در نسخه دوم این DEX، کارمزدهای معرف به جای یک کیف پول، در یک قرارداد Vault اختصاصی قرار میگیرند. ادغام شما باید متد برداشت Vault را فراخوانی کرده و قبل از واریز به حساب معرف، توکنهای دریافتی را مدیریت کند.
آنچه توسعهدهندگان درباره آن بحث میکنند
برخی توسعهدهندگان استدلال میکنند که SDK بار اضافی (overhead) غیرضروری ایجاد میکند و یک payload دستی برای BOC میتواند کوچکتر و از نظر gas ارزانتر باشد. این راهنما این دیدگاه را میپذیرد اما اشاره میکند که SDK همچنین بهروزرسانیهای مربوط به آدرس روتر و طرح کارمزد (fee schema) را نیز همراه دارد؛ این بدان معناست که یک payload که به صورت دستی ساخته شده است، باید پس از هر ارتقای STON.fi دوباره بازبینی شود. بنابراین، انتخاب بین صرفهجویی جزئی در gas و ریسک از کار افتادن بیخبر (silent breakage) است.
آنچه باید در ادامه زیر نظر داشته باشید
- اعلانهای ارتقای روتر. STON.fi تغییرات آتی روتر را در کانال توسعهدهندگان خود منتشر میکند. مشترک شدن در این فیدها به شما اجازه میدهد قبل از سوئیچ به mainnet، آدرس جدید را در یک sandbox از پیش تست کنید.
- بازبینی پارامترهای کارمزد. از آنجایی که درصدهای کارمزد میتوانند برای پاسخ به شرایط بازار تنظیم شوند، یک فراخوانی دورهای از endpoint پیکربندی را در هر سرویس مانیتورینگ بگنجانید.
- انتشار نسخههای جدید SDK. نسخههای جدید SDK اغلب شامل اصلاح باگهایی برای موارد خاصی است که پس از لانچ در mainnet کشف شدهاند. بهروز نگه داشتن SDK به اندازه بهروزرسانی آدرس روتر اهمیت دارد.
نکته کلیدی روشن است: یک سواپ که «در مرحله تست کار میکند»، لزوماً به معنای تجربهای امن در mainnet نیست. با دریافت تمامی مقادیر حیاتی — از آدرس router گرفته تا جدول کارمزدها (fee schedule) — از STON.fi API زنده، و با آزمایش دقیق مسیرهای خطا پیش از آنکه کاربران با رابط کاربری مواجه شوند، توسعهدهندگان میتوانند از داراییهای کاربران محافظت کرده و اعتماد آنها را در مرحله نهایی انتقال به محیط production حفظ کنند.
Source: https://dev.to/web3kd/the-last-mile-taking-a-stonfi-integration-from-test-network-to-real-users-2ho0