פיתוח טוקן FA2 Tezos: צווארי בקבוק בלוגיקה רב-נכסית
טוקן רב-נכסי הוא לא אוסף של חוזים נפרדים, אלא מרשם אחד שבו כל נכס חי תחת מזהה משלו, וניהול היתרות מתבצע לפי הצמד «בעלים — מזהה נכס». התבנית חוסכת בפריסה ומאפשרת לעבוד עם עשרות נכסים מנקודה אחת, אך דווקא היא יוצרת צווארי בקבוק.
פיתוח טוקן FA2 ב-Tezos מתחיל לא בקוד ההעברות, אלא בתכנון האינווריאנטים: כמה הונפקו בסך הכול, למי מותר לשנות את המרשם ומה נחשב להעברה תקינה.
המקום הראשון שבו נשבר חוזה רב-נכסי הוא הרשאות האופרטור. ניתן למנות אופרטור גם לנכס מסוים וגם לכולם בבת אחת, ואת האפשרות השנייה מרבים להחמיץ: אינטגרציה שזקוקה לגישה למזהה אחד מקבלת שליטה על כל מכלול הנכסים. רשומה אחת כזו במרשם ההרשאות מספיקה כדי שהוצאת נכסים תהפוך לעניין של זמן.
השנייה — העברות בין נכסים שונים. החלפה ישירה בתוך פעולה אחת שוברת את האינווריאנט של שמירת הסכום: היתרות «צפות», וההנפקה מפסיקה להתאים להיצע בפועל. הדרך התקינה היא להפריד בין חיוב להנפקה, לתעד את הנפחים לפני ואחרי, ולבדוק את ספיקות היתרה עבור כל נכס בנפרד.
מחיר הטעות בחוזה טוקן גבוה יותר מאשר בשירות רגיל: אי אפשר להוסיף לוגיקה מעל, ותיקון מחייב תמונת מצב של היתרות והעברת המאגר. אם המרשם כבר אינו מסונכרן, לא ניתן להרכיב תמונת מצב — המחזיקים מאבדים גישה לנכסים, והמוצר עובר לבירור ידני. בהמשך נבחן כיצד תרחישים אלה נסגרים בשלב התכנון והבדיקות.
מה נותן טוקן רב-נכסי: אפקט בגדלים מדידים
טוקן רב-נכסי הוא מרשם אחד לכל סוגי הנכסים במקום חוזה נפרד לכל מכשיר. מניות, יחידות קרן, יחידות בונוס ותעודות חיים בחוזה משותף בתקן FA2 על Tezos, ונכס חדש הופך לרשומה במרשם זה, ולא לפריסה נפרדת עם מערך כתובות ותפקידים משלה.
האפקט המדיד הראשון — צמצום ההתאמות הידניות. כשכל נכס מטופל בחוזה משלו, הנהלת החשבונות מתאימה את התפוקות של כל אחד מהם בנפרד, ומספר ההתאמות גדל באופן לינארי עם מגוון המכשירים.
מרשם אחד נותן נקודת אמת אחת: ההתאמה מתבצעת לפי מקור אחד, ושיעור הפעולות הדורשות התערבות ידנית יורד לתרחישים בודדים — העברה כפויה או הקפאה לפי החלטת המנפיק.
האפקט השני — נעלמים סוגים שלמים של כשלים. חוסר סנכרון בין יתרות של מכשירים שונים, אובדן כתובת עם הנפקת נכס חדש, שכפול הרשאות מנהל — כל אלה תוצאות של חוזים משוכפלים, ובמרשם המשותף הם לא נוצרים באופן מבני. נותרו כשלים ברמת הרשת: הם נראים לפי סטטוס הפעולה ומטופלים בלי לתקן את לוגיקת החשבונאות.
השלישי — זמן ההנפקה של נכס חדש. בעבר היה זה חוזה נפרד, הבדיקה שלו, אינטגרציה בממשק ובמערכת החשבונאית; כעת — תיאור הפרמטרים של סוג חדש במרשם והענקת תפקיד אופרטור. כללי ההעברות, ההקפאות ותיחום ההרשאות עוברים בירושה אוטומטית, ולכן ההנפקה נמדדת בימים ולא בשבועות של תיאומים.
שלוש גישות לרב-נכסיות: חוזה מאוחד והחלופות שלו
תקן FA2 מגדיר את הממשק של רב-נכסיות: מרשם הבעלים בנוי לפי הצמד «כתובת — מזהה נכס», וההעברות, שאילתות היתרה וניהול האופרטורים עוברים דרך נקודות כניסה חובה transfer, balance_of ו-update_operators. מה שהתקן לא מכתיב הוא כיצד לסדר את הנכסים עצמם בין החוזים.
מכאן שלוש תבניות עבודה, והבחירה נקבעת בשלב הארכיטקטורה: החלפת תבנית לאחר ההשקה משמעה מיגרציה של המרשם והנפקה מחדש של הטוקנים תחת כתובות חדשות.
| וריאנט | מתי מתאים | מגבלות |
|---|---|---|
| חוזה רב-נכסי מאוחד | מגוון נכסים עם כללי העברה משותפים, מרשם משותף ונקודת אינטגרציה אחת לבורסות ולארנקים | הלוגיקה משותפת לכל הנכסים; הרשאות ההנפקה וההקפאה קשורות לצמד «כתובת — מזהה», האצלת תפקידים מסתבכת; המרשם גדל בבת אחת עבור כל המגוון |
| חוזה נפרד לכל נכס בתוספת מפעל פריסה | לנכסים כללים שונים (עמלות, מגבלות על העברה), עדכונים בלתי תלויים, מעגלים משפטיים שונים | כל נכס — כתובת נפרדת ופריסה נפרדת; האינטגרטורים צריכים לחבר ידנית כתובות חדשות; חלון ראווה אחיד נבנה כשכבה מעל המרשם |
| חוזה-שכבה מעל מימושים חיצוניים | נדרש ממשק אחיד, אך הנכסים כבר הונפקו או שהלוגיקה שלהם צריכה להתעדכן באופן בלתי תלוי | שכבה מיותרת בשרשרת הקריאות: עלות הפעולה גבוהה יותר והסיכון לכשל בהפניה; יש לבצע ביקורת ולעדכן שני חלקים |
יש לקחת בחשבון בנפרד ש-FA2 לא מתאר הנפקה של טוקנים חדשים, תמלוגים ותפקידי ניהול — אלה מוצאים אל המטא-נתונים והרחבות ברמת TZIP-12 ו-TZIP-21.
לכן השאלה «איזה וריאנט זול יותר» אינה מדויקת: תחילה קובעים מי ובאיזו תדירות מנפיק נכסים, האם נדרשים כללים שונים לנכס והאם מתוכנן עדכון לוגיקה — ורק אז נבחרת התבנית. בהמשך נבחן כיצד כל וריאנט משפיע על אינטגרציות ועדכונים.
שלבי הפיתוח: מניתוח המשימה ועד מסירת החוזים
את סדר העבודה קובעים לפני שורת הקוד הראשונה: שלבי פיתוח הטוקן עוברים מניתוח המשימה למסירת החוזים, ובכל שלב יש ארטיפקט שאתם מאשרים. זה מסיר את הסיכון העיקרי — כשמודל הנכסים מתוקן כבר אחרי ההשקה וגורר אחריו מיגרציה של היתרות. להלן הרצף שלפיו פועל הצוות שלנו.
- ניתוח המשימה והגבולות. קובעים את הרכב הנכסים, מי מנפיק ומי רשאי לשרוף, האם נדרשות מגבלות על פעולות, הקפאה ותפקידי מנהל. בפלט — תיאור מוסכם של כלכלת הטוקן, ולא משאלות כלליות.
- תכנון מודל הנכסים. מגדירים את מרשם הטוקנים, הרשאות התפקידים, מדיניות ההעברות והאופרטורים. כאן גם מחליטים אילו בדיקות מתבצעות ברמת החוזה ואילו נשארות באפליקציה.
- מימוש החוזים. כותבים FA2 רב-נכסי על Tezos לפי המודל המאושר: ממשק, נקודות כניסה, טיפול בשגיאות. הקוד מפוצל למודולים כדי שתיקון של נכס אחד לא ישפיע על האחרים.
- בדיקות בצד הפיתוח. מכסים בבדיקות את כל הענפים: הנפקה, העברה, שריפה, דחייה בגלל הרשאות, ערכי קצה של סכומים. שיעור הנתיבים המכוסים — מדד שאנחנו מראים לכם לפני היציאה לרשת.
- בדיקה ברשת הבדיקות. מריצים תרחישים מהפעלה אמיתית: הנפקות בהיקף גדול, העברות בין מספר רב של מחזיקים, התנהגות בעת כשלים. בנפרד בודקים עדכון של החוזה וחזרה לגרסה הקודמת.
- קבלת החוזים ומסירה. אתם מקבלים את תוצאת הבדיקה הבלתי תלויה, ניתוח של כל ההערות, תיעוד של התפקידים והכתובות, סקריפטים לפריסה והוראות הפעלה.
כל שלב נסגר באישור שלכם — השלב הבא לא מתחיל עד שמודל הנכסים או הרשאות התפקידים מאושרים. תארו את המשימה, ונחזור עם תוכנית עבודה והערכה.
מה המזמין מקבל לידיו: קוד, תרשימים ותקנונים
מסירת הפרויקט היא לא רק חוזה עובד, אלא גם כל מה שמאפשר לצוות שלכם להנפיק נכסים ולשנות כללים בלי ההשתתפות שלנו. לכן בהיקף העבודה על טוקן FA2 ב-Tezos נכלל מארז של מסמכים נלווים: קוד, עותקים פרוסים, תרשים תפקידים ותקנונים שלפיהם הטוקן ממשיך להתקיים.
- קוד המקור של החוזים עם היסטוריית שינויים, ארטיפקטי פריסה בנויים ועותקי עבודה ברשת הבדיקות.
- תרשים תפקידים: מנהל החוזה, אופרטור הנפקה, מבקר — מה כל תפקיד יכול ליזום וכיצד להעביר אותו.
- מדיניות גישה: תנאי ההנפקה, ההקפאה וההעברות של נכסים, הגדרת מגבלות על פעולות.
- תקנון הנפקת נכסים: סדר פעולות שלב-אחר-שלב להוספת נכס חדש — מטא-נתונים, נפח, בדיקות, מי מאשר את הפרסום.
- תיעוד הטוקן: ייעוד המתודות והאירועים, מגבלות התקן, התנהגות בעת שגיאות — אינטגרציה בלי לקרוא את הקוד.
- הוראות לפריסה ולעדכון: פרמטרים של הרשת, סדר העלאת הלוגיקה החדשה, חזרה לעותק העבודה הקודם.
- מארז בדיקות ותרחישי קבלה: כיסוי של נתיבי הנפקה, שריפה, העברות והחלפת הרשאות, דוח על ההרצה.
- פרוטוקול מסירת החוזים: כתובות, זכויות הבעלים בצד שלכם, הגישה של הצוות שלנו סגורה.
מקרה בוחן: העברת לוגיקה רב-נכסית לחוזה אחד
המזמין ניהל אחד עשר סוגי נכסים — נתחי השתתפות, יחידות קרנות, זכויות על ציוד, נקודות בונוס — בחוזים נפרדים על Tezos. לכל אחד הייתה לוגיקת העברות משלו, רשימות אופרטורים משלו וניהול יתרות משלו, אף שהכללים לכל הסוגים תאמו במהותם.
בגלל זה הנפקה של נכס חדש ארכה כשלושה ימים: העתיקו את החוזה, תיקנו ידנית הרשאות ומגבלות, הריצו בדיקות מחדש. תיקון של עמלה או של מדיניות הקפאה התבצע בנפרד עבור אחת עשרה כתובות, ופערים בין סוגי הנכסים צפו כבר בסביבת העבודה.
מה שינינו
איחדנו את הלוגיקה הרב-נכסית לחוזה אחד לפי תקן FA2: סוג הנכס הפך למזהה בתוך מרשם משותף, וההעברות, ההקפאות והתפקידים — לכללים אחידים עם הגדרה ברמת הטוקן. נכס חדש מתואר כעת במערך פרמטרים, ולא בקוד חדש, ויורש את אותן הבדיקות כמו האחרים.
מדדים לפני ואחרי
- הנפקה של סוג נכס חדש: שלושה ימי עבודה ידנית → ערב אחד של קונפיגורציה והרצת בדיקות.
- פעולות ידניות בהעברות ובהחלפת מדיניות: הצטמצמו בכ-80% — הכללים המשותפים של החוזה לקחו אותן על עצמם.
- פערים בהתנהגות בין נכסים: ארבעה בירורים ברבעון לפני המעבר, ואף לא אחד אחרי.
- ביקורת: בסיס קוד אחד במקום אחד עשר — שטח הבדיקה הצטמצם יחד עם נפח הקוד.
ביקורת חוזרת לאחר האיחוד עברה בלי הערות על הלוגיקה הרב-נכסית, והמעבר של סוג נכסים נוסף ארך יום במקום שבוע — וזו ההוכחה שהלוגיקה אכן משותפת, ולא הועתקה אחד עשר פעמים.
במה FA2 שונה מ-FA1.2 וכיצד להעביר נכסים שכבר הונפקו
FA1.2 הוא תקן חד-נכסי: החוזה מטפל בנכס אחד, ולנהל את היתרה יכול הבעלים או כתובת שקיבלה אישור דרך approve. טוקן שני הוא חוזה שני עם עותק של הקוד: שכפול לוגיקה, כתובות שונות, אישורים שאינם קשורים זה לזה.
FA2 מסיר את המגבלה הזו באמצעות token_id: נכסים רבים חיים במאגר אחד, ונקודת הכניסה transfer מקבלת חבילת העברות בפעולה אחת. במקום allowance משתמשים ב-operator — זכות קבועה לנהל יתרה של אחר, בתוספת בדיקות בצד השולח והמקבל בעת ההעברה: עליהן בנויים ציות ורשימות לבנות.
ברמת המאגר התקנים אינם תואמים: אי אפשר «לעדכן» חוזה שכבר הונפק. העברת נכסים מתבצעת בתמונת מצב של המצב: מתעדים את היתרות בבלוק מסופי, מכניסים את החוזה הישן להשהיה, פורסים FA2 ומנפיקים מקבילה עם אותם token_id ו-decimals, ולאחר מכן שורפים את הרשומות הישנות.
הדקות המרכזית — אישורים לא עוברים: את ה-operator יהיה צורך להנפיק מחדש, ועל כך מזהירים מראש את המחזיקים והפלטפורמות. ההשהיה הכרחית, אחרת בין תמונת המצב להנפקה אפשר להעביר את הנכס הישן והוא יוכפל.
מוסיפים בדיקת אינווריאנטים: סכום היתרות, הנפח הכולל וה-decimals לפני ואחרי תואמים, ואת האינדקסרים והארנקים מעבירים לכתובת החדשה.
אם בחוזה המקורי אין מפתח מנהל או פונקציה לעצירת העברות, נותרת עטיפה: חוזה FA2 מחזיק את FA1.2 ומנפיק תביעה להחלפה אחד לאחד — אך זה אמון באופרטור של העטיפה. בודקים זאת לפני תחילת העבודה ובוחרים מסלול מיגרציה המתאים למקרה שלכם.
ספקות טכניים: ביקורת, אחסון מפתחות, עדכונים
לפני תחילת הפיתוח יש למזמין הטכני בדרך כלל שלוש שאלות: מה קורה בתוך החוזה, בידי מי יהיו המפתחות ומה אפשר לשנות במערכת פעילה. להלן כיצד אנחנו עונים עליהן כברירת מחדל, בלי הסכמות נפרדות.
כיצד לוודא שאין בחוזה הרשאות נסתרות?
לפני המסירה אנחנו מוסרים מפת נקודות כניסה ומטריצת תפקידים: מי יכול להנפיק טוקנים, לשרוף אותם, להשהות העברות, לשנות פרמטרים של עמלות. התפקידים מפוזרים על כתובות שונות, ולא מרוכזים במפתח ניהולי אחד — זה נקרא בקוד ונבדק ברשת הבדיקות. בנוסף יש מארז בדיקות לתרחישים שליליים: הנפקה מעל המגבלה, העברה של נפח חסום, קריאה תחת תפקיד של אחר.
היכן נשמרים המפתחות ומי מנהל אותם?
מפתח המנהל לא נמצא במאגר הקוד, בבנייה ובהתכתבות — רק במדיה חומרתית אצל המחזיק שמונה לכך. עבור פעולות הנפקה והחלפת פרמטרים מגדירים ריבוי חתימות: העסקה עוברת כשמאשרים אותה כמה מחזיקים. המסירה מתבצעת לפי נוהל עם רוטציה של מפתחות, כדי שלצוות הפיתוח לא יישארו הרשאות פעילות לאחר ההשקה.
מה לעשות אם צריך לשנות את הלוגיקה אחרי ההשקה?
החוזה אינו ניתן לשינוי, ולכן עדכון הוא העברת הרשאות לגרסה חדשה עם מיגרציה של היתרות בתמונת מצב. החוזה הקודם עובד זמן מה במצב קריאה בלבד, בזמן שהמחזיקים מעבירים נכסים, ואנחנו בודקים את התאמת החשבונאות. חזרה אחורה אפשרית כל עוד הרשאות המנהל לא הועברו סופית.
לאחר המסירה נותר מארז: מפרט התנהגות, תרשים תפקידים, תקנון עדכון החוזה ותמיכה לפי לוח זמנים מוסכם. שאלות כאלה בנוגע לטוקן מסירים לפני תחילת העבודה — תארו את המשימה, ונחזור עם הערכה ותוכנית.נדון במשימה: מה לשלוח לצורך הערכה ותוכנית עבודה
כדי לחזור עם הערכה ותוכנית עבודה, ולא עם ניסוחים כלליים, נדרש מארז נתוני קלט. ככל שכללי השימוש בטוקן מתוארים בצורה מדויקת יותר, כך יישארו פחות הנחות בחישוב — וכך ידרוש החוזה פחות תיקונים לאחר ההשקה.
- כלכלת הנכס: כמה סוגי טוקנים, מי ובאילו תנאים מנפיק ושורף, האם יש מגבלת הנפקה, הקפאה, חיובים כפויים.
- מודל תפקידים: מי מנהל את החוזה, מי משהה פעולות, האם נדרשת ריבוי חתימות ולשם אילו פעולות.
- לוגיקת העברות: עמלות, תמלוגים, רשימות לבנות ושחורות, בדיקות נוספות ב-hooks של ההעברה.
- מטא-נתונים: אילו שדות נדרשים לתצוגה בארנקים ובפלטפורמות, היכן נשמרות התמונות, האם מתוכננת עריכה של התיאורים.
- יכולת שינוי: האם מותר להעביר מצב לחוזה חדש, מי יוזם את העדכון, וכיצד נשמרות בזמן זה יתרות המחזיקים.
- עומס: כמה נכסים והעברות צפויים, מהם שיאי העומס, האם נדרשת אינדקסציה של ההיסטוריה עבור הממשק.
- בדיקות וקבלה: האם נדרשת ביקורת חיצונית, אילו תרחישים נחשבים קריטיים, מי מכין את רשת הבדיקות ואת הנתונים לחזרה הכללית של ההשקה.
אם חלק מהסעיפים עדיין לא מוגדרים — זה לא חוסם את ההערכה: נדון במשימה ונקבע יחד את החסר. תארו את תרחיש השימוש, ונחזור עם הערכת לוח זמנים, תוכנית עבודה ופילוח לפי שלבים.