פיתוח NFT על TON: היכן נשברת הנפקת קולקציה
הנפקת קולקציה על TON נשברת לא ברגע ההטבעה, אלא בהכנה: מטא-נתונים, מגבלה על מספר הפעולות בבלוק ותור העסקאות בארנק של הלקוח. פיתוח NFT על TON לכן מתחיל לא בקוד, אלא בבדיקת שלושת הצמתים האלה — בדיוק שם נמצאות השגיאות היקרות ביותר בהנפקת קולקציה.
מטא-נתוני הקולקציה — המקור הראשון לאי-סנכרון. כשכתובת הבסיס של האחסון, המספור ותוכן קבצי JSON נאספים ידנית, חלק מהטוקנים מקבלים תכונות או תמונות של אחרים, והמרקטפלייס שומר במטמון את מה שקרא פעם אחת: עדכון באחסון כבר לא מגיע לקונה.
אנחנו מייצרים מטא-נתונים ממקור אחד ומשווים את הקישור «טוקן — מספר — קובץ» לפני הטבעה, ולא אחרי התלונות הראשונות.
הצומת השני — החוזה החכם של הטוקן ותפוקת הרשת. ההטבעה יוצאת לא כפעולה אחת, אלא כחבילת הודעות, והמגבלה על מספר הפעולות בבלוק פוסלת חלק מהן או מותחת אותן בזמן: הקולקציה מונפקת חלקית, ומגלים זאת רק אחרי תחילת המכירות. גודל החבילה וסדר השליחה מחושבים מראש, עבור גודל הקולקציה הספציפי.
השלישי — תור העסקאות. הודעות מארנק אחד נשלחות לפי סדר קפדני, לכן בשליחה המונית התור נערם, ופעולה תקועה אחת חוסמת את כל הבאות אחריה. אנחנו בונים את תרשים ההנפקה כך שהתור לא ייתקע: מפזרים את השליחה, בודקים אישורים ומשאירים אפשרות חזרה לאחור עבור החלק שכבר הונפק בקולקציה.
מה נותן פרויקט עם ארכיטקטורת קולקציה נכונה
ארכיטקטורת הקולקציה פותרת שלושה דברים: כמה זמן אורכת ההנפקה הציבורית, האם התמלוגים מגיעים ליוצר לאחר מכירה חוזרת, ומה קורה כשבמקביל מגיעים אלפי ארנקים להטבעה. בקולקציית בדיקות שגיאות ברמה הזו לא נראות — הן מתגלות בהשקה, כשכבר מאוחר לשנות משהו.
הנפקה צפויה ותמלוגים בתוך החוזה
קולקציה על TON אנחנו בונים סביב חוזה רישום אחד עם הטבעה נדחית: המטא-נתונים והזכויות נמצאים במקום אחד, והטוקן נרשם ברגע הרכישה. זה מסיר את הסיבה העיקרית לזמן הנפקה «צף» — חוזה נפרד לכל עותק לא עומד בקצב התור.
התמלוגים מוגדרים בחוזה הקולקציה, לכן השוק המשני קורא אותם מנתוני הטוקן ולא יכול לעקוף אותם דרך הגדרות הפלטפורמה.
עמידות בביקוש שיא
שיא שובר קולקציות לא באמצעות לוגיקה, אלא באמצעות חזרות: שני קונים תובעים את אותו מספר, עיכוב בתגובה מעורר ניסיון חוזר, והמטא-נתונים לא תואמים את הטוקנים שהונפקו בפועל. הגבלת הנפקה לפי מספרים והטבעה חוזרת סוגרות את זה — בקשה חוזרת מחזירה עותק שכבר הונפק, ולא עותק שני.
סוג כשלים שבו מחצית מהקונים רואה שגיאת הנפקה, והשוק המשני לא מאנדקס את הקולקציה במשך שבוע, לא נוצר בתרשים כזה.
אפשרויות הנפקת קולקציה: השוואת גישות
את תרשים ההנפקה בוחרים לא לפי טעם: הוא קובע היכן נמצא מצב הקולקציה, כמה פעולות נדרשות להצבת הפריטים, ואיך המרקטפלייסים והארנקים יראו את הקולקציה.
ב-TON כתובת הפריט מחושבת מכתובת הקולקציה ומהמספר הסידורי, לכן התרשים נקבע לפני ההנפקה הראשונה — לא ניתן לשנות אותו לאחר מכירות, תישאר רק הנפקה מחדש.
ההבדל בין הגישות מתבטא בשלושה מקומות: עלות הצבת המלאי, מהירות הנפקה במקביל ותאימות לאינדקסרים של הפלטפורמות.
| אפשרות | מתי מתאימה | מגבלות הגישה |
|---|---|---|
| חוזה קולקציה אחיד | מלאי קטן, רשימת בעלים סגורה, פריטי שירות ובונוס | המצב ועלות הפעולות גדלים יחד עם מספר הפריטים; הנפקה המונית נתקעת במגבלה של עסקה אחת |
| חוזה נפרד לכל פריט | קולקציות ציבוריות עם תמלוגים ומסחר משני | יקר יותר בהתחלה, ההנפקה נעשית בחבילות הודעות; נדרש טיפול בכשלים חלקיים כדי שלא ייווצרו חורים במספור |
| הנפקה נדחית | מלאים גדולים, שבהם לא ידוע מראש כמה פריטים יהיו מבוקשים | המטא-נתונים חייבים להיות דטרמיניסטיים מראש, הבעלים והתמלוגים תלויים בתקינות העסקה הראשונה, וחלק מהפלטפורמות מציגות פריטים כאלה לא מיד |
בחירת התרשים היא פשרה בין עלות ההנפקה, צפיות המספור ותמיכת הפלטפורמות. אנחנו קודם מריצים את התרשים על קולקציית בדיקות: הנפקה, העברה, מכירה — ורק אחר כך קובעים את התצורה.
שלבי העבודה: מביקורת המשימה ועד מסירת הקולקציה
שלבי הפיתוח של קולקציית NFT כפופים לאי-הפיכות: לא ניתן לתקן חוזה בשקט לאחר פרסום, ושגיאה בלוגיקת ההנפקה מתגלה כבר כשהטוקנים עברו לשוק המשני. לכן כל בדיקה מתבצעת לפני שלב שלא ניתן לבטל, ולא אחריו.
- ביקורת המשימה. מפרקים את מודל ההנפקה: מלאי קבוע או מנות פתוחות, האם נדרשת הוספה, איך מחושבים התמלוגים, היכן נשמרים התמונות והתכונות. בפלט — תרשים תפקידים ומגבלות מוסכם איתכם.
- תכנון תרשים החוזים. מפרידים בין מה שנמצא בבלוקצ'יין לבין מה שנמצא באחסון חיצוני, ומתארים תרחישים: הנפקה, העברה, מכירה, שריפה. כאן גם קובעים אילו נתונים ייכנסו למטא-נתונים.
- פיתוח החוזים. כותבים חוזים לקולקציה ולטוקן נפרד לפי הענף העדכני של תקן TON — כך המרקטפלייסים והארנקים קוראים מטא-נתונים ותמלוגים בלי התאמות מצדם.
- בדיקת החוזה. מכסים בבדיקות הנפקה מעל המגבלה, הנפקה חוזרת, החלפת בעלים והתנהגות בכשלים. בנפרד בודקים שאי אפשר להנפיק טוקן בעקיפין ללוגיקת המלאי.
- פרסום הקולקציה. מריצים את הבנייה ברשת בדיקות, בודקים תצוגה במרקטפלייסים ובארנקים — ורק אחר כך מנפיקים ברשת הראשית.
- מסירת החוזים. מוסרים כתובות, קוד מקור, תרשים פריסה, הרשאות לתפקידי ניהול והוראות להנפקות הבאות.
תוצרי הפרויקט: חוזים, תרשימים ונוהלים
הפרויקט נמסר לא כקישור לחוזה פרוס, אלא כערכה שלפיה אפשר לפרוס את הקולקציה מחדש — בחשבון שלכם, בלעדינו ובלי גישה לשרתים שלנו. כל מה שמתאר את התנהגות הטוקן ואת סדר ההנפקה נמצא במאגר של הלקוח עם היסטוריית שינויים, והמסירה מלווה בניתוח קוד עם המהנדס שלכם.
- קוד מקור של החוזים ושל סקריפטי הפריסה — עם הערות ללוגיקת ההנפקה, ולא רק תוצרים בנויים.
- תיעוד לחוזים: ממשקי קריאה, פרמטרים, אירועים, מגבלות הנפקה ותפקידים — עם דוגמאות לקריאות תקינות ולקריאות נדחות.
- תרשים הנפקת הקולקציה: לוגיקת המטא-נתונים, פיזור התכונות והנדירות, גודל המנות, סדר החשיפה, הצמדה לארנק.
- מדיניות גישה לארנקים: מטריצת תפקידים, מי חותם על אילו פעולות, היכן נשמרים המפתחות, איך בנויה בקרה מרובת גורמים ורוטציה מתוכננת.
- סביבת בדיקות עם תרחישים מוכנים: הנפקה, העברה, שריפה, צבירת תמלוגים, התנהגות עם מיצוי המגבלה.
- נוהל תמיכה: איך לעדכן מטא-נתונים, מה לעשות כשההנפקה נתקעת, אילו מדדי חוזה לבדוק ובאילו ערכים להגיב.
- הוראות פריסה וחזרה לאחור — שלב אחר שלב, עם בדיקות בכל שלב, כדי שאפשר יהיה לחזור על השחרור בלי מחבר הקוד.
הערכה מיועדת לכך שהצוות שלכם או קבלן אחר ימשיכו לפתח את הקולקציה בלי הנדסה לאחור ובלי נקודת תלות אחת בנו.
מקרה בוחן: קולקציה ששרדה ביקוש שיא
מקרה בוחן של הנפקת קולקציה עם מלאי קבוע על TON: הטבעה פתוחה, אלפי ניסיונות הנפקה במקביל בדקות הראשונות. בסביבת הבדיקות החוזים החזיקו מעמד היטב, בהשקה אמיתית חלק מהמשתמשים קיבלו שגיאת חיוב, וחלק קיבלו פריט בעיכוב של עשרות דקות.
מה הראה שיא העומס
שיעור פעולות ההנפקה הכושלות הגיע ל-17% — כמעט כל קונה שישי לא קיבל פריט בניסיון הראשון. הנפקה מלאה של המלאי נמשכה יותר מתשע שעות במקום ארבעים דקות מחושבות, וזרם הבקשות החוזרות העמיס עוד יותר את הרשת והאריך את האישור.
עיבוד מחדש של החוזים
חוזה ההטבעה נכתב מחדש: בדיקות שקודם בוצעו באותה קריאה עם ההנפקה הועברו לשלב נפרד, והותירו בשרשרת מינימום חישובים. הוספנו הנפקה בקבוצות — קריאה אחת סוגרת קבוצת כתובות ורושמת את מצב הקולקציה פעם אחת, ולא בכל פעולה. פיזור הפריטים מחושב כעת מראש מחוץ לרשת, ולשרשרת נשלחת רשימה שכבר נבדקה.
לאחר העיבוד מחדש שיעור הפעולות הכושלות בשיא דומה — פחות מ-1%, והנפקה מלאה של המלאי אורכת כחצי שעה בלי התערבות ידנית. תוצאת היישום: הקולקציה עברה השקה בלי קפיאות וסבבים חוזרים, והחוזים עמדו בשיא שני — במכירה המשלימה — עם אותו מרווח.
במה שונה הנפקה ב-TON מהנפקה ברשתות אחרות?
TON — רשת אסינכרונית: החוזים מחליפים הודעות, והמצב מפוצל לרסיסים. לכן הנפקת קולקציה לא נכנסת לקריאה אטומית אחת — הטבעה, תשלום והעברת בעלות הופכים לשרשרת הודעות, שבה צריך לתכנן מראש עיכובים, ניסיונות חוזרים וטיפול בכשלים. במקום שבו ברשתות אחרות אותה פעולה נסגרת בקריאה אחת, כאן נדרשת לוגיקת אישור מפורשת לכל פעולה.
ההבדל השני — מיעון. כתובת של כל עותק מחושבת באופן דטרמיניסטי מכתובת הקולקציה ומהמספר הסידורי שלו, לכן האינדקס והמטא-נתונים קשורים בחוזקה בחוזה. הקולקציה חייבת למסור מטא-נתונים לפי ממשק תקני: בלי זה המרקטפלייסים לא יציגו את הטוקנים והמסחר לא ייפתח.
עלות הפעולות צפויה יותר: התשלום על הטבעה לא תלוי במכרז על מקום בבלוק, כמו ברשתות עם מצב גלובלי אחיד. להנפקה המונית זה הוצאה אחידה על כל הקולקציה במקום פיזור שתלוי בעומס ברגע ההשקה. התשלום מחויב מיתרת החוזה, לכן מטעינים אותו מראש — אחרת ההנפקה תיתקע באמצע.
מכאן המסקנה לבחירת פלטפורמה: במקום שבו ברשתות אחרות הלוגיקה אטומית, ב-TON נדרשים תרחישי פיצוי — החזר, הטבעה חוזרת, הודעות נפרדות לתשלומים ליוצר. זו עבודת תכנון, ולא העברה של חוזה מוכן. יש להשוות רשתות לפי תרחיש: הנפקה המונית עם מחיר פעולה נמוך או סביבה עם תשתית מוכנה וביקורת.
TON
שאלות טכניות לגבי הנפקת קולקציה
לפני הנפקת קולקציה מצטברים אצל הלקוח אותם ספקות: מה אפשר לשנות בחוזה פרוס, למי יגיעו המפתחות, ומה מאשר את התקינות לפני הפרסום. אנחנו מסירים אותם מראש — אחרי ההטבעה תיקונים כאלה עולים יותר.
האם אפשר לשנות חוזה אחרי הנפקה?
הקוד ברשת אינו ניתן לשינוי — זו ערובה לבעלים. לכן פרמטרים שעשויים להידרש מאוחר יותר — כתובת תמלוגים, בסיס מטא-נתונים, מגבלת הנפקה — מוציאים לשכבת נתונים נפרדת: היא נערכת בעסקת שירות עם הרשאות מנהל, בלי לבנות מחדש את החוזה.
אצל מי נשארים המפתחות?
אצלכם. ניהול הקולקציה שהונפקה לא נשאר בידינו: בהתחלה מגדירים שני מפתחות — של הבעלים ושל שירות, כדי שפעולות שגרה לא ידרשו גישה למפתח הראשי. סדר האחסון והמסירה מתואר בתיעוד.
איך בודקים לפני שחרור?
מריצים תרחישים ברשת בדיקות: הנפקה, העברה, תשלום תמלוגים, קריאה לשיטות ניהול ללא הרשאה, הטבעה חוזרת, מגבלת מלאי. בנפרד בודקים איך הקולקציה מוצגת ונסחרת במרקטפלייסים — ב-TON לא כל הפלטפורמות תומכות בתמלוגים.
מה הלאה בתמיכה בקולקציה?
תמונות ומטא-נתונים ממוקמים באחסון מבוזר, ולא בשרת שלנו — הקישורים לא תלויים בתשתית שלנו. מוסרים תרשים פריסה, כדי שאפשר יהיה לחזור על ההנפקה בכוחות עצמכם.
נדון במשימה שלכם להנפקת קולקציה
כדי לחזור לא עם שיקולים כלליים, אלא עם הערכת פרויקט ותוכנית עבודה, אנחנו צריכים קלט מינימלי על הקולקציה. ככל שהנתונים הראשוניים מפורטים יותר, כך לוחות הזמנים מדויקים יותר — פערים במלאי ובלוגיקת ההטבעה בדרך כלל יוצרים פער בהערכה פי כמה.
מה לשלוח לניתוח ראשוני
- רעיון הקולקציה: כמה טוקנים ייחודיים, האם יש רמות נדירות, ואיך הן מתפלגות לפי המלאי.
- תוכן ומטא-נתונים: תמונות או מודלים מוכנים, שכבות וכללי הרכבה, היכן יישמרו הקבצים ואיך מוצמדות אליהם התכונות.
- כלכלת ההנפקה במונחי כללים: סדר ההטבעה, תמלוגים ממכירה חוזרת, מגבלות לארנק, שלבי מכירה, והאם נדרשת רשימת כתובות מורשות.
- תרשים ההטבעה: האם המטביעים הם המשתמשים או הצוות, האם נדרש אתר עם חיבור ארנק, ומי משלם את עמלת הרשת.
- פלטפורמות יעד: באילו מרקטפלייסים הקולקציה צריכה להיסחר ואילו דרישות למטא-נתונים הן מציבות.
- תאריכים: לאיזה אירוע או גל מכירות ההנפקה צריכה להיות מוכנה.
מה נסגור בתוכנית התגובה
- ארכיטקטורת החוזים: מה נכנס לחוזה הקולקציה, מה לחוזי עזר, ואיך בנויים שלב ההטבעה והמעבר למסחר.
- סדר הבדיקות: בדיקות ברשת בדיקות, בקרת הרשאות בעלים, מגבלות ותמלוגים לפני היציאה לרשת הראשית.
- שלבי פיתוח ולוחות זמנים עם נקודות ביקורת שמראות את ההתקדמות.
- מה נדרש מצדכם בכל שלב: הרשאות, חומרים, החלטות לגבי נדירות ולוגיקת מכירות.
- סדר העלאה למרקטפלייסים ופעולות אם הפלטפורמה תחזיר מטא-נתונים לתיקון.
תארו את המשימה בצורה חופשית — נחזור עם הערכת פרויקט, תוכנית עבודה ולוחות זמנים. הצעד הבא שלנו: ננתח את החומרים ונציע תרשים הנפקה קונקרטי לקולקציה שלכם.