חוזים חכמים ב-FunC ל-TON: מהרעיון ועד ל-Mainnet
החלטתם לבנות על TON. כתבתם בעבר ב-Solidity. עכשיו אתם מסתכלים על FunC, תוהים למה קיים Cell ואיך לטפל בהודעות bounce. עקומת הלמידה תלולה: TVM מבוסס מחסנית, מודל אחסון מבוסס תאים, והעברת הודעות אסינכרונית. במשך 5 שנים יישמנו יותר מ-120 חוזי TON ואנחנו יודעים לנווט בשטח הזה מבלי לאבד כספים. החוזים שלנו צורכים בממוצע 25% פחות גז מאשר יישומי ייחוס — תוצאה של שנים של אופטימיזציה.
לפי התיעוד של קרן TON, Jetton הוא תקן הטוקנים ברשת TON.
איך הודעות אסינכרוניות עובדות ב-TON?
ב-Solidity Cell הוא קריאה סינכרונית בתוך טרנזקציה אחת. ב-TON הכל שונה: חוזים מתקשרים באמצעות הודעות, כל אחת מעובדת בטרנזקציה משלה. אם חוזה A שולח הודעה לחוזה B, ששולח הודעה לחוזה C — אלה שלוש טרנזקציות נפרדות בשלושה בלוקים נפרדים. זה שובר דפוסים מוכרים ודורש מכונת מצבים מפורשת באחסון.
TVM ו-Cell — לא מה שאתם רגילים אליו
ב-EVM חוזה הוא bytecode, אחסון הוא key-value עם משבצות של 32 בתים. ב-TVM החוזה מאוחסן כעץ של אובייקטי Cell. כל Cell מחזיק עד 1023 ביטים של נתונים ועד 4 הפניות ל-Cells אחרים. האחסון של החוזה הוא עץ Cell שנטען כולו בכל קריאה ונשמר כולו בחזרה. יש לכך השלכות קונקרטיות: אין התנגשויות משבצות כמו ב-proxy של EVM, אבל קריאת מבנים מקוננים עמוק דורשת ניתוח רציף באמצעות begin_parse() / load_uint() / load_ref(). תשכחו את סדר השדות במהלך deserialization — תקבלו נתונים פגומים ללא שגיאת קומפילציה.
למה טיפול בהודעות bounce הוא קריטי לאבטחה?
הודעת bounce היא המקבילה להחזר כספי כאשר מתרחשת שגיאה. אם חוזה המקבל מבצע revert, TON שולח אוטומטית הודעת bounce לשולח עם הכספים הנותרים. אם השולח לא מטפל ב-bounce — הכספים נתקעים לנצח. ראינו פרויקטים שמפסידים עשרות אלפי TON בגלל מחסור במטפל bounce. במהלך התכנון אנחנו תמיד מטמיעים מכונת מצבים ומנגנוני timeout.
מודל הגז ב-TON
ל-TON אין מגבלת גז לטרנזקציה כמו ב-EVM. במקום זאת, יש דמי אחסון — החוזה משלם על אחסון המצב שלו כל שנייה. חוזה עם אחסון גדול ויתרת אפס יקפא בסופו של דבר. יש להתחשב בכך בתכנון: חוזים שאוגרים נתונים (למשל, ארנקי jetton בודדים) זקוקים למנגנון חידוש או ליתרת מינימום. אופטימיזציית אחסון היא אחת מהליבות המקצועיות שלנו.
איך להימנע מאובדן כספים ב-bounce: צעד אחר צעד
- יישמו פונקציית bounce נפרדת לפי op-code.
- תעדו במפורש את כל מטפלי ה-bounce בקוד.
- השתמשו במכונת מצבים באחסון עם סטטוסים: pending, processing, completed, failed.
- הוסיפו timeout: אם פעולה נשארת ב-processing יותר מ-N שניות — rollback אוטומטי.
- ספקו מטפל נפרד לכל bounce.
דילוג על טיפול ב-bounce הוא טעות אופיינית למתחילים. חוזה שולח TON לחוזה אחר, החוזה הזה מבצע revert, המטבעות חוזרים כהודעת bounce. אם השולח לא מטפל ב-bounce — המטבעות נעלמים.
TON לעומת EVM למשימות פיתוח
| תכונה | TON / FunC | EVM / Solidity |
|---|---|---|
| מודל ביצוע | הודעות אסינכרוניות | קריאות סינכרוניות |
| אחסון נתונים | עצי Cell | משבצות key-value |
| שפה | FunC / Tact | Solidity / Vyper |
| תקני טוקנים | TEP-74 (Jetton), TEP-62 (NFT) | ERC-20, ERC-721, ERC-1155 |
| פעולות אטומיות | לא (טרנזקציות מרובות) | כן (טרנזקציה אחת) |
| דמי אחסון | כן (תקופתיים) | לא |
| מהירות טרנזקציות | <5 שניות | 12-60 שניות (Ethereum) |
| כלי ביקורת | סט מוגבל | Slither, Mythril, Echidna |
| קיבולת TPS | 1,000,000 TPS (sharded) | 15-30 TPS (Ethereum) |
הטבלה מראה ש-TON אינו "טוב יותר" או "גרוע יותר" — הוא שונה. למשימות עם TPS גבוה וטרנזקציות זולות (תשלומים, gamefi, מיני-אפליקציות בטלגרם) הארכיטקטורה של TON היא אופטימלית. TON מהיר פי 10 מ-Ethereum בתפוקה.
איך אנחנו כותבים חוזים ב-FunC
ערכת הפיתוח
Blueprint — הכלי הסטנדרטי לפיתוח ובדיקת חוזי TON. הוא מספק סביבה לביצוע TVM מקומי, בדיקות TypeScript וסקריפטי פריסה הניתנים להתאמה אישית. אנחנו משתמשים ב-toncil לפרוטוטייפינג מהיר. לפרויקטים חדשים אנחנו בוחרים ב-Blueprint. Tact — שפה ברמה גבוהה מעל FunC, המורידה את חסם הכניסה; אנחנו משתמשים בה לפרויקטים שבהם המהירות חשובה יותר משליטה מקסימלית ב-bytecode. TEP-74 — תקן ה-Jetton שעליו אנחנו מבססים טוקנים.
תקנים רשמיים: TEP-74 (Jetton), TEP-62 (NFT), TEP-64 (metadata). אין מקבילה ל-OpenZeppelin ב-TON — קיימים יישומי ייחוס מקרן TON, ואנחנו משתמשים בהם כבסיס.
טעות Jetton אופיינית
ארכיטקטורת Jetton היא sharded: לכל משתמש יש חוזה ארנק משלו. העברה היא שתי הודעות מהארנק של השולח לארנק של המקבל. הטעות הסטנדרטית: חוזה המקבל לא מיישם מטפל contractA.functionB() — ה-jettons מגיעים אבל מצב החוזה לא משתנה.
תהליך הפיתוח של חוזה TON
- תכנון זרימת הודעות (3-5 ימים). לפני כתיבת קוד — דיאגרמת הודעות מלאה: op-codes, כיוונים, תרחישי bounce.
- פיתוח ב-FunC + בדיקות TypeScript (1-3 שבועות). בדיקות Blueprint מכסות את הנתיב התקין ואת כל תרחישי ה-bounce (כיסוי של 80%+).
- סקירת מבנה האחסון. אנחנו מוודאים את סדר ה-serialization/deserialization של Cells, ואת תקינות ה-bounce.
- פריסה ל-testnet → mainnet. אימות קוד באמצעות TON Verifier.
הערכות מורכבות וזמנים
| סוג פרויקט | ציר זמן | הערה | עלות משוערת |
|---|---|---|---|
| Jetton בסיסי (TEP-74) | 3-5 ימים | חוזה סטנדרטי עם לוגיקה מינימלית | $5,000 - $7,000 |
| אוסף NFT עם לוגיקה מותאמת | 1-2 שבועות | TEP-62, metadata, תמלוגים | $8,000 - $15,000 |
| פרוטוקול DeFi עם חוזים מרובים | מ-4 שבועות | מכונת מצבים, אינטגרציה, ביקורת | $20,000 - $50,000 |
| אינטגרציה עם מיני-אפליקציית טלגרם | +3-7 ימים | באמצעות tonconnect | $3,000 - $5,000 |
מה כלול בעבודה
- קוד מקור ב-FunC/Blueprint עם הערות
- בדיקות TypeScript (כיסוי של 80%+)
- תיעוד על זרימת הודעות ומטפלים
- הוראות פריסה (testnet + mainnet)
- תמיכה במהלך הפריסה וההשקה הראשונית
- ביקורת חוזה (אופציונלי)
צרו קשר כדי להעריך את הפרויקט שלכם. קבלו ייעוץ חינם על ארכיטקטורת החוזה שלכם. הזמינו פיתוח היום — נכין הצעה מותאמת לארכיטקטורה שלכם. איכות מובטחת וניסיון מוכח ביותר מ-120 פרויקטים.