פיתוח אפליקציות TON: היכן הלוגיקה נשברת
הלוגיקה של אפליקציית TON נשברת לא בחיבור הארנק, אלא במקום שבו הממשק והשרשרת מתחילים לחיות לפי שעונים שונים. המשתמש חתם על עסקה, האפליקציה כבר הציגה "הצלחה", אך החוזה החכם мог לדחות את ההודעה או להחזיר אותה. לאחר מספר דקות היתרה באפליקציה וברשת מתפצלת — וזה הפנייה הראשונה לתמיכה.
התקלה השכיחה ביותר — חוסר סנכרון בין מצב האפליקציה לרשת. נתוני החוזה החכם משתנים רק לאחר שהעסקה נכללת בבלוק, בעוד הממשק מגיב ללחיצת כפתור. זה מטופל בשכבת אישורים נפרדת: השירות מאזין לשרשרת, משווה אירועים לבקשות, ורק אז מסמן את הפעולה כמבוצעת. בלעדיו, ניתוק הסשן נראה ללקוח כאובדן כספים.
נקודת הכשל השנייה בלוגיקת בלוקצ'יין — שליחה חוזרת. הקשר נותק לאחר החתימה, האפליקציה לא יודעת אם ההודעה נשלחה, והמשתמש לוחץ שוב — כך נוצרים כפילויות של זיכויים.
לא טיימר מציל אותנו, אלא הסתמכות על המספר הסידורי של הארנק: שליחה חוזרת עם אותו מספר אינה יוצרת פעולה שנייה, אלא מחזירה את התוצאה הקודמת. אחרת, חיובים המוניים צריכים להיבדק ידנית — חלק מהכתובות נדחות, והתמונה בהנהלת החשבונות אינה מתאמתת.
את כל הנקודות הללו אנו מנתחים לפני שורת הקוד הראשונה: היכן דרושה שכבת אישורים, כיצד מטופלים החזרים, ומה לעשות במקרה של חבילה המבוצעת חלקית. להלן — כיצד זה נסגר בפיתוח אפליקציות TON.
מה נותנת השקה צפויה של מוצר בלוקצ'יין
חוזים חכמים, צד שרת וחיבור ארנקים — אנו מתכננים אותם כמעגל אחד; אז האפקט נראה במטריקות, ולא במצגת.
עדכון הלוגיקה אנו מוציאים דרך הפרדה לליבה בלתי ניתנת לשינוי ולמודול ניתן להחלפה: הכתובת וההיסטוריה נשמרות, הגרסה החדשה מתחברת ללא הגירת משתמשים, ולכן מהתיקון ועד לשחרור עוברות שעות, ולא שבועות של תיאומים והנפקות מחדש ידניות.
המודל האסינכרוני של TON סולח על שגיאות רק למי שצפה אותן מראש: מטפלים אידמפוטנטיים, יומן אירועים ושליחה חוזרת עם אותו מזהה אינם מאפשרים לפעולה להיתקע.
שיעור העסקאות במצב לא מוגדר בעומס שיא יורד לכמה אחוזים בודדים, וסוג שלם של כשלים — מסד הנתונים לא תואם לרשת — נעלם יחד עם בדיקה ידנית.
העמלות מפסיקות להיות הפתעה כאשר עלות החישוב והאחסון מוערכת לפני השליחה. הגבלה על ביצוע, החזר יתרה שלא נוצלה ורזרבה לאחסון הופכים את החיוב לצפוי: הפעולה אינה נכשלת בגלל חוסר במשאבים, והתנהגות הרשת נראית בניטור לפני שהמשתמש מבחין בכך.
תשלומים אנו מבצעים אוטומטית ברמת החוזה: קליטה דרך חיבור ארנק, אישור לפי אירוע מהרשת, חלוקת סכומים וניכוי עמלה ללא פעולות ידניות.
פיתוח אפליקציות TON בצורה כזו נותן לא "טכנולוגיה אופנתית", אלא מוצר שבו עדכונים יוצאים במהירות, פעולות נסגרות, והחישובים מתאמתים ללא עבודת חשבונאות ידנית.
אפשרויות יישום: בנייה עצמית או היברידי
בחירת האפשרות קובעת כמה לוגיקה נשארת בשליטתנו והיכן עוברים גבולות הכשל. להלן — ארבע סכמות, שביניהן באמת בוחרים בעת השקת אפליקציה על TON, עם המגבלות הכנות של כל אחת.
| אפשרות | מתי מתאים | מגבלות |
|---|---|---|
| חוזים מאפס | לוגיקה לא טיפוסית: חלוקת נתחים, עסקה עם החזקת כספים, רישום זכויות עצמאי | יציאה לרשת ארוכה יותר; לפני פרסום נדרש ביקורת, ותיקונים לאחר מכן — רק דרך הגירת מצב |
| התאמה של פתרונות פתוחים | תסריטים טיפוסיים: הנפקת טוקן, החלפה, לוגיקה פשוטה — הקוד כבר נבדק על ידי הקהילה | עוברים בירושה הנחות ותנאי רישיון של אחרים; כללים לא סטנדרטיים יש להתאים למבנה זר |
| היברידי: חוזה וצד שרת | חלק מהלוגיקה פרטי, לרשת מועברים רק החישוב וקיבוע התוצאה | השרת — נקודת כשל יחידה; נדרש מעגל גיבוי, יומן פעולות ושחזור מצב |
| ללא חוזים עצמאיים | בדיקת ביקוש, שירותים פנימיים, אינטגרציה עם פתרונות שכבר פרוסים | אין שליטה על עמלות ומגבלות; את הכללים משנה בעל החוזה, ולא אתם |
הגבולות בין הסכמות אינם נוקשים: פרויקט לעיתים קרובות מתחיל בפתרונות מוכנים, וככל שהלוגיקה גדלה, עובר להיברידי. תאימות אנו מניחים מראש — כתובות, פורמטי הודעות ומבנה ארנק מתוארים כך שההעברה לא תשבור משתמשים שכבר מחוברים.
שלבי יישום: מפירוק המשימה ועד מסירה
את העבודה אנו מנהלים באיטרציות: לאחר כל שלב נשאר חפץ שאפשר לראות ולערער עליו, ולא "נראה מוכן להשקה". הסדר הוא כזה ששגיאות במודל הנתונים, בהרשאות ובמגבלות יצופו לפני שהן מתקבעות בחוזה — שינוי לוגיקה בשלב מאוחר הוא היקר ביותר.
- ניתוח תסריטים. אנו מפרקים את המוצר לפעולות: מה חייב להיות ניתן לבדיקה ובלתי ניתן לשינוי, מה חי במסד נתונים רגיל, היכן נדרשת חתימת משתמש. בפלט — מפת פעולות עם חלוקה לאזורי אחריות.
- תכנון סכמה ומודל נתונים. כתובות, תפקידים, עמלות, מגבלות, חלוקת לוגיקה בין חוזים, התנהגות בשליחה חוזרת. מתקבעים את הסכמה בטקסט ובתרשים לפני שורת הקוד הראשונה.
- בניית חוזים. מימוש עם כיסוי בבדיקות לא רק של happy path, אלא גם של גבולות: סכומים אפסיים, קריאות חוזרות, חוסר במשאבים, מועדים.
- חיבור לצד שרת ולארנק. זרימת תשלומים, אישורים, ניסיונות חוזרים בניתוק קשר, הצגת סטטוס הפעולה בחשבון המשתמש.
- בדיקה ברשת טסט. הרצה של מסלול מלא על עותק של סביבה אמיתית: מחיבור ארנק ועד משיכה והחזר כספים.
- קבלה ומסירה. משווים את התוצאה לתסריטים, מריצים צ'ק-ליסט אבטחה, מוסרים מאגרי קוד, סכמות, הוראות פריסה וחזרה לאחור, ומלמדים את הצוות שלכם.
ערכת מסירה: קוד, סכמות ותקנונים
לאחר השחרור, הערך העיקרי הוא בכך שאת המוצר ניתן לקרוא ולשחזר ללא המחברים. לכן מסירה היא לא ארכיון קבצים, אלא ערכה עובדת: קוד עם היסטוריה, סכמות פריסה, מדיניות גישה ותקנונים שלפיהם הצוות שלכם פועל באופן עצמאי. להלן — מה בדיוק אתם מקבלים לידיים.
- קוד המקור של החוזים במאגר שלכם: היסטוריית שינויים, ענפי שחרור, גישה למספר עובדים — בלי עותק יחיד במחשב נייד של מישהו.
- סכמות פריסה: מה נמצא היכן, סדר הפרסום, תלויות בין חוזים לשירותים חיצוניים.
- מדיניות גישה ותפקידים: מי מחזיק במפתחות, אילו פעולות דורשות אישור שני, כיצד נשללת גישה.
- תיאור תסריטים: הנפקה, העברה, משיכת כספים, טיפול במצבים שנויים במחלוקת — עם רשימת אירועים הנכללים ביומן.
- תקנון עדכון: כיצד מכינים תיקון, כיצד בודקים ברשת טסט, באיזה סדר מפרסמים.
- תקנון חזרה לאחור: כיצד להחזיר מצב קודם, מה קורה עם פעולות שכבר בוצעו.
- ערכת תיעוד לליווי: מפת קוד, נקודות אינטגרציה, תקלות טיפוסיות וסדר פעולות.
פרוטוקול המסירה — שלב נפרד: ניתוח משותף עם המהנדסים שלכם, מענה על שאלות ותקופה שבה ניתן לפנות בנוגע לקוד שנמסר.
מקרה בוחן: חוזים חכמים ב-TON לשירות מנויים
פעולות ידניות אצל הלקוח — שירות מנויים לגישה לתוכן — נראו כך: רואה החשבון השווה תקבולים, המנהל סימן חידוש באדמין, הגישה הופעלה לאחר מספר שעות, לעיתים למחרת. על כל תשלום היו 3-4 פעולות ידניות, ופערים בדפי חשבון טופלו בהתכתבות עם המנוי.
מה הועבר לחוזה
חיוב, חידוש אוטומטי והחזר יתרה בביטול הפכו לכללים בקוד, ולא לתקנון של עובד. את התשלום בממשק בנינו על TON Connect: הארנק מתחבר ישירות מהאפליקציה, וסטטוס המנוי מתעדכן מיד לאחר אישור העסקה — אין יותר שער נפרד ואישור ידני.
אירועי החוזה נסרקים על ידי צד השרת ומועברים לחשבון האישי ולמערכת החיוב. הזיכויים בנויים כך שעיבוד חוזר אינו מכפיל את התשלום בעת ניתוק קשר, ומצב המנוי תמיד משוחזר מהיסטוריית הבלוקצ'יין.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| זמן זיכוי | שעות, לעיתים יממה | עשרות שניות |
| פעולות ידניות לתשלום | 3-4 | 0 |
| פניות לתמיכה בנושא תשלום | קו בסיס | מינוס ~70% |
| התאמת תקבולים | עובד נפרד | לא נדרש |
שיעור הפניות לתמיכה בנושא תשלומים וחידושים ירד בכ-70% — עיקר השאלות היה בדיוק על "הכסף עבר, הגישה לא הגיעה". ביטול והחזר יתרה המשתמש עושה כעת בעצמו בחשבון, והצוות לא מחזיק אדם לבדיקה ידנית.
במה שונה חוזה חכם מחתימה על השרת?
חתימה במפתח פרטי מאשרת שהפקודה נשלחה על ידי בעל הארנק, אך כשלעצמה היא אינה יוצרת רשומת בעלות. הרישום נשאר במסד נתונים בשרת: מי, מה ולמי העביר, נקבע על ידי קוד האפליקציה ומנהל הגישה למסד נתונים זה. המשתמש סומך על החתימה במידה שבה הוא סומך על הפלטפורמה.
חוזה חכם מעביר את המצב לרשת: יתרות, בעלים, מגבלות וכללי העברת זכויות נמצאים במרשם פתוח, והבדיקה מבוצעת על ידי צמתי רשת TON, ולא על ידי השרת שלכם. לא ניתן לשכתב את התוצאה בלי להשאיר עקבות פומביות.
האמון בחתימה מוחלף כאן בבדיקת קוד, והעומס על הליווי משתנה: במקום הרחבת מסד נתונים — דיוק הלוגיקה, כי טעות בחוזה פרוס אי אפשר לתקן בעדכון רגיל.
חוזה אינו נדרש במקום שבו הערך סגור בתוך הפלטפורמה: נקודות פנימיות ללא משיכה, רישום פרטי, תרחישים שעבורם חזרה לאחור של פעולה היא התנהגות נורמלית.
כאן מספיקה בדיקת חתימה בצד השרת: הכללים משתנים בשחרור אחד, הלוגיקה נשארת ניתנת לשינוי, ואחסון המצב במרשם אינו מוסיף לכם עלויות ואינו דורש מנגנון עדכון.
ההסתעפות נפתרת לפי שאלה אחת: האם המשתמש צריך למשוך נכס או להוכיח זכות עליו ללא השתתפותכם. אם כן — המצב והכללים עוברים לחוזה, וצד השרת הופך לחלון ראווה ושכבת חישוב עם מטמון ואנליטיקה. אם לא — חתימה ומסד הנתונים שלכם נותנים את אותה תוצאה מהר יותר ועם פחות החלטות בלתי הפיכות.
ספקות טכניים: ארנקים, כשלים, עדכונים
ספקות בפרויקטים של TON נוגעים בדרך כלל לא לבלוקצ'יין עצמו, אלא לחיבורים: מי מחזיק במפתחות בעת חיבור ארנק, מה רואה המשתמש בעת כשל רשת וכיצד לעדכן לוגיקה מבלי לאבד נתונים שנצברו. להלן — תרחישים שנבדקים לרוב בקבלה.
האם האפליקציה מקבלת גישה למפתחות הארנק?
לא. החיבור אינו משמורן (non-custodial): המפתח הפרטי אינו עוזב את הארנק, האפליקציה מקבלת כתובת ציבורית וחתימה של פעולה ספציפית. את העסקה מרכיב הבקאנד, אך המשתמש מאשר — איננו מבקשים ביטוי סודי ואיננו שומרים אותו בשרת. הסשן קשור לדומיין, לכן לא ניתן להחליף את כתובת הנמען בצד האפליקציה.
מה קורה אם הרשת אינה זמינה או שהעסקה נכשלה?
הצלחה נקבעת לפי המצב ברשת, ולא לפי תגובת ה-API — האפליקציה לא תציג זיכוי שאינו קיים. כל פעולה מקבלת מזהה, שליחה חוזרת לאחר ניתוק יוצאת עם אותו מספר, לכן חיוב כפול לא נוצר. בתור רואים מה נשלח, מה ממתין לאישור ומה דורש בירור.
האם ניתן לעדכן חוזה בלי לאבד נתוני משתמשים?
כן, אם הלוגיקה והמצב מופרדים: הנתונים נמצאים באחסון נפרד, והחוזה הפעיל פונה אליו בכתובת קבועה. בעת שחרור גרסה חדשה הקוד משתנה, הרשומות נשארות. את העדכון מריצים על עותק של הרשת, ואת הגרסה הקודמת מחזיקים מוכנה לחזרה לאחור — אם ההתנהגות שונה, חוזרים בלי לאבד היסטוריה.
נדון במשימה ונחזור עם תוכנית עבודה
דיוק ההערכה נקבע לפי נתוני המקור, ולא לפי מהירות התגובה. אם יש לכם תיאור של תרחיש וגישה לקוד הנוכחי, נחזור עם סכמת פתרון ולוחות זמנים לאחר שיחת זום אחת; אם אין נתונים, חלק נאסוף בעצמנו בשלב הניתוח — זה מאריך את ההכנה, אך אינו משנה את התוצאה. כדי לא לנחש, אנו צריכים מכם:
- תרחיש: מה עושה המשתמש, אילו פעולות ובאיזה סדר, מה נחשב לסיום מוצלח של הפעולה.
- תפקידים והרשאות: מי חותם על פעולות, היכן מאוחסנים המפתחות, האם נדרשים ריבוי חתימות ומגבלות על סכומים או תדירות.
- קוד נוכחי: מאגר, מצב בנייה, כיסוי בבדיקות, פגמים ידועים ומקומות שבהם האפליקציה כבר סוטה מהתיעוד.
- קשרים חיצוניים: שירותי תשלום, בורסות, מקורות נתונים — לאן יוצאים ומאיפה מגיעים אירועים.
- עומס: מספר משתמשים צפוי, תקופות שיא, זמן אישור פעולה מותר.
- מגבלות: מעגל סגור, דרישות שירות אבטחה, האם נדרשת רשת נפרדת לבדיקות.
- החלטות בצד שלכם: מי מקבל החלטות במחלוקות וכמה מהר נותן משוב על שלבים.
לאחר מכן הסדר הוא כזה: שיחת זום של 40–60 דקות, ואחריה סכמת פתרון עם חלוקה לשלבים, הרכב העבודה ולוחות זמנים, ורק לאחר תיאום — התחלה עם הגרסה הראשונה הניתנת לבדיקה.