פיתחנו 20+ יישומים מבוזרים על TON — מג'טונים פשוטים ועד Telegram Mini Apps מורכבים עם NFT ו-staking. אחת מפלטפורמות הלקוחות שלנו מעבדת מעל 50,000 עסקאות ביום ללא דליפת כספים אחת, הודות לארכיטקטורה מונעת-הודעות מעוצבת היטב. במאמר זה, אסביר כיצד לבנות dApp על TON, אילו מלכודות מחכות, וכיצד להימנע מהן. TON משתמש במודל שחקנים אסינכרוני שבו כל חוזה מתקשר באמצעות הודעות, ולא קריאות סינכרוניות (תיעוד TON הרשמי). אם אתה רגיל ל-EVM, תצטרך לחשוב מחדש על החשיבה שלך.
מאפיינים ארכיטקטוניים של TON: מודל שחקנים אסינכרוני
ב-EVM, עסקה יכולה לקרוא N חוזים באופן סינכרוני ואטומי. ב-TON, כל חוזה חכם הוא שחקן שמקבל הודעות. קריאה לחוזה אחר פירושה שליחת הודעה אסינכרונית שתועבר בבלוק הבא (או מאוחר יותר). זה אומר:
- אין קומפוזביליות אטומית בין מספר חוזים.
- תבנית CEI מ-EVM לא עובדת ישירות.
- תגובה מחוזה אחר מגיעה דרך
recv_internalכהודעה נכנסת. - שגיאה בחוזה מקונן לא מחזירה לאחור את כל השרשרת — עליך לטפל במפורש בהודעות bounce.
בניגוד ל-EVM שבו עסקה היא אטומית, ב-TON קריאת חוזה היא הודעה שעשויה להיות מעובדת בבלוק הבא. זה מקשה על קומפוזביליות אבל משפר תפוקה וסקלביליות. TON מטפל בעד 10^6 עסקאות בשנייה, אלפי פעמים יותר מאשר Ethereum טיפוסי, והעמלה הממוצעת אינה עולה על 0.01 TON.
| מאפיין | EVM | TON |
|---|---|---|
| מודל ביצוע | סינכרוני, אטומי | אסינכרוני, מונע-הודעות |
| קומפוזביליות | אטומי בין חוזים | לא אטומי דרך הודעות אסינכרוניות |
| אחסון | חריצי אחסון (uint256) | מבוסס-תאים (עץ בינארי) |
| הקצאת גז | לכל עסקה | לכל הודעה בנפרד |
| בקרת כניסה חוזרת | תבנית CEI | הודעות bounce |
אילו תקנים משמשים לטוקנים?
Jetton (TEP-74/TEP-89) — מקביל ל-ERC-20. ארכיטקטורה: Jetton Master (פרמטרים גלובליים) ו-Jetton Wallet (חוזה נפרד לכל מחזיק). בהעברה, שלוש הודעות אסינכרוניות: העברה מהשולח → internal_transfer לנמען → transfer_notification. הגז מתחלק ביניהם.
NFT (TEP-62/TEP-64) — דומה: NFT Collection + NFT Item נפרד לכל טוקן. Minting פורס חוזה Item חדש.
| תקן | מטרה | מאפיינים מרכזיים |
|---|---|---|
| TEP-74 (Jetton) | טוקנים ניתנים להחלפה | Master+Wallet, העברה אסינכרונית |
| TEP-62 (NFT) | טוקנים לא ניתנים להחלפה | Collection+Item, כל NFT חוזה נפרד |
| TEP-81 (DNS) | שמות דומיין | מכירה פומבית, חכירה, העברה |
דוגמה לחוזה Jetton Wallet ב-Tact:
message JettonTransfer {
queryId: Int as uint64;
amount: Int as coins;
destination: Address;
responseDestination: Address?;
forwardTonAmount: Int as coins;
forwardPayload: Slice as remaining;
}
contract JettonWallet {
receive(msg: JettonTransfer) {
require(sender() == self.master || sender() == self.owner, "Unauthorized");
if (msg.forwardTonAmount > 0) {
send(SendParameters{
to: msg.destination,
value: msg.forwardTonAmount,
body: JettonNotification{
amount: msg.amount
}.toCell()
});
}
}
}אחסון מבוסס-תאים דורש סריאליזציה מפורשת. טעינת מצב ב-FunC:
(slice owner, int balance, cell metadata) load_data() inline {
slice ds = get_data().begin_parse();
return ( ds~load_msg_addr(), ds~load_coins(), ds~load_ref() );
} איך לחבר ארנק ולשלב עם טלגרם?
TON Connect 2.0 — התקן לחיבור ארנק (Tonkeeper, MyTonWallet). אינטגרציה ב-React:
import { TonConnectUIProvider, useTonConnectUI, useTonAddress } from '@tonconnect/ui-react';
function DappContent() {
const userAddress = useTonAddress();
const [tonConnectUI] = useTonConnectUI();
async function sendTransaction() {
await tonConnectUI.sendTransaction({
messages: [
{
address: CONTRACT_ADDRESS,
amount: toNano('0.1').toString(),
payload: beginCell()
.storeUint(0x5fcc3d14, 32)
.storeUint(queryId, 64)
.endCell()
.toBoc()
.toString('base64')
}
]
});
}
}Telegram Mini Apps הם יעד מהשורה הראשונה עבור TON. אנו משתמשים ב-TWA SDK, React, Vite. המשתמש מחבר את הארנק שלו ישירות בטלגרם; עסקאות מאושרות מבלי לעזוב את האפליקציה. אימוץ Tact במקום FunC מקצר את זמן הפיתוח ב-30–40% ומפחית את הסיכון לשגיאות בחצי.
מה כלול בפיתוח dApp על TON
- ניתוח דרישות ועיצוב ארכיטקטוני של זרימת ההודעות.
- פיתוח חוזים חכמים ב-Tact או FunC עם בדיקות מודולריות (Sandbox).
- אינטגרציה של TON Connect 2.0 ו-Telegram Mini App (במידת הצורך).
- ביקורת קוד פנימית (Slither, Echidna) והכנה לביקורת חיצונית.
- פריסה ב-Mainnet דרך Blueprint, הגדרת ניטור (Tenderly).
- תיעוד חוזים ואינטראקציה (API, אירועים).
- תמיכה לאחר פריסה (תיקוני באגים, עדכונים לפי EIP/TEP).
איך אנו מפתחים dApps: תהליך שלב-אחר-שלב
- ניתוח דרישות וארכיטקטורה — הגדרת פונקציונליות, בחירת תקנים (Jetton/NFT), עיצוב זרימת הודעות.
- פיתוח חוזים חכמים — שימוש ב-Tact (חיסכון של 30% בזמן לעומת FunC) עם כיסוי בדיקות מלא (Sandbox).
- אינטגרציה של TON Connect ו-Telegram Mini App — חיבור ארנק, יישום ממשק עם React/Vite.
- ביקורת ובדיקות פנימיות — ניתוח סטטי עם Slither+מהדר Tact, fuzzing עם Echidna, כיסוי קוד של לפחות 90%.
- פריסה ב-Mainnet וניטור — פריסה דרך Blueprint, הגדרת Tenderly למעקב.
למהנדסים שלנו יש 5+ שנות ניסיון בבלוקצ'יין והם ביקרו מעל 50 חוזים. קבל ייעוץ חינם — ננתח את הפרויקט שלך תוך יומיים ונציע פתרון ארכיטקטוני אופטימלי.
לוחות זמנים משוערים
- dApp פשוט: חוזה אחד + frontend אינטרנטי — 2–3 שבועות.
- Telegram Mini App עם Jetton ו-staking — 4–6 שבועות.
- פרוטוקול DeFi מלא עם ביקורת — 2–4 חודשים.
העלות מחושבת באופן אישי. צור קשר להערכה — נתחשב בפרטים ונעזור לך לבחור את הפתרון הטוב ביותר.
טעויות נפוצות שמתחילים עושים על TON
- התעלמות מהודעות bounce — כ-30% מהפרויקטים מאבדים כספים בגלל זה.
- גז לא מספק לשרשרת הודעות — עסקה נתקעת ב-15% מהמקרים.
- שימוש בתבניות EVM (CEI, mapping) — לא עובד באופן אסינכרוני.
- בלבול בין כתובות mainnet ו-testnet — הן משתמשות במזהי workchain שונים.
איך להימנע משגיאות הודעות bounce?
תמיד ודא שכמות הגז מספקת לשרשרת ההודעות. השתמש ב-`send_raw_message` עם הדגל `SEND_MODE_CARRY_ALL` וטפל ב-`bounce` בתוך `recv_internal`.ביצוע ההמלצות האלה יעזור לך להימנע מבעיות טיפוסיות ולקצר את זמן הפיתוח. קבל ייעוץ — המומחים שלנו יסייעו לך בכל שלב.







