פיתוח אסימון שירות עם מנגנוני סטייקינג וצריבה

פיתוח utility token: היכן נשברת מכניקת ההנפקה

טוקן utility נשבר לא בשלב כתיבת החוזה, אלא בממשק שבין הרכיבים: חישוב הזכאות לתגמול מתקיים במקום אחד, ההנפקה וה-burn במקום אחר, ואת המצב הסופי מחזיק Ethereum. כל עוד יש זרם אחד או שניים, אי-ההתאמה אינה מורגשת.

ברגע שמופיעים staking, צבירות שותפים ו-burn תקופתי, הממשק מפסיק להסתדר, וטעות במכניקת ההנפקה עולה כבר לא בספרה אחת, אלא באמון המחזיקים.

ראשון מתגלה אי-סינכרון בחישובים. בסיס הצבירות ומצב הטוקן מתעדכנים על ידי שירותים שונים, ואין ביניהם גבול טרנזקציוני משותף — הסכום לתשלום מפסיק להתאים למה שבאמת נמצא בכתובת.

בהמשך מגיעים תיקונים ידניים: "מתקנים" צבירה ישירות בבסיס הנתונים, ואחרי זה שום מספר לא ניתן לשחזור מתוך היומן.

קטגוריה נפרדת — פעולות תקועות. שליחה לרשת לא אושרה, ניסיון חוזר יוצר כפילות, אבל הרשומה במערכת החשבונאות כבר מסומנת כבוצעה. פעולה כזו צריכה סטטוס מפורש, מפתח אידמפוטנטיות וחזרה על פי היומן, אחרת היא תלויה בין "בוצע" ל"לא בוצע" וחוסמת התאמות.

התוצאה — חוסר אפשרות לבצע ביקורת. כשחלק מהצבירות תוקנו ביד, וחלק מהפעולות קיימות בלי סטטוס, בדיקה חיצונית נתקלת לא בחוזה, אלא בהיעדר היסטוריה ניתנת לשחזור. צבירת תגמול לא שקופה במבנה כזה אי אפשר להוכיח או לערער — וכאן בדיוק נבחן איך סוגרים את זה.

אפקט מדיד: לוחות זמנים של הנפקה ויציבות המוצר

מהירות עדכונים, יציבות חישובים וצמצום פעולות ידניות

לוגיקת הצבירות וה-burn מועברת למודול נפרד שניתן לעדכן, בעוד ההרשאות והיתרות נשארות בלתי משתנות. כלל תגמול חדש או מגבלת burn נפרסים בלי לפרוס מחדש את החוזה ובלי הגירת מחזיקים — העדכון עובר ברשת בדיקה ועולה לרשת הראשית באותו יום.

החישובים מבוצעים ממצב מאושר, ולא ממונים בשירותים נפרדים, ולכן סיכום הארנק מתאים באופן זהה אצל כל המשתתפים. התשלומים יוצאים בקבוצות, אי-ההתאמות נסגרות בהתאמות — שיעור הפעולות שדורשות התערבות ידנית יורד למקרים בודדים במחזור.

שיעור הכשלים שהוסרו וצפיות בצבירות

חלק מהכשלים נסגר ברמת הכללים: צבירה כפולה לאותה כתובת, אובדן תגמול בזמן burn מקביל, stake שנתקע בעת משיכת כספים, אי-התאמה בין הצבור לזמין. לכל תרחיש יש בדיקה שמשחזרת את התקלה, ולכן התקרית לא מגיעה לרשת הראשית.

צפיות נשמרת על סט כללים אחד: ספים, חלונות ואירועים קבועים ונרשמים ביומן, ולכל אחוז רואים מאיפה הוא בא. פעולות ידניות לא נעלמות מעצמן — אותן מחליף תהליך מתואר שמופעל באופן זהה בכל קריאה.

מכניקות הנפקה והחזקה: השוואת גישות

מודל ההנפקה קובע איך משתנה ההיצע של הטוקן, ומכניקת ההחזקה קובעת מה מונע מהמחזיק לצאת לשוק. אלה שני פרמטרים בלתי תלויים: אותו לוח זמנים של הנפקה מתנהג אחרת עם staking גמיש ועם staking קצוב, ולכן אי אפשר לבחור אותם בנפרד.

אפשרויות והמגבלות שלהן

איך לבחור מודל למשימה

יוצאים מתפקיד הטוקן במוצר: אם הוא משלם עבור פעולה בתוך השירות, burn לפי אירוע תואם את הביקוש בפועל ולא דורש כוונון ידני. במקומות שבהם חשובים הצבעה והחזקה ארוכה — ניקח staking קצוב, ואת ה-burn לפי לוח זמנים נשאיר כרקע פשוט וניתן לבדיקה.

את השילוב מריצים בסימולציה: שיעור הטוקנים הנעולים, קצב ה-burn מול ההנפקה והתנהגות בזמן נטישת משתמשים.

שלבי עבודה הנדסית: מפירוק המשימה ועד למסירה

את שלבי ההטמעה בונים כך שהחלטות על כלכלת הטוקן יתקבלו לפני שורת הקוד הראשונה. staking ו-burn הם מכניקות של פעולה דחויה: טעות בחישובים מתגלה לא בהשקה, אלא אחרי שבועות, כשהמחזיקים מתחילים לצאת מהנעילה. לכן כל שלב מסתיים בארטיפקט שבודקים לפני המעבר לשלב הבא.

הכנה וסכמה

1. פירוק המשימה. מה הטוקן נותן למחזיק, באילו תנאים נצבר תגמול, מה נכנס ל-burn — עמלה, יתרה שלא נפדתה או שני הזרמים.
2. סכמת החוזה והתפקידים. סט תפקידים, גבולות ההרשאות שלהם, מה נשאר בלתי משתנה אחרי ההשקה ואיך מועברות הרשאות ניהול.
3. בדיקת חישובים. נוסחאות תגמול, תקופות נעילה, לוח הנפקה ומקרי קצה: stake אפס, שחרור נעילה ברגע שינוי התעריף.

בדיקה, השקה ומסירה

• מימוש. בודקים חישובים, הרשאות גישה וקריאות חוזרות: פנייה לתפקיד זר צריכה להיחסם.
• הרצה על העתק של הרשת. יציאה המונית, זמן שקט ארוך, עלייה חדה בפעילות — האם הצבירות מסתדרות עד הספרה האחרונה.
• השקה עם מגבלות. בהתחלה מחזיקים מגבלות על נפח הפעולות ואפשרות להשהות מכניקות, אם הרשת מתנהגת אחרת מהתחזית.
• מסירה. תיעוד המכניקות, סכמת תפקידים, גישות, ניטור מדדים ונוהל פעולה בחריגות.

מה מועבר לידיים: קונפיגורציות, סכמות, נהלים

אחרי ההשקה כל המבנה חי בתשתית שלכם, ולכן מוסרים לידיים לא רק חוזים פרוסים, אלא גם ערכה מלאה שצוות התמיכה עובד ממנה באופן עצמאי: מה מותר לשנות, למי יש הרשאה לקריאות ניהול ואיך מבטלים פעולה עם אפקט לא צפוי.

חבילת מסמכים טכנית

• תיעוד החוזה: מתודות ציבוריות, אירועים, פרמטרים של הנפקה ו-burn, רשימה נפרדת של ערכים שאסור לשנות בלי פריסה מחדש.
• סכמות אינטראקציה: זרימת קריאות בין הטוקן, מאגר ה-stakes ומכניקת ה-burn — עם סדר צבירת התגמולים ובדיקת המגבלות.
• קונפיגורציות תפקידים: טבלה "תפקיד → פעולות מותרות → אופן הענקה ושלילה" עם כתובות ארנקים ותיאור איך הגישה מוסרת.
• מדיניות גישה: מי מחזיק בפונקציות ניהול, אילו קריאות דורשות אישור מכמה צדדים והיכן יש השהיה לביצוע.
• מרשם פרמטרים: כתובות של חוזים פרוסים, הנפקה, מגבלות, ספי אישורים — מקור אמת אחיד לביקורת ותמיכה.
• דוח בדיקות: תוצאות ביקורת חיצונית והרצות ברשת בדיקה עם רשימת מגבלות ידועות.

נהלי תפעול ותחומי אחריות

• נהלי תחזוקה: איך ובאיזה סדר משנים פרמטרים, מי מאשר שינוי ואיך מבטלים טרנזקציה.
• סדר תגובה: סימני תקרית, אחראים ורצף פעולות עד לחיבור אלינו.
• מטריצת אחריות: מה נשאר בצד שלנו בתקופת התמיכה, ומה עובר לצוות שלכם.
• העברת ידע: סקירת קוד עם המהנדסים שלכם ותשובות בכתב על אזורים שנויים במחלוקת.

מקרה בוחן: איך הסירו פעולות תקועות ותיקונים ידניים

מצב התחלתי וצוואר בקבוק

לקוח הגיע עם utility token עובד, אבל קו התפעול לא עמד בצמיחה: חלק מההעברות ופעולות ה-staking נתקעו בסטטוס ביניים, ואי-התאמות ביתרות היה צריך לסגור ידנית דרך טבלאות ותשלומים חוזרים.

בשיא, שיעור הפעולות התקועות הגיע ל-8–12% מהנפח היומי, וכל פעולה כזו עלתה למהנדס מחצי שעה ועד כמה שעות של בדיקה ידנית, כולל התאמת יומנים ושליחה חוזרת.

מה עשו ואיזו תוצאה התקבלה

לוגיקת הצבירות נכתבה מחדש לפעולות בקבוצות עם מזהים אידמפוטנטיים: הרצה חוזרת לא מכפילה את התגמול, ופעולה שלא הושלמה ממשיכה לפי יומן מצבים.

החוזים נבנו על ספריות בדוקות — מנגנוני גישה בסיסיים והגנה מפני ביצוע חוזר נלקחו מ-OpenZeppelin, ומעליהם הוספה תור עם הגבלת ניסיונות וסטטוסים מפורשים: פעולה או הושלמה, או ממתינה לחזרה, ואין יותר מצב שלישי במערכת.

burn של טוקנים קושר לחיוב מאושר, ולכן היתרה וההיצע תמיד מסתדרים בלי התאמה ידנית. שיעור הפעולות התקועות ירד ל-0.3% מהנפח היומי, והשאר נסגרות בחזרה אוטומטית. תיקונים ידניים הצטמצמו מכמה עשרות בשבוע לפניות בודדות, ויציבות הצבירות עלתה ל-99.9% מחזורים בלי התערבות מהנדס.

במה שונה burn של טוקן מ-staking ומתי צריך את שניהם?

burn ו-staking שניהם מקטינים את נפח הטוקנים במחזור החופשי, אבל פותרים משימות שונות. burn הוא בלתי הפיך: טוקנים נשלחים לכתובת "חור שחור" או שקריאה לפונקציית burn בחוזה מוציאה אותם מההיצע לנצח — במודל דפלציוני זו הדרך היחידה לרסן האצת הנפקה. staking הוא הפיך: הנכס ננעל לתקופה, נשאר בבעלות הבעלים וחוזר למחזור, ופועל על החזקה, לא על ההיצע.

ההבדל מתגלה בקונפיגורציה. במודל דפלציוני מגדירים שיעור burn מהעמלה, מגבלה לתקופה והתחשבנות בנפח שנשרף בהיצע הכולל. ב-staking גמיש — תקופה מינימלית ומקסימלית, מכפיל תגמול, תנאי משיכה מוקדמת ומקור מאגר התגמולים.

השילוב של מכניקות מוצדק כשהתגמולים על staking מגיעים מעמלות שנשרפו, ולא מהנפקה חדשה: burn סוגר את האינפלציה, staking — את ההחזקה. אז בחירת המכניקה נקבעת לא לפי טעם, אלא לפי כלכלה, והכללים של שתיהן צריכים להיות ניתנים לבדיקה בביקורת וצפויים למחזיק.

חששות בנושא אבטחה, ביקורת ועדכון חוזה

לפני ההשקה החוזה עובר שלושה מעגלים: ניתוח סטטי לפגיעויות אופייניות, בחינה ידנית של מודל הגישה ובדיקות לתרחישי קצה — burn גדול מהיתרה, claim חוזר, יציאה מ-stake בזמן השהיה.

בנפרד בודקים ש-mint, שינוי תעריפים והשהיה סגורים במודל תפקידים ולא נקראים מכתובת רגילה: מפזרים הרשאות בין ארנקים שונים, ופעולות קריטיות שמים מאחורי timelock. תקנים בסיסיים נלקחים מספריית OpenZeppelin בדוקה, ולא כותבים בקרת גישה ואריתמטיקה מאפס.

עדכון הלוגיקה תלוי בסכמה: חוזה בלתי משתנה בטוח יותר, אבל תיקון דורש העברת נכס; סכמת proxy שומרת על הכתובת והיתרות, אבל מוסיפה מעגל ניהולי שצריך להגביל.

העברה של טוקן שהונפק מתבצעת לפי snapshot של מחזיקים ו-stakes — סקריפט החלפה, חזרה על העתק של הרשת, ואז טרנזקציה ראשית, והמחזיק מקבל את אותה כמות בלי פעולות ידניות.

מי יכול לשנות את הלוגיקה ואיך זה מוגבל?

התפקידים מופרדים: עדכון בנפרד, הנפקה בנפרד, השהיה בנפרד. קריאות קריטיות עוברות דרך השהיה בזמן, ולכן השינוי גלוי למחזיקים לפני כניסתו לתוקף, ומפתח אחד שנחשף לא נותן שליטה על הנכס.

נדון במשימה: מאיפה להתחיל ומה להכין

כדי שההערכה תהיה עניינית ולא "פחות או יותר לפי ניסיון", לפגישה הראשונה מספיק לתאר מה הטוקן עושה במוצר ואיך הוא חי אחרי ההשקה. להלן צ'קליסט: הוא מכסה כמעט את כל השאלות שקבועות מהן לוגיקת החוזים, היקף העבודה ולוחות הזמנים של השלבים.

• תרחיש שימוש: עבור מה נצבר הטוקן, מי ולמה מחזיק אותו, מה הבעלות נותנת — מזה תלויה לוגיקת ההנפקה והמגבלות.
• פרמטרים כלכליים: חלקי חלוקה, נפח הנפקה כולל, כללי צבירת תגמולים — מחשבים בחלקים ומגבלות, בלי הצמדה למחיר.
• מכניקת staking: תקופות נעילה, סדר צבירה ויציאה, מה קורה במשיכה מוקדמת ואיך זה בא לידי ביטוי בהנהלת חשבונות.
• מדיניות burn: מה נשרף, לפי איזה אירוע, מי יוזם את הפעולה ואיך היא נכנסת לדיווח.
• דרישות להשקה: רשת, ארנקים נתמכים, אינטגרציות נדרשות, תפקידי גישה ומי בצד הלקוח מקבל החלטות.
• ממשקים: האם צריך אזור אישי למחזיק, פאנל ניהול פרמטרים למנהל, ייצוא להנהלת חשבונות ולאנליטיקה.
• מגבלות: דרישות רגולטוריות ופנימיות, וכן סדר בדיקת חוזים לפני פרסום ברשת הראשית.

הסט הזה מספיק כדי לחזור עם הערכה ותוכנית עבודה: שלבים, הרכב צוות, לוחות זמנים, נקודות קבלה וסדר בדיקות לפני ההשקה. תארו את המשימה בצורה נוחה — נחזור עם הערכה ותוכנית, ואת הנקודות השנויות במחלוקת נבחן בפגישה.