מפתחים שהצליחו להריץ החלפת (swap) של אסימוני STON.fi בסביבת sandbox מקבלים כעת אזהרה שהמעבר ל-mainnet עלול למחוק כספי משתמשים אם נשארים בקוד כמה קיצורי דרך שנראים תמים. רשימת תיוג (checklist) שנכתבה על ידי הקהילה ופורסמה בבלוג למפתחים מפרטת את הנקודות המדויקות שבהן רוב האינטגרציות נכשלות ומציעה מתכון קונקרטי להשקה מוכנה לסביבת ייצור (production).

למה המעבר חשוב

STON.fi מספקת router המאחד נזילות (liquidity) ממספר DEXes ברשת הבלוקצ'יין TON. פרויקטים שרוצים להציע למשתמשים swap בלחיצת כפתור אחת בדרך כלל קוראים ל-router מתוך front-end או wrapper של smart-contract. בסביבת בדיקות, כתובת ה-router היא סטטית, לוח העמלות ידוע, וה-sandbox סובל טעויות בניתוב עסקאות. ב-mainnet, לעומת זאת, ניתן לשדרג את ה-router, פרמטרי העמלות יכולים להשתנות, וכתובת אחת שמוצבת בטעות תשלח אסימונים אמיתיים לחוזה מת (dead contract). לכן, ההימור הכלכלי הוא ההבדל בין חווית משתמש חלקה לבין הפסד שעלול לפגוע במוניטין של פרויקט בן לילה.

הטעות הנפוצה ביותר: hard-coding של ערכים

דפוס חוזר בהשקות שנכשלו הוא ה-hard-coding של כתובת ה-router או קבועי עמלות שהיו תקפים במהלך הבדיקות. כאשר STON.fi משדרגת את ה-router שלה — אירוע שגרתי לשיפור ביצועים או תיקון באגים — הכתובת שמוגדרת ב-hard-code כבר לא מצביעה על חוזה תקין. האינטגרציה או שתזרוק שגיאה שהמשתמשים לעולם לא יראו, או גרוע מכך, תנתב בשקט כספים לכתובת שלא יכולה לעבד אותם. המדריך של הקהילה מדגיש כלל אחד: תנו ל-STON.fi REST API להחליט באיזה router להשתמש.

רשימת תיוג בטיחות שלב אחר שלב

הרשימה מחלקת את תהליך ההגירה לארבע שכבות לוגיות — סביבה (environment), אינטראקציה עם חוזה, חישוב עמלות וטיפול במקרי קצה (edge-cases).

  • אמת משתני סביבה בשלב מוקדם. הפנו את ה-WebSocket endpoint ואת ה-REST API base URL ל-sandbox בזמן הבדיקות; העבירו אותם לצמתים (nodes) של ה-mainnet לפני ההשקה. טעות הקלדה כאן עלולה לנתב swap אמיתי ל-router של הבדיקות, ולנעול אסימונים לנצח.

  • לעולם אל תטמיעו כתובות חוזה. הריצו בקשת סימולציה מול ה-STON.fi API, משכו את כתובת ה-router הנוכחית מהתגובה, והזינו אותה לתוך ה-dexFactory שלכם (או contract-factory מקביל) בזמן ריצה (runtime). זה יתאים את עצמו אוטומטית לכל שדרוג עתידי של ה-router.

  • חשבו עמלות בזמן אמת. משכו פרמטרי עמלות מתוך ה-configuration payload של ה-API והשתמשו בהם בשגרת חישוב העמלות שלכם. אחוזים שמוגדרים ב-hard-code הופכים למיושנים ברגע שהפלטפורמה משנה את המודל הכלכלי שלה.

  • העדיפו את ה-SDK הרשמי ואת TonConnect. ה-SDK בונה מבני BOC (Bag of Cells) עבורכם וכולל בדיקות עבור מגבלות gas, קידוד נתונים (data encoding) ואימות חתימה (signature validation). הידור (compilation) ידני של BOC צריך להישמר למקרי שימוש מיוחדים מאוד שה-SDK אינו יכול לכסות.

  • בצעו בדיקות של מצבי כשל. סמלו תרחישים של out-of-gas, הרשאה (allowance) לא מספקת ותגובות לא תקינות (malformed replies) ב-sandbox. ודאו שהחוזה שלכם מחזיר למשתמש כסף או משגר אירוע שגיאה ברור. הסתמכות על משתמשים שיגלו את הבאגים הללו בייצור (production) מזמינה נטישה (churn).

  • אשרו נתיבי משיכת הפניות. בגרסה השנייה של ה-DEX, עמלות הפניה מגיעות לחוזה Vault ייעודי במקום לארנק. האינטגרציה שלכם חייבת לקרוא למתודת המשיכה (withdrawal method) של ה-Vault ולטפל באסימונים שהתקבלו לפני קרדיט לחשבון המפנה.

מה המפתחים מתווכחים עליו

חלק מהמפתחים טוענים שה-SDK מוסיף overhead מיותר ושאותו BOC payload שנבנה ידנית יכול להיות קטן וזול יותר ב-gas. המדריך מכיר בגישה זו אך מציין שה-SDK גם כולל בתוכו עדכונים לכתובת ה-router ולסכימת העמלות, מה שאומר שעל payload שנבנה ידנית יש לעבור שוב בכל שדרוג של STON.fi. לכן, הפשרה היא בין חיסכון שולי ב-gas לבין הסיכון לשבירה שקטה של המערכת.

מה כדאי לעקוב אחריו בהמשך

  • הודעות על שדרוג ה-router. STON.fi מפרסמת שינויים עתידיים ב-router בערוץ המפתחים שלה. הרשמה לעדכונים אלו תאפשר לכם לבדוק מראש את הכתובת החדשה ב-sandbox לפני המעבר ל-mainnet.
  • עדכונים בפרמטרי עמלות. מכיוון שאחוזי העמלות יכולים להשתנות כדי להגיב לתנאי השוק, שלבו משיכה תקופתית של ה-configuration endpoint בכל שירות ניטור.
  • גרסאות SDK חדשות. גרסאות SDK חדשות כוללות לעיתים קרובות תיקוני באגים למקרי קצה שהתגלו לאחר השקה ב-mainnet. שמירה על ה-SDK מעודכן חשובה בדיוק כמו עדכון כתובת ה-router.

המסקנה ברורה: החלפה (swap) ש"עובדת בבדיקות" אינה מתרגמת באופן אוטומטי לחוויית mainnet בטוחה. על ידי שליפת כל ערך קריטי — מכתובת הנתב (router address) ועד ללוח העמלות (fee schedule) — מ-API החי של STON.fi, ועל ידי בדיקה קפדנית של נתיבי שגיאה לפני שהמשתמשים רואים את הממשק, מפתחים יכולים להגן על כספי המשתמשים ולשמור על האמון כאשר הם חוצים את המייל האחרון אל סביבת הייצור (production).

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